PC warz or EFI_332 Not

[Robert Harris]

SET HTML=SUCKS
SET DIGEST MODE=TRUE
SET GRIN MODE=ON
SET TREE PISSING=NOT

In a world dominated by techno-dweebs whose massive enlightenment of PC
things consists of a subscription to PC magazine, I simply wished to raise
the bar to the point of limiting the discussion to those who actually have a
clue.  Fred and I have little true differences and the discussion brings out
more options.

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.

Next on to laptops.  A used laptop can be either as a controller type
computer or viewed as a cheap bundle of parts to embed.  A 486 with good
disk, memory and 640 x 480 display can be had for around 500 bucks most any
time.  This neatly and cheaply overcomes the 12 VDC (most have adapters)
problem, the drivers problem and the video problem.

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).

In the real world, many computers come up and are left on forever,
eliminating the boot up and set up problem.  If you simply let it boot up
the first time, go through diagnostics etc. and can accept that it might
take a few moments, especially if you have got some neat stuff loading, and
then go into the "sleep" mode, it will instantly come up every time you turn
the key on. The draw is about what the cute digital clock on your dash costs
you.  This time then becomes like tune up time.  You don't set the points
and timing and tweak the carb before you put it in drive (old timey stuff)
do you?  No - so don't reboot the computer every time you turn the key on.

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.

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.

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.

Incorporating the thread I started about ionization, another PIC could also
detect the knock and save that data for export and perform a temporary
correction. This one has to be half smart and communicate directly with the
spark controller.

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.

Resist the temptation to include more and more into a single unit - you soon
begin to re-invent EFI_332.  Their goals and plans are much more ambitious
than this simple controller concept and if you want to do a lot more, don't
re-invent the wheel - go with them.

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.

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.