One of the alpha testers has this device if we could add support he can test it.Rak4631
Proposed Solution
It should work with flashing and configuring
Alternatives Considered
No response
Area
Networking
### Problem
One of the alpha testers has this device if we could add support he can test it.Rak4631
### Proposed Solution
It should work with flashing and configuring
### Alternatives Considered
_No response_
### Area
Networking
What already works with no code changes: detection (the udev rule covers RAK's native USB, symlinked as /dev/mesh-radio), the UI knows the board (icon + label), and the serial/config path supports nRF52 boards over the Meshtastic serial API — a RAK4631 that arrives already flashed with Meshtastic firmware should plug in and work on v1.8.4. @reporter: could you confirm this with your board? That is testable today and would close the usable-today half.
What is deferred (deliberately, as a feature with its own milestone): in-app flashing. The entire flash backend is esptool/ESP32-only; the RAK4631 is nRF52840 and needs the UF2/DFU path (adafruit-nrfutil, 1200-baud touch to enter the bootloader), different upstream firmware assets, and a new board table entry — a new flash backend, not a table row. It also really wants the physical device in the loop to validate the DFU dance.
Keeping this open pending the tester's confirmation of the already-flashed path.
Triage + decision (2026-08-30):
**What already works with no code changes:** detection (the udev rule covers RAK's native USB, symlinked as /dev/mesh-radio), the UI knows the board (icon + label), and the serial/config path supports nRF52 boards over the Meshtastic serial API — a RAK4631 that arrives **already flashed** with Meshtastic firmware should plug in and work on v1.8.4. @reporter: could you confirm this with your board? That is testable today and would close the usable-today half.
**What is deferred (deliberately, as a feature with its own milestone):** in-app flashing. The entire flash backend is esptool/ESP32-only; the RAK4631 is nRF52840 and needs the UF2/DFU path (adafruit-nrfutil, 1200-baud touch to enter the bootloader), different upstream firmware assets, and a new board table entry — a new flash backend, not a table row. It also really wants the physical device in the loop to validate the DFU dance.
Keeping this open pending the tester's confirmation of the already-flashed path.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
One of the alpha testers has this device if we could add support he can test it.Rak4631
Proposed Solution
It should work with flashing and configuring
Alternatives Considered
No response
Area
Networking
Triage + decision (2026-08-30):
What already works with no code changes: detection (the udev rule covers RAK's native USB, symlinked as /dev/mesh-radio), the UI knows the board (icon + label), and the serial/config path supports nRF52 boards over the Meshtastic serial API — a RAK4631 that arrives already flashed with Meshtastic firmware should plug in and work on v1.8.4. @reporter: could you confirm this with your board? That is testable today and would close the usable-today half.
What is deferred (deliberately, as a feature with its own milestone): in-app flashing. The entire flash backend is esptool/ESP32-only; the RAK4631 is nRF52840 and needs the UF2/DFU path (adafruit-nrfutil, 1200-baud touch to enter the bootloader), different upstream firmware assets, and a new board table entry — a new flash backend, not a table row. It also really wants the physical device in the loop to validate the DFU dance.
Keeping this open pending the tester's confirmation of the already-flashed path.