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 advedure. I have to admit at one point I had it towed to a place that could deal with a very disfunctional 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.