[Ovmsdev] Can.c heating state update
Jack West
jackduncanwest at gmail.com
Sat Feb 18 04:20:50 HKT 2012
Mark and Michael, others,
I tested the following changes to can.c in my cold car:
case 0x95:
.
.
if ((car_chargestate >= 0x0d) && (car_stopped)) //change test to include preparing.
{ //when heating fails state goes to preparing, not stopped
car_stopped = 0;
net_notify_status;
}
.
.
case 0x96:
if (car_chargestate == 0x0f)
can_databuffer[1] |= 0x10; //make heating state look like charging
I also added a heating case to net_msg_alert
I did this to test:
Open charge port, plug in car. App shows charge port open
Slide pilot on
SMS STAT = charging, heating
APP = shows normal 'non charging' screen
VDS = heating % complete (heating at 7amps/240V)
Slide pilot off //simulate failure
APP = standard, preparing (alert). //would be nice to see 'charging stopped'
SMS = charging, preparing (alert)
Slide pilot on
APP = shows normal non charging screen. // would be nice to see 'charging, heating'
SMS = no alerts
SMS STAT = charging, heating
It seems this could be better. Would be nice if heating state showed up as charging on apps. I'm not sure what happens if I heat to 100% and begin charging because if I do that then I can't test the cold car state. I realize that heating is a state that will affect only a very few users but I'm certainly one of those and I'm willing to keep plugging away at it. Any suggestions will be appreciated, as always.
Jack
On Feb 15, 2012, at 11:45 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>
> Temperature here would have to drop 25celcius or more for me to be able to test ;-) That said, I here we're going to have a cold snap this weekend - it will perhaps drop to +15celcius or lower...
>
> Then again, I'm interested in seeing what is going to happen in a couple of months when we reach 35celcius ambient here. Is there a mysterious "Cooling" state?
>
> Mark.
>
> On 16 Feb 2012, at 4:35 PM, Jack West wrote:
>
>> 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
>
> _______________________________________________
> 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/20120217/5676de9d/attachment.htm>
More information about the OvmsDev
mailing list