It needs figuring out, since all timer stuff on tside runs out of it. At least we know it is 50% off, so it can be assumed it is correct for the 999.376ms interval. That explains the slight off time on longer longs.
The doom is inevitable all around so just stay healthy.
Actually it seems like the 999.376ms interval may be correct. I timed engine runtime (ALDL) for 20 minutes against a stopwatch and couldn't identify a definite skew. At that interval the error would be about 2.5 seconds per hour, which seems plausible. The difference between the log time and runtime could be dropped connections / eehack reconnecting. No biggie, I'll try to find a counting scheme that comes close.
Unfortunately there's another gremlin to shake out.
This is the current progress - I'm calling this an official beta release if that means anything. Note that the source archive is attached to this post, and I will change my .sig to point to the most current version on my vanity domain. The github repository is no longer current.
This uses a 3d table for max dwell target vs temp vs volts, and another 3d multiplier table for multiplier vs map vs rpm. The controller is applying the multiplier and converting the target dwell from time to degrees based on current RPM on the fly. This has added significant cpu load compared to previous releases using fixed degree based tables. Because of this I profiled most of the lookup, multiplier and conversion routines against data sweeps to get things done with the least possible number of processor instructions.
Interactive logging has been improved immensely so as to reduce the possibility of causing time-sensitive procedures from being delayed excessively. I forgot to add it to the readme in this release but if you experiment with logging be cautious of including too many pids that require conversions such as [V]oltage and [R]pm because these conversions are more taxing on processor than ones that report raw data or table indexes.
Warning: there are two known issues / bugs I have yet to resolve to my satisfaction.
The first is a slight miss that with my test mule occurs at approximately 3400 rpm, and then re-occurs much more pronounced around 4200-ish. It is only evident when slowly accelerating through the RPM range under load. I suspect this is a timing issue caused by routine starvation that I hope to be able to eliminate by initiating dwell from within the high-res interrupt routine (i.e. event-based).
The second issue is an intermittent crank-no-start condition that I suspect is being caused by the ect table sensing missing on the first attempt due to an invalid first spark advance #. It's only happened to me 3 times out of several hundred starts, and unfortunately I only have one debug log of the problem to give me clues. When it has happened, a second blip of the key has always produced a start. This should be simple to resolve but I just haven't been able to reproduce enough to come up with a possible solution.
The zip contains much more info now - see README.txt and RELEASE_NOTEES.txt, for details.
The source has been split up into different files to eliminate the need to scroll through all 1600 lines. User settings are now in config.h and custom setting files can be specified by editing the #include statement i.e. #include "config_spfautsch.h" (see README.txt).
Ultimately I'd like to put together a complete assembly and installation manual including pictures, etc. when time permits. But...
As much as I hate to, I'm rushing this out due to growing economic uncertainty as the virus continues to spread. If what my employer is telling us is to be believed the situation is dire. Things could change without warning so I wanted to get this in people's hands now in the event my ability to continue testing and developing is compromised due to loss of income. If things go to hell I will be scrambling to find all sorts of solutions to problems, least of which will be hosting for my vanity domain and keeping gas in my garage queen. Also, the offer of a $50 Amazon gift card has been rescinded due to wages being cut. However, I will do my best to get kits out if there's any new interest for them.
Edit: I forgot to mention that the lower voltage cells for the dwell tables where no dwell limiting could be observed during testing contain hand-interpolated values. There is a spreadsheet in the archive that I used to generate the tables if anyone would like to customize their tables. If you look back to the post containing the test results you can compare that spreadsheet to see which cells were interpolated. In particular the D514a table contains a large amount of this data. It shouldn't pose a problem as the system generally wont be operating below 11 volts for extended periods, but I thought it important you know.
Last edited by spfautsch; 04-04-2020 at 10:05 PM.
Believe I found the crank-no-start problem - a purely boneheaded oversight on my part in the general timekeeping interrupt resulted in no dwell target for the first couple firing events.
This has not been road tested but I don't anticipate any problems as the change was extremely minor. Will try to test the day after tomorrow and report back.
Edit: Road testing today was successful. I'll start working on the miss issue in a day or two.
Last edited by spfautsch; 04-08-2020 at 02:43 AM.
Another update - I'm still alive and well, and still employed. I hope everyone here is enjoying the same.
Made some significant progress today running fully interrupt driven dwell (i.e. no hazard of routine starvation). In the process of locating the issue I implemented some real-time profiling that helped me identify how dwell wasn't being initiated by the controller around the transition points in certain conditions. This is where dwell needs to extend beyond one cylinder firing event or simply put more than 90 / 180 / 270 degrees of crank rotation. After sweep testing a few more routines I found a couple possible issues that were easily fixed.
The result is something the butt-dyno says is damned good, but the profiling numbers say still lacks ever so slightly. Possibly a missed dwell happening during decel events where I lift my foot off the go pedal.
Hoping to put a couple hundred miles on it Monday and will report back. I'm excited! Not only because it's no longer exhibiting the rev-limiter type behavior around the transition points, but I'm also happy to report the microcontroller seems to have more than enough processing power to compute dwell from time to degrees on the fly once per combustion event (using the 16 bit RPM value) as far as I've been able to push it (around 5800 rpm).
Last edited by spfautsch; 04-19-2020 at 04:01 AM.
That sounds awesome. I'll admit I was on the fence about running any of the new stuff due to the dwell bugs (the older branch seemed more robust, if far less feature-rich), but it seems like those last few remaining issues are going to be ironed out in short order. I'll need to hit you up to swap to the new board. I've had a full set of coils and harnesses laying in my lab for months now, just need to get spark plug wires and figure out a way to mount them in the engine bay. Well, that and buy up a few more connectors so I can try to fab up a "plug and play" harness to let me switch between your controller and the Opti for testing. I prefer to modify as little of the original wiring as possible, and thankfully the majority of the car's connectors are still available on Mouser or Digikey, so yeah.
It may sound like crickets around here but I still watch this thread and the EEHack/Flashhack threads like a hawk reading every update. Glad you're still safe and still employed, and hope it stays that way.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
For plug wires I generally like making my own - a set of Taylor 46052 straight boots (search amazon) and I generally go to Autozone and buy a universal set of 8mm wires. With headers I needed 90* boots on all but 6 & 8 plugs so I got a Duralast 1601 kit for like $24. Heck they may even have a universal kit with the LT-1 straight boots (the Taylor PN above). Get a plug wire crimper and a can of silicone spray and you're all set.
There are no major functional changes to the new board, just the addition of an ICP header and provisions to add jumpers to disconnect the ground planes for the leds. I PM'd you details - all you need is a .1uf cap for the ECT sense input.
I don't know what possessed me, but I invited my wife to go for a ride today because I thought she'd be helpful in switching a parameter I wanted to test. Got tired of hearing "stop trying to make me puke" real quick. After dropping her off at the house and re-connecting all the USB cables she yanked loose, had a successful test drive. Spun it up slowly to about 6400 in 2nd and couldn't feel any missing even though the profiling metrics showed 2 or 3 missed dwells. Hoping to have a more productive day tomorrow logging my commute.
Posting Permissions
Reply With Quote
Bookmarks