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.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment