Android 2.8.3, channel privacy, and the preset question
This digest collects practical Meshtastic developments: a public Android release that now requires current firmware, a reminder of who can read the default channel, the FCC preset debate, advice for a new node that hears nothing, and two hardware experiments. Source stories span several dates; this is an editorial selection, not a claim that every story was published this week.
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 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.
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.
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.
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.
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.
Confirm compatible settings with a nearby contact, establish a counted two-way baseline, then change one variable. Save the build and test notes in My Mesh Project.
Source publication dates remain on each story. Firmware alpha announcements are for assessment and testing, not automatic update advice. Manufacturer announcements are not our own hardware reviews.
Future issues require a source review. If no useful new developments are verified, retain this dated issue rather than relabeling old stories. RSS follows the newsroom's published briefings; it is not an email subscription.