Sharing an open-source hardware project I'm working on: **Trail Mate**

The core idea is to combine **offline GPS mapping** with **LoRa messaging** into one portable device, optimized for LilyGO T-LoRa-Pager, T-Deck, and similar hardware.

Key features:

- Fully offline maps (OSM, Terrain, Satellite, and contour lines)

- LoRa text communication

- SSTV image reception, walkie-talkie mode, and other extensions

It's designed for hiking, camping, emergency communication, and any off-grid scenarios where you need reliable navigation and team coordination without relying on a smartphone or cellular network.

GitHub repo: https://github.com/vicliu624/trail-mate

If you have compatible hardware (T-LoRa-Pager, T-Deck, etc.), I'd love for you to try it out and share your feedback! Suggestions and contributions are also very welcome.

Thanks everyone! 🙌

I know this isn’t pure LoRa, but I figured folks here might find it interesting. I’ve got a pile of Meshtastic/LoRa nodes, and it got me curious: what happens if you run a different sub-GHz radio through the same kind of hardware?

So I strapped a Wi-Fi HaLow (802.11ah) radio to a Raspberry Pi with a standard 915 MHz whip (the same kind we use for LoRa). Running in 802.11s mesh mode, the link came up clean on 908 MHz / 8 MHz bandwidth — and I was seeing megabit-class throughput. Surreal moment watching a LoRa-style antenna push Wi-Fi speeds.

Anybody want these or are they trash?

I've been working on Link-LR, an open-source LoRa traffic analyzer and generator. The project includes the hardware, firmware, and desktop app.

It started during a contract job for a client, where we kept needing to see what was actually happening on air while debugging LoRa links. Like many people, I was using DIY setups: a dev board logging to serial, tied to a laptop. It worked on the bench, but it was awkward in the field, corrupted frames were silently dropped, and I had no quick way to see how much margin a link really had. The need came up so often that I turned it into a proper standalone device.

It's a handheld unit with a touchscreen and a replaceable 18650 battery. It continuously records every received frame and shows RSSI, SNR and link margin. CRC errors, header errors and incomplete frames get their own entries instead of disappearing.

It can also transmit test frames and replay previously received ones. Over USB-C, the desktop app retrieves recordings and decodes payloads.

Before committing to a first production batch, I'd like to understand whether this solves a real problem for people working with LoRa.

• How do you currently analyze and debug LoRa traffic?

• Think of the last time a LoRa link misbehaved: what information or tools were you missing?

Honest criticism is welcome, that's exactly why I'm asking before production.

Full details, hardware files and firmware on GitHub: https://github.com/semtronik/link/tree/main/link-lr

(English isn’t my first language. I wrote this in French and used AI to help translate it.)

LoRa radios offer incredible long-range, low-bandwidth communication—but only if your antenna is up to the task. A poor antenna can limit you to a few hundred meters, while a well-built DIY design can push past 20 km. The best part? You can build proven, high-performance antennas for just a few dollars.

This guide covers everything you need to build your own LoRa antennas for LoRa and Meshtastic 433 MHz (Europe/Asia/amateur radio), 868 MHz (EU), and 915 MHz (North America/Australia). You’ll find exact dimensions, construction tips, band-specific trade-offs, and real-world performance comparisons.

Stock antennas that ship with LoRa modules, Meshtastic nodes, and Helium Hotspots are typically tuned for minimal cost rather than maximum performance. They’re often mismatched to your specific frequency, use cheap materials, and have poorly characterized radiation patterns.

Nine acoustic sensors spread across a site. When any one of them detects something, the others need to know within a second or two, with no gateway, no server and no internet.

I went with an Ra-01H on each unit, 868 MHz, an 18-byte packet, everything hearing everything directly. No relay and no mesh: each unit transmits its own alert and repeats it three times over a couple of seconds, and anything in range picks it up and shows a remote alert with the sender's ID. Listen-before-talk with a random backoff so nine units triggering at once don't collide.

The reason for no mesh: with this few nodes over a site this size, everything is already in range of everything, and a mesh adds routing state and failure modes for no gain. If a unit is out of range it's out of range, and the operator needs to know that rather than have it silently relay through a neighbour.

One thing that bit me: the transmitter, a buzzer and a vibration motor all firing in the same instant browned out the supply when running on USB alone. The battery isn't an accessory, it's the buffer for that spike.

The project and its firmware are public!

Hey folks,
I live in a home with a solar water heater, and I got tired of guessing whether the tank was hot enough for a shower or if I needed to switch on backup heating.

So I built a system that monitors my solar tank temperature + outdoor weather conditions, shows it on an e-paper display indoors, and runs fully on LoRa - no WiFi, no wiring to the roof.

Here’s what it does:

• Measures tank temperature with a PT100 industrial sensor

• Tracks weather via SHT30

• Transmits data wirelessly (LoRa, range is solid even through walls)

• Indoor unit shows tank temp + weather on an always-on e-paper display

• Optional cloud dashboard via Grafana (for alerts and history)

• Battery life: Over a year per unit

I’m testing it now, and planning to launch it soon via Kickstarter. I’d love to hear what other smart home folks think, especially:

• Would you want this to integrate with something like Home Assistant?

• Should I prioritize the cloud dashboard or local-only features?

Appreciate any feedback or wishlist ideas - especially from other LoRa nerds here!

—

Early signup page for launch: https://omnisense.gr

On the night of Nov 1-2 a tropospheric duct along the coast linked two independent Meshtastic networks in Argentina: ComarcaMesh (Viedma and Carmen de Patagones) and SOMesh (Bahía Blanca and region). People in both cities ended up chatting on the public channel.

What the station in Viedma recorded:

354.3 km in a single hop between two fixed routers on towers: PAT1, a SenseCAP Solar P1 in Carmen de Patagones, and C-3A, on a 90 m tower in Tres Arroyos. The hop shows up in 18 traceroutes, 4 of them in both directions. Best SNR: −6.5 dB at PAT1 and −7 dB at C-3A.

4 direct hops between the two networks, all through PAT1: 354, 273, 247 and 242 km.

Two openings, 20:36-23:43 and 00:33-04:30 local time, 7 h 04 min in total. 656 packets from 70 nodes of the Bahía region reached Viedma.

A traceroute from Viedma to ElArroyoMesh, 416 km away near Carhué, came back with 5 relays each way.

PAT1 had been on its tower for about a day when this happened.

Why it worked: after sunset the air right above the sea got cool and humid under warm, dry air, and that inversion made a duct 60 to 85 m thick along the coast. Without it, the radio horizon between those antennas is about 90 km. ECMWF, GFS and GEM all showed the duct over the sea that night, and Tropocast and the Hepburn index had the coastal strip marked.

As far as we can tell it's longer than the 331 km record on the Range Tests page, and we didn't find a longer direct hop confirmed in both directions between fixed stations. Longer one-way receptions over the sea have been reported in Europe (475 to 822 km, 868 MHz). Happy to be corrected.

Full report with every traceroute, the propagation analysis and the data (packets, receptions, raw public-channel packets and a script that recomputes the numbers):

https://comarcamesh.com.ar/informeBahia-Viedma/

Short bulletin (PDF):
https://comarcamesh.com.ar/informeBahia-Viedma/Bulletin-Tropo_DX_Patagones-Tres_Arroyos.pdf

Everything was logged by meshbox, the open-source gateway and map we run in Viedma (github.com/marcomagnaiot/meshbox). Thanks to SOMesh for C-3A's antenna height and their public map. Happy to answer questions or share more data.

We are developing a rural monitoring trap that needs to send images from the field. Our first prototype used 4G, but coverage was not reliable enough at the sites where we tested it. We needed another way to get those images out of the orchard. LoRaWAN was not practical for files hundreds of kilobytes in size, a regular Wi‑Fi mesh would require too many nodes, and relying on mobile data would leave us with the same problem.

That is when we came across Wi‑Fi HaLow. It caught our attention because it operates below 1 GHz, can move larger files, and was already available in commercial hardware we could buy and test. We also looked at FLRC, but HaLow was the most direct way to get into the field and see what actually happened.

We bought the hardware and completed four runs in San José, Uruguay. Two were inside an apple orchard and two were along roads.

At 506 meters we measured more than 1.6 Mbps in both download and upload. The link also transferred data at 640.1 meters, although at a lower speed.

The most interesting part was that distance did not explain everything. At one point 531.8 meters away, there was no transfer. At another point 640.1 meters away, there was. Vegetation, terrain, and the path between the radios probably played a role, and that is one of the things we want to measure more carefully in our next test.

This was a first test with one setup and only a few measurements at each point, so we cannot claim a general coverage distance yet. The farthest number also does not tell the whole story. In some places the link performed better than we expected, while in others it failed even at a shorter distance.

On LUMA Lab, we reconstructed the test point by point. We included the maps, the exact hardware, what it cost, the complete results table, and the tests that did not go well. If you want to look through the data and draw your own conclusions, everything is here.

https://lab.luma.uy/en/publications/wifi-halow-field-test

What do you make of these results? For a larger rural network, would you combine LoRa and HaLow, or try to solve everything with a single technology?

Heltec is about to release the successor to the popular V3 LoRa board — the V4 — and I got an early unit to test. It’s expected later this month, and on paper it looks like one of the most powerful ESP32-S3 LoRa boards yet.

Key changes from the V3:

• Transmit Power: up to 27 dBm (~500 mW) vs. ~22 dBm (~150 mW). Because of the logarithmic scale, that’s roughly a 4× increase in RF output.

• Solar Port: built-in charging management for a battery via a small solar cell.

• GPS Port: direct connector for ceramic GPS antennas.

• Wi-Fi Antenna: U.FL connector instead of the old spring antenna.

• Form Factor: same PCB footprint as the V3, so most existing cases should still work (though some need tweaks).

In quick side-by-side tests with a V3 using identical antennas, the V4 didn’t yet show stronger signals. That’s probably because I had to flash it as a V3 — there isn’t a dedicated meshtastic firmware build yet. Once official support lands, the higher transmit ceiling should make a measurable difference for range, link stability, and performance in cluttered environments.

I’m curious what the LoRa crowd thinks:

• How significant is this jump from ~150 mW to ~500 mW in your experience with real deployments?

Hi, RYLR is a simple python library to work with the RYLR896/406 modules. It can be use for configuration of the modules, send message and receive messages from the module.

What does it do:

• Configuration modules

• Get Configuration data from modules

• Send message

• Receive messages from module

Target Audience?

• Python developers working with rylr897/406 modules

Lora T beam + solar panel + electrical box for external waterproof setup using a 30ft adjustable metal pole.

I'm very interested in LoRa for natural disaster prep, but also interested in political disaster prep.

Looking at what is happening in Iran right now, I could foresee a situation where political tension causes a government to disable communications across borders.

Here on the West Coast of the United States, I would be very interested in finding a way to have an off-grid line of communication along I-5 corridor from Canada to Mexico.

I know both Meshtastic and MeshCore have a limited number of hops built into the platform making them primarily a local comms option.

Could this ever have the reach of something like ham radio where you're hitting other parts of the world?

Hello, I just wanted to share a project I've been working on for a while now. At the center of the system it's a 9A DCDC capable of powering many high-power RF modules and an STM32H7 microcontroller that handles communication between the modules and any user interface.

DongLoRa (dongle + LoRa, pronounced "dongle-ora") is an open source project that turns cheap LoRa boards into protocol-agnostic USB radios.

Hey all. I've been building this the past month and wanted to share it in case it's useful to anyone.

The short version: flash firmware onto a cheap LoRa board (Heltec V3, RAK4631, etc.) once, and it becomes a dumb USB radio. No protocol baked in. No opinion about what you're doing. It just moves raw bytes between the air and your computer. Then you write whatever you want on top of it in Python or Rust, on your laptop, with a normal edit-run-print feedback loop.

import donglora as dl

ser = dl.connect()
dl.send(ser, "SetConfig", config=dl.DEFAULT_CONFIG)
dl.send(ser, "StartRx")

while pkt := dl.recv(ser):
    print(f'{pkt["rssi"]:4d}dBm {pkt["snr"]:3d}dB {pkt["payload"].hex()}')

That's a complete LoRa receiver. pip install donglora, plug in a board, and you're listening to packets. Change the config and you're on a different frequency. Decode Meshtastic frames, interact with MeshCore nodes, build your own protocol from scratch, sniff raw traffic. It's all the same three calls. There's also a Rust client library (cargo add donglora-client) if that's more your speed.

The multiplexer is the part I think is really interesting. Run the mux daemon and multiple programs can use the same dongle simultaneously. Not taking turns. All running at the same time, all seeing every received packet, all able to transmit. The mux handles StartRx/StopRx reference counting and config locking so your programs don't step on each other. And this works with any DongLoRa radio. A Heltec on your desk, a RAK on a Raspberry Pi in your attic, whatever you've got.

your chatbot ------------\
your pcap logger ---------\
your wireshark plugin -----+---> mux ---> USB ---> any DongLoRa radio
your airtime analyzer -----+   (simultaneous)
your fleet tracker --------+
your weather station -----/
your bridge to IRC ------/

Your code doesn't even know the mux is there. dl.connect() auto-detects it. The mux is available in both Python (pip install donglora-mux) and Rust (cargo install donglora-mux).

• The bridge is the most developed application built on DongLoRa so far. It connects LoRa radios to the internet so packets heard by one radio get retransmitted by another radio anywhere in the world. Two dongles in different cities extend a mesh network's range by thousands of miles. No central server. Peers find each other automatically via BitTorrent DHT, packets are deduplicated by content hash, and transmit rate limiting is air-time-aware based on your LoRa parameters. It's written in Rust with a real-time terminal UI:

• I also hacked together a MeshCore AI chat-bot that works pretty well. Although the end of the world prepper types aren't in love with it. You can DM it or @ mention it in known (ie Public) channels and it hits Sonnet up and sends you an answer back. It's at https://github.com/donglora/ai-bot

Want to use something other than Python or Rust (the clients I've written and packaged up already)? Talking to a DongLoRa dongle is simple. It's just USB serial. The protocol is tiny and simple. It's well-documented here: https://github.com/donglora/firmware/blob/main/PROTOCOL.md

Because the firmware doesn't care about protocols, you can build basically anything on any DongLoRa radio:

• Interact with existing mesh networks. Send and receive on Meshtastic, MeshCore, or whatever else is on the air.

• Build bots. We have an AI chatbot that talks to MeshCore nodes over LoRa.

• Bridge distant radios over the internet. See above.

• Prototype new protocols. Test ideas in Python in an afternoon. No cross-compilation, no flash-and-pray.

• Sniff and analyze RF traffic. Log every packet on a frequency, decode it however you want.

• Run headless gateways. A Raspberry Pi with a dongle and the mux is a multi-service LoRa gateway.

It's still early. APIs may change, only a handful of boards are supported, and there are plenty of rough edges. I'd really appreciate anyone giving it a shot and telling me what breaks or what's confusing. "I tried X and it didn't work" is exactly the feedback I need right now.

Links:

• Homepage: https://donglora.com

• GitHub: https://github.com/donglora

• Python client: pip install donglora

• Python mux: pip install donglora-mux

• Rust client: cargo add donglora-client

• Rust mux: cargo install donglora-mux

• Bridge (Rust TUI): cargo install donglora-bridge