Add nRF52 2.4GHz wireless bridge

[recrof]

NRF52RadioBridge: an ESP-NOW-like broadcast bridge that drives the RADIO peripheral directly (1Mbit GFSK, custom framing) and reuses the ESP-NOW payload format, secret and Fletcher-16 isolation.

• compile repeater with WITH_NRF52_WIRELESS_BRIDGE
• bridge.channel 1/2/3 -> 2482/2450/2424 MHz
• new bridge.txpower setting (-20..8 dBm, default 4)
• bridge.type reports "nrf52-wireless", advert feature flag 0x05
• listen-before-talk with random backoff
• fixed whitening seed: frequency-derived seeds made the hardware CRC check fail on some channels
• move xorCrypt into BridgeBase (also fixes divide-by-zero on an empty secret)
• bridge envs: RAK4631, RAK3401, Heltec T114/T096, Xiao nRF52, SenseCAP Solar, ProMicro, Wio Tracker L1

[recrof]

@jbrazio can you review please?

[liamcottle]

I've tested with the following setup, and it appears to be working:

• 1x RAK4631 repeater with 917MHz LoRa and nRF52 2.4GHz bridge enabled
• 1x RAK4631 repeater with 918MHz LoRa and nRF52 2.4GHz bridge enabled
• 1x Wio Tracker L1 Pro companion with 917MHz LoRa
• 1x Wio Tracker L1 Pro companion with 918MHz LoRa

I'm able to send private messages between both companions, and can see the traffic being passed across both 91xMHz frequencies.

I don't have an SDR that can show 2.4GHz, but I can see the packets being logged in the repeater bridge debug logs.

Logging in to both repeaters via either companion, on either frequency is also working.

This will be a nice alternative to serial bridge via TX/RX pins, allowing for cross frequency LoRa bridging on nRF devices without needing to do hardware modification.

[jbrazio]

This is very interesting. I need more time to bench-test it, but overall, it looks very promising.

@recrof Could this new implementation support both ESP32 and nRF52? Since it uses GFSK, we could consider decommissioning ESP-NOW and creating a wireless bridge that supports both targets for cross-compability.

[recrof]

did some digging and it seems that esp32s3/c3 doesn't officialy support any raw GFSK transport, but newer boards(c5,c6,h2) support 802.15.4(phy for thread/zigbee), which is also supported on nrf52/54.
there are some hacky solutions for raw GFSK on s3 around, but it would require extra libs and questionable stability
I can try to extract the phy from https://github.com/RaemondBW/esp32-ant/ to use with c3/s3, but it won't work on c5 and c6 then