PC warz or EFI_332 Not

[Matthew B. Watts]

>My dislike of the PC104 comes from actual experience.  On my last project at
>a major aerospace company, they chose to use a brand x PC104 system for
>development.  It was not overlay lab friendly and was a real PIA since we
>had to send them back several times for repairs. If it had been a PC, we
>could have damn near bought a new one for what they charged for a repair.


I've had a similar experience using one of these for a job at Lockheed.
The idea sounded good until we were dead in the water waiting for the
box to come back from repair.

>The amateur radio types have a pedestal mount for radios that could be used
>to mount it on the central console, flipping up the display when needed and
>to access the keyboard.  Of course, if you chose not to use the display
>except for diagnostics etc., it could be mounted under the seat. No matter
>what computer you use, it should wind up in the drivers compartment instead
>of under the "bonnet" because of heat, electrical noise (spark plugs
>generate an electrical fire storm no matter what the resistance wire
>manufactures say).


Get some good cabling to route everything through the firewall and
let the unit ride by your side.

>On to real time.  No experience firing a plug - but imagine its like firing
>and controlling a missile.  It has to happen "rat now", not when the
>computer gets around to it.  The bigger and more powerful a system gets, the
>harder it becomes to do things "rat now".  One very common way is to build a
>semi-stupid piece of hardware that does the real time thing and then use the
>smarts to control the parameters the semi-stupid thing uses to do its real
>time thing.


Exactly right.  There is very little room for error on this on.

>Building a simple board to control the injectors would not be a major
>undertaking.  A small memory could save the parameters for the pulse widths.
>A table of 256 entries for each injector would give a wide range of control.
>A PIC looks at the where am I in rotation, determines which injector to
>fire, looks up the injector in memory using the INJECTOR ENTRY NUMBER for
>the current pulse width and fires the injector.  No biggy.


I burned a CPLD chip to do exactly this.  Takes a lot of the time critical
work away from the CPU.

>Do something similar for the spark. The PIC looks at where am I in rotation,
>which plug to fire, what rpm am I at, and looks up the advance using the
>SPARK ENTRY NUMBER and fires the plug. It makes available the RPM to the
>Laptop.  It could also export the where I am in rotation to the injector
>controller - simplifying it also.  Two versions - one for distributors and
>one for individual coils.


Make something fairly generic with delay registers that can handle both
spark and fuel; that is dedicated to nothing else but getting events to
happen on time, every time.  Then pump the signals into the particular
output driver, and you're half the way done.

>The Laptop or other computer non real time looks at RPM, KNOCK, throttle
>position, temperature, gear, altitude etc. yada yada yada  and re-calculates
>the SPARK ENTRY NUMBER and INJECTOR ENTRY NUMBER to use and
> sends it to the spark and injector controller. It also does a slow background
> algorithm taking full advantage of time and disk space and re-calculates the
> tables for the PIC's, updating them as needed.
>
>What you have now is basically offloaded the real time work to two (maybe
>three) simple controllers that essentially are stupid, and can do any weird
>and wonderful control algorithms you want in either a  small dedicated
>controller or a laptop or both.  It does not need to be real real time, just
>quick.


This is the modular approach and will save you tons of frustration down the
road.  Get the small pieces working and integrate them into a complete unit.

>By intelligently guessing at the table entry numbers (Injector is for
>calibration and cylinder to cylinder correction, spark is similar), the
>initial setting could be very close.  Then use a converging algorithm using
>knock and EGO and we quickly get a self tuning engine.


After some time, your limp home mode will become your fully tuned
mode and you'll have something to be proud of, maybe even willing
to share with the rest of us.

>By using a modular approach, you could start with a standard EGO, MAP etc.
>and by simply replacing a module, upgrade to whatever.
>
>This is the concept I meant when I mentioned distributed processing based on
>PICS.  In the car, it will be controlled by a laptop - in my RV by a
>desktop.  Using the best of both worlds.


The hard part comes when you have all the modules working good and you
decide you'd like to put everything into a single box...

Matt
_______