TPro Data Stream Sample Rate

[toliphint]

TPro-RT latest version - Is there a way to maximize the number of received data samples per second? Am trying to monitor the status of some bits that get flipped every 6.25 - 12.5ms. ($8d AUJP).

[robertisaar]

that is 80-160Hz.... you won't get anywhere near that with a full-sized datastream.

you'll need to setup some mode 2 or 3 commands(i can never remember which) and only be able to request 1 or 2 bytes, that MIGHT get you to 80Hz.

[robertisaar]

or, should you want to modify the calibration, you could (temporarily) cut down the mode 1 reply down to those 1 or 2 bytes and not suffer some of the overhead of the mode 2/3 requests.

[toliphint]

or, should you want to modify the calibration, you could (temporarily) cut down the mode 1 reply down to those 1 or 2 bytes and not suffer some of the overhead of the mode 2/3 requests.

Thanks Robert -- Understand. Seems to be Mode 3 to get up to 6 bytes of data. Have read the TPro help file and every post here involving "command" and am still unclear on a few things:

• - Is it the string in the Monitor Command window of the ADX header (mine = "Mode 1 ALDL Dump Request Macro") that causes the Mode 1 data to be repeatedly transmitted by the ECM?
  - I'm assuming that data can be transmitted by the ECM no faster than the frequency at which data is requested by TPro. Do you (or anyone) know that frequency? (using '7730 = 8192 baud) No point in my proceeding if not at least 80Hz.
  - If a Mode 3 send/reply macro is created and the ADX Monitor Command is changed to point to the Mode 3 Macro, does that stop all Mode 1 send/reply activity and implement only the Mode 3 request?
  - Would a truncated Mode 1 request with only 2 byte Values be faster or slower than using Mode 3 requesting 2 bytes?

Lot of detail, but really trying to understand how I can automatically and most quickly get the data I need in a log for some debugging.

Thanks

[robertisaar]

i've run mode 3 before with a couple of items to see how it worked, i seem to remember somewhere in the 30-40Hz range, but i don't remember how many bytes i was requesting. i'm fairly certain the limit is 8 bytes, but i've never tested the limit.

yes, the entry selected for "monitor command" is what will be sent over and over until the disconnect command is triggered.

there might be some slight overhead in tunerpro sending messages back out after one gets in, but i have no way of measuring it. Mark may have a better estimate/answer.

yes, if a mode 3 macro is selected for the monitor command, you will receive only mode 3 packets. you could setup a macro to mix both mode 3 and mode 1 packets if desired, but you'll take a hit to the logging rate.

mode 1 with the datastream modified to allow only the two bytes would likely be faster since there is less overhead.

an example send/respond in mode 1:

send:

F4
57
01
00
CS

receive:
F4
58
01
??(first value)
??(second value)
CS

so, 5 bytes sent, 6 bytes received. if the ALDL code were modified, the mode 1, message 0 could probably be trimmed down to being just a mode 1 byte like how it is in earlier code before multiple streams were common. but let's not get too far ahead yet.

mode 3:

send:

F4
5A
03
?? (16-bit address of byte 1)
??
?? (16 biit address of byte 2)
??
CS

receive:

F4
58
03
??(value 1)
??(value 2)
CS

so, with mode 3, 8 sent and 6 received.

this isn't accounting for start/stop bits, but 11 vs 14 bytes, so a 27.2% reduction in number of number of bytes sent/received, it could make enough of a difference to get you into the speed range you want. to extend further on this, the more bytes you request, the better mode 1 looks as well. 3 bytes would be 12 vs 17(41.7%) and keeps getting better up to the 6 or 8 value limit for mode 3.



what exactly are you looking to monitor? async fueling?

[toliphint]

Thanks!!! Yea, after posting, realized I had a brain cramp and decided to do the calcs you provided and realized Mode 1 would be faster than 3 as you indicated. So will create a bare-bones ADX file with just the values needed.

Because you asked, what I'm trying to do is understand how TPS AE and MAP AE work in AUJP $8d. I've been tracing the code and now have a good idea of everything which I'm in the process of documenting. But there's one thing I can't figure out at the exit of the 6.25ms IAC PID. It's a bit detailed. Looking at the code, it appears that some variables have to always = 0 at PID exit, yet in the high-level logs I've done they are not. The code at PID exit is below.

Code: Select all

              brclr   *L0037,#0x80,LE8EA
              inc     L01A4
              bne     LE8EA 
              dec     L01A4
LE8EA:        brclr  *L0045,#0x40,LE8F6
                                          
              ldab    *L00A4
              incb
              cmpb    L852F
              bcs     LE8FF        ; Was $FF before ++, Now=0
                                   ; else [NOT $FF before ++, Now=1 to FF]
LE8F6:        bclr    *L0045,#0x40 
              clrb
              stab    *L00A2       ; Table Index value 0-7
              clra
              std     *L00F8
LE8FF:        stab    *L00A4
;----------------------------------------------
[The only branch here is if Engine NOT Running]
;----------------------------------------------
LE901:        rts                  ; RETURN TO 6.25ms ISR. PID Done

And here's the declaration of L852F
(verified in my Bin as 0x01 which is important):
L852F:        .byte   0x01

Because L00A4 is only used in the PID code shown above (verified a million times), it always has to be = 0 at PID exit and re-entry. And logs verify it is always = 0. Therefore, the 'cmpb L852F' instruction that tests it after being incremented will always yield (L00A4=0+1=1) - (L852F=1) = 0 and the Carry bit is not set. That means all variables at LE8F6 and following will = 0 because a branch to LE8FF cannot occur in the 'bcs LE8FF' instruction. But what logs show is that L00A2 has values 0-7 indicating that it must be exiting the PID without equalling 0. Just don't know how!

L00A2 is always and only incremented in the Asynch Fuel Out routine. If I have the code execution order correct, L00A2 will enter the PID equalling 1 after having been incremented in Asynch Fuel Out, but will exit the PID equalling 0. Here's the execution order as I understand it:

• 6.25ms Interrupt Service Routine (ISR)
  ISR calls 6.25ms IAC PID (L00A4 = 0 at exit ALWAYS)
  Return to 6.25ms ISR
  Execute Spark or Fuel Minor Loops
  Spark or Fuel calls Asynch Fuel Out routine (++L00A2)
  Return to Spark or Fuel
  
  Repeat the order next 6.25ms
  6.25ms Interrupt Service Routine (ISR)
  ISR calls 6.25ms IAC PID
  (L00A4 = 0 at entry, ++'d to 1, tested (1 - 1 = 0 [Carry NOT set]), at exit = 0)
  (L00A2 = 1 at entry, 0 at exit)

Bottom line, I'm trying to have a log show L00A2 and L0045 values as rapidly as possible in hope I can figure out how L00A2 is ever anything other than 0 or 1. Maybe I have the execution order wrong and that's my problem, but really want to figure it out. Right now, it's almost as if the code is somehow re-entrant and is not being executed in sequence.

Certainly TMI, but many thanks if you can see something I'm overlooking.

[toliphint]

AFTERTHOUGHT --- Could it be that Mode 1 is not the best choice after all. Seems if Mode 1 is requested, the ECM will always transmit 63 bytes. Then TPro will log only those specified in the ADX. If so that would make Mode 3 the choice for fastest ECM xmit.

Thoughts?

[robertisaar]

you're further into 8D than i've ever needed to dig. i didn't know IAC logic was somehow involved with the AE calcs.

mode 1 can be setup to allow to transmit only two bytes, but you'll need to change a value in the calibration from 63 to 2. i'm not that familiar with 8D to know off-hand, but i'm sure it is near the datastream.

[Mangus]

Mode 3 is the way to go. I use it for 6E on occasion, when I only need to monitor a few items at higher speed.