Is there a dwell setting that is accessible with $ee hack?
Is there a dwell setting that is accessible with $ee hack?
I assume you mean in the PCM firmware (referred to as the $EE mask for 94-95 model years), and not that I've been able to discern. All the documentation we've seen indicates it's controlled by the EST output but I would have to defer to kur4o or someone else who has the intestinal fortitude to stare at the disassembly because I simply lack the willpower.
I've found an interrupt triggered capture function available on the Atmegas that might allow for calculating RPM accurately enough to suffice, but a lot more research is needed. One thing I can say for certain is whatever I might be able to come up with will not function whatsoever without the high res signal.
There are plenty of unidentified parameters used by tpu processor.
It runs from some built in memory ROM but uses some of data in the bin as calibration parameters.
I figured some high res counters in the code, thanks to service manual opti error descriptions.
Finding dwell parameters without TPU processor main code will be a guess work.
Some waveforms from the est signal might help alot though.
PCM calulates spark:
1. angle based when high res signal is present{high res counter {possibly triggered after low res rising edge} + {90- spark advance}
2. time based when high res error is set( in ms after low res pulse is detected}.
68hc11f1 is 4mhz. I cant find a pic of the crystal used on the board to confirm.
Like a mask ROM? There's generally no way to dump something like that, right?
I was afraid that would be the case. This goes way beyond my propensity for machine code hacking. The deepest I got into this type of thing was dumping avr firmware from a smartcard "unlooper" and reverse engineering it to change a few uart commands.
This got me thinking it would probably advisable to use an arduino with a crystal oscillator, which eliminates my preferred adafruit piece. :-\
Mask rom code showed some good google results.
The best invasive method is to scrape the chip and read the data optically.
I know someone figured an easy way. These D84G TPU processors{I guess some 68hcXX variant} are used in many sir, abs, and other controllers in that era as a primary processor.
Ok. I was extremely busy this week at work, so I did this tonight in the cold after I cannibalized a battery pack to fix my interro scope. Hopefully, this will be enough to keep all coil dwell paranoia at bay, and determine which coils will work best.
From what I have found out, the LS2 non-finned truck ignition coils (barrel shaped), should work best for this conversion. My '95 wagon has 4.59 mS max dwell and 3.2 mS minimum dwell. According to the Megasquirt coil dwell page, max dwell for the LS2 coil should be set to 4.5 mS. This looks like a perfect match. The LTCC product page says you cannot use the finned LS2 ignition coils. Not sure why.
"The round body truck coils with the metal fins (19005218) DO NOT WORK"
Now we also know why the LTCC module has so few parts. It most likely GATES the EST signal to the correct coil in sequence. The lack of other chips is why I suspected this. It just looked too simple for yesteryear's technology. I figured that engineer was clever, and he sure is. More clever than most, since he has a finished product with a minimum of internal parts.
Anyways, here is my proofs. The battery voltage was 13.85v
Attachment 12253
Attachment 12254
Attachment 12255
damn it. The server flipped them sideways.
Last edited by vilefly; 11-11-2017 at 05:20 AM. Reason: crooked pictures
None of the attachments are working on this end. Anxious to see what you got but no rush. This weekend I'm going to be freezing my stones off finishing my deck rebuild that should have been done in May.
What I think you might be misunderstanding or in denial about is the notion that multiplexing the EST circuit will work. The reason coil per cylinder setups work well at high RPMs is because they aren't limited to 90 degrees of crank / 45 degrees of distributor rotation to charge. The EST circuit on the other hand has to live within this constraint. What I was trying to illustrate with this post is that if we're multiplexing the EST line, the very best dwell we could possibly get at 6000 RPM, assuming a very tame 30 degrees spark advance is 1.67 ms. That's the opposite of "good".
edit: I got sidetracked by dogs needing to go outside, but meant to also add that I've been thinking this over non-stop and think there may be hope for the arduino platform. If the original LTCC module multiplexes / gates the EST line (I'd bet you a bottle of good whiskey it doesn't) then what I'm hoping to be able to come up with should be better in the same way sliced bread was an improvement on flour dough baked on a hot stone.
Last edited by spfautsch; 11-11-2017 at 06:11 AM.
Bookmarks