[Ovmsdev] Power usage / sleep mode
Michael Balzer
dexter at expeedo.de
Tue Jan 29 23:45:54 HKT 2013
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130129/838efe08/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/20130129/838efe08/attachment-0002.vcf>
More information about the OvmsDev
mailing list