deploy: 439dc7da3c

cli_commands/index.html

@@ -8184,7 +8184,7 @@ capacity. Remote use follows the existing administrator-command permissions.</p>
 - <code>sf</code>: Spreading factor (5-12)
 - <code>cr</code>: Coding rate (5-8)</p>
 <p><strong>Set by build flag:</strong> <code>LORA_FREQ</code>, <code>LORA_BW</code>, <code>LORA_SF</code>, <code>LORA_CR</code></p>
-<p><strong>Default:</strong> <code>869.525,250,11,5</code></p>
+<p><strong>Default:</strong> <code>869.618,62.5,8,5</code></p>
 <p><strong>Note:</strong> Requires reboot to apply. If RXPS is enabled and the saved minimum
 level/preamble cannot safely cover the new radio timing, the command reply
 reports the effective level and preamble, or <code>RXPS continuous-fast</code> when no
@@ -8406,7 +8406,7 @@ preamble. LoRa OTA treats v1.17.1.5 as that capability boundary.</p>
 - <code>set freq &lt;frequency&gt;</code></p>
 <p><strong>Parameters:</strong>
 - <code>frequency</code>: Frequency in MHz</p>
-<p><strong>Default:</strong> <code>869.525</code></p>
+<p><strong>Default:</strong> <code>869.618</code></p>
 <p><strong>Note:</strong> Requires reboot to apply</p>
 <p><strong>Connections:</strong> USB, browser/TCP/Ethernet CLI, Companion binary command
 <code>0x42</code> (USB/BLE/TCP), and authorized LoRa CLI. <code>set freq</code> saves the frequency;
@@ -9167,7 +9167,7 @@ installed images need an updated build. See the <a href="../cli_settings_audit/"
 - <code>set direct.txdelay &lt;value&gt;</code></p>
 <p><strong>Parameters:</strong>
 - <code>value</code>: Direct transmit delay factor (0-2)</p>
-<p><strong>Default:</strong> <code>0.2</code></p>
+<p><strong>Default:</strong> <code>0.3</code> (Repeater) - <code>0.2</code> (Room Server, Sensor)</p>
 <p><strong>Note:</strong> Same collision-avoidance random window as <code>txdelay</code>, but applied to direct (non-flood, routed) traffic. The default is lower because direct packets are addressed to a specific next hop, so far fewer nodes compete to retransmit them.</p>
 <hr />
 <h4 id="experimental-view-or-change-the-processing-delay-for-received-traffic">[Experimental] View or change the processing delay for received traffic</h4>
@@ -9278,7 +9278,7 @@ reduce unnecessary recoveries when no traffic is expected.</p>
 - <code>set flood.advert.interval &lt;hours&gt;</code></p>
 <p><strong>Parameters:</strong>
 - <code>hours</code>: Interval in hours (3-168)</p>
-<p><strong>Default:</strong> <code>12</code> (Repeater) - <code>0</code> (Sensor)</p>
+<p><strong>Default:</strong> <code>47</code> (Repeater, Room Server) - <code>0</code>, disabled (Sensor)</p>
 <hr />
 <h4 id="view-or-change-the-zero-hop-advert-interval">View or change the zero-hop advert interval</h4>
 <p><strong>Usage:</strong>
@@ -9286,7 +9286,11 @@ reduce unnecessary recoveries when no traffic is expected.</p>
 - <code>set advert.interval &lt;minutes&gt;</code></p>
 <p><strong>Parameters:</strong>
 - <code>minutes</code>: Interval in minutes rounded down to the nearest multiple of 2 (61 becomes 60) (60-240)</p>
-<p><strong>Default:</strong> <code>0</code></p>
+<p><strong>Default:</strong> <code>2</code> on a factory-fresh node, then <code>0</code> (disabled) once configured.</p>
+<p><strong>Note:</strong> A new install ships with a 2 minute zero-hop advert interval. Saving
+any setting resets an interval below the 60 minute minimum to <code>0</code>, on the
+assumption that the node has now been deliberately configured. To keep zero-hop
+adverts running, set an explicit value in the 60-240 range.</p>
 <hr />
 <h4 id="limit-the-number-of-hops-for-a-flood-message">Limit the number of hops for a flood message</h4>
 <p><strong>Search terms:</strong> hop limit, maximum hops, max hops, flood distance.</p>

companion_protocol/index.html

@@ -4799,11 +4799,11 @@ a raw byte count.</p>
 - <code>0xFFFF</code> (<code>DATA_TYPE_DEV</code>) is the developer namespace for experimenting and developing apps.
 - Registered application/community namespaces occupy <code>0x0100</code>-<code>0xFEFF</code>; the remaining nonzero ranges are reserved for internal or development use. See the <a href="#registered-data_type-values">Registered data_type values</a> table below.</p>
 <p><strong>Limits</strong>:
-- Maximum payload length is <code>MAX_CHANNEL_DATA_LENGTH = MAX_FRAME_SIZE - 9 = 167</code> bytes.
+- Maximum payload length is <code>MAX_GROUP_DATA_LENGTH = MAX_PACKET_PAYLOAD - CIPHER_BLOCK_SIZE - 3 = 165</code> bytes.
 - Larger payloads are rejected with <code>PACKET_ERROR</code> (<code>ERR_CODE_ILLEGAL_ARG</code>).</p>
 <p><strong>Response</strong>: <code>PACKET_OK</code> (0x00) on success, or <code>PACKET_ERROR</code> (0x01) with one of:
 - <code>ERR_CODE_NOT_FOUND</code> (2) - unknown <code>channel_idx</code>
-- <code>ERR_CODE_ILLEGAL_ARG</code> (6) - invalid <code>path_len</code>, reserved <code>data_type</code> (<code>0x0000</code>), or payload larger than <code>MAX_CHANNEL_DATA_LENGTH</code>
+- <code>ERR_CODE_ILLEGAL_ARG</code> (6) - invalid <code>path_len</code>, reserved <code>data_type</code> (<code>0x0000</code>), or payload larger than <code>MAX_GROUP_DATA_LENGTH</code>
 - <code>ERR_CODE_TABLE_FULL</code> (3) - outbound send queue is full; retry later</p>
 <p><strong>Inbound datagrams</strong> are delivered to the host via <code>RESP_CODE_CHANNEL_DATA_RECV</code> (0x1B); see <a href="#receive-channel-data-datagram">Receive Channel Data Datagram</a>.</p>
 <h4 id="registered-data_type-values">Registered <code>data_type</code> values</h4>

faq/index.html

@@ -5307,8 +5307,8 @@ sudo apt install python3-venv
 </code></pre>
 <p>Mac: python3 should be already installed.</p>
 <p>Then it should be the same for all platforms:</p>
-<pre><code>python3 -m venv meshcore
-cd meshcore &amp;&amp; source bin/activate
+<pre><code>python3 -m venv meshcore-venv
+cd meshcore-venv &amp;&amp; source bin/activate
 pip install -U platformio
 git clone https://github.com/meshcore-dev/MeshCore.git
 cd MeshCore

nrf52_power_management/index.html

@@ -3598,9 +3598,16 @@
 </tr>
 </tbody>
 </table>
-<p>On boards without power management enabled, all commands except <code>get pwrmgt.support</code> return:</p>
+<p>On boards without power management enabled, <code>get pwrmgt.source</code> and
+<code>get pwrmgt.bootmv</code> return:</p>
 <pre><code>ERROR: Power management not supported
 </code></pre>
+<p><code>get pwrmgt.support</code> returns <code>unsupported</code>. <code>get pwrmgt.bootreason</code> is not
+compiled out at all and answers on every board: <code>getResetReason()</code> and
+<code>getShutdownReason()</code> are virtuals on the base board class, so a board that
+does not override them reports <code>Not available</code> rather than an error. ESP32
+boards override the reset half with <code>esp_reset_reason()</code>, so they return a real
+reset reason and <code>Not available</code> for the shutdown reason.</p>
 <h2 id="debug-output">Debug Output</h2>
 <p>When <code>MESH_DEBUG=1</code> is enabled, the power management module outputs:</p>
 <pre><code>DEBUG: PWRMGT: Reset = Wake from LPCOMP (0x20000); Shutdown = Low Voltage (0x4C)

terminal_chat_cli/index.html

@@ -3137,9 +3137,6 @@ keeps the bond. Send <code>off</code>, then <code>on</code>, then reboot to reop
 <pre><code>set lon {longitude}
 </code></pre>
 <p>Sets your advertisement map longitude. (decimal degrees)</p>
-<pre><code>set dutycycle {percent}
-</code></pre>
-<p>Sets the transmit duty cycle limit (1-100%). Example: <code>set dutycycle 10</code> for 10%.</p>
 <pre><code>set af {air-time-factor}
 </code></pre>
 <p>Sets the transmit air-time-factor. Deprecated - use <code>set dutycycle</code> instead.</p>