[Gasification] OBD-II extension for gasifier self-diagnosis and "phone home" fixing

Tue Dec 28 00:34:29 CST 2010

below is an interesting note from the wood gas list exploring the
difference between obd-I and obd-II vehicle computer systems.  reading
this i see the odb II type systems are what we've been stepping
towards inhouse with the power pallet system, not really knowing about
the proper prior art.  we should likely study the vehicular systems
more closely and learn something.  there also might be some potential
for collaboration between many in the field to develop such an "OBD
type" system or extension dedicated to gasifiers.  many of us are
looking at electronic automation systems and some standardization
and/or interoperability might be useful.

our goal with the pp electronics is not only to fully automate all
engine gasifier parameters, but to also enable self-diagnosis and
off-site fixing.  tele mechanics, as it were.  gasifier expertise is
the rare commodity here we're finding.  the more we can put the
expertise in the electronics that automate running, and the more we
can diganose and fix from a distance, the lower we can likely make the
hurdle to end users.  electronics are expensive to develop, but near
free once done and replicated in number.  this is why we put them in
near everything at this point.  onboard brains can do many things that
mechanics cannot.

adding to this, we see that connectivity is becoming near universal.
premising onsite support via mobile phone or wifi connectivity seems
not impossible at this point.  of course you can put much of this on a
screen onsite, but some things always seem to rise to the level of
offsite support being needed.

a self-diagnosing system that can "phones home" its state is quite
similar to what is now happening with vehicular computers and
emissions testing.  current vehicle computers store all sorts of data
and run self-tests on the vehicle that is simply downloaded at the
time of smog test.  same thing for maintenance and fixing.  the
computer has already logged and tested many system states and can
usually tell you what is wrong without a dedicated test.  the systems
not only log, but run proactive system tests and component cyclings to
establish component condition.

this even goes for instruments.  with a full system map, you can
locate instrument failures when single readings are out of congruence
with other readings in the system.  this even allows the elimination
of some "single point" sensors, and instead calculate a specific point
reading by known states elsewhere in the system.  i think these are
called "phantom sensors".  working with a many point mapping, single
point instrument failures don't give false readings or tank the
system.

anyways, i'm realizing that what we're trying to do on the power
pallet is what has already been done for autos.   there are likely
things to learn from these systems.  we should look at their specifics
in more detail at some point.  tom visel has suggested starting here:
[url]http://www.obdii.com/obdii.html[/url]

OBD-II is an international govt standard, that different manufacturers
have adopted and extended.  there are now common readers that diy
tuners use to diagnose and fix things.  could we leverage these for
gasifier diagnosis?

maybe we might want to consider working within OBD-II for a gasifier
self-testing and diagnosis system.  maybe it is an architecture we
could expand and extent for our purposes.  or maybe just its structure
and methods are relevant to consider for us in building our own.

-----------------------------------------------------------

All,

Another part of OBD-II, and the part that lets inspection stations be
lazy, is its self-testing ability. Besides doing the aforementioned
sensor-out-of-range style of checking that OBD-I did, it does
rationality checks, e.g. "is my throttle position sensor in a normal
range for this engine speed, road speed and load?" sort of checking. It
also checks oxygen sensors (the ones before the catalysts) for
performance - not just for giving a signal - and it checks the
catalysts' oxygen-storing capability by comparing the rich/lean
switching rates of the up- and downstream catalysts. Lastly, it keeps
track of all the system tests it has performed; these are called
monitors. All the inspector has to do is ensure that all monitors have
run and passed, and s/he can pass the vehicle.

The thing that sinks the whole idea of erasing the keep-alive memory,
supposing you had a car with a computer that allowed you to do this, is
that it would cause the monitors to be reset as well. Despite the lack
of codes, the inspector would still flunk your car or tell you to come
back after driving it for a while, because the car tests itself and the
inspector is only the messenger (in most places.)

Rob,
What kind of codes was your LPG conversion tripping? perhaps I can
assist - email me off-list.

HTH,
TomV

how to learn about obd2

It's not super in-depth, but http://www.obdii.com/obdii.html has a
decent description of many aspects of OBD-II. I'm sure there's more out
there for the finding, and Google is your friend. I got most of my
knowledge either hands-on or in clinics and classes.

FWIW, OBD-II was a government-mandated specification that was rather
broad, leading to variations in implementation from manufacturer to
manufacturer. It does not specify PCM type or location, for instance,
but it does specify standards for self-testing quality, misfire
tolerance, location of the diagnostic connector, a format for diagnostic
codes (DTCs) and standardization of nomenclature encompassing all
manufacturers. For instance, whether dealing with a VW, Honda, or Chevy,
the sensor that tells coolant temperature is always the ECT (engine
coolant temperature) sensor, and a P0302 always means a misfire on
cylinder #2.

HTH,
TomV

DTC information can be found at the link in my last post, or at any of a
number of sites that googling for "obd2 dtc" would bring to your
screen. Additionally, it is a good idea to search for the code and the
vehicle in question, like this: "P0440 dodge ram 4.7".

There is so much to know that it is not practical to try - even guys
like myself who do it for a living only know a few by heart, and we
still check for car-specific oddities when something seems out of the
ordinary. If you don't know what is ordinary, it's a good idea to check
all the time.

If you are modifying an EFI vehicle, be it OBD-I (83-95) or OBD-II, it
is a good idea to have a scan tool that can read "serial data" (engine
parameters,) and not just DTCs. This way, you can watch fuel trim in
real time - both long and short term fuel trim, for both banks of your
engine if it is a V6 or V8. It also lets you see problems as they
develop, for instance if your intake ducting is causing the mass air
flow sensor to give a funky reading or if your idle speed control is
maxed out because your throttle plate is gunked up. It is akin to
watching the game as the coach, rather than catching the highlight
reel. Such scanners don't have to cost much - I think the one I carry
in my truck cost $200 and will do OBD-I and OBD-II vehicles. Harbor
Freight is your friend here.

HTH,
TomV

-- 
------------------------------------------------------------------------------
Jim Mason
Website: http://www.whatiamupto.com
Current Projects:
   - Gasifier Experimenters Kit (the GEK): http://www.gekgasifier.com
   - Escape from Berkeley alt fuels vehicle race: www.escapefromberkeley.com
   - ALL Power Labs on Twitter: http://twitter.com/allpowerlabs
   - Shipyard Announce list:
http://lists.spaceship.com/listinfo.cgi/icp-spaceship.com

-- 
------------------------------------------------------------------------------
Jim Mason
Website: http://www.whatiamupto.com
Current Projects:
   - Gasifier Experimenters Kit (the GEK): http://www.gekgasifier.com
   - Escape from Berkeley alt fuels vehicle race: www.escapefromberkeley.com
   - ALL Power Labs on Twitter: http://twitter.com/allpowerlabs
   - Shipyard Announce list:
http://lists.spaceship.com/listinfo.cgi/icp-spaceship.com