Technical details of the VID and more is now available at the following website:

http://www.riverstoneembedded.zxq.net

June 8, 2010

I see it has been sometime since I last posted here. During that interval a lot has happened. The VID project has spawned from a single minded application to a general appreciation of a number of other environmental (or green) issues. I seems that when I sat down to actually design a PIC based card to formalize that Vehicle Information Device---- I ended up with a system that could (and will) be useful in other areas of energy conservation.

The VID (Vehicle Information Device) application is now simply a PIC based C program that is installed on a general purpose micro controller card. IN fact, the VID application can now be used in several ways depending on the needs of the user. One way is to use the RF features of the boards would be to divide the application between a sender and reciever/display board. The sender card is powered by the vehicle's 12 volt system. It connects directly to the vehicle's fuel injection and speed measurement system While the receiver card is battery powered--allowing the user to place it any in the passenger compartment in a position that is most convenient. While both sender and receiver cards are electrically identical to the other--- the embedded software on this card performs high level functions required to process data coming from the other card via IEEE 802.15.4 radio system. This board interacts between the user and the sender card----sending the user requested information to a LED display mounted near the user. Via the switches mounted on reciever card, the user can request information on the engine economy functions, the electrical system output, and the temperature of both inside and outside of the passenger compartment-- as well as have access to a very precise real time clock mounted on either the sender or receiver card. Given the open design concept of this device--- new devices can be added interface with any foreseeable future need.For example, vehicle handling dynamics can be monitored via accelerators, vehicle position can be computed via GPS add-on devices. This is made possible by a I2c inteface provide on both cards.

The final configuration is really just a matter of what software is installed on the boards(or board). For instance--- if a potential user only wanted one board---but also wanted to be able to receive vehicle information via his PC--- he could opt for bring the Fuel Injector and Vehicle Speed Sensor information into the sender board as before. Expect, that instead of broadcasting the information to the receiver card for display to to the user--he could simply attach the I2C display board to the sender card----and be done with it. The unit would also come with a USB attachment and software for the user's PC. Vehicle information could then be viewed and/or saved to the PC harddisk.

At any rate, this application is but one of many possible applications for RF remote sensing and control type projects.

In fact, the same PIC/RF technology is about to be deployed to create a system of remote controlled thermostats in our home. Since the card was originally designed for the automotive application, it also includes temperature sensing and real-time clock--- it was a natural step to move this device to monitoring and controlling the temperature in each of the (many) rooms in this house. I will get into the technical specifics of this application later-- but in general using these boards will allow us to manage the electrical use during the winter months with the eventual goal of time-sharing KWHs used as alternative heat source to the oil-fired boiler.

With the ability to centrally monitor and up to 10 thermostats distributed throughout the house, the temperature in those areas(zones) can now be optimized for the exact use required--according to the time of day, and the number of people occupying that space. Assuming that the R value factors are in order---- it is now possible to install by each zone, a single 120 vac, 1500 watt electrical heater for use as supplemental heating.

The astute reader would immediately question exactly how potentially 15000 watts of load attached to 120 volt circuits would be useful when having more than one unit on at a given time would likely trip the 15 amp breakers. And so that is the point--- by finding a proper balance point between heater on time (for each zone) and the requested room temperature-----and the heat loss characteristics of this house. it may be possible to keep a large (and largely unoccupied) house such as this from freezing using a round-robin approach to the several 1500 watt heaters--without (immediately) resorting to the use of a 2.5+ gallon/hour oil fired boiler. (I might add-- that we have a 75 KBTU wood stove that is used to handle most of the living space heat requirements during the waking hours.)

In other words, the basic goal is to keep the huge oil fired boiler OFF for as long as possible during the coldest NE nights of the winter. Of course the boiler also constitutes a heating zone of control--the PIC based system can also trigger it into operation when the temperature finally drops below a point where the heaters are not adequate.. However, having a system that would automatically adjust all zones for real-time conditions---just barely keep the unoccupied rooms in this house from freezing without the boiler would save the large cost of developing a head of steam for no particular reason other then to keep pipes from freezing in the outlaying areas of the house.. Of course depending on the load on each 15 amp circuit some heaters on different circuits could be triggered on together--but the general goal is to run each heater for just long enough to satisfy a constantly variable set point and then move on to the next---until the cycle is repeated---perhaps each hour.

So---with a RF networked group of remote sensor/thermostats (each controlling one heater), the hour-by-hour requirements of each zone can be managed from a central-led PC running Windows XP. In addition , each zone station can be set either remotely or at the station to maintain a specific temperature if it receives no countervailing commands from the central thermostate program.


Ok--- I have said enough for now... just in case anyone is reading this-- drop back soon for more details on these cards and the general progress of things.

1993 Accord LX

The old car is back. I finally got it all back together and in road worthy shape. To do it myself turned out to be quite an adventure. I have to admit at one point I had it towed to a place that could deal with a very dysfunctional ball-joint. But other then that "minor" deviation, I completed about $2500 worth or repair work for about 1/5 that amount, and the car rides and runs great. The VID device is now laying loose on the passenger side rug... it reports a nice 34 MPG average during my drives. Apparently the GD front driver side brake rotor has been completely dysfunctional for a long time. While working on the other issues, I think it was pushed into to complete failure.. I finally had to replace everything on the driver's side wheel assembly, except the steering knuckle itself. But that turned out to be very inexpensive---thanks to ebay etc. Along the way,, i also replaced the front coil springs, and the entire exhaust system south of the catalysis converter. At any rate, the only thing remaining on my list--- for long term stability is the timing belt.. I believe with the amount of information I have on this subject, and the tools I have.. it would be feasible to do the job myself. I am however, worried that unforeseen problems might prevent me from getting to the core of the issue. For instance, the engine mount on that side must be removed.. and it is a bear...

Update

If anyone requests information on the original design of the VID, I would be happy to assist them. However, I have sent this over all design back to be repacked. The current VID software and hardware supports most pre-1996 fuel injected automobiles--the functionality of the fuel economy hardware and algorithms are solid. The problems lies in the device mounting and packaging. In my case, the 1993 Honda Accord has a dash mounted clock. I recently removed this item (it was not working).. and realized that building the clock function into the VID and then installing it in the existing clock (footprint--if you will) might be a good way to finally get some use from the device. I have started to select a I2C based Real time clock chip to provide this feature. Now---that I have a I2C bus--- i am adding temperature sensors for both inside and outside the cab.. I am also adding analog monitoring capacity for other things. i.e. battery voltage measurement etc.

Bottom line.. (in case anyone is reading) the VID is going to be redesigned to work with multiple cpus. It will also be configured to run at 20 MHZ (not 8 MHZ) The clock chip will provide the main processor a reliable source of 32.768 KHZ---This means that fuel measurement system accuracy will no longer depend on the cpu's instruction clock and the timer divider, currently used to achieve 125 microsecond measurement granularity. The other feature needed was the addition of non-volatile static ram. The clock chip will provide about 56 bytes of static ram This storage will replace the flash storage currently used. One of the issued uncovered during long term testing was that flash can wear out-- since a some sort of non-switched power will be required for the clock--- it will also keep TRIP and TANK data alive.

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.

Honda Fuel Economy TRIP COMPUTER VID/YAG

I have prepared a brief video of the PC application I used to configure and interact with the Vehicle Information Device--VID.

The video is without narration--but shows the three main tab/screens--- Main, TANK, TRIP. It also shows the dialog used to send configuration information to the device flash memory.Because the device has a dual port option of USB/Serial and Blue Tooth serial, the VID application can actually connect with the device using either of these two methods. In my video, I show the device attached via the USB serial port- In this configuration, the application can send information to the device. Currently, the Blue Tooth interface is receive only.

In the mean time, I finally got the axle nut off from the driver side front wheel yesterday--with the help of my step-son Robert. It seems that no matter what I did alone to feat, pound and turn the axle nut--nothing worked until I was able to devote my full attention to getting the nut hot with the torch and then while rob used a three foot extension 36mm socket/1/2 inch drive, I pounded on the socket and finally it let go.

Now,, I am working to get the lower ball joint nut off. Apparently the last person to take this apart stripped the edges from the nut, so now the only option is to try to drill and destroy the nut with a chisel. I will let you know how this process is going. Oh BTW, the reason I need to take it apart is to replace the left side CV joint/axle.

Honda Mileage Measurement Device Firmware testing update

Today, the good news is that, after thousands of miles of simulated driving, the VID's fuel mileage measurement algorithms prove to be very stable. Indications on both the Blue Tooth and USB serial channels show complete complience with the established beta software testing standards.However, testing has uncovered one firmware bug. It is this type of bug that this test was designed to catch.

From the beginning we've decided not to utilize the floating point libraries available with the development compiler, we have instead gotten around the precision issues associated with using 32 bit unsigned long variables to represent floating point elements by using scaling up (by some factor) any variable that when divided by something else would result in round off errors. To use the floating point libraries too early would needlessly consume memory and processor bandwidth before we determined that we actually needed it. At some point, we may use the libraries but not before we run out of other options.

At any rate, given the wide latitude of using non signed 32 bit words we (thought) were careful to scale everything enough range to cover all possible uses of the variables.

For instance, the variable that stores the accumulated pulses for trip and tank is normally large enough to accommodate a trip of about 500,000 miles before that variable overflows. Similarly, the variable that holds the [accumulated gallons used] would handle 100,000 gallons before it overflowed. The accumatged gallons used variable is pre-scaled by a factor of 10000. i.e. 1 gallons is stored as 10000.

However, as we found out, while the variables are large enough to accumulate the specified range, certain functions used to convert accumulated pulses to accumulated miles, can overflow because of additional scaling used to avoid round off errors in these calculations.

This problem was noticed only once the trip and tank miles exceeded 1050 miles. A simple check of the process used to compute these numbers showed that pre-multiplying the accumulated pulses by 1000 to avoid round off errors, actually resulted in an overflow condition in a local unsigned long variable.

After following the general rule of THREES-- that is finding at least three ways to do something in embedded code, I have finally linked in the floating point libraries that came with this development system. As I eluded to a few paragraphes ago, falling back on the floating point libreies too early in the process would not have been the right thing to do. However, now that we are almost done-- with a lot of flash memory availabe-- it would be just as wrong not to include them now.

So.. without having to worry (so much) about the range of variables--- the device outputs the correct MPG to both the BCD display and the devices connected via the serial port(s).