FreeEMS firmware feature wishlist! (out of date)

[davebmw]

Are there any plans to do sensor diagnostics - like putting up a warning light if a sensor is disconnected or acting up.....

This is something lacking in MS - isee posts like - i dont have spark or i dont have RPM in MSland - and i feel that sensor diagnostics may help or atleast provide a starting point....

Thats an interesting point.
During my tearing down of the Bosch motronic ECU i have found that there is a 240R resistor on the HT side ground return line from the COP's this enables the ECU to detect misfire's.
Although there is a seperate microcontroller just for fault dignosis and reporting in OEM ECU's so its going to come at a cost I would have thought.

Oh yes and thanks Fred i found the Quote button! Slacker indeed!

[Fred]

I don't think it matters to many people if they get the odd misfire, but sensor range checking and possibly even limiting and/or defaulting are definitely options that I'm considering. I would like to know if my coolant is reading -25C even though it's 10C weather for example. I think that is something to add down the line. Because The input and averaging and what have you are modular it should be childs play to insert code to cause that behaviour into the mix.

If someone is getting consistent misfires, either their ignition settings are bad, their ignition components are broken, or they need an upgrade for the cylinder pressure they are trying to achieve. Occasional misfires are normal and expected. The modern COP units have feedback pins on them to return a "sparked" signal back, but it doesn't tell the ecu if there was a misfire. That is done with crank speed variance and ionisation testing. Both things out of our league at the moment and far from essential too.

Fred.

[davebmw]

Would it be possible to setup a map for VANOS/VVT actuation based upon various factors, load, rpm, coolant temp?

What about 2 or more knock sensor channels?

and Multiple WBO2 sensor inputs?

Programmable Fuel consumption output calculated from number and duration of squirts, RPM and road speed?

What do you think?

[Fred]

Would it be possible to setup a map for VANOS/VVT actuation based upon various factors, load, rpm, coolant temp?

Either PWM or on off should be doable/usable like this, however if a solution makes it into the main release code it needs to be generally useful for more than one function. For that I would say load/rpm vs pwm could be used for open loop boost and vvt and probably other things too. Adding coolant temperature to it might be frivolous. Basically anything is possible and most things like that should be childs play to implement, but things for the release code should be generically useful.

What about 2 or more knock sensor channels?

2 is good for flat/V engines, but not useful on inline engines. Of course, we'd need one input functioning first :-) most stuff should have an option for parallel usage for V/flat engines.

and Multiple WBO2 sensor inputs?

This would be nice on a boosted engine for each cylinder except that you can't use them under pressure like that. Is it worthwhile blocking your ports with a sensor when NA, probably not. Boosted use one or two wbo2 and a set of EGT to ensure the cyl flows are even. The best solution is to design the manifolds and fuel rails etc well so you don't have uneven flow issues. There are two for V/flat engines included already. (not used just yet though, but loggable)

Programmable Fuel consumption output calculated from number and duration of squirts, RPM and road speed?

Output to what? In the log should be easy enough to do for sure provided VSS is used.

Fred.

[davebmw]

Would it be possible to setup a map for VANOS/VVT actuation based upon various factors, load, rpm, coolant temp?

Either PWM or on off should be doable/usable like this, however if a solution makes it into the main release code it needs to be generally useful for more than one function. For that I would say load/rpm vs pwm could be used for open loop boost and vvt and probably other things too. Adding coolant temperature to it might be frivolous. Basically anything is possible and most things like that should be childs play to implement, but things for the release code should be generically useful.

Oh i agree that the auxilary outputs should be very configurable for almost any application, from VANOS, VVT, Flaps in exhaust, Boost control, intercooler water spray, intercooler fan etc etc etc

What about 2 or more knock sensor channels?

2 is good for flat/V engines, but not useful on inline engines. Of course, we'd need one input functioning first most stuff should have an option for parallel usage for V/flat engines.

My straight 6 has 2 knock sensors, it would be nice to have both of them listening out for potential problems and reeling back the timing should the big bang be imminent!

and Multiple WBO2 sensor inputs?

This would be nice on a boosted engine for each cylinder except that you can't use them under pressure like that. Is it worthwhile blocking your ports with a sensor when NA, probably not. Boosted use one or two wbo2 and a set of EGT to ensure the cyl flows are even. The best solution is to design the manifolds and fuel rails etc well so you don't have uneven flow issues. There are two for V/flat engines included already. (not used just yet though, but loggable)

I need 2 for my application as i have 2 x 3 into 1 headers.

Programmable Fuel consumption output calculated from number and duration of squirts, RPM and road speed?

Output to what? In the log should be easy enough to do for sure provided VSS is used.

Output for the On-board Computer and MPG gauge I monitor this closely as it is the first sign of poor running on my engine, bear in mind my car is my daily driver I want to get the best MPG i can on the mundane commuting through the week but out right performance on the odd occasion when boot meets mat! I have all these signals at the ECU connector and want to use them if they are there. what can i say i'm a fussy git!

[Delta]

If the computer can output L/100kms instant fuel use etc etc, Freegauge will be able to display it

[Fred]

My straight 6 has 2 knock sensors, it would be nice to have both of them listening out for potential problems and reeling back the timing should the big bang be imminent!

Fair enough, I guess the question then becomes whether you would expect it to pull timing from different cylinders based on which sensor, and indeed if it is even meaningful to do that in that case. Additionally it seems to me that knock sensing is a backup plan in the first place. Perhaps EVEN on V/flat engines it makes sense to just treat the engine as a whole regardless of which cylinder the signal comes from? If that is the case then it would make the most sense by far to place the signal merging outside the CPU in hardware. I think that is probably the best solution for your setup, but being open source if you disagree the world is your oyster :-)

I need 2 for my application as i have 2 x 3 into 1 headers.

Is this how they come stock? Do they actually read differently? What if you swap the sensors? If they don't come stock like that, why would you not put it after the 2:1 merge? Again, would you expect the controller to pull/add fuel differently for the different sets of cylinders? I think it makes more sense in this case to do that. I'd be surprised if an M50/M52 would flow that differently along it's length though.

Output for the On-board Computer and MPG gauge I monitor this closely as it is the first sign of poor running on my engine, bear in mind my car is my daily driver I want to get the best MPG i can on the mundane commuting through the week but out right performance on the odd occasion when boot meets mat! I have all these signals at the ECU connector and want to use them if they are there. what can i say i'm a fussy git!

I'm still not certain that I know what you mean. By on board computer do you mean there is a separate MCU on board for doing auxiliary stuff like gauges etc? If so, what sort of format does it take data in? Over what physical medium?

Fred.

[davebmw]

Fair enough, I guess the question then becomes whether you would expect it to pull timing from different cylinders based on which sensor, and indeed if it is even meaningful to do that in that case. Additionally it seems to me that knock sensing is a backup plan in the first place. Perhaps EVEN on V/flat engines it makes sense to just treat the engine as a whole regardless of which cylinder the signal comes from? If that is the case then it would make the most sense by far to place the signal merging outside the CPU in hardware. I think that is probably the best solution for your setup, but being open source if you disagree the world is your oyster
Using the 2 knock sensors I suppose will allow for greater sensitivity, because after all it is a big old block! I would think that when the knock threshold is detected the whole timing table gets offset back by predefined amount. there probably is no point in detecting the exact combustion characteristics per cylinder thats just asking for over complication.


Is this how they come stock? Do they actually read differently? What if you swap the sensors? If they don't come stock like that, why would you not put it after the 2:1 merge? Again, would you expect the controller to pull/add fuel differently for the different sets of cylinders? I think it makes more sense in this case to do that. I'd be surprised if an M50/M52 would flow that differently along it's length though.

No, as stock the 2 cast iron 3 port headers flow down 2 down pipes into 1 pipe just before the cat at that merging point the stock NBO2 sensor sits sampling the gas pulses. The pipes splint into 2 again and into the 2 cats and out the arse end.
My setup is slightly different as i have 2 stainless 3 into 1 headers that don't meet anywhere, so I have 2 sensors 1 for bank 1 to 3 and the other for 4 to 6 at the moment i can only sense from one bank which i fear wouldn't give a true reading.

I'm still not certain that I know what you mean. By on board computer do you mean there is a separate MCU on board for doing auxiliary stuff like gauges etc? If so, what sort of format does it take data in? Over what physical medium?

BMW's have an on board computer for MPG distance time external temp that sort of thing as well as an analogue gauge on the instrument cluster to display instant MPG's. this signal is provided by the stock Bosch ECU i think is PWM along the stock harness.

[Fred]

Well, for the wideband, the thing to do would be just log the extra channel in to see what it's actually doing first. You could configure it as a V6 for closed loop control if/when we get to coding that in. I doubt it will be significantly different though, but I guess it could be. If it is an M50/52 the plastic manifolds have the intake pointing straight at cylinders 3 and 4 thereby giving them a slight charging effect, but that isn't a difference across two banks, its a difference from two cylinders to the rest (possibly one in each bank).

You will probably be wanting to measure that PWM signal and watch it on a scope to ensure it's not digital in some way. Once you determine what sort of duty = what sort of mpg / lpkm you will be in a better position to judge whether 8 bit PWM is enough, or you need 16. Additionally, depending on your tacho requirements you could reuse the modulus down counter to supply an almost unlimited resolution PWM signal.

[MotoFab]

An interesting idea, but one that will only mask bugs IMO. I think if something gets out of place this needs to be obvious and quickly found and fixed.

The practice isn't for the code per se, it's for the processor chip and hardware. The CMOS gates in the processor can change state for myriad reasons other that errant code.

If you are interested in using it to catch bugs, it can be used for that too. The code in the housekeeping section is set up to compare the 'constants' in the housekeeping section, with their matching registers. If something doesn't match, it's possible to know which constant didn't match up with it's physical CMOS counterpart. The 'physical errors' say, can be categorized into critical or non critical for instance. Particular critical errors might need to trigger a controlled safe shutdown.

During development you can just log the error, or set it up to trigger an interrupt, or something.

Two other common ruggedizing techniques that have a use here:
'call counting': Set up a register and increment it as the first instruction of each called routine. Then decrement the register as the first instruction after the return to the main code. At certain points in the main loop check that 'call count' register for the appropriate value. Maybe log the event, or take some fail safe action, depending on where in the main code the register shown the wrong value.

'lost program watchdog timer reset': Loosely described as filling each line in the unused portion of the program code space with a call to an endless loop somewhere. That endless loop will trip the watchdog timer and cause a reset. But you can get creative with it too and do other things. Capture the state of the output registers and force a return to re-initialize and then to the main loop for example. That may even happen without the user knowing it.

- Jim

Edit: Often some pieces of the ruggedizing code are written in assembly, so the user knows exactly what they're getting.