I asked claude about this before and it thought it was too much work and to invasive for me as a newbie to consider but now I ask:
I'm getting some positive noise about the idea of porting all of the RNode firmware to RadioLib. Please give me a list of things that would have be be changed to make that fit. I'm not interested in a shim solution but rather analyze a full migration to RadioLib.
And it says:
Based on a full pass through Radio.hpp/Radio.cpp (the actual driver), Boards.h (per-board config), and everywhere else RadioInterface is touched, here's what a genuine full port — replacing the hand-rolled opcode drivers everywhere, not just adding a shim — would involve.
The good news: the abstraction boundary is already clean
Only Radio.hpp/Radio.cpp (and now my Xiao adapter) ever reference the chip classes directly. Console, BLE, display code, Utilities.h, and RNode_Firmware_CE.ino all talk exclusively through the RadioInterface abstract base and the interfaces[]/interface_obj[] arrays. That
means the migration is contained to two files' worth of implementation, not a sprawling refactor.
1. Replace three driver classes with RadioLib-backed ones
Radio.hpp currently declares sx126x, sx127x, sx128x as three independent classes with duplicated opcode/SPI plumbing. RadioLib's PhysicalLayer interface is common across its SX1262/SX1276/SX1278/SX1280 classes, so this is a chance to collapse to one adapter class
parameterized over which RadioLib radio object it holds, instead of three. That's a real simplification opportunity, not just a mechanical swap.
2. Move per-board radio config out of #if BOARD_MODEL chains inside the driver
Right now TCXO voltage is hardcoded via a #if BOARD_MODEL == ... chain inside sx126x::enableTCXO() in Radio.cpp (3.3V for RAK4631/OPENCOM_XL/Heltec32V3/Xiao, 1.8V for T-Beam/T-Echo/T3S3/T-Deck/T-Beam-S/Heltec-T114/E22). RadioLib takes TCXO voltage as a plain begin()
parameter. This data belongs in Boards.h's per-board pin/config tables (same pattern I already used for the Xiao adapter), not compiled into the driver. Same treatment needed for the RFO-vs-PA_BOOST output selection currently hardcoded in sx127x::setTxPower().
3. Per-chip-family feature-parity checks (verify against RadioLib, don't assume)
- PA antenna-mismatch clamp workaround — sx126x::setTxPower() does a manual RegTxClampConfig register write per Semtech's errata. Need to confirm RadioLib's SX126x does this internally (it generally does, but must verify per version) rather than silently dropping it.
- Output power tables — the hand-tuned pa_buf/OCP values that hit exactly 22dBm on SX1262 need to be checked against RadioLib's own power-setting path so max EIRP doesn't drift on boards with regulatory certification tied to specific output levels.
- SF5/SF6 handling — already chip-family-conditional in getAirtime(); confirm RadioLib's low-datarate-optimization behaves the same at those edge SFs.
- packetFrequencyError() — implemented for sx127x but stubbed to 0 for sx126x/sx128x today. RadioLib exposes getFrequencyError() for all three — this migration is a chance to actually fill that in consistently instead of carrying the stub forward.
- getPacketValidity() / CRC-error IRQ mapping — same shape of check I did for the Xiao adapter, needed for both other chip families too.
4. DIO-sharing/interrupt logic, per chip family
Each family shares TX_DONE/RX_DONE IRQs across DIO pins differently (this was the trickiest part of the Xiao adapter). SX127x traditionally has more DIO pins available and doesn't need the same "am I mid-TX" flag trick SX126x does; SX128x's IRQ layout is closer to SX126x.
Each needs its own careful audit, not a copy-paste of the Xiao adapter's handleDio0Rise() logic.
5. Dual-radio board support
BOARD_OPENCOM_XL runs two interfaces simultaneously ({SX1262, SX1280}). Need to confirm RadioLib supports two independent Module/radio instances on separate SPI busses/IRQ pins concurrently without cross-talk — likely fine, but it's an explicit thing to test, not assume.
6. Build system
- Makefile's prep-esp32 needs the RadioLib install (already added for the Xiao work) — but prep-nrf needs it too now, since RAK4631/OpenCom XL/T-Echo/Heltec-T114 are all NRF52 and currently untouched.
- Flash/RAM budget: RadioLib compiles in support for many protocols (LoRa, FSK, GFSK, etc.) by default. The NRF52 boards are the tightest fit here — use RADIOLIB_EXCLUDE_* defines to trim to LoRa-only and verify against each board's upload.maximum_size in the Makefile
before assuming it fits.
7. Testing matrix
27 discrete firmware-* build targets exist today, covering ~20 board models across 4 chip families (mostly SX1276, several SX1262, one SX1278, one SX1280, one dual). A flag-day rewrite isn't realistic to validate — the sane rollout mirrors what happened with the Xiao
board: port one chip family at a time behind BOARD_MODEL/chip-family conditionals, keep the old driver reachable until each board is confirmed working over real RF, then delete the old path per family once its boards are all validated. Old Radio.cpp/Radio.hpp should only
be deleted after the last board's cutover, not before.
8. Loose ends carried over from the Xiao work
Still open from before: the license-header convention for new files, and whether to bump MAJ_VERS/MIN_VERS — both apply with more weight now since this would touch every board's reported firmware identity, not just one.
Now, given the trouble it had with debugging the existing SX1262 implementation, take all that with a big grain of salt. Plus it'll get immediately labelled slop which honestly I can't really evaluate because this isn't a domain I'm very knowledgeable about, which is why I'm using claude in the first place.
