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.
RAK4631 now has a Meshtastic-only application UF2 flashing path and owned serial transport admission. It verifies the official release archive, exact RAK4631 image, nRF52840 UF2 family/application ranges and USB-bound mounted bootloader volume before copying. It never uses ESP32 erase/write commands on this board. The UI explains double-reset/bootloader-drive setup and reports the copy as awaiting device verification, not verified firmware success. The bootloader drive must already be mounted and the current bootloader TTY selected; protected USB appointment rules remain enforced across re-enumeration.
The official Meshtastic 2.7.26 RAK4631 UF2 passed validation. Fourteen firmware/USB/owner fixtures, the real frozen helper build and disposable FD copy, backend flash regressions, eight setup-modal tests and the production UI build passed. Physical flashing/configuration remains unverified under the specific maintainer waiver.
Closing as an accepted next-release source fix with that limitation. No new ISO/OTA or physical radio success is claimed.
Implemented in canonical ngit PR https://gitworkshop.dev/nevent1qqsw4q34tmjymq698lh4nunraegn50fzes89qyuk6w2yerv5ancq5kspz3mhxue69uhhyetvv9ujumn8d96zuer9wcwmrwh0, merged as 21c1f8da63e946d32f5181ad411daeb544fb5c28 and mirrored exactly to Gitea. Maintainer approved the UI/UX and explicitly instructed us to proceed without a physical RAK4631 test: "oh right, I can't do that, we'll have to blind fix."
RAK4631 now has a Meshtastic-only application UF2 flashing path and owned serial transport admission. It verifies the official release archive, exact RAK4631 image, nRF52840 UF2 family/application ranges and USB-bound mounted bootloader volume before copying. It never uses ESP32 erase/write commands on this board. The UI explains double-reset/bootloader-drive setup and reports the copy as awaiting device verification, not verified firmware success. The bootloader drive must already be mounted and the current bootloader TTY selected; protected USB appointment rules remain enforced across re-enumeration.
The official Meshtastic 2.7.26 RAK4631 UF2 passed validation. Fourteen firmware/USB/owner fixtures, the real frozen helper build and disposable FD copy, backend flash regressions, eight setup-modal tests and the production UI build passed. Physical flashing/configuration remains unverified under the specific maintainer waiver.
Closing as an accepted next-release source fix with that limitation. No new ISO/OTA or physical radio success is claimed.
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.
Implemented in canonical ngit PR https://gitworkshop.dev/nevent1qqsw4q34tmjymq698lh4nunraegn50fzes89qyuk6w2yerv5ancq5kspz3mhxue69uhhyetvv9ujumn8d96zuer9wcwmrwh0, merged as
21c1f8da63and mirrored exactly to Gitea. Maintainer approved the UI/UX and explicitly instructed us to proceed without a physical RAK4631 test: "oh right, I can't do that, we'll have to blind fix."RAK4631 now has a Meshtastic-only application UF2 flashing path and owned serial transport admission. It verifies the official release archive, exact RAK4631 image, nRF52840 UF2 family/application ranges and USB-bound mounted bootloader volume before copying. It never uses ESP32 erase/write commands on this board. The UI explains double-reset/bootloader-drive setup and reports the copy as awaiting device verification, not verified firmware success. The bootloader drive must already be mounted and the current bootloader TTY selected; protected USB appointment rules remain enforced across re-enumeration.
The official Meshtastic 2.7.26 RAK4631 UF2 passed validation. Fourteen firmware/USB/owner fixtures, the real frozen helper build and disposable FD copy, backend flash regressions, eight setup-modal tests and the production UI build passed. Physical flashing/configuration remains unverified under the specific maintainer waiver.
Closing as an accepted next-release source fix with that limitation. No new ISO/OTA or physical radio success is claimed.