deploy: f6c9d5a87f

ota_easy/index.html

@@ -1669,7 +1669,15 @@ builds; do not override them for this normal nRF52 flow. Do not continue if veri
 check fails.</p>
 <h2 id="transfer-and-install-either-package">Transfer and install either package</h2>
 <h3 id="1-start-the-temporary-ota-channel">1. Start the temporary OTA channel</h3>
-<p>On the source node, destination node, and every intermediate repeater, run:</p>
+<p>First save the current <code>ota config</code> output. For a direct source-to-destination link, set both OTA-enabled
+endpoints to direct-only mode before starting the transfer:</p>
+<pre><code class="language-text">ota config hops 0
+</code></pre>
+<p>Do not use <code>hops 1</code> as extra margin on a direct link. It tells a receiving repeater to retransmit each direct
+DATA/PROOF packet; that unnecessary half-duplex transmission can make it miss the source's next fragment,
+especially with older single-block receivers. Use <code>hops 1</code> only when one real intermediate relay is required,
+<code>hops 2</code> for two, and so on. This setting is saved, so restore the original value after the maintenance window.</p>
+<p>On the source node, destination node, and every intermediate repeater, then run:</p>
 <pre><code class="language-text">tempradio 909.950,250,5,5,120
 </code></pre>
 <p>All participating nodes must use the same frequency, bandwidth, and spreading factor. Their time windows must
@@ -1702,6 +1710,14 @@ firmware requires <code>ota pull &lt;mid8&gt; flash rescue</code>, followed afte
 <p>Monitor the transfer:</p>
 <pre><code class="language-text">ota status
 </code></pre>
+<p>For a powered bench update where restart-resume is not needed, <code>ota config checkpoint 0</code> on the destination
+removes periodic progress writes. It is a smaller optimization than selecting the correct hop count and it
+trades away persisted mid-download resume; restore the previous checkpoint cadence afterward.</p>
+<p>Current repeater firmware automatically uses the full transmit budget during a bounded TempRadio window.
+Older receivers do not: if <code>get af</code> reports a nonzero value on such a node, record it, use <code>set af 0</code> for the
+maintenance window, and restore it afterward. This affects how promptly the legacy receiver can send its next
+block/proof request; it does not increase LoRa transmit power. Use a full duty budget only where the selected
+frequency and local rules permit it.</p>
 <p>The update is ready when the status says <code>ready to install</code>. Discovery is background traffic, while an
 active OTA download is primary mesh traffic. At the temporary-radio settings in this guide, allow roughly
 <strong>one hour</strong> for a typical ESP32 full image over a quiet, direct link. That is a planning estimate, not an
@@ -1738,7 +1754,8 @@ application can be restored.</p>
 <li><strong>nRF52 reports a base mismatch:</strong> the file passed to <code>--base</code> is not the exact application running on
   the destination. Rebuild the delta from the correct saved <code>firmware.hex</code>.</li>
 <li><strong>The download stalls:</strong> check the source, destination, and intermediate repeaters. Restart matching,
-  overlapping temporary-radio windows if one expired.</li>
+  overlapping temporary-radio windows if one expired. On a direct link, also require <code>ota config hops 0</code>;
+  a larger reach makes a repeater destination unnecessarily echo source packets.</li>
 <li><strong>The serial port is busy:</strong> close the serial terminal before starting <code>motatool serve</code>.</li>
 <li><strong>The destination rejects the package:</strong> verify the source files, their <code>EndF</code> trailers, the package's
   target/hardware identity, and the result of <code>motatool verify</code>.</li>

ota_protocol/index.html

@@ -2330,10 +2330,14 @@ OTA_LEAVES:        manifest_id[4]  frag_idx(1)  frag_total(1)  bytes[]      # up
   reassembly bitmap (&lt;=16 fragments/block; 1 KB blocks = 7). <code>OTA_PROOF</code> is a single packet and needs no mask.</li>
 <li><strong>Data and proof remain separate packets, without a normal extra round trip.</strong> A server retains requested
   blocks in a bounded descriptor queue, admits at most one response per main-loop pass, and sends one
-  <code>OTA_PROOF</code> after each block's requested fragments. The receiver uses an airtime/path-aware proof grace
-  (never less than 500 ms) and defers <code>OTA_REQ_PROOF</code> while any flight slot still expects DATA. Thus a missing
-  early proof cannot make the receiver transmit into the rest of a legitimate half-duplex response train.
-  After the complete-flight deadline, only one slot's missing fragments/proof is requested at a time.</li>
+  <code>OTA_PROOF</code> after each block's requested fragments. Before admitting that proactive proof, the source leaves
+  an airtime/duty-aware 100-3000 ms RX turnaround gap. It accounts for one active transmission plus the two
+  paced-response queue credits. A legacy receiver uses the gap to send its immediate
+  <code>OTA_REQ_PROOF</code>; receiving that explicit request bypasses the remaining gap, avoiding a proof/request
+  collision and an otherwise multi-second legacy retry. A newer receiver uses an airtime/path-aware proof
+  grace (never less than 500 ms) and defers <code>OTA_REQ_PROOF</code> while any flight slot still expects DATA. Thus a
+  missing early proof cannot make the receiver transmit into the rest of a legitimate half-duplex response
+  train. After the complete-flight deadline, only one slot's missing fragments/proof is requested at a time.</li>
 </ul>
 <h3 id="85-sizing-against-max_packet_payload-184">8.5 Sizing against <code>MAX_PACKET_PAYLOAD = 184</code></h3>
 <table>
@@ -2383,8 +2387,10 @@ to its persistent archive, it registers that complete file as a MotaSource and a
 This keeps each active transfer as one transmitter and one receiver while still allowing active temporary-radio
 repeaters between them and persistent archive nodes to improve future availability.</p>
 <p>TempRadio is treated as a private maintenance network. Active transfer packets use priority 0, bypass the
-public-flood receive holdoff, retain the relay role's airtime-scaled transmit collision window, and do not
-schedule generic flood retries. The bounded serving
+public-flood receive holdoff, use the full transmit budget without overwriting the saved normal-radio airtime
+factor, retain the relay role's airtime-scaled transmit collision window, and do not schedule generic flood
+retries. Deployed firmware predating that TempRadio budget override can be accelerated manually with a saved
+<code>get af</code> / temporary <code>set af 0</code> / restore sequence. The bounded serving
 queue admits at most two DATA/PROOF packets ahead of the radio while preserving at least four free packet-pool
 entries. CAD remains enabled to arbitrate the half-duplex channel, but its busy retry is scaled to one-quarter
 of a packet airtime and clamped to 5-50 ms instead of the ordinary 120-360 ms cadence. Discovery traffic keeps
@@ -2489,9 +2495,12 @@ the <code>MotaSource</code> random-access contract.</p>
 a time. Their source-side gap follows the active maximum packet airtime and
 dispatcher duty spacing, clamped to 100-1000 ms. The 100 ms floor protects
 fast radios' TX-to-RX turnaround; the cap keeps the receiver's one-second
-manifest progress/retry observation responsive. Relay collision delay is a
-separate setting: active OTA floods honor the relay role's configured
-<code>txdelay</code>, and the deployment runner temporarily uses <code>0.3</code> on managed relays.</p>
+manifest progress/retry observation responsive. The source uses the same
+radio-aware 100-3000 ms drain/turnaround gap before an unsolicited block proof,
+but immediately serves a
+legacy receiver's explicit <code>OTA_REQ_PROOF</code>. Relay collision delay is a separate
+setting: active OTA floods honor the relay role's configured <code>txdelay</code>, and the
+deployment runner temporarily uses <code>0.3</code> on managed relays.</p>
 <p><strong>What to plug into <code>--serial</code>.</strong> Use the USB serial console of an OTA-enabled MeshCore node built with
 <code>OTA_FOLDER_SERIAL</code>. The node must have a working LoRa radio plus an
 <code>ota folder on</code> command; that command confirms it can host and advertise the folder. A <strong>KISS modem will not

rak3401_mota_chain/index.html

@@ -1525,7 +1525,7 @@ python3 tools/lora_ota/rak3401_mota_chain.py \
   --source-shares-controller \
   --target-key 63d8df63 \
   --temp-radio 909.950,500,5,5,120 \
-  --ota-hops 1 \
+  --ota-hops 0 \
   --motatool /path/to/motatool \
   --yes
 </code></pre>
@@ -1568,14 +1568,17 @@ after every bridge reboot:</p>
 <pre><code class="language-text">powersaving off
 set radio.rxps off
 set rxdelay 0
-ota config hops 1
+ota config hops 0
 tempradio 909.950,500,5,5,120
 </code></pre>
 <p><code>powersaving off</code> is an isolation guardrail, not the fix for the observed
 failure. The actual source failure was an oversized USB CDC reply; current
 firmware splits those reads. Some historical bridge builds may report RXPS as
 unsupported while already operating continuously. Verify the reported state
-and do not substitute a normal reboot for the one-time watchdog reset.</p>
+and do not substitute a normal reboot for the one-time watchdog reset. Direct
+tests use <code>hops 0</code>: <code>hops 1</code> makes the target echo each source response despite
+there being no intermediate relay, increasing half-duplex loss and legacy
+three-second retries.</p>
 <p>Put the source on the identical TempRadio tuple. If it is a binary-mode Full
 Companion, the current <code>motatool</code> can switch modes for the serving session:</p>
 <pre><code class="language-bash">motatool serve \