Reference Pulses, Time Between Reference Pulses, etc.

[1project2many]

What appears to happen is the ECM reads the Distributor Pulses, converts them to ECM Pulses with a base frequency of 65536Hz and then outputs the equivalent ECM Reference Periods into variable L00B3.

The commenter of the ANHT hac (and others) often used his own shorthand and would mix references, likely due to familiarity with the material and systems. DRP Period is a correct term as it refers to the elapsed time, or period, between distributor reference pulses.

The ecm queries for the time between reference pulses as measured by the 65 kHz timer value then compares the result with the time value stored at $801A. The commenter did the conversion between time and RPM and listed the RPM in the comments. But that value onlyt represents 300 rpm for engines with eight cylinders.

Elsewhere in the code that same time variable is queried and the result is multiplied against the number of cylinders, or knumcyl. The result, now corrected for cylinder count, is saved as RPM. Engines with less than eight cylinders are corrected to eight cylinder values. The attached chart might serve as a handy lookup.

[84Elky]

The attached chart might serve as a handy lookup.

Exactly & Thanks! Where has this chart been all my life? The column labeled “cntr” (3^rd from right after adjusting the headings) is precisely the decimal value of what the code is getting from the ECM after the ECM receives DRPs at a given RPM. It’s the “# of ECM-generated Reference Periods at X RPM.

But believe the last column labeled “cntr * knumcyl” should be labeled (cntr * knumcyls) / 8, with no adjustment to “cntr” being required for 8 cyls.

Thanks again, and just curious about the origin of the chart and if there is other similar ECM related info available because have not seen this before?

[1project2many]

Exactly & Thanks! Where has this chart been all my life?

I made it back in 2000 when I was working through $58. I wrote a program to do the math in hex, with appropriate rounding, so I could see it happen step by step. I've posted it to a few sites over the years but the people that appreciate it are few and far between.

Why are you inserting "ECM generated reference periods" into the process? That phrase indicates the ecm is responsible for creating the value, which it is not. The ecm simply measures time between two events. No event, no measurement. Are you referring to the source of the value?

LDX L3FC0 ; LAST DRP PERIOD
STX L00B3 ; CURRENT MNR LOOP DRP PERIOD

I suppose this might be thought of as "Ecm generated" since the value is obtained from onboard hardware but it's the only "reference period" other than when "current" is moved to "old."

LDD L00B3 ; CURRENT MNR LOOP DRP PERIOD
STD L00B5 ; OLD REF PER

But believe the last column labeled “cntr * knumcyl” should be labeled (cntr * knumcyls) / 8, with no adjustment to “cntr” being required for 8 cyls.

The last column is the result of multiplication done by the ecm with the number of cylinders variable. There is no division. It's done with rounding. The time between DRP's is queried, knumcyl is loaded, and the two variables are sent to the standard 8X16 multiply subroutine.

CFAD            ldd     REFINT	
CFB0            std     rpmref	; L0037.  This will become 90deg ref * # of cylinders. 
CFB2            ldx     #0x0037	; places addy of rpmref in X
CFB5            ldaa    NUMCYL	; sets up for 8X16mult
CFB8            beq     LCFBF	; for 8cyl, goto LCFBF
CFBA            jsr     8X16mult	; generic multiply for 8X16 bit #'s: returns 16 bit 
					; value in D = 90 deg counter * NUMCYL
					;
CFBD            std     rpmref	; now we have a number = ref corrected for knumcyl

The logical tests are reversed in $8D (BNE vs BEQ) but the steps are the same. What's in the column is exactly what's generated by the 8X16 multiply subroutine for the listed counter and knumcyl values. If you're looking at this section:

LDD L00B3 ; CURRENT MNR LOOP DRP PERIOD
LSRD ; DIV BY 8
LSRD
LSRD

Its for dwell calculation.

What other info are you looking for?

Edit: The file I attached to the previous post was the raw data I obtained from the program. That's not what I intended to attach. This is formatted a little better.

[84Elky]

Thanks for the reformatted file.

Why are you inserting "ECM generated reference periods" into the process?

I’ve been tracing through the AUJP $8D code trying to understand why some things work they way they do, rather than just blindly accepting them. In the process, the comments in the hack have been very helpful. In fact it would be impossible for me to trace without the comments. Many, many kudos to those who had the ability to interpret the raw code and add them. But in some cases, I’ve found things to be a bit confusing.

This might be viewed to be somewhat anal, but it’s important for my understanding. For example, take the labelling of the variables below. To me, it’s confusing if not incorrect. If these were truly Distributor Reference Periods, then at 300 RPM, the value would be 1200d. But it’s not; we know it to be 3277d.

LDX L3FC0 ; LAST DRP PERIOD
STX L00B3 ; CURRENT MNR LOOP DRP PERIOD

So that says that somehow, Distribitor Reference Periods are being changed to something else for use by the code. Otherwise 1200d would be used. And since the ECM is reporting the value of 3277d at 300 RPM, I just chose to call the value “# of ECM-generated Reference Periods" (could be “# of 65536Hz Reference Periods from the ECM, computed from Distributor Reference Periods”), and will change my work-in-process commented code file accordingly (updated periodically and found here in Post #8 as JP_AUJP-ASM.zip:http://www.gearhead-efi.com/Fuel-Inj...Information-8D ). That way when I go back to the code at a later time, I won’t be confused as to what the variables really are. That’s all, nothing more.

Regarding the last column of data. Understand that it’s done (in hex) with rounding and an 8x16 multiply subroutine; but using decimal values the last column value is:
(cntr * # cylinders) / 8

Take the 6 cylinder, 2500 RPM values as an example:

               pulses    pulses      secs/    cntr  hxcntr       cntr*
# Cyl    RPM   /min      /sec        pulse                       knumcyl
6        2500  7500      125         0.008    524   020C         0189

Doing the decimal math:
(524 * 6) / 8 = 393d = 0x189 (the table value)

Ditto for any value.

[1project2many]

This might be viewed to be somewhat anal, but it’s important for my understanding. For example, take the labelling of the variables below. To me, it’s confusing if not incorrect. If these were truly Distributor Reference Periods, then at 300 RPM, the value would be 1200d. But it’s not; we know it to be 3277d.

Ahhh. Understood. DRP could mean Distributor Reference Period.

But at 300 rpm how would you obtain a value of 1200d for a distributor reference period? One revolution of the distributor takes 1/150 second.

Regarding the last column of data. Understand that it’s done (in hex) with rounding and an 8x16 multiply subroutine; but using decimal values the last column value is:
(cntr * # cylinders) / 8

The title was derived from the source of the data, not the values themselves. The last two columns contain hex values to be used for quick reference for people not used to hex <> decimal conversions.

[84Elky]

Was thinking about this again when you replied and was about to make a correction, so will do it here. I made an error in both the value 1200 and what the variables represent. What’s really happening is a conversion of Distributor Reference Pulses (DRPs) at a given RPM to equivalent ECM clock ticks. Consider this:

4 DRPs        300 rev       1200 DRPs           1 min       20 DRPs
--------  x  ---------- = -------------- x -------------- = ----------
1 rev           min            min              60 sec        sec

Now, with 20 DRPs per second at 300 RPM, what’s the equivalent ECM pulse rate (in ECM clock ticks) at 300 RPM? It’s simply:

   65536 ECM Clock Ticks         1 sec                3277 ECM Clock Ticks
--------------------------  x  -------------    =  --------------------------
           sec                   20 DRPs              per DRP at 300 RPM

Perhaps that’s why it’s referred to in some of the comments as a “counter”.

I should have approached it this way to begin with using the above simple formula and it would have been much less complicated. And proving the formula:

1 sec         0.05 sec        1000000 uS
-------  =  ----------- x ------------------ = 50000uS per DRP at 300 RPM
20 DRPs        DRP               sec

 
3277 ECM Clock Ticks           15.26 uS
---------------------- x ------------------- = 50000uS per DRP at 300 RPM
per DRP at 300 RPM         ECM Clock Tick

Wish it weren’t so that it takes me so long to get somewhere. At times it takes a while for the synapses to fire..

[1project2many]

ANHT is essentially someone's personal notebook. Not all of the notes are meaningful and some are not 100% correct. I haven't looked at AUJP lately but I think that contains some of the same comments and possibly some of the same errors.

Feel free to challenge what's presented. Several months ago there was a long thread that started as a question about EGR operation, moved through the discovery that the temperature conversion we'd been taking for granted was not correct for all ecm's, and ended with development of a polynomial representation of a thermistor lookup table for use in some ADX files. Wouldn't have happened without someone asking questions.