freeeSim: Free Engine Simulator

[ababkin]

freeeSim: Free Engine Simulator
... now with sourceforge.net presence: http://sourceforge.net/projects/freeesim

!!! Please don't post in this thread !!!
... but feel free to have a discussion about freeeSim over here

!!! freeeSim project NEEDS YOU !!!
Currently the project is looking for your ideas and feedback on the existing documentation. Please post them here.

This thread will be an attempt at documenting the effort to create a hard/firm/software combo (referred to as freeeSim) for testing/validation/ or just plain playing around with pretty much any kind of EMS including but not limited to the freeEMS.

The big idea:
The concept is supposed to be a reasonably complete test-bed, substituting the actual car/engine/sensors/etc, for alpha testing of the initial implementation of an EMS as well as the implementation of further new features or other modifications.

Why is having a good 'test bed' a good idea?:
The 'test bed' does not only allow a convenience of testing things at home in comfort of your favorite armchair, but also allows to operate with multitudes of possible input/output states seamlessly, not to mention alleviating the risks of damaging the engine and associated hardware.

Similar devices:
The two devices somewhat similar in essential functionality to freeeSim are B&G's Stimulator and JimStim. Both of those great devices are quite affordable, easy to assemble/use and rugged, due to their simplicity. freeSim, however, is conceived to go an extra mile in complexity to achieve more ambitious goals.

HW ideas:
Note: using MS hardware for freeeSim is NOT decided upon yet and just a consideration at this time
It would be convenient to leverage the existing and available micro-controller-based hardware, such as MS v.3 board with the MS2 daughter board, or just a MS2 daughter board on a proto board.

HW Interface:
The interface will consist of digital/pwm/analog inputs/outputs as well as possibly some sort of air pressure interface solution for the MAP. (such direct MAP interface would be quite ambitious, so, for starters, an analog electric output will do just fine, bypassing the actual air pressure transducer).
The analog outputs will be implemented using PWM+low pass filters OR digi-pots as cheap DAC solution.
The interface with a PC, which will be running the control software, will be over a regular serial port.

Firmware
Will be written from scratch (with help of free examples available on the internet). The freeeSim firmware source is be available under the GPL.
The firmware will essentially be a 'smart' pass-through between the software (on PC end) to the hardware (on EMS end). An example of this 'smartness' would be firmware's ability to query the PC side software for a crank wheel teeth pattern, then 'playing' this pattern accurately using internal timers, through the output tach signal to the EMS.
Read more about the firmware here

Software
Will be simple, at first, dashboard of various controls to manipulate (primitively at first) the engine simulation parameters. Source will be available under the GPL.

Why bother with this and not just get a JimStim?
The freeeSim, once its essentials are implemented, will open up few avenues of abilities that would not be possible with simple simulators like JimStim.
Few examples:
- Repeatability of scenarios: one would be able to define some outputs-value-change sequence scenario, then replay it verbatim many times (this need may arise while analysing the correctness of the EMS operation and tweaking EMS's firm/hardware to react adequately to a particular scenario)
- Ability to define and execute some physical models, which would enable freeeSim to 'act' like an approximation to a real live engine. i.e the inputs would actually affect the outputs of the freeeSim much like, for example, fuel injector pulse width (freeeSim input, EMS output) would affect rpm, MAP,etc (freeeSim outputs, EMS sensor inputs) in a real running engine.
- Ability to add various controlled amounts of noise, distortions or delays to the signals, to test the input signal resilience of the EMS
- Defining and monitoring for undesirable/dangerous states that the 'EMS under test' may put the system into. (for example transient lean conditions during high-rpm/high-load)




freeeSim Credits and Thanks
Fred Cooke:
- chip/module suggestions
- practical uses suggestions

[to be continued...]

[ababkin]

Hardware interface analysis (EMS side)



Outputs:

Tach signals:
- crank sensor
- cam sensor (secondary tach, may be multiple with independently changing phases as is the case on newer bmw engines with double vanos)
- speed sensor ("a nice to have", manufacturer specific)

Requirements:
- Compatible with as many VR and Hall-effect sensors inputs as possible.
- Maximum temporal accuracy

Proposed implementation:
- For starters, it will be a simple (buffered? protected?) pass-through of one of the freeeSim's digital output bit to one of the freeEMS's hardware interrupted inputs, bypassing the filtering circuitry on the EMS.

Questions to answer/research:
- If implemented with timer+bitbang, what timer resolution is sufficient? (for such usages as: just crank, crank+fixed cam, crank+variable phase cam)
- What circuitry to apply to a regular MCU output to generate a tach signal appropriate for the use?




Time/acuracy-critical analog:

- NBO/WBO
- MAP/MAF (needs to be time critical?)

Requirements:
- Maximum signal voltage range: 0-5V

Proposed implementation:
- PWM + low pass. (Ensure low-noise/noise-free signal)
- DAC (+ sample-and-hold if needed to demultiplex)
- digipot + bias resistors

Questions to answer/research:
- What PWM frequency would be appropriate for the task?




Non-time/accuracy-critical analog:

- MAT
- CLT
- TPS (may be an input for both the Sim and the EMS hooked up to a user manipulator to simulate the accelerator pedal)

Requirements:
- Reasonably fast response (in millisecond range?)
- Resistance driven (TPS can be voltage source driven on some)

Proposed implementation:
Use digital pots driven over SPI (or alike)

Questions to answer/research:




Battery voltage simulation:
- (digitally?) regulated voltage voltage to power the EMS under test

Requirements:
- Power supply with appropriate voltage/current range for the regulation

Proposed implementation:
- Fast acting, digitally driven voltage regulated power supply.

Questions to answer/research:
- SPI too slow for the task?





Inputs:

digital, time critical, proper load/induction simulated:
- injectors (pulse width)
- coils (dwell, advance)

implementation:
- for starters, create a passthrough from the EMS's logic level outputs for spark/injectors directly (buffered? protected?) to the freeeSim's interruptable inputs. Some interrupt multiplexing scheme will need to be devised as there is only 1 (2?) hw interruptable inputs.

implementation ideas: Use a PC based logic/signal analyzer to log these signlas against the tach signals generated by freeeSim. Them perform automated analysis on the logged data. This can be turned into a fully capable automated testing infrastructure for hard/firmware testing during the development cycle (to eliminate regressions, quality control, etc).


digital, non-time-critical:
- single vanos (bmw specific)
- fuel pump

PWM, not time-critical: (implemented with a low-pass filter + ADC to determine the duty cycle)
- double vanos (bmw specific, also VVT, other variable cam angle / valve lift mechanisms)
- ICV

Auxiliary:
- Check engine light (EMS goes in 'limp home' mode)

[ababkin]

Hardware circuits and components

Shift-registers: (for non-time-critical digital inputs and outputs)
for example this cheap unit
or this one suggested by Fred earlier.

External PWM driver:
This Maxim unit also suggested by Fred.

Digital pots:
A local friend of mine (big thanks Mark) had suggested using cheap digital pots (something like these) for non-time/resolution-critical analog outputs like temperature.

[ababkin]

References

FPGA based oscilloscopes (to be used for EMS outputs signals analysis):

http://uvasux.googlepages.com/simplelogicanalyser

http://www.sump.org/projects/analyzer/

http://ece-www.colorado.edu/~ecen4610/e ... EC_CDR.ppt