As some of you may know, over the past couple of years OVMS has made me passionate about the concept of 'open vehicles', and in particular how smartphone control and monitoring can further the cause of EV adoption. One handicap to this is the expense and difficultly of decoding the vehicle buses.
I've recently launched a new project on github:
https://github.com/markwj/CAN-RE-Tool
With the other OVMS projects on-going, I've got too much on my plate to do this all on my own, so I'm announcing it here and hoping that some one / some people will step forward and offer to help. The main areas I need help with are finalising the hardware design and writing the PIC32 firmware - but longer-term if people want to help out with the CAN-RE-TOOL software, that would be wonderful.
Open Vehicles can sponsor the hardware for developers - so all I'm looking for is donation of your time and enthusiasm to this project. If you can't directly help with the coding / hardware hacking, then perhaps just help by spreading the news about this.
Volunteers please contact me at mark@openvehicles.com.
Background is that I'm pissed how costly CAN-USB adaptors are. For what they are, the cost is too high and the software is terrible. If you want the good software, the hardware cost is beyond ludicrous (thousand of dollars).
Bill of materials for these things is around US$20-US$30. Street price is US$150 upwards (excluding shipping).
I've got a hardware design (based on PIC32 and MCP2551 chips, plus a little power regulator), and I''m working with a China factory to see if we can get these down to US$50-60 (including shipping).
On the software side, I've released the CAN-RE-TOOL source code. This is perl code (but with a few libraries necessary), and pretty neat. Still very much a work-in-progress, but very usable. Some notes:
- It should be cross platform - just textual curses based. But, only tested on OSX so far. Linux should be easy, but not sure about Windows.
- It works with an Input-Transfrom-Output model, with optional displays. You can define the input as either a disk-based log file (CRTD format) or a CAN-USB adaptor to input from. The output can be discard, disk-based log, or CAN-USB adaptor to output to. The transforms take the input and perform optional transformations. At the start, the main transform is 'Uniques' - which find unique messages and keeps a history of updates to them. The input can be real-time or sped-up/slowed-down.
- Various real-time displays can be called up, including Cyclic and Scrolling real-time message lists, Unique message display, and coverage (which shows just the parts of the unique messages not currently understood).
- The uniques system identifies messages by a combination of CAN arbitration IDs plus optional data bytes within the message (an example being Tesla Roadster using byte #1 of ID 0x100 as a unique message).
- Decoders can be defined, to produce sensors from the messages. These decoders document the protocol and message coverage.
Everything is implemented as plugins, so it is very very expandable. I've working on a bunch of experimental plugins to do statistical and heuristic style analysis looking for patterns in the messages captured. - Control is via mouse, keyboard commands, or scripts on disk.
Here are some screens, to give you an idea of what is possible:
Selecting a CRTD log file as the input source:
Scrolling CAN message display (input is a CRTD log file being played back in real time):
Uniques message display (note the decodes on the right, and message count + interval towards the left):
Coverage message display (everything not '*' is unknown):
The whole point of this is to provide a system to capture messages from the can bus, work out which messages are unique for that particular car, provide a facility to decode the messages to user-readable sensors (speed, SOC, CAC, odometer, etc), and finally to allow the vehicle message documentation to be produced. It does all this today. Perl is used to make this all scriptable and extremely quick/simple to extend.
In future, I'm also interested in providing a facility to simulate a vehicle (we can only do that now by replaying a log file back out). OBDII style support work also be useful (include a PID scanner).
Regards, Mark.