CAN node for pre-1996 Vehicles
 

Speaking of the "ScanGauge." I was wondering if anyone within range had any information that might make it possible to build a device that could efficiently become a virtual OBDII connector point/port in pre-1996 vehicles--thereby allowing the user to connect a ScanGauge type device to it and access a small subset of information normally available.

In other worlds, based on recent experience, I think I can create a suitable device interface for acquiring fuel/distance information. I could also, conceivably, handle the task of building the (CAN) Controller Area network node interface--i.e. meeting the electrical and basic interface specifications for CAN. That part does not seem too hard.

However, once the interface is created, I have no way to know exactly what inquiry messages from the scan gauge would need to be responded to---and the necessary format. So on the off chance that someone has intimate knowledge of the Scangauge message format etc, and wishes to share it.. I make this inquiry.

That makes the scangauge a very expensive lcd display. Why bother with the obd translation? Just connect whatever you want to monitor to a mpguino hybrid using the analog ports and display it.

Yes, it does make it more expensive. Besides the technical challenge/enjoyment involved, if someone already owned a "ScanGauge" for one vehicle, it would be nice be able to use it (more) universally. In other words, in our family we have one ScanGauge-capable vehicle, and two which are not. At any rate, I am only thinking about it-for now.

LOL, For the price of one sg you could put mpguinos in all three cars :) The injector monitoring approach is typically more accurate than obd solutions.

I think there is a version of the megasquirt that has obd, but if you can build a megasquirt, you can modify that to display mpg on something (like a $15 serial lcd).

But take a look at the obduino, http://ecomodder.com/forum/showthrea...auge-2702.html , it is a mpguino like self contained computer (atmega and an lcd and some buttons) that can read some obd protocols. You can see what pids it uses to determine mpg, as well as the messaging details.

"Well... you see--- i am new to these parts." So, any "unbiased" opinion/information I receive could be useful. Does anyone know exactly how many SGs have been sold?

I am merely stating the bleeding obvious from much experience. The obd market is for people who don't like tapping wires on their car, your adapter would require them to do just that. Nothing biased about it, this is a half baked idea. Have fun.

Well thanks for your feedback. I am encouraged.

c'mon now, put your mad skills to some good use :)

You know there has to be something that people need, how about a diy efie? That intercepts a narrow bandwith o2 sensor and adds a user controlled delay to lean out the mixture (based on conditions, could even leverage obd for all the sensor values if needed)? maybe with injector pulse feedback or somethin?

I dunno, just trying to think of something that might have a demand and be productive.

Not much diy in the fine tuned water/methanol injection department either.

An although we have diy mpg gauge out the yang, there are some useful features that no-one has sorted out yet:
two that come to mind are cDA computing and determining the most efficient acceleration curve.

You have given me an idea, We should probably start a diy wishlist.

Well yes.. the future usefulness of this approach does not preclude reading any of about four (scaled) analog parameters from the vehicle--and relaying the values back to the host computer. While it does NOT currently have analog output capacity--- that could be rectified. Those analog inputs could also be used to interface with accelerometers---devices that might supply useful parameters for the "arithmetic" you suggest.

accelerometers are nice, but I would start with the vehicle speed sensor as it is far more accurate, and (I think) we are mostly about cheap here :)

Well yes--that is generally true, However, the type of sensor I refer to costs less than $15--- but oftering +2/-2 gs in increments of about 0.003 gs/bit(10 bit a/d) In my exprience, to fully appreciate subtle changes in velocity influenced by other physical force (air pressure or rolling friction) tends to require data acquisition times at least 10-100 times faster then sampling the VSS.

Using both vss and accelerometer might be the most robust actually. Either one by themselves would have no way of knowing if you are climbing a hill or being affected by wind (though you need a wind sensor for that one).

The vss is a little chunky, but pretty accurate, since it is limited by your CPUs ability to measure time (i.e. within a few microseconds). If it is your typical 'murrican car with 5000 pulses per mile then @60mph, if you can measure 10us, then you will get 83 samples per second where each sample is accurate to 1 part in 1200, slower = more accuracy but lower sample rate.

You are right about the VSS's utilty. I would not discount the VSS's usefulness at all. In the first version of the VID, I spent processor time measuring VSS pulse width etc--but only to within the nearest 250 microsecond. The new version, just counts pulses over a fixed period of time. Given the time interval i use, this naturally can result in slower response to non-average velocity conditions. But till now--this was good enough. The addition of a two or three axis accelerometers. would serve to augment the VSS--- not replace it.. And, it would be cpu time intensive-- to make multiple measurements and integrate fps/s to fps would take CPU resources. Because when you think about it, the VSS is doing most of the work.(most of the time--anyway)... it is more than adequate for simple fuel meter applications. My VSS gives about 4000 PPM. At 60 MPH that is about 66 counts per second (1.1 % error)--or about 15 millisecond period. My basic clock is current set to (a slow) 125 microseconds--so 15 ms resolves to an even 120 counts. So--yes i agree.. VSS is GOOD.

I do understand why this would be good

Better diagnosis on older engines + some people want the simplicity of plug and play
(and lots of times, those are the people you need to persuade to get better mileage)


The downside of course would be money, time and effort

Yes, this might be the closest to Plug-n-Play old cars can get.

It isn't plug and play if you have to hook up a bunch of wires. All my mpguinos have the same plug and I can move them from car to car easily, or even connect multiple with a simple 4 conductor Y adapter, but the matching plug had to be installed first.

You are correct again. Plug and play it is not. I only said it was as the "closest to Plug-n-Play old cars can get" to that. Obviously, anyone can "rig" up their own custom device and then make it possible to move, for instance, the display unit from car to car-- but I think what the plug-play poster meant, was that IF such a standardized interface existed, it would be more "LIKE" the plug-n-play scan gauge for newer cars. That having been said, I am painfully aware of the "dangers" of taking something simple and effective, and making it complicated-----purely in the name of technological elegance. I am just as cognizant that one "intended" consequence of the status quo, is by definition, to throw sand in the engine of change.

The great thing about OBD for older cars is the other things you can do with it. There's lots of applications (not just in the ecomodding world) that would find OBD useful. For example, I may be ecomodding my Smart Roadster but I have a track car that doesn't have OBD and would benefit greatly from being able to interface with RaceChrono, which supports logging RPM and otehr parameters via OBD. I'm sure there's many more potential areas of use, too.

Sorry but there is such a gauge, a Vacuum Gauge...

Rich

"Sorry but there is such a gauge, a Vaccum Gauge...

Rich
"

yes of course ,
however
the vacuum gauge has already been invented and in order to use it in the car , you need to run a vacuum line and mount the gauge somewhere ,

but a simple wire from the "load sensor" to a small high impedance voltmeter either analogue or digital samples the signal with the most authority that the ECM / PCM uses for calculating how much fuel to add at almost any given time ,
not counting decel fuel cutoff or clear flood or open loop WOT fuel enrichment conditions ,

better still, but much less simple ;
to just use the calculated load PID in scan data .....
lower is better for fuel economy ....
but most people will not want to have a laptop on the passenger seat as they do most of their driving , and it is awkward and distracting to look to the right seat all the time ...

Typos will be the death of me...

True BUT a vacuum guage does a great job, it shows when you add a little throttle (lower vacuum...) and when you step off (higher) and it can also do some checking and warning of problems in the engine as well...so for a little cost and a lot less work of hanging that meter and hooking up to something and trying to figure out is more voltage a good thing or a bad the vacuum gauge is butt simple low vacuum low mileage...

And there are those great looking piller pods for mouning it and it can look cool.

I have had one in every car I have owner from my 56 Studebaker on....(it was stock in the Stude

Rich