I was curious if TunerPro had a more accurate method of displaying elapsed time besides the "Engine Running Time" field in the datalog outputs. I think it would be really useful to have a finer scale to gauge performance gains (0-60 during drag racing, etc.). Craig Moates' DOS-based software counted the seconds to several decimal places, but the best I can do with TunerPro is interpolate between the whole seconds it logs. Is there any way around this?

 

The program counter would probably be the easiest thing to use. It will resolve down to 6.25 msecs (each 160 counts = 1 second). I dont know offhand what addr. it is in the RAM. The elapsed engine run time and program counter are in sync, so you can use them together to see how much time has passed.

 

Could you elaborate a little more, dimented24x7? Would I have to use some sort of external program to read TunerPro's internal counter in realtime, and then manually relate it to my logs? It would be nice if there was a way to integrate the counter directly into the data acquisition.

 

The program counter is in the ECM itself. Basically you go into the ALDL addr. table table in the prom and replace something you dont need with the program counter's address and itll be transmitted, and datalogged.

 

Another method is to count packets. Each time the second portion of the engine running time changes keep a count of packets. At 10 packets per second each one is a tenth of a second.

RBob.

 

RBob, would the packet count be the same as the "Sample #" shown in TunerPro's logs? If that's the case, I could fairly easily determine how far into a second I am... that is, if the engine running time was logged consistently. Sometimes I see a value listed for 10 samples, sometimes 8, other times it's 4 or 5.

I looked through the $6E hack and the info on page 287 seems like it might allow me to feed a different signal through the line. I don't care much about the EPROM ID, for example, since it's not going to change during a log. On p. 287, the EPROM ID identifier (?) appears to be $C000 defined at FD5C (0x3D5C). In 8192 baud mode (page 74), the EPROM ID signal looks like it's located at LC66F (0x066F). Would I simply change the value at 0x066F to the one for the ECM program counter?

Again on page 287 of the hack, there are a numerous timers indicated. These are:

$3FC0 - Ref Period Timer
$3FC2 - Timer #1 (Input 5)
$3FC4 - Timer #2 (Input 6)
$3FC6 - Counter #1 (*** Pulses)
$3FC8 - Counter #2 SPK PERIOD, (SPK Feed Bk, in 3)
$3FCA - Counter #3 (16.5 Khz cntr if In 4 is hi)
$3FE0 - Counter #4 (*** pulses on in 5)
$3FF8 - Timer #1A (B Cnt'r Last H.U Pulse)

Any idea on which one of these I should use? If I had to take a guess, I'd say the reference period timer...

 

Those are all program code timers that probably have different rates due to the loop they are executing in. You would be best off finding the hardware counter directly and grabbing the numbers from there. I see the program counter in $8D to be at $4005 but it indicates it is a single byte 8 bit counter. that kind of bugged me that it may recycle to zero after 255.

 

The *problem* is in the resolution of the VSS. You can have a 3' error before the car trips the VSS the first time. That first 3' can be *really* slow and throw things way off. Now, if you wanted to use an ABS ring with it's 52 pulses per revolution, that would be another matter.

 

Mark is aware of this need and is planning to add a data field 'elapsed time' into the ADS format. That will let you use the PC-side timer to determine when a particular data packet is received. If you're looking for a solution right now, then no, that doesn't help too much. But figured I'd mention it.

 

Grumpy, the low accuracy of the VSS didn't even come to mind. Using a tone ring would be a much better way of doing things... maybe I can rig one up on one of the front hubs like some guys have proposed for ABS swaps. That would probably be easier (for me) than swapping differentials, but even then, it might not be worth the time or expense. A G-tech or real dyno would probably be more helpful and accurate.

I'm glad to see that Mark is going to add a timer with higher resolution, Craig. That's the one thing about TP that's bugged me. Your ECM852 software worked great but it became a hassle to have to reboot if I needed to make changes to the EPROM (had to use a boot disk since the laptop was running Windows 2000).

I'll still look through the hack again and try to find the proper counter, if just for informational purposes. JP86SS, I wonder if there's any correlation to the $8D location versus $6E. Hmm.

 

There may be hardware registers that are common.
I/O counts and component differences are there but controls seem to be the same.
Can't see them totally reinventing the wheel with every ECM during the P4 generation.

 

The PC along with the engine run time is like a stop watch. When the PC rolls over (after 160 counts), engine run time will increment by one second since the PC is what serves as its time reference. 160 counts = one second for the counter. Not the most convinient thing since you have to look at both to determine elapsed time, but accurate and better then nothing while a solution on the datalogger side comes along.

 

Those are all hardware counters. The PC is stored in the ram and incremented each time the code runs through a loop. One would have to look at the code carefully to determine where it is.

NVM. Found it by typing in '#160' and searching. It resides at $0000 in the ram in the $6E.

 

Come to think of it, it was bad wording on my part to use program counter as it also referes to the CPU's built-in counter as well. Looking at the ARAP stuff, the original hac refers to the counter as a 'minor loop counter', which is probably more correct given how the code is structured.

 

Nice. I know very little about assembly, but I'm trying to see what's going on with that portion of the $6E code.

So it sets the register at $0000 to store the output of the counter, increments the counter, compares it to the maximum allowed value of 160, and repeats the process until the limit is reached? The code appears to move to the routine at $CB33 between counts to save the value in memory at $0000. Does that sound right?

Also, what determines that 160 counts equals one second of real time? Are we talking clock cycles of the processor?

 

The value in RAM location L0000 cycles from 0 through 159. When it reaches the value of 160 the ECM runs the 1 second logic and resets the counter to 0. Part of the 1 second logic increments the engine running counter (if running).

There is a hardware interrupt that runs at 160 Hz. This is every 6.25 msec. Which is then used to run the real time logic of the ECM. Fueling minor loop every 12.5 msec with the spark minor loop every 12.5 msec. On alternating interrupts. Then 1 of 16 major loops after each of the minor loops in a round robin fashion. So they are called every 100 msec.

When the minor loop code and the major loop has completed, the code goes into a spin cycle (sometimes used for RAM refresh) until the next interrupt.

Then there are loops that run on sub's of the 12.5 msec and 100 msec loops. Such as ones that run every 25 msec, or 200 msec.

Back to the issue at hand. Place the address of 0 in the ALDL stream. Using that value and the engine run time counter fairly accurate timing can be had. There are other issues involved, such as latency in the data packet. But all in all, it can be used for general timing purposes.

RBob.