[Ovmsdev] Power usage / sleep mode

Wed Jan 30 08:16:06 HKT 2013

Michael,

We have another signal:
unsigned char car_doors3 [bit 1]

This bit is set to 1 to indicate the vehicle is awake, and operational, else 0. For some cars, this would indicate that cooling systems are working, but for most cars it should just be set to 1 if the car is ‘awake’ in any way. 

On the roadster, that is set when the cooling pump is on, and all systems in the car are 'alive'.

Is that suitable for this?

If not, it is probably best to include a new car_door5 (which we need anyway for rear-left, rear-right door bits) and include a bit on that to signify 12V battery charging.

Regards, Mark.

On 29 Jan, 2013, at 11:45 PM, Michael Balzer wrote:

> Mark,
> 
> I completely misunderstood bit 3 "pilot present" as a driver detection (seat pressure), good you explained that now :-)
> 
> I may have been unclear. I tried to use bit 4 before, but the 12V battery charge process is decoupled from the main battery charge process. That's for the Twizy, of course, but I suppose that's on other cars as well, as it seems to make sense to charge the 12V battery independantly.
> 
> I first thought about extending the doors flags to introduce a separate "12V charging" flag, but then thought the combination car_linevoltage + car_chargecurrent normally implies this.
> 
> But "pilot signal present" is also not quite the same as "charging 12V"...
> 
> So, would you still say we can generally use bit 3 for this, or shall I rather introduce a new vehicle hook, as this needs to be vehicle dependant?
> 
> Thanks,
> Michael
> 
> 
> Am 29.01.2013 02:24, schrieb Mark Webb-Johnson:
>> Michael,
>> 
>> To determine if the car is charging or not, the best way is:
>> unsigned char car_doors1 [bit 4]
>> This bit is set to 1 if the vehicle is currently charging, else 0.
>> 
>> 
>> Alternatively, if you want to pickup "able to charge" rather than "charging":
>> unsigned char car_doors1 [bit 3]
>> 
>> This bit is set to 1 if the pilot signal is present, else 0. This would normally indicated that the vehicle is connected to external power and either charging or ready to charge. 
>> 
>> 
>> Seems a better solution than linevoltage/current.
>> 
>> Regards, Mark.
>> On 29 Jan, 2013, at 5:05 AM, Michael Balzer wrote:
>> 
>>> Done :-)
>>> 
>>> Also, as the Twizy (and I suppose other cars as well) charges the 12V battery further on as long as it's plugged in, I now use the plug in status (car_linevoltage + car_chargecurrent) to detect a 12V charge status.
>>> 
>>> After plug-out, the OVMS waits for 10 minutes (time for the 12V battery to calm down) until taking the new ref voltage. That will still be a bit above the nominal voltage, but the span should be short enough to allow for taking a new ref even if taking the car for the next drive soon after charging.
>>> 
>>> I hope this will work on other cars as well without change/config, but it will now need the car_linevoltage and car_chargecurrent reflecting the actual plugin status. If a car cannot provide this info, we can introduce a new vehicle hook for a function that checks for a valid calibration time.
>>> 
>>> Regards,
>>> Michael
>>> 
>>> 
>>> Am 26.01.2013 22:05, schrieb Michael Balzer:
>>>> I've got a flaw in there: as the code begins taking ref max values right after charging ends, the ref gets too high. After charging my current ref is now 14.7 due to that bug, should be around 12.7. 
>>>> 
>>>> I need to factor in the voltage decay after end of charge. I'll see if I can get that in without introducing a new timer variable... 
>>>> 
>>>> @Mikeljo: "> 13" is correct (just ensures ref-13 > 0), your change to "> 130" is not correct, as the ref can be much lower. 
>>>> ...also consider using stp_l2f() for the STAT message, see the DIAG message for a copy source. 
>>>> 
>>>> I really should document the stp functions... 
>>>> 
>>>> Regards, 
>>>> Michael 
>>>> 
>>>> 
>>>> Am 25.01.2013 17:16, schrieb Mark Webb-Johnson: 
>>>>> Michael, 
>>>>> 
>>>>> Seems like a sensible approach. 
>>>>> 
>>>>> Your car is now showing "11.9,0,12.2". 
>>>>> 
>>>>> I'll try it in my car over the weekend. 
>>>>> 
>>>>> Regards, Mark. 
>>>>> 
>>>>> On 25 Jan, 2013, at 9:16 PM, Michael Balzer <dexter at expeedo.de> wrote: 
>>>>> 
>>>>>> Mark, Tom, 
>>>>>> 
>>>>>> I just checked in the auto calibration implementation. 
>>>>>> 
>>>>>> It works by taking the maximum voltage reading while the car is off and not charging as the reference voltage, so it should adapt to all possible variations. 
>>>>>> 
>>>>>> Alert is triggered if current reading is at/below ref - 1.3V, which should fit for all cases. 
>>>>>> 
>>>>>> The alert now also includes the reference, and it can be queried by the "DIAG" SMS command. It's also now included as a new field in the environment message ("D"). 
>>>>>> 
>>>>>> Regards, 
>>>>>> Michael 
>>>>>> 
>>>>>> 
>>>>>> Am 22.01.2013 04:19, schrieb Mark Webb-Johnson: 
>>>>>>> Tom, 
>>>>>>> 
>>>>>>> My understanding is that the 2.x cars work the same way. The 12V battery is just for emergency systems. 
>>>>>>> 
>>>>>>> Presumably if the main pack fails (fuse blows, whatever), the 1.5 cars have no way of running hazard warning lights, brake lights, etc. 
>>>>>>> 
>>>>>>> It would still be useful to see the stability of that 12V line, on the v1.5 Tesla Roadsters. 
>>>>>>> 
>>>>>>> Regards, Mark. 
>>>>>>> 
>>>>>>> On 21 Jan, 2013, at 12:48 AM, Tom Saxton <tom at idleloop.com> wrote: 
>>>>>>> 
>>>>>>>> on 1/19/13 10:08 PM, Mark Webb-Johnson wrote: 
>>>>>>>> 
>>>>>>>>> If anyone has a 1.x roadster with a v2 hardware module, and has recently 
>>>>>>>>> parked it for some days, it would be helpful if you could send me the 
>>>>>>>>> date/time range and your vehicleid. 
>>>>>>>> I don't think the v1.5 Roadster has a 12V battery. It's my understanding 
>>>>>>>> that it uses a DC-to-DC converter on one of the ESS sheets to power the 12V 
>>>>>>>> systems when the car is off. 
>>>>>>>> 
>>>>>>>>     Tom 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________ 
>>>>>>>> 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 
>>>>>> -- 
>>>>>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal 
>>>>>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 
>>>>>> 
>>>>>> <dexter.vcf>_______________________________________________ 
>>>>>> 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
>>> 
>>> -- 
>>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>> <dexter.vcf>_______________________________________________
>>> 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
> 
> -- 
> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
> <dexter.vcf>_______________________________________________
> 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/20130130/c141db11/attachment.htm>