@Keith Bryant yeah this is a solid approach and definitely worth doing rather than just pinning everything to max — you're right that it's wasteful and the co-channel interference gets real when you have a dense node cluster all transmitting at full power simultaneously.
On the RSSI feedback loop: the STM32WB07 gives you RSSI per connection event, so the cleanest way to handle this is to have the gateway read RSSI on incoming packets and then push a power adjustment command back to the remote node over your existing config channel. You're already doing config pushes so you basically have the mechanism for free — just add a power step command to your protocol and let the gateway drive it. I'd suggest treating it as a slow control loop, not a fast one. Sample RSSI over maybe 10-20 packets, take an average, and only step if you're consistently well above your target margin. Chasing every RSSI fluctuation just creates instability.
For the front-end settling question — with the external PA architecture on the MultiNav Pro+ there is a small window after a TX power change where you can get inconsistent output. It's not dramatic but it's real. The safe move is to avoid changing TX power mid-burst; do it between packet exchanges rather than while you're actively streaming telemetry. If you build in even a modest inter-packet gap around the power transition you should be fine. A couple of dropped packets during the step is annoying but not catastrophic if your telemetry has any kind of sequence numbering or retry logic.
The GitHub repo has the STM32WB07 firmware source so it's worth digging into how TX power is being set there before you build your control layer on top of it — link's at github.com/RFOXiA/MultiNav-Pro-Long-Range-BLE-Module-Firmware-STM32WB07. Might save you some reverse-engineering time on the exact register sequence.
