1 reply to this topic

[jimmason]

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.


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:  http://www.obdii.com/obdii.html

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.spacesh...p-spaceship.com

[Tom deSabla]

the smugness of the auto mechanic as he told me a couple of years ago that my emissions failed because I "needed a new catalytic converter." Oh he was quite sure about it you know, because the computer couldn't be wrong.

Strangely, after I got somebody else to figure out how to reset the computer so as to get the dash warning light to turn off, I passed that good old emissions test with flying colors. With the all-important warning light off, my bad converter suddenly became good again.