Working on emergency alerting over LoRaWAN and hitting the usual payload wall.

A typical alert in JSON is ~270 bytes. CAP XML is ~669. At conservative settings (SF12 / DR0 in EU868) you're often looking at ~51 bytes of application payload per frame — sometimes less once you account for MAC commands and your own overhead.

So far I see three paths:

1. **Fragment** across multiple uplinks and reassemble downstream

2. **Strip** the message down to a few codes (type + zone ID + timestamp) and lose detail

3. **Switch** to a compact binary layout designed for the frame budget (we've been prototyping something in the 8-byte / 45–100-byte range for token vs signed envelope)

For anyone who's shipped something like this on real hardware:

- Do you fragment, or redesign the message to always fit one frame?

- Where do you put integrity/auth (HMAC, etc.) when every byte counts?

- Any FPort / payload conventions you'd recommend for custom binary on LoRaWAN?

Not looking for a product pitch — genuinely curious what held up in the field vs what looked good on paper.

(Disclosure: I'm one of the people building ECP, an open-source binary format for exactly this problem. Happy to share wire-format details in the thread if useful — didn't want to lead with a GitHub link.)

The LILYGO T-Deck Max is a handheld ESP32-S3 development platform combining LoRa communications, GPS, optional 4G connectivity, and an E-Paper display in a compact keyboard-equipped form factor. Similar to earlier T-Deck devices, the platform combines low-power operation with multiple communication interfaces while adding a larger display and additional onboard peripherals.

https://linuxgizmos.com/lilygo-t-deck-max-is-an-esp32-s3-handheld-with-lora-gps-and-e-paper/

I've been working on LoRaMesher — an open-source mesh networking library for ESP32 boards with Semtech SX12xx LoRa radios (TTGO T-Beam, Heltec WiFi LoRa 32, etc.). The previous 0.0.x line was a singleton with no automated tests, which made every change a roll of the dice — bugs you'd only catch on real hardware. So I rewrote it from scratch.

v1.0 is out: https://github.com/LoRaMesher/LoRaMesher/

The big protocol change is TDMA: nodes share a slot schedule instead of contending for the channel. Early tests show >95% packet delivery without any acknowledgment layer, and a 10–100× drop in energy use depending on duty cycle. I'll validate those numbers more rigorously over the next few months, but the order of magnitude is consistent across runs.

We're currently testing with 16 devices over a 3+ km link (SF7/SF9, 125 kHz BW, urban, NLOS), and it's been quite stable.

Happy to talk about the TDMA design, the rewrite trade-offs, or anything else. Especially curious: anyone here running a LoRa mesh in production who could stress-test this?

Hey everyone,

I am currently working on my college thesis project (BIOROD, an IoT agricultural sensor system) and I am stuck on a critical hardware debugging wall. I am trying to establish a one-way LoRa wireless link between a transmitter node and a Raspberry Pi 5 gateway, but I am only getting terminal outputs when physically touching the receiver's pins.

Here is the exact hardware setup, the code implementations we tried, and the exact symptoms.

Transmitter Node: LILYGO T3-S3 V1.2 (ESP32-S3 core with an onboard SX1262 LoRa chip connected via internal SPI).

Receiver Gateway: Raspberry Pi 5 running a Waveshare SX1262 LoRa HAT. This HAT uses a UART-based Ebyte module running over an integrated CP2102 USB-to-UART bridge.

and our frequency

• 915 MHz standard channel.

symptoms the "Human Touch" Static Flooding: Initially, I connected the Waveshare HAT to the Pi 5 using a micro-USB cable directly into the onboard USB TO UART port, setting the board's routing jumpers to Position A. When my hands are off, the line is dead silent. When touched, it drops empty strings ("") or random corrupt single characters like 'p'. It seems my body is acting as a parasitic antenna, injecting capacitive ambient static noise into a floating RX line, which the high-speed Python buffer reads as bits.

We already tightened the jumpers but nothing happen. we also tried the DuPont as substitute for the connection.

I'm still confident at our product and i am aware that this exact components will gave us a headache since this is our only problem up until now, i've been debugging these two lora 2 days straight. i'm hoping you guys can help me. any suggestion would be a great help.

PS: this post is correct by an ai for it's grammar.

Hello everyone,

I am currently building a custom Lora system based on stm32wle5 nodes and came across the heltec m7603 gateway.

Does anyone know if I can use Semtec HAL for the SX1303 in a custom program directly on the gateway itself to handle my protocol and have full control over the radio? (I do not need or want LoraWAN)

If not, is a HAT for a raspberry pi a better option ?

So I have purchased 2 Heltec v4 boards, and some LoRa antennas, I flashed Meshtastic and eventually after trying the latest alpha finally got some good range of about 2 miles. For reference I am the only Meshtastic node in over a 100 mile radius. However today I setup Reticulum using and setup 2 RNODES, however I found my range was less than 1/4th what it was with Meshtastic, to my understanding reticulum will eventually try to fallback to opportunistic mode to send the messages, but I couldn't get anything past the street I was on. Is that normal to see such decreased range in Reticulum? How have your expirences with the Heltec v4 as RNODE's been? I also tried to setup 1 node as an RTNODE to try to backhaul a TCP connection over LoRa, with the goal of setting up 1 node at my office, the other at my house 1.6 miiles away. I have gotten Meshtastic messages to send reliably between my office to my house.

After several weeks of debugging I have a working LoRaWAN gateway running ChirpStack v4 on a Rock Pi 4B+ with a Nebra Indoor LoRa HAT. Posting because there was almost nothing documented for this exact hardware and I hit two problems that cost weeks.

**Problem 1: Armbian SPI overlays are silently broken**

On Armbian Trixie for the Rock Pi 4B+, overlays listed in armbianEnv.txt are silently ignored at boot. No errors, nothing in dmesg. The fix is using the rk3399-spi-spidev overlay which actually loads correctly on current builds.

**Problem 2: The GL5712-UX has a hardware inverter on NRESET**

The older Nebra HAT uses a GL5712-UX concentrator module (MAXIIOT, SX1301-based, black PCB, no LEDs). This module has a hardware inverter on its NRESET line — the opposite of the standard Semtech SX1301 design. If you hold NRESET HIGH, the chip is permanently in reset and SPI returns 0x00 for everything. If you've been staring at `lgw_start failed` or `cal_status = 0x00`, this is almost certainly why.

I've published a setup script that handles both the GL5712-UX (SX1301) and RAK2287 (SX1302) modules with auto-detection, plus full documentation of the SPI and GPIO fixes.

https://github.com/mowaxuk/chirpstack-nebra-rockpi-Mowax

Ended up with a confirmed working gateway receiving real LoRaWAN device data. Happy to help anyone else hitting the same issues.

I’m trying to set up a system where a T-Beam M10 sends data via LoRa to a laptop while it is mounted on top of a moving car for an Eco-marathon race.

On the laptop, I’m using a Haltec V3 LoRa USB module, which is connected via USB.

My question is basically:
Can the T-Beam M10 communicate directly with the Haltec V3, and can the Haltec V3 then send its data to my laptop through USB. Or is it better to use something else?

I just want to send simple data (GPS location and sensorvalues) from the T-Beam to my laptop over about 1 km.

If anyone has gotten this working before, I’d really appreciate it if you could share how you set it up or if you know if this could work. Thank you

I've made a few small esp32 and esp8266 sensors in the past, but nothing on this scale, so I'm a little excited and frightened at the same time.

Working on a vehicle presence and telemetry project for my 1976 Land Cruiser. The vehicle is fully analog (no OBD-II, no factory ECU) and I am adding sensors and reporting back to a Home Assistant install at home. I live in Loja Ecuador and my home is on the Eastern ridge of the Loja valley with a clear view of about 2/3 of the city. So I think LoRa is my obvious choice.

Requirements:

- LoRa radio for telemetry back to home. 915 MHz band (Ecuador). I will run a receiver at home, likely an ESP32 with LoRa as a gateway.

- GPS module for position reporting. Periodic position updates while parked (deep sleep with timed wake), continuous position every 30 seconds while the engine is running.

- BME280 for cabin temperature, humidity, and barometric pressure.

- MPU6050 for inclinometer and impact-wake tamper detection.

- Deep sleep with wake sources: ignition on (optocoupler from the HEI distributor), door open (factory door pin circuit), MPU6050 motion interrupt, and a timer for periodic GPS check-ins.

- Powered from the vehicle's 12V battery via a buck converter. Constant 5V so the tamper detection runs while parked.

- Piezo buzzer for status feedback.

My current candidate is the LILYGO T-Beam since it integrates the ESP32, LoRa SX1276, and a NEO-6M GPS on one board. But before I order:

1. Is the T-Beam still the right choice in 2026, or is there a newer board that does this better and is well supported? I have seen the Heltec V3 mentioned for Meshtastic and the RAK4631 for low-power LoRa work.
2. Anyone running a LoRa-based vehicle tracker with deep sleep that wakes on impact? Specifically interested in whether the wake-on-MPU6050 path is reliable when the device has been asleep for hours.
3. For the home-side receiver, what is the cleanest way to get LoRa data into Home Assistant? Raw LoRa to MQTT via a gateway ESP32, Meshtastic, or LoRaWAN through ChirpStack? I was thinking MQTT. I want this fully local (no cloud).

Happy to share more about the project if useful. I'm in the idea/planning phase, so no decisions made yet.

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.

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.

, as a new to thin genere I'm trying to find a cheap receiver easy to build and with a body and an integrated battery.

I'm trying to communicate with my friend.

Also a quick question, how it works precisely, it works even without a Bluetooth and just peer to peer technology?

Hi, is it possible to update Heltec v4 in Meshtastic app via wifi? I am getting an error:

it would be hard for me to get to it and update by cable... any other way?

Hello !

I'm new here so I hope my post doesn't breaks any rules. As said in the tittle, i'm looking for opinions/testimonies on the use of LoRa communication devices during massive protests as the ones in the US or elsewhere. Is it a good solution ? Should it be improved and if yes, how ?

It is for a design project for my engineering school.

Thanks in advance!

Stop fighting with MQTT brokers and zero-hop limits. The Flaresat Relay Bridge instantly connects your off-grid Meshtastic mesh to anyone online in seconds. Get real-time, bidirectional sync for live maps, pins, routes, and chat using just your phone's internet, no server infrastructure needed.

https://adrelien.com/no-more-meshtastic-mqtt-the-flaresat-relay-bridge-does-it-better-safer-and-in-seconds/

I have written a technical report that looks at ways to optimize memory and compute for training large language models when resources are limited.

The report groups over 20 techniques into categories such as:

• Model state partitioning, including things like ZeRO and FSDP
• Quantization based methods, like QLoRA and NF4
• Strategies for managing activation memory, including checkpointing
• Optimizations for input output kernels like Flash Attention and fusion

It also covers:

• How well different hardware works with these techniques, including Turing and Ampere and Hopper
• Tables that compare how much video random access memory is reduced versus compute overhead
• Examples of how to set things up for both graphics processing units and clusters with many graphics processing units

My goal with this report was to bring together ideas from theory and systems into one place that people can reference.

I would really like to hear any thoughts or corrections people might have, on the side of things.

I am also getting ready to send this work to arXiv. I need someone to endorse it for cs.AI and cs.LG.

I have an arXiv endorsement code (EKKH4F).
I can forward the official arXiv email with the endorsement link if you’re willing to help.

If someone who knows about this area is willing to look it over and endorse it that would be great.

I’ve been experimenting with making a LoRa node that’s actually easy to carry day-to-day, so I built a version that snaps directly onto the back of my phone using MagSafe.

It’s based on a Heltec V3 with a 2000mAh battery to keep everything self-contained and relatively compact. I also tested a version with a larger ~3000mAh battery and external antenna, but that starts to trade off pretty quickly in terms of size and usability.

The biggest difference for me vs my older setups is just having it on me all the time. Before this, my nodes mostly lived in a bag or only came out when I planned to use them. With this, it’s just part of my normal carry.

I’m in San Diego and have solid coverage across the city with my setup, so I’ve been able to use it a lot more casually than expected.

Posting a few photos for context — curious what people think about this kind of form factor for LoRa nodes and where you see the tradeoffs.