Implementing skipped (for determenistic results) delays

[stachuman]

Simulating PR #2125 on autotune delays — findings and questions

Hi, I've been working on exercising the autotune delay mechanism from PR #2125 inside the meshcore_sim simulator. I ran into a few structural issues and wanted to share findings and get feedback before proceeding.

The autotune mechanism lives in two layers:

1. Mesh layer (PR #2125): _tx_delay_factor, _direct_tx_delay_factor, _rx_delay_base members; autoTuneByNeighborCount() looks up DelayTuning.h; getRetransmitDelay() uses _tx_delay_factor.
2. MyMesh layer (firmware): recalcAutoTune() calls autoTuneByNeighborCount() on every advert and every 5 minutes; putNeighbour() maintains the neighbor table.

Since SimNode inherits from Mesh directly (no MyMesh), nothing ever calls autoTuneByNeighborCount(). Worse, SimNode overrides getRetransmitDelay() to return 0 for test determinism, so even the base Mesh::getRetransmitDelay() with _tx_delay_factor never runs.

I know that it was done for the purpose of deterministic results, hence, it limit one of the most important feature to avoid collisions and improve reliability of communication.

SimRadio airtime approximation

A second issue: SimRadio::getEstAirtimeFor() uses a rough len_bytes * 125 ms approximation (labeled "SF7 BW125"). For a 40-byte packet that returns 5,000 ms — vs ~330 ms at MeshCore's actual SF10/BW250. Since Mesh::getRetransmitDelay() computes 5 * getEstAirtimeFor(len) * _tx_delay_factor, this would produce ~25-second delays instead of the intended ~1.6 seconds. This needs a proper LoRa airtime formula before autotune can be meaningfully tested.

Planned approach:

• Does NOT override getRetransmitDelay() — lets Mesh::getRetransmitDelay() run with _tx_delay_factor
• Calls autoTuneByNeighborCount(contact_count) in onAdvertRecv() (mimicking what MyMesh::putNeighbour() does on real firmware)
• Fixes SimRadio::getEstAirtimeFor() with the Semtech AN1200.13 airtime formula
• Uses longer warmup periods (6+ min) to let autotune stabilize

This will let me compare three variants under RF contention:

• node_agent (baseline, zero delay)
• adaptive_agent (simulator's own density-adaptive delays, independent of PR #2125)
• autotune_agent (exercises PR #2125's actual Mesh.cpp code)

Any feedback welcome. I'll share comparison results once the experiment is running.

I have created the fork, but will be happy to collaborate.