code review
Thread Starter
Member
Joined: Jun 2001
Posts: 391
Likes: 0
From: Eh?
Car: 1988 Monte Carlo SS
Engine: 5.7L TPI
Transmission: T5
Axle/Gears: 3.73
code review
I came up with the idea to use some of the free ram in my ecm (730 w/4kb nvsram module) to store the accumulated distance and fuel used counters. I'm hoping someone that can read hc11 would be willing to check over some code that I wrote.
I'm hoping I can insert this into one of the minor loops. Anyone know which one has the most amount of time idle? I need to initialize 0x2C00-0x2C02 on boot up (code not shown).
If the above works, I'm thinking of making a 2nd set of same counters to create a trip odometer that would be reset via aldl.
The goal here is to store accurate long term mpg info in the ecm.
Code:
nvsram memory locations to be used: 0x2C00 old accumulated distance counter 0x2C01 old IP fuel MSB (0x3130) 0x2C02 old IP fuel LSB (0x3131) 0x2C03 PPM counter byte MSB - 32 bits 0x2C04 PPM counter byte 0x2C05 PPM counter byte 0x2C06 PPM counter byte LSB 0x2C07 IPFUEL counter byte MSB - 64 bits 0x2C08 IPFUEL counter byte 0x2C09 IPFUEL counter byte 0x2C0A IPFUEL counter byte 0x2C0B IPFUEL counter byte 0x2C0C IPFUEL counter byte 0x2C0D IPFUEL counter byte 0x2C0E IPFUEL counter byte LSB # update pulse per mile counter PPMC: ldaa 0x0134 ;current accumulated distance counter (8 bits) cmp 0x2C00 ;old accumulated distance counter beq IPFUEL ;no change - jump to injector msec counter update psha ;store a copy of current accumulated distance counter blo PPMROLLED ;branch if new value is lower then old (the 8bit counter rolled over) suba 0x2C00 ;calculate delta PPM bra PPMUPDATE ;branch always - update total distance counter PPMROLLED: tab ;copy A -> B comb ;1's compliment aba ;255 - old counter + new value PPMUPDATE: adda 0x2C06 ;add contents of 0x2C06 to A staa 0x2C06 ;save new value pula ;fetch current accumulated distance counter staa 0x2C00 ;save as old accumulated distance counter bcc PPMDONE ;if no carry over, jump to IP FUEL update ldaa #0 ;load 0 in A adca 0x2C05 ;add 0x2C05 to carry bit staa 0x2C05 ;save new value bcc PPMDONE ;if no carry over, jump to IP FUEL update ldaa #0 ;load 0 in A adca 0x2C04 ;add 0x2C04 to carry bit staa 0x2C04 ;save new value bcc PPMDONE ;if no carry over, jump to IP FUEL update ldaa #0 ;load 0 in A adca 0x2C03 ;add 0x2C03 to carry bit staa 0x2C03 PPMDONE: # update IP fuel counter IPFUEL: ladd 0x3130 ;16bit rolling accumulated fuel counter cmpd 0x2C01 ;compare to old value beq FINISHED ;no change - jump to end pshb ;store a copy of current IP FUEL counter (order is important for TSX instruction) psha ; blo IPFUELROLLED subd 0x2C01 ;calculate IP FUEL delta (current - old) bra IPFUELUPDATE IPFUELROLLED: ldd 0x2C01 ;load old IP FUEL value coma ;1's compliment of D accumulator comb tsx ;set X to last entry of stack pointer addd 0x00,x ;add 1's compliment of old value to new value IPFUELUPDATE: clc ;ensure carry is clear addd 0x2C0D ;add D to lower 16bits of total fuel counter pula pulb stad 0x2C01 ;save current IP FUEL counter as old ldy #6 ;6 bytes left... ldx 0x2C0C ;pointer to next significant byte IPFUELLOOP: bcc IPFUELDONE ;carry bit clear? bail loop if it is ldaa #0 ;load 0 into A adca 0x00,x ;add carry bit to byte staa 0x00,x ;save the new value dex ;move pointer to next byte dey ;decrement counter cpy #0x0 ;compare counter to 0 bne IPFUELLOOP ;if not 0, loop IPFUELDONE:
If the above works, I'm thinking of making a 2nd set of same counters to create a trip odometer that would be reset via aldl.
The goal here is to store accurate long term mpg info in the ecm.
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
I looked at the accum PPM portion of the code. I will save the look at the FUEL tomorrow night.
Before entering this piece of code. Reg_a = accum PPM/0x0134.
so it will be stuck at 255.
Is that the behaviour you wanted?
Before entering this piece of code. Reg_a = accum PPM/0x0134.
Code:
PPMROLLED:
tab ;copy A -> B (save accum PPM 0x0134 to reg_b)
comb ;1's compliment (reg_b = 255 - reg_b)
aba ;255 - old counter + new value (reg_a = reg_a + reg_b)
; (accum PPM + (255 - accum PPM)) = 255 Is that the behaviour you wanted?
Last edited by junkcltr; Jul 17, 2006 at 11:22 PM.
Thread Starter
Member
Joined: Jun 2001
Posts: 391
Likes: 0
From: Eh?
Car: 1988 Monte Carlo SS
Engine: 5.7L TPI
Transmission: T5
Axle/Gears: 3.73
Junkcltr, you are right - I goofed that one up. I changed the 'tab' instruction, new code below.
Code:
PPMC: ldaa 0x0134 ;current accumulated distance counter (8 bits) cmp 0x2C00 ;old accumulated distance counter beq IPFUEL ;no change - jump to injector msec counter update psha ;store a copy of current accumulated distance counter blo PPMROLLED ;branch if new value is lower then old (the 8bit counter rolled over) suba 0x2C00 ;calculate delta PPM bra PPMUPDATE ;branch always - update total distance counter PPMROLLED: ldab 0x2C00 ;load old accumulated distance counter comb ;get 1's compliment of old distance counter (255-old value) aba ;255 - old counter + new value PPMUPDATE: adda 0x2C06 ;add contents of 0x2C06 to A staa 0x2C06 ;save new value pula ;fetch current accumulated distance counter staa 0x2C00 ;save as old accumulated distance counter bcc PPMDONE ;if no carry over, jump to IP FUEL update ldaa #0 ;load 0 in A adca 0x2C05 ;add 0x2C05 to carry bit staa 0x2C05 ;save new value bcc PPMDONE ;if no carry over, jump to IP FUEL update ldaa #0 ;load 0 in A adca 0x2C04 ;add 0x2C04 to carry bit staa 0x2C04 ;save new value bcc PPMDONE ;if no carry over, jump to IP FUEL update ldaa #0 ;load 0 in A adca 0x2C03 ;add 0x2C03 to carry bit staa 0x2C03 PPMDONE:
Thread Starter
Member
Joined: Jun 2001
Posts: 391
Likes: 0
From: Eh?
Car: 1988 Monte Carlo SS
Engine: 5.7L TPI
Transmission: T5
Axle/Gears: 3.73
Woohoo... my pulse per mile counter is working! Now off to find the bug in my fuel counter (which isn't incrementing).
edit: found the bug. Forgot a store D instruction after adding delta fuel to lower 16 bits of the fuel counter.
edit: found the bug. Forgot a store D instruction after adding delta fuel to lower 16 bits of the fuel counter.
Last edited by MonteCarSlow; Jul 18, 2006 at 10:50 PM.
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Well sort of. You still have one bug that you will never see. It happens on the roll-over. You need to do a "+1" when the counter rolls over. When the previous accum is 255 and the new accum is 0, then "255 - 255 + 0" = 0. When you should have had a +1 to add to the accum.
So you need a +1 after the
aba ;255 - old counter + new value
adda #0x01 ; you need this
Check the fuel accum for the same problem. You accum will be off by 1 every time the roll over occurs............you would never notice I bet....but theoretically it is incorrect.
Good to hear you have it working though.
Junk
So you need a +1 after the
aba ;255 - old counter + new value
adda #0x01 ; you need this
Check the fuel accum for the same problem. You accum will be off by 1 every time the roll over occurs............you would never notice I bet....but theoretically it is incorrect.
Good to hear you have it working though.
Junk
Thread Starter
Member
Joined: Jun 2001
Posts: 391
Likes: 0
From: Eh?
Car: 1988 Monte Carlo SS
Engine: 5.7L TPI
Transmission: T5
Axle/Gears: 3.73
Perhaps someone can show me what I've done wrong in the following code that seems to go errant on boot up whenever the lower byte (or word in the case of the IP fuel counter) is non-zero.
The idea with this code is to store a nonvolatile 32bit accumulated distance counter and a 64bit accumulated fuel counter. These counters are stored in my nvsram module. Under normal operation (ie. engine running and vehicle moving - everything works fine), but on an ecm reset boot up, if the lowest byte of the distance counter or the lowest word of the fuel counter is non-zero, the next byte gets incremented and the lowest byte or word is cleared to 0. I've fought with this for hours now trying to figure it out - I've given up.... I don't see what I've done wrong.
how the above are called:
the register IPTEMP is cleared to 0 just before the EPROM checksum occurs.
e.g. of the bug:
accumulated distance counter:
00 00 12 34 (before key-off)
00 00 13 00 (after ecm boot up)
accumulated fuel counter:
00 00 00 00 12 34 56 78 (before key-off)
00 00 00 00 12 35 00 00 (after ecm boot up)
If anyone has any ideas...
The idea with this code is to store a nonvolatile 32bit accumulated distance counter and a 64bit accumulated fuel counter. These counters are stored in my nvsram module. Under normal operation (ie. engine running and vehicle moving - everything works fine), but on an ecm reset boot up, if the lowest byte of the distance counter or the lowest word of the fuel counter is non-zero, the next byte gets incremented and the lowest byte or word is cleared to 0. I've fought with this for hours now trying to figure it out - I've given up.... I don't see what I've done wrong.
Code:
PPMBYTE4 = $2C00 PPMBYTE3 = $2C01 PPMBYTE2 = $2C02 PPMBYTE1 = $2C03 IPBYTE8 = $2C04 IPBYTE7 = $2C05 IPBYTE6 = $2C06 IPBYTE5 = $2C07 IPBYTE4 = $2C08 IPBYTE3 = $2C09 IPBYTE2 = $2C0A IPBYTE1 = $2C0B IPTEMP = $2C0C ;16 bits UPDATEPPM: ; enter with delta PPM in register B ; A and X registers are trashed pshb addb PPMBYTE1 ;add delta to LSB of PPM COUNTER stab PPMBYTE1 ;save it bcc PPMDONE ;if no carry over, then done ldx #PPMBYTE2 ;X points to next byte ldaa #$03 ;index to number of bytes left PPM1: inc $00,x ;increment byte bne PPMDONE ;if byte didn't become zero then there is no carry over and we are done dex ;move pointer to next byte deca ;one less byte to do cmpa #$00 ;last byte? bne PPM1 PPMDONE: pulb rts UPDATEIPFUEL: ; polls IP fuel counter and compares against previously stored ; copy of IP fuel counter - any delta is added to a 64bit ; IP fuel nonvolitile counter ; ; register IPTEMP is initialized to $00 just before EPROM checksum check ; ; X register is trashed ldd L0130 ;IP fuel counter pshb psha subd IPTEMP ;copy of previous counter value addd IPBYTE2 ;add delta to LSW (16bits) of IPFUEL counter std IPBYTE2 ;save it bcc IPDONE ;if no carry over, then done ldx #IPBYTE3 ;point to next byte ldaa #$06 ;number of bytes left to update IP1: inc $00,x ;increment byte bne IPDONE ;if byte didn't become zero then there is no carry over and we are done dex ;move pointer to next byte deca ;update bytes left counter cmpa #$00 ;done all bytes? bne IP1 IPDONE: pula pulb std IPTEMP rts
how the above are called:
Code:
... LBF4B popX stX L0085 staB L008D pushB call UPDATEPPM addB L0134 staB L0134 tSX ldD 1, X subD L0087 ... ... LD26F clr L01B3 clr L01B4 LD275 ldaA #$FF staA L4003 ldD L012D lslD lslD lslD stD L0130 call UPDATEIPFUEL ret ; LD284: brclr L0036, #%10000000, LD28B call L5812 LD28B ldaA #$F7 staA L5000 ret ...
e.g. of the bug:
accumulated distance counter:
00 00 12 34 (before key-off)
00 00 13 00 (after ecm boot up)
accumulated fuel counter:
00 00 00 00 12 34 56 78 (before key-off)
00 00 00 00 12 35 00 00 (after ecm boot up)
If anyone has any ideas...
Trending Topics
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
I was looking through some $58 logs and comparing them with some recent $8D logs. I noticed that the injector BPWs weren't the same for a given AFR on the same engine.
The $8D BPW that is reported to the ALDL datastream does not contain the injector vs. battery offset (pulsewidth adder). The value from the table is added twice to the ALDL reported BPW before sending it to the injector driver. Not sure which BPW RAM variable you are using, but it could make the MPG report higher than actual.
The $8D BPW that is reported to the ALDL datastream does not contain the injector vs. battery offset (pulsewidth adder). The value from the table is added twice to the ALDL reported BPW before sending it to the injector driver. Not sure which BPW RAM variable you are using, but it could make the MPG report higher than actual.
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Wondering if the "Z" bit is doing something. Don't know why I'm thinking that.
Just thinking out loud.
If you want I could change some syntax and try to run it in my simulator and maybe see what happens on a reset.
Just thinking out loud.
If you want I could change some syntax and try to run it in my simulator and maybe see what happens on a reset.
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
JP86SS,
I think he found the problem and has it working but didn't post that yet. I seem to remember that he started another post about MPG with it.
BTW, the AUJP does not report the real sync BPW to the ALDL datastream. The battery correction PW that is added twice is not reported. So if the ALDL is saying 5ms BPW, then it really is about (5+2*.7) = 6.4ms. Something to think about when doing duty cycle calcs. The real DC is higher than what the ALDL says. Low BPWs are even worse because the Low PW correction is also not reported to the ALDL.
I think he found the problem and has it working but didn't post that yet. I seem to remember that he started another post about MPG with it.
BTW, the AUJP does not report the real sync BPW to the ALDL datastream. The battery correction PW that is added twice is not reported. So if the ALDL is saying 5ms BPW, then it really is about (5+2*.7) = 6.4ms. Something to think about when doing duty cycle calcs. The real DC is higher than what the ALDL says. Low BPWs are even worse because the Low PW correction is also not reported to the ALDL.
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Really need to look into that. Wonder why its like that.
Oversight ? Intentional ?
Been simulating his stuff there and not seeing how it all is working. Decrementing PPMByte1 and incrementing PPMByte2 and upwards works good. Rolls back to zero when full and all.
Was getting strange results from the LDD using the 8 bit L0130 address. Kept feeding me $FF for the B register when the value was zero as on a reset would be. If its fixed I'll move on.
Time to sleep ZZzzz......
Oversight ? Intentional ?
Been simulating his stuff there and not seeing how it all is working. Decrementing PPMByte1 and incrementing PPMByte2 and upwards works good. Rolls back to zero when full and all.
Was getting strange results from the LDD using the 8 bit L0130 address. Kept feeding me $FF for the B register when the value was zero as on a reset would be. If its fixed I'll move on.
Time to sleep ZZzzz......
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
I don't know why they did it that way. They do record the actual injector driver to the HUD. I used an NVSRAM memory location and ship that out on the ALDL at the PROM location (byte 1&2). I thought it was interesting because a lot of people say how GM oversized the injectors because the ALDL BPW they see. For example, one sees an 8ms BPW at 6000 RPM and thinks 80% DC. The true BPW actually around (8+2*.7) = 9.4ms. That is, 94% DC sent to the injector. Maybe the injector driver has some strange thing and decreases the BPW? I wouldn't think it would have strange behaviour like that. I haven't built the AVR signal logger yet. Once I get that done I can record the ECM Pin signal and see what really happens.
I never looked at the code you simulated becuase by the time I got back to it he seemed to have it working.
I never looked at the code you simulated becuase by the time I got back to it he seemed to have it working.
Supreme Member
iTrader: (2)
Joined: Jul 2003
Posts: 3,205
Likes: 0
From: Dallas, TX area
Car: 91 Formula WS6 (Black, T-Tops)
Engine: 383 MiniRam (529 HP, 519 TQ - DD2K)
Transmission: Built '97 T56, Pro 5.0, CF-DF
Axle/Gears: 4.11 posi Ford 9"
WOW! Junk, that brings a whole 'nother issue to light.
So when we see 80% duty cycle we could really be in the 90's, depending on your actual PW. I need to go back thru some WOT logs and see how close I really am.
Sounds like something we might be able to address in the XDF files, though. Provided you know your injectors up and down times.
Anyone know the opening and closing times for an SVO 30# injector?
I also wonder how varying fuel pressure might affect those times, too. Probably not much as long as you don't double the FP or similar
So when we see 80% duty cycle we could really be in the 90's, depending on your actual PW. I need to go back thru some WOT logs and see how close I really am.
Sounds like something we might be able to address in the XDF files, though. Provided you know your injectors up and down times.
Anyone know the opening and closing times for an SVO 30# injector?
I also wonder how varying fuel pressure might affect those times, too. Probably not much as long as you don't double the FP or similar
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Since this has gone off track and the problem is fixed anyway, Let me thow something out there.
When dealing with PWM drivers, my vision of the operation is like this.
The Pulse Width is the length of "ON" time for the output. The Duty Cyle is the frequency of that PW in some amount of time based on a 100% maximum.
At the lower end of the scale the PW and duty cycle are in combination to allow the injector to open/close without actually going full stroke.
Once the PW becomes long enough to achieve a full opening time, then the Duty cycle would determine the full "ON" time of that.
PW is normally a fixed value in the controls I use for hydraulics and then the Duty Cycle is the controlling factor that when coupled to a valve coil ends up being the average current through the device is what is being controlled. The current is used for physical work and DC is understandable.
This application doesn't lend itself to my thinking of this. Peak and hold makes perfect sense to me, the saturated injectors have me thinking too much.
I may be way off base in my thinking on this.
Being that the injectors are not a "load" so to speak, how does the PW & DC apply?
Are they both variable?
When dealing with PWM drivers, my vision of the operation is like this.
The Pulse Width is the length of "ON" time for the output. The Duty Cyle is the frequency of that PW in some amount of time based on a 100% maximum.
At the lower end of the scale the PW and duty cycle are in combination to allow the injector to open/close without actually going full stroke.
Once the PW becomes long enough to achieve a full opening time, then the Duty cycle would determine the full "ON" time of that.
PW is normally a fixed value in the controls I use for hydraulics and then the Duty Cycle is the controlling factor that when coupled to a valve coil ends up being the average current through the device is what is being controlled. The current is used for physical work and DC is understandable.
This application doesn't lend itself to my thinking of this. Peak and hold makes perfect sense to me, the saturated injectors have me thinking too much.
I may be way off base in my thinking on this.
Being that the injectors are not a "load" so to speak, how does the PW & DC apply?
Are they both variable?
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
The open/close times are adjusted according to the injector offset table that is used for low BPW values.
For high RPM, high BPWs that table wouldn't be used. Just the battery correction table would be used. The open/close times really wouldn't come into play because the PW table value is added twice. Once could maybe be for the open time, but then the close time should be subtracted. In the end, a typical saturated injector open/close time is 1ms.
Example, ALDL 8ms, batt. corr. table = 1ms.: The driver BPW is (8+2*1) = 10ms. Assume open time is 1ms and provides 0 fuel. Real injector on time is now 10ms - 1ms. Assume injector off time provides zero fuel. Therefore, true injector fuel spray time would be 9ms or (8ms + 1ms) = 9ms = (ALDL_BPW+BATT_CORR_BPW). Just thinking out loud.........have not verified at the injector pin yet.
----------
You are talking about frequency and duty cycle of doing pulse width modulation control. That is not what we are doing here. We are doing duty cycles of injector ON time as a function of RPM. Since BPW and RPM change then so does duty cycle. Both P&H and Sat. are the same from a DC point of view. P&H get a bigger current shot to open faster and then it is reduced to to save heat/power.
For high RPM, high BPWs that table wouldn't be used. Just the battery correction table would be used. The open/close times really wouldn't come into play because the PW table value is added twice. Once could maybe be for the open time, but then the close time should be subtracted. In the end, a typical saturated injector open/close time is 1ms.
Example, ALDL 8ms, batt. corr. table = 1ms.: The driver BPW is (8+2*1) = 10ms. Assume open time is 1ms and provides 0 fuel. Real injector on time is now 10ms - 1ms. Assume injector off time provides zero fuel. Therefore, true injector fuel spray time would be 9ms or (8ms + 1ms) = 9ms = (ALDL_BPW+BATT_CORR_BPW). Just thinking out loud.........have not verified at the injector pin yet.
----------
Since this has gone off track and the problem is fixed anyway, Let me thow something out there.
When dealing with PWM drivers, my vision of the operation is like this.
The Pulse Width is the length of "ON" time for the output. The Duty Cyle is the frequency of that PW in some amount of time based on a 100% maximum.
At the lower end of the scale the PW and duty cycle are in combination to allow the injector to open/close without actually going full stroke.
Once the PW becomes long enough to achieve a full opening time, then the Duty cycle would determine the full "ON" time of that.
PW is normally a fixed value in the controls I use for hydraulics and then the Duty Cycle is the controlling factor that when coupled to a valve coil ends up being the average current through the device is what is being controlled. The current is used for physical work and DC is understandable.
This application doesn't lend itself to my thinking of this. Peak and hold makes perfect sense to me, the saturated injectors have me thinking too much.
I may be way off base in my thinking on this.
Being that the injectors are not a "load" so to speak, how does the PW & DC apply?
Are they both variable?
When dealing with PWM drivers, my vision of the operation is like this.
The Pulse Width is the length of "ON" time for the output. The Duty Cyle is the frequency of that PW in some amount of time based on a 100% maximum.
At the lower end of the scale the PW and duty cycle are in combination to allow the injector to open/close without actually going full stroke.
Once the PW becomes long enough to achieve a full opening time, then the Duty cycle would determine the full "ON" time of that.
PW is normally a fixed value in the controls I use for hydraulics and then the Duty Cycle is the controlling factor that when coupled to a valve coil ends up being the average current through the device is what is being controlled. The current is used for physical work and DC is understandable.
This application doesn't lend itself to my thinking of this. Peak and hold makes perfect sense to me, the saturated injectors have me thinking too much.
I may be way off base in my thinking on this.
Being that the injectors are not a "load" so to speak, how does the PW & DC apply?
Are they both variable?
Last edited by junkcltr; Oct 19, 2006 at 12:02 PM. Reason: Automerged Doublepost
Supreme Member
iTrader: (2)
Joined: Jul 2003
Posts: 3,205
Likes: 0
From: Dallas, TX area
Car: 91 Formula WS6 (Black, T-Tops)
Engine: 383 MiniRam (529 HP, 519 TQ - DD2K)
Transmission: Built '97 T56, Pro 5.0, CF-DF
Axle/Gears: 4.11 posi Ford 9"
So, how does one "know" if the battery PW modifier is correct for his style/brand/size of injectors?Sorry for the stoopit quesshuns....
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
VernW,
That is a vey good question. The only answers I know of is to get the manufacturer data or do the cal on a test/flow bench. A simple setup would be to control the turn on/off time and sync that with the injector flow breaking a laser beam/LED beam.
Take a look at: Fuel Injector Waveforms
That is a vey good question. The only answers I know of is to get the manufacturer data or do the cal on a test/flow bench. A simple setup would be to control the turn on/off time and sync that with the injector flow breaking a laser beam/LED beam.
Take a look at: Fuel Injector Waveforms
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Maybe Rich at Cruzin' Performance could shed some light.
He runs lots of stuff across his flow benches.
Still digesting the rest
He runs lots of stuff across his flow benches.
Still digesting the rest
Thread Starter
Member
Joined: Jun 2001
Posts: 391
Likes: 0
From: Eh?
Car: 1988 Monte Carlo SS
Engine: 5.7L TPI
Transmission: T5
Axle/Gears: 3.73
Been simulating his stuff there and not seeing how it all is working. Decrementing PPMByte1 and incrementing PPMByte2 and upwards works good. Rolls back to zero when full and all.
Was getting strange results from the LDD using the 8 bit L0130 address. Kept feeding me $FF for the B register when the value was zero as on a reset would be. If its fixed I'll move on.
Time to sleep ZZzzz......
Was getting strange results from the LDD using the 8 bit L0130 address. Kept feeding me $FF for the B register when the value was zero as on a reset would be. If its fixed I'll move on.
Time to sleep ZZzzz......
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
The BPW "ON" time is just that. The battery volts (or FP volts) is there to ensure the injector opens fully at the same rate irregardless of the power to it. The length of "ON" time is then consistent with the commanded BPW.
Monte' If I get some more time I'll play with that code some more.
Just did something really stupid to the car this morning that will take me some time to sort out.
Supreme Member
iTrader: (2)
Joined: Jul 2003
Posts: 3,205
Likes: 0
From: Dallas, TX area
Car: 91 Formula WS6 (Black, T-Tops)
Engine: 383 MiniRam (529 HP, 519 TQ - DD2K)
Transmission: Built '97 T56, Pro 5.0, CF-DF
Axle/Gears: 4.11 posi Ford 9"
Uh-oh, what did ya do, John?
Junkcltr - I'm still jus kinda stoopit, I guess, but please bear with me. Seems to me if the opening and closing time for an injector is 1ms, and the ecm has determined you need 8ms of fuel, then the "on time" would be 8ms. Which would equate to 1 ms of opening time and just 7ms of fully open time. In actual fact, there will be an increasing amount of fuel released during that 1ms opening time, plus a decreasing amount during the 1ms of closing time.
For the sake of discussion, wouldn't it be safe to assume the increasing from 0 to wide open amount of fuel for the 1ms opening time, when combined with the 1ms of decreasing fuel amount after the injector has been commanded to close, would sum up to equal 1ms of wide open fuel amount? I would think it would be d@mn close to that anyway. In which case, aren't we are really getting the full equivalent of 8ms of fuel when commanded to open for 8ms?
(1/2 * 1ms_startup) + (7ms_full_on) + (1/2 * 1ms_shutdown)
But for duty cycle calculations, we would have to use the full 9ms of time (actually 18ms since the injectors are batch fired twice per firing as I understand it), right?
Which means an 8ms commanded injector open time would result in (assuming 3000rpm):
DC = 18ms / ( (3000rev/min) * (1min/60sec) * (1spark/2rev) )
DC = 18ms/ (25sparks/sec)
DC = 18ms / 40ms <------ 25sparks/sec = 1spark every 40ms maximum
DC = 72% (without any consideration for the batt voltage injector table values at this point)
I thought the micro second values listed in the "Injector PW Correction Vs. Battery Voltage" table at 03fa were the amounts of time added to the calculated PW based on the battery voltage. Meaning the coils open faster with more voltage and slower with less. Aren't these values added to the calculated PW to get the total commanded PW duration? In other words, I thought these values were the injector opening (and hence closing) times - what we approximated as 1ms in the above calculations. Are they not? Seems only logical since the fuel pressure is what controls the amount of fuel, the electrical side can only figure time which would naturally get smaller (open quicker) as the voltage went up.
Now if all that's true, I have no idea what the "Injector PW Low Offset Vs. Base Pulse Width" table at 040B is for. Is it because at lower PW's the approximations above are not "close enough"? Or is it something else?
So, what PW is being included in the ALDL stream? I would ASSume (there I go again) that it would be the total combined/alterred commanded pulse width , which would have to have the value from the battery correction table added to it to calculate duty cycle.
By this time I've probably put everyone to sleep sounding like I know what I'm talking about when I have no concrete proof (I can't read assembly). So I'll shut up now and go back to sleep myself.....
Junkcltr - I'm still jus kinda stoopit, I guess, but please bear with me. Seems to me if the opening and closing time for an injector is 1ms, and the ecm has determined you need 8ms of fuel, then the "on time" would be 8ms. Which would equate to 1 ms of opening time and just 7ms of fully open time. In actual fact, there will be an increasing amount of fuel released during that 1ms opening time, plus a decreasing amount during the 1ms of closing time.
For the sake of discussion, wouldn't it be safe to assume the increasing from 0 to wide open amount of fuel for the 1ms opening time, when combined with the 1ms of decreasing fuel amount after the injector has been commanded to close, would sum up to equal 1ms of wide open fuel amount? I would think it would be d@mn close to that anyway. In which case, aren't we are really getting the full equivalent of 8ms of fuel when commanded to open for 8ms?
(1/2 * 1ms_startup) + (7ms_full_on) + (1/2 * 1ms_shutdown)
But for duty cycle calculations, we would have to use the full 9ms of time (actually 18ms since the injectors are batch fired twice per firing as I understand it), right?
Which means an 8ms commanded injector open time would result in (assuming 3000rpm):
DC = 18ms / ( (3000rev/min) * (1min/60sec) * (1spark/2rev) )
DC = 18ms/ (25sparks/sec)
DC = 18ms / 40ms <------ 25sparks/sec = 1spark every 40ms maximum
DC = 72% (without any consideration for the batt voltage injector table values at this point)
I thought the micro second values listed in the "Injector PW Correction Vs. Battery Voltage" table at 03fa were the amounts of time added to the calculated PW based on the battery voltage. Meaning the coils open faster with more voltage and slower with less. Aren't these values added to the calculated PW to get the total commanded PW duration? In other words, I thought these values were the injector opening (and hence closing) times - what we approximated as 1ms in the above calculations. Are they not? Seems only logical since the fuel pressure is what controls the amount of fuel, the electrical side can only figure time which would naturally get smaller (open quicker) as the voltage went up.
Now if all that's true, I have no idea what the "Injector PW Low Offset Vs. Base Pulse Width" table at 040B is for. Is it because at lower PW's the approximations above are not "close enough"? Or is it something else?
So, what PW is being included in the ALDL stream? I would ASSume (there I go again) that it would be the total combined/alterred commanded pulse width , which would have to have the value from the battery correction table added to it to calculate duty cycle.
By this time I've probably put everyone to sleep sounding like I know what I'm talking about when I have no concrete proof (I can't read assembly). So I'll shut up now and go back to sleep myself.....
Last edited by vernw; Oct 20, 2006 at 02:22 PM.
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
I see you have been thinking about this. Your thoughts are good.
It actually does it backwards of that. It looks up the VE, the AFR, the AIRFLOW and does a calc for injector BPW. It takes this value and spits it out on the ALDL datastream. Then it takes the value and adds the Battery Correction and Low BPW Correction and sends that to the injectors (injector driver). So, the ALDL BPW is not the real BPW sent to the injector driver.
I'll buy the 1/2 fuel spray during open and close. Using your 3000 RPM example, the total time to squirt for one revolution would be 40ms. The ALDL BPW is ALWAYS the time the injector was ON. It has nothing to do with double fire or single fire mode. You need to know which one the ECM is in. Let's say it is in double fire for the example and the ALDL reports 8ms and your Battery Correction value is 1ms.
Time for one engine (8 cyls fire) at 3000 RPM: 40ms
Time for one injector fire event(we are in double fire mode): 20ms
ALDL reported BPW: 8ms
Battery Correction: 1ms
BPW sent to injector: 1+8+1 = 10ms
Using 1/2 fuel during open and close the fuel BPW is: .5*1 + 8 +.5*1 = 9ms
The ALDL reported value is still 8ms, but the injectors sprayed fuel for 9ms.
The ALDL would report 8ms/20ms DC, the injectors saw a 9ms/20ms DC
Keep in mind the ALDL BPW is always ON time reguardless of firing mode.
If you want to use the 8cyl fire time then you need to 2X the BPWs for the DC calc when in double fire mode. Or 2*8ms/40ms and 2*9ms/40ms.
Maybe the next SAUJP will report the sync. BPW that is sent to the injectors (includes corrections for Battery and Low Pulsewidths). The STACK can be shortened and the RAM can be used for storing values like BPW. I send the real BPW out the ALDL datastream at bytes 1 and 2 (was the PROM ID in the stock AUJP). Three lines of code need to be changed for shortening the stack. All the 0x01C2 references. I have the stack limited to 0x01D8 right now to fit a bunch of stuff I want to report on the ALDL. That is, I use the RAM between 0x01C2 through 0x01D8 for new variables. I wanted to get my code working without the NVSRAM Module.
EDIT: When doing stack adjustments, keep an eye on address 0x0036. It reports stack overruns and failures.
Seems to me if the opening and closing time for an injector is 1ms, and the ecm has determined you need 8ms of fuel, then the "on time" would be 8ms. Which would equate to 1 ms of opening time and just 7ms of fully open time. In actual fact, there will be an increasing amount of fuel released during that 1ms opening time, plus a decreasing amount during the 1ms of closing time.
For the sake of discussion, wouldn't it be safe to assume the increasing from 0 to wide open amount of fuel for the 1ms opening time, when combined with the 1ms of decreasing fuel amount after the injector has been commanded to close, would sum up to equal 1ms of wide open fuel amount? I would think it would be d@mn close to that anyway. In which case, aren't we are really getting the full equivalent of 8ms of fuel when commanded to open for 8ms?
(1/2 * 1ms_startup) + (7ms_full_on) + (1/2 * 1ms_shutdown)
But for duty cycle calculations, we would have to use the full 9ms of time (actually 18ms since the injectors are batch fired twice per firing as I understand it), right?
(1/2 * 1ms_startup) + (7ms_full_on) + (1/2 * 1ms_shutdown)
But for duty cycle calculations, we would have to use the full 9ms of time (actually 18ms since the injectors are batch fired twice per firing as I understand it), right?
Time for one engine (8 cyls fire) at 3000 RPM: 40ms
Time for one injector fire event(we are in double fire mode): 20ms
ALDL reported BPW: 8ms
Battery Correction: 1ms
BPW sent to injector: 1+8+1 = 10ms
Using 1/2 fuel during open and close the fuel BPW is: .5*1 + 8 +.5*1 = 9ms
The ALDL reported value is still 8ms, but the injectors sprayed fuel for 9ms.
The ALDL would report 8ms/20ms DC, the injectors saw a 9ms/20ms DC
Keep in mind the ALDL BPW is always ON time reguardless of firing mode.
If you want to use the 8cyl fire time then you need to 2X the BPWs for the DC calc when in double fire mode. Or 2*8ms/40ms and 2*9ms/40ms.
EDIT: When doing stack adjustments, keep an eye on address 0x0036. It reports stack overruns and failures.
Last edited by junkcltr; Oct 20, 2006 at 03:31 PM.
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Hate to even say how dumb this was. Installed by lift bars (LCA) this week and was too lazy to drill the second bolt hole to secure them because I was going to have them welded. Took it for a drive last night and "seemed" like the lowering brackets weren't shifting while accelling so thought it could make the 10 mile trip. So while driving real slow this morning (in heavy rain)taking it to get welded, I had to hit the brakes slightly hard. Wheels locked up on a 3" tar patch for an instant and then caught back on the asphalt,
BANG, ClUnK, CrunCH!
Brackets swung around and the pinion is now pointing down at a 45* taking out the DS, E-brakes and the brake lines.
Pretty stooooopid I must say.
Will check the damage tomorrow night. Don't even want to look at it now.
Hopefully its not too bad.
Got a welder lined up to do it myself in the garage before it moves again.
Got to see a nice rear end job a few cars ahead of me while waiting for the tow. Rubbernecking can kill you!
Heck of a morning.
Back to the subject,
Thanks for that great explaination J'.
Makes me think that the reporting may have been intentional.
If the reported BPW included the voltage correction it may change with RPM in allot of actual usage. This would make it more difficult to ascertain what the fueling calculations were doing. By making a hardwired correction, the fueling can be reported as calculated but still compensated for voltage.
Not 100% accurate, but repeatable.
Do any of your output logs indicate anything of that nature?
BANG, ClUnK, CrunCH!
Brackets swung around and the pinion is now pointing down at a 45* taking out the DS, E-brakes and the brake lines.
Pretty stooooopid I must say.
Will check the damage tomorrow night. Don't even want to look at it now.
Hopefully its not too bad.
Got a welder lined up to do it myself in the garage before it moves again.Got to see a nice rear end job a few cars ahead of me while waiting for the tow. Rubbernecking can kill you!
Heck of a morning.
Back to the subject,
Thanks for that great explaination J'.
Makes me think that the reporting may have been intentional.
If the reported BPW included the voltage correction it may change with RPM in allot of actual usage. This would make it more difficult to ascertain what the fueling calculations were doing. By making a hardwired correction, the fueling can be reported as calculated but still compensated for voltage.
Not 100% accurate, but repeatable.
Do any of your output logs indicate anything of that nature?
Supreme Member
iTrader: (2)
Joined: Jul 2003
Posts: 3,205
Likes: 0
From: Dallas, TX area
Car: 91 Formula WS6 (Black, T-Tops)
Engine: 383 MiniRam (529 HP, 519 TQ - DD2K)
Transmission: Built '97 T56, Pro 5.0, CF-DF
Axle/Gears: 4.11 posi Ford 9"
Wow, sorry to hear about the rear problems!
And J's explanation is starting to make sense to me too (or at least I think it does... LOL)
And J's explanation is starting to make sense to me too (or at least I think it does... LOL)
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
That read end problem didn't sound like fun. I hope it isn't that bad to fix.
I am still not sure why GM reports the BPW this way. The above example shows that:
the ALDL would report 8ms
the injector driver was on for 10ms
the fuel injector sprayed fuel for 9ms (assuming 1/2 fuel during open&close)
The Battery Correction is constant over RPM so it increase the injector DC as RPM increases. Using the example above:
At 3000 RPM:
(2*ALDL_BPW/40ms) + (2*(2* 1/2) * BATT_CORR/40ms) = (2*8ms/40ms)+ (2/40)
The (2*(2* 1/2) * BATT_CORR/40ms) is 2X for double fire mode, the (2*1/2) is for both open&close using 1/2 fuel sprayed during that time. The Batt. Corr. contributes (2ms/40ms)*100 = 5% injector DC
At 6000 RPM:
(2*ALDL_BPW/20ms) + (2*(2* 1/2) * BATT_CORR/20ms) = (2*8ms/20ms)+ (2/20)
The Batt. Corr. contributes (2ms/20ms)*100 = 10% injector DC
I wanted to report both BPWs as a duty cycle in the ALDL stream, but I can't figure out how to get TP to take two ALDL items (BPW and RPM) and divide them to create a DC value. I guess I could do it in the ECM using the 0x00B3 (time between DRPs) and 0x00E2 (ALDL BPW) report that. It would be a lot easier if I could do it using TP.
I am not sure why GM did it that way, but it sure is great to be running the AUJP again. The single fire injector code works quite well with bigger injectors. I can see it drop in and out of single fire while cruising. I still haven't gotten around to trying single fire at idle. The idle is very stable with the AUJP where as it fluctuated with the $58 (even after A LOT of tuning).
I should probably get around to looking at MonteCarSlow's code since I am clogging up his thread with other stuff.
EDIT: The Batt. Corr. contributes (2ms/40ms)*100 = 10% injector DC was incorrect
Makes me think that the reporting may have been intentional.
If the reported BPW included the voltage correction it may change with RPM in allot of actual usage. This would make it more difficult to ascertain what the fueling calculations were doing. By making a hardwired correction, the fueling can be reported as calculated but still compensated for voltage.
Not 100% accurate, but repeatable.
Do any of your output logs indicate anything of that nature?
If the reported BPW included the voltage correction it may change with RPM in allot of actual usage. This would make it more difficult to ascertain what the fueling calculations were doing. By making a hardwired correction, the fueling can be reported as calculated but still compensated for voltage.
Not 100% accurate, but repeatable.
Do any of your output logs indicate anything of that nature?
the ALDL would report 8ms
the injector driver was on for 10ms
the fuel injector sprayed fuel for 9ms (assuming 1/2 fuel during open&close)
The Battery Correction is constant over RPM so it increase the injector DC as RPM increases. Using the example above:
At 3000 RPM:
(2*ALDL_BPW/40ms) + (2*(2* 1/2) * BATT_CORR/40ms) = (2*8ms/40ms)+ (2/40)
The (2*(2* 1/2) * BATT_CORR/40ms) is 2X for double fire mode, the (2*1/2) is for both open&close using 1/2 fuel sprayed during that time. The Batt. Corr. contributes (2ms/40ms)*100 = 5% injector DC
At 6000 RPM:
(2*ALDL_BPW/20ms) + (2*(2* 1/2) * BATT_CORR/20ms) = (2*8ms/20ms)+ (2/20)
The Batt. Corr. contributes (2ms/20ms)*100 = 10% injector DC
I wanted to report both BPWs as a duty cycle in the ALDL stream, but I can't figure out how to get TP to take two ALDL items (BPW and RPM) and divide them to create a DC value. I guess I could do it in the ECM using the 0x00B3 (time between DRPs) and 0x00E2 (ALDL BPW) report that. It would be a lot easier if I could do it using TP.
I am not sure why GM did it that way, but it sure is great to be running the AUJP again. The single fire injector code works quite well with bigger injectors. I can see it drop in and out of single fire while cruising. I still haven't gotten around to trying single fire at idle. The idle is very stable with the AUJP where as it fluctuated with the $58 (even after A LOT of tuning).
I should probably get around to looking at MonteCarSlow's code since I am clogging up his thread with other stuff.
EDIT: The Batt. Corr. contributes (2ms/40ms)*100 = 10% injector DC was incorrect
Last edited by junkcltr; Oct 21, 2006 at 05:32 AM.
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
I am thinking that the PPM and Fuel inputs change during boot up as the ECM does it thing to setup stuff. Did you try only allowing the fuel calc to be done if the engine running bit is set?
Thread Starter
Member
Joined: Jun 2001
Posts: 391
Likes: 0
From: Eh?
Car: 1988 Monte Carlo SS
Engine: 5.7L TPI
Transmission: T5
Axle/Gears: 3.73
I'm quite sure I tried that. Regardless, it doesn't explain why the last byte (or 2 bytes for the fuel counter) gets set to zero when the code is only supposed to add a delta to the previous value.
Last edited by MonteCarSlow; Oct 21, 2006 at 07:48 AM.
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Been simulating this for over two hours now and can not duplicate what you're seeing. everything is counting and incrementing fine.
Tried $00, $ff and even some oddball negatives to see if I could screw it up.
Only thing I can think of is somehow there is a complimentary value being used on the lower bytes. Must be for only the first pass through.
That is the only way I can force the second byte to increment AND get a zero in the lower.
Is there a "negate" bit in the staus register that could be set during the initial run?
Need to refresh myself on those.
BTW, Dodged a big bullet on the rear. totally no damage, just mayhem!
Should be back to life once welded
Tried $00, $ff and even some oddball negatives to see if I could screw it up.
Only thing I can think of is somehow there is a complimentary value being used on the lower bytes. Must be for only the first pass through.
That is the only way I can force the second byte to increment AND get a zero in the lower.
Is there a "negate" bit in the staus register that could be set during the initial run?
Need to refresh myself on those.
BTW, Dodged a big bullet on the rear. totally no damage, just mayhem!
Should be back to life once welded
Supreme Member
iTrader: (2)
Joined: Jul 2003
Posts: 3,205
Likes: 0
From: Dallas, TX area
Car: 91 Formula WS6 (Black, T-Tops)
Engine: 383 MiniRam (529 HP, 519 TQ - DD2K)
Transmission: Built '97 T56, Pro 5.0, CF-DF
Axle/Gears: 4.11 posi Ford 9"
Wow, JP, you did dodge a bullet on that one! Congrats!!!
Thread
Thread Starter
Forum
Replies
Last Post
