Running Near Empty

2010-10-22T07:08:00.001-07:00

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

http://www.riverstoneembedded.zxq.net

June 8, 2010

2010-06-09T10:03:00.000-07:00

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

2009-12-05T11:08:00.000-08:00

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

2009-12-05T10:41:00.000-08:00

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

2009-10-25T09:55:00.000-07:00

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

2009-08-18T06:37:00.000-07:00

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

2009-07-30T05:53:00.000-07:00

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).

Honda Mileage Device VID

2009-07-23T12:00:00.000-07:00

This morning I finally implemented the changes required to fully make it possible to programmaticlly alter the fuel injection edge detection levels. I installed a divider resistor on the injector input line. I then wired the output of the CPU reference voltage circuit to pin 7 of the LM339 voltage comparator. Along the way, I had to make a small change in the program. In two places in the code, the program was blocking on [while] loops while waiting for the injector input line to go either high or low. Normally, when the injector comparator levels are set correctly, the resting voltage for the injector is 12 volts. However, if one or the other of the comparator reference voltages do not fall within the proper range, the interrupt line could get stuck in the wrong state--freezing up the program.I, therefore, added code to break out of the while loop after a 2 ms time delay. So, with that fixed, I was able to alter the comparator voltage level (using the setup program) until the the device started to work.

In this image, the scaled injector signal is shown in blue. The CPU voltage reference signal is in red. The voltage scale is 2 volts per unit. The time units is 500 microseconds. Notice, how the voltage reference signal moves to a low value ahead of the falling edge of the scaled injector signal. This shows how the device captures the leading edge of the injector signal.

This image shows the trailing edge of the injector signal. Notice how the voltage reference has assumed a value of around 2.75 volts before the injector signal begins to turn off--then goes low to wait for the next injector pulse. Note: the voltage reference level is capable of being programmed through the entire range of the injector signal swing. In this example, it was set for about 0 volts and 2.75.

Obliviously, this simulated injector signal is derived from a resistor and not an inductor. Had this been a real fuel injector, the (falling) leading edge would have taken almost a millisecond to reach full saturation-- meaning that the falling edge would have followed the characteristic exponent charging curve of an inductor. If this had been a peak-&-hold fuel injector type, it would have reached saturation sooner because it would have been of a lower impedance than saturated types. Once it reached full saturation, the ECU would have then reduced the current flow. The voltage reading at the injector would have responded by moving to a higher resting (2/3 point) level. It would have then remained at this higher plateau for the duration of the pulse, before being turned off completely and going to 12 volts. Obviously,the two step nature of the peak&hold injector presents certain challenges to any measurement circuit.

Therefore, for this particular measurement circuit to work, I decided that the the CPU controlled reference voltage would need to actually track the injector pulse by setting itself at a relatively low value during injector off time, and then moving to a point higher than the injector plateau level ahead of the injector current reduction commanded by the ECU.

Therefore by using the provisions of the 18F2520 programmable internal reference voltage, the user is now able to program the device to track these two levels with two injector comparator constants. For example, in a typical saturated type fuel injector system, the ECU pulls current through each injector by forward biasing an open collector power transistor. This collector is tied to one end of the fuel injector. The other end is ether tied directly to 12 volts, or, to a ballast resistor that is in turned tried to 12 volts. The measurement point for the VID is usually a point common to the open collector of the ECU transistor. If one puts a scope on this point, he would see that the transistor is pulling the line down from 12 volts zero volts each time it fires..
The VID injector input sees this same signal except that due to the input voltage divider it sees a scaled down version of it-i.e the signal now swings from 3.2 down to 0 volts.

The internal voltage reference has 16 possible programmable voltage levels. (0-15) The transfer function is therefore

Vout = ( (4 bit value) / 24) * 5;

low range = 5 * (0x00vref/24) = 0 volts

high range = 5 (0x0Fvref/24) = 3.15 volts

Example 1:

if the desired unscaled voltage threshold for this case is 6 volts and the scaling factor is 4.4 then
the actual scaled voltage is 1.36 volts. To make this happen with a VCC of 5 volts:

(4 bit value) = (1.36vref / 5vcc) * 24
= (6.52)
= (7)

We can program a value of 7 into both constants for the device and all will be well for this saturated type device. Reference_L(ow) and Reference_H(high) would be set to 7.

Example Two:

A peak and hold type injector with an open collector type ECU. For the falling edge, 6 volts might also be adequate so we already know that Reference_L would be set to 7.

The value of the rising edge should be somewhatlower than 12 volts but higher than the highest plateau voltage we could expect to see. For this example, lets use a value of 10 volts.

10 volts / 4.4 scaling factor = 2.27 volts

4 bit binary value = (5vcc/2.27) * 24
= 10.9
ReferenceH = 11

We have now talked about computing comparator levels. But how does the user program different comparator levels into the device? The answer: By using the Windows interface program, the user can now set the two reference levels at the same time he/she sets the Fuel and Distance Constant. In the lower left portion of this dialog box are two entry boxes labeled Reference_L and Reference_H. In this image, they are set for 1 and 10 respectively. The reader may notice that other two entry boxes labeled ECU_type and Timebase. For most vehicles, the ECU_Type will be set to 0. In some rare cases, this could be changed to 1. Setting ECU_type to 1 tells the VID that the vehicle's ECU is pulling the injectors to 12 volts from zero volts, instead of pulling them down to zero volts (from 12 volts) as in most vehicles.Timebase is set to a divider of 1.0. Since the basic time base of the VID is 1 second.. setting time base to 1 sets the VID time base to 1 second. A value of 2 here would set the VID time base to 500 milliseconds.

For information about Fuel and Distance Constants, please refer to an earlier blog entry.

The VID comes programmed with Reference_L and Reference_H programmed with values corresponding to 6 volts. That should satisfy most of the saturated type fuel injector vehicles. However, if it does not, then the user would experiment with these two constants until the VID readings (at idle) make sense.

Honda Mileage Device Regession Testing update.

2009-07-22T12:02:00.000-07:00

The image above shows the Simulated Honda Dashboard connected to the VID as it undergoes bench testing. To the right is the MPH gauge showing 10 mph. To the left is the engine RPM gauge showing about 1400 rpms. In the center are two pointer style gauges showing 10 MPG for both trip and tank. Below, are the odometer style indicators showing miles traveled and gallons used for both tank and trip totals. Note the reset switches are currently cross wireed--so resetting trip-- reset tank instead.

Regression testing of the software changes is going well. The device has run for several days without a repeat of that issue I talked about in the last post. It now seems that the periodic upward variation in injector pulse width and therefore caused by an interrupt synchronization. g issue has been corrected by changing the order of certain instructions in the injector interrupt routine. These changes also resulted in minor code size reduction.

This test also demonstrates the system's reaction to having a Blue Tooth module broadcasting in close proximity to other circuits on the VID board. However, the operation of both the Blue Tooth and RS-232 communication channels is flawless at 57600 baud. I am currently receiving a steady stream of data from the device via the serial to USB device on this laptop and the program shown above. While a HP Pocket Pocket PC receives the same stream via the radio based Blue Tooth interface. I would have to rate the performance of the overall device (in the environment) as excellent.

Below are images of the Pocket PC VID interface program. When this program is involved, it requests the user select a Blue Tooth device from the list of available devices. It then connects and starts displaying data sent from the VID via the Blue Tooth connection. The data is updated each second and sent at about 7000 characters per second-- 57600 baud.

Note that the steady state GPH is about 1.054 gallons. While the speed is about 11 mph. Leading to a MPG of about 11.

This image shows the Pocket PC VID program main screen. The main screen shows RPM, MPH, GPH, and MPG. At the bottom of the main screen is the tab component selector bar. The user interacts with the tab control by simply clicking on the desired tab--- the screen the changes.
Below the tab control is the dialog menu which has three items. Exit, Connect, and Disconnect. Connect and Disconnect refer to the Blue Tooth Device. When the program first starts, the user is required to click on Connect-- this leads to a system screen for Blue Tooth device Selection. The user can click Disconnect or simply click Exit.

This image shows the Tank Screen: Tank Miles, Tank Gallons, Tank Seconds, and Tank MPG.

This image shows the RAW screen. Raw screen shows the current injector pulse and period width, along with the computed duty cycle percentage.

This image shows the Trip screen. Same items at the Tank Screen. Notice the crowding of
characters bug.

Finally, this images shows the Port setup screen. Blue tooth COM6 and 57600 baud rate are defaults here.

VID/YAG update

2009-07-19T07:42:00.000-07:00

Good Morning.

I am still testing the changes I made the other day in regard to the bug I reported. However, I also decided I better get some of code changes entered to support peak&hold type injectors. Of course this compounds the testing effort. However, it is interesting how fixing a bug leads to other improvements in the program. It is of course, still one step forward, 1 1/2 steps back. most of the time.

The Windows host configuration dialog now allows the user to select whether the VID responds to negative going or positive going fuel injector pulse information. In most cases, the vehicle's ECU pulls the injector to ground.-- so the VID's default for this, is negative going. In some cases, however, (I understand that some) ECUs pull the fuel injector up toward battery voltage.
This change, handles that contingency.

Both the VID and Windows host program also now allows the user (me) to enter values for the high and low limits for the injector input comparator. Again, in most cases both values would simply be set to mid-range and forgotten. However, in peak and hold cases, the values entered would be more like 1 and 15. This effectively, allows the VID to alter the input switching threshold from about 2 volt (for the negative going edge) up to about ( 10 volts actual) volts for the positive going edge. (Internally, the actual injector voltage level is scaled down into a range of about 1-3.3 volts to comply with CPU voltage reference constrains.) I believe this would allow the device to accurately profile the two step pulse width of the peak and hold type fuel.injectors.

In this shot, the blue trace represents the CPU controlled reference voltage--ranging from about 3 up to about 10 volts. The blue line illustrates the falling edge of the injector input--ranging from 12 down to about 0 volts. Notice how the blue trace changes from low state to high state following the transition of the injector trace. I don't have a trace of what an actual peak&hold injector would look like (in real life). However, an educated guess is, that once the ECU pulls the injector line to hard ground, unless the comparator reference voltage is immediately switched to a much higher level, the output pulse width (seen by the CPU) will be truncated when the ECU relaxes its hold on the injector--and not, when the injector is switched off. Therefore, in my application, the reference voltage moves up to above the "hold level" of the injector, and waits for the ECU to switch the injector--fully OFF...i.e. returning to 12 volts. In this fashion, the entire pulse width of the peak and hold injector is captured.

The design of the injector front end is trying to make it possible for the card to be adapted to almost any vehicle situation. I plan to make it very easy to change resistor and capacitor values in the field. This should--- make it flexible enough for most technical types to get this thing working with a minimum of fuss.

Honda Mileage Device YAG VID

2009-07-17T19:02:00.001-07:00

Just a quick note to say that I think changes I made last night to the VID firmware correct a slight problem I've been seeing for a few weeks now. As some might surmise, I have a vehicle simulator hooked up the device on the bench. I run this thing day and night-- accumulating hundreds of virtual miles each day. When the simulator is in the static mode, I expect to see the trip/tank averages remain constant PERIOD. However, I have recently noticed that the engine pulse width (that should remain constant) sometimes jumps about 50 percent several times per minute. This leads to a lowered average MPG. I checked and rechecked the incoming pulse width and could find nothing wrong. I then checked and rechecked the code--- also found nothing wrong.

Last night, it finally dawned on me that due to the way I was averaging pulse width readings in the injector interrupt thread, the main thread was sometimes disabling the injector interrupt before it could complete the last measurement cycle. So now by checking the completion status of the injector interrupt thread before halting the injector interrupt, the problem "seems" to be cured. While this appears to be the cure, I have now entered a new phase of regression testing to make certain that this change does not cause something else to break.

Honda Mileage Meter Update July 16, 2009

2009-07-16T08:06:00.000-07:00

Today is the 40th anniversary of the launch of Apollo 11 from Pad 39A at the Kennedy Space Center in Florida. I remember that day well. I was 17 at the time. I was working this particular summer at the local hospital as a combination grounds keeper / painter. On this day, I commandeered one unused patient room on the third floor. I then setup my RCA cassette tape recorder on one of the bedside tables-- just barely in audio range of the black/white TV set hanging over head. I closed the door, and hang out up there until the Apollo 11 crew made it into parking orbit.. Of course, some people heard the TV and before I knew it-- the room had a number of interested people standing around. I still have that recording---somewhere?

Today I want to introduce the new version of the VID circuit board. I also want to explain in detail, how it works.

Pictured to the left is the latest [http://www.cadsoftusa.com/] schematic drawing of what I am currently calling the VID short for----Vehicle Information Device. It could also be called YAM-- for Yet-Another-Meter.

The first thing the reader will notice about this design is my choice of an Microchip 18F2520 micro controller. Indeed, some might be tempted to question why I did not use a smaller processor for this "simple application." When I started this project, I used a 16F648A. The first generation VID actually worked quite well running at 4 Mhz and constrained by the 4 K limit on program memory.

However, all things being equal, I decided to move up to the 18 series for this application---mostly to focus on getting things done- rather than worrying about running out of memory at any second. In this application, the 18F2520, runs on its own internal 8 MHz clock.

Looking at the circuit diagram the reader will notice that I am using four connectors to tie the VID to the world. There is one connector called X4 for power/ground/and vehicle signals. X1 is the in circuit programming connector (ICP) used for in-circuit programming--allowing the user to eventually modify the VID firmware. X3 is the BCD connector is used to connect the VID to the display card. Finally, there is another four pin connector called X2. X2 is wired as a dedicated RS-232 port.

X4 is a four pin connector used to bring vehicle power, vehicle ground, vehicle speed sensor, and vehicle fuel injector signals on to the board. The battery power pin is connected directly to the input of a LM7805 (IC3) 5 volt regulator. The ground pin is wired to the center pin of IC3-- this is the official ground point on this card.

The vehicle speed sensor (VSS) pin is connected through R6 series resister before connecting to (non-inverting) IC1A pin 5 of a LM339 linear comparator. Pin 6 of IC1A is tied to resistors R2 and R12-- which together, form a voltage divider. R2/R12 provide approximate 50 percent of the vehicle battery voltage level as a voltage reference for the VSS half of the circuit. The output of IC1A, being an open collector type, is pulled up to VDD/VCC via R8. This output line is then connected to pin 11 of the IC1. Pin 11 of the CPU is the input to the Timer1/Counter1.

It can not be emphasized enough-- the series resistors on both the VSS and INJ line serve to limit the possible current that could be drawn should one or both of these lines go to ground. Nevertheless, each of these lines should also feature an in-line fuse (positioned as close to the vehicle connection point as possible) of about 250 milliamp rating to protect things---just in case.

The (user) selected vehicle fuel injector (INJ) is connected to the VID via a voltage divider formed from resistors R5 and R3. Together, they drop the maximum voltage seen by the inverting input of IC1B to about 3.2 volts. The reason, the injector signal level is reduced is because this version of the VID features what I will call dynamic injector level sampling. This means that I use the internally programmable voltage reference supplied by the CPU to provide a reference voltage for the external comparator.. Since,this reference voltage is only capable of being driven to some percentage of VDD/VCC, I ether had to amplify this signal, or scale down the other. Therefore, I scaled down the injector input level to match this level. Dynamic injector level sampling allows the user to configure the VID to adapt to almost any vehicle fuel injector condition. For example, with vehicles with saturated type fuel injectors, the injector reference level can be set and forgotten, peak and hold types often require two different levels per pulse cycle. This circuit there, allows the CPU the option of managing the reference level on the fly. It can should, therefore, handle most P&H type systems. The reader will note, the divided signal injector input is also connected to pin 2 of the CPU. This (feature) will allow the CPU to read the analog level of the signal. Thus, the operating battery voltage of the vehicle can also be ascertained and sent to the user. (I might note: this system is capable of reading up to a total of 4 analog voltages in this fashion.) Having this analog input also allows the processor to potentially decide for itself what reference voltage levels to issue to the external comparator. The output from IC1B is pulled up to VCC though R7, and also connected to the CPU at pin 21. In this application, pin 21 is configured as a high priority interrupt. Each time, this pin changes logic state, the CPU generates an interrupt. This interrupt is used to either start or stop the 62.5- 125 microsecond clock. In this fashion, the device determines the pulse and period width of the fuel injector input within less than 250 microseconds of precision. Using this measurement granularity, and taking into account other factors, the device should be able to measure fuel usage to within a few percent of actual.

The other components on the VID are used to connect the VID with either the BCD display board, or to a host computer via either, the serial interface connector, or the on-board Blue Tooth module--by radio.

IC2 provides the necessary interface between logic level serial signals provided by the CPU and the NRZ signals required by RS-232. IC2 is a Maxim 232. The 232 uses 4 polarized capacitors to produce the necessary voltage levels required by RS-232 interface

The two-wire interface to the display board uses IC4C and IC4D. IC4 is a CMOS compatible AND gates of the 7400 logic family. In this application, each of the four gates are simply used as buffers. In addition to BCD_CLOCK and BCD_DATA pins, X3 also provides connections for three remote tactile switches. The three switches are normally located on the display card. X3 also provides power and ground to the display card.

The final element of this version of the VID is the [ http://www.connectblue.com/products/bluetooth-products/oem-modules/oemspa310/] Blue Tooth module. Shown at the bottom of this schematic. In this configuration, the Blue Tooth module merely copies all outbound serial traffic and relays it to any compatible Blue Tooth device within range. The VID Connect Blue module is configured as a server. Other Blue Tooth devices will connect as clients. The default baud rate for the VID is set at 57600. (The Blue Tooth module will currently function at only 57600 baud.) The reader may also notice a jumper labeled: SJ1. This is left open unless the IC2 is removed from the board. At that time, the Blue Tooth device can be configured to receive commands and traffic from the Blue Tooth client. IC4A and IC4B and gates are used to interface the 3.3 volt [Connect Blue] module with 5 volt logic circuits.

The final version of the VID will feature full-duplex communications via the Blue Tooth interface. But at the present time, the VID Blue Tooth communications is outgoing only.

Final note: The latest VID design features provisions for adding filter capacitors and protection diodes to the two signal input lines. While, in my case, the signal lines were clean, I wanted to add these to the design in case others did not fair as well.

One possible PCB layout is shown above.

Honda Gas Mileage Device:July 13 2009

2009-07-13T08:51:00.000-07:00

I am writing this from the local MacDonalds in northern NY state. Today, I volunteered to take my wife's 2005 Accord in for its 70K mile checkup. So, I have some time to kill before 2 pm. Actually, I had plenty of time to kill over 2 pm as well. I have to say, the folks at the Honda dealer have a good reputation around town. However, they may need to "stick to the knitting" as they say when it comes to making sure their customers don't get the idea that they (the dealer) thinks their time is worth nothing.

I made some progress during the weekend toward the (more) final VID design. As I said last night, I finally recognized the need to extend VID to support folks with peak-and-hold injector systems. And, while I think that many people who drive higher performance cars using P&H wouldn't care one way or the other--- some might. I,therefore, decided the small cost of putting this capability into the design now, out weighted other factors. And, so now the design allows the device to be configured to meet the requirements of over 85% of pre-1996 vehicle users.

The other important development was the recent addition of wireless output capability for the VID. One of the things that has bothered me from the start of this project was the prospect of having all of those unsightly wires running around the vehicle dashboard. For, it seemed that no matter in which direction the hard wired design went, there would always be a need to have something (in view) with wires sticking out of it.. Now--maybe certain hacker types like having wires running around-- but I get the impression that this would be frowned by most their friends. Besides that, all of those wires and connectors are one of the great negative factors in overall system reliability. I think that when the device is first installed it might be necessary to use the supplied RS-232 hard wired interface to configure it. But once that is done, the laptop should never again need to be connected directly to the device.

Taking all this into account , I first roughed out the basic wired design. Once that was done, I decided to try to obviate the need to have the VID circuit card/box exposed to general view. The only viable mechanism for getting information from the box to the user is by using some sort of radio based interface. I have looked at general purpose radio modems. However, they all seem to operate in the licensed region of the spectrum-- and therefore would require ultimate FCC approval. Since, the idea here is not to send these signals thousands of feet--but only about 10 feet. Blue Tooth serial is designed as a cable replacement medium-- so that is what I decided to focus on, for this application.

At any rate, at first I toyed with the idea to transmit raw injector pulse/period information from under the hood to a box located in the passenger compartment containing the VID/CPU. But doing this (alone) would not completely address the issue of wires inside the car. So,I decided the first revision of the wireless system would involve wiring the signals to the VID, and then sending processed information from the VID processor box to one of three types of display devices. The first two of these options were easy choices:(both to build and use) Blue Tooth equipped laptops , and certain BT enabled PDAs. The third Blue Tooth option, involves actually developing a custom Blue Tooth enabled display card. Equipping the display card with a wireless interface and LCD display would allow it almost autonomous--- and battery powered. In fact, doing this would allow it to be so thin and tiny, it could be mounted anywhere. Since all wiring would be hidden under the dashboard (along with the VID card itself), the display box would be so compact, it could be Velcro-ed almost anywhere.

So.. here is the plan: I will first concentrate on building a reliable VID box. A box that handles virtually all types of fuel injectors, and vehicles. This particular version of the VID will have no built-in display. Instead it will transmit all acquired vehicle data to any compatible Blue Tooth device, or to a laptop, via the wired serial interface. Since there is very little extra cost involved-- the VID will also feature a two-wire display interface. In the event someone wants wires, this interface would make it easy to connect a hardwired display directly to the VID.

Currently, the data transmitted by the VID is sent in binary form--c structures. Future modifications would allow it to send data to devices that have no knowledge of this, or any format. To this end, the device could stream straight text or XML formatted text to programs like Hyper-Terminal etc.

This morning, I roughed out the interface for PDA device I already own. A device that has not gotten a lot of use during the past few years. With the help of Visual Studio 2008, I created the rudiments of a program that allows me to connect the PocketPC2003 to the VID. After the connection is made, it receives a continues stream of engine data from the VID. I can easily see this device placed in a cradle on the dashboard---and connected once the engine is started. The user would not necessary have to watch this device constantly--but could refer to it occasionally. Using the HP device's stylus, the user could also easily manipulate the VID. For example, it could reset the trip/tank totals-- or just set it to display trip data as he/she wishes. To me this is the least expensive route toward the goal of getting a handle on fuel mileage and economy. Of course all of the existing Windows vehicle monitoring software works equally well with a Blue Tooth dongle installed on the laptop.

Beyond this, the next processor based project will involve the development of a BLUE TOOTH enabled LCD/BCD display unit for a more unified approach to the overall problem. However, the nice thing about having an easily programmed display platform like the POCKET-PC PDA, is that it can be easily adapted to display any information that VID is eventually configured to acquire. Nevertheless, other mileage meters have LCD/LED displays--so this one will too. The only difference is--this one will be without wires.

More technical details of the Blue Tooth interface will be forthcoming. I have to get a little test time on the design before I release the information. Within a few days I will release information on the type of Blue Tooth module I selected for this project--and the issues I faced getting it to work. At this time the device works in non-duplex mode. Meaning that the data flows out of the VID only. Soon, I hope to have complete two way communications between the Blue Tooth Client ,and the Blue Tooth Server (located on the VID) working. At this time, I can say the baud rate is quite acceptable--i.e. 57600.

I believe we are approaching feature freeze on this thing.

Honda Mileage:VID Update July 12

2009-07-12T08:39:00.001-07:00

Since my last post (over a week ago) I've been busy with a number of things . But, even while I rebuilt our front steps--- and other duties, I still found a time to do some thinking about modifying the VID design to handle both "saturated" and "peak and hold" type injectors.

This morning I completed changes to the prototype board addressing this---and other issues. While, I am currently testing the changes, I have hopes that the VID can now be user programmed to handle any type of fuel injector, or fuel injector system.

As the readers may recall, I originally configured my YAM "yet another (meter)" to handle only saturated type fuel injectors. After researching the issue, I discovered that other meters/devices offered for this purpose, also do not claim to be able to handle anything but saturated type fuel injectors.

So, that got me thinking: I surmised that in order to handle the saturated type, the input threshold could simply be statically assigned to one voltage---and that would be good enough. (and experience proves this to be correct) However, because of the way peak-and-hold fuel injectors work, assigning a unitary voltage to work with saturated types almost certainly would not work (correctly) for peak and hold types.

So, I took a look at the specification for the PIC 18F2520 CPU and found the device could be configured to provide a (16 step) variable reference voltage output at one of its analog pins.
BTW--the 18F2520 also has two internal linear comparators--but they do not offer the kind of flexibly i needed--so, I use my own.) However, since the range of this voltage reference is limited to a maximum of about 3.3 volts (using a Vcc of 5 volts) --- the injector voltage would also have to be scaled down to match this voltage range.

By installing the appropriate voltage divider on the INJ input, and rewiring the comparator to accept the reference voltage provided by the CPU, the program can now adjust the INJ reference voltage on the fly. With a maximum of 14.5 (high alternator output) voltage at the INJ input, the scaled output reads about 3.3 volts. The processor is now able set the comparator threshold to any value the range of 0 to 3.3 volts. With the 4.4 gain factor this represents a 0 to 14.5 volt adjustment range.

What does this mean? It means that unlike when I used fixed zener diode to provide a constant/stable reference voltage, the user can now set one threshold for the fuel injector current rise time and anther for the fall time. This is most important for the peak and hold type fuel injectors. Because P&H types employ a two step fall time. Obviously, if we did not adjust the threshold to accommodate the two-step-nature of S&H injectors, we might get a very rosy (but inaccurate) impression of the amount of fuel they were allowing to pass.. However, in this way, we will be able to detect exactly the correct pulse for both types of fuel injectors.

I realize the wiring in most cars is designed to allow the ECU to drive one end of each fuel injector to ground while the other is held at battery voltage. I also understand that some cars tie one end of the peak-and-hold type injector to ground, while using the ECU to drive the other end to battery voltage. In either case, the (newly redesigned) VID will accommodate either voltage polarity. In rare cases, certain jumpers would need to reconfigure/switched. As an added benefit, the new design allows the CPU to monitor the analog voltage level on the INJ input, this means that it is (theoretically) capable of automatically setting the appropriate threshold levels itself.

In summary, the changes I made to the VID design this morning allow the user (via the host software) to configure the INJ thresholds levels to match (almost) any requirement. For instance, if the vehicle uses situated fuel injectors, the user might simply enter the number representing 6 volts for both values--- and be done. (Better, yet, the device would simply default to 6 volts.) If, on the other hand, the user needed to configure for peak-hold type fuel injector system, he/she might decide to enter 3 volts for the injector charge time value and 10 volts for the injector off time value. In any case, this design allows the user the flexibility to just "make it work."

I mentioned other changes: In this REV, I have added other features to make it possible to do on the fly communications with laptops and PDAs without having to hook up either a serial or USB cable to the VID. I will be releasing more information on this development as my testing continues. But suffice to say, the final design of the device will provide both wired and wireless communication options. For those who still have their handy HP-Pocket PC with Blue tooth, they may finally have found something they are good for.

Honda Mileage: VID constants

2009-07-03T10:46:00.000-07:00

This provides a little background on the calibration constants used by the VID

Fc-----Fuel Constant

As we have already discussed, Fuel Injectors are sized according to how many cc (cubic centimeters) of fuel they spray per minute of full-on operation. For example, the fuel injectors I use, emit 240 cc per minute of operation. What does that mean to people who think about gasoline in terms of gallons:

240 cc/min is the number used by for just one cylinder. For the total amount of gasoline consumed by the engine we multiply this by the number of cylinders. Again, in my case, that number is 240 * 4 cylinders = 960 cc/min/engine.

960 cc/min/engine * 60 min/hour = 57600 cc/hour/engine

1 gallon of any liquid contains: 3785,51 cubic centimeters

Therfore: 57600 cc/hour/engine * 3785 gallon/cc = 15.217 gallons / hour / engine

To eliminate the decimal point, the number the VID uses internally is :
15.217 * 100 = 1522

Therefore Fc = 1522

Dc ----Distance Constant

Typically, vehicle Speed Sensors (VSS) change logic state (counts) between 4000 and 10000 times per mile (5280 feet) of travel. My vehicle happens to send about 4000 counts/min (PPS).

The VID, however, prefers the number be in another form:

So... to create that constant the program first divides the

PPM by 5280 = 4000/5280 = 0 .757575.

Fps_mph = 88 fps / 60 mph = 1.46666

Then, it multiplies Fps_mph * 0.757575 = 1.111

Therefore : Dc = 1111 = (1.111 * 1000)

Dc = 1111

The three numbers required by the VID are :

1. Pulses per mile PPS

2. Fuel Injector cc/ minute

3. Number of Cylinders

Honda Mileage: VID installation

2009-07-03T05:26:00.001-07:00

In the last post, I talked about VID calibration. Perhaps, what I should have talked about was how I installed the VID device in a pre-1996 automobile in the first place. Since I started with nothing but a voltmeter and oscilloscope, I may have had a slight advantage over someone simply trying to hook this thing up to some anonymous type of automobile. However, anyone that is capable of building this device (from the schematics) is more than capable of figuring out how to hook it up.

At any rate, I did not want to take any chances with the ECM wiring in this car. I therefore, stayed completely away from that part of the electrical system. Instead, I found the fuel injector ballast resistor block under the hood--this indicated to me that I had a saturated type injector system. In this case, the ballast resistor block is located on the driver's side of the engine--mounted near other electrical components near power steering reservoir. (I talked about the two types of fuel injectors in my past post.)

I nicked into one of the black wires connecting the ballast block with one of the fuel injectors. ( I think it was #1 cylinder--but it does not really matter.) I connected this with another wire of sufficient size and specification to ensure its wear resistance integrity as it passed through the fender wall and across the rubber door mounting, and into the passenger compartment. (I found no easy way to pass the wire through the firewall). The fact that this wire passes across metal door parts almost demands that a small fuse be installed in series near the tap in point--i.e. a short to ground here could affect the output transistor in the ECM.

As for the VSS: I am lucky to have a vehicle with a conveniently located cruise control box (CCB). In my case, the CCB is located under the dash directly below the steering wheel. I first removed the CCB from the connector. Then, while referring to the electrical schematic of the vehicle, I located the VSS wire. (In this case, this is a orange wire coming from the speed sensor.)

The next thing was to find a suitable source of power and ground for the VID. The CBB connector also provided a convenient place to make these connections as well. For me, this setup was ideal, because I wanted to be able to control the power to the VID by the same switch that controls power to the cruise control. So I tapped into three wires near the CBB connector with a type of connector that allowed me slip the connector over the target wire, and close them with a pair of pliers. Doing this, laces the target wire, creating a reliable, but 'semi-easily removable attachment point for the wire attached to the other half of the connector. I then installed three 18 guage wires into the three CCB attachment point connectors. The three wires from the CBB jointed the wire coming from the fuel injector connection under the hood. I then brought all four wires out from below the dash and into to a 9 pin molex style power connector. I finished connecting the wires to the VID by using the mate to the 9 pin molex connector. When I was finished, I could remove the VID from the vehicle by detaching one end of the molex connector. Since for development purposes, I used a vehicle simulator, this connector arrangement made it convenient to attach the VID to either system.

At any rate, this is what I did. What someone else would do depends on his/her particular vehicle. Obviously, the vehicle must be fuel injected. And, if the fuel injector system turns out to be a saturated type, this device design would most likely work--as is.

NOTE: Most ECMs will have connection points for both the VSS input and the fuel injector outputs. However, it might be better to NOT disturb the ECM, if that can be avoided.
In all cases, I would recommend that 1/4 amp inline fuses be installed in series with both signal lines (VSS & INJ) The VBATT line could also be fused. However, in most cases, as long as the power source is already fused, this may be unnecessary. In my case, the fuse that controls the cruise control box also protects for the VID.

Honda Mileage:VID Calibration

2009-07-02T13:12:00.000-07:00

Currently, the only way to enter calibration information into the VID is via the Windows based VID monitor program. To calibrate the VID, the user of this device would first have to obtain the specification on the type of fuel injector his/her vehicle uses. Somewhere, there is a number for every type of fuel injector made that specifies the number of cubic centimeters of fuel the device emits while being held fully on for one minute at the vehicle's specified fuel pressure. In my case, that number is 240 cc/min. The program also requires the user specify the number of cylinders the engine uses.Note:The program will automatically convert this number to gallons per hour for the engine as a whole, i.e. about 15.20 gallons/hour for my Honda Accord.

Because the VID was designed to expect a certain type of measurable injector pulse width, it is therefore assured to work with so-called "saturate and hold" type fuel injectors. Further investigation is needed before I can say for sure how the device will function with "peak and hold" type fuel injectors. See NOTES.

The other important constant needed by the VID is the number of counts the Vehicle Speed Sensor (VSS) sends for each mile the vehicle is driven. In my case, the number turned out to be about 4000 counts/mile. However, once the VID is installed, the user can easily determine the correct number for his/her type of vehicle by simply driving it for one measured mile and using the host PC software to note the number of actual counts the device received.

The picture above shows the calibration dialog box of the VID monitor program. After the program establishes a connection with the VID, the user invokes this dialog box. The user then enters the pulses per mile for distance and cc/minute for fuel, number of cylinders and pushes the corresponding button to convert the values. Then the user pushes send button. The user can then push "get" to confirm the VIM values.

Once the user knows what these two numbers are, it is a simple matter to start the program and connect to the VID. Then, open up the calibration dialog box in the Windows program and enter the three numbers. Pushing the send button transmits the numbers down to the VID where they are stored in flash memory.Once the unit is powered off and on, it should be ready to make use of the new constants.

And that is about all there is to calibrating the VID. For additional precision, the user should now drive about 10 miles and check the amount of error in the distance traveled. He should recompute the pulses per mile count and enter that number. In this fashion, the device will eventually know the exact numbers for this vehicle. If after driving the vehicle for some distance and computing MPG by hand, the user determines that the MPG calculation is off by some percentage, he can then recalibrate the fuel constant accordingly using the empirical data--by adding to, or deducting the percent error to/from from the cc/min constant.

The final version of the device will allow the user to enter these calibration constants using the UP/DOWN/ACTION switches and the BCD display.

NOTES:

Peak and Hold verses Saturated:
Peak and hold type injectors usually are of lower coil resistance than saturated-- around 2 ohms. P&H type injectors require the ECM to first turn on the injector using one current level, and then switch to another current level to maintain the injector on-state. This implies that the energy required to energize the fuel injector coil is higher than that required to keep it turned on. The , the maker is therefore able to reduce power dissipation across the fuel injector while improving performance and dynamic response time by overcoming the inductive reactance of the coil with higher current.

Saturated types usually feature higher coil resistance than P&H. The ECM turns them on for the full duration of the fuel injector pulse. In my case, the coil resistance is about 4 ohms with a series ballast resister of about 7 ohmes resistance. The inductive reactance (X sub L) of the coil, dictates the rise/fall time that can be expected of the fuel injector. My measurements shows that the typical rise time is around 500-1000 microseconds for this particular coil. The only outstanding question I had was exactly when the fuel starts to flow during the transition from fully off to fully on. Currently, the VID currently assumes that some fuel starts to flow once the voltage across coil reaches the 1/3 point. This is the reason the comparator reference voltage is set to 9.1 volts. Of course, the value of the zener diode can be changed very easily. In any case, any error generated would be swamped by other factors--i.e. the user simply adjusting the device until his/her reading agreed with empirical measurements.

Fuel Injection Resources:

http://www.robietherobot.com/Storm/fuelinjectorguide.htm

http://users.erols.com/srweiss/tableifc.htm

Why the future electric vehicle economy depends on fission.

2009-07-02T07:07:00.000-07:00

During the past few days I have made several posts containing technical material concerning one of my "pet" projects aimed at energy/environment conservation.

Today, I plan to express some of my opinion/feelings regarding the future of the nation's dependence on fossil fuel and how it seems that we are in such a no-win situation with regard to our reluctance to forgo the very thing that will eventually alter our ability to have any future options in this regard.

To paraphrase John F. Kennedy in a speech to the UN on another subject: "either we put an end to nuclear weapons, or they will put an end to us." As some will recall, at the time, there was a very real chance that this statement would be proven correct. Fortunately, the world got through this era without the worst happening. Now, over 50 years later, we stand at another even more perilous crossroad.

Ironically, back then, nuclear power seemingly threatened our existence, today if allowed to flourish, nuclear power may well be our only salvation. Indeed, the people of this country seem almost unable to overcome their fear of what COULD happen, to open their eyes to what WILL happen. As everyone knows by now, the forces that shaped our world into a place capable of supporting life as we know it, also locked away millions (if not billions) of years worth of a typically benign element, we call carbon.

It has been only about 200 years since mankind discovered the "wonders" of removing this carbon in the form of coal or liquid oil in large quantities. But in that "cosmic nanosecond" of time, man has already reached that point where half of the carbon sequestered by nature is now in our environment. No one could have known the consequence of being so greedy. But,nevertheless, now those consequences are becoming real.

So, as a people what are we going to do? Do we continue on this course without abatement? Or, do we alter that course just in the nick of time to avoid world wide displacement, death and destruction. Either way, I assure you, the earth will continue on. The earth is not in any real danger. It has seen it all before. In its' brief (6 billion) year history, the earth has stood witness to many many similar upheavals--and as we can see, it has endured.

There are those out there right now who preach that what we are seeing is merely the end or beginning of a cyclical temperature change. Nothing to be alarmed about--because it has happened before. And, taken in that context, they are right. I guess the only thing we differ upon is what happens to mankind, and the world we have all grown to love? Unlike the earth, mankind has not be around long enough to see the end or beginning of any geological cycle. So--it begs the question: do we really want to find out the hard way, what happens while the earth sorts out these issues over a period longer than man can ever imagine?

I think we know about one group among us that really accepts the end of civilization as we know it. But then there are those of use who haven't read that chapter. Perhaps, we would like to go on living as before. Then, of course there are those who want to go living as before, but don't want to give up anything to achieve that goal. These are the folks who get in their cars every day and drive to the local gas station and expect the gas to be there for them. They are not worried about tomorrow--because today "is hard enough." Hard or not, as long as they can afford gasoline and home heating oil, they choose not to worry---too much.

In the past few years, that is up until about October of 2008, we watched people flock to the showrooms to buy SUVs. Ironically, they say they wanted these vehicle because they someone said to be safer than conventional sedans. And, as it turns out, when pitted against one of these SUVs the "poor fools" who continued to drive their sedans died at a higher rate than those "smart folks" who proudly drove, to prove what they could purchase. However, when pitted against just the road, people also died in SUVs because of their less than excellent stability at any speed. It also does not help that some people just drive SUV more aggressively because they are "SAFER"-- you see.

I sometimes wonder exactly what odds SUV owners give themselves for being a victim of an automobile accident if they continued to drive smaller more fuel efficient automobiles. The fact of the matter is that while they are more massive-- and there is some safely in size--- SUV were popular to the BIG-3 because they were cheaper to produce. Why were they cheaper? Because they did not require compliance with the same safety standards as the sedans and compact cars.
Nevertheless, the BIG-3 made it almost a requirement of life to own one of these monsters.

Now, as we all know, that changed last fall when gasoline prices topped $4.00 per gallon. All of a sudden, the new car lots where awash with unsold SUVs. As a result, GM and one competitor are now coming out of bankruptcy as a result of both their miscalculation, and the government's charity.

I remember watching a show last summer about the "FUTURE of automobiles," on PBS. The "car talk" brothers were at the Detroit auto show interviewing a certain person from GM. When asked why GM insisted on making 500 hp automobiles--- in this day and age, the women laughed and said "well---this is what the people want?". To which, one of them said under his breath--but want about what they will want tomorrow? And, can you respond that fast?

During the winter and spring of 2009, gasoline prices dropped back to below $2 per gallon. And I detected some return to old ways of thinking--but not obliviously not enough to save the BIG-2. Now, with gasoline prices at almost $3 per gallon, Ford has recorded better sales numbers than Toyota for the first time in a while. This is based on the apparent fact that Ford has a few fuel efficiency models and people want to buy American. I must say, that I am not myself ready to leave Honda behind, but if I ever decide to buy American, it would be a Ford.

So, now that the smile has finally been erased from the faces of those smug populous BIG-3 executives where do we go from here?Certainly that question is far to complicated for most people like me to answer. Because sometimes the most obvious answer usually is way to simplistic. But I guess if i had to guess. I would have to say that the efficient non-carbon dependent production of electricity is at least part of the solution. Notice, I said non-carbon dependent. That means that electricity produced by coal, and oil should be out of the equation. That leaves us with Hydro, Solar, Wind, and Nuclear as our only viable long term energy sources. Oh, I almost forgot, one huge source of new energy, is in fact simply to stop wasting the energy we are already producing. This is why I think it is important to make even modest improvements in the efficiency of the automobiles we already have on the road. i.e. my efforts to make it possible to know precisely how much fuel a car is using in real-time.

Of the four, Solar and Wind are now being addressed. But like hydro, they are at best only capable of filling a small percentage of our needs. Also, many smart people point out that solar is good only when the sun shines. That leaves the only 80 plus percent on-line source as nuclear. Naturally, just like everything else, nuclear power has its own unique set of problems. Moreover, unlike the long term problems caused by the others, its drawbacks can lead to major immediate consequences if not handed correctly. The other major problem with nuclear power is in the long term disposal of the spent fuel. These important issues notwithstanding, I for one believe that nuclear power, is our only real option. Coupled with the other three non-carbon sources of power, it will provide enough power to see this country through this period of transition. It will power our homes, our factories, and, indirectly, our automobiles.

Speaking again of automobiles: The trend in automobiles these days is toward plug-in hybrids. Hopefully, within a few years, battery technology will obviate the need for the gasoline assist engine and they will become all electric. That is good except: where is that electricity going to come from? Certainly, we can not pay the cost of this transition, plus continue to burn coal to power these electric cars. I believe we must therefore push wind and solar to the hilt. But, we must also license and build many more "inherently safe canned design" nuclear power plants. We must also solve the long term waste problem. Perhaps, one way would be to find some way to use the residual heat from this waste to power applications requiring lower grade heat.

Unfortunately, the era of not-in-my-backyard (NIMBY) may need to be pushed aside to keep the wishes of a few from detailing the dreams of the many.

Honda Mileage: July 1 2009 Update 3

2009-07-01T16:14:00.001-07:00

Here, I have uploaded the schematic for the custom 2-wire BCD seven segment card. The reader will notice that this card uses up to four Microchip PIC 16F627/648a CPUs for interface and seven segment decoding function. Originally, I used these processors because they were all I had in stock.In other words, I had no seven segment latch/decoders. However, as it turned out using $2 CPUs actually lowered the cost and complexity of this card. It also allows me to customize the decoding function enough to invert the display output--just in case I want to try to read the display off from the windshield while keeping my eyes on the road. The primary drawback to this is actually seeing the displays in bright sun light.

The reader might also notice that this drawing shows the board with its own 5 volt regulator. A prudent design would isolate the power requirements for this card from the VID--given the relatively high current requirements of these seven segment displays. In my prototype, I used u the 5 volts from the VID card.

Unlike the VID card, this (3*4 inch) card is densely populated. It is, however, quite simple to understand. From the schematic the reader can see that I used a total of four PIC 16F627 class CPU devices to drive three common cathode seven segment LED devices and discrete LEDs. In this application, each processor's interrupts are connected to allow them to all process all transitions on the BCD_DATA and BCD_CLOCK input lines.

In essence, they are all looking for something specifically addressed to them. To configure their address, Each processor has three input lines tied to either logic high or low. For example IC1 has all of its address inputs tied to ground. It, therefore, processes all messages sent over the BCD_DATA and BCD_CLOCK lines, but looks for messages addressed to device zero. In a like fashion the other devices listen for their unique address and respond accordingly.

IC1- IC3 contain the exact same program. (IC4 is the voltage regulator.)IC6 contains a program that responds to address 3 but instead of driving a seven segment display it drives the decimal points on the other seven segment LED devices, or one of several status LEDs.

As in the case of the VID, the code for these chips will also be available to anyone that requests it via email.

Preliminary parts list for BCD Display Card

C1 0.1uf C5/2.5 ceramic capacitor
C2 .1uf C5/2.5 ceramic capacitor
C3 .1uf C5/2.5 ceramic capacitor
C5 .1uf C5/2.5 ceramic capacitor
C6 0.1uf C5/2.5 ceramic capacitor
C8 10 uf polarized capacitor 25 volts
D1 PCB LED different colors
D2 "
D3 "
D4 "
D5 "
D6 "
IC1 PIC16F627P PIC16F627P DIL18 microchip 1
IC2 PIC16F627P PIC16F627P DIL18 microchip 1
IC3 PIC16F627P PIC16F627P DIL18 microchip 1
IC4 7805T 7805T TO220H linear 1
IC6 PIC16F627P PIC16F627P DIL18 microchip 1
R1 2K 1/8 watt carbon
R2 33K 1/8 watt carbon
R3 33K 1/8 watt carbon
R4 33K 1/8 watt carbon
R5 33K 1/8 watt carbon
R6 33K 1/8 watt carbon
R7 33k 1/8 watt carbon
RN1 8R-N DIL16
RN2 8R-N DIL16
RN4 8R-N DIL16
RN6 8R-N DIL16
S1 10-XX B3F-10XX switch-omron 1
S2 10-XX B3F-10XX switch-omron 1
S3 10-XX B3F-10XX switch-omron 1
U$2 1INCHLED 1INCHLED LQ5 stanleyled 1
U$3 1INCHLED 1INCHLED LQ5 stanleyled 1
U$4 1INCHLED 1INCHLED LQ5 stanleyled 1
X2 22-23-2081 22-23-2081 22-23-2081 con-molex 1

Below is one possible PCB layout for this circuit. Here I am using 1 inch high LED display units from Stanley Electric.

Honda Mileage:Update 2 July 1 2009 (VID Schematic)

2009-07-01T09:54:00.000-07:00

In the last post, I said I would release the schematic of the devices I am working on.

I am now releasing a very preliminary schematic drawing (Eagle CAD) of the VID card featured in yesterday's post. The only variation is the physical location of the tactile UP/DN/ACTION switches. This drawing shows the resister pull-ups for the switches only. In fact, the switches are (currently) located on the VID card.

As the reader can see, the circuit is really quite simple and straight forward. It consists of a total of three ICs and one 5 volt regulator. There are a three molex style header, and one DB-9, connectors on this card. The three molex connectors are designated as X3,X1, and X4. The DB-9 is shown as X2.

Starting with the power/signal connector: X4. Connector X4 brings vehicle power from a switched connection point near the cruise control card (CC) to the VID. The VID vehicle ground connection is also obtained at the CC card, as is, the vehicle speed sensor input. The other connection point on X4 is the fuel injector input (INJ). In this application, the INJ signal is obtained from tapping one of the fuel injector signals near a block ballast resister device located under the hood, and delivered to the VID card via X4. The decision to tap the the ballast resistor was made for purposes of expedience. In most applications, the best place to obtain this signal is at the ECM connector--- located below the front seat passenger's feet. Electrically, the VID input circuit will respond to the signal from either location. Also tapping at the ECM would eliminate the postive 4 volt offset that is seen when tapping at the ballast resister.

From connector X4, vehicle power is converted to logic +5 volts by the LM7805 regulator called IC3. Logic ground is also established at pin 2 of IC3 by way of connector X4. On the VID, both engine signals are each buffered by two 1K resisters. In any PCB layout, the input resistors should be placed in such a way so as to limit the chance that any short circuit condition could affect the integrity of either signal. I would recommend that one resister (for each signal) be placed at the connector, while the other as close to IC3 as possible. My tests have shown that 2K in addition the the input impedance of IC3 works well. Also, by splitting the resistance here, it would be possible to add filter capacitance-- if that became necessary.

The VSS signal is fed to one the high impedance non-inverting inputs of the quad comparator: IC1. While, the INJ signal is fed to another inverting input of IC1. The reference voltage for both comparators is established by dropping vehicle power down to about 9.1 volts using a zener diode and a 100 ohm resistor. The outputs from each of the comparators are pulled up to logic VCC by 3.3 k resistors. In this way both 12 volt signals are converted to proper logic 5 volt levels. When the INJ signal is inverted by IC1, both output levels are active high at the CPU inputs. The schmitt trigger inputs of the comparator also define sharper rise and fall times for the CPU edge sensitive interrupt inputs.

The VSS output from IC1 is connected to the PIC's timer1/counter1 via pin 11 on the 18F2520. The INJ output from IC1 is connected to the PIC's via pin 21 of the CPU. The processor monitors the INJ signal using one of its high priority interrupt inputs. Using it to constantly compute the ratio of pulse on-time to the total period duration. In this application, PIC Timer 1 is used as a counter. Using Timer 1, the program merely reads the count total each second, reset it, and and allows the count to build up again. For each second of operation, the processor tabulates both INJ duty cycle and VSS counts The results are placed in one of four internal data structures after it finishes computing RPM, MPH, distance traveled, and gallons used, and the like.

The other IC on the VID card is IC2. IC2 is a Maxim 232 RS-232 interface chip. Four, 1.0 uf capacitors allow IC2 to provide the necessary negative going signal voltage to make the output signals comply with the RS-232 standard. The RS-232 signals can connected to the host computer via connector X2. NOTE: the published picture of the prototype card features a standard PCB DB-9 style connector, the proposed PCB might opt for a header style connector instead.

Upon, start up, the VID is programed each second (by default) to compute the necessary data elements and send the contents of data structure #1 to the host through the serial port as message #1. If a proper request is initiated from the host software, VID can also send one of the other (requested) data structures as messages 2,3, or 4 before resuming default operation.

Data Message #1 consists of the following data items: MPH, RPM, GPH(gallons per hour) and preliminary MPG. Message #2 sends accumulated tank information: gallons used, distance traveled. Message #3 sends raw data on injector pulse on time and period width information.
Message #4 sends accumulated trip information. (the same as message 2--but for trip)

Future versions could also provide additional messages. Such as the status of the analog inputs on the PIC18F2520. With the extended memory capability of this chip, there is almost no limit to the vehicle data acquisition capability of this architecture.

In addition to the serial port, the VID provides a custom two-wire output format via connector X3 to either a LCD or LED display card. In its' current state, the two-wire interface connects to a LED based card. Connector X3 also provides connection points for the status of three tactile switches for UP/DN and ACTION to the VID. While the pull-up resistors are located on the VID, the switches will be located on the display card.

The two wire interface consists of a BCD_DATA line and a BCD_CLOCK line. This two wire interface is very similar to well known I2C style interface, except that it does not provide for read back capability. The two-wire interface in this application sends one eight bit byte for each digit used on the BCD card. Embedded in each byte is a four bit address and four bits of actual BCD data. Using this format, allows the device to send up to 16 BCD digits of data to any properly equipped card. In the proposed application, the VID would send 3-4 digits of BCD data along with one byte of status and decimal point information. Please refer to the writeup on the BCD card for more information on the two-wire format used here.

Connector X1 provides for In Circuit Programming capability for the PIC 18F2520.

Below is a preliminary BOM or parts list for the VID.

9.1V 1/2 watt zener diode

C1 1 uf 20 v polarized capacitor

C2 1 uf 20 v polarized capacitor

C3 1 uf 20 v polarized capacitor

C4 1 uf 20 v polarized capacitor

C5 0.1uf ceramic capacitor

C6 0.1uf ceramic capacitor

C7 0.1uf ceramic capacitor

C8 10 uf 25 v polarized capacitor

C10 0.1uf ceramic capacitor

U$1 PIC18F2520 28 pin cpu

IC1 LM339N Quad comparator 14 pin dip

IC2 MAX232 RS-232 interface chip 16 pin dip

IC3 7805T 5 voltage regulator

R1 3.3K 1/8 watt resistor

R2 2.2K 1/8 watt resistor

R3 1K 1/8 watt resistor

R4 100 Ohms 1/2 watt resister

R5 1K 1/8 watt resister

R6 1K 1/8 watt resister

R7 2.2K 1/8 watt resister

R8 3.3K 1/8 watt resister

R9 2.2K 1/8 watt resister

R10 15K 1/8 watt resister

R11 2.2K1/8 watt resister

U$1 PIC 18F2520 28 pin dip

X1 22-23-2041 molex header

X2 22-23-2041 molex header

X3 22-23-2081 molex header

X4 22-23-2041 molex header

The image above represents one possible PCB layout for this card.As I said before, the code for the PIC 18F2520 can be obtained by contacting me via email.

KEYWORD: Mileage, Fuel, Trip Computers

References:

wiki: http//ecomodder.com/wiki/index.php/MPGunio

Honda Mileage:Update July 1, 2009

2009-07-01T07:05:00.001-07:00

After posting yesterday, I decided to create an overview drawing of the VID connection schema.
The vehicle's connection points are to the left. the VID and the Display box are to the left. The Vehicle Speed Sensor (VSS) connects near the cruise control box (located under dashboard). The VID box receives the same power and ground as does the cruise control box. The device can therefore be restarted by cycling the power to the cruise control via the switches on the steering wheel. The injector pulse is connected (in this case) at the junction of the injector ballast resistor and the wire running to one of the fuel injectors in this engine. The display box is connected via a four conductor cable that currently terminates on the VID board as a 8 pin dip header/socket. The serial port connection to the USB and the laptop connects at the DB-9.

I have tentatively decided to soon release all electrical schematics for these devices. The idea being to encourage other interested folks to build such devices to aid in saving energy resources over the long run. And, if there turns out to be some interest in using the existing PIC18F firmware, I will make that available in the form of pre-programmed chips with the right to trade up to take advantage of periodic updates. Included with the chips will be open-source copies of the Windows based interface programs. As time goes on, and as the firmware for the various modules becomes more stable, I may release the PIC code as open source. For now, however, I will for a small handling charge (in addition to the cost of the chip itself), provide the pre-programmed PIC 18F series chip(s) to anyone who asks for them via email.

Honda Mileage:Vehicle Information Device(Introduction)

2009-06-30T09:59:00.000-07:00

The other day, I started to discuss my project to construct my own Vehicle Information Unit (trip computer). Today, I will share a few photographs of both that device, and the NET application I use to debug and calibrate it. Because of the grainy nature of these images, I plan to replace these photographs very soon with better shots of each subject.

This image (to the left) shows the layout of the prototype CPU card. The CPU (located along the top edge of this card) is a Microchip 18F2520. The two other chip components on the card are a LM339 comparator, and a Maxim 232 RS-232 converter chip. Shown at the bottom edge is the RS-232 DB-9 connector. The RS-232 interface allows the device to be connected to a laptop via a serial USB device.

The device works by constantly monitoring the voltage across one of the transistors controlling the fuel injector for engine cylinder one. (see image below) Each time the transistor fires the injector, the VID measures the exact amount of time, that particular fuel injector remains on relative to the off time. For each second of operation the device determines an average on/off (Duty Cycle) time for that cylinder. Because the device knows the amount of fuel the fuel injector would emit if it was held on for one full minute, the CPU can extrapolate the amount of fuel the engine consumed that past second by multiplying the value for this cylinder by four. In my case, each fuel injector emits 240 cc per minute-- the engine there would therefore use about 15.5 gallons per hour. (I am glad the injector ON time is measured in milliseconds.)

This image shows what a typical injector pulse looks like hear the injector side of the resister ballast resister in the Honda Accord. Notice that, the ECU controller is not able to being this point to ground. Since this is where I am tapping in, I need to level shift this signal to ground using a LM339 comparator. The approximate on time shown here is about 2 milliseconds. The comparators' schmitt trigger inputs are also useful for squaring up the signal for the CPU.

While all that is going on, the device is also counting the number of Vehicle Speed Sensor pulses (VSS) it is receiving from the sensor attached to the transmission. Again, the device knows how many pulses the vehicle produces each mile--so it can easily compute the number of feet (or miles) the vehicle has traveled during the past second.

So--knowing the distanced traveled this past second, combined with the amount of gasoline consumed allows the VID to compute MPG (miles per gallon), M.P.H., G.P.H. (gallons per hour) and so on. The device has flash memory built in--so all accumulated numbers are saved to flash, allowing the device to be used across engine starts as a real trip computer.

The device can (if requested) send a complete packet of data to the host PC. The VID always sends two characters of data to the BCD display. When the new display is complete,, the device will have four digits plus status LEDs--each digit will be at least 1 inch tall. And they will be the same color--the two shown were drawn from my sparsely populated parts box.

The following four images show the four main screens of the Windows C# program used with the VID for debug and data logging. This program is used in the lab and the vehicle to verify software changes made to the VID's firmware. It can also be used to actively record all received data for later playback. These simulated drives are sometimes useful for spotting spurious events that are not noticed as the vehicle is being driven. Future versions of the VID software will allow use of PDA platforms for this purpose. In most cases, there is no need to constantly watch these parameters. As the VID stores the fuel/distance state to flash every time it either times out or notices the vehicle about to come to a stop. The prototype BCD display is displayed here showing the TANK miles per gallon of 18.

This image shows the default screen. The default screen displays preprocessed data from the VID such as MPH, GPH, RPM and all of the error and status code transmitted by the VID.

This image shows the TANK Status screen. Here the program displays accumulated tank data such as distance traveled in both total number of pulses and Miles. This screen also shows accumulated fuel used since tank reset, and the number of running seconds on this tank. See trip screen.

This screen shows the VID output for the current Fuel Injector pulse and period width.

Similar to the Tank screen, this screen shows the accumlated data assocated with this TRIP.

The image above shows the VID with a 2 digit version of the two-wire BCD card. The VID card has just been removed from the vehicle and is still displaying the tank mileage figure of 28 MPG. The BCD card (currently)uses two 16F series processors to ( interface with the VID via a custom two-wire interface and seven segment decoders. Because I am using 16F devices I also have the capability to mirror the segment display output--allowing it to be positioned on the dashboard and the LED's reflected on to the windshield--- a HUD effect--if you will.

Located in the lower right corner of the board are a series of tactile switches. One switch is called UP, one called DN(down) and the other is labeled "action."It is by using these switches the user can select a parameter for display, or reset either tank or trip numbers. If the user selects either Trip or Tank MPG and then pushes the Action button, the all data for that entry will be cleared to zero. The user can clear the Tank, Trip data--or both. Later the Action switch will allow the user to change calibration constants for fuel and distance without using the laptop. Currently that is all a function of the NET C# programs.

Finally, in this picture, I show the Visual Studio 2008 produced C# program (with some open-source graphics support--see below) that provides me with a simulated Honda Accord Dashboard. The the Speedometer is the large item to the left, the tachometer to the right. In the center are two gauges showing the trip and tank miles per gallon figures. The display also shows simulated odometers for tank and trip distance and gallons used. Note: the 2 digit 2 wire BCD display now reads 25 MPG. This is because while being attached to the vehicle simulator in my lab, it has not been treated as well as when attached to the actual vehicle. The vehicle simulator sends pulses to the device showing about 10 MPH while sending fuel information showing about one gallon per hour,i.e 10 MPG.

NOTE: As stated before, the Windows interface is not normally required while out driving. However, it is useful sometimes for logging vehicle driving habits etc. Using xml serialization, I can easily log all data coming from the VID for later playback. The VID normally stores accumulated miles driven and gallons used in flash memory. It can also store information on maximum vehicle speed, maximum engine RPMs, and acceleration and braking habits. While I am sure that anyone using such a device would never be caught breaking the law, it is remotely possible that if the ticket was for a speed greater than the VIM recorded as maximum for that trip that you might be able to use this as evidence in your defense. In the future certain real-time markers can be added to the stored data to make it possible to legally correlate such things.

At this point in this project, I am almost satisfied with how the device works with the engine and the vehicle simulator etc. It has passed tests concerning electrical noise-- the two-wire BCD device is works well enough that the length of wire between the master and the slave does not produce measurable error. I was impressed that the wire length grew to four feet without negative consequences. I did add 10 K termination resistors to the receiver end, before the display settled down, however.

As I said the other day, I am making plans to produce two PCB for a full-up test of both sub-systems. In the meantime, I will continue to field test the device whenever the Accord is driven. In fact, it is nearing that point where a full tank test is called for. I will therefore be planning a trip to Vermont after the Forth Holiday.. I would go this weekend to my favorite remote camping location. However, experience tells me that the Forth of July is no time to expect any peace and quiet in that place.. not so remote after all.

During the next week, it will be my goal to get the exhaust and the front half axle replaced. After 220000 miles, I can not complain about the CV joints-- that is for sure. The right side was replaced last month. As I have said, the driver's side would have been already been replaced but to do it myself, I an still unable to get the 32 mm axle nut loosened up. I have broken several 1/2 inch drive tools trying.

References:

1.0 Thanking,Guillaume CHOUTEAU for open source Windows GUI support for custom controls

Honda Fuel Economy

2009-06-26T07:32:00.000-07:00

The vehicle now has 220,000 miles on it. It does not use a drop of oil--and retains over 85 percent of its factory power. Currently, the vehicle is capable of 34-36 mph.

In the meantime, I have been working on an engineering project to design, and build a Vehicle Information Device (VID), that would at least mimic---OBDII in regard to fuel mileage. In some ways the VID provides the essential features of commercial devices like ScanGauge, but for cars older than the model year 1996.

At this stage I have settled on a PIC 18F2520 processor, and worked out the necessary algorithms to measure and/or record fuel usage and distance traveled. I've also developed an efficient method to transmit BCD data to a display board using a two wire interface. The display board can be configured as either an LCD module or a custom seven segment LED display. The LED display is the most interesting as it allows me to mirror the seven segment display and thus create a device capable of being read indirectly from reflection off the windshield. A HUD display--if you will. I use 1 inch seven segment LEDs for this purpose.

The existing VID currently monitors the duty-cycle status of one of four fuel injectors in this car. It also measures VSS (Vehicle Speed Sensor) pulse information. Combining the data allows the device to keep track of the number of gallons used over the distance traveled. It stores this accumulated data in internal flash memory and therefore forms the basics for a vehicle trip computer.

The VID prototype also employs three tactile switches. These switches allow the user to select the type of data displayed. The user can view tank and trip mile per gallon and distance traveled. Currently the display also shows RPM and MPH.The user can use these switches reset trip and/or tank data whenever desired.

The VID also includes an RS-232 interface. This allows the VID to send a constant stream of data to a Windows based program, located on a laptop. The program can be configured to simply monitor and display data, or actually log the data in XML format--for later play back. This feature is useful in analyzing driving styles and locations. I have two windows C# based programs for the laptop. One is a simple graphical/text based program that allows the user to select one of four different data messages and watch the data as it changes. The other program features a nice application of the C#/NET drawing class. It uses bitmaps representations of both the actual vehicle's speedo and tachometer gauges. The application then rotates a bitmap of the pointer and paints it over the gauge display.

Currently the actual device is a 3*3 inch wire wrapped prototype board. Soon i plan to move it toward a PCB prototype as the next step before having multiple PCBs built by a PCB vendor. In the meantime, I am exploring other avenues for simplifying the device design and usage. Currently the device requires the user physically tap into the vehicle's wiring--for power,ground, injector and VSS signals--in what I consider, a rather intrusive way. And, while I don't see any way around taping the fuel injector signal, I am working on ideas to eliminate the need to tap into the VSS. I am also looking for options to eliminate most wiring to the the display Unit. My ultimate goal is to have a device that is battery powered and can be positioned anywhere--including flat on the dashboard--doing this would allow the user to view the mirrored information via the windshield---and thus--- not be accused to being distracted by electronic gadgets. This Heads up Display (HUD) would allow the device to be much more instrumental in assisting the drive with his driving habits.

In my testing so far, the VID device has proven that using the vehicle specifications for the fuel injectors produces realistic fuel use data. (For this engine, the fuel injectors are specified to emit 240 cc/min of 100 percent operation. Or, about 15.48 gallons per hour.) By measuring the real-time fuel injector on time, the device can easily infer the fuel usage to within 5 percent of the actual usage.

Practical use so far shows that by driving the vehicle very carefully around town, the device easily reaches 28-30 MPG. For more extensive drives---covering many more miles, the VID agrees with the numbers arrived by the old method of measuring vehicle mpg.(i.e filling up the tank and driving for n-miles) On a trip of 300 miles or more, the device shows the vehicle average over 34 mpg. Fuel measurement confirms these numbers.

The extensible nature of the PIC/VID architecture will allow it to eventually monitor more vehicle information--- just as OBD does. For instance, the device will eventually provide (4) four, 10 bit analog to digital inputs--useful for monitoring any number of vehicle or environmental data. For example, engine or road temperature, O2 Sensor output, and the like.

So.. please come back for further updates on my efforts to squeeze both more miles and less fuel from my old Honda Accord.