MembersPage/PatrickB (2012-12-12 12:03:38)

Latest Update

OK, the VR signal was infact reverse polarity. I have corrected and retested but the result is exactly the same. I have also recorded a new trigger log.

The trigger logs are interesting as the extra pri trig signal is shown 12us - 15us after the coil fires. This has been a constant in all trigger logs irrespective of VR polarity.

trigLogCP.png

I have re-routed all sensors and injector harness away from coils and ignition leads but it make no difference.

I have played with the VR harness shield (was grounded at ECU case with ECU floating) and that makes a big difference; floating - it generates irregular extra pri trig (1 - 3 per cycle), grounded to head - crazy with ~30 extra triggers per cycle.

I have a 100mm section of unshielded wire from VR harness to EC36, so I'll attempt to shield that too.

I would like to simply filter them out with an algorithm that says "reject any pri trig signals within Xus (20us in my case) after spark event". As this window equates to only a few degrees at redline RPM, then the pickup position could be moved to allow.

Does anyone else think this is a good idea?

Can someone please send me the 1.1.96 firmware code to spatrickb at hotmail dot com.


Continung InputTrigger issue

I recorded the signal into the line level audio input on my laptop. A bit crude but the signal looks to be VR, about 1.2 volts with a 0.02 variance. It is clean during coil firing and not firing.

These signal images show reverse polarity VR (rising edge, while LM1815 triggers on falling edge). Of course if the soundcard is inverting (some soundcard does), than it can be OK:

crankLine.png

sparkLine.png

VR-polarity must be verified !

So, if the VR signal is clean, then the problem I think is either incorrect config or spark energy getting back into Genboard and causing to malfunction and report erroneous trigger errors. The injector harness and one or two sensor wires are very close to the coils, is that bad?

Any other ideas?


I'm Back

Wow, its been four years..started a family, etc....life gets in the way of playing with cars ;)

Anyway, I bought a v3.6 GenBoard for my latest project; a 302 CI Small Block Ford, EFI and Whipple Twin Screw Supercharger.

Everything works great except I have a VR Primary Trigger noise problem when coils are firing. Grounds are good, cable is shielded with MSD part # 8862, route is low on the block and along the brake lines with no electrics in path, polarity is correct, etc.

Are you sure it is VR sensor?

Logs here: http://vems.hu/files/PatrickB/PriTrigProblem/ (rename triggerlog*.txt to triggerlog*.triggerlog to view in VemsTune

They show that the signals are always clean and correct when coils are not powered (+12 relay removed).

However, the log gets 2 "Too Many Pri Trig" (MISSINGTOOTH errors?) per cycle when coils are powered. But, there are no missing teeth on wheel: http://www.msdignition.com/Products/Crank_Triggers/Crank_Triggers/8640_-_Ford_Small_Block_Crank_Trigger_Kit.aspx

It's just four flying magnets, one pulse per 90 degrees, hence the 8+1 config.

This problem manifests in sounding like it wants to start but then misfires/backfires.

My conclusion is that I have to live with this noise and filter it out in firmware.

The problem is I have tried all filtering options to no avail.

I am now ready to write filtering code unless someone has other suggestions.


Old SVN stuff

You already got svn acc, if you cannot access for some reason, this is not something that can be resolved publically (for obvious reasons).


Old Trigger Problem with v3.1

Got the engine ready to go together and into the car so I've set up the GenBoard on my test engine but I have not yet been able to get a successful trigger config.

I am using a MSD Flying Magnet Crank Trigger http://www.msdignition.com/mag_1.htm

Describe the trigger PATTERN

I have the following config with v1.1.27:

primary_trigger=FE

tooth_wheel=4

tooth_wheel_twidth1=68

tooth_wheel_twidth2=00

trigger_tooth=0

This does not trigger at all.

Can someone tell me what is wrong with this config?

The problem is that the most basic things that need to be checked for any VR trigger are not all checked:


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:

Other functionality I want is:

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: engineComplete.jpg

It's nearly ready for final assembly....and a Genboard sticker ;


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:

Anyone know any theory/algorithms around ignition only rev limitng?


Well, it's been 18 months since I worked on this, during which time I was busy buying a house, etc. My car is not ready for the engine (and GenBoard) yet, but I worked on the IonSense project yesterday with my friend Gary.

We managed to record some IonSense signals!!! However, they have a lot of distortion from the ripple effect of the power supply. We are going to build a new low noise power supply to resolve that.

Currently the signal has headroom for the whole spark event which is not needed, so we will add clipping.

We are using an inductive ignition for testing at the moment, hence the need for clipping.

After we sort these problems, we will collect more data and design a circuit suitable for genboard interfacing.


GenBoard v3.1 Build

Started building my GenBoard....

Did my first SMD soldering on this - Advice: DO NOT attempt this after half a bottle of wine as I did....results in pretty ugly mess...luckily it tests OK, i.e. no shorts. Retested and luckily (phew) everything is okay...One of it's chunky legs must have shorted. Anyway, I replaced it with a 000 (0 ohm) SMD thing from rescue pack: 0 ohm is just that, it is same as a 0.001 Ohm resistor or a 0uH inductor, or a wire or a jumper. It's suitable to power the AD597AR K-thermocouple amplifier.

Thanks,

Patrick B.