<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Patrick,<br>
<br>
<div class="moz-cite-prefix">Am 14.11.22 um 10:25 schrieb Patrick
Stein:<br>
</div>
<blockquote type="cite"
cite="mid:07CB9EF8-8BAA-450A-8A5B-80FC769DB914@jinx.de">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I’ve never seen such a low value - lowest I’ve seen is 250 mW in deep sleep with all my four modules. </pre>
</blockquote>
I did the measurements using a USB power meter, just verified with a
multimeter for 12V (11.6V Lipo), which gave slightly higher results:<br>
<ul>
<li>base load in Wifi mode, GPS antenna attached ~ 60 mA / 700 mW</li>
<li>sleep, GPS antenna attached ~ 16 mA / 180 mW</li>
<li>sleep, GPS antenna detached ~ 11 mA / 130 mW</li>
</ul>
<br>
So nowhere near 250 mW. Mark, any idea about this?<br>
<br>
<blockquote type="cite"
cite="mid:07CB9EF8-8BAA-450A-8A5B-80FC769DB914@jinx.de">
<pre class="moz-quote-pre" wrap="">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 ? </pre>
</blockquote>
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.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:07CB9EF8-8BAA-450A-8A5B-80FC769DB914@jinx.de">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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 ?</pre>
</blockquote>
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.<br>
<br>
The boot process basically consists of these phases:<br>
<ol>
<li>Hardware init (esp-idf bootloader)<br>
</li>
<li>Application init (static object inits in __attribute__
init_priority order) ending with the FreeRTOS scheduler start<br>
</li>
<li>Application start (entry point: app_main() in ovms_main.cpp)
(system is now in FreeRTOS mode)<br>
</li>
<li>Housekeeping init (starting dynamic components &
peripherals according to user configuration)<br>
</li>
</ol>
Every phase resets the log time to 0.<br>
<br>
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:<br>
<br>
<font face="monospace">…<br>
I (2081) cpu_start: Pro cpu start user code<br>
I (2086) spiram: Adding pool of 4096K of external SPI memory to
heap allocator<br>
I (92) ovms_main: Set default logging level for * to INFO<br>
I (93) ovms_main: Initialising WATCHDOG...<br>
I (93) ovms-duktape: Initialising DUKTAPE Registry (1000)<br>
I (100) command: Initialising COMMAND (1010)<br>
I (105) command: Expanding DUKTAPE javascript engine<br>
<b>I (110) boot: Initialising BOOT (1100)</b><br>
…</font><br>
<br>
Boot::Boot() is the static init of the MyBoot object, this is
executed quite early at init_priority 1100.<br>
<br>
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.<br>
<br>
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:<br>
<br>
<font face="monospace">…<br>
I (1050) ovms_main: Starting HOUSEKEEPING...<br>
I (1050) housekeeping: Initialising HOUSEKEEPING Framework...<br>
…<br>
</font><br>
Houskeeping init finishes with starting the USB console:<br>
<br>
<font face="monospace">I (2450) housekeeping: Starting USB
console...<br>
…<br>
Welcome to the Open Vehicle Monitoring System (OVMS) - Async
Console<br>
Firmware: 3.3.003-97-g5ccff7cf/factory/edge<br>
Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3<br>
OVMS> </font>
<br>
<br>
<br>
<blockquote type="cite"
cite="mid:07CB9EF8-8BAA-450A-8A5B-80FC769DB914@jinx.de">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<br>
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.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
</body>
</html>