[Ovmsdev] Introducing myself and questions on deep sleep

[Michael Balzer]

Welcome, Patrick :-)

@others: Patrick is jollyjinx on Github, he posted his 12V findings 
first in issue #711:
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/711#issuecomment-1099895336

The BMW i3 is unique in not charging the 12V battery by itself while 
parked, it needs to be plugged in to enable trickle charging. The i3's 
12V battery is also rated at a mere 20 Ah when new.

Am 12.11.22 um 09:20 schrieb Patrick Stein:
> As I’m only interested in live data while driving/charging and the 12v battery of the i3 is not charged while parked I would like to have the ovms module sleep when the car is parked - so the battery does not drain as much. I have to add that I can’t charge the car at home or work.
>
> My current OVMS quest is to get deep sleep working correctly.
As written in the issue discussion, there's a minimum load from the 
unswitchable components. In deep sleep mode, that's around 155 mW with 
the GPS antenna attached, and ~ 100 mW with GPS antenna detached. An 
option to control the GPS antenna could be using a simple 12V relay, 
either on SW_12V or on the ignition 12V line, to switch the antenna's 
GND connection.

Assuming you do that, deep sleep will reduce the consumption to ~ 100 mW 
/ 8-9 mA at 12 V, that should give you a minimum parking time of 46 days 
when assuming you shouldn't take more than 10 Ah out of the battery to 
avoid trouble.

> the module sometimes does not recognize it’s coming out of deep sleep and will fully boot and then go to sleep cause the battery level is too low. This is only happening when NOT connected to the serial port (bad for debugging).#
Did you try using a USB cable with the Vcc line (pin 1) cut?

> I started to pack the calibration and wakeup voltage in a RTC_DATA_ATTR variable before sleep and immediately check it ovms_boot.c . That helped but it sometimes RTC_DATA_ATTR would be empty even though I set it the last line before going to sleep.
> Then I thought ok, when the deep sleep is somewhat faulty, let the module go to sleep as early as possible in the boot process, so as soon as we have the configuration data with the calibration voltage and sleep then.
> That works ok, but the problem is, that in the boot process the cellular modem is powered on and stays on when going to deep sleep. So I decided to power off the cellular modem, but that will sometimes crash.
>
> So my questions:
>
> 1. Why does the module forget that it was in deep sleep before ? Is it the esp32 beeing faulty or something else ?
> 2. What would be the best way to immediately sleep again by reading the configuration without starting anything else - not even a second processor.

The ESP32 has quite its share of hardware bugs.

You could try RTC_NOINIT_ATTR instead, and you could try setting the RTC 
RAM power explicitly (esp_sleep_pd_config).

But I also found occasional RTC RAM corruptions even on normal reboots, 
that's why we do CRC checks on the boot data and persistent metrics.

A more reliable approach could be to disable the standard auto init when 
going to sleep (see config auto init). My suggestion would be to add a 
third 'wakeup' auto init mode that tells the system to first check if it 
actually should do a full boot or return to deep sleep.

That way you'll boot into the base operation mode and have access to the 
config store etc., while avoiding to power up optional components. If 
returning to sleep immediately, that would result in a necessary uptime 
of just ~ 5 seconds at base power consumption level.


> 3. Is this the mailing list still active ? I would rather use the forum, but the forum is not really usable.

The forum is meant for user support, developer discussions are done here 
and on github.

Regards,
Michael

> Best Regards, Patrick aka @jollyjinx
>
>
> P.S.: If I can get OVMS to work for me I might adopt it to my application which then makes it possible for a broader audience to use (not just the three users it currently has)  (currently it needs a backend where I’m using undocumented access to bmw servers, so I can’t open it up right now).

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20221113/202bf206/attachment-0001.sig>