TPro ALDL Data Request Rate

[toliphint]

For Mark -- At what frequency does TPro request an ALDL data transmit from the ECM using the Monitor Command macro specified in the ADX file header? Am trying to get 3 bytes of data via Mode 3 very quickly but the fastest frequency I've been able to get is 15.6 samples per second = 64ms per sample.

[Mangus]

It will query at the maximum of the fastest your computer can issue the requests and process the results, and the fastest the ECM can return the data.

I've a test definition for another vehicle that does 1400hz.

[toliphint]

It will query at the maximum of the fastest your computer can issue the requests and process the results, and the fastest the ECM can return the data.

I've a test definition for another vehicle that does 1400hz.

Understand the "maximum of" issue. Wow 1400Hz! I'd be a happy camper if could get something just over 160Hz. So would really appreciate anything you might suggest so I could get there.

Am sending a Mode 3 request for a return of only 3 bytes with a bare-bones ADX file with 3 Values and 3 Bit Masks defined. It all works great, but presently only at 15-16 samples per second. That's a long way from 1400Hz!

Environment:

• 1227730 ECM
  AutoProm and supplied cable to ECM ZIF socket
  Laptop:
  • 2.2GHz CPU
    USB 2.0 (using high quality cable)
    64 bit Win 7

Surely this combo is capable of achieving well over 160+Hz.

Would it be faster with a chip instead of AutoProm?
Anything I can do to the laptop configuration, minimize TPRo to show desktop, etc.?

Thanks in advance for any ideas.

[Mangus]

Here's what my Mode 3 stuff looks like for $6E. It requests 3 items (RPM, LV8, and TPS):

Request command:

0x80 0x5C 0x03 0x00 0x59 0x00 0x64 0x00 0x82
(Checksum enabled, 2's compliment, which is 0xE2)

Response:

Payload offset = 3
Body size = 7
Payload size = 3
(Process data enabled)

Macro:

Set up a macro to pair the request and response (as is normal).


I then set up a separate set of values (3 of them), a separate item list, and a separate dashboard for displaying this data.

I don't recall how fast this goes, but I'll check on the bench again tonight. I know it's faster than 15 hz (the entire mode 1 ALDL packet is 10-11 hz).

[toliphint]

I don't recall how fast this goes, but I'll check on the bench again tonight. I know it's faster than 15 hz (the entire mode 1 ALDL packet is 10-11 hz).

Thank you!!! Look foraward to the bench results. I'm doing exactly what you are doing except in $8D, no dashboard, an Item List View with 3 varbs and 3 bit masks from one of the variables -- so essentially the same thing.

So there must be something wrong at my end because my Mode 1 rate is 100 samples per 3.6 seconds = 7.4 samples per sec. So Mode 3 with only 3 bytes should be much faster, but it's only 2x faster at 15.6 samples/sec.

Interestingly, when I was setting up my Mode 3 request, RoberISaar asked if I had used 7 Body Size bytes instead of 6. Also, I noticed that you used 7 Body bytes. So I made 2 identical ADX files: one with 6 and one with 7 Body bytes, 3 offset, 3 payload. Ran 2 tests with each. Here are my results:
6 bytes
--15.6 samples/sec
-- TPro reporting 14.9-16.3Hz to the left of the DA connectd window
7 bytes
--10.4 samples/sec (a 34% drop!!!)
-- TPro reporting 11.5-13.4Hz

Nothing else changed but the ADX file and all tests were done within 5 minutes to grab 200-300 samples.

This is why I'm intereseted in what in my environment can be changed to improve throughput. Could using AutpProm be causing my slow rates? Just asking before I go change everything to test.

[Mangus]

Is your FTDI driver latency set to a minimal value (it defaults to 16. I set it to 1, but if you have problems with 1, you can increment it until the problems go away).

Also, are you using the AutoProm as a passthrough device (i.e. a simple ALDL cable), or are you using in active mode, where you can emulate and log at the same time? If the latter, try the former. Active mode will definitely add quite a bit of overhead. In passthrough mode, the AutoProm is just a simple ALDL cable.

[toliphint]

Is your FTDI driver latency set to a minimal value (it defaults to 16. I set it to 1, but if you have problems with 1, you can increment it until the problems go away).

Also, are you using the AutoProm as a passthrough device (i.e. a simple ALDL cable), or are you using in active mode, where you can emulate and log at the same time? If the latter, try the former. Active mode will definitely add quite a bit of overhead. In passthrough mode, the AutoProm is just a simple ALDL cable.

Thanks for the heads-up on the latency and pass-through. Latency was set to 16 as I had not corrected it to 1 after a driver updata some time ago, and pass-through was not being used. So made those changes and again ran the log tests. In summary, I'm still a long way from achieving a desired 160+ Hz for debugging 6.25ms bit flips. Here are the results for Mode 3 requests previously documented:

Latency = 16, No pass-through
Body size = 6 bytes: 15.6 samples/sec
Body size = 7 bytes: 10.4 samples/sec (7 bytes 34% slower than 6 bytes)

Latency = 1, No pass-through
Body size = 6 bytes: 16.6 samples/sec (6 bytes latency = 1 is 6% faster than 6 bytes latency = 16)
Body size = 7 bytes: 12.2 samples/sec (At latency = 1, 7 bytes is 27% slower than 6 bytes)
-------------------------------------------(7 bytes latency = 1 is 17% faster than 7 bytes latency = 16)

Latency = 1, With pass-through
Body size = 6 bytes: 32.3 samples/sec (Pass-through 95% faster than No pass-through)
Body size = 7 bytes: 32.5 samples/sec (Essentially no difference between 6 and 7 bytes)

Any other ideas of how I can boost sample rate? What did your Mode 3 bench tests show? Surely my laptop is new enough and fast enough to achieve faster rates than above (see Feb 03 9:13 am post above). All thoughts appreciated and thanks for your help!!!

[Mangus]

Oops, I forgot to test this last night.

However, let's do some math.

8192 baud is ~910 bytes per second (9 bits per byte, including stop). Not including frame overhead.

160hz is 6.25 ms per frame/sample. At 910 Bps, you can, at best, transmit 5.46 bytes in 6.25 ms. There are 9 bytes in the command, 7 in the response, for a total of 16 bytes being transmitted on the line. 16 is a long way over 5.46 bytes.

At best, you'll get ~56 hz at the rates we're talking about.

[toliphint]

Oops, I forgot to test this last night.

At best, you'll get ~56 hz at the rates we're talking about.

And my opps as well -- I clearly slipped a few decimal places in my back of the envelope calculation of potential throughput. Thanks for the clarification. At least I'm now faster than before!

But would appreciate one clarification as am confused on something between Mode 1 and 3:

Mode 1 as set up in $8D ADX header and works perfectly (per downloaded $8D ADS from tunerpro.net):
Payload Offset = 3 (Assume this is (1=Msg ID [0xF4], 1=Msg Length, 1=Mode # -- Is that correct?)
Payload Size = 63 (63 data bytes in the $8D DDS)
Body Size = 66 = Payload Offset + Size

Yet Mode 3 seems to be different:
Payload Offset = 3 (Assume this is same 3 bytes as Mode 1 -- Is that correct?)
Payload Size = 3 (3 data bytes, or is it 6 assuming MSB and LSB for each address requested)
Body Size = 7 != Payload Offset of 3 + Size of 3 or 6

So some questions:
If Mode 3 payload offset and size are both 3, why does size = 7 -- what's the extra byte?
Or maybe Mode 1 should be 67 to allow for the checksum byte and that would explain Mode 3 at 7??? But Mode 1 works at 66 bytes, and unless in AutoProm pass-through mode, Mode 3 is considerably slower at 7 bytes than 6.
Is Mode 3 returning single bytes or MSB/LSB?

Also, still interested in your though-put once you have test time.
Thanks again for answers to the above!

[Mangus]

Technically, the 8D ADX/ADS should have a body size of 67. 66 means the checksum isn't being read (which is fine, because the FIFO on the PC-side is flushed before each command is sent to the ECM). The byte is still transmitted, though, so reducing the body size won't affect data rate.

So, the 7th byte for Mode 3 is the checksum.

The difference in perf between 6 and 7 bytes is probably due to the additional process overhead in the AutoProm (in active mode), and the latency in the FTDI driver when not set to 1 (as you saw, setting it to 1 nearly eliminates the difference).

[toliphint]

Technically, the 8D ADX/ADS should have a body size of 67. 66 means the checksum isn't being read (which is fine, because the FIFO on the PC-side is flushed before each command is sent to the ECM). The byte is still transmitted, though, so reducing the body size won't affect data rate.

So, the 7th byte for Mode 3 is the checksum.

The difference in perf between 6 and 7 bytes is probably due to the additional process overhead in the AutoProm (in active mode), and the latency in the FTDI driver when not set to 1 (as you saw, setting it to 1 nearly eliminates the difference).

Got it.
Thanks for the replies and assistance. Very much appreciated!

[Mangus]

Have you considered modifying the ALDL code to output only the flag (or flags) to the port without the need for a command, and without the additional data overhead? That might get you where you need to go.

[toliphint]

Have you considered modifying the ALDL code to output only the flag (or flags) to the port without the need for a command, and without the additional data overhead? That might get you where you need to go.

Must admint I don't know how to do that. If you're talking modifying source and recompiling, not sure I'm ready for that. Otherwise, if you can point me somwhere, I don't mind fishing.