freeSim firmware: Suggestions, requests and feedback thread

[ababkin]

Hi all

This thread is for discussing freeSim firmware
(original freeSim firmware document presented here: http://www.diyefi.org/forum/viewtopic.php?f=4&t=60)

Thank you
Alex

[AbeFM]

A protocol of continuous-only change in real-time RPM between freeEMS software and hardware interface to the EMS will have to be developed, to implicitly avoid a physically implausible case of instant change in RPM (i.e inertial must always be present in the reciprocating mass of the simulated engine). As an example of such a protocol, instead of setting the RPM value directly, the software would pass the rate of change of the RPM in respect to time (potentially in variety of orders, i.e linear factor, quadratic factor, etc)

Oh, awesome, I'll have to read up more about this!

I do have a comment though, one I wish I were less familiar with: real sensors malfunction, miss a pulse, pick up noise, etc. The ability to move a tooth, add or subtract a tooth, or other "noise" would be very good for testing how the EMS deals with these real-world events.

I have lots of logs where the RPM drops to 0 from 5500 rpm for a single point: the car bucks violently, backfires, etc. Clearly in a situation like this you want to run smoothly and log/note the error.

The other issue that is very common with hall effect sensors is to have one unreliable edge, generally at low rpm/voltage. Probably more trouble than it's worth to simulate that (though the logic isn't hard), but the missing tooth/extra tooth would be a very nice feature.

[Fred]

I agree that error handling should be as benign as possible. Having said that, it might be a complex thing to try to achieve. You not only have to notice the issue, you have to interpret it and act accordingly. Acting the wrong way and firing a coil could destroy a boosted motor in a heartbeat so care is needed and dropping the ball/starting over is a better approach that a cracked piston from "trying to carry on".

I suggested the same sort of thing noise injection wise, this is the embodiment of it (which you obviously missed) :

- Ability to add various controlled amounts of noise, distortions or delays to the signals, to test the input signal resilience of the EMS

Fred.

[ababkin]

I agree that error handling should be as benign as possible. Having said that, it might be a complex thing to try to achieve. You not only have to notice the issue, you have to interpret it and act accordingly. Acting the wrong way and firing a coil could destroy a boosted motor in a heartbeat so care is needed and dropping the ball/starting over is a better approach that a cracked piston from "trying to carry on".

I suggested the same sort of thing noise injection wise, this is the embodiment of it (which you obviously missed) :

- Ability to add various controlled amounts of noise, distortions or delays to the signals, to test the input signal resilience of the EMS

Fred.

Please elaborate on the injection noise, i'll happily add it but i need to understand the phenomenae first

What do you mean by "error handling should be as benign as possible"?

[Fred]

I meant that when you lose syncronisation with the RPM/engine position input signal, the effects on the engine and vehicle should be A as harmless as possible B as subtle as possible (hard to notice).

A requires removing all fuel and ignition anytime anything is at all "suss"
B requires leaving as much fuel and ignition in place as possible and a lot more CPU cycles to ensure that leaving it firing is safe to do.

It won't be easy, and it may not be possible, but we will try :-)

Fred.

[ababkin]

Yes, i am absolutely with you on minimizing the harmfull effects of input noise (i.e creating smart safety nets, etc perhaps even risk estimation and dealing with it statistically)

[AbeFM]

Sure, but two seperate problems. Here I'm talking about making the freeSim as demanding as possible on the ECU. Then it's another thread's problem what to do about it. But to test how the motor reacts, it would be better to simulate it and discover you would have blown a motor than to test is on the car. On my car.

What I meant about adding noise is to add extra pulses where they don't belong, in a controlled fashion (or remove them, or move them). Perhaps even change pulse width.

When there's a noisey line, you can miss teeth, or worse still, read a tooth early. My logs on MS-II 'often' show the RPM skyrocket from 5219 rpm to 12,346 RPM, and the car backfires or knocks. My assumption is it sees 90 degrees of crank rotation in 1.25 milliseconds and goes "oh, I guess we're going faster now. Long overdue for that spark, let's see if we can't have it now, chaps.

It's just the sort of thing I want to avoid.

[Fred]

My logs on MS-II 'often' show the RPM skyrocket from 5219 rpm to 12,346 RPM, and the car backfires or knocks. My assumption is it sees 90 degrees of crank rotation in 1.25 milliseconds and goes "oh, I guess we're going faster now. Long overdue for that spark, let's see if we can't have it now, chaps.

OUCH :-( you should be able to specify max acceleration before its assumed to be an error, maybe you can?