<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Scott,<div><br></div><div>I've spent some time with different can bus tools, and they all have their own proprietary log format. Some good, some bad.</div><div><br></div><div>The tool I'm working on uses a combination log file format (called .crtd), that seems to do what I need. Here is some example log data:</div><div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>1320745424.000 CXX OVMS Tesla Roadster cando2crtd converted log</div><div>1320745424.000 CXX OVMS Tesla roadster log: charge.20111108.csv</div><div>1320745424.002 R11 402 FA 01 C3 A0 96 00 07 01</div><div>1320745424.015 R11 400 02 9E 01 80 AB 80 55 00</div><div>1320745424.066 R11 400 01 01 00 00 00 00 4C 1D</div><div>1320745424.105 R11 100 A4 53 46 5A 52 45 38 42</div><div>1320745424.106 R11 100 A5 31 35 42 33 30 30 30</div><div>1320745424.106 R11 100 A6 35 36 39</div><div>1320745424.106 CEV Open charge port door</div><div>1320745424.106 R11 100 9B 97 A6 31 03 15 05 06</div><div>1320745424.107 R11 100 07 64</div></div></blockquote><div><br></div><div>The space-seperated fields are:</div><div><br></div><div><ul class="MailOutline"><li>time (utc julian date seconds '.' milliseconds)</li><li>Record type</li><ul><li>CXX is a textual comment</li><li>CEV is a event marker comment</li><li>R11 is reception of a can bus message with 11 bit id</li><li>T11 is transmission of a can bus message with 11 bit id</li></ul><li>Data</li><ul><li>For C** it is a textual comment</li><li>For R** and T** it is the hex ID follow by hex data bytes</li></ul></ul></div><div><br></div><div>The format is human readable, and can be analysed by can-re-tool.</div><div><br></div><div>It is pretty trivial to convert most log file formats to/from this one.</div><div><br></div><div>The nice things about .crtd is that (a) it is both human and machine readable, (b) the times are clear and in UTC, (c) the CEV message is handy to issue just before doing something on the car.</div><div><br></div><div>The only thing missing at the moment is a local time zone stamp. I'm trying to decide how to do that, but most likely it will end up as a new comment type at the top of the file, specifying the number of seconds offset from UTC. I haven't bothered with it up to now, as all the can systems I've seen so far use UTC in the messages anyway.</div><div><br></div><div>Regarding can-re-tool, that is written in perl and is based on the CANUSB adapter for live capture and playback, but can also read-and-write .crtd log files. It can (or will be able to):</div><div><br></div><div><ul class="MailOutline"><li>Capture live data and show it on the screen</li><li>Log captured data to a .crtd file</li><li>Replay captured .crtd file data either in real-time or slow/fast time</li><li>Playback captured .crtd file data to the CAN bus, in actual time or slow/fast time</li><li>Analyse CAN bus data for unique messages</li><li>Allow user to define and revise decode rules for messages, decoding to parameters, in real time while capturing data</li><li>Display decode dashboards from any of the sources</li><li>Produce can message documentation</li></ul></div><div><br></div><div>The last one is the most interesting. I've found it troublesome to maintain multiple copies of the same information. What I'm trying to do is just like .crtd have a .crtr rules file that describes what is known about the messages. That file can be used either for decoding on-screen, or for producing a textual document describing what is known. Multiple .crtr rules files can be loaded, and maintained 'live' while data is being captured. This allows you to say things like 'what if that byte was X', or what if can bus message id Y had uniqueness on B1, and test the hypothesis with live data.</div><div><br></div><div>I'm also trying to formalise plugins for seaching/analysing the data. Things like "I know that the odometer message is there somewhere - please look for candidate messages with incrementing values in this range", or "Highlight it if you see value Y anywhere".</div><div><br></div><div>It is a work-in-progress. I've done most of this in scripts, for the Roadster work, but am now trying to put it all into one single tool.</div><div><br></div><div>Regards, Mark.</div><div><br><div><div>On 1 Jun, 2012, at 9:19 PM, R. Scott Perry wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi Mark,<br><br>I'll go ahead and send you some log files.<br><br>I would be interested in the format you are using for can-re-tool -- I haven't found anything else out there that logs CAN "monitor all" data to a log file. It would be nice to have a common format.<br><br>I did some experimenting yesterday, and was not successful in finding anything directly related to charging. The best I found was another number indicating power flow to/from the battery. I logged all the data that was sent while unplugging the cord and plugging it back in, and then "played back" the log file on the screen (where I can see all the CAN data, and watch it change). There is a lot of data (11,758 lines for just over 8 seconds of logging), so there could be something in there I missed. Or it may be on a different bus.<br><br>After the car is turned off, it looks like the CAN data stops about a minute later. If I press the unlock button on the remote, the CAN data will start again. If I am in the car, stepping on the brake pedal will normally start it up again.<br> -Scott<br><br>On 5/31/2012 9:11 PM, Mark Webb-Johnson wrote:<br><blockquote type="cite">Scott,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Thanks for this. Most useful. I'll see what I can do with Michael (who is working on the development of the Volt/Ampera can module for OVMS).<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Do you have any logs that you can share (either privately with Michael and myself, or publicly)? In particular, I'm interested in those messages I mentioned. It would be useful to be able to use this for validation of what we're doing and comparison. Don't worry about the format. Any textual fomat is ok - I'll convert it to the can-re-tool format. My eMail is <a href="mailto:mark@webb-johnson.net">mark@webb-johnson.net</a>.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The GPS issue is worrying, but not overly so. At the moment, OVMS uses a SIM900 chip for GSM/GPRS. As we are looking to support more and more cars, and realise that most don't have GPS systems on the CAN bus, we've been looking to switch to the SIM908 chip which also has GPS onboard (accessed via the same async port and AT commands as the GSM/GPRS system). If necessary, we can use that, but let's see what Michael comes up with when he manages to log more data.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">For charging, I would suspect that the charge mode (charging or not) is in there somewhere.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Have you looked at what is logged when the ignition is off? Michael sees that all messages stop, and we are concerned that will mean an inability to monitor charging. I think for your project, you are more concerned with monitoring driving, so not an issue for you, but interested in what you've found logging what the car does during charging.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Regards, Mark.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 31 May, 2012, at 9:34 PM, R. Scott Perry wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Hi everyone,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I'm the RScott from <a href="http://gm-volt.com">gm-volt.com</a>, and I wrote the page at evtools.info about the Volt and OBD2 data (which I haven't updated in quite some time). I've read the recent posts to the list about the Volt, and thought I would provide information here in response.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">First, if it would be helpful, I have written a program for Windows to record data from an OBD2 scanner. It is designed to work with scanners that use the ELM327 chip (or are compatible). It saves the timestamp, and saves the data in the format "11:48:45.829: 206 639600". It is run from a command prompt, and not very user friendly.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">For the SOC, the "206 3 69 C3 00" capture indicates CAN ID 206, with 3 bytes of data. The SOC data only uses the first two bytes, so this would be 0x69C3, or 27075d. Dividing by 4,000 gets 6.769kWh in the battery, or about 42% of the total battery capacity, which should be 4 bars on the display. <a href="http://gm-volt.com/forum/showthread.php?5328-Volt-Diagnostic-Tool&p=91868#post91868">http://gm-volt.com/forum/showthread.php?5328-Volt-Diagnostic-Tool&p=91868#post91868</a> correlates the SOC number here with the bars displayed.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The VIN can be constructed by taking the number "1" and converting the CAN IDs 4E9 and 514 to ASCII. So with "4E1 4255313032363839" and "514 4731524436453436", you would end up with 42 55 31 30 32 36 38 39 47 31 52 44 36 45 34 36, where 42 is ASCII for B, 55 is U, etc.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The latitude/longitude conversion is almost the same as what you have for the Tesla, with two exceptions -- changing the 2048 to 1000, as noted, and the accounting for negative numbers is different. It seems that the number the Volt supplies is a 31-bit signed integer. The easiest way to handle that, I think, would be to add "latlon = latlon<< 1;" before checking for<0, and then "latlon = latlon>> 1;" afterwards. Running the code you have with those two changes seems to work fine.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The bad news is that I have checked all my log files (I have been logging almost all the time I have driven for about 8 months now), and the CAN ID 32A (latitude/longitude) has never shown all zeroes. If the GPS data is unobtainable, I believe the car reports the most recent reading. The GPS data comes from the OnStar system, so I am thinking it may only provide the data if the OnStar service has been activated, which could be a problem for owners outside of U.S/Canada.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">For charging, all I have found so far are some numbers that appear to show electricity flow to/from the battery. If they are positive, electricity is going to the battery; if negative, electricity is leaving the battery. But this will also be positive if the gas engine is on and charging the battery, as well as if the car is going downhill and the regenerative braking is being used.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> -Scott<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">OvmsDev mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">OvmsDev mailing list<br></blockquote><blockquote type="cite"><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br></blockquote><blockquote type="cite"><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br></blockquote><blockquote type="cite"><br></blockquote>_______________________________________________<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></div></blockquote></div><br></div></body></html>