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:
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 firstname.lastname@example.org.
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:
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).