@Michael: Thanx for all your answers - that helps me a lot. With your pointers I’ve started looking into esp documentation and found the *esp_get_deep_sleep_wake_stub* which would be exactly that kind of thing to run before the boot process, but using it does not work - it wakes from deepsleep and then enters a reset as it looks: ``` I (1491) 12battery: sleepImmediately()2 I (1491) 12battery: sleepImmediately()3 I (4501) 12battery: sleepImmediately()4 ets Jul 29 2019 12:21:46 rst:0x5 (DEEPSLEEP_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) ets Jul 29 2019 12:21:46 rst:0x7 (TG0WDT_SYS_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 ``` I found that there was a bugfix for a sleep not using the wake stub code in https://github.com/espressif/esp-idf/issues/5983 and it seems the fix in https://github.com/espressif/esp-idf/commit/ff8d05466e83049bca44e1584891bfaf... is not OVMS. Maybe that’s also the problem with the buggy coming out of deepsleep behaviour with OVMS as well ? Are there so many changes in OVMS esp_idf part that OVMS can’t use the newest (presumably less buggy?) version of esp_idf ? Excuse my newbie questions - I’m not used to embedded programming or esp development. Regards, Patrick aka @jollyjinx
On 14. Nov 2022, at 17:26, Michael Balzer <dexter@expeedo.de> wrote:
Patrick,
Am 14.11.22 um 10:25 schrieb Patrick Stein:
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.
I’ve never seen such a low value - lowest I’ve seen is 250 mW in deep sleep with all my four modules. I did the measurements using a USB power meter, just verified with a multimeter for 12V (11.6V Lipo), which gave slightly higher results: • base load in Wifi mode, GPS antenna attached ~ 60 mA / 700 mW • sleep, GPS antenna attached ~ 16 mA / 180 mW • sleep, GPS antenna detached ~ 11 mA / 130 mW
So nowhere near 250 mW. Mark, any idea about this?
About the 12v antenna switch that would make total sense to me to be able to switch that on/off. I can solder and have the equipment, but I’m not really into hardware modding. Can someone point me on what wires on the board need to be modified for that ? I meant making your own external GPS antenna cable including the relay. Within the module you could use a custom pigtail cable, but I wouldn't recommend that, as these are fragile.
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.
Thanx for pointing that out - remember I’m new to OVMS I just got the development environment working on my arm mac natively. I have to learn on how the boot process works - I thought it would start in ovms_boot, but other code runs before. your mention of config auto init means the make menuconfig process ? No, I mean the OVMS AutoInit system. The main controller for that is Housekeeping::Init(), which reads the config and calls the AutoInit() methods of the components enabled.
The boot process basically consists of these phases: • Hardware init (esp-idf bootloader) • Application init (static object inits in __attribute__ init_priority order) ending with the FreeRTOS scheduler start • Application start (entry point: app_main() in ovms_main.cpp) (system is now in FreeRTOS mode) • Housekeeping init (starting dynamic components & peripherals according to user configuration) Every phase resets the log time to 0.
In the boot log, you can identify phase 2 begin/end by the "cpu_start" log lines, with the static object (object factory) inits logging their invocations including their init priority:
… I (2081) cpu_start: Pro cpu start user code I (2086) spiram: Adding pool of 4096K of external SPI memory to heap allocator I (92) ovms_main: Set default logging level for * to INFO I (93) ovms_main: Initialising WATCHDOG... I (93) ovms-duktape: Initialising DUKTAPE Registry (1000) I (100) command: Initialising COMMAND (1010) I (105) command: Expanding DUKTAPE javascript engine I (110) boot: Initialising BOOT (1100) …
Boot::Boot() is the static init of the MyBoot object, this is executed quite early at init_priority 1100.
This is the place we currently check if the 12V level is sufficient when waking up from deep sleep. From here we can go back to sleep immediately, but cannot yet access the config store.
Phase 3 (app_main()) starts with logging "ovms_main: Executing on CPU core 0", then essentially mounts the configuration partition "/store" and hands over control to Housekeeping:
… I (1050) ovms_main: Starting HOUSEKEEPING... I (1050) housekeeping: Initialising HOUSEKEEPING Framework... …
Houskeeping init finishes with starting the USB console:
I (2450) housekeeping: Starting USB console... … Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console Firmware: 3.3.003-97-g5ccff7cf/factory/edge Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3 OVMS>
Maybe it’s easiest to put a separate esp32board in front of the OVMS module to only switch on OVMS when battery level is high enough - maybe board designers can think of really low power deep sleep in the next interation of the OVMS module.
Sure. Or you could use an OBD cable with a manual power switch. Or you could use an OBD cable that connects to a 12V source that's switched by the car.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev