mirror of
https://github.com/mikecarper/MeshCore.git
synced 2026-10-29 03:32:22 +00:00
deploy: 3881345992
This commit is contained in:
mikecarper committed
1 parent
c56be78fdb
commit
d66a35bb52
3 files changed
+145
-12
No files matched your search
@@ -2285,6 +2285,17 @@
|
||||
<nav class="md-nav" aria-label="Radio">
|
||||
<ul class="md-nav__list">
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#select-mcu-and-lora-regulator-modes" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Select MCU and LoRa regulator modes
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#view-or-change-this-nodes-radio-parameters" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
@@ -5255,6 +5266,17 @@
|
||||
<nav class="md-nav" aria-label="Radio">
|
||||
<ul class="md-nav__list">
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#select-mcu-and-lora-regulator-modes" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Select MCU and LoRa regulator modes
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#view-or-change-this-nodes-radio-parameters" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
@@ -8403,6 +8425,38 @@ capacity. Remote use follows the existing administrator-command permissions.</p>
|
||||
<hr />
|
||||
<h2 id="configuration">Configuration</h2>
|
||||
<h3 id="radio">Radio</h3>
|
||||
<h4 id="select-mcu-and-lora-regulator-modes">Select MCU and LoRa regulator modes</h4>
|
||||
<pre><code class="language-text">get mcu.regulator
|
||||
set mcu.regulator auto|dcdc|ldo
|
||||
get radio.regulator
|
||||
set radio.regulator auto|dcdc|ldo
|
||||
reboot
|
||||
</code></pre>
|
||||
<p>These are independent controls. <code>auto</code> follows the board's existing default;
|
||||
<code>dcdc</code> requests its switching regulator and <code>ldo</code> requests its linear regulator.
|
||||
Settings are saved for the next reboot. The getter reports the saved choice,
|
||||
active mode, automatic fallback, crash streak and whether recovery is available.
|
||||
Setting a mode again, including the same value, clears that regulator's learned
|
||||
fallback and crash streak. The other regulator keeps its settings.</p>
|
||||
<p>Choices depend on the board's verified circuit. MCU selection is available on
|
||||
nRF52 boards that already initialize their supported REG1 DC-DC regulator; it
|
||||
does not control REG0, an external PMIC, or ESP32/RP2040 processor regulators.
|
||||
Radio selection covers supported SX1262, LR1110/LR1121 and Meshnology W12 LR2021
|
||||
implementations. A board with only verified LDO support rejects <code>dcdc</code>.
|
||||
Unverified LR2021 switching-regulator circuits retain their existing mode.</p>
|
||||
<p>On platforms with retained crash recovery, three consecutive qualifying crashes
|
||||
while a domain is using DC-DC select LDO for that domain on the next boot.
|
||||
Each crash requires a valid last battery sample of at least 50%, no more than
|
||||
60 seconds old at the last heartbeat. Low/unknown battery readings, stale
|
||||
samples, ordinary reboots, sleep wakes and unknown reset causes break the
|
||||
streak. Five minutes of healthy operation also clears the streak; a later crash
|
||||
starts a new one. LDO fallback stays selected until a mode is explicitly set
|
||||
again; recovery never switches back to DC-DC automatically.</p>
|
||||
<p>ESP32 WebConfig shows <strong>Power regulators</strong> under <strong>Radio → Advanced</strong> when
|
||||
supported, with separate processor/radio choices and active/fallback status.
|
||||
Only supported options are offered. <strong>Clear fallback on restart</strong> reapplies the
|
||||
current choice through the normal save flow. Saving either control restarts the
|
||||
node after the save succeeds. See <a href="../power_saving_diagnostics/#user-selectable-regulators-and-crash-recovery">regulator recovery and hardware checks</a>.</p>
|
||||
<h4 id="view-or-change-this-nodes-radio-parameters">View or change this node's radio parameters</h4>
|
||||
<p><strong>Usage:</strong>
|
||||
- <code>get radio</code>
|
||||
|
||||
@@ -2313,6 +2313,34 @@
|
||||
</span>
|
||||
</a>
|
||||
|
||||
<nav class="md-nav" aria-label="Board regulator initialization">
|
||||
<ul class="md-nav__list">
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#user-selectable-regulators-and-crash-recovery" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
User-selectable regulators and crash recovery
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#existing-board-defaults" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
Existing board defaults
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
</nav>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
@@ -2471,12 +2499,62 @@ that hardware arrangement, not a normal RAK4631 image. This startup change has
|
||||
host regression tests; sleep-current improvement still needs matched current
|
||||
measurements on the physical core/module combination.</p>
|
||||
<h2 id="board-regulator-initialization">Board regulator initialization</h2>
|
||||
<p>RAK4631 Companion uses the same nRF52840 REG1 DC/DC initialization as the other
|
||||
RAK4631 roles. The former Companion-only force-LDO flag has been removed. This
|
||||
does not change REG0, the SX1262 regulator, storage layout, or boot-voltage
|
||||
protection. The shared initializer uses the SoftDevice API when BLE's stack is
|
||||
already active and the hardware register otherwise; Companion starts the board
|
||||
before it starts Bluetooth.</p>
|
||||
<h3 id="user-selectable-regulators-and-crash-recovery">User-selectable regulators and crash recovery</h3>
|
||||
<p><code>mcu.regulator</code> and <code>radio.regulator</code> independently select <code>auto</code>, <code>dcdc</code> or
|
||||
<code>ldo</code> where the board supports those modes. <code>auto</code> preserves its existing board
|
||||
default. The choice is saved and takes effect after <code>reboot</code>; the two getters
|
||||
show requested/active mode, fallback, crash count and recovery availability.
|
||||
An explicit setter clears the corresponding fallback and streak, even when the
|
||||
same value is saved again. See the <a href="../cli_commands/#select-mcu-and-lora-regulator-modes">CLI commands</a>.</p>
|
||||
<p>Processor selection applies to the existing, circuit-supported nRF52 REG1
|
||||
DC-DC path. It does not select REG0, change an external PMIC, or expose an
|
||||
ESP32/RP2040 CPU regulator control. Radio controls apply to the supported
|
||||
SX1262, LR1110/LR1121 and Meshnology W12 LR2021 implementations. DC-DC is offered
|
||||
only when that board's regulator circuit is supported. LDO-only boards reject
|
||||
<code>dcdc</code>; unverified LR2021 switching circuits keep their existing mode.</p>
|
||||
<p>Integrated STM32WL targets retain their existing supply configuration. Their
|
||||
MCU and radio share the regulator, so independent selections need a coordinated
|
||||
implementation and board circuit verification before they can be offered.</p>
|
||||
<p>Automatic recovery uses reset-retained RAM on supported platforms. A domain
|
||||
must have been armed in DC-DC mode before the crash, with a valid last battery
|
||||
sample of at least <strong>50%</strong>, no more than <strong>60 seconds</strong> old at its last
|
||||
heartbeat. The <strong>third consecutive qualifying crash</strong> selects LDO before that
|
||||
domain starts again and saves the fallback. MCU and radio streaks are separate;
|
||||
if both were using DC-DC during the same qualifying failures, both can fall
|
||||
back. This is a recovery action, not proof that a regulator caused the crashes.</p>
|
||||
<p>Low/unknown battery, stale samples, cold starts, intentional reboots, sleep
|
||||
wakes and unclassified resets break a streak. Corrupt retained state cannot
|
||||
add a crash. <strong>Five healthy minutes</strong> clear the running streak; a later crash
|
||||
starts a new one. The saved LDO fallback survives normal resets and power
|
||||
cycles. It stays in LDO until a user explicitly selects a mode again, with no
|
||||
automatic return to DC-DC. Crash bookkeeping stays in retained RAM rather than
|
||||
writing flash at every heartbeat.</p>
|
||||
<p>Battery eligibility follows the board's battery measurement and configured
|
||||
percentage curve. USB supply voltage alone does not establish that a physical
|
||||
battery is at 50%; validate battery-only starts and the board's absent-battery
|
||||
reading when qualifying recovery. Boards without a trustworthy battery reading
|
||||
should report it invalid. A getter reporting recovery unavailable still permits
|
||||
supported manual mode selection.</p>
|
||||
<p>ESP32 WebConfig exposes supported controls under <strong>Radio → Advanced → Power
|
||||
regulators</strong>, showing active mode and fallback status. Unsupported domains and
|
||||
DC-DC options are hidden. Saving reboots only after the authenticated save
|
||||
completes successfully. <strong>Clear fallback on restart</strong> lets a user retry the
|
||||
current saved mode without first choosing a different one.</p>
|
||||
<p>For hardware qualification, compare both modes with battery-only cold starts,
|
||||
normal reboots, sleep/wake, BLE/WiFi and radio TX/RX under load. Confirm that
|
||||
three injected qualifying watchdog/fault resets select LDO, that fewer than
|
||||
three and low/unknown-battery resets do not, and that an explicit setter restores
|
||||
the requested choice. Also check current consumption and voltage during TX;
|
||||
native recovery tests and successful firmware builds do not establish these
|
||||
physical results.</p>
|
||||
<h3 id="existing-board-defaults">Existing board defaults</h3>
|
||||
<p>RAK4631 Companion shares the nRF52840 REG1 regulator path with the other
|
||||
RAK4631 roles. <code>auto</code> preserves its DC-DC default; the former Companion-only
|
||||
force-LDO flag has been removed. Saved mode selection is deferred until board
|
||||
ADC and primary filesystem initialization are complete, before display, radio
|
||||
and wireless startup. This retains boot-voltage protection and keeps REG0 and
|
||||
storage layout unchanged. The shared initializer uses the SoftDevice API when
|
||||
BLE's stack is already active and the hardware register otherwise.</p>
|
||||
<p><a href="https://docs.rakwireless.com/product-categories/wisduo/rak4630-module/quickstart/">RAK documents DC/DC support</a>
|
||||
for the module. The related upstream <a href="https://github.com/meshcore-dev/MeshCore/issues/1878">battery-startup report #1878</a>
|
||||
concerned Repeater firmware, with BLE Companion reported working on an affected
|
||||
@@ -2484,8 +2562,8 @@ board. It did not establish filesystem corruption or a Companion-specific
|
||||
DC/DC failure. <a href="https://github.com/meshcore-dev/MeshCore/pull/1914">PR #1914</a>
|
||||
also changes boot-voltage/wakeup handling and is not proof that every failure
|
||||
in that thread has the same cause.</p>
|
||||
<p>Host startup tests cover both SoftDevice states and regulator selection before
|
||||
the boot-voltage check. Firmware compilation is not hardware qualification:
|
||||
<p>Host startup tests cover both SoftDevice states and deferred regulator selection
|
||||
with boot-voltage protection preserved. Firmware compilation is not hardware qualification:
|
||||
compare battery-only cold starts, low-voltage recovery, BLE operation and
|
||||
settings writes/reboots on the actual board/baseboard revisions before a fleet
|
||||
rollout. USB power can mask the reported startup symptoms. A current meter is
|
||||
@@ -2531,9 +2609,10 @@ external LDO, PMIC output, or radio regulator.</p>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>The startup tests execute each real <code>begin()</code> with SoftDevice off/on and power
|
||||
management compiled out/in. They require DC/DC before peripheral initialization
|
||||
and before any enabled boot-voltage check, while retaining one common board
|
||||
initialization. The previous bypass fails these tests.</p>
|
||||
management compiled out/in. Normal startup defers the selected mode until the
|
||||
saved settings and recovery state can be read, while retaining one common board
|
||||
initialization. The board class still defines the circuit-supported default;
|
||||
the settings layer applies it before display/radio startup.</p>
|
||||
<p>ThinkNode M3/M4/M6 and generic ProMicro remain unchanged pending exact circuit
|
||||
or physical-board confirmation; their DC/DC inheritance alone is not evidence.
|
||||
Nano G2 Ultra, ThinkNode M1/M8 and Keepteen LT1 retain their plain <code>NRF52Board</code>
|
||||
|
||||
@@ -1 +1 @@
|
||||
{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Home","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"#meshcore-documentation","title":"MeshCore documentation","text":"<p>Choose firmware with the firmware picker. For help with a device already in service, start with the FAQ.</p>"},{"location":"#current-release","title":"Current release","text":"<ul> <li>1.17.1.8 USA Cascade release notes</li> <li>Test Results \u2014 validation archive and 1.17.1.8 Preview 1 qualification evidence</li> </ul>"},{"location":"#documentation","title":"Documentation","text":"<ul> <li>Feature switches by role and Full Companion features</li> <li>Firmware update guide, easy LoRa OTA, and scripted LoRa OTA</li> <li>CLI commands, availability by build, and radio profiles</li> <li>Private fleet management: signed filtering and secondary-radio commands for a fleet or one node</li> <li>Room history, moderation, and information board: optional persistent chat and local Wi-Fi room access</li> <li>Companion protocol, packet format, and QR codes</li> </ul> <p>The navigation groups the remaining guides under Documentation, including board-specific updates, networking, power, and protocol references.</p>"},{"location":"#tools","title":"Tools","text":"<ul> <li>Firmware picker and USB web console</li> <li>Notification builder and temporary radio test builder</li> <li>Filter policy playground, telemetry decoder, and management report decoder</li> </ul>"},{"location":"#engineering-records","title":"Engineering records","text":"<ul> <li>Research \u2014 design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases \u2014 historical release notes and supporting files</li> </ul> <p>Found a mistake or missing information? Edit the documentation.</p>"},{"location":"WiFi/","title":"WiFi","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"WiFi/#wifi-and-mqtt-by-firmware-type","title":"WiFi and MQTT by Firmware Type","text":"<p>MeshCore itself does not require WiFi or the internet. LoRa packet exchange, repeating, room servers, companions, and sensors can all operate without either. WiFi is added by particular ESP32 firmware targets for one or more of these purposes:</p> <ul> <li>a TCP connection between a WiFi companion and a phone or computer;</li> <li>the WebConfig browser interface;</li> <li>MQTT uplinking from the radio to internet or LAN brokers;</li> <li>WiFi-assisted OTA services on builds that include them;</li> <li>ESP-NOW bridging, which uses the ESP32's 2.4 GHz radio but is not a connection to a WiFi access point.</li> </ul> <p>The firmware role and the build profile are separate choices. USB logging does not itself provide MQTT. MQTT-capable Full Companions include that feature without <code>mqtt</code> in their filename; check the artifact capability manifest. See feature switches by role for the different Companion and infrastructure controls and the USB web console.</p>"},{"location":"WiFi/#quick-reference","title":"Quick reference","text":"Firmware target or role Infrastructure WiFi MQTT What WiFi does <code>*_repeater</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_repeater_observer_mqtt</code> Yes Yes Uplinks heard and selected transmitted LoRa packets; repeating remains enabled by default <code>*_room_server</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_room_server_observer_mqtt</code> Yes Yes Runs the room server and uplinks radio traffic <code>*_companion_radio_wifi</code> Yes No Exposes the MeshCore companion protocol on TCP port 5000 <code>*_companion_radio_wifi_mqtt</code> Yes Yes Runs both the TCP companion interface and the MQTT uplink <code>*_companion_radio_full*</code> ESP32, subject to board/transport selection Where compiled on ESP32 Includes supported USB/wireless transports; configure MQTT through WebConfig Dedicated USB, BLE, or serial companion (not Full) No No Uses the transport named by the target instead <code>*_repeater_bridge_espnow</code> Build-dependent on ESP32 No Uses ESP-NOW for its bridge; <code>bridge.format wrapped|raw</code> selects legacy bridge framing or primary-ESP-NOW compatibility; a FULL build also exposes the TCP 5001 LoRa-OTA seeder whenever WiFi is usable RS232 bridge No No Bridges through a serial interface Ethernet repeater/room server No WiFi No Uses wired Ethernet for its role-specific network interface <code>*_sensor</code> Build-dependent on ESP32 No A FULL ESP32 sensor can expose the TCP 5001 LoRa-OTA seeder through its browser-OTA setup AP Terminal-chat or KISS modem No in current targets No Uses LoRa and its role-specific local interface <code>*_lora_ota_no_external_sensors</code> On demand on ESP32 No LeaLine truncated
|
||||
{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Home","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"#meshcore-documentation","title":"MeshCore documentation","text":"<p>Choose firmware with the firmware picker. For help with a device already in service, start with the FAQ.</p>"},{"location":"#current-release","title":"Current release","text":"<ul> <li>1.17.1.8 USA Cascade release notes</li> <li>Test Results \u2014 validation archive and 1.17.1.8 Preview 1 qualification evidence</li> </ul>"},{"location":"#documentation","title":"Documentation","text":"<ul> <li>Feature switches by role and Full Companion features</li> <li>Firmware update guide, easy LoRa OTA, and scripted LoRa OTA</li> <li>CLI commands, availability by build, and radio profiles</li> <li>Private fleet management: signed filtering and secondary-radio commands for a fleet or one node</li> <li>Room history, moderation, and information board: optional persistent chat and local Wi-Fi room access</li> <li>Companion protocol, packet format, and QR codes</li> </ul> <p>The navigation groups the remaining guides under Documentation, including board-specific updates, networking, power, and protocol references.</p>"},{"location":"#tools","title":"Tools","text":"<ul> <li>Firmware picker and USB web console</li> <li>Notification builder and temporary radio test builder</li> <li>Filter policy playground, telemetry decoder, and management report decoder</li> </ul>"},{"location":"#engineering-records","title":"Engineering records","text":"<ul> <li>Research \u2014 design notes, diagnostics, and historical update-chain studies</li> <li>Old Releases \u2014 historical release notes and supporting files</li> </ul> <p>Found a mistake or missing information? Edit the documentation.</p>"},{"location":"WiFi/","title":"WiFi","text":"<p>View this page on MeshCore Docs.</p>"},{"location":"WiFi/#wifi-and-mqtt-by-firmware-type","title":"WiFi and MQTT by Firmware Type","text":"<p>MeshCore itself does not require WiFi or the internet. LoRa packet exchange, repeating, room servers, companions, and sensors can all operate without either. WiFi is added by particular ESP32 firmware targets for one or more of these purposes:</p> <ul> <li>a TCP connection between a WiFi companion and a phone or computer;</li> <li>the WebConfig browser interface;</li> <li>MQTT uplinking from the radio to internet or LAN brokers;</li> <li>WiFi-assisted OTA services on builds that include them;</li> <li>ESP-NOW bridging, which uses the ESP32's 2.4 GHz radio but is not a connection to a WiFi access point.</li> </ul> <p>The firmware role and the build profile are separate choices. USB logging does not itself provide MQTT. MQTT-capable Full Companions include that feature without <code>mqtt</code> in their filename; check the artifact capability manifest. See feature switches by role for the different Companion and infrastructure controls and the USB web console.</p>"},{"location":"WiFi/#quick-reference","title":"Quick reference","text":"Firmware target or role Infrastructure WiFi MQTT What WiFi does <code>*_repeater</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_repeater_observer_mqtt</code> Yes Yes Uplinks heard and selected transmitted LoRa packets; repeating remains enabled by default <code>*_room_server</code> Build-dependent on ESP32 No FULL builds provide WebConfig, browser OTA, and the TCP 5001 LoRa-OTA seeder while WiFi is active <code>*_room_server_observer_mqtt</code> Yes Yes Runs the room server and uplinks radio traffic <code>*_companion_radio_wifi</code> Yes No Exposes the MeshCore companion protocol on TCP port 5000 <code>*_companion_radio_wifi_mqtt</code> Yes Yes Runs both the TCP companion interface and the MQTT uplink <code>*_companion_radio_full*</code> ESP32, subject to board/transport selection Where compiled on ESP32 Includes supported USB/wireless transports; configure MQTT through WebConfig Dedicated USB, BLE, or serial companion (not Full) No No Uses the transport named by the target instead <code>*_repeater_bridge_espnow</code> Build-dependent on ESP32 No Uses ESP-NOW for its bridge; <code>bridge.format wrapped|raw</code> selects legacy bridge framing or primary-ESP-NOW compatibility; a FULL build also exposes the TCP 5001 LoRa-OTA seeder whenever WiFi is usable RS232 bridge No No Bridges through a serial interface Ethernet repeater/room server No WiFi No Uses wired Ethernet for its role-specific network interface <code>*_sensor</code> Build-dependent on ESP32 No A FULL ESP32 sensor can expose the TCP 5001 LoRa-OTA seeder through its browser-OTA setup AP Terminal-chat or KISS modem No in current targets No Uses LoRa and its role-specific local interface <code>*_lora_ota_no_external_sensors</code> On demand on ESP32 No LeaLine truncated
|
||||
Reference in new issue
Block a user