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.