<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi,<div><br></div><div>Great work.<div>Looks good.</div><div><br></div><div>In the Moment can i use my CAN2USB as source?</div><div><br></div><div>Bye</div><div>Michael J.</div><div><br></div><div><br><div><div>Am 12.07.2013 um 09:05 schrieb Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net">mark@webb-johnson.net</a>>:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>I've launched a new project on github:</div><div><br></div><div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><a href="https://github.com/markwj/CAN-RE-Tool">https://github.com/markwj/CAN-RE-Tool</a></blockquote></div><div><br></div><div>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).</div><div><br></div><div>Bill of materials for these things is around US$20-US$30. Street price is US$150 upwards (excluding shipping).</div><div><br></div><div>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).</div><div><br></div><div>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:</div><div><br></div><div><ul class="MailOutline"><li>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.<br><br></li><li>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.<br><br></li><li>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).<br><br></li><li>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).<br><br></li><li>Decoders can be defined, to produce sensors from the messages. These decoders document the protocol and message coverage.<br><br></li><li>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.<br><br></li><li>Control is via mouse, keyboard commands, or scripts on disk.</li></ul></div><div><br></div><div>Here are some screens, to give you an idea of what is possible:</div><div><br></div><div>Selecting a CRTD log file as the input source:</div><div><span><PastedGraphic-1.png></span></div><div><br></div><div>Scrolling CAN message display (input is a CRTD log file being played back in real time):</div><div><span><PastedGraphic-2.png></span></div><div><br></div><div>Uniques message display (note the decodes on the right, and message count + interval towards the left):</div><div><span><PastedGraphic-3.png></span></div><div><br></div><div>Coverage message display (everything not '*' is unknown):</div><div><span><PastedGraphic-5.png></span></div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>This is mostly for me, but I'm putting it out there and sharing it in case anyone else needs this.</div><div><br></div><div>Regards, Mark.</div><div><br></div></div>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br></blockquote></div><br></div></div></body></html>