Hi everyone,
I'm the RScott from 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#po... 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
Hi Scott,
nice work. is it possible to get the software. I still in fight with canhack to get the logs in the rigth format.
@Mark: you ask about the computer with i got the logs. i answer that is an PC with XP. BUT i would prefer to use my MacBook with Lion. But couldnt find a working software.
Bye michael
Am 31.05.2012 um 15:34 schrieb R. Scott Perry:
Hi everyone,
I'm the RScott from 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#po... 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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 5/31/2012 10:17 AM, Michael Jochum wrote:
Hi Scott,
nice work. is it possible to get the software. I still in fight with canhack to get the logs in the rigth format.
Hi Michael,
I have just put the program online at http://www.evtools.info/elmma.htm.
If there are any problems getting it to work, or you have any questions, please let me know. -Scott
Hi Scott,
the link at your web site is wrong. you have a dot at the end, after the "exe". But i could download. Unfortunalety it didnt work with my canusb. But i can log now with canhacker. Log is on the way to mark. It is a little bit bigger (10MB, 760k rar), so i didnt post it to the list.
Bye michael
Am 31.05.2012 um 20:48 schrieb R. Scott Perry:
On 5/31/2012 10:17 AM, Michael Jochum wrote:
Hi Scott,
nice work. is it possible to get the software. I still in fight with canhack to get the logs in the rigth format.
Hi Michael,
I have just put the program online at http://www.evtools.info/elmma.htm.
If there are any problems getting it to work, or you have any questions, please let me know. -Scott
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Michael,
I'll try to get you a version of my can-re-tool over the weekend. That will work on your Mac with Lion (same as I use). Sorry it has taken so long - just been busy with other projects.
Regards, Mark.
On 31 May, 2012, at 10:17 PM, Michael Jochum wrote:
Hi Scott,
nice work. is it possible to get the software. I still in fight with canhack to get the logs in the rigth format.
@Mark: you ask about the computer with i got the logs. i answer that is an PC with XP. BUT i would prefer to use my MacBook with Lion. But couldnt find a working software.
Bye michael
Am 31.05.2012 um 15:34 schrieb R. Scott Perry:
Hi everyone,
I'm the RScott from 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#po... 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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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, 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#po... 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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi mark,
i got a log. i think it is in the right format. it helps to save as trace. :-) BUT it is a little bigger. ~10MB (5 Minutes or so) I rar it, now it is 700k. So i send it only to you.
you can post this mail to the list, but i think its better without the big log. ;-)
My Position is: 49° 29' 11" N and 7° 43' 37" Time is 12:50 Germany Summer Time 24h Format 1.6.2012
When the car is on, everything is fine. i play a little bit with some settings, activate Navi, clima, and so on. The hole time the car was connected to power. during log it switch between charging and full.
But when i switched the car of, the bus stops after a few seconds. The bus goes on the for a few seconds when:
- i touched the door knob (keyless entry), with or without key in range
- when i removed the charger
- when i open the door
- and yes when i switch on the car.
I make me now some adapters to get access to the 3 other can buses.
BTW: i run canhack (V2.0) in an VM (XP) on my MacBook Pro. Works well.
Bye michael
Am 01.06.2012 um 03:11 schrieb Mark Webb-Johnson:
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@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, 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#po... 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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Michael,
Looks good. I'll convert to .crtd in the morning and let you know what I find.
Regards, Mark.
On 1 Jun, 2012, at 7:22 PM, Michael Jochum wrote:
Hi mark,
i got a log. i think it is in the right format. it helps to save as trace. :-) BUT it is a little bigger. ~10MB (5 Minutes or so) I rar it, now it is 700k. So i send it only to you. <20120601_1250.rar> you can post this mail to the list, but i think its better without the big log. ;-)
My Position is: 49° 29' 11" N and 7° 43' 37" Time is 12:50 Germany Summer Time 24h Format 1.6.2012
When the car is on, everything is fine. i play a little bit with some settings, activate Navi, clima, and so on. The hole time the car was connected to power. during log it switch between charging and full.
But when i switched the car of, the bus stops after a few seconds. The bus goes on the for a few seconds when:
- i touched the door knob (keyless entry), with or without key in range
- when i removed the charger
- when i open the door
- and yes when i switch on the car.
I make me now some adapters to get access to the 3 other can buses.
BTW: i run canhack (V2.0) in an VM (XP) on my MacBook Pro. Works well.
Bye michael
Am 01.06.2012 um 03:11 schrieb Mark Webb-Johnson:
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@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, 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#po... 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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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, 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#po... 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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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 CXX is a textual comment CEV is a event marker comment R11 is reception of a can bus message with 11 bit id T11 is transmission of a can bus message with 11 bit id Data For C** it is a textual comment 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@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, 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#po... 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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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 64The 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@webb-johnson.net <mailto:mark@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#po... <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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi,
in the mean time in can confirm:
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.
"1" . 514 . 4E1 converted to ascii IS the VIN!
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#po... correlates the SOC number here with the bars displayed.
could be the SOC. But in my case it goes only to 14,14kwh and that it falls down. Car is still connected AND Battery is full (Green Light is flashing).
Bye michael
Am 31.05.2012 um 15:34 schrieb R. Scott Perry:
Hi everyone,
I'm the RScott from 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#po... 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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi Michael,
I believe the SOC is correct. The SOC number is the actual amount of electricity in the battery, not the usable amount. Only about 70% of the actual battery power is ever used. So this number is normally between about 3,5kwh and 14,4kwh. -Scott
On 6/1/2012 8:35 AM, Michael Jochum wrote:
Hi,
in the mean time in can confirm:
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.
"1" . 514 . 4E1 converted to ascii IS the VIN!
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#po... correlates the SOC number here with the bars displayed.
could be the SOC. But in my case it goes only to 14,14kwh and that it falls down. Car is still connected AND Battery is full (Green Light is flashing).
Bye michael
Am 31.05.2012 um 15:34 schrieb R. Scott Perry:
Hi everyone,
I'm the RScott from 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#po... 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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
For OVMS, is it best to leave this as 'real' soc, or 'normalise' to the 'standard' range like the Tesla does?
For example, say the top 10% and bottom 10% is never used, so only numbers between 10 and 90 are seen (in a 0 to 100 range). For example, if the value is 40, is that 40% SOC or 37.5%?
It is going to be interesting coming up with estimates for ideal and estimated miles in the Volt...
Mark.
On 1 Jun, 2012, at 9:47 PM, R. Scott Perry wrote:
Hi Michael,
I believe the SOC is correct. The SOC number is the actual amount of electricity in the battery, not the usable amount. Only about 70% of the actual battery power is ever used. So this number is normally between about 3,5kwh and 14,4kwh. -Scott
On 6/1/2012 8:35 AM, Michael Jochum wrote:
Hi,
in the mean time in can confirm:
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.
"1" . 514 . 4E1 converted to ascii IS the VIN!
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#po... correlates the SOC number here with the bars displayed.
could be the SOC. But in my case it goes only to 14,14kwh and that it falls down. Car is still connected AND Battery is full (Green Light is flashing).
Bye michael
Am 31.05.2012 um 15:34 schrieb R. Scott Perry:
Hi everyone,
I'm the RScott from 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#po... 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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I think that normalizing would be best.
The SOC could on rare occasions go below or above the normal range (e.g. if going downhill after charging, the regenerative brakes might get the SOC above the normal range, or if the Volt is out of gas it might go below the normal low). But events like that are rare, and showing "0%" or "100%" would be seem appropriate in those situations. -Scott
On 6/1/2012 10:46 AM, Mark Webb-Johnson wrote:
For OVMS, is it best to leave this as 'real' soc, or 'normalise' to the 'standard' range like the Tesla does?
For example, say the top 10% and bottom 10% is never used, so only numbers between 10 and 90 are seen (in a 0 to 100 range). For example, if the value is 40, is that 40% SOC or 37.5%?
It is going to be interesting coming up with estimates for ideal and estimated miles in the Volt...
Mark.
On 1 Jun, 2012, at 9:47 PM, R. Scott Perry wrote:
Hi Michael,
I believe the SOC is correct. The SOC number is the actual amount of electricity in the battery, not the usable amount. Only about 70% of the actual battery power is ever used. So this number is normally between about 3,5kwh and 14,4kwh. -Scott
On 6/1/2012 8:35 AM, Michael Jochum wrote:
Hi,
in the mean time in can confirm:
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.
"1" . 514 . 4E1 converted to ascii IS the VIN!
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#po... correlates the SOC number here with the bars displayed.
could be the SOC. But in my case it goes only to 14,14kwh and that it falls down. Car is still connected AND Battery is full (Green Light is flashing).
Bye michael
Am 31.05.2012 um 15:34 schrieb R. Scott Perry:
Hi everyone,
I'm the RScott from 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#po... 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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I'm not a Volt owner, but I've been logging EV drive and charge data for four years across three different production EVs.
It's great that the Volt is giving an energy number, not an SOC. The Leaf's factory SOC gauge is relative to the battery's current capacity. Fortunately, the CAN bus provides an energy number.
The RAV4-EV, Roadster and Leaf all show SOC relative to the usable portion of the battery, not the full rated capacity. I think it makes sense to set 0% to the bottom of the normal usable range and 100% at the top.
If the battery pack gets outside those bounds in some unusual circumstance, it should show negative or above 100% so that net battery use can be computed by subtracting two SOC values. (That doesn't give energy use, but rather use of energy capacity, which can be different.)
To compute ideal miles do what Tesla does: multiply the SOC by the EPA-rated electric range. If you want to be really nice, let the user set the full range number to something other than the EPA number if they like.
Personally, I think estimated miles is rarely useful and often worse than useless. We live in an area with lots of hills, so estimated miles are constantly jumping up and down. Alternative, the estimated miles could be on a wider driving window, but then it becomes too unresponsive to be useful. I wouldn't bother to go to a lot of trouble to create an estimated miles algorithm that's only going to be useful in a steady speed and flat road situation.
Tomon 6/1/12 7:46 AM, Mark Webb-Johnson wrote:
For OVMS, is it best to leave this as 'real' soc, or 'normalise' to the 'standard' range like the Tesla does?
For example, say the top 10% and bottom 10% is never used, so only numbers between 10 and 90 are seen (in a 0 to 100 range). For example, if the value is 40, is that 40% SOC or 37.5%?
It is going to be interesting coming up with estimates for ideal and estimated miles in the Volt...
Mark.
On 1 Jun, 2012, at 9:47 PM, R. Scott Perry wrote:
Hi Michael,
I believe the SOC is correct. The SOC number is the actual amount of electricity in the battery, not the usable amount. Only about 70% of the actual battery power is ever used. So this number is normally between about 3,5kwh and 14,4kwh. -Scott
On 6/1/2012 8:35 AM, Michael Jochum wrote:
Hi,
in the mean time in can confirm:
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.
"1" . 514 . 4E1 converted to ascii IS the VIN!
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#p ost91868 correlates the SOC number here with the bars displayed.
could be the SOC. But in my case it goes only to 14,14kwh and that it falls down. Car is still connected AND Battery is full (Green Light is flashing).
Bye michael
Am 31.05.2012 um 15:34 schrieb R. Scott Perry:
Hi everyone,
I'm the RScott from 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#p ost91868 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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi Scott,
can you check that the data from ID 32A is somewhere else in your logs? in mine 32A is always zero. We have here no OnStar. But i have the full package including Navigation.
Bye michael
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.
Hi Michael,
I cannot find the data from 32A does not appear elsewhere in the logs.
My guess is that OnStar uses a separate GPS system than the navigation, and OnStar sends the latitude/longitude on 32A, and the navigation system sends it on a different bus (or, hopefully, on the same bus but with a different CAN ID).
I'll take a look at your log file, and see if I can find the GPS information, if it is in there. -Scott
On 6/2/2012 7:16 AM, Michael Jochum wrote:
Hi Scott,
can you check that the data from ID 32A is somewhere else in your logs? in mine 32A is always zero. We have here no OnStar. But i have the full package including Navigation.
Bye michael
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.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi,
today i got some Logs from both Expansion Buses (DS (Chassis Expansion), RH(High Voltage Powertrain Expansion), Pin 12 and 13). Made an Cable for this. The trc are the time stamped Logs. The txt show only the IDs, the last Values and some comments from me. Unfortunately both stops after 5-10 seconds the car switched of. Car stands still. Clear sky view.
Next i made a Cable for the RH High Voltage Energy Management BUS (Pin 3 and 11) and than a cable for the Low Speed GMLAN (SWCAN ~33.3kbps) - Body Electrical Services Only at Pin 1 DS.
Bye Michael
Am 02.06.2012 um 18:45 schrieb R. Scott Perry:
Hi Michael,
I cannot find the data from 32A does not appear elsewhere in the logs.
My guess is that OnStar uses a separate GPS system than the navigation, and OnStar sends the latitude/longitude on 32A, and the navigation system sends it on a different bus (or, hopefully, on the same bus but with a different CAN ID).
I'll take a look at your log file, and see if I can find the GPS information, if it is in there. -Scott
On 6/2/2012 7:16 AM, Michael Jochum wrote:
Hi Scott,
can you check that the data from ID 32A is somewhere else in your logs? in mine 32A is always zero. We have here no OnStar. But i have the full package including Navigation.
Bye michael
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.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi,
yesterday i got some Logs. I do one log for each action. Lock/unlock car, open/close door, Remote start, Plugin/remove Charging Plug, ..... I do the action in 5 second interval. I think i found some IDs. And i found something interesting: Some IDs cycle 4 with 4 times Blocks. That mean there is a counter or an adress field in one data field that repeats after 4 times. It counts like 10 20 30 40, FF FE FD FC, or...... the rest of the data fields change there value. Can anybody confirm? Didi anybody see this before? I can see this after sort the Logs (Excel). As Sort field i use the ID. So i can see the value changing over time.
Bye Michael
Am 11.06.2012 um 16:39 schrieb Michael Jochum:
Hi,
today i got some Logs from both Expansion Buses (DS (Chassis Expansion), RH(High Voltage Powertrain Expansion), Pin 12 and 13). Made an Cable for this. The trc are the time stamped Logs. The txt show only the IDs, the last Values and some comments from me. Unfortunately both stops after 5-10 seconds the car switched of. Car stands still. Clear sky view.
<20120612-Michas Volt Logs>
Next i made a Cable for the RH High Voltage Energy Management BUS (Pin 3 and 11) and than a cable for the Low Speed GMLAN (SWCAN ~33.3kbps) - Body Electrical Services Only at Pin 1 DS.
Bye Michael
Am 02.06.2012 um 18:45 schrieb R. Scott Perry:
Hi Michael,
I cannot find the data from 32A does not appear elsewhere in the logs.
My guess is that OnStar uses a separate GPS system than the navigation, and OnStar sends the latitude/longitude on 32A, and the navigation system sends it on a different bus (or, hopefully, on the same bus but with a different CAN ID).
I'll take a look at your log file, and see if I can find the GPS information, if it is in there. -Scott
On 6/2/2012 7:16 AM, Michael Jochum wrote:
Hi Scott,
can you check that the data from ID 32A is somewhere else in your logs? in mine 32A is always zero. We have here no OnStar. But i have the full package including Navigation.
Bye michael
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.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Michael,
I looked at your previous two log files (DS and RH), and they don't seem to match-up with the powertrain logs from before. I think these are completely separate buses with completely separate data, rather than sources of data multiplexed onto the one bus.
Regarding the counters, it is common to see increasing counters (odometer, trip, kWh used, etc), but seems strange they would cycle after just 4, particularly as you describe.
Regards, Mark.
On 28 Jun, 2012, at 8:29 PM, mikeljo@mac.com wrote:
Hi,
yesterday i got some Logs. I do one log for each action. Lock/unlock car, open/close door, Remote start, Plugin/remove Charging Plug, ..... I do the action in 5 second interval. I think i found some IDs. And i found something interesting: Some IDs cycle 4 with 4 times Blocks. That mean there is a counter or an adress field in one data field that repeats after 4 times. It counts like 10 20 30 40, FF FE FD FC, or...... the rest of the data fields change there value. Can anybody confirm? Didi anybody see this before? I can see this after sort the Logs (Excel). As Sort field i use the ID. So i can see the value changing over time.
Bye Michael
Am 11.06.2012 um 16:39 schrieb Michael Jochum:
Hi,
today i got some Logs from both Expansion Buses (DS (Chassis Expansion), RH(High Voltage Powertrain Expansion), Pin 12 and 13). Made an Cable for this. The trc are the time stamped Logs. The txt show only the IDs, the last Values and some comments from me. Unfortunately both stops after 5-10 seconds the car switched of. Car stands still. Clear sky view.
<20120612-Michas Volt Logs>
Next i made a Cable for the RH High Voltage Energy Management BUS (Pin 3 and 11) and than a cable for the Low Speed GMLAN (SWCAN ~33.3kbps) - Body Electrical Services Only at Pin 1 DS.
Bye Michael
Am 02.06.2012 um 18:45 schrieb R. Scott Perry:
Hi Michael,
I cannot find the data from 32A does not appear elsewhere in the logs.
My guess is that OnStar uses a separate GPS system than the navigation, and OnStar sends the latitude/longitude on 32A, and the navigation system sends it on a different bus (or, hopefully, on the same bus but with a different CAN ID).
I'll take a look at your log file, and see if I can find the GPS information, if it is in there. -Scott
On 6/2/2012 7:16 AM, Michael Jochum wrote:
Hi Scott,
can you check that the data from ID 32A is somewhere else in your logs? in mine 32A is always zero. We have here no OnStar. But i have the full package including Navigation.
Bye michael
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.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi,
i think too that this are total separated Buses. -> Multi CAN Monitor! :-)
tonight i send the LOGs and the cycling IDs i found. BTW: the logs from yesterday are from the main CAN Bus DS.
Bye Michael
Am 28.06.2012 um 15:05 schrieb Mark Webb-Johnson:
Michael,
I looked at your previous two log files (DS and RH), and they don't seem to match-up with the powertrain logs from before. I think these are completely separate buses with completely separate data, rather than sources of data multiplexed onto the one bus.
Regarding the counters, it is common to see increasing counters (odometer, trip, kWh used, etc), but seems strange they would cycle after just 4, particularly as you describe.
Regards, Mark.
On 28 Jun, 2012, at 8:29 PM, mikeljo@mac.com wrote:
Hi,
yesterday i got some Logs. I do one log for each action. Lock/unlock car, open/close door, Remote start, Plugin/remove Charging Plug, ..... I do the action in 5 second interval. I think i found some IDs. And i found something interesting: Some IDs cycle 4 with 4 times Blocks. That mean there is a counter or an adress field in one data field that repeats after 4 times. It counts like 10 20 30 40, FF FE FD FC, or...... the rest of the data fields change there value. Can anybody confirm? Didi anybody see this before? I can see this after sort the Logs (Excel). As Sort field i use the ID. So i can see the value changing over time.
Bye Michael
Am 11.06.2012 um 16:39 schrieb Michael Jochum:
Hi,
today i got some Logs from both Expansion Buses (DS (Chassis Expansion), RH(High Voltage Powertrain Expansion), Pin 12 and 13). Made an Cable for this. The trc are the time stamped Logs. The txt show only the IDs, the last Values and some comments from me. Unfortunately both stops after 5-10 seconds the car switched of. Car stands still. Clear sky view.
<20120612-Michas Volt Logs>
Next i made a Cable for the RH High Voltage Energy Management BUS (Pin 3 and 11) and than a cable for the Low Speed GMLAN (SWCAN ~33.3kbps) - Body Electrical Services Only at Pin 1 DS.
Bye Michael
Am 02.06.2012 um 18:45 schrieb R. Scott Perry:
Hi Michael,
I cannot find the data from 32A does not appear elsewhere in the logs.
My guess is that OnStar uses a separate GPS system than the navigation, and OnStar sends the latitude/longitude on 32A, and the navigation system sends it on a different bus (or, hopefully, on the same bus but with a different CAN ID).
I'll take a look at your log file, and see if I can find the GPS information, if it is in there. -Scott
On 6/2/2012 7:16 AM, Michael Jochum wrote:
Hi Scott,
can you check that the data from ID 32A is somewhere else in your logs? in mine 32A is always zero. We have here no OnStar. But i have the full package including Navigation.
Bye michael
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.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I have seen some like that, too, that might go 10 20 30 40 10 20 30 40 10 20 30 40 and keep repeating the same way. -Scott
On 6/28/2012 8:29 AM, mikeljo@mac.com wrote:
Hi,
yesterday i got some Logs. I do one log for each action. Lock/unlock car, open/close door, Remote start, Plugin/remove Charging Plug, ..... I do the action in 5 second interval. I think i found some IDs. And i found something interesting: Some IDs cycle 4 with 4 times Blocks. That mean there is a counter or an adress field in one data field that repeats after 4 times. It counts like 10 20 30 40, FF FE FD FC, or...... the rest of the data fields change there value. Can anybody confirm? Didi anybody see this before? I can see this after sort the Logs (Excel). As Sort field i use the ID. So i can see the value changing over time.
Bye Michael
Am 11.06.2012 um 16:39 schrieb Michael Jochum:
Hi,
today i got some Logs from both Expansion Buses (DS (Chassis Expansion), RH(High Voltage Powertrain Expansion), Pin 12 and 13). Made an Cable for this. The trc are the time stamped Logs. The txt show only the IDs, the last Values and some comments from me. Unfortunately both stops after 5-10 seconds the car switched of. Car stands still. Clear sky view.
<20120612-Michas Volt Logs>
Next i made a Cable for the RH High Voltage Energy Management BUS (Pin 3 and 11) and than a cable for the Low Speed GMLAN (SWCAN ~33.3kbps) - Body Electrical Services Only at Pin 1 DS. Bye Michael
Am 02.06.2012 um 18:45 schrieb R. Scott Perry:
Hi Michael,
I cannot find the data from 32A does not appear elsewhere in the logs.
My guess is that OnStar uses a separate GPS system than the navigation, and OnStar sends the latitude/longitude on 32A, and the navigation system sends it on a different bus (or, hopefully, on the same bus but with a different CAN ID).
I'll take a look at your log file, and see if I can find the GPS information, if it is in there. -Scott
On 6/2/2012 7:16 AM, Michael Jochum wrote:
Hi Scott,
can you check that the data from ID 32A is somewhere else in your logs? in mine 32A is always zero. We have here no OnStar. But i have the full package including Navigation.
Bye michael
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.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (5)
-
Mark Webb-Johnson -
Michael Jochum -
mikeljo＠mac.com -
R. Scott Perry -
Tom Saxton