Need Help With Mode 3 ALDL Command

[84Elky]

Need some help using Mode 3 -- using TunerPro RT v5; AUJP $8d. Have attached pics of what doesn't work. It appears to mimic that used for Mode 1 that works.

Trying to get values for 3 variables only, excluding everything else: 0x00A2, 0x0045 and 0x00A4. Am sending:
0xF4 0x5C 0x03 0x00 0xA2 0x00 0x45 0x00 0x45 0x22
using a macro that first uses the above in a Send command and then executes a Reply command that waits for the data

where:
0xF4 = Device ID
0x5C = Msg Len = (2 * 3 bytes) + 1 + 85 = 92 = 0x5C (is this correct?)
0x03 = Mode 3
0x00 0xA2 = MSB LSB of 1st variable
0x00 0x45 = MSB LSB of 2nd variable
0x00 0xA4 = MSB LSB of 3rd variable
0x22 = 2's complement checksum of the above (is this correct?)

The only differences from Mode 1 appear to be message length and checksum. What about the Reply command Body and Payload values. Are they correct?

[RobertISaar]

i notice you don't have the "process data" box checked on the reply..... you'll need that enabled.

setting body size to 7 instead of 6 should help as well. that way the checksum is accounted for, or at least whatever ghost in the machine that causes bad data when there isn't Payload Size + Payload Offset + 1 for Body Size.

[EagleMark]

Is the Engine Send checksum correct at 2's compliment? I usually calculate it and add it to end of string. Then use none. It works as a double check as you choose
Sum = 0x00
2's Compliment = 0x00
1's Compliment = 0xFF

Kind of a double check if it's calculated properly...

[RobertISaar]

i calculated it as correct.... i just let TP do the calculation when possible anyways, computer is far less likely to make a math error than i am.

[84Elky]

Thanks for the input guys. Everything now working perfectly. A few comments:


It was not necessary to use 7 bytes for the Body Size. Seems receiving 3 bytes of data (3 = Payload Size) + (Payload Offset of 3 bytes = 1 byte for Device ID + 1 byte for Mode # + 1 byte for null char???) = Body Size = 6 was OK.
It worked with the checksum in the string and without it using 2's complement.
Thanks for catching the omission of ticking the Process Data box. But don't understand its purpose. Without it checked, nothing is logged which indicates that the data was likely transmitted by the ECM but ignored by TPro. Any idea under what circumstances NOT processing data would be a valid case?
Sampling rate strangeness - This is a crude analysis but is consistent. Only the Mode changes.

Under Mode 1, the frequency of samples in the log on my laptop is approximately 136 milliseconds (ms) per sample, or 7.35 samples per second (100 samples in approximately 13.6 seconds = 13.6 sec / 100 samples * 1000 ms / sec = 136ms per sample). So we know that data can be requested and received at least at that frequency. And each sample received is 66 bytes=660 bits.
Yet under Mode 3 a similar 100 samples is logged in 6.4 seconds = 64ms per sample, or roughly 2x faster than Mode 1 (15.6 samples per second). But my Mode 3 test is only receiving 6 bytes from the ECM versus 66 for Mode 1. Seems the sample rate for Mode 3 would be approx. 10 times faster than Mode 1, rather than only 2x. Granted Mode 3 is sending 8 bytes to the ECM to make its request versus only 3 for Mode 1, but surely Mode 3 overhead is not 5x greater than Mode 1 to only provide a 2x improved throghput. Something's not consistent. What am I missing?



So, I'm back to the question: At what frequency does TPro request an ALDL data transmit from the ECM using the macro defined it the ADX file header? Sure wish one of the TPro programmers would chime in. Request frequency must have something to do with this.

When time permits, I'll do a write-up of the details of how to do a Mode 3 request and post it. Thanks again for your prompt replies.

[RobertISaar]

on a similar ECM, just a different mask, using tunerpro v5, i've gotten in the 40Hz range before....

did you try using a body size set to 7?

notification box flashing red?

the only person with any official information about how TP does its stuff is Mark Mansur.

[84Elky]

Did not try 7 bytes because 6 worked, but will tomorrow and reply. Not sure what this means: "notification box flashing red?"

I posted on tunerpro.net so see if Magnus will respond to the TPro sample rate question.

[84Elky]

on a similar ECM, just a different mask, using tunerpro v5, i've gotten in the 40Hz range before....

did you try using a body size set to 7?

notification box flashing red?
Because you asked about using 7 as a Body Size, I ran some tests where the only thing that changed was the Body Size. One Mode 3 ADX file had 6 bytes and another identical ADX file had 7. Note below that changing from 6 to 7 shockingly slowed the sample rate, which somewhat makes sense if any of this does. Sample rate went from 15+ samples/sec to 10+, a drop of 34%!!! But the 6 byte sample rates are still way low from what Magnus is apparently getting. He's saying Mode 1 DDS should be 11-12 Hz. Mine are 7+. And with a 2.2 GHz 64 bit Laptop. Really weird.

Note the Hz reported by TPro below. Is that the packet frequency -- seems so based on the calculated frequency.
And is the "Notification box" you're referencing the one reporting Frequency to the left of the DA Connected window?
Can the sample frequency possibly be affected by using AutoProm as opposed to using a chip?
Would appreciate others providing their Mode 1, 100 sample, sample frequency.


=======================================

TunerPro Sample Rates -----------------------------

The logs below with "Mode 3" in the title were done 2/3/2014. The ONLY variable was the ADX file.



The other log files were randomly chosen for comparison purposes.




The logs with "(Mod Mode 1)" extracts additional bit masks from DDS values and is reporting some



values not normally reported from the DDS because addresses were changed in the code



The TPro Hz value is that reported in the window left of the "DA Connected" window. Not



sure what this is reporting, but likely the theoretical sample frequency















100 Sample

Calculated

TPro



Log Files

Begin Secs

End Secs

Time

Frequency

Frequency



100 Samples

Sample 50

Sample 100

Difference

(Samples/Sec)

(Hz)











H9 (True Mode 1)

179.199

192.905

13.706

7.30

(A)











Mod 17 (True Mode 1)

6.579

20.013

13.434

7.44

(A)











H47 (Minor Mod Mode 1)

13.284

26.981

13.697

7.30

(A)











Mode 1 (Big Mod Mode 1)

6.517

21.389

14.872

6.72

6.57



















Mode 3, 6 Bytes #1

4.479

10.878

6.399

15.63

(A)











Mode 3, 6 Bytes #2

2.944

9.342

6.398

15.63

14.9-16.33











Mode 3, 7 Bytes #1

4.415

14.029

9.614

10.40

(A)











Mode 3, 7 Bytes #2

4.415

14.317

9.902

10.10

11.5-13.14











(A) TPro information not recorded

[RobertISaar]

i've calculated my mode1 request rate with a 63 byte stream to be 10.6x Hz, this was a while ago so i likely don't have the logs around anymore.

the type and number of displays i have open can signficantly impact that number though.... if i record a log with the monitors tab active with ~7 items being graphed while monitoring, topping 8Hz is a challenge. because of this, i record logs with only the item list view open, if any.

1.6GHz dual-core processor, for reference.

yes, the notification box is how you described. it will flash red when packet errors occur, which i believe there is a counter for as well.

i don't think the autoprom makes a difference, but i've been told of some weird things happening when using an ostrich/autoprom and datalogging.

maybe if the snow clears out in the next couple of days, i'll unbury my car and run a few tests.

[EagleMark]

i don't think the autoprom makes a difference, but i've been told of some weird things happening when using an ostrich/autoprom and datalogging.
During Mode 3 commands only?

I've never used Mode 3-1 and never had any issues with AutoProm...

[RobertISaar]

no idea.... i don't know why emulation makes a difference, but it seems to upset certain masks. 58 is one of them, i don't know about 8D.

[84Elky]

Thought I'd update some info on logging sample rates previously posted here after corresponding with Magnus at TunerPro. To improve sample rate frequency, he suggested 2 things:


changing the FTDI driver latency to 1ms, and
setting the AutoProm to pass-through mode.


In the Mode 3 tests previously discussed in this thread, changing Latency to 1ms from the default of 16ms helped, but only marginally. Sample rate increased 6% at Body Size = 6 bytes and increased 17% at body size = 7 bytes. The real improvement came by enabling pass-through mode on the AutoProm. This provided a 95% sample rate increase from 15.6Hz to 32.4Hz for 6 bytes, and a 310% increase from 10.4 Hz to 32.5Hz for 7 bytes. There was essentially no difference between 6 and 7 body size bytes using Latency = 1ms and pass-through. This lack of difference for 6 and 7 bytes obvoiusly has to do with how the AutoProm processes data when not in passs-through mode.

Also, Magnus pointed out that the maximum theoretical sample rate (in Hz = samples/sec) for an 8192 Baud ECM is:


910 bytes 1 sample
-------------- x -------------------------------------------------------
sec (# transmitted bytes + # received bytes)

where:
8192 Baud ~= 910 bytes/sec

The theoretical sample rate does not include the overhead of the i/o devices (PC and ECM). So for the Mode 3 test here, the maximum achievable sample rate would be:
910 / (9 + 7) = 56.9 Hz

Below is a revised Sample Rate table from that in Post #8.


================================================== ===



The only variable in all the "Mode 3" tests below was the ADX file specifying 6 or 7 bytes as Body Size.



All other log files were randomly chosen for comparison purposes.





The logs with "Mod" extracts additional bit masks from Mode 1 DDS values and is reporting some



values not normally reported from the DDS because addresses were changed in the code



The TPro Hz value is that reported in the window left of the "DA Connected" window.























100 Sample

Calculated

TPro



Log Files

Begin Secs

End Secs

Time

Frequency

Frequency



100 Samples

Sample 50

Sample 100

Difference

(Samples/Sec)

(Hz)











FTDI Driver Latency in all tests below = 16






H9 (True Mode 1)

179.199

192.905

13.706

7.30

(A)











Mod 17 (True Mode 1)

6.579

20.013

13.434

7.44

(A)











H47 (Minor Mod Mode 1)

13.284

26.981

13.697

7.30

(A)











Mode 1 (Big Mod Mode 1)

6.517

21.389

14.872

6.72

6.57



















Mode 3, 6 Bytes #1

4.479

10.878

6.399

15.63

(A)











Mode 3, 6 Bytes #2

2.944

9.342

6.398

15.63

14.9-16.33











Mode 3, 7 Bytes #1

4.415

14.029

9.614

10.40

(A)











Mode 3, 7 Bytes #2

4.415

14.317

9.902

10.10

11.5-13.14



















FTDI Driver Latency in all tests below = 1






Mdoe 3, 6 Bytes, Lat=1

2.951

8.976

6.025

16.60

18.07-19.72











Mdoe 3, 7 Bytes, Lat=1

4.020

12.220

8.200

12.20

11.50-13.15











Mdoe 3, 6 Bytes, Lat=1, PT

1.500

4.594

3.094

32.32

31.4-32.8











Mdoe 3, 7 Bytes, Lat=1, PT

1.515

4.584

3.069

32.58

31.7-32.8











"Lat" = FTDI Driver Latency








"PT" = AutoProm Pass-through















(A) TPro information not recorded