Update

It has been a while since I last posted to this blog. During that time, VID (Yet another gauge) testing has continued off and on. When the test reached about 10,000 miles the Microchip F182520 failed to accept flash programming and had to be replaced. The only thing I can relate this to is the fact that I was updating internal flash memory at a rate that "might" have exceeded the specification for read/write cycles. At any rate, the on board flash is now NOT updated unless it is absolutely necessary to do so. This should ensure a long useful product life.


Because this project is moving toward a static point, I will soon release as open source all of the software source code for this project. I will also make available any and all information on BOM list and electronic schematics. I would enjoy seeing what improvements others might make on this device and associated software. Again, if anyone wishes to just build the hardware, and receive a preprogrammed controller chip from me, that might also be arranged.

So say tuned. As for open source Linux fans, the laptop client application (host) runs equally well under Ubuntu, as it does Windows. There is also a version of the application that is capable of running on Pocket PC type devices. I believe previous blog posts have documented all of these possibilities.

Because I will soon be on the road traveling to remote customer sites for software contract work, I plan to have the opportunity to set up the VID on the old Honda Accord. This should make possible to supply periodic posts on exactly how the device is helping save me fuel---- and money.

While feedback on the existing VID is/was lacking, I have received several messages regarding my comment that perhaps a CAM style interface for the VID would facilitate the use of commercial devices front ends (Scan Gauge) for user readout. Obviously cars made before 1996 have no existing infrastructure for using any type of diagnostics readout device. It occurred to me (as it did others) that by building a relatively simple CAM node device and wiring the fuel injector inputs, VSS sensors, and varous analog signals from the vehicle to the its ( CAN node) inputs would allow someone with OBDII devices to monitor these values. Some feedback has suggested as much.

Building upon what I've already done, the actual task of building the NODE is not as challenging as being able to structure the data in a format that Scan Gauge would accept as valid information. It means having a some knowledge of exactly what information is derived directly from the vehicle and what information is inferred/computed from these readings. With this knowledge, the designer of the CAN information tables could arrange things in a way the OBDII device would like to see it. This means knowing exactly the CAN_ID for each of the required data elements. Using a u Processor with sufficient memory resources to interface with a dedicated CAN chip is one why to do this. The other way is to use a u Processor that has CAN facilities built in. Either way, there would be some interesting challenges to surmount--even with copious amounts of open source support software that currently exists.