deploy: d66b9336a9

radio_chirp_math_validation/index.html

@@ -3042,11 +3042,14 @@
 <h1 id="shared-radioradio2-chirp-timing-and-preamble-warnings">Shared radio/radio2 chirp timing and preamble warnings</h1>
 <p>Historical validation record: the nominal 600 us policy described below has
 been replaced by the activation self-test and 10% guarded measured budget.
+The later automatic policy also removed the pair-specific 88-symbol SF8/500
+floor and the fixed 300 us loop allowance; the older calculations below remain
+as test history.
 See <a href="../radio_profiles/#preamble">radio profiles</a> for
 current behavior.</p>
 <p>Implemented in the <code>keymindCascade</code> working tree, 2026-09-14. The initial
 4.1/4000-us implementation record below is retained as history; the
-<a href="#automatic-46-chirp--300-us-policy-update">4.6/300-us policy update</a> is now current.
+<a href="#automatic-46-chirp--300-us-policy-update">4.6/300-us policy update</a> was a prior stage.
 No radios were flashed or RF experiments started for either function-only change.</p>
 <h2 id="initial-implementation-scope">Initial implementation scope</h2>
 <ul>

radio_dwell_policy_validation/index.html

@@ -2998,6 +2998,9 @@
 <h1 id="automatic-dwell-policy-46-chirps-on-both-profiles">Automatic dwell policy: 4.6 chirps on both profiles</h1>
 <p>Historical validation record: the nominal 600 us switch allowance below has
 been replaced by the activation self-test and a 10% guarded measured budget.
+The current automatic policy also removed the fixed 300 us loop allowance and
+the pair-specific SF8/500 88-symbol floor. Values below are retained as bench
+history, not current automatic defaults.
 See <a href="../radio_profiles/#preamble">radio profiles</a> for current behavior.</p>
 <p>The shared <code>RadioProfiles</code> function uses a 4.6-symbol minimum for both logical
 profiles of one physical transceiver, rounded upward to a whole microsecond.

radio_profiles/index.html

@@ -3543,9 +3543,11 @@ profile</strong>, then spends the remaining budgeted time on the faster profile,
 also with a <strong>4.6-symbol floor</strong>. Slower
 means a longer LoRa symbol (<code>2^SF / bandwidth</code>), regardless of profile number.
 The slower preamble sets the return deadline. The calculation allows two slow
-visits within that preamble, reserving the self-tested switch time per hop and 0.3 ms of main-loop
-margin. Fast-channel transmit preambles include sixteen acquisition symbols.
-For a primary SF7 / 62.5 kHz profile with a <em>measured</em> 600 us guarded switch allowance:</p>
+visits within that preamble, reserving the self-tested, 10%-guarded switch time
+per hop. There is no extra fixed main-loop allowance. Fast-channel transmit
+preambles include sixteen acquisition symbols.
+For a primary SF7 / 62.5 kHz profile with a 763 us measured maximum switch
+(840 us after the 10% guard, from the BLE-on T1000-E trial):</p>
 <table>
 <thead>
 <tr>
@@ -3564,7 +3566,7 @@ For a primary SF7 / 62.5 kHz profile with a <em>measured</em> 600 us guarded swi
 </tr>
 <tr>
 <td>SF8 / 500 kHz</td>
-<td style="text-align: right;">88</td>
+<td style="text-align: right;">40</td>
 <td style="text-align: right;">64</td>
 <td style="text-align: right;">32</td>
 </tr>
@@ -3577,18 +3579,17 @@ For a primary SF7 / 62.5 kHz profile with a <em>measured</em> 600 us guarded swi
 </tbody>
 </table>
 <p>With preamble 32 on that slower profile, its visit is 9.421 ms and the faster
-visit is 21.847 ms, plus the actual switching time. Increasing the slow preamble
+visit is 21.667 ms, plus the actual switching time. Increasing the slow preamble
 also increases the time available on the fast channel. If the symbols are equal
 in length, the primary profile goes first. Detected packets hold the current
 channel until reception finishes.</p>
-<p>The SF8 / 500 kHz value also retains the measured 88-symbol floor from the
-production V4/XIAO tests, where 72 and 80 each missed a packet.
-The explicit values come from the
-<a href="../radio_profiles_validation/">production validation</a>: the final fast-channel
-attempts each received 50/50 packets at 4.8 slow symbols. Automatic values use
-the switching and loop-jitter allowances below.
+<p>The SF8 / 500 kHz value is calculated from the same formula as every other
+profile; the older pair-specific 88-symbol floor has been removed. The explicit
+values come from <a href="../radio_profiles_validation/">historical production validation</a>:
+the final fast-channel attempts each received 50/50 packets at 4.8 slow symbols.
+Automatic values use the measured switch allowance below.
 Those explicit-preamble tests used the older 4.8-symbol policy; they do not
-validate the new 4.6-symbol slow dwell / 0.3 ms reserve. The
+validate the newer 4.6-symbol slow dwell. The
 <a href="../radio_dwell_policy_validation/#hardware-context">4.6/0.3 ms two-profile bench</a> received 197/200
 at SF7/62.5 + SF8/500 with explicit 32-symbol preambles. The newer four-channel
 5.1/6.1/7.7 tests also had misses, so this is a timing policy, not a claim of zero packet loss.
@@ -3601,10 +3602,22 @@ receiver's setting does not lengthen packets sent by other nodes.</p>
 <p><code>get radio2.timing</code> (alias <code>get radio.timing</code>) reports the active pair in
 <code>radio,radio2</code> order: dwell in chirps, recommended preambles in symbols, and
 the switching/loop allowances. Before calibration it reports <code>timing self-test
-pending</code> and the provisional preambles. For SF7/62.5 on <code>radio</code> and SF7/500 on
-<code>radio2</code> after a 600 us guarded measurement:</p>
-<pre><code class="language-text">&gt; chirps=4.60,85.34; need=32,64; switch=600us; loop=300us (estimate); test=4/4,4/4 ready; WARN recommended preamble: radio2=64
+pending</code> and the provisional preambles. On the T1000-E, the Full Companion now
+uses RTC2 for both retune timing and scan visits (about 31 us resolution).
+Previously, the nRF52 <code>micros()</code> fallback counted 1,024 Hz RTOS ticks: a real
+sub-millisecond retune could be reported as exactly 977 us, and two ticks as
+1,953 us. Those old numbers are timer artifacts, not measured RF costs.
+For SF7/62.5 on <code>radio</code> and SF8/500 on <code>radio2</code>, one live BLE-on read returned:</p>
+<pre><code class="language-text">&gt; chirps=4.60,42.84; need=32,40; switch=706us; loop=0us; test=4/4,4/4 ready; WARN recommended preamble: radio2=40
 </code></pre>
+<p>Later good hops in another BLE-on trial raised the measured maximum to 763 us
+(840 us with the 10% guard); the recommendation stayed at 40 symbols.</p>
+<p>The measured switch duration is wall time, so an interrupt during the hop is
+included. Bluetooth's SoftDevice may still preempt application code; this
+clock correction does not stop it. Ordinary Companion/USB work in the main
+loop does not run inside the synchronous retune, but it can delay when the
+next scan visit begins. The zero fixed loop allowance is not a guarantee of
+lossless reception under arbitrary application load.</p>
 <p><code>WARN recommended preamble</code> identifies <strong>each</strong> profile whose recommendation
 exceeds the standard 32 symbols or its explicitly selected value. For example,
 with SF7/62.5 on the primary profile, <code>set radio2 910.5,500,7,5,rx,32</code>
@@ -3637,14 +3650,13 @@ Using microseconds throughout:</p>
 slow = profile with the longer T (radio wins ties)
 L[slow] = max(requested_visit_us[slow], ceil(4.6 * T[slow]))
 L[fast] = max(requested_visit_us[fast], ceil(4.6 * T[fast]))
-O    = 2 * switch_us + loop_margin_us
+O    = 2 * switch_us
 C    = L[radio] + L[radio2] + O
 
 P[slow] = round_up_to_8(max(32, 2 * C / T[slow]))
 P[fast] = round_up_to_8(max(32, (L[slow] + O) / T[fast] + 16))
 </code></pre>
-<p>The previous SF8/500 versus SF7/62.5 measured 88-symbol floor remains in force.
-Automatic selection uses the minimum visits to choose a preamble, then allocates
+<p>Automatic selection uses the minimum visits to choose a preamble, then allocates
 the fast visit from half the slow preamble's duration. Diagnostics feed the
 actual allocated visits back into the same function, including longer visits
 caused by an explicit slow preamble. Too-short slow preambles that cannot fit
@@ -3655,10 +3667,10 @@ fast_dwell = max(ceil(4.6 * T[fast]),
                  floor(P_configured[slow] * T[slow] / 2 - slow_dwell - O))
 </code></pre>
 <p>For the tested SF7/62.5 + SF8/500 pair with slow preamble 32, this yields
-9,421 us slow and 21,847 us fast (42.67 fast chirps). Swapping <code>radio</code> and
-<code>radio2</code> swaps the allocations automatically. The 0.3 ms reserve is not a sleep.</p>
+9,421 us slow and 21,197 us fast (41.40 fast chirps) with the 1,075 us guarded
+switch allowance above. Swapping <code>radio</code> and <code>radio2</code> swaps the allocations automatically.</p>
 <p>Production scheduling and automatic preambles use the <strong>self-tested maximum
-successful switch plus 10%</strong>, together with 300 us per cycle. Subsequent
+successful switch plus 10%</strong>, without an additional fixed loop allowance. Subsequent
 successful hops can only raise that allowance until the next profile change.
 The measured recommendation is rounded up to eight symbols and capped at 128
 for automatic settings. The calculator and warnings retain the <em>uncapped</em>

search/search_index.json

@@ -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":"Introduction","text":"<p>Welcome to the MeshCore documentation.</p> <p>Below are a few quick start guides.</p> <ul> <li>1.17.1.5 Markdown audit</li> <li>1.17.1.5 USA Cascade release</li> <li>Feature switches by role: Companion, Repeater, Room Server, Sensor</li> <li>USB web console</li> <li>Full Companion feature switches</li> <li>Frequently Asked Questions</li> <li>Firmware Picker</li> <li>Temporary Radio Test Command Generator</li> <li>CLI Commands</li> <li>LoRa CLI Host Service</li> <li>Filter Policy Playground</li> <li>Telemetry Decoder</li> <li>Management Report Decoder</li> <li>CLI Availability by Firmware Build</li> <li>Classic ESP32 image memory budget</li> <li>Full Companion contact caches and capacity trials</li> <li>Easy LoRa OTA: ESP32 and nRF52 firmware updates</li> <li>Scripted LoRa OTA: Bash and PowerShell</li> <li>nRF52 repeater OTA with external QSPI</li> <li>nRF52 bootloader updates over LoRa</li> <li>MeshTower V2 microSD self-updates</li> <li>GPS Tracking</li> <li>Companion Protocol</li> <li>Companion Offline Message Queue</li> <li>Full Companion: ESP32 and nRF52</li> <li>Full Companion USB CLI and binary switcher</li> <li>Packet Format</li> <li>QR Codes</li> </ul> <p>If you find a mistake in any of our documentation, or find something is missing, please feel free to open a pull request for us to review.</p> <ul> <li>Documentation Source</li> </ul>"},{"location":"WiFi/","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 Lean LoRa-OTA repeater image; ESP32 builds retain the compact <code>start ota</code> browser uploader <p>Direct on-device WiFi and MQTT are currently ESP32 features. nRF52, STM32, and the currently enabled RP2040 targets do not run this MQTT bridge. An nRF52 connected to a Raspberry Pi can still be logged or uplinked by software on the Pi, but that is a separate host-side bridge rather than MQTT running in the radio firmware.</p>"},{"location":"WiFi/Line truncated
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Introduction","text":"<p>Welcome to the MeshCore documentation.</p> <p>Below are a few quick start guides.</p> <ul> <li>1.17.1.5 Markdown audit</li> <li>1.17.1.5 USA Cascade release</li> <li>Feature switches by role: Companion, Repeater, Room Server, Sensor</li> <li>USB web console</li> <li>Full Companion feature switches</li> <li>Frequently Asked Questions</li> <li>Firmware Picker</li> <li>Temporary Radio Test Command Generator</li> <li>CLI Commands</li> <li>LoRa CLI Host Service</li> <li>Filter Policy Playground</li> <li>Telemetry Decoder</li> <li>Management Report Decoder</li> <li>CLI Availability by Firmware Build</li> <li>Classic ESP32 image memory budget</li> <li>Full Companion contact caches and capacity trials</li> <li>Easy LoRa OTA: ESP32 and nRF52 firmware updates</li> <li>Scripted LoRa OTA: Bash and PowerShell</li> <li>nRF52 repeater OTA with external QSPI</li> <li>nRF52 bootloader updates over LoRa</li> <li>MeshTower V2 microSD self-updates</li> <li>GPS Tracking</li> <li>Companion Protocol</li> <li>Companion Offline Message Queue</li> <li>Full Companion: ESP32 and nRF52</li> <li>Full Companion USB CLI and binary switcher</li> <li>Packet Format</li> <li>QR Codes</li> </ul> <p>If you find a mistake in any of our documentation, or find something is missing, please feel free to open a pull request for us to review.</p> <ul> <li>Documentation Source</li> </ul>"},{"location":"WiFi/","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 Lean LoRa-OTA repeater image; ESP32 builds retain the compact <code>start ota</code> browser uploader <p>Direct on-device WiFi and MQTT are currently ESP32 features. nRF52, STM32, and the currently enabled RP2040 targets do not run this MQTT bridge. An nRF52 connected to a Raspberry Pi can still be logged or uplinked by software on the Pi, but that is a separate host-side bridge rather than MQTT running in the radio firmware.</p>"},{"location":"WiFi/Line truncated