mirror of
https://github.com/mikecarper/MeshCore.git
synced 2026-10-26 17:12:26 +00:00
deploy: 79fe4362f8
This commit is contained in:
mikecarper committed
1 parent
b7b150bb4f
commit
b0eadbbc9b
2 files changed
+103
-1
No files matched your search
@@ -2281,6 +2281,17 @@
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#mercermesh-heltec-t096-sx1262-experiment-2026-09-21" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
MercerMesh Heltec T096 SX1262 experiment (2026-09-21)
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
@@ -3278,6 +3289,17 @@
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
<li class="md-nav__item">
|
||||
<a href="#mercermesh-heltec-t096-sx1262-experiment-2026-09-21" class="md-nav__link">
|
||||
<span class="md-ellipsis">
|
||||
|
||||
MercerMesh Heltec T096 SX1262 experiment (2026-09-21)
|
||||
|
||||
</span>
|
||||
</a>
|
||||
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
@@ -3877,6 +3899,86 @@ against the pinned RadioLib. No firmware was uploaded, no radio command was
|
||||
issued, and no new RF result was collected. The temporary build overlay was
|
||||
removed. The earlier ~0.549 ms XIAO and ~8.263 ms Indicator timings do <strong>not</strong>
|
||||
measure this added optimization; its time saving and RF behavior await testing.</p>
|
||||
<h2 id="mercermesh-heltec-t096-sx1262-experiment-2026-09-21">MercerMesh Heltec T096 SX1262 experiment (2026-09-21)</h2>
|
||||
<p>The Pi has <strong>one</strong> Heltec T096 (USB serial <code>651F8E496197F882</code>); the other
|
||||
Heltec-named nRF52 is a MeshTower V2, not another T096. An application-only
|
||||
T096 HIL image tested two further RX-to-RX shortcuts with a buffered 8 MHz SPI
|
||||
bus: use SX1262 <code>SetFs</code> instead of warm XOSC standby, and skip
|
||||
<code>SetPacketParams</code> only when the LoRa RX packet tuple is unchanged. Both switches
|
||||
defaulted off in this HIL image. The image explicitly enabled the existing
|
||||
production fast-RX path. Normal T096 firmware does not currently enable that
|
||||
path or use the buffered SPI HAL, so these numbers are <strong>not</strong> stock T096
|
||||
switch timings.</p>
|
||||
<p>The same image ran 256 measured hops per configuration, after eight warm-up
|
||||
hops, on 909.5/909.75 MHz. <code>freq</code> held SF7/BW125/CR5; <code>both</code> alternated
|
||||
SF7/SF8 at BW125/CR5. Preamble was 32 symbols. The DWT cycle counter measured
|
||||
through RX re-entry and BUSY release. Every 8 MHz configuration had zero
|
||||
switch failures, mode/cache/RSSI errors, or BUSY timeouts.</p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>8 MHz HIL configuration</th>
|
||||
<th style="text-align: right;">Frequency-only mean</th>
|
||||
<th style="text-align: right;">Frequency + SF mean</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Fast RX baseline</td>
|
||||
<td style="text-align: right;">467.3 us</td>
|
||||
<td style="text-align: right;">553.6 us</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>SetFs</code> only</td>
|
||||
<td style="text-align: right;">422.5 us</td>
|
||||
<td style="text-align: right;">517.4 us</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Unchanged packet tuple skip only</td>
|
||||
<td style="text-align: right;">357.7 us</td>
|
||||
<td style="text-align: right;">444.0 us</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Both</td>
|
||||
<td style="text-align: right;"><strong>313.0 us</strong></td>
|
||||
<td style="text-align: right;"><strong>407.8 us</strong></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Combined savings were 154.3 us (33.0%) for frequency-only and 145.8 us
|
||||
(26.3%) for frequency-plus-SF relative to the same-image fast-RX baseline.
|
||||
Command counts confirmed one frequency command, IRQ clear and RX command per
|
||||
hop; the optimized cases eliminated the corresponding standby and packet
|
||||
commands. These are controlled short-range, same-band results, not a field
|
||||
packet-error rate or a qualification of large frequency jumps, sleep/wake,
|
||||
TX/CAD interruption, BLE scheduling, or all SX1262 boards.</p>
|
||||
<p>A separate RAK4631 fixed transmitter sent 16-byte synthetic packets at
|
||||
909.5 MHz/SF10/BW125/CR5/preamble32, -9 dBm chip power. The T096 hopped to
|
||||
909.75 MHz and back before each transmission. Baseline and combined shortcuts
|
||||
each delivered <strong>60/60</strong> packets after <strong>120</strong> fast hops, with payload sequence
|
||||
and content checked. The RAK bootloader on this exact fixture enumerated as
|
||||
<code>239A:002A</code> (the fixture's earlier <code>0029</code> expectation was corrected).</p>
|
||||
<p>Doubling buffered SPI to 16 MHz gave only 12–21 us (about 3–4%) savings in
|
||||
comparable successful cases, while five of eight setup attempts failed. The
|
||||
combined shortcut had no clean 16 MHz result. Keep this T096 at 8 MHz pending
|
||||
a separately diagnosed and repeatable 16 MHz bring-up; no 16 MHz over-air
|
||||
qualification was attempted.</p>
|
||||
<p>Both radios were restored via app-only DFU after the experiment: the T096 to
|
||||
<code>Heltec_t096_repeater</code> and the RAK to <code>RAK_4631_companion_radio_full</code>, each
|
||||
built at <code>v1.17.1.7-hil-restore-e7160dfd</code>. The T096 answered normal <code>version</code>
|
||||
and <code>board</code> commands; the RAK answered the Full Companion terminal's version
|
||||
command. The V4 observer's memory-soak service remained active. Reproducible
|
||||
bench code is in <code>tools/hil/profile_switch_t096_sx1262.cpp</code> and
|
||||
<code>tools/hil/t096_sx1262_packet_probe.py</code>.</p>
|
||||
<p>Follow-up: owned fast RX, <code>SetFs</code>, and acknowledged packet-tuple reuse are
|
||||
now defaults for <code>CustomSX1262</code> targets, including the original XIAO S3 WIO,
|
||||
Station G3 KISS, and Heltec V4 KISS paths. The Seeed Indicator retains its
|
||||
original owned-RX path but explicitly opts out of the two new shortcuts because
|
||||
its radio control and BUSY/IRQ pins run through an I2C expander. The owned-RX
|
||||
state now remembers only an acknowledged packet tuple and revokes it on
|
||||
ordinary packet setters, TX/CAD staging, standby outside the hop, sleep,
|
||||
reset, RX duty cycling, or command failure. The T096 numbers remain lab
|
||||
measurements, not on-board qualification of every <code>CustomSX1262</code> target.</p>
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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
|
||||
Reference in new issue
Block a user