GeneralDisorder

iTrader: (1)

LB9 running $6E.

So I'm logging my cold startup trying to determine a direction for intermittent long crank.

I don't see any RPM data in my log till it shoots up to about 600 RPM and starts firing. Is that an indication that the ECM isn't seeing the pulses or? My experience with other (admittedly more modern) injection systems is that you can see the RPM data when cranking (usually around 300 RPM).

I'll post a short log if anyone is interested.

I'm wondering if I have an ignition module on it's way out. I can't find any other reason for intermittent long cold cranking. Sometimes it will sit for 6-8 hours and have a long 4-5 second crank, other times it has sat for a couple days and fired immediately. So I'm leaning towards it not being tune related.

The fuel system is completely new (tank to injectors all inclusive) and I just adjusted the fuel pressure to 43.5 psi. It doesn't bleed down, and I have prime every time I turn the key.

GD

GeneralDisorder

iTrader: (1)

Anyone know if I should be seeing RPM in the datalog while cranking?

GD

RBob

iTrader: (1)

If using the 160 baud logging, no, RPM will not be calculated by the ECM until the engine is running.

If using the 8192 baud logging, one can use the time between DRPs to calculate the RPM at any time.

RBob.

GeneralDisorder

iTrader: (1)

I am using the 8192. I'll take a look at the DRP data. Great idea!

GD

GeneralDisorder

iTrader: (1)

What units is the time between DRP being output in? In the ADX the units display is entered as microseconds? This doesn't seem right. Wouldn't it be in whatever units of frequency the ECM processor is running at?

I've been looking but not finding much info on this.

GD

GeneralDisorder

iTrader: (1)

Ok I got it figured out. If anyone is looking to calculate RPM prior to the ECM reporting it directly in the data stream just create an item in the ADX (for $6E - maybe others IDK) that's exactly the same as the "Time Between Reference Pulses" but change the Equation under the Coversion tab to:

983040 ÷ X

This will give you an item that directly corresponds to RPM but is available prior to actual RPM data output. That way you can correlate injector pulse width to cranking RPM, etc. Or track cranking RPM for any other reason. Personally I'm used to being able to see this in more modern live data. Makes it easy to see if the ECM can "see" the engine is turning.

GD

RBob

iTrader: (1)

Don't forget that you need to grab two bytes of the ALDL stream for the calculation. The lowest RPM that can be displayed is 15 RPM, so that will be shown with a non-running engine.

Since the $6E code doesn't do 2 byte grabs for the ALDL stream, the RPM shown can glitch from time to time. As an example the $8D ALDL code does do two byte grabs so that the value stays synced up.

RBob.

GeneralDisorder

iTrader: (1)

So in $6E, the LSB is not available?

Is it a matter of changing the acquisition (ADX) to grab the LSB, or would it require rewriting the code using the $8D ALDL code and then also the ADX to match.

It seemed to work pretty well for my log. The first DRP delta gave me 106 RPM.

GD

RBob

iTrader: (1)

Both bytes are in the data stream. It is just in $6E the firmware grabs the MSB and sends it. Once that byte has been transmitted it grabs the LSB and sends it.

The issue being that the ECM could have rewritten the 2-byte value in between the ALDL stream grabs. So a nonsense RPM can occur.

In $8D, there is a flag used for those two bytes (and all other 2-byte values) that causes the ALDL firmware section to grab both bytes at the same time. It sends the MSB while tucking away the LSB until it needs to be sent. So both the MSB and LSB are from the same grab and are sync'd.

RBob.

GeneralDisorder

iTrader: (1)

Ah yes I see now what you are getting at. Fortunately the LSB is only going to throw off the number by a max of 256 - which at cranking RPM is not super critical because of the relatively large DRP delta. So at 650 RPM you have an error of about +/- 100 RPM and the lower the RPM goes the more the error is reduced.....

Not ideal for sure, but useful for logging cold start pulse width....

It would be nice if there was a reference pulse counter. Since the Crank PW Multiplier table is based on the reference pulse count.

GD

RBob

iTrader: (1)

Exactly, as long as you understand the nuances and aren't surprised by the odd readings, it works.

Makes sense that there has to be one.

RBob.

GeneralDisorder

iTrader: (1)

I've been going through the $6E hac and familiarizing myself with 6811 assembly (I've only ever done x86, but did quite a lot in the past). Still learning but assuming I can find the variable for the counter - how feasible would it be to add this to the ALDL data stream or replace something less useful with it?

Would it be possible to add more information or is there hardware limitations on packet size, etc? I'm not too familiar with I/O in this configuration. Might be a good way to learn more about the code.

Thanks for the info RBob. You're the best!

GD

RBob

iTrader: (1)

It is easy to change what is sent via the ALDL link. Look at the L0121 RAM variable.

RBob.