Just been reading p40 on the coolant temperature sensor. That's interesting. I've not seen seen a sensor used with dual range/sensitivity before.Originally Posted by kur4o
Presumably there must be some bit in the PCM that stores this info when it's crossed up over the 51C threshold.
I suppose it could also be done easily with discrete components and a latch once it's passed the 1st limit.
... Does it switch back if the sensor is cooled down whilst the PCM is still powered?
Mitch
'95 Z28 M6 -Just the odd mod.
'80 350 A3 C3 Corvette - recent addition.
LOL yup cranking voltage can be around 8 volts, so yes, you can dramatically help cold start especially with a bad cold start tune :)
-Carl
Here is the switch code. The pcm converts the raw adc input to table lookup value and decides based on the lookup value. So converting to raw adc voltage is a little tricky. The thresholds used are lookup values of $78 =40*C and $6a=50*C. You have to find where these thresholds are stored in the lookup tables and count the adc steps.Code:RESERVED:66C3 ; =============== S U B R O U T I N E ======================================= RESERVED:66C3 RESERVED:66C3 RESERVED:66C3 COOL_FILT_ROUTsub_66C3: ; DATA XREF: RESERVED:6293o RESERVED:66C3 ldx #$EED1 RESERVED:66C6 ldaa byte_1807 RESERVED:66C9 bita #2 RESERVED:66CB bne loc_66D0 RESERVED:66CD ldx #$EFD1 RESERVED:66D0 RESERVED:66D0 loc_66D0: ; CODE XREF: COOL_FILT_ROUTsub_66C3+8j RESERVED:66D0 ldab byte_109 ; RESERVED:66D0 ; raw ad ect RESERVED:66D3 abx RESERVED:66D4 ldaa 0,x RESERVED:66D6 staa byte_1A7 ; raw lookup ect RESERVED:66D9 ldx #$1807 RESERVED:66DC cmpa #$78 ; 'x' ; 42 raw RESERVED:66DC ; table1 RESERVED:66DE bhi loc_66EC RESERVED:66E0 cmpa #$6A ; 'j' ; d0 raw RESERVED:66E0 ; table0 RESERVED:66E2 bhi loc_66F2 RESERVED:66E4 bset 0,x 2 RESERVED:66E7 bset byte_80 2 RESERVED:66EA bra loc_66F2 RESERVED:66EC ; --------------------------------------------------------------------------- RESERVED:66EC RESERVED:66EC loc_66EC: ; CODE XREF: COOL_FILT_ROUTsub_66C3+1Bj RESERVED:66EC bclr 0,x 2 RESERVED:66EF bclr byte_80 2
I do the counting and from table0 $78 is reached at $31 ADC counts and $6A at $44 ADC counts
table1 $78 is at $b8 ADC counts and $6A is at $CB counts.
To converts adc counts to voltage use the formula. X*(5/255) or X*(5/256), not sure which one is correct.
$31=0.96v equals 40*C table0
$44=1.328v equals 50*C table0
$b8=3.6v equals 50*C table1
$cb=3.965v equals 40*C table1
This translate to
As the engine is warming voltage goes steady down from 5 v to 0.96. When 0.96 is reached the rc network is switched and the voltage raises to 3.6v. Than it continues to drop till 0volts. If the engine gets cooler and the voltage raises to 3.965volts, the rc network is switched again and the voltage drops to 1.328volts and keeps raising with the engine getting cooler.
Thanks, that's exactly what I was looking for.
I think I've got this mostly figured out, and will be using the lookup value internally (call it an engineering unit, whatever). It's very handy because it gives operating temp in 8 bits without needing a sign. Then I can just convert it to C or F if needed for logging.
I would advise staying away from referencing voltages because there can be lots of precision lost converting back and forth. Now I just need to test how close the two ADCs are between the AVR and the PCM. I'm having to bit shift the 10 bit AVR value to get it to a 0-255 range.
I finally found a calibration that uses map reference for the coil. It is 2002 express van l31 engine with the same coil and ICM module as 96-97 LT1.
It is a single coil and that can explain the less dwell on lower map to offload the coil.
Though it doesn't seem like GM is using it in their (coil per cylinder) calibrations I think I'm going to keep working towards the goal of using the MAP input, or at the very least reading it and having the data available. It causes very little overhead so even if it's unused it's nice to have the ability to include MAP compensation in a future build.
Progress has been slow this week due to work and crappy winter weather. Found out the hard way the breaker for our 10kva UPS was 10 amps smaller than was called for and that the panel it's in is ridiculously overloaded. So I've been spending some "quality time" there playing electrician in addition to IT guy.
Anyway, by adding a point or so of skew I've been able to get the (converted to 8 bit) ADC readings from the coolant sensor to match the readings in the ALDL stream very closely, and initial spark advance seems to be working reliably so I think this should work. I'm planning to pull the controller out of my car tonight to add another wire for the spare output so I can also use the MAP input.
I've also added a bit of code to tell me where the engine was at the time the controller began seeing high res data. Not that it's needed, I just wanted to know...
In this example it saw 55 degrees of rotation before seeing a TDC signal on the low res line, and the sequencer detected the next cylinder was 7, so it was 55 btdc on the #5 compression stroke.Code:diy-ltcc-0.9.20 startDegrees=55 startLRCount=1 startSeqDeg=0 invertSeq=0 firstCyl=7 initSaDegrees=8 firstFire=7 adcEctAvg=80 1 : F 16721 : C 79 : V 11.71 : T 0 2 : F 7258 : C 79 : V 14.19 : T 0 3 : F 7289 : C 79 : V 14.19 : T 0
Last edited by spfautsch; 02-06-2020 at 07:21 PM.
Forgive me butting in. I know nothing about code, but I do about electrical theory and the dielectric strength of gasses. Lowering the ignition output is of course possible at lower cylinder pressures, but the benefit to me seems to be largely in reduced wear across the spark gaps including those in the distributor. With coil-per-cylinder the reduced dwell certainly reduces heat and power consumption, but by how much?
Joshua
1994 Corvette, 6MT, Z07
Scientific method is paramount, so no forgiveness is necessary. The code is merely the vehicle that manifests the science.
All this is worth considering. But we've taken the wear parts of the distributor out of the picture so the plugs are the only thing remaining to erode.
The power consumption topic is an interesting one. Looking at the dwell tables of the coil per cylinder calibrations it seems to me they aren't really caring much about power consumption. At lower voltages (see my next comment about dwell limiting) the dwell time seems to be focused on maximum spark energy for starting. But the other condition that causes low voltages (a dead charging system) to me it seems like they would want to maximize runtime to get the owner home (or to a garage if they're the typical consumer-driver).
On the thermal side of things, all the coils I've tested thus far have built-in dwell limiting that's both voltage and temperature dependent. This is entirely my opinion, but after testing 5 different coils at 6-8 different voltage bands and 10 or so temperature ranges (350 data points give-or-take) I think it would be all but impossible to "hurt" one of these coils thermally with normal use regardless of how much dwell you're throwing at them. When I use the qualifier "normal" I mean having coolant in the engine, and some measurable amount of oil pressure. Cleetus McFarland types need not apply here.
With that said, thanks for contributing - all good points worth considering.
I got absolutely nothing done tonight due to more work stuff. Fingers crossed that's done and over with.
I brought up wearing of the spark gaps due to the distributor-equipped Express Van that have, as ku4ro found, "...map reference for the coil." That code could be there for long-term durability. Coil-per-cylinder doesn't have that durability issue with decent spark plugs.
Ooo, that's good coil testing! I wasn't thinking about hurting a coil in the near-term, but thinking about long-term reliability due to thermal degradation and also the tiny bit of CAFE improvement engineers are chasing through reduced electrical load.
Joshua
1994 Corvette, 6MT, Z07
I see some good progress here.
You can use map reference for heavy acceleration and deceleration events. On heavy load and off load, bumping the dwell +-10% to the theoretical best dwell.
So you need to get a delta map reading. Think about adding some blending factor for gradual dwell change.
I am still trying to find how beneficial is lowering dwell on rpm increase. I will do some test with my test ls1 coil vehicle with different dwell settings at wot.
Another test that might reveal dwell vs rpm relation is to put a coil for an hour with 4ms on, 2 ms off interval. Timing can be varied by your decision. The idea is to get the coil very limited off time and see how it behaves, does some charge remains in the coil, does it heat up or the dwell limiter might exhibit and the spark output degrades.
Now you know the start position of the opti. How about record the off position and save the data in ram, I suspect the avr can be brought to bed with some timer. Not immediately on ign off. And some data can be saved there. It can be used on immediate hot restart.
I have runned 10ms on startup with no issues. That might be the best startup dwell since on most calibrations that is used as target. You can also specify a dwell adder for engine off and checkbyte for engine on with some conditions met.
That's almost exactly how works now minus smoothing. Ramping a 10% change into something like 4 milliseconds seems awfully pointless and eats a timer that I need elsewhere.
I'm not seeing a point to this unless you want to actually melt a coil. Let's step back and look at some generalizations.
At some ridiculous RPM like 10,000, there's 12ms between combustion events, correct? (120 / 10000 = 0.012)
Assume some default dwell of 4ms, and a 2ms spark duration. That puts the individual coil at roughly 50% duty cycle - charge 4ms, discharge for 2ms, rest for 6ms (at 10k rpm). Why push it further? I just don't feel it's worth agonizing over. I'm still planning to add an optional RPM vs dwell multiplier table (i.e. 128 = 1.0), but it will eat 5-6 clock cycles to do the math of multiplying the 16 bit dwell time integer with an 8 bit multiplier. And then it needs to be converted to degrees for RPM.
I considered building it this way initially, but I'm not sure it's worth the trouble to potentially eliminate 90 degrees of engine rotation. Worst case scenario where the engine stops in the #2 low res trigger slot, a maximum of 138 (90+46(+/-2) degrees rotation is required for sequence to be picked up.
At what voltage? I'm not planning on having separate dwell tables for cranking or making it any more complicated than it needs to be. One 3d with dwell vs temp vs voltage.
I'm hoping to make some headway this weekend. Mainly because I'm itching to get the car out and enjoy doing what it was made to do - be driven. I do love solving problems like this, but I'm coming up on my 49th birthday, and need to get firmware version 1.0.0 released before I run out of days.
Here is the startup dwell from 0-400 rpm. It gets interpolated as the rpm raise. I set it 10ms for all voltage range. I have a plan to set it at a fixed value of 10ms until the engine on flag is set at 500rpm. In this setup it is impossible due to interpolation. Small code change will be needed. I feel now that startups are not optimal. I will report how it feels with the fixed dwell target at cranking.0 400 rpm
21.17 21.17
9.95 7.82
9.95 7.14
9.95 6.80
9.95 5.95
9.95 5.61
9.95 5.44
9.95 5.10
9.95 4.85
9.95 4.50
9.95 4.34
9.95 4.08
9.95 4.00
9.95 3.74
9.95 3.57
9.95 3.49
9.95 2.98
I vote for the simplest most efficient code. It always works better. No fancy loops required, just some thresholds and your done.
So you are telling me that running the coils at higher 6000+rpms for 3.8ms on and 6.2ms off time[my current setup at 6000rpm] will fry the coil. Good that the test vehicle sees 6000+rpm very rare.
What test vehicle / engine / ecu are you referring to here?
The thing you need to keep in mind is that during cranking you absolutely have to compensate for voltage. Don't check my math on this one because I'm just spitballing, but a fixed 10ms of dwell at 9 volts is going to charge the coil with roughly half as much energy as 10ms at 12 volts (not considering integral dwell limiting). Power isn't a linear equation, in this instance it's the product of voltage and current over time (I*E)/T=W.
I'm working hard at stripping out irrelevant code, as well as optimizing the math for this build because it will need to convert dwell from time to degrees based on current angular velocity (RPM) on the fly. There's no way I can do this with a lookup table. I've built a profiling sketch that enables me to find how many clock cycles a given equation uses with different input data, which I've been using heavily. KISS (Keep It Simple, Stupid) has been my mantra for most of the past 20 years. Unfortunately (or fortunately depending on how you look at it), my knowledge and experience with c++ has tripled in depth over the course of this project.
No. Check your math - or check my math. In a 4 cycle engine combustion events happen at 120(combustion events per division) / 6000(rpm) = 20ms.
Unless you're referring to another waste spark setup, which as I've stated repeatedly is a completely different animal.
The math is correct, but being waste spark, coil is fired each 360* or 10ms for 6000rpm. An oddball gm tbi pcm is used with hc11 processor.
I just tried the 10ms fixed dwell for starting and couldn`t tell any difference. A subzero start at -5*C. A new plugs can be better for such tests, since the ones I have now are shot.
I am starting to think that at lower voltages the coil would never go to full charge. My theory is that the energy will start to radiate or heat will built inside.
AN example will be bottle with a small hole. When you fill the bottle with high current of water, it will overfill easily. If you reduce the water current, the hole in the bottle will start to leak and there will be more time needed to fill the bottle. If the current is low enough and can`t overcome the hole leak, you can never get it full.
So at low voltage the coil can`t charge full enough to kick in the dwell limiter. Adding extra dwell will only produce more em radiation and heat but not more energy output.
Lt1 pcm also converts dwell to degrees but only on startup situation. There is also some sophisticated system timer. Based on the timer each routine is executed on the timer basis with fixed intervals. Adding that kind of stuff may give you better control of code flow. Coolant lookup is really slowly updated and the code for it can be runned each 1-2 seconds. So everything non critical can be made to run each xx ms.
I'm not a professional mechanic, and I've personally seen a half dozen of those waste spark coil packs melt around the towers on pre-2002 3.8L v6s - most with less than 200k miles on them. They were perfectly adequate on low-revving stuff, but I don't think GM used them on many "performance" setups with redlines > 5000rpm.
The waste spark coils they're using on the current 3.9L v6s seem to be much more robust.
Maybe a project for next winter. Time based control would be nice, but there's only one 16 bit timer available on the AVR so if it's possible to handle sequencing overlapping dwells with just that, I haven't wrapped my head around how to approach it.
Coolant detection based on the 12057 cranking spark advance table looks like it will work.
First column is engine runtime in seconds, C is internal ecu engineering units - convert to celcius with (X*0.75)-40, V is obvious and M is raw adc count of the MAP input.
Transition to table1 worked as expected.Code:diy-ltcc-0.9.20 startDegrees=8 startLRCount=1 startSeqDeg=0 invertSeq=0 firstCyl=1 tbl0Val=93 ectMaxTmp=112 ectMinTmp=80 ectTable=0 tdcEvents=0 ectValue=93 initSaDegrees=9 firstFire=1 adcEctRaw=93 1 : F 9074 : C 91 : V 11.03 : M 897 2 : F 8242 : C 91 : V 11.25 : M 565 3 : F 8194 : C 92 : V 12.91 : M 518 4 : F 8200 : C 91 : V 14.14 : M 537 5 : F 8185 : C 91 : V 14.25 : M 479 6 : F 8184 : C 91 : V 14.04 : M 453
I'll have to test a bunch of different scenarios but the code is pretty simple.Code:173 : F 8183 : C 118 : V 14.04 : M 348 174 : F 8191 : C 118 : V 14.00 : M 348 175 : F 8186 : C 118 : V 14.04 : M 342 176 : F 8192 : C 118 : V 14.07 : M 333 177 : F 8188 : C 120 : V 13.45 : M 336 < I forgot to have it spit a message out, but transition would have happened here 178 : F 8188 : C 121 : V 13.03 : M 334 179 : F 8184 : C 119 : V 14.04 : M 345 180 : F 8187 : C 119 : V 14.12 : M 335 181 : F 8193 : C 119 : V 14.00 : M 346 182 : F 8187 : C 119 : V 14.12 : M 344 183 : F 8189 : C 119 : V 14.07 : M 338 184 : F 8189 : C 120 : V 14.04 : M 335 185 : F 8184 : C 123 : V 12.82 : M 356 186 : F 8193 : C 120 : V 14.00 : M 334 187 : F 8189 : C 120 : V 14.04 : M 349 188 : F 8188 : C 120 : V 14.00 : M 330 189 : F 8189 : C 120 : V 14.02 : M 338 190 : F 8188 : C 121 : V 14.11 : M 344 191 : F 8189 : C 121 : V 14.00 : M 345 192 : F 8189 : C 121 : V 14.04 : M 330 193 : F 8188 : C 121 : V 13.99 : M 350 194 : F 8189 : C 122 : V 14.04 : M 333 195 : F 8193 : C 122 : V 13.97 : M 318 196 : F 8186 : C 122 : V 14.00 : M 340 197 : F 8181 : C 122 : V 13.97 : M 338
Code:uint8_t discEctTbl(uint8_t rawEct) { // read the lookup value from table0 based on current raw ect value uint8_t tbl0Val = pgm_read_byte(&ectTable[0][rawEct]); uint8_t ectMinTmp = 128; uint8_t ectMaxTmp = 128; // iterate the cranking spark table from both directions for (uint8_t i = 16; i < 255; i--) { if (pgm_read_byte(&crankSpkTable[i][1]) > initSaDegrees) { if ( i < 16 ) { //ectMinTmp = pgm_read_byte(&crankSpkTable[i + 1][0]); ectMinTmp = pgm_read_byte(&crankSpkTable[i][0]); } else { ectMinTmp = pgm_read_byte(&crankSpkTable[16][0]); } break; } } for (uint8_t i = 0; i < 17; i++) { if (pgm_read_byte(&crankSpkTable[i][1]) < initSaDegrees) { if ( i > 0 ) { //ectMaxTmp = pgm_read_byte(&crankSpkTable[i - 1][0]); ectMaxTmp = pgm_read_byte(&crankSpkTable[i][0]); } else { ectMaxTmp = pgm_read_byte(&crankSpkTable[0][0]); } break; } } if (ectMinTmp == ectMaxTmp) { if (ectMinTmp == 0 || ectMinTmp == 255) { if (ectMinTmp == 0) { ectMaxTmp = 16; } else { ectMinTmp = 240; } } else { // this should never happen, but if it does increase the spread ectMinTmp -= 8; ectMaxTmp += 8; } } #ifdef TEMP_DEBUG Serial.print(F("tbl0Val=")); Serial.print(tbl0Val); Serial.print(F(" ectMaxTmp=")); Serial.print(ectMaxTmp); Serial.print(F(" ectMinTmp=")); Serial.println(ectMinTmp); #endif // at this point there should be a range in ectMinTmp and ectMaxTmp that the current actual temp should reside in if (tbl0Val > ectMinTmp && tbl0Val < ectMaxTmp) { return 0; } else { return 1; } }
Posting Permissions
Reply With Quote
Bookmarks