[Ovmsdev] CAN-RE-TOOL

Sat Jul 13 08:36:29 HKT 2013

Great work Mark,
I wish you all the best on this project.
I have wasted lots of time in the past on lots of different, but equally crappy CAN bus SW. 
I've also used one of the very expensive systems and it suffers poor UX from spaghetti code/features tacked on over time.
All the above have bad return on invested time and money.
Your samples below have better features than even the expensive SW.
This is a great oppty for an open src project to provide some quality SW.
All the best,
Richard

________________________________
 From: Mark Webb-Johnson <mark at webb-johnson.net>
To: OVMS Developers <OvmsDev at lists.teslaclub.hk> 
Sent: Friday, July 12, 2013 12:05 AM
Subject: [Ovmsdev] CAN-RE-TOOL

I've launched a new project on github:

https://github.com/markwj/CAN-RE-Tool

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  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).

This is mostly for me, but I'm putting it out there and sharing it in case anyone else needs this.

Regards, Mark.

_______________________________________________
OvmsDev mailing list
OvmsDev at lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130712/786b060e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.png
Type: image/png
Size: 106023 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130712/786b060e/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-2.png
Type: image/png
Size: 164813 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130712/786b060e/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-3.png
Type: image/png
Size: 235825 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130712/786b060e/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-5.png
Type: image/png
Size: 241242 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130712/786b060e/attachment-0011.png>