Background
I'm building a roots supercharged 347ci small block Ford (actually a stroked 302 Windsor) on which I wish to run an ion sensing ignition, so I'm looking at the GenBoard/VerThree (which is not yet implemented with IonSense, it needs some DCDC extensions even for simple CDI, but work is ongoing).
Goals
After spending a number of months researching ignition systems, i've decided that I want to use a non-commercial, ion sensing type ignition system for my current and likely future engine development projects. This is for a few reasons:
- All commercial ignition systems are completely proprietary, providing no options for third party software or hardware interfacing, thus having limited extensibility.
- I see ion sensing as a superior method for ignition monitoring and control.
- A system that I can build myself or build in collaboration, will be more cost effective.
Other functionality I want is:
- WBO2.
- Data logging.
- Supercharger efficiency monitoring.
- DetonationDetection.
- Both intelligent/dynamic or "dumb"/lookup table types of ignition control data.
- Loosely coupled hardware and I/O interfacing.
- 8ch EGT
Points 5 & 6 stem from racing regulations i.e. some racing classes do not permit the use of reactive electronics (computer control) but do permit other non-reactive electronics such as data logging, pre-programmed ignition curve, etc.
What's Next
OK, 4ch DIS off GenBoard is easy so it's all requirments met and I'm sold!
Now to start cutting some code...IonSense and/or JTune code.
Currently you can only play with IonSense sample-data on PC, as we don't have the LPC2119 playground yet (GenBoard/VerFour).
I added a MembersPage/PatrickB/Notes page for temp storage of thoughts, etc.
I've come up with a PPP detection algorithm that I've documented on the IonSense page. There's also a few other of my thoughts and comments on there.
I'm looking now to setup my own Ion Sensing test environment where I can collect more data to fine tune the algorithm then port it to ARM. Hopefully Jorgen is going to help me with a schematic for this.
I have my ADC/software ready for Ion Sense data collection and a chassis dyno to run on where I'll be able to run a number of conditions and collect a lot of data to use for fine tuning the algorithms. I plan to run idle, wot, detonation, accelerating, decelerating, highway crusing, etc. My friend should soon finish the hardware (current mirror, etc)...Stay tuned.
I've been hell busy at work and my friend has been sick for a couple of weeks but he should have the Ion Sensing test hardware completed by Sept. That'll tie in nicely with things cooling down at work, so expect Ion Sense to be cranked back into gear then!
BTW, got my v3.1 Just need the time now to put it together..another job for September.
My friend just sent me some CRO traces from his newly completed test ion sense circuit and they look very promising. :)
I'll arrange with him soon to take my car & DAQ along with his circuit to my friends chassis dyno where we'll run a number of tests and collect a lot of ion sense test data.
Went to my friends house and we hooked up the IonSense test circuit to my car and DAQ. We had some clipping problems so we had to play with the component values to get the right range (-5V to +5V), which we eventually did.
Collected a lot of data along the way but none of it is of any use yet, as we seem to be intermittently losing the ion current and this results in random chunks of waveform missing.
We think that this is perhaps due to the ion voltage being too low (it's about 300V) so we're going to setup another power supply of 400V and try that.
Digested the data collected in the last session and we've decided that the current in the current mirror test circuit is so low that the transistors may not be functioning correctly. My mate Gary is going to design a simple resistor based circuit as an alternative to the current mirror.
Here's a photo of my engine: 
It's nearly ready for final assembly....and a Genboard sticker ;
Latest Update
I've put the IonSense research on hold until March, as I've been getting my engine ready to assemble and dyno tune.
As I'm going to race with this engine in racing body sanctioned events, I need to comply with the rules [here] in my class so I've worked out that I'm going to have to cut a special version of the firmware that will allow the engine to run without any possible reactive electronics, i.e. run only with timing data inputs. It will be an "ignition only" system as well (I haven't thought much about running EFI with timing data only, as I use a carburettor).
This version will be based on preprocessor directives that provide the functionality switching between full featured and timing/ignition only, so it could be incorporated into the main codeline if it made sense to do so, which it may well as other sanctioning bodies have many sportsman classes that are "no electronics" rules based (they allow electronic ignition).
I plan to do this over the next month and upon finishing it, I will submit it along with Genboard to the sanctioning body to be incorporated into the approved list of EMS/electronics, etc. I believe they would welcome an open source system as it's much easier for them to verify it's legality when scrutineered, i.e. a proprietary system can never be properly verified as there's often no public interface and/or nothing to compare scrutineering results to.
Any ideas or comments?
If you just don't connect the injectors, or ground a few input signals (whatever is necessary) doesn't that make your electronics comply? Sure, but the system has to run with timing information only, i.e. crank pulse & cylinder reference. ...no TPS, MAP, MAT, etc.
Do they review sourcecode? Maybe.
Or reverse engineer the flash content? No, but they might want to make checksum comparisons. The point is that you can be "guilty until proven innocent" so you need ways of proving your innocence.
I've had some more ideas, I'd like to make this code run time conditional (as opposed to compile time conditional) based on a jumper setting perhaps, i.e. jumper on = race code, jumper off = standard/full featured code.
I also want to add to the race code:
- Upper rev limiting (set max revs via config, etc).
- Addtional 2 stage rev limiting (via config, etc) triggered by a single flip-floping momentary contact input, low-high = limit 1, low-high = limit 2, low-high = no limit (upper limit), low-high = limit 1, etc. Also needs corresponding output to led or similar to indicate current limit (upper only, 1 or 2).
- Shift point output for shift solenoid and/or shift light with configurable number of shift points.
Anyone know any theory/algorithms around ignition only rev limitng?
Cheers,
Patrick.
More to come....
GenBoard v3.1 Build
Started building my GenBoard....
- Added Power Supply,
- Tested Comms: OK.
- Added 4 IGBT for DummyIgnition - ordered MSD coils today, thanks for the help folks :)
- Added WBSensor (2 channels) - need to fully test.
- Added most of ExhaustGasTemp (2 channels). Check GenBoard/Manual/ExhaustGasTemp . 0..10 ohm is fine onto L4 pads (would be nice in RescueKit). AD597 GND to V- decoupling hint: 0..510 Ohm seems right (try 270 Ohm first).
- Finished EGT. I could not get a 10uH L4 in SMD so I used a full sized choke. Tested the board again and the trouble started....the current overloaded my multimeter and it read 0 so I hooked the board up direct (this was a very rude step!)....fizz and smoke, fried the choke!
- Finished the Knock circuit.
- HW finished!!
- Compiled and uploaded firmware. Tweaked the code beforehand as the LCD preprocessor directive did not work (I have no LCD).
Thanks,
Patrick B.