Add-on board 1 for DFH

Jared's unmaintained and never-used TA based "Defacto FreeEMS Hardware" design.
davebmw
LQFP144 - On Top Of The Game
Posts: 331
Joined: Sun Jul 13, 2008 2:58 pm
Location: South Wales, UK

Re: Add-on board 1 for freeEMS_1.0 rev A

Post by davebmw »

Knock sensing for me is quite easy as I have the 2 stock sensors bolted to the head and they are tuned piezo type. This is a simple matter of amplify (not a lot) window on spark event and capture with a monostable with adjustable trigger threshold this in theory should work in a crude MS2 sense. real world however is a different ball game.

Ion sensing could be treated in the same way it is quite easy to bias the spark plugs with a couple of hundred volts DC and measure the voltage drop across a resistor to determine current down to a couple of hundreds of micro amps.
The front end of the circuit can be stuck on the ground return side of the coils with a MOV in parallel with the sense resistor to bypass the high voltage portion during plug firing.
The sense window can be based upon degrees after TDC or plug fire and be as simple as a maximum limit set in good old analog fashion which would be directly analogous to cylinder pressure this output could be used almost as a knock event in MS2 land where a maximum safe cylinder pressure has been reached and the ECU is told to back off the timing by a degree or 2 to prevent detonation. This could just be a logic 1 on a GPIO port the rest is code that would be there for knock sense anyway.

The circuit design for the inverter to get the Biasing voltage is a fairly straight forward Switching PSU, as is the current sensing front end and protection side of things, once the design is proven it can be tweaked and later in the life of the design an ADC pin would be required to allow the ECU and code to do the decision making rather than a crudely set preset.

As for the single O2 sensor for all cylinders here is my thinking:

The engine will draw in a specified volume of air as measured by the MAP sensor then add fuel at the amount specified on the map to attain desired AFR, compress and ignite. the breakdown of liquid fuel into burning and expanding gases equates to the final volume of the exhaust gases which will travel down the exhaust and pass the O2 sensor this in turn produces a voltage at the sensor for that Phut of gas.
Now because the O2 sensor is usually a good few feet away from the exhaust ports it becomes difficult to know which phut belongs to which combustion event.

But I have a plan!

Say on a 6 cylinder engine like mine if you have the ability to individually trim each cylinder you could trim one up a couple of notches and measure the time or number of crank degrees it takes to get that richer gas packet/phut to get to the sensor the sensor.
The relationship of MAP to AFR will be fairly linear and based upon RPM will give the volume of exhaust gases per phut.

This should provide an accurate method of determining which cylinder is doing what and has potential for individual cylinder trim based on AFR from one sensor.

For odd length manifolds you could run a auto tune style program where each cylinder in turn runs a little richer than the rest to calibrate the distance from exhaust port to O2 sensor for each cylinder.
This would get more accurate at higher loads as you have more to work with in terms of bigger phuts of gas, but a linear relationship could be generated to give a reasonable estimation at lower load levels.

I have absolutely no idea of how to do this in code, I just come up with these daft ideas in the bath!

Even if Knock sensing is an optional extra or play it safe feature, I would dearly love to see code written to accept a GPIO port as a timing retard input that would give us the option straight off to implement crude detonation protection/prevention using whatever method, after all MS2 does give that feature and FreeEMS should be considerably more advanced even in its basic form.
93'BMW 325is M50B25TU, Rebuilt 06/06, JE10.5:1, polish&port. Scorpion BB, K&N CAI, TEJ21 WBO2, '07 M3 Evo 18" 225F, 255R, EBC Kevlar, Bilstien Sprint, Polyflex. Head rebuild Oct'08, OEM+FSE FPR, MS2v3.0_DJB Custom, Extra 2.0.1
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Add-on board 1 for freeEMS_1.0 rev A

Post by Fred »

I have absolutely no idea of how to do this in code, I just come up with these daft ideas in the bath!
All the best ideas are had in the shower or similar ;-)

O2 : I think you will be disappointed by the real world sensor speed. Furthermore I think you will find there isn't the HP to make use of such info or read it accurately. Lastly, only shlt engines have issues with poor distribution of gas. Anything decent does not.

For ion sensing, you really want to analyse the wave form... not just trigger at a pressure point. Rather look at it to ensure its smooth. No spike. That takes a LOT of power and special purpose CPU goodness. One day, sure, but in some sort of independent box with comms to the main one.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
davebmw
LQFP144 - On Top Of The Game
Posts: 331
Joined: Sun Jul 13, 2008 2:58 pm
Location: South Wales, UK

Re: Add-on board 1 for freeEMS_1.0 rev A

Post by davebmw »

Fred wrote:O2 : I think you will be disappointed by the real world sensor speed. Furthermore I think you will find there isn't the HP to make use of such info or read it accurately.
Wideband are very poor due to the fact that the charge pump circuit cannot compensate fast enough. Narrow band however are really quite quick, a scope trace of the NB O2 sensor gives you the individual phuts of gas as they pass the sensor head
Fred wrote:only shlt engines have issues with poor distribution of gas. Anything decent does not.
Very true if you have to adjust each pot then there is something fundamentally wrong with the mechanical side of things, I.E. Built by Jim Hensons machine shop! or Ford
Fred wrote:For ion sensing, you really want to analyse the wave form... not just trigger at a pressure point. Rather look at it to ensure its smooth. No spike. That takes a LOT of power and special purpose CPU goodness. One day, sure, but in some sort of independent box with comms to the main one.
maybe a project for a high powered PIC or similar, if all it has to look for is rapid changes in ionic current flow that should be possible for fairly little expense
93'BMW 325is M50B25TU, Rebuilt 06/06, JE10.5:1, polish&port. Scorpion BB, K&N CAI, TEJ21 WBO2, '07 M3 Evo 18" 225F, 255R, EBC Kevlar, Bilstien Sprint, Polyflex. Head rebuild Oct'08, OEM+FSE FPR, MS2v3.0_DJB Custom, Extra 2.0.1
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Add-on board 1 for freeEMS_1.0 rev A

Post by Fred »

davebmw wrote:Wideband are very poor due to the fact that the charge pump circuit cannot compensate fast enough. Narrow band however are really quite quick, a scope trace of the NB O2 sensor gives you the individual phuts of gas as they pass the sensor head
Two things, one, the only information that gives you is the timing of the crossing of the stoich threshold. Nothing else about a narrow band signal is useful. two, I've no intention to support narrow band sensors as they require a 2k lookup table and are next to no use for anything except emissions. Same goes for odd-ball non-linear widebands.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
davebmw
LQFP144 - On Top Of The Game
Posts: 331
Joined: Sun Jul 13, 2008 2:58 pm
Location: South Wales, UK

Re: Add-on board 1 for freeEMS_1.0 rev A

Post by davebmw »

oh i know NB are as good as useless unless the tune is bang on stoich and i wasn't suggesting we waste our time on it I was merely commenting and thinking aloud as to why WBO2 are so slow reacting and have been thinking about a redesign of the charge pump design to improve response time. but in all honesty there are many more fruits that require squeezing first. as for non linear wide band controllers, what is the point in making them anyway. I thought the whole idea of a wide band controller output is to be linear why over complicate things un-necessarily.

Personally EGO Phut ID = not worthwhile just an idea but if someone makes it work and markets it I want the credit!!

Knock sensing = Crude method eg just simple external circuitry to flag knock and retard ignition would be great.

ion sensing = worth while looking into as a separate project to communicate Via CAN or in crude form again flag and retard like the above.

thats my 2p worth
93'BMW 325is M50B25TU, Rebuilt 06/06, JE10.5:1, polish&port. Scorpion BB, K&N CAI, TEJ21 WBO2, '07 M3 Evo 18" 225F, 255R, EBC Kevlar, Bilstien Sprint, Polyflex. Head rebuild Oct'08, OEM+FSE FPR, MS2v3.0_DJB Custom, Extra 2.0.1
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Add-on board 1 for freeEMS_1.0 rev A

Post by jharvey »

To me it seems like there should be a cleaver way to use a switch cap filter as a windowing frequency dependant knock sensor. Perhaps if we had an output signal from the RPM_ISR every 45 degrees, and a connection to the ignition wire. The RPM signal could be the base clock for a switched cap filter, the dwell could be the enable line of the filter, so that prior to the spark the filter isn't allowing much of anything to pass. Then when the spark happens, it's at full sensitivity, however the ignition trigger would shut down the filter. Hmmm, I would bet it could be made to work.

Hmmm, probably would be better to have a programmable oscillator instead of a signal from RPM_ISR. The knock ping is dependant on the motor dimensions, and not the RPM. So we want it to filter for a specific frequency.

Key features switch cap filters offer include, sharp edges (8 pole is fairly easy to obtain), low cost, windowing via digi signal and rugged.

Here's some basic switched cap stuff

http://www.swarthmore.edu/NatSci/echeev ... edCap.html

http://www.maxim-ic.com/quick_view2.cfm/qv_pk/1957

http://www.ecircuitcenter.com/Circuits/ ... ap_Int.htm
davebmw
LQFP144 - On Top Of The Game
Posts: 331
Joined: Sun Jul 13, 2008 2:58 pm
Location: South Wales, UK

Re: Add-on board 1 for freeEMS_1.0 rev A

Post by davebmw »

If you can filter out the noises from the other engine components by selectively windowing from the time that the plug fires until the piston is past the peak pressure point you stand a good chance of detecting an unusually fast rising edge and acting upon it.
so for my setup with a straight 6, I will have an ignition event every 120 degrees in alternate banks of 3 cylinders.
so with a firing order of 1-5-3-6-2-4 and 2 sensors the window switching should look like this:

Fire SP 1, listen on sensor 123
crank travels 120 deg
Fire SP 5, listen on sensor 456
crank travels 120 deg
Fire SP 3, listen on sensor 123
crank travels 120 deg
Fire SP 6, listen on sensor 456
crank travels 120 deg
Fire SP 2, listen on sensor 123
crank travels 120 deg
Fire SP 4, listen on sensor 456
crank travels 120 deg back to start of cycle.

So its just a case of latching on a sequential spark event and selecting which sensor you want to listen to with MS you would have to use some external logic and the cam sensor to determine which plug just fired. but on freeEMS its sequential which would save some work.
Knock sensors are also the tuned to the knock frequency of 6 to 8 Khz which also helps some what.

Now this is a really crude way of doing it using external to the ECU logic and may still be susceptible to cold engine piston slap from forged pistons but that could be ignored in code, based upon CLT and or part of the map where knock control will be active.
93'BMW 325is M50B25TU, Rebuilt 06/06, JE10.5:1, polish&port. Scorpion BB, K&N CAI, TEJ21 WBO2, '07 M3 Evo 18" 225F, 255R, EBC Kevlar, Bilstien Sprint, Polyflex. Head rebuild Oct'08, OEM+FSE FPR, MS2v3.0_DJB Custom, Extra 2.0.1
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Add-on board 1 for freeEMS_1.0 rev A

Post by jharvey »

The more I think about it, the more I think we want either a chip dedicated to knock, or perhaps a remote AVR (or similar) to do significant signal processing. Hmmm.
davebmw
LQFP144 - On Top Of The Game
Posts: 331
Joined: Sun Jul 13, 2008 2:58 pm
Location: South Wales, UK

Re: Add-on board 1 for freeEMS_1.0 rev A

Post by davebmw »

That would be by far the best solution maybe another XDP cpu to take care of the Knock and ion sensing and all other luxury bits. wow! dual core ECU now thats a cool idea! ;)
93'BMW 325is M50B25TU, Rebuilt 06/06, JE10.5:1, polish&port. Scorpion BB, K&N CAI, TEJ21 WBO2, '07 M3 Evo 18" 225F, 255R, EBC Kevlar, Bilstien Sprint, Polyflex. Head rebuild Oct'08, OEM+FSE FPR, MS2v3.0_DJB Custom, Extra 2.0.1
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Add-on board 1 for freeEMS_1.0 rev A

Post by jharvey »

I'm wondering about the staged injectors. Are those intended to have one extra injector per cyl, or should there be one staged injector that covers them all.

My understanding of staged injection is that when at an idle, you need fine control over the fuel. However with an injector that can give you WOT fuel, you often loose that control fine control at idle. If you use one smaller injector for the fine control, and a second injector to bump up the fuel when running harder, you can keep the fine and power control.

What I'm not understanding is if there is one larger upstream injector that fuels all the cyls, or if it's a separate injector per cyl. Perhaps we plan to support both? I'm mostly curious for electrical reasons. Should we have one injector driver or 6 injector drivers?
Post Reply