[Bruce Land] sent in this cool final project for ECE 4760 at Cornell University. Dubbed TrckrX, it is an OBD-II tracking and data logging system built into a BMW E36 M3. The car in question is being used in some auotocross competitions. The driver wanted instant access to some data as well as a log of everything for later analysis. The unit gives a real time display of vehicle speed, coolant temp, and RPM. G-force and timestamps are stored on the SD card.
We think this is a very cool idea, and could be quite useful in some instances. The real time display of speed and RPM seem a bit peculiar as the car’s speedometer and tachometer are more appropriately placed for real time information. However, we completely understand that this was a class project and this person may not have wanted to replace their dash cluster with a new readout.
[Steve] let us know about his MultiDisplay car monitoring system. Unlike traditional systems that rely on interfacing with the OBD-II protocol and existing car computer, the MultiDisplay uses an Arduino and custom shield with a combination of sensors; including temperatures, pressures, throttle, Boost, and etc. The data collected can then be displayed on a 20×4 LCD or streamed to a PC with visualization and event recording.
It’s nice to see half a years worth of work finally be complete and presented in such a clean and professional manner, keep up the good work [Steve]
[Avi Aisenberg] sent us his final project for ece 4760. His team built and OBD-II data interface. Even though OBD-II is an industry standard, each manufacturer has implemented it differently. This is where this project shines. They have built it to be capable of talking to any of them. Not only that, but it has a nice backlit LCD screen for diagnosing issues without having to go back to your computer and downloading the data. If you really don’t need all the bells and whistles, you can make one for roughly $15. They even have an OBD-II app for the iPhone.
Rev by DevToaster is an application for the iPhone and iPod Touch that allows real-time monitoring of vehicle ECU data from the OBD-II port. Rev interfaces with a WiFi OBD-II dongle.
If your check engine light is on or flashing, REV is able to check the engine code, list all of the engine codes stored in the vehicle, and reset the stored codes or check engine light.
Rev is able to monitor real-time; vehicle speed, RPM, fuel consumption, engine coolant temp, fuel pressure, calculated engine load, throttle position, intake manifold pressure, air intake temp, timing advance, mass air flow, fuel level, barometric pressure, EVAP system vapor pressure, and fuel trim.
A brief video of REV in action is after the break.
Continue reading “iPhone OBD-II app”
You can buy a dongle with a weird industrial connector that fits under the dash of any car on the road for $15. This is just a simple ODB-II transceiver meant for reading error codes and turning a Crown Vic into a police interceptor. There’s a lot more to the CAN Bus than OBD-II; robots and industrial control units, for instance, and Hackaday alum [Eric] has developed an open source tool for all things CAN.
[Eric] built this tool because of a lac of open-source tools that can talk CAN. There are plenty of boards floating around that can reset codes in a car using OBD-II, but an open hardware CAN device doesn’t really exist.
The CANtact is a small board outfitted with a USB port on one end, a DE-9 port on the other, and enough electronics to talk to any CAN device. The hardware on the CANtact is an STM32F0 – an ARM Cortex M0 that comes with USB and CAN interfaces. This chip connects to a Microchip CAN transceiver, and that’s pretty much all you need to talk to cars and industrial automation equipment. If doing something legal, moral, or safe with the CAN bus in your car isn’t your thing, Wired reports you can digitally cut someone’s brake lines.
On the software side of things, the CANtact can interface with Wireshark and the CANard Python library. All the files, from hardware to software, are available on the Github. Oh, CANtact was at Black Hat Asia, which means [Eric] was at Black Hat Asia. We should have sent stickers with him.
[Justin] tipped us about his slick custom OBD-II gauge that could easily pass for an OEM module. He was able to use the clock area of his Subaru BRZ to display a bunch of information including the oil and coolant temperatures and the battery voltage.
The forum post linked above has a good FAQ-based explanation of what he did, but so many people have told him to shut up and take their money that he created an Instructable for it. Basically, he’s got a Sparkfun OBD-II UART board communicating with a pro Trinket. The display is an Adafruit OLED, which he found to be an ideal choice for all the various and sundry light conditions inside the average car.
[Justin] was able to reuse the (H)our and (M)inute buttons and reassigned them to (H)igh to show the peak reading and (M)ode to, well, switch between modes. The (:00) now resets the peak readings. He offers suggestions for acquiring the specific CAN codes for your car to make the data more meaningful. [Justin]’s code is safe in the many tentacles of Octocat, and you can check out his demo video below.
Continue reading “Ceci N’est Pas Une Clock”
We’ve gone over the basics of CAN and looked into how CAN databases work. Now we will look at a few protocols that are commonly used over CAN.
In the last article we looked at CAN databases, where each bit of a message is mapped to a specific meaning. For example, bit 1 of a CAN message with ID 0x400 might represent whether the engine is currently running or not.
However, for more complex communications we need to use protocols. These can map many meanings to a single CAN ID by agreeing on a structure for sending and receiving data.
Continue reading “CAN Hacking: Protocols”