[Ovmsdev] Volt/Ampera CAN Logs

R. Scott Perry spamfree4 at rscott.org
Sat Jun 2 01:50:54 HKT 2012


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#post91868 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#post91868 correlates the SOC number here with the bars displayed.
>>>>
>>>> The VIN can be constructed by taking the number "1" and converting the CAN IDs 4E9 and 514 to ASCII.  So with "4E1 4255313032363839" and "514 4731524436453436", you would end up with 42 55 31 30 32 36 38 39 47 31 52 44 36 45 34 36, where 42 is ASCII for B, 55 is U, etc.
>>>>
>>>> The latitude/longitude conversion is almost the same as what you have for the Tesla, with two exceptions -- changing the 2048 to 1000, as noted, and the accounting for negative numbers is different.  It seems that the number the Volt supplies is a 31-bit signed integer.  The easiest way to handle that, I think, would be to add "latlon = latlon<<   1;" before checking for<0, and then "latlon = latlon>>   1;" afterwards.  Running the code you have with those two changes seems to work fine.
>>>>
>>>> The bad news is that I have checked all my log files (I have been logging almost all the time I have driven for about 8 months now), and the CAN ID 32A (latitude/longitude) has never shown all zeroes.  If the GPS data is unobtainable, I believe the car reports the most recent reading.  The GPS data comes from the OnStar system, so I am thinking it may only provide the data if the OnStar service has been activated, which could be a problem for owners outside of U.S/Canada.
>>>>
>>>> For charging, all I have found so far are some numbers that appear to show electricity flow to/from the battery.  If they are positive, electricity is going to the battery; if negative, electricity is leaving the battery.  But this will also be positive if the gas engine is on and charging the battery, as well as if the car is going downhill and the regenerative braking is being used.
>>>>                        -Scott
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>



More information about the OvmsDev mailing list