The public 2.8.3 release of the Meshtastic Android app keeps radios on firmware older than 2.5.14 connected but sends them straight to a firmware update, which the app now requires. It adds backup and restore of the app database, in-place resending of failed messages, a separate notification channel for reactions, radio settings that open and search without a radio attached, and Site Planner coverage calculated on the phone. The release notes also list many stability fixes and remove the app's Android Auto declaration.
Selection reviewed . Our short summaries link to the original publishers. Publication dates describe the source stories; this selection is maintained by the BackCountrySignal team and is not a live feed.
The public 2.8.3 release of the Meshtastic Android app keeps radios on firmware older than 2.5.14 connected but sends them straight to a firmware update, which the app now requires. It adds backup and restore of the app database, in-place resending of failed messages, a separate notification channel for reactions, radio settings that open and search without a radio attached, and Site Planner coverage calculated on the phone. The release notes also list many stability fixes and remove the app's Android Auto declaration.
For your next build: Check your radio's firmware version before updating the app on the morning of a trip. If it is older than 2.5.14, update the radio at home first, then back up the app database so your contacts and settings survive a phone change.
Hackaday covers a standalone C tool for the DragonOS radio Linux distribution that uses a HackRF software-defined radio to scan Meshtastic frequencies, detect traffic and decode it when the channel key is known. The article notes the HackRF covers most, but not all, Meshtastic frequencies, and that traffic on a channel with an unknown key cannot be decoded. The builder's claims come from a project video and were not independently tested.
For your next build: Treat the default public channel as readable by anyone with a radio, because its key is published. Put private conversations on a secondary channel with its own key, and never send exact home locations or personal details on the public channel.
Hackaday covers a hobbyist prototype that fits a Heltec V4 (ESP32-S3) board inside a Motorola T900 two-way pager. The builder reverse-engineered the original screen and keyboard to work with Meshtastic and reports basic functionality so far, with more features and a possible drop-in board planned. This is a project-reported prototype, not tested hardware.
For your next build: A physical keyboard makes a phone-free messenger possible, but a one-off conversion is a research project. For a dependable trail radio, start from a supported board and confirm battery life and two-way delivery yourself.
The Meshtastic project explains the usual reasons a new radio hears nothing: a different modem preset, a renamed primary channel that moves the frequency slot, or a local group using its own settings. In the US, Long Fast, Long Turbo and Medium Fast each land on a different slot. With 2.8 firmware, setting the US region on the device itself starts on Long Turbo, while a phone or CLI setup stays on Long Fast. The post also notes that old node lists can make other meshes look reachable, and that only an acknowledged direct message proves delivery.
For your next build: Ask the nearest group which preset and channels it uses before you change anything. Keep private groups on secondary channels, and test with an acknowledged direct message rather than a channel post.
Our five-step checklist helps you prepare a radio, confirm local settings and record a nearby two-way test. Progress stays in your browser. The local setup page clearly identifies settings that still need confirmation.
For your next build: Start with a nearby operator and record both directions before planning a longer link.
Seeed Studio highlights four custom Meshtastic builds, including handhelds with physical keypads, a portable location tracker and an expandable carrier board. The roundup links design repositories and explains that the carrier board uses different firmware for standalone and companion operation; its multi-radio decoding remains in development. These are manufacturer-reported prototypes, not independently tested BackCountrySignal hardware.
For your next build: Use the linked design files for build research. Check the exact firmware target, parts list and enclosure before assembly, then measure your own power use and test two-way delivery before taking a custom build off-grid.
The project withdrew 2.8.0 after finding a packet-signing issue. Its replacement, 2.8.1, remains an alpha for testing rather than general deployment. The announcement also covers migration changes, packet authentication and location defaults.
For your next build: Check the official announcement before updating. Coordinate firmware and radio settings with your intended contacts.
The official closed prerelease notes describe coverage calculations on the device and a clearer comparison of installed and available bootloaders before an update. They also list fixes that keep missing signal and power readings from appearing as valid measurements. This is an app prerelease; it does not change the alpha status of radio firmware 2.8.1.
For your next build: Keep a tested app and firmware combination for field trips. If you test this prerelease, record both versions and confirm a nearby two-way message. Treat predicted coverage as a planning aid that needs a field test.
The official release notes describe reply gestures, reactions, saved conversation drafts and pinned or unread chats. They also list a shared search across nodes, messages, settings and documentation, plus additional map controls.
For your next build: App and radio firmware version numbers are separate. Check both when troubleshooting a connection.
RAKwireless describes the WisMesh Repeater Mini V2 as a solar-powered Meshtastic relay with revised waterproof USB-C connectivity and battery mounting. Its bulletin also announces a higher-power option subject to regional rules. These are manufacturer claims, not our field-test results.
For your next build: Evaluate site, power, legal configuration and maintenance needs before choosing an outdoor node.
The official solar-node guide explains how to measure energy over a representative operating period, calculate average power and allow for cloudy weather and system losses. A momentary current reading can miss the cost of relaying traffic.
For your next build: Measure the complete node under realistic conditions before choosing its battery and panel.
Hackaday reports a debate over FCC Part 15.247, which it reads as requiring at least 500 kHz of bandwidth; the long-standing Meshtastic default, Long Fast, uses 250 kHz. Commenters dispute whether that paragraph applies to LoRa at all, and the article reports no FCC action or rule change. It says recent alpha firmware starts new US radios on a configuration intended to comply. Radios on 500 kHz and 250 kHz settings cannot hear each other, so communities may split while they migrate.
For your next build: Do not change a working regional mesh on your own. Watch what your local group decides, plan any preset move together, and record the date you switched so field reports stay comparable.
CNX Software describes OpenMANET, an open-source mesh built on Raspberry Pi boards and 802.11ah Wi-Fi HaLow radios, running OpenWrt with 802.11s and batman-adv. The project lists push-to-talk, GPS sharing, camera streams and ATAK support. The article sees it as a complement to Meshtastic rather than a replacement: more bandwidth and full IP networking, but costlier, more power-hungry hardware. Throughput and range figures are not independently tested.
For your next build: Keep Meshtastic for low-power text, position and sensor links across ridges. Consider HaLow only for short, powered links that need voice or video, and measure its power draw before planning a solar site.
The iOS announcement describes a local TAK server inside the Meshtastic app, allowing compatible mapping clients to exchange positions, messages and markers through the radio network. The source explains setup and the additional traffic this creates.
For your next build: Review channel privacy and coordinate traffic before testing a mapping integration on a shared mesh.
This earlier routing article explains the conditions under which infrastructure nodes can relay traffic without consuming another hop. It describes role and favorite-list requirements, while keeping the configured maximum hop limit unchanged.
For your next build: Treat infrastructure roles as coordinated decisions and verify behavior with a controlled test.
The ROUTER_LATE explainer describes its place in planned infrastructure and how its rebroadcast behavior can add airtime. It distinguishes that role from personal rooftop or mobile nodes and discusses congestion and delayed relays.
For your next build: Coordinate infrastructure roles with local operators and test their effect on the shared channel.
This hardware-support announcement explains the distinction between officially supported devices and boards maintained by the community. Support classification affects documentation and tooling and can change as manufacturers introduce or retire devices.
For your next build: Verify the exact board revision and its current support route before buying or flashing it.