My original plans for this project did not include OBD support. My bike doesn't have an OBD port, just a direct connection to the CAN bus, and that was all I was planning on building for. In addition, I was only planning on supporting RaceChrono on the software side for the data collection and analysis. But in the interest of getting public support and possibly doing some crowdfunding or turning this into a commercial product, it seems some sort of support for OBD as well as other collection software would make for a more widely appealing product. So I took some time during vacation and did some reading up on OBD (OBD-II specifically) and the alphabet soup of protocols and standards involved. I now have a plan, subject to change, of course.
To implement "OBD support", two elements are needed: the software interface used to talk to my device and the hardware interface my device uses to talk to the vehicle.
The software interface side of the OBD puzzle is fairly straightforward. The industry has largely settled on ELM327, which is both a chip sold by ELM Electronics and an "AT" like protocol that chip speaks. The chip provides the physical interface to the OBD signaling and speaks its protocol over a serial port to OBD diagnostic tools or software like Harry's Lap Timer and RaceChrono. It was suggested by some users that I consider using such a chip, or more specifically, an STN1110, which is a newer, faster, cheaper alternative that does exactly the same thing. Using a chip like that would take care of the OBD hardware interface and allow me to support all (almost all?) the known OBD signalling protocols. One stop shopping. I was seriously considering doing that until I realized I wanted something a little different.
The OBD interface on a vehicle is used to query and report PIDs. There are a number of predefined PIDs and a bunch of non-standard PIDs, usually defined by vehicle makers. An ELM327 (or STN1110) simply reports the PIDs the vehicle outputs. By default, the output of such a chip can't report anything that doesn't come from the vehicle, such as the analog or digital inputs, accelerometers, or GPS information my device will provide. The chip is a black box and I can't change how it works. Using a chip like that wouldn't allow any of those sensors to be reported through the ELM327 protocol. But if I implement my own ELM327 interpreter, I can define my own PIDs, much like a vehicle maker, and add all those useful values to the output.
So that brings us to the hardware interface to the vehicle. The vehicle interface is embodied by the SAE J1962 connector. The vehicle typically uses the female version of the Type A connector (for 12V systems) and the data collector uses the male. I haven't decided yet on how to make the physical connection between my data collector and the SAE J1962 plug, but it will probably be an add-on cable to allow someone the option of not using it if it's not needed.
SAE J1962 Type A male connector
Modern OBD connectors can support a variety of signals depending on the make and model of the vehicle. Some vehicles support multiple signals. As mentioned above, an ELM327 or STN1110 chip would make short work of those signals and provide nice neat output. But as I also mentioned, using such a chip would preclude me from providing all those other useful sensor values. So I'll need to process the OBD signals myself, which is a pain. Since I'm just one person and I don't have a PhD in vehicle data protocols, I won't be able to support as many signalling protocols as an off-the-shelf chip. I'll need to pick and choose which ones I think I can reasonably support.
As of 2008, all vehicles sold in the U.S. must support CAN bus as one of the OBD signalling methods. I don't think "vehicles" in this sense means motorcycles, however. Since I already have the hardware for CAN bus, that's a no-brainer. There is a protocol layer used on top of the standard CAN bus protocol that will need to be supported by firmware, but that shouldn't be a problem if I can get my hands on the standard (which may cost money to purchase). I'm also considering supporting ISO 14230 and maybe ISO 9141-2, both of which uses the "K" (and optional "L") signal line, assuming I can find enough information. I probably won't support any other signalling over OBD. I think that may be enough for many people. Some of the other signalling protocols are antiquated or only used on a small subset of vehicles. Feel free to correct me if I'm wrong.
Before my vacation, I started a major refactoring of code in both the firmware and emulator. I've now mostly completed the task of converting 5000+ lines of code to a much nicer object oriented architecture which will allow me to more easily add features moving forward. All that remains is more regression testing.
I've also added a Roadmap page to the site, linked in the header. This will be a living document that I'll try to keep updated with plans and schedules as I see them.