I am running an '87 GTA 350 tpi auto with a 165ECM and have just today loaded up the 6E bin on the chip. I am not able to connect to the ecm using tunerpro RT. I have selected the 165 6e datastream definition, tried checking and unchecking the 160 baud box with no luck and made sure that I had a log file selected for recording.

When I push the connect to ecm button, it shows connecting for a couple seconds then goes right back to not connected.

Anyone have any ideas?? I love the program and have been using it to alter bins, but this data collection aspect of it is just killin me.

Thanks in advance.

 

Not for sure of your app, but if its 160 baud, you might have some trouble. He is working on getting the 160 part of it working better. I had no luck at all getting it to work, but he promised to fix his routines.

 

I to have this problem, My solution is When I open TunerPro RT 3.08 For the first Time When it opens Look at the Bottom of the Screen (in the pic Below WHere it says: Hardware Not Found.) Mine says v86.86.

So I Figured out if I shut Down Tuner Pro RT and Load Moates ECM852 it will connect and Scan The car, When I shut down ECM852 And Restart Tuner Pro RT It will then Say Hardware Not Found And COnnect and scan Perferct. I have Been Meaning to Mention this to Mark but My Lap Top Has No Screen Shot So I cant Give him a Pic of it Yet. Maybe We Will Figure it out now.

Just my .02

 

I am not sure what the 852 is???However, Mark did say that with the 165 ECM and the 6E mask it should connect and sample with a baud rate of 8192.

I am pretty sure that's what Mark said, but I may be mistaken.

 

If TunerPro returns 86.86 in the hardware ID window, somethings wrong (maybe with your cable). TunerPro should not detect ALDL cables.

Sparks - Regarding connecting with you 165 $6E, make sure you have the 10k in place. Trust me, TunerPro works with $6E provided you have things configured correctly, your cable functions, you have the 10k in place, and there's nothing wrong with your bin/ECM/ALDL port. Make sure you have TunerPro configured to use MAX232 as the interface type.

MTPFI - you may have to hit the connect button a couple times to connect. Give it a couple tries before booting up moates's software. I bet it works.

 

Mangus. I have everything there that you have mentioned. Correct settings, good cable. 10K, ecm set to 165 6E, 6E bin,,,etc..????

 

See my post in your other thread. You're very likely running in limp home mode from what you describe.

 

ok mark I think I found My Problem. I checked the resitance on the 10K resistor between Pin A&B and it Measured 9.85K. Could this be why I have to connect to ECM852 before TunerPro RT. After I connect to Moates, close it and Start TunerPro I don't Get the 86.86

 

No, that is a valid resistance (and is within the 15% tolerance).

I'm not sure why you're getting hte 86.86. Its as though the serial buffer isn't flushed before detecting hardware, but it is.

I'm not sure what kind of cable failure could cause this, but I have seen other customers with this, and it turned out to be bad cables. However, you say Moates's software works, so your cable is good.

 

yes if I load moates software first then Close it, then Run TunerPro RT It will connect Instantly no Problem. If I don't Load Moates Software when I press connect It will Connect for a second then Dissconnect.

Hmmm. I have data Logs using your software but i have to connect By the method above. it might be the fact that I don't have the car running yet. I did a 870-165 swap, and have a Brand New ANZA memcal. I am ordering My Flash N Burn, HDR1, & GP1 Tomorrow so I can Disable (VATS) and actually scan the Vechicle Running. Since the vechicle Isn't Running yet the Battery Voltage When I scan it is like 11.5V so that Might Be why the Cable isn't working Correctly.
This is why I haven't Mentioned This problem to you yet is by Using Battery power in the car and Not Running yet so the alternator can't charge the battery so Batt Voltage is Low is my fault, I know it is something on my part is the problem. I can still Data log so It really isn't a Problem

 

Seems to be that Moates stuff is setting some hardware that TunerProRT isn't. . .

Even so, it may be a Windows thing.

RBob.

 

No, its neither. Its more likely that the user isn't allowing enough connection time (i.e. attempts) to connect.

connecting removes the 160 baud chatter and makes the ECM responsive only to the packet dump request.

So connecting with moates "primes" the ECM, making it easier for TunerPro to connect.

I know of many users who have no issues with datalogging $6E with TunerPro, myself and Craig included, so it must be something fishy.

I'll have to put some thought into it, but I'd say its likely there jsut aren't enough connection attempts (it can take 10 or more sometimes, though rarely).

 

I just want to clear things up so anybody reading this Thread wont assume this is a problem with software , I am not saying this is a issue with your software. I love your software, I am having a issue that is probally related to the cable that I make in 15 min or that I am using a very Very Slow laptop. 486DX with 16mb of Ram TO scan the vechicle. I will try to connect more times with TP Rt and see if it works.

{edit: I goofed. I hit the edit key instead of reply and added my post to yours. I didn't make any changes to your post. I apologize. RBob.}

 

Yes, the $6E and '165 ALDL methodology doesn't make it easy. Have you thought about an auto-connect mode? Where the user tells it to connect and TunerProRT has a routine that keeps at it until it can talk to the ECM. May be easy to do by looping through the current connect routine.

RBob.

 

I am the one that brought up that there may not be something quite right. Having done a lot of programming of hardware devices, serial communications, networking, etc. I know how difficult it can be to get things to work properly under various conditions.

An application under Windows has an even more difficult time at this since it has the Windows OS to deal with. With Windows doing multitasking getting accurate consistent timing can also be tricky.

With ALDL interfaces timing is a key part of getting it to work. The other part is having the hardware setup properly. Apparently the hardware in this case is the ECM and it's serial mode.

A case in point is the Lockers HDS.EXE program. On many laptops and desktops (slow 386SX stuff!) it was able to receive data at 56kb and write it to disk, in real time.

A few others had trouble with the newer faster laptops (Such as 66MHz 486's and 100MHz Pent's). Data was being lost to the tune of 50% to 75%. It took some time before I figured out what the problem was.

The 'newer' laptops had hard drive BIOS routines that overran the allowed interrupt off time. IOW they broke the rules. With interrupt driven serial routine this caused a lot of lost data. To fix the problem I enabled the FIFO buffers within the UART.

It wasn't until I had one of these 'broken BIOS' laptops in my hands that I was able to discover the problem and correct it.

RBob.

 

Yes, I'll be redesigning the data acquisition stuff with full-time monitoring. This is all irrelevant to this case, however. The setup in quesiton here works without issue.

However, you should know that in the case of serial communications (parallel is a different story), Windows is not a hinderance (contrary to what most believe). Timing will also not be an issue with serial (and Windows), since the driver buffers any (true) RS232 it receives in its own queue. If the queue is full, it pushes out the oldest bytes (per the definition of a queue). So in a nutshell, the timing is up to the MAX232 chip (or the circuit). And not Windows. Now, you mention 386 platforms. The timing issues there are more likely to be disk related (I assume you're writing data to disk), as well as (less likely, but maybe) the ability for the processor to keep up with the data you're passing it. We don't run into issues like that nowadays, nor will we ever when working with our low-speed, low-tech ECM interfacing software.

Anything modern will always use the FIFO. The old ways of serial programming are gone, my friend. =)

The reason why, for instance, ECM852 doesn't work when executed directly in XP is that XP no longer has a true DOS-wrapped command line (nor does 2k). Without this, there is no built in OS functionality (in a nutshell).

 

The timing I am referring to is being able to time out various processes. Such as waiting a milli-second after a chatter packet is received before transmitting a data request or be-quiet packet.

Or being able to do short timeout periods such as 5 to 50 milliseconds while data is arriving. This is nice to have when attempting to capture a link. As Windows multitasks these types of things become difficult to do within an application.

The data lost problem outlined above was due to receive data overruns in the UART. While writing to the hard drive the BIOS disabled interrupts for too long a period of time. Funny how a slower laptop did not have this problem. They obeyed the compatibility rules with regards to the BIOS.

With interrupts disabled there was no way for the ISR to know that a character needed to be retrieved from the UART and placed into the ring buffer. That data was lost. Testing for and enabling the UART internal FIFO buffers fixed this issue. Also need to test for the correct FIFO buffers. There are UARTS with broken buffers in them. . .

I found the easiest ALDL link to acquire is for $8D's AXCN. No chatter packets. Makes it easy to sync up and very easy to reacquire the link when lost. Just need a decent timer to know that a whole packet has arrived or just a partial packet arrived.

Nothing wrong with the 'old' methods of serial programming

RBob.

 

In the next week or so I hope to have my car back running and intend to install my 165 computer via an adapter harness. I will need to modify the bin file that was preloaded in the just installed PROMinator at that time (changed from 24 to 30# injectors among other things).

You mentioned having problems datalogging with XP. I am running a 2.8ghz Pentium 4 in my laptop with XP. I have the Moates USB adapter for my ALDL cable. Am I going to have data logging issues with the 165 ECM?

 

Nope. My references to issues with XP are exclusive to Moates's ECM852 (or any other DOS-based application that uses ports).

 

Heh. This isn't really a problem so much anymore. I can get pretty good timing (down to sub-millisecond) using QueryPerformanceCounter, even on a machine with an unreasonable number of processes running (many hundreds of the threads active on the system, some not doing anything other than inducing the overhead of context switching).

I've not run into a situation where sub mS timing is required for packet acquisition, but I'm only just discovering the timing goodness required for $58, so I may have some hurdles there. I'm not looking forward to having to re-write all of this.

I'll tell you, its hard to write software that handles all the cases.

 

Two things that I want to mention that can help to get logged in TunerPro RT.

1) I did change the Target Sample Rate to 8Hz under Tools – Preferences.
2) I did change the BIOS and make the USB Bios Support to “Enable” I am using one of the Moates USB to Serial adapter.

It is not full proof but I can get better connection with those settings.
The amount of attempts is average 10 times.

Regards,
Cobra289

 

Hmm. Sounds like I need to get one of Craig's adapters and test it out. If you're averaging 10 connection attempts, thats just annoying! With my AKM cable I average 2. =)

 

Hi Mark,
I will try you information from the other thread:

I just changed the setting on the Lap Top but I need to wait till my clutch arrive from the USA (It will take some time) you know import things.

Regards,
Cobra289

 

Now isn't that the truth! Seems that most of the typing is for error/exception/variance handling. . .

RBob.