[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