The LIS3DH is a widely available 3-axis accelerometer used in several Meshtastic-compatible hardware platforms through the RAK1904 WisBlock module and other carrier boards. Until now, Meshtastic had no built-in way to use that sensor for anything other than detecting motion to wake a sleeping node. The new module changes that by continuously reading the sensor and pushing tilt data out over the mesh.

What the Module Sends

The TiltTelemetryModule broadcasts a 20-byte packet containing five float values: roll, pitch, and the raw X, Y, Z accelerometer readings in g-forces. Roll and pitch are computed from the LIS3DH gravity vector and expressed in degrees from vertical. The packet uses the PRIVATE_APP port number, which keeps it out of the standard telemetry channels and means existing setups are unaffected.

Transmission follows a three-part policy. The module waits 60 seconds after boot before sending anything, giving a freshly powered node time to stabilize before it starts reporting movement. After that, it sends whenever roll or pitch changes by at least 0.5 degrees. A heartbeat packet goes out every five minutes regardless of motion, so a client monitoring the node has a regular signal to confirm it is still alive.

Built From Real-World Use

The PR description goes into unusual detail about why the module exists: pacmac built and deployed it to monitor a directional Yagi antenna mast. Tilt packets from the node feed into mesh-gw, a BLE-to-JSON bridge the same developer wrote, which then forwards the data to mesh-radar, a Node.js dashboard showing live roll/pitch and a four and 24-hour tilt history chart. The system gives early warning of mast movement from wind loading before anything physically fails.

That background makes this a more complete contribution than a typical first PR. The module was tested in a real deployment with supporting tooling already written, which should help reviewers evaluate whether the send policy and packet format are practical rather than theoretical.

Scope and Compatibility

The module only activates on nodes where Meshtastic detects a LIS3DH at boot. Boards using other accelerometers or no accelerometer at all are unaffected. Build exclusion guards wrap the code so it can be omitted from firmware builds that strip environmental and accelerometer support.

The four files changed are limited: the new module source, a visibility change to a method in the shared motion sensor header, a one-line call added to the LIS3DH sensor class, and an instantiation in main. This is a reasonably contained change for the amount of new functionality it adds.

PR #10787 is open and awaiting review at github.com/meshtastic/firmware. It has not been merged into the Meshtastic develop branch as of this writing.

The N37 is built around the Wio Tracker L1 development board, a platform that integrates LoRa radio and GNSS positioning in a compact form factor. The 1.3-inch OLED gives the device a small but usable status display without requiring a phone or computer nearby to see what the node is doing.

Pre-Flashed Out of the Box

The “no setup hassle” angle matters more than it might seem. Getting Meshtastic onto a new device typically means downloading firmware, picking the right binary for your exact board variant, running a flashing tool, and sometimes hitting driver issues on the way. Power it on, open the Meshtastic app, and start connecting.

Where It Fits

Most purpose-built Meshtastic hardware with built-in GPS and a display sits in the $35 to $80 range. The N37 is competitive, making it a reasonable choice for testing GPS tracking, adding a second node to an existing setup, or handing to someone new to the project who wants to start without a big investment.

Meshnology also lists an N37E variant with an E-Ink display instead of the OLED, starting at $56.99, for anyone who needs better outdoor readability or lower power draw from the display itself.

The N37 is available now at meshnology.com.

Learn to install it the easy way, using the Mesh America Device Configurator!

All builds are available at github.com/IoTThinks/EasySkyMesh/releases. Source code and pull request history live at IoTThinks/EasySkyMesh on GitHub.

The change, merged as commit 4f0e2dd via pull request #10136, gives operators of fixed Meshtastic infrastructure a way to update firmware without physical access to the device. For a rooftop repeater, a basement gateway, or a weather-sealed enclosure on a remote tower, that means no ladder, no drive out to a site, no screwdriver to open the box.

The update uses a Python script (bin/eth-ota-upload.py) that compresses the firmware image with GZIP and transfers it over TCP using Meshtastic’s MOTA protocol. Authentication uses SHA256 challenge-response with a pre-shared key, which keeps unauthorized updates out even on a shared network. The target node runs an OTA firmware update server on port 4243 and requires at least 0.75 MB of LittleFS storage to stage the compressed image during the update.

The feature targets RP2350-based Meshtastic hardware — the Raspberry Pi Pico 2 is the most widely known RP2350 board — paired with a W5500 SPI Ethernet controller, a combination commonly used for always-on Meshtastic nodes and gateways. Meshtastic’s Linux daemon (meshtasticd) has seen expanded support for gateway-class deployments over the past year, and Ethernet OTA fits that trajectory.

The commit is in the firmware development branch and has not yet appeared in an alpha or stable release. No target release date has been announced.

What the dashboard covers

The interface is organized around several workspaces. The Chat workspace handles group channel messaging and direct peer-to-peer messages. The Network workspace shows a live map with node positions, signal links between them, and a heatmap of observed signal strength. From there you can pull up a link topology graph centered on any node in the mesh and run on-demand route traces that show per-hop packet details.

A Telemetry workspace logs sensor history across nodes, making it possible to compare environmental or battery data over time. A Packet Console surfaces raw traffic in real time. Optional workspaces include a BBS area for installations running community nodes and a small games console built around Zork.

Beyond reading data, Meshyface can push configuration changes back to the connected radio: device settings, channel configuration, and connectivity options are all accessible from the browser tab. All packet history, chat logs, node analytics, and telemetry rollups are saved to a local SQLite database. A no-history mode is available for operators who prefer to keep nothing on disk.

Getting it running

The project requires Python 3.11 or newer. A Raspberry Pi running Bookworm is the documented primary platform, though Proxmox VM and LXC setups are also covered in the repository. For radios with Wi-Fi enabled, the connection is over TCP; USB serial is the fallback for direct cable connections.

The basic startup command for a TCP-connected radio looks like this:

python mesh_dashboard.py --mesh-host meshtastic-radio.local --http-host 0.0.0.0 --http-port 8877

A bundled deploy script can install Meshyface as a systemd service on a Raspberry Pi over SSH in a single step. Once running, the dashboard is accessible from any browser on the same network at the configured host and port.

A few things to know before deploying

Meshyface is built for use on a trusted LAN or VPN. The project documentation explicitly cautions against exposing it directly to the public internet; a reverse proxy with access controls in front of it is the recommended approach for anything beyond a private home network. An --api-token flag is available for locking down write endpoints on shared installations.

The project also ships a “Join Meshyface” channel preset with a shared PSK intended purely for interoperability testing between Meshyface users. This channel is not designed for private or sensitive communications.

There are currently no versioned releases. All builds come from the main branch on GitHub, which is worth noting for anyone considering running this on a node that also carries production mesh traffic.

The source code is available at github.com/jaronmcd/meshyface under the GPL-3.0 license. RTL-SDR Blog covered the project this week, which appears to be the first broad public writeup.

T-Deck and T-Deck Plus Touch Driver Fixed

The most visible fix for Meshtastic users with LilyGo T-Deck hardware is a corrected touch driver. The T-Deck and T-Deck Plus are among the more popular standalone mesh terminals in the community, so this fix should reduce frustration for anyone who noticed erratic touch input on those screens.

GPS Time Sync Now Runs Every 30 Minutes

Nodes with GPS enabled will now synchronize their internal clock from GPS every 30 minutes. Previously, time drift could accumulate over long uptime sessions. This change keeps mesh timestamps more accurate without requiring a reboot or manual resync.

RAK Module and Hat Configs Filled In

Several missing configuration values for RAK6421, RAK13300, and RAK13302 modules have been added, along with configuration files for the Zebra and Nebra Pi Hat form factors. These additions should smooth out setup for anyone running Meshtastic on Raspberry Pi-based setups using RAKwireless hardware.

B&Q Station G3 Gets Linux Daemon Config

The B&Q Station G3 now has a Meshtasticd configuration file, making it easier to run the Linux-native Meshtastic daemon on that hardware without manual configuration work.

ESP32 RTC and Phone API Fixes

An ESP32-specific bug where the RTC timer would incorrectly wake the device during a user-initiated shutdown has been corrected. A TAP V2 OCV and partition fix was bundled in the same pull request.

The phone API also received a targeted fix: the firmware now skips a potentially expensive manifest scan when the phone requests node-info-only config, which should reduce unnecessary radio channel overhead during those interactions.

Getting the Update

Firmware 2.7.26 is an Alpha (pre-release) build. It is available through the official Meshtastic web flasher and the GitHub releases page. As with all Alpha builds, users who prefer stability may want to wait for the next Beta or Stable release.

The library is authored by Joan Miquel Sole, Felix Freitag, and Roger Baig, and the source code is published at github.com/LoRaMesher/LoRaMesher.

Direct Node Routing, No Gateways Required

Most commercial LoRa deployments rely on LoRaWAN, a protocol that routes packets upward through fixed gateways and a network server before reaching an application. LoRaMesher takes a different approach: devices communicate directly with each other in a multi-hop mesh, forwarding packets toward their destination based on locally maintained routing tables, with no central infrastructure involved.

The library implements a proactive distance-vector routing protocol, meaning each node periodically exchanges routing information with its neighbors and keeps an up-to-date map of paths to the rest of the network. When a packet needs to travel multiple hops to reach its destination, each intermediate node consults its routing table and forwards accordingly.

Three Delivery Modes and Large Payload Support

LoRaMesher supports three message delivery modes. Unicast sends a packet to a specific addressed node. Broadcast distributes a message to every node on the network. Reliable delivery adds acknowledgments and retransmission so that the sender can confirm a message arrived.

For larger payloads that exceed a single LoRa packet, the library handles fragmentation on the sending side and reassembly on the receiving side automatically. This is a practical consideration for applications that need to move more than a handful of bytes at a time over a slow radio link.

Built on RadioLib and FreeRTOS

Under the hood, LoRaMesher uses RadioLib for radio hardware access, which gives it compatibility with a wide range of SX1276, SX1278, SX1262, and other popular LoRa transceivers. Task scheduling is handled by FreeRTOS, which is already included in the ESP32 toolchain. The library integrates with PlatformIO, letting developers add it to existing projects using the standard PlatformIO library manager.

The authors describe use cases including environmental and industrial monitoring, smart-city sensor networks, emergency communication systems, asset tracking, and connectivity in areas without fixed infrastructure.

Paper and Source Code

The full paper is available open access at ScienceDirect. The library source code and documentation are at github.com/LoRaMesher/LoRaMesher.

The answer, it turns out, involves a drone.

Rastislav Vysoky, a web and firmware developer known in the MeshCore community as “recrof,” documented the project on the MeshCore Blog on June 22, 2026. The system uses a Seeed Xiao nRF52840 microcontroller mounted on a DJI Neo2 drone to perform over-the-air (OTA) firmware updates on hard-to-reach nRF52-based repeaters via Bluetooth DFU.

From Raspberry Pi to a 7.5-Gram Payload

The project grew out of earlier experiments. Another community member had already created a drone-based update framework using a Raspberry Pi Zero 2W, but that approach carried a 70-gram total payload and required significant setup and debugging effort. Vysoky set out to build something simpler and far lighter.

The Xiao nRF52840 turned out to be a good fit. Its nRF52 processor is power-efficient, it has 2MB of onboard flash, and it includes a full USB controller. Taking inspiration from the Arduino UF2 bootloader, Vysoky configured the Xiao to expose its external flash as a mass storage volume with a FAT12 filesystem. This means any computer or phone can be used to copy firmware files to the device, edit the configuration, and review update logs after a flight. The total payload, Xiao plus a 250mAh lithium-ion battery, weighs 7.5 grams.

Getting a Repeater Updated

For the system to work, the target repeater must run the OTAFIX bootloader at version 2.1 or higher, developed by community member oltaco. The operator sets a BLE name filter in a configuration file on the Xiao’s USB drive and copies the firmware ZIP from the MeshCore flasher.

After sending a “start ota” command to the repeater over LoRa, the operator attaches the Xiao to the drone and flies it toward the target site. The update starts automatically once the Xiao detects the repeater’s Bluetooth advertisement above the configured minimum signal strength. Progress can be tracked by pinging the repeater over LoRa during the process. When the drone returns, the Xiao’s LED shows the result: green for success, red for failure, or still blinking blue if the update never started. A timestamped log file stored on the Xiao provides additional detail.

Currently supported boards include the Seeed Xiao nRF52840, and RAK3401 and RAK4631 boards paired with a RAK15001 external flash module.

Where to Find It

The firmware and setup guide are published on GitHub at github.com/recrof/xiao_nrf52_updater. The original write-up with photos appears on the MeshCore Blog.

First-Time Setup Gets a Walkthrough

Connecting a device for the first time now opens a step-by-step onboarding screen that walks through the key initial settings in order. The goal is to reduce the guesswork for new users getting a fresh node running. An empty contacts list now shows a button to add a contact directly rather than presenting a blank screen.

Region Scan From Nearby Nodes

Running firmware v1.16.0 or later, the app can now detect which radio regions (frequency bands) neighboring devices are using, even if those devices are not in your contact list. This gives you a faster read on local band activity without any manual configuration.

Crash and Bug Fixes

Two crash scenarios have been resolved. Tapping both buttons of a confirmation dialog at the same time could bring down the app; so could the Android foreground service that keeps the connection alive in the background. Both are fixed in this release.

Four additional issues have been corrected: a channel failed to load when multiple channels shared the same secret; the neighbours map was omitting your own repeater when auto-fitting the view; attaching your current location to a message was not pulling a fresh position fix; and the discover list filter was ignoring the contact type setting when also filtering by path hash size.

The channels tab icon has changed from a signal wave symbol to a hashtag, and translations have been refreshed across several languages. The update is available on the Google Play Store and the Apple App Store.

Source: meshcore.at

The badge originally shipped with a MicroPython firmware that included a basic messaging app. That worked for the event, but left the hardware without much of a path forward. The new firmware changes that by turning it into a functional Meshtastic node you can actually use in the field.

Under the Hood

The replacement firmware runs FreeRTOS rather than MicroPython. Installing it requires the Espressif ESP-IDF toolchain, so this is aimed at users who are comfortable with embedded development. That said, Giovi321 has put together detailed installation instructions at a dedicated documentation site.

A separate community effort, tracked on GitHub under the EU-meshcore branch, is working on a MeshCore port for the same badge hardware, so there may be more options for badge owners before long.

Badge Background

The Hackaday Communicator badge has a form factor that translates naturally to a mesh radio terminal: the QWERTY keyboard makes typing messages practical, the ESP32 handles the processing, and the LoRa radio provides the off-grid link. The badge was used at the Hackaday event in Lecco, Italy, where it ran the original messaging app during the conference.

Event badges with radio hardware often end up in drawers after the conference. Community firmware projects like this one keep the hardware relevant and give owners something practical to build on. For anyone who picked up a Communicator badge at the event and wants to put it to use on a local mesh, the firmware and documentation are available on GitHub.

Hackaday covered the project on June 12, 2026.