1993 Accord LX

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

Update

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

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

Update

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


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

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

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

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

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

Honda Fuel Economy TRIP COMPUTER VID/YAG

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

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

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

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

Honda Mileage Measurement Device Firmware testing update

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

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

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

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

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

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

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

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

Honda Mileage Device VID

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.

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

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

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

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

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

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

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

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

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.

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

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)

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