95 LT1 Vette and V5 TunerProRT setup

dfarney · Post by **dfarney** » Sat Oct 24, 2009 2:13 pm

Hi - I am trying to data-log a 95 vette with TP V5 build 5.00.4331. I am having trouble getting TP to conect to the pcm (16181333). I am using a Moates ALDU1 and CABL2 Combo for my ALDL cable. It works fine with TunerCat - used it with ScannerPro - TunerProRT version 4 also connected with it (although it did not data-log correctly). In V5 when I go to Tools/Preferences and set my com Port to Com4 and click on "Test for valid Interface" it returns a "Cable not found or not functioning" error when the ALDU1 is connected to the car. If I unplug the cable from the ALDU1 to the pcm and leave the ALDU1 connected to the laptop it finds and reports correct connection. (This also is the same behavior in V4 - except that when I went to Tools/ALDLData Logging - I was able to load an "94 - 95 LT1 F Car.ads" as a Definition File and then click on Connect to ECM button and it would connect) I am using the EE.xdf file also.
Any help will be greatly appreciated.
Thanks
Dan

Six_Shooter · Post by **Six_Shooter** » Sat Oct 24, 2009 3:11 pm

A "non-functioning" error will be returned with the cable connected to the ALDL port. The cable muct be disconnected from the car to use the "find cable" feature.

You must import the .ads file into TO RT V5 and save as an .adx. The Scanner Pro .adx you have will not work in TP RT V5, since there has been changes to what the .adx file contains. TP RT V5 allows for LOTS of customization.

Anyway, once you properly import the working ads, you should have no problems connecting.

Even though I do experiance some connectivity issues, but is a result of port conflicts (at least that's what it seems to be at this point), I have easier connection with V5 than I did with V4.

The xdf you are using doesn't effect the connectivity to the ALDL.

dfarney · Post by **dfarney** » Mon Oct 26, 2009 7:10 am

Thanks - that helped - It is now connecting. I'll probably have more questions later - I feel like a blind man in a dark room, wouldn't matter if he could see!

Post by **robertisaar** » Mon Oct 26, 2009 9:25 am

dfarney: me and mark have been working on a EE XDF for a little while, want to check it out and see how well it works?

dfarney · Post by **dfarney** » Tue Oct 27, 2009 6:08 pm

robertisaar wrote:dfarney: me and mark have been working on a EE XDF for a little while, want to check it out and see how well it works?

Yes I certainly want to. How do I get it? Probably best way to get it to me is email - farney56@gmail.com

Which leads me to my next ? When I am connected to the car computer, I am getting what seems to me to be a lot of errors. In the bottom of the screen it will continually flash between connected and error. (not sure exactly what it said right now) During the time that the counter for engine run time reached 60 (I assume 60 seconds) the error counter would increase by about 150 to 170. While the car is running odd numbers will flash on the Item Lists items. example - the Engine Runtime would count up as normal but flash to like some 4 -5 digit number so fast that you could not read it. This will happen on many but maybe not all of the items.
Is there something that I need to change?
Thanks
Dan

Post by **robertisaar** » Tue Oct 27, 2009 6:15 pm

i have that issue once in a while, but it's either the port on my laptop or the cable itself causing it. i usually have to exit tunerpro, remove the cable, wait a few seconds and try again. 99% of the time, that fixes my issue with it. while logging i normally pick up around 5 or 6 hours every half hour, almost always at least 1 during connect then the rest are random.

sending the ADX now. there are different streams depending on if it's a manual or auto, so i'll just send both.

dfarney · Post by **dfarney** » Wed Oct 28, 2009 8:53 am

robertisaar wrote:dfarney: me and mark have been working on a EE XDF for a little while, want to check it out and see how well it works?

I sent an email back to you - I think that Coolant Temp F is not reporting right. This XDF seems to be much more complete than the one that I was using. I also attached a log/scan to the email - next time I'll zip it - sorry
Thanks for any help/insight that you have for me
Dan

Post by **robertisaar** » Wed Oct 28, 2009 10:04 am

you're right about the coolant temp, when i was punching in the conversion, i missed the -40 part, i'm sending the updated version to you.

i'm also answering the other questions from the email in my email.

Post by **Mangus** » Wed Oct 28, 2009 5:50 pm

Does this mean that the ADX Robert sent is connecting and showing valid data?

dfarney · Post by **dfarney** » Thu Oct 29, 2009 1:58 pm

Mangus wrote:Does this mean that the ADX Robert sent is connecting and showing valid data?

I would say that the answer is yes. I am still getting a lot of "ALDL Data Error" messages at the bottom of the main screen. By a lot I mean that it is flashing constantly. The Acquisition/Item Lists shows data (I can only assume that it is valid data at this point - that's how new at this I am) The .csv file that I exported has occasional "garbage" lines in it - if you want to look at it I will zip and email. I would be interested to know if the "ALDL Data Error" is normal or not. My cable is a Moates ALDU1 and CABL2 Combo and seems to work OK with other programs - specifically Tunercat.
Mark - quick ? Is PCM reading and flashing something that could or might be added to V5? In my situation I would love to have 1 program that did the reading/flashing, tuning, and data logging. Having said that I still think that you have a super program and will be registering it soon just for the data logging part of it.
Thanks
Dan

Six_Shooter · Post by **Six_Shooter** » Thu Oct 29, 2009 2:46 pm

Tuner Pro RT can datalog and "flash" the ECM, with the use of an Ostrich (2.0), or APU1.

No, constant data errors is not normal.

As I've read on some other trouble threads, concerning datalogging with V5, there may need to be a delay added to the command string.

Post by **Mangus** » Thu Oct 29, 2009 3:18 pm

I've got the information needed to read/flash LT1 PCMs, but nothing to test it with. If I could hunt down a PCM and a way to test the code, I may do it.

dfarney · Post by **dfarney** » Fri Oct 30, 2009 4:43 am

Six_Shooter wrote:Tuner Pro RT can datalog and "flash" the ECM, with the use of an Ostrich (2.0), or APU1.

No, constant data errors is not normal.

As I've read on some other trouble threads, concerning datalogging with V5, there may need to be a delay added to the command string.

Sorry - Maybe I wasn't totally clear. On 94 & 95 Vette LT1's (and other 94 & 95 LT1 cars I think) we reflash the PCM with just a cable - no other equipment needed.

dfarney · Post by **dfarney** » Fri Oct 30, 2009 4:50 am

Mangus wrote:I've got the information needed to read/flash LT1 PCMs, but nothing to test it with. If I could hunt down a PCM and a way to test the code, I may do it.

If you decide to pursue this and need a car to test it on maybe you can send me the test PCM and I will switch it out on my car to try. (before trying on the one in my car now)
Dan

96HawkCnvt · Post by **96HawkCnvt** » Fri Oct 30, 2009 6:52 pm

Mangus wrote:I've got the information needed to read/flash LT1 PCMs, but nothing to test it with. If I could hunt down a PCM and a way to test the code, I may do it.

Mark,

I would be happy to send you a PCM & some connectors if it would help. Let me know when you need it and where to send it.

Todd

zx900e2 · Post by **zx900e2** » Fri Nov 20, 2009 11:37 am

Could you also send me the $EE file. I have a 94 LT1 Camaro that I would like to try it on. I have one from years ago but I think it is missing some stuff.

Probably the best way to send it is to my email address at zx900e2@gmail.com.

I wanted to start mapping out the $EE bin file on my car but I'm not sure where to get the data from to figure out which addresses of the file are used for what in the computer. I'm sure there is a way to do it and I am sure GM has it documented but I'm not sure how to even start on that one.

Post by **Mangus** » Fri Nov 20, 2009 11:38 am

zx900e2 wrote:Could you also send me the $EE file. I have a 94 LT1 Camaro that I would like to try it on. I have one from years ago but I think it is missing some stuff.

Probably the best way to send it is to my email address at zx900e2@gmail.com.

I wanted to start mapping out the $EE bin file on my car but I'm not sure where to get the data from to figure out which addresses of the file are used for what in the computer. I'm sure there is a way to do it and I am sure GM has it documented but I'm not sure how to even start on that one.

There's an EE bin definition on the TunerPro site. Please download it from there.

Faceman · Post by **Faceman** » Thu May 12, 2011 6:36 am

Hi,

it's quite an old thread, but maybe that issue was solved. With my 95 auto LT1 Vette I'm facing the same problem as Dan had or still has. I installed Build 5.00.7575.00 on my XP machine using EE.xdf and EE_Auto.adx files.
I did not yet check the xdf stuff but the datastream definition does not work with my car, I am getting a lot of errors and weird values are shown in the data list. Does anybody have TunerPro running with a 95 LT1 vette?

Thanks and Greetings, Heiko

Faceman · Post by **Faceman** » Fri May 13, 2011 5:17 am

Today I used Roberts file (EE F Y B & D Body Auto.adx) that I downloaded from his website: http://www.robertisaar.co.cc/web_images ... streams.7z
With this file the connection is much more stable (only a few errors). But the reading is strange, I took a movie with car at idle:
http://www.little-red-corvette.net/Tune ... Values.avi

Sometimes feasible values are shown as a screenshot shows:

Something is still wrong with my PCM, my cable or whatever.

Post by **robertisaar** » Fri May 13, 2011 5:55 am

interesting..... when i had my 2 transistor cable, it tended to do that as well....

we can slow down the data rate a bit to see if that will get the stream to correct itself. if it doesn't, then some other module on the ALDL line is making too much noise or the cable itself is the issue.

Faceman · Post by **Faceman** » Fri May 13, 2011 6:09 am

Hi Robert,

thanks for your reply. I bought the cable a while ago from www.aldlcable.com
It's the USB version with the 16 pin connector (95 vette). It works perfectly with TunerCat (reading/programming flash) and with PCMcomm (showing correct values). With FreeScan there are similar problems, only sometimes values are shown.

Is there any setup to do for the Serial Port? I am wondering that I do nowhere read something about the correct settings. I am using the latest drivers from http://www.ftdichip.com/Drivers/VCP.htm version 2.8.14.0.

The setup: 9600 Baud, 8N1, Flow control: none. With the advanced button I could change more: Receive/Transmit Bytes, Latency Timer, Timeouts and Miscellaneous. Maybe some setup there would help but I do not know.

How can u slow down the data rate?

Can I capture the serial data somehow to get figured out if another module causes these problems, I could imagine the FX3 module because I disconnected the FX3 stuff (installed a coilover) and the "Service Ride Control" light is on.

Post by **robertisaar** » Fri May 13, 2011 6:27 am

all of the items you listed should probably best be left alone.

we can slow down the data rate by adding a delay between the the periods of time where TP "listens" to the serial data and then sends out another request for more data.

here is a quick revision to the one you downloaded from my 7Z archive, it has both the delay and extra commands to get the CCM to be quiet when datalogging.

http://bit.ly/jKxWCT

Faceman · Post by **Faceman** » Fri May 13, 2011 6:41 am

I'm standing right besides the car currently

The connection with the new file is not as stable as with the initial one (much more errors) and the values are still flickering. Do I have a chance to trace the serial data flow with TunerPro?

cmaje72 · Post by **cmaje72** » Fri May 13, 2011 7:08 am

Go into the Com port settings in device manager and try turning the latency down to 1 (by default I think its on 16). See if it gets better.

Faceman · Post by **Faceman** » Fri May 13, 2011 7:24 am

Yes, default is 16, changing it to "1" did not help, all the same:
- TunerPro 5.0.7575 + downloaded ADX from Robert: low connection errors, flickering
- TunerPro 5.0.7575 + 'EE_Auto.adx': many connection errors, flickering
- PCMcomm 4.40: works
- Freescan 2.0.1: shows values only sometimes
- Datamaster 4.01: loses connection/sync to PCM very often

Next week I can check another 95 LT1 auto vette. Maybe I get another cable organized to check this.
I really wanna change to TunerPro because I like the diagrams, with PCMcomm I have no idea how to visualize the logged data.

Post by **robertisaar** » Fri May 13, 2011 7:47 am

do you have a link to this "PCMcomm"? i've never heard of it before and googling it hasn't turned up much.

Faceman · Post by **Faceman** » Fri May 13, 2011 7:56 am

It's especially for 94 and 95 LT1: http://carputing.tripod.com/pcmcomm.exe

Post by **robertisaar** » Fri May 13, 2011 9:10 am

i don't suppose you are familiar with the concept of serial port monitors.....

Faceman · Post by **Faceman** » Fri May 13, 2011 8:25 pm

Not really

Such a thing: http://technet.microsoft.com/en-us/sysi ... s/bb896644 ??

But I would like to see some interpretation of the communication going on regarding ALDL GM 8192. The plain hex numbers are too strange for me

Post by **robertisaar** » Sat May 14, 2011 5:44 am

that looks like it would work...

i've been trying to get serialmon working on my machine, but the software monitoring seems to fail on all of my machines... this program doesn't seem to be working either, but i'm also running a 64 bit machine, so that may be the issue.

the idea here would be to see WHY the PCMcomm application works without any kind of errors... and if we can view the commands it sends and how often it sends them, we can replicate that in tunerpro.

Faceman · Post by **Faceman** » Sun May 15, 2011 8:34 am

I captured some serial data. The init of the COM port is the first thing that looks quite different:

PCMcomm:
0 0.04120552 pcmcomm.exe IRP_MJ_CREATE VCP0 SUCCESS Options: Open
1 0.00293417 pcmcomm.exe IOCTL_SERIAL_SET_WAIT_MASK VCP0 SUCCESS Mask: RXCHAR
2 0.00000251 pcmcomm.exe IOCTL_SERIAL_SET_QUEUE_SIZE VCP0 SUCCESS InSize: 4096 OutSize: 4096
3 0.00000559 pcmcomm.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: TXABORT RXABORT TXCLEAR RXCLEAR
4 0.00000279 pcmcomm.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:-1 RM:-1 RC:1 WM:0 WC:0
5 0.00000223 pcmcomm.exe IOCTL_SERIAL_GET_BAUD_RATE VCP0 SUCCESS
6 0.00000307 pcmcomm.exe IOCTL_SERIAL_GET_LINE_CONTROL VCP0 SUCCESS
7 0.00000251 pcmcomm.exe IOCTL_SERIAL_GET_CHARS VCP0 SUCCESS
8 0.00000196 pcmcomm.exe IOCTL_SERIAL_GET_HANDFLOW VCP0 SUCCESS
9 0.00000223 pcmcomm.exe IOCTL_SERIAL_GET_BAUD_RATE VCP0 SUCCESS
10 0.00000223 pcmcomm.exe IOCTL_SERIAL_GET_LINE_CONTROL VCP0 SUCCESS
11 0.00000196 pcmcomm.exe IOCTL_SERIAL_GET_CHARS VCP0 SUCCESS
12 0.00000196 pcmcomm.exe IOCTL_SERIAL_GET_HANDFLOW VCP0 SUCCESS
13 0.00261206 pcmcomm.exe IOCTL_SERIAL_SET_BAUD_RATE VCP0 SUCCESS Rate: 8192
14 0.00207205 pcmcomm.exe IOCTL_SERIAL_SET_RTS VCP0 SUCCESS
15 0.00286601 pcmcomm.exe IOCTL_SERIAL_SET_DTR VCP0 SUCCESS
16 0.00296797 pcmcomm.exe IOCTL_SERIAL_SET_LINE_CONTROL VCP0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
17 0.00000251 pcmcomm.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13
18 0.00293529 pcmcomm.exe IOCTL_SERIAL_SET_HANDFLOW VCP0 SUCCESS Shake:1 Replace:40 XonLimit:100 XoffLimit:100
19 0.00258999 pcmcomm.exe IOCTL_SERIAL_SET_DTR VCP0 SUCCESS
20 0.00274448 pcmcomm.exe IOCTL_SERIAL_SET_WAIT_MASK VCP0 SUCCESS Mask: RXCHAR
21 0.00000531 pcmcomm.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: RXCLEAR

TunerPro:
0 0.04080686 TunerPro.exe IRP_MJ_CREATE VCP0 SUCCESS Options: Open
1 0.00000587 TunerPro.exe IOCTL_SERIAL_GET_BAUD_RATE VCP0 SUCCESS
2 0.00000335 TunerPro.exe IOCTL_SERIAL_GET_LINE_CONTROL VCP0 SUCCESS
3 0.00000251 TunerPro.exe IOCTL_SERIAL_GET_CHARS VCP0 SUCCESS
4 0.00000223 TunerPro.exe IOCTL_SERIAL_GET_HANDFLOW VCP0 SUCCESS
5 0.00000223 TunerPro.exe IOCTL_SERIAL_GET_BAUD_RATE VCP0 SUCCESS
6 0.00000223 TunerPro.exe IOCTL_SERIAL_GET_LINE_CONTROL VCP0 SUCCESS
7 0.00000196 TunerPro.exe IOCTL_SERIAL_GET_CHARS VCP0 SUCCESS
8 0.00000196 TunerPro.exe IOCTL_SERIAL_GET_HANDFLOW VCP0 SUCCESS
9 0.00280175 TunerPro.exe IOCTL_SERIAL_SET_BAUD_RATE VCP0 SUCCESS Rate: 8192
10 0.00274951 TunerPro.exe IOCTL_SERIAL_SET_RTS VCP0 SUCCESS
11 0.00222850 TunerPro.exe IOCTL_SERIAL_SET_DTR VCP0 SUCCESS
12 0.00281404 TunerPro.exe IOCTL_SERIAL_SET_LINE_CONTROL VCP0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
13 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13
14 0.00293641 TunerPro.exe IOCTL_SERIAL_SET_HANDFLOW VCP0 SUCCESS Shake:1 Replace:40 XonLimit:2048 XoffLimit:512
15 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:40 RM:0 RC:300 WM:0 WC:300
16 0.00000223 TunerPro.exe IOCTL_SERIAL_GET_BAUD_RATE VCP0 SUCCESS
17 0.00000251 TunerPro.exe IOCTL_SERIAL_GET_LINE_CONTROL VCP0 SUCCESS
18 0.00000196 TunerPro.exe IOCTL_SERIAL_GET_CHARS VCP0 SUCCESS
19 0.00000196 TunerPro.exe IOCTL_SERIAL_GET_HANDFLOW VCP0 SUCCESS
20 0.00000223 TunerPro.exe IOCTL_SERIAL_GET_BAUD_RATE VCP0 SUCCESS
21 0.00000196 TunerPro.exe IOCTL_SERIAL_GET_LINE_CONTROL VCP0 SUCCESS
22 0.00000223 TunerPro.exe IOCTL_SERIAL_GET_CHARS VCP0 SUCCESS
23 0.00000196 TunerPro.exe IOCTL_SERIAL_GET_HANDFLOW VCP0 SUCCESS
24 0.00273079 TunerPro.exe IOCTL_SERIAL_SET_BAUD_RATE VCP0 SUCCESS Rate: 8192
25 0.00293501 TunerPro.exe IOCTL_SERIAL_SET_RTS VCP0 SUCCESS
26 0.00308307 TunerPro.exe IOCTL_SERIAL_SET_DTR VCP0 SUCCESS
27 0.00265257 TunerPro.exe IOCTL_SERIAL_SET_LINE_CONTROL VCP0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
28 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13
29 0.00313308 TunerPro.exe IOCTL_SERIAL_SET_HANDFLOW VCP0 SUCCESS Shake:1 Replace:40 XonLimit:2048 XoffLimit:512
30 0.00000251 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS
31 0.00000223 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110
32 0.00000223 TunerPro.exe IOCTL_SERIAL_SET_QUEUE_SIZE VCP0 SUCCESS InSize: 1024 OutSize: 512
33 0.00000223 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS
34 0.00000223 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110
35 0.00000223 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS
36 0.00000223 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:200 RM:0 RC:750 WM:0 WC:300
37 0.05874071 TunerPro.exe IRP_MJ_READ VCP0 SUCCESS Length 3: F0 56 F1
38 0.00000587 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS
39 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:75 RM:0 RC:400 WM:0 WC:300
40 0.00000503 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: RXCLEAR
41 0.00000279 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: TXCLEAR

Faceman · Post by **Faceman** » Sun May 15, 2011 8:37 am

It seems as would TunerPro run the init process twice, the timeouts are different. Later during communication it always does:
227 0.00000782 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS
228 0.00000251 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:75 RM:0 RC:400 WM:0 WC:300
229 0.00000615 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: RXCLEAR
230 0.00000279 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: TXCLEAR
231 0.00139291 TunerPro.exe IRP_MJ_WRITE VCP0 SUCCESS Length 5: F4 57 01 00 B4
232 0.00694725 TunerPro.exe IRP_MJ_READ VCP0 SUCCESS Length 5: F4 57 01 00 B4
233 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS
234 0.00000223 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:200 RM:0 RC:400 WM:0 WC:300
235 0.08777959 TunerPro.exe IRP_MJ_READ VCP0 SUCCESS Length 63: ...
236 0.00000754 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS
237 0.00000251 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:75 RM:0 RC:400 WM:0 WC:300
238 0.00000559 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: RXCLEAR
239 0.00000335 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: TXCLEAR

Faceman · Post by **Faceman** » Sun May 15, 2011 8:40 am

Another point: until PCMcomm sends "normal" messages it sends "F1 56 08 B1" during init of the PCM communication. What does it mean?

A list of the serial writings without the replys:

Line 3642: 3641 0.00124262 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 4: F4 56 08 AE
Line 4060: 4059 0.00095264 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 4: F4 56 08 AE
Line 4841: 4840 0.00083865 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 4: F1 56 08 B1
Line 9582: 9581 0.00081491 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 4: F4 56 08 AE
Line 10352: 10351 0.00030367 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 4: F1 56 08 B1
Line 10353: 10352 0.00119792 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 4: F4 56 08 AE
Line 13701: 88959 0.00126497 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 5: F4 57 01 01 B3
Line 14461: 105148 0.00050342 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 5: F4 57 01 01 B3
Line 15224: 116932 0.00096688 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 5: F4 57 01 00 B4

Post by **robertisaar** » Sun May 15, 2011 9:03 am

Faceman wrote:Another point: until PCMcomm sends "normal" messages it sends "F1 56 08 B1" during init of the PCM communication. What does it mean?

A list of the serial writings without the replys:

Line 3642: 3641 0.00124262 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 4: F4 56 08 AE
Line 4060: 4059 0.00095264 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 4: F4 56 08 AE
Line 4841: 4840 0.00083865 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 4: F1 56 08 B1
Line 9582: 9581 0.00081491 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 4: F4 56 08 AE
Line 10352: 10351 0.00030367 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 4: F1 56 08 B1
Line 10353: 10352 0.00119792 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 4: F4 56 08 AE
Line 13701: 88959 0.00126497 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 5: F4 57 01 01 B3
Line 14461: 105148 0.00050342 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 5: F4 57 01 01 B3
Line 15224: 116932 0.00096688 pcmcomm.exe IRP_MJ_WRITE VCP0 SUCCESS Length 5: F4 57 01 00 B4

AWESOME!

F1 56 08 B1 is the software telling the CCM to quit transmitting on the ALDL line. F1 being the module, 56 refers to message length, 08 is mode(8 being quit transmitting) and B1 is the checksum.

so what it looks like is....

1. mode 8 to PCM
2. mode 8 to PCM
3. mode 8 to CCM
4. mode 8 to PCM
5. mode 8 to CCM
6. mode 8 to PCM
7. PCM mode 1 message 1 request
8. PCM mode 1 message 1 request
9. PCM mode 1 message 0 request

Post by **Mangus** » Sun May 15, 2011 9:07 am

robertisaar wrote: AWESOME!

F1 56 08 B1 is the software telling the CCM to quit transmitting on the ALDL line. F1 being the module, 56 refers to message length, 08 is mode(8 being quit transmitting) and B1 is the checksum.

so what it looks like is....

1. mode 8 to PCM
2. mode 8 to PCM
3. mode 8 to CCM
4. mode 8 to PCM
5. mode 8 to CCM
6. mode 8 to PCM
7. PCM mode 1 message 1 request
8. PCM mode 1 message 1 request
9. PCM mode 1 message 0 request

Exactly correct. I had an EE ADX sitting around that I got working when I had a test vehicle available, but I don't know what happened to it. Get one workin', flesh it out, and send it my way.

Faceman · Post by **Faceman** » Sun May 15, 2011 9:14 am

PCMcomm shows some interpreted information if I switch it on.
Sometimes it shows "bad chksum", "bad length bad chksum", "disable echo" and as a result it resends that "silent" stuff again to CCM and PCM as it seems. Maybe until the line is quite. Because later no more bad chksum and bad length printouts are there.
Maybe we could simply add that CCM quite stuff to the macro and repeat both... let's say 5 times... ?

Post by **robertisaar** » Sun May 15, 2011 9:28 am

don't suppose there is any pattern to how long before the bad checksum messages come up?

and the second volley of mode 8 commands are the last time they get sent?

Post by **Mangus** » Sun May 15, 2011 12:53 pm

The PCM or BCM typically send out ifle chatter (f4 55 b0, for instance), and in response the scanner should send the silence cmds. Perhaps the idle messages are confusing the other software.

Faceman · Post by **Faceman** » Mon May 16, 2011 2:02 am

Mangus, the "f4 55 b0" sequence I do not find anywhere in the log. Do you remember what you all changed to get $EE ADX work with a 94 or 95 vette?

Post by **Mangus** » Mon May 16, 2011 7:42 am

Faceman wrote:Mangus, the "f4 55 b0" sequence I do not find anywhere in the log. Do you remember what you all changed to get $EE ADX work with a 94 or 95 vette?

That was an example. It could be a different set of bytes, and it could be that EE doesn't send them.

You need the mode 8 commands in place.

Faceman · Post by **Faceman** » Mon May 16, 2011 10:20 am

One question Mangus: does TunerPro 5 calculate and verify the checksum of the ALDL frames?

Post by **Mangus** » Mon May 16, 2011 10:26 am

Faceman wrote:One question Mangus: does TunerPro 5 calculate and verify the checksum of the ALDL frames?

No, not currently.

Faceman · Post by **Faceman** » Mon May 16, 2011 10:40 am

Mangus wrote:
Faceman wrote:One question Mangus: does TunerPro 5 calculate and verify the checksum of the ALDL frames?
No, not currently.

Ok, that's the reason why those wrong values get shown. Can the "Listen for silence" command be used in a loop or similar to send the mode 8 commands until PCM and CCM are quite?

Post by **Mangus** » Mon May 16, 2011 10:40 am

Faceman wrote:
Mangus wrote:
Faceman wrote:One question Mangus: does TunerPro 5 calculate and verify the checksum of the ALDL frames?
No, not currently.
Ok, that's the reason why those wrong values get shown. Can the "Listen for silence" command be used in a loop or similar to send the mode 8 commands until PCM and CCM are quite?

I don't see why not.

Faceman · Post by **Faceman** » Mon May 16, 2011 8:53 pm

I do not find in the docu how to do a loop within the ADX definition that is left when the line is quite. Maybe someone can help me out. Robert help!

Post by **robertisaar** » Tue May 17, 2011 8:45 am

i don't think i've ever implimented a "listen for silence" command before.... and as such, i'm not quite certain how to setup the ADX so that it will listen for silence, and then if it sees data still flowing, to continue sending mode 8 commands, and then if silence free, start throwing out the mode 1 message x commands.

Mark?

Faceman · Post by **Faceman** » Mon May 23, 2011 10:02 pm

Robert, I changed your ADX file: created Mode 8 command for CCM, added it to the Mode 8 macro. The two different options for the repeat count is mysterious to me. There is one on the Macro page called "Macro Repeat Count" and one "Entry Repeat Count". It seems the "Macro Repeat Count" has no affect. I've set it to 50 but the macro is only executed once. Maybe Mark can check it out and give some comments. The mode 8 macro is contained in the Connect sequence macro, I've set the "Entry Repeat Count" for the mode 8 macro to 10. It seems to work

The good news: the file can be used with a Vette now, the CCM is quiet. TunerPro shows meaningful values now. So I could record some data. I will do a test drive during this week maybe.

Faceman · Post by **Faceman** » Tue May 24, 2011 3:55 am

Another thing: the ALDL Mode 1 Message 1 Request is not sent by TunerPro. That causes the Tranny temp to stay at -40°. Is it a bug Mark?

Post by **robertisaar** » Tue May 24, 2011 4:20 am

for testing purposes, i didn't want to throw in the m1m1 request in case it caused even more problems, but since it seems you know how to modify the macros, go ahead and stick it in monitor macro. your data acquisition rate will drop however.

Faceman · Post by **Faceman** » Tue May 24, 2011 4:28 am

I am stupid, okok, there is this Monitor Command on the Header data page... I thought, TunerPro discovers on its own, what data is shown and what commands have to be sent. But it's not this intelligent

I still have no idea how to stopp if there is silence on the line. I now just sent both mode 8 commands, for PCm and CCM, 30 times.