[Ovmsdev] Volt/Ampera CAN Logs
R. Scott Perry
spamfree4 at rscott.org
Sat Jun 2 02:27:17 HKT 2012
Hi Mark,
Thanks for the information on the crtd format. I've added support for
that and the can-do csv format to the program I have that analyzes CAN
log files. Mine isn't nearly as sophisticated as can-re-tool, but it
has been helpful for me. I've just placed mine online at
http://www.evtools.info/CanAnalyzer.htm . It, too, is a work in progress.
It requires Windows, and runs from a command prompt. "CanAlayzer
playback [filename]" plays back the log file, showing all CAN IDs on the
screen. "CanAnalyzer analyzeid [ID] [filename] > output.htm" will
generate an HTML file that does some analysis of a specific CAN ID to
see what numbers appear there. It's certainly not ready for the general
public, but might give you some ideas.
-Scott
On 6/1/2012 11:18 AM, Mark Webb-Johnson wrote:
> Scott,
>
> I've spent some time with different can bus tools, and they all have
> their own proprietary log format. Some good, some bad.
>
> 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:
>
> 1320745424.000 CXX OVMS Tesla Roadster cando2crtd converted log
> 1320745424.000 CXX OVMS Tesla roadster log: charge.20111108.csv
> 1320745424.002 R11 402 FA 01 C3 A0 96 00 07 01
> 1320745424.015 R11 400 02 9E 01 80 AB 80 55 00
> 1320745424.066 R11 400 01 01 00 00 00 00 4C 1D
> 1320745424.105 R11 100 A4 53 46 5A 52 45 38 42
> 1320745424.106 R11 100 A5 31 35 42 33 30 30 30
> 1320745424.106 R11 100 A6 35 36 39
> 1320745424.106 CEV Open charge port door
> 1320745424.106 R11 100 9B 97 A6 31 03 15 05 06
> 1320745424.107 R11 100 07 64
>
>
> The space-seperated fields are:
>
> * time (utc julian date seconds '.' milliseconds)
> * Record type
> o CXX is a textual comment
> o CEV is a event marker comment
> o R11 is reception of a can bus message with 11 bit id
> o T11 is transmission of a can bus message with 11 bit id
> * Data
> o For C** it is a textual comment
> o For R** and T** it is the hex ID follow by hex data bytes
>
>
> The format is human readable, and can be analysed by can-re-tool.
>
> It is pretty trivial to convert most log file formats to/from this one.
>
> 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.
>
> 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.
>
> 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):
>
> * Capture live data and show it on the screen
> * Log captured data to a .crtd file
> * Replay captured .crtd file data either in real-time or slow/fast time
> * Playback captured .crtd file data to the CAN bus, in actual time or
> slow/fast time
> * Analyse CAN bus data for unique messages
> * Allow user to define and revise decode rules for messages, decoding
> to parameters, in real time while capturing data
> * Display decode dashboards from any of the sources
> * Produce can message documentation
>
>
> 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.
>
> 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".
>
> 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.
>
> Regards, Mark.
>
> On 1 Jun, 2012, at 9:19 PM, R. Scott Perry wrote:
>
>> Hi Mark,
>>
>> I'll go ahead and send you some log files.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>> -Scott
>>
>> On 5/31/2012 9:11 PM, Mark Webb-Johnson wrote:
>>> Scott,
>>>
>>> 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).
>>>
>>> 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 mark at webb-johnson.net
>>> <mailto:mark at webb-johnson.net>.
>>>
>>> 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.
>>>
>>> For charging, I would suspect that the charge mode (charging or not)
>>> is in there somewhere.
>>>
>>> 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.
>>>
>>> Regards, Mark.
>>>
>>> On 31 May, 2012, at 9:34 PM, R. Scott Perry wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> I'm the RScott from gm-volt.com <http://gm-volt.com>, 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>> 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>
>>>> correlates the SOC number here with the bars displayed.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>> -Scott
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
More information about the OvmsDev
mailing list