[Ovmsdev] Can.c logic

Jack West jackduncanwest at gmail.com
Thu Feb 16 16:35:08 HKT 2012 

Mark and Michael,

This didn't get the right results.  It seems that the heating state does not error out into a stopped state.  If you lose the pilot while heating, the car just goes back to preparing, so no alerts.  Stopping heating 'by request' does get a 0x15 state so that part is OK.  I messed with it quite a bit but can't seem to get the logic programmed right.  

Seems like we want the app to read "charging" when we are heating and "charging stopped" if heating state fails.  But not get any alerts when heating ends and charging commences normally.
I also tried looking at the pilot B2b3 to check for failure.  I'm doing my best but you guys seem to have quite the knack for knocking this stuff out.  I am pretty good at catching salmon though :)

Best, Jack



On Feb 15, 2012, at 10:28 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:

> Jack,
> 
> Sorry for late response.
> 
> Yes, that looks good. You could also optimise it with "can_databuffer[1]  |= 0x10" (I've never tried that on PIC, but it should work).
> 
> Regards, Mark
> 
> On 15 Feb 2012, at 11:34 AM, Jack West wrote:
> 
>> Mark and Michael,l,
>> 
>> I'm all for making things easy.  Sounds like a good solution.  Just to clarify:
>> 
>> can.c line #243
>> 
>> case 0x96:
>> if ((car_chargestate = = 0x0d) || (car_chargestate = = 0x0f))
>>      can_databuffer[1] = can_databuffer[1] | (0x10);
>> 
>> I'm pretty rusty at programming and only want to help, not make more work.
>> 
>> Jack
>> 
>> On Feb 14, 2012, at 6:05 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>> 
>>> 
>>> Would it be easier to 'fix' the issue by just setting bit4 high in can_databuffer[1] of 0x96 if the chargestate was 'preparing' or 'heating'?
>>> 
>>> It would make it easier for the Apps to handle.
>>> 
>>> Mark.
>>> 
>>> On 15 Feb 2012, at 10:51 AM, Jack West wrote:
>>> 
>>>> Michael and Mark,
>>>> 
>>>> I'm glad you were able to test this out and confirm Michael.  My car was too warm to test the heating cycle today.  I'm proposing the following and will test it out tonight or in the morning (as soon as my car chills out).
>>>> 
>>>> can.c
>>>> 
>>>> Line #243
>>>> Case 0x96:
>>>>   if ((car_charging) && !((can_databuffer[1] & 0x10) || (car_chargestate == 0x0f)))
>>>>      car_stopped = 1;
>>>>   car_charging = ((can_databuffer [1] & 0x10) || (car_chargestate == 0x0f));
>>>> 
>>>> And
>>>> 
>>>> Line #229
>>>> case 0x95:
>>>> if (car_chargestate = = 0x0f) // heating state is treated as charging
>>>>    car_charging = 1;
>>>> 
>>>> Jack
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Feb 14, 2012, at 3:43 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>>>> 
>>>>> 
>>>>> Bizarre. I guess they don't count it as 'charging' until current is going into the pack directly (as opposed to coming out of the wall).
>>>>> 
>>>>> I converted your logs (thanks) to roadster_can.pl compatible format, and it all looks quite clean. There are some very strange message states (in particular, the percentage jumps all over the place), but I don't see any unexpected charging->notcharging->charging transitions. Charging is OFF for the whole of the 0-49 log, and only goes on after pre-heat in the 100 log.
>>>>> 
>>>>> The 0-49 log shows:
>>>>> 
>>>>> 0.0 100 95 0D 07 64 A4 01 16 00    ->VDS Charger v1.5 (preparing-to-charge) (conn-pwr-cable) (standard)
>>>>>  ...
>>>>> 0.0 100 96 2C 00 02 21 38 00 00    ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C)
>>>>> 0.0 100 95 0F 0B 31 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 00 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 18 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 00 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 18 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 31 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 15 03 64 A4 01 16 00    ->VDS Charger v1.5 (stopped-charging) (by-request) (standard)
>>>>> 0.0 100 96 2C 00 02 21 38 00 00    ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C)
>>>>> 
>>>>> The 100 log shows:
>>>>> 
>>>>> 0.0 100 95 15 03 64 A4 01 16 00    ->VDS Charger v1.5 (stopped-charging) (by-request) (standard)
>>>>> 0.0 100 95 0F 0B 31 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 00 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 31 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 00 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 00 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 31 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 63 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 96 2C 00 02 21 38 00 00    ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C)
>>>>> 0.0 100 95 0D 01 64 A4 01 16 00    ->VDS Charger v1.5 (preparing-to-charge) (??sub-state?? 1) (standard)
>>>>> 0.0 100 96 2C 00 02 21 38 00 00    ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C)
>>>>> 0.0 100 95 01 05 64 A4 01 16 00    ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard)
>>>>> 0.0 100 96 3C 00 02 21 38 00 00    ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: true) (bits 3C)
>>>>> 0.0 100 95 01 05 64 A4 01 16 00    ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard)
>>>>> 
>>>>> [ side note - it seems the pilot does go false at some points in your logs ]
>>>>> 
>>>>> Regards, Mark.
>>>>> 
>>>>> On 14 Feb, 2012, at 7:01 PM, Michael Stegen wrote:
>>>>> 
>>>>>> Mark, Jack,
>>>>>> 
>>>>>> I can confirm that the charging bit is not set when pre-heating the battery.
>>>>>> It's only set when it goes from pre-heating to charging.
>>>>>> 
>>>>>> Maybe we should just look at the State (0x95) instead of charging bit (0x96) and state.
>>>>>> 
>>>>>> I have uploaded my logfiles fom when i did the test here:
>>>>>> http://www.stegen.com/pub/bat_heating.rar
>>>>>> 
>>>>>> Inside the rar archive are two logfiles, one pre-heats till 49% then i press stop from the VDS.
>>>>>> The otherone pre-heats till 100%, and then the charging begins.
>>>>>> 
>>>>>> Note that the "preparing to charge" state is also entered after the pre-heating ended and before the actual charging starts.
>>>>>> 
>>>>>> -Michael
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Op 14-2-2012 4:01, Mark Webb-Johnson schreef:
>>>>>>> Urgh.
>>>>>>> 
>>>>>>> I think we really need to get a good trace of what you are seeing.
>>>>>>> 
>>>>>>> Is it possible for you to run the 1.2.0-rc3 code in the car, using 202.52.42.80 server, do a full charge (including pre-heat), then let me know UTC time it started? If possible, check up on it with an App during the charge (when an App is connected, the car reports in once every minute - otherwise only once every ten minutes). I have a full log running on the development server at the moment, and 1.2.0 code sends the detailed charging bytes as well as the summary status text.
>>>>>>> 
>>>>>>> Regards, Mark.
>>>>>>> 
>>>>>>> On 14 Feb 2012, at 2:22 AM, Jack West wrote:
>>>>>>> 
>>>>>>>> Mark,
>>>>>>>> 
>>>>>>>> One possibility that might explain what I saw:
>>>>>>>> 
>>>>>>>> In heating substate the car does not turn on b4 of B2 in 0x96. Therefore logic does not see the car as charging when in the heating state so flags are not set, etc.
>>>>>>>> 
>>>>>>>> I'll look into this in more detail tonight.
>>>>>>>> 
>>>>>>>> Jack
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Stegen Electronics
>>>>>> Kwartslaan 95
>>>>>> 3162 RD Rhoon
>>>>>> The Netherlands
>>>>>> 
>>>>>> Tel:    +31 10-5016960
>>>>>> Skype:   stegen.com
>>>>>> www.stegen.com
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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
>>>> 
>> 
>> On Feb 14, 2012, at 6:05 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>> 
>>> 
>>> Would it be easier to 'fix' the issue by just setting bit4 high in can_databuffer[1] of 0x96 if the chargestate was 'preparing' or 'heating'?
>>> 
>>> It would make it easier for the Apps to handle.
>>> 
>>> Mark.
>>> 
>>> On 15 Feb 2012, at 10:51 AM, Jack West wrote:
>>> 
>>>> Michael and Mark,
>>>> 
>>>> I'm glad you were able to test this out and confirm Michael.  My car was too warm to test the heating cycle today.  I'm proposing the following and will test it out tonight or in the morning (as soon as my car chills out).
>>>> 
>>>> can.c
>>>> 
>>>> Line #243
>>>> Case 0x96:
>>>>   if ((car_charging) && !((can_databuffer[1] & 0x10) || (car_chargestate == 0x0f)))
>>>>      car_stopped = 1;
>>>>   car_charging = ((can_databuffer [1] & 0x10) || (car_chargestate == 0x0f));
>>>> 
>>>> And
>>>> 
>>>> Line #229
>>>> case 0x95:
>>>> if (car_chargestate = = 0x0f) // heating state is treated as charging
>>>>    car_charging = 1;
>>>> 
>>>> Jack
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Feb 14, 2012, at 3:43 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>>>> 
>>>>> 
>>>>> Bizarre. I guess they don't count it as 'charging' until current is going into the pack directly (as opposed to coming out of the wall).
>>>>> 
>>>>> I converted your logs (thanks) to roadster_can.pl compatible format, and it all looks quite clean. There are some very strange message states (in particular, the percentage jumps all over the place), but I don't see any unexpected charging->notcharging->charging transitions. Charging is OFF for the whole of the 0-49 log, and only goes on after pre-heat in the 100 log.
>>>>> 
>>>>> The 0-49 log shows:
>>>>> 
>>>>> 0.0 100 95 0D 07 64 A4 01 16 00    ->VDS Charger v1.5 (preparing-to-charge) (conn-pwr-cable) (standard)
>>>>>  ...
>>>>> 0.0 100 96 2C 00 02 21 38 00 00    ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C)
>>>>> 0.0 100 95 0F 0B 31 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 00 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 18 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 00 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 18 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 31 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 15 03 64 A4 01 16 00    ->VDS Charger v1.5 (stopped-charging) (by-request) (standard)
>>>>> 0.0 100 96 2C 00 02 21 38 00 00    ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C)
>>>>> 
>>>>> The 100 log shows:
>>>>> 
>>>>> 0.0 100 95 15 03 64 A4 01 16 00    ->VDS Charger v1.5 (stopped-charging) (by-request) (standard)
>>>>> 0.0 100 95 0F 0B 31 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 00 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 31 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 00 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 00 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 31 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 95 0F 0B 63 A4 01 16 00    ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard)
>>>>> 0.0 100 96 2C 00 02 21 38 00 00    ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C)
>>>>> 0.0 100 95 0D 01 64 A4 01 16 00    ->VDS Charger v1.5 (preparing-to-charge) (??sub-state?? 1) (standard)
>>>>> 0.0 100 96 2C 00 02 21 38 00 00    ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C)
>>>>> 0.0 100 95 01 05 64 A4 01 16 00    ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard)
>>>>> 0.0 100 96 3C 00 02 21 38 00 00    ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: true) (bits 3C)
>>>>> 0.0 100 95 01 05 64 A4 01 16 00    ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard)
>>>>> 
>>>>> [ side note - it seems the pilot does go false at some points in your logs ]
>>>>> 
>>>>> Regards, Mark.
>>>>> 
>>>>> On 14 Feb, 2012, at 7:01 PM, Michael Stegen wrote:
>>>>> 
>>>>>> Mark, Jack,
>>>>>> 
>>>>>> I can confirm that the charging bit is not set when pre-heating the battery.
>>>>>> It's only set when it goes from pre-heating to charging.
>>>>>> 
>>>>>> Maybe we should just look at the State (0x95) instead of charging bit (0x96) and state.
>>>>>> 
>>>>>> I have uploaded my logfiles fom when i did the test here:
>>>>>> http://www.stegen.com/pub/bat_heating.rar
>>>>>> 
>>>>>> Inside the rar archive are two logfiles, one pre-heats till 49% then i press stop from the VDS.
>>>>>> The otherone pre-heats till 100%, and then the charging begins.
>>>>>> 
>>>>>> Note that the "preparing to charge" state is also entered after the pre-heating ended and before the actual charging starts.
>>>>>> 
>>>>>> -Michael
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Op 14-2-2012 4:01, Mark Webb-Johnson schreef:
>>>>>>> Urgh.
>>>>>>> 
>>>>>>> I think we really need to get a good trace of what you are seeing.
>>>>>>> 
>>>>>>> Is it possible for you to run the 1.2.0-rc3 code in the car, using 202.52.42.80 server, do a full charge (including pre-heat), then let me know UTC time it started? If possible, check up on it with an App during the charge (when an App is connected, the car reports in once every minute - otherwise only once every ten minutes). I have a full log running on the development server at the moment, and 1.2.0 code sends the detailed charging bytes as well as the summary status text.
>>>>>>> 
>>>>>>> Regards, Mark.
>>>>>>> 
>>>>>>> On 14 Feb 2012, at 2:22 AM, Jack West wrote:
>>>>>>> 
>>>>>>>> Mark,
>>>>>>>> 
>>>>>>>> One possibility that might explain what I saw:
>>>>>>>> 
>>>>>>>> In heating substate the car does not turn on b4 of B2 in 0x96. Therefore logic does not see the car as charging when in the heating state so flags are not set, etc.
>>>>>>>> 
>>>>>>>> I'll look into this in more detail tonight.
>>>>>>>> 
>>>>>>>> Jack
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Stegen Electronics
>>>>>> Kwartslaan 95
>>>>>> 3162 RD Rhoon
>>>>>> The Netherlands
>>>>>> 
>>>>>> Tel:    +31 10-5016960
>>>>>> Skype:   stegen.com
>>>>>> www.stegen.com
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20120215/6cae098f/attachment.htm>

More information about the OvmsDev mailing list