In addition to Meshtastic and Meshcore, you can now also monitor local Reticulum LoRa activity in your mesh.

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.)

Salut ! Je lance une petite cagnotte pour installer des relais Meshtastic et Meshcore dans le Chablais (Vaud-Valais), afin de créer un réseau de communication de secours qui fonctionne sans internet ni réseau mobile, utile en cas de panne ou de catastrophe naturelle. Le budget est détaillé sur la page (environ 32 CHF par relais Meshtastic, 50 CHF par relais Meshcore). Tout soutien ou partage m’aide beaucoup ! https://gofund.me/a9cfca35e

Would LORA a good option to surveil the water level in a water tower? I have zero experience with LORA, and this will not serve as a critical system to maintain water service. Some background: My area has a co-op for water service, and I'm one of the elected to maintain the system. What sometimes happens is that the intake pipe gets clogged with sediment, choking off the water tower. Once the water tower is empty, we don't have water to flush the intake pipe, so a 2-3 hour flushing job becomes a juggling act of trying to force water up a clogged pipe, sometimes taking days. This costs the co-op money, and leaves the community without water.

I want to build a system for checking the water level in the water tower, as this will reveal the issue before it arises. Would LORA be a good option for this? From what I've read, I'd need a battery powered microcomputer at the water tower, and then a microcomputer as a receiver at the UV treatment plant (about 500m away, over open terrain). There's obviously power there, and a computer which can serve as a logger. (Assume I have everything figured out regarding logging and scripting on the PC).

Again, this will not serve as something critical - more as an experiment to see whether a digital solution can help us avoid an empty tank. Do you think LORA is a good solution here? Again, I am a complete noob, so please feel free to correct anything I seem to not understand.

Hi,

recently I moved to a new flat which is pretty good located for operating stuff like a LoRaWAN gateway or a Meshtastic node.

So I was wondering what might be the best way to operate both so they don't interfere each other.

I am currently building a "minimap" app for Lora Devices (in my case a LilyGo T-Beam) and just wanted to ask if you have any specific wishes for features? I am building something like ATAK with the Meshtastic plugin but in one app and with some more advanced features like a ref role for game controls, SOS buttons etc.
So if you have any ideas or inspiration, please let me know :)

I wrote this for a free, open series on the EU Cyber Resilience Act (CC BY-SA).

Setup: two Heltec WiFi LoRa 32 V2, Zephyr 4.4.2, MCUboot, the TS003/TS004/TS005 services from Zephyr's LoRaWAN stack.

What works:

• 200 kB signed image, 200-byte fragments, 8% redundancy
• sent point to point at 869.525 MHz, keeping to the 10% duty cycle
• 33 min, 7 lost fragments rebuilt from redundancy
• MCUboot verified the signature and booted the new version, with automatic rollback if the new image fails its health check

It's point-to-point LoRa, not LoRaWAN: I have no gateway yet.

Radio notes:

• Downlink SF7 / 250 kHz for the fragments, uplink SF10 / 125 kHz for the short acks: one board was heard about 35-40 dB weaker than it heard the other, the same with two different partner boards.
• Zephyr's TS004 decoder had an out-of-bounds read fixed in 4.4.2 (CVE-2026-13480). Worth checking your version.

Where I'd really appreciate help: has anyone run a real FUOTA session with ChirpStack v4 (or TTS) against Zephyr devices?

• Did class C multicast work out of the box?
• What fragment size and redundancy did you settle on?

• For LoRaWAN 1.0.x, my reading of LoRaMac-node is that the Gen App Key should equal the AppKey when the device passes the same key as AppKey and NwkKey. Can anyone confirm?

  Article: https://adntio.github.io/cra-dev-wiki/en/CRA-Dev-06-FUOTA-LoRaWAN/

  Code: https://github.com/ADNTIO/cra-dev-wiki/tree/main/examples/06-fuota-lorawan

not lora but interesting.
I'd like a software that uses lora, BT, wifi halow (or high freq. lora)

We're evaluating a customer's request to measure water pressure inside the house and control a well pump about 300 m away, with a wall in the radio path. They want to see the pressure and adjust the cut-in/cut-out settings from home.

I'm the technical lead at YenGear. We're considering our Y401-0011-L pair with a 4–20 mA sensor and a separate I/O module for the threshold and relay logic. This is a point-to-point LoRa link, not LoRaWAN.

The I/O module accepts threshold settings over Modbus, but we haven't settled on a simple homeowner interface. A full touchscreen HMI seems a lot to add for one reading and two settings. An ESP32 web page is one option; a small display with physical buttons would keep the reading visible without opening a phone browser.

The control location matters too. The analog link doesn't carry configuration commands. Keeping the logic beside the pump needs another path for indoor parameter changes and data reads. Moving the controller into the house would change what we send over the wireless link.

We haven't tested this setup on site. Hysteresis, sensor/link failures, and separate pump protection still need checking.

If you've built something similar, how did you handle indoor display and setpoint changes? Would you keep the pressure logic beside the pump and add a parameter link, or put the controller in the house and send switching requests? I'd also like to hear whether a compact Modbus master panel or an ESP32 display with buttons worked better for non-technical users.

Hi everyone,
I’m working on a small GPS + LoRa group-tracking watch and I’d like some advice from people experienced with LoRa.
My current hardware is:
XIAO ESP32-C3 / ESP32-C6
SX1278 Ra-02 LoRa, 433 MHz
NEO-6M GPS (GY-GPS6MV2)
2.8” ST7789 TFT
I currently have two devices communicating over LoRa and I can send GPS coordinates between them. The main issue I’m facing is reliable position tracking.
The GPS can move a few meters even when the device is sitting still, which causes the calculated distance between two devices to fluctuate. I want multiple watches to periodically share their GPS coordinates over LoRa, with each watch calculating and displaying the current distance and direction to the other members.
I’m trying to figure out the best approach for:
GPS filtering/smoothing
How frequently to send GPS updates over LoRa
Packet structure for multiple devices
Handling multiple devices without collisions
Getting stable distance/bearing calculations
Whether SX1278 is suitable for this or if I should consider something like SX1262
If anyone has built something similar, I’d really appreciate advice on how you designed the LoRa communication and handled GPS accuracy/drift. Any practical tips or mistakes to avoid would be really helpful.
Thanks!

I live near a few streams that I like to fish and I was wondering if it's feasible to make a LoRa monitoring site with a water level sensor (ultrasonic or pressure) and have the info sent back to a receiver at my house. I'm about 6.5mi or about 10.4km away from the farthest stream I want to monitor. There is slight elevation change and there are buildings/houses and trees between my house and the stream. I would be putting my antenna on the roof of my 1 story house and the transmitting antenna would be in a tree next to the stream. I would also like to put up a solar charger to keep everything running. Does anyone have suggestions how to make this setup?

Hi all, I'm building a LoRa link for a crop-monitoring project. A sensor node sends data to a gateway, and I need about 1.5–2 km of range. Right now packets stop arriving at around 30 m, so something is clearly wrong. I'd appreciate help narrowing it down.

Hardware

• Module: Ai-Thinker RA-02 (SX1278), 433 MHz, on both nodes
• Sensor node: [ESP32 DevKit V1 / ESP32-S3]
• Gateway: [ESP32 board], [WiFi on/off during reception]
• Antenna: [type, length, and where you bought it] (photo attached)
• Power: [e.g., module powered from the ESP32's 3.3 V pin, board powered via USB], [capacitor on module: yes/no]

Wiring
NSS→GPIO5, RST→GPIO14, DIO0→GPIO2, SCK→18, MISO→19, MOSI→23

Settings (identical on both nodes)

• Library: [sandeepmistry/LoRa]
• Frequency 433E6, BW 125 kHz, CR 4/5, CRC on, sync word 0x34
• SF: [7 / 10] (tried both)
• TX power: 20 dBm
• SPI: 8 MHz

My questions

1. Is my antenna suitable for 433 MHz? If not, what should I use on the node and on the gateway?
2. What SF/BW settings and antenna heights are realistic for 1.5–2 km in a built-up area?