[Ovmsdev] Power usage / sleep mode

Michael Balzer dexter at expeedo.de
Sat Feb 2 22:19:58 HKT 2013


I've added car_doors5 with a first definition as follows:

typedef struct {
   unsigned RearLeftDoor:1;
   unsigned RearRightDoor:1;
   unsigned Frunk:1;
   unsigned :1;
   unsigned Charging12V:1;
   unsigned :1;
   unsigned :1;
   unsigned :1;
} car_doors5bits_t;

(I also added bit field types for the doors vars)

Please note the Charging12V flag now needs to be set by the vehicle 
modules for the 12V reference / alert logic to work properly.

This commit also includes support for the parking timer on the Twizy.

Regards,
Michael


Am 31.01.2013 02:57, schrieb Mark Webb-Johnson:
> Michael,
>
> As the 'virtual car' originally came from the Tesla Roadster, those 
> bits are not really 'unused' - more accurately 'unknown'.
>
> I guess we could mask them off, in the Tesla Roadster module, but for 
> the sake of 1 byte, it seems better to keep the original Tesla 
> Roadster data unchanged.
>
> Regards, Mark.
>
> On 30 Jan, 2013, at 11:44 PM, Michael Balzer wrote:
>
>> Mark,
>>
>> what about the unused bits in doors1..4, it seems these are not 
>> currently in use:
>>
>> doors1 bit 5
>> doors2 bits 0..2 + 5
>> doors3 all except bit 1
>> doors4 all except bit 2
>>
>> That's 19 bits we could use for new flags, or am I missing something?
>>
>> Regards,
>> Michael
>>
>>
>> Am 30.01.2013 01:16, schrieb Mark Webb-Johnson:
>>> 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 <mailto: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 <mailto: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 <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130202/8a6047d1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dexter.vcf
Type: text/x-vcard
Size: 206 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130202/8a6047d1/attachment-0002.vcf>


More information about the OvmsDev mailing list