Go Back   EcoModder Forum > EcoModding > Instrumentation
Register Now
 Register Now
 

Reply  Post New Thread
 
Submit Tools LinkBack Thread Tools
Old 07-17-2009, 03:50 PM   #1 (permalink)
Ecomoddling Trooper
 
Join Date: Jul 2009
Location: New York
Posts: 11

WhiteHonda - '93 Honda Accord 10th special
Thanks: 0
Thanked 1 Time in 1 Post
Arrow YAG --- Yet Another Gauge DIY project

I am an embedded engineer with a passion for both Honda Automobiles, and their associated electrical/electronic components. (maybe a little too much time on my hands) Like other people (here on this site), I dislike the idea of wasting certain non-renewable commodities. Moreover, I have long believed that while we wait for a better day in terms of personal automobile use, our most important contribution to the planet is in squeezing every possible ounce of energy from the fuel we already have--- and use.

Last summer, I took a drive to a spot in Vermont that I enjoy. As I was driving, I started to think about the possibly of building a custom device that could monitor engine vehicle performance while providing me with near real-time display/information on fuel usage. We have two Accords: a 2005 and a 1993. You will soon figure out which one is mine.

When I got back from my trip, I started right in looking at the injector signals with my scope. I was soon able to build the first device prototype using a Microchip 16F series processor ,and some other circuitry. Because of the need to level shift the vehicle’s signals to logic levels, I built a suitable front end interface for the 1993 Accord saturated fuel injectors, and that vehicle’s speed sensor input. To make it all work, I used a popular IDE and C compiler designed for this processor family. The embedded program’s primary task was to measure injector pulse and period width and compute duty cycle. The other important task was to count the number of vehicle speed senor pulses that occurred during a fixed period of time and compute feet traveled. With this information, the device could compute MPH,RPM, GPH, and MPG.

To view this information, the device communicated with world via a RS-232 / USB interface to my laptop. It also sent limited information to a very crude three LED display that I attached (taped) to my dash board. This dongle shaped LED display featured three vertically aligned LED lights. While driving, the idea was to maintain the top most LED on at all times. For testing and debug purposes, the laptop would dutifully capture and record all data sent by the device via the serial interface. Using NET C#, I was able to quickly serialize all useful data and stream it to files on the disk drive. These log files later proved useful as they allowed me to replay the drive at any time. This data also provided a way to show others how driving style could impact fuel economy. The laptop software also allowed me to upload/down key conversion constants to/from the device’s flash memory.

In addition to (this limited amount of) actual road testing, I built and deployed another processor based device/system to simulate vehicle signals for bench testing purposes. This saved a lot of time, frustration, and GASOLINE. The vehicle simulator fed a constant stream of injector and VSS pulses to the device; allowing me to uncover hidden issues resulting from variable overflow, and other less obvious programming issues. The simulator also provided a platform for testing device stability while being exposed to electrical and RF noise here on the bench. I also used to simulator to test the power supply limits and device power sensitively.

The development system proved to be very good at speed/memory optimization. In fact, the working program never got past the ¾ point in memory use. This was in sharp contrast to other compilers I had initially tried--where I quickly ran out of space—and had to optimize memory use until functionality suffered. As I have said, the software developed for the laptop was written to run under NET 2-3 using C#. I also explored using Linux under the MONO C# platform. The GUI programs all ran well under Ubuntu--- however the unfinished IO system in Mono seemed to prevent me from achieving full operation.

This spring, I took the first prototype on a return visit to Vermont. Along the way, the laptop provided me with real-time information on vehicle mileage. It also showed me how well the mileage device was handling the stress of heat, and electrical noise produced by the vehicle. When I arrived back home, the device showed a distance error of about 2/10 of a mile in about 100. The fuel usage numbers were also very consistent with the amount of fuel I had to add to the vehicle’s tank. The device showed MPG at about 34, while I computed about 33. The LED display also proved ,that in a pinch, three lights could queue the driver to his driving habits etc- and do it without distracting the him/her into oblivion.

So, with this first proof of concept test behind me, I decided to place this legacy device on the shelve and design a follow on device using a more advanced processor. A few months ago, I started with a clean sheet of paper and achieved a reasonable design using Microchips PIC 18F2520 processor. With twice the clock speed and 8 times the memory of the F16 device, this chip proved almost ideal for this application. In addition to the now named Vehicle Information Device (VID), I built a simple synchronous two wire interfaced BCD display device to replace that “stupid” looking LED dongle display device. Currently the device has only two digits, but due to the extensibility inherit in the design, the device is expandable to about 16 digits. A more reasonable, four or five digit display is projected for the near future.

The current prototype VID works almost exactly like the legacy device. However, the 18F device allows better allocation of interrupt thread and memory resources. For instance, the UART communications is now handled by using lower priority interrupts--- this allows very full speed communications without the risk of blocking the injector measurement thread. The new version also makes use of the counters on the chip to measure number of VSS pulses occurring during the sampling period. The final version will allow the sampling period to be selected as either 500 milliseconds or 1 second.

Other interesting features of the new VID involves the generalization of the signal input section. I recently realized that some pre-1996 vehicles use peak and hold type injectors and with a slight redesign, the VID could also handle them without much trouble. Therefore, I changed the way the incoming injector signal width was detected and fed to the processor.

For the original saturated type interface, a single reference voltage was selected and applied to one input of a linear comparator. The comparator output would therefore change state on the leading edge of the pulse. The comparator output would flip back once the trailing edge passed this same voltage level on the way back to off position. For the Honda Accord, the voltage level was set at about 5 volts.

For the newest version of the VID, the injector input signal is scaled down (voltage divided down) to provide a maximum voltage of 3.3 volts at the comparator inverting input. The reference voltage applied to the other comparator input, is now derived from the CPU’s internal voltage reference source which is programmable in 16 steps. Obviously, for saturated fuel injector types, the reference voltage can be (like before) set to the center of range, and forgotten. However, for peak and hold, this reference voltage would need to be programmaticlly changed each time the injector pulse changes state. Therefore, when the injector is turned-on (hard) by the ECU, the reference voltage has already been set to relatively low value to capture the pulse’s leading edge. Once the leading edge is detected, the CPU would then change the reference voltage to a higher level in anticipation of the upward level shift, the ECU would soon command. In this way, the VID can capture the entire multi-level pulse generated by the peak-and-hold injector type.

I must add, at this point, I have no way of testing peak-and-hold injector types with this device.

Another important feature of the new VID is the addition of wireless cable replacement. This cable replacement takes the form of a Blue Tooth serial interface. Using this new wireless interface, allows me (or anyone else) to effectively bury the VID device under the dash board---- if that is desired.

Making use of the the Blue Tooth option also allows the use of existing PDAs, and/or laptops while forestalling the use of unsightly wires to connect them. Sometime in the future, I plan to build a Blue Tooth enabled custom LCD or LED display board for direct use on the dash board. And, given the custom nature of the current design for the LED display, the LED digits could easily be flipped or mirrored. In theory, this would allow the unit to be used as a type of HUD display—i.e. with the reflected digits appearing on the windshield (at night at least).


At any rate, the wire wrapped prototype VID unit is nearing beta quality status. Last night, I (think I) put to bed the last “known” bug in the firmware. While new features are still creeping in to firmware, the hardware design is almost at the prototype PCB state. Naturally, each time firmware changes occur, testing repeats/continues on the bench, and in the vehicle. Certain enhancements have caused such an improvement in performance that some internal constants need to be changed. Then regression testing begins again.

Before, going to the next step, a complete 500 (one tank) mile road test is in order. I think the wire-wrapped hardware is adequate for this test. Once that is finished, a beta PCB design and implementation is possible.

At any rate, I have started a blog which attempts to describe the VID/YAG DIY project in greater detail. I believe it can be found by searching under Honda Fuel Economy--- Running near Empty..VID etc.

http://honda93-runningonempty2.blogspot.com/


Last edited by JRC903; 07-17-2009 at 05:35 PM.. Reason: added one sentence
  Reply With Quote
The Following User Says Thank You to JRC903 For This Useful Post:
ECONORAM (04-15-2016)
Alt Today
Popular topics

Other popular topics in this forum...

   
Old 07-19-2009, 09:47 AM   #2 (permalink)
Dartmouth 2010
 
SVOboy's Avatar
 
Join Date: Nov 2007
Location: Hanover, NH
Posts: 6,447

Vegan Powa! - '91 Honda CRX DX
Team Honda
90 day: 66.52 mpg (US)
Thanks: 92
Thanked 122 Times in 90 Posts
Send a message via AIM to SVOboy Send a message via MSN to SVOboy Send a message via Yahoo to SVOboy
Nice work! How much money would you say it costs to assemble one of your VIDs?
  Reply With Quote
Old 07-19-2009, 12:04 PM   #3 (permalink)
Ecomoddling Trooper
 
Join Date: Jul 2009
Location: New York
Posts: 11

WhiteHonda - '93 Honda Accord 10th special
Thanks: 0
Thanked 1 Time in 1 Post
The firmware/device is currently still under development. (No PCB exists--- as of yet) However, it was my goal to not spend much more on this then other popular DIY approaches. Currently, the biggest expense is the blue tooth module.. but leaving that and the PCB expense out of the picture, the parts total less than $20-25.

  Reply With Quote
Reply  Post New Thread


Tags
honda fuel meter

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Econometer/Vacuum Gauge Installation Guide Johnny Mullet Instrumentation 80 02-18-2015 12:58 PM
Electric car conversion: Project ForkenSwift MetroMPG Fossil Fuel Free 1041 07-28-2014 09:19 AM
Project: Rebuilding an '01 Honda Insight as a nonhybrid Fabio Hybrids 158 01-12-2013 11:59 AM
10-minute Accord vacuum gauge "install" Clev DIY / How-to 7 09-10-2010 03:53 AM
DIY - Head Swap (Project KDA complete!) SVOboy DIY / How-to 16 01-03-2008 02:17 AM



Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Content Relevant URLs by vBSEO 3.5.2
All content copyright EcoModder.com