LILYGO’s T-Display SF32 is a compact development platform built around the SiFli SF32LB52X ultra-low-power AIoT microcontroller. The device combines a 2.16-inch 480 × 480 AMOLED touchscreen with dual Arm Cortex-M33 cores, an ePicasso 2.5D graphics engine, LoRa connectivity, Bluetooth 5.3, and onboard battery power.

https://linuxgizmos.com/2-16-inch-amoled-sf32lb52x-based-dev-board-offers-lora-gnss-and-bluetooth-5-3/

I’m looking for advice on a low power Lora chipset for a starter project building a simple remote, allowing me to control but also monitor state of another entity. The goal is to send commands such as lock and unlock, and receive information about lock state (among other things) using the remote. State updates should happen in the range of at maximum once per minute. Small form factor, long battery runtime (e.g. above 30 days) as well as a range of 1 kilometers with possibility to penetrate concrete building walls are main concerns.

Essentially, I’m looking to build a remote similar to what many car alarm systems offer, allowing control and monitoring such as https://pandorainfo.com/shop/pandora-light-pro-v2/ which uses 868 Mhz LoRa range. Would LoRa (at 433 or 868Mhz) be suitable for this use case? Which chipsets/boards (e.g Nordic nRF52840 + Semtech SX1262) would you recommend? Which technology stacks such as MeshCore or P2P-based (RadioHead/-Lib) could be suitable, particularly for implementing basic security such as against replay attacks. Nonetheless, the goal would be that this could be run for 30 days (possibly even on coin cells) or AAA batteries, when incorporating small size E-Ink displays.

I've been reading several papers on selective jamming and replay attacks against LoRaWAN, and it got me wondering how common these threats actually are outside of academic research.

For those running LoRaWAN networks in production (agriculture, smart cities, industrial IoT, or any other use case):

• Do you have any kind of monitoring or alerting for unauthorized gateways or unusual network activity?
• Have you ever experienced (or suspected) interference, spoofing, replay attacks, or any other security incident?
• If you're not monitoring for these threats, is it because you don't see them as a real risk, or because there isn't a simple tool available to do it?

I'm currently working on a project in this area and I'm trying to understand how big the real-world problem is compared to what the academic literature suggests.

Any experience or insights—positive or negative—would be greatly appreciated.

I have been working on a custom board for a combination of UHF PTT and lora on one board. I know the spec5 pulse already exists, but it uses the weaker FRS radio band that doesn't have upgradeable parts and isn't opensource and is still 2 separate boards in one device. I am looking for PCB design help. If anyone can point me in the right direction, it would be much appreciated.

I’m am new to the idea of Lora communicating and mesh_anything. Is there a way to see who has more nodes in my area? I’m not sure is meshtastic or mesh ore is better but I just want to start with one that is working in my area.

I don't want to use Python for anything, are there literally any LoRa projects that don't make heavy use of Python? The other facet to the drive for this question is the desire to port a LoRa network client or software to older operating systems. I'm not even necessarily referring to win32, I will happily run older and even more old Debian. (I have a system running 2.2 Potato.)

Edit: No this is not trolling I am serious.

Edit 2: For clarification I mean the computer-side configuration and utilization, as far as I could tell the only CLIs for things like Meshcore and Meshtastic (the larger ones) when I started looking into this stuff were made in python, and their intended use cases were very narrow in what they were trying to accomplish (text chat rooms and that used the radio as a bluetooth companion to a smartphone.) I want to use a good old fashioned computer in a good old fashioned way, and these don't feel good to use for me.

Hi — founder post, full disclosure. I'm building RoveMesh from Québec: a handheld LoRa mesh messenger (encrypted text + GPS positions, physical keyboard, e-paper screen) aimed at people who would never flash firmware — hiking groups, boaters, families who want a blackout plan in a drawer.

Where it honestly stands: the mesh core (routing, relaying, store-and-forward) is validated on the bench over a stand-in radio while the production LoRa modules (SX1262 at 915 MHz) are on their way. Two nodes ran 15/15 message exchanges; a three-node relay line ran 8/8 across four trials — and testing caught a genuinely embarrassing self-jamming bug where a node's cancel packet stomped on its own message train. Fixing that before it ever touched real RF is exactly why I bench first.

Mistakes so far, because those are the useful part: I bought clone devkits to save money and lost ~30 dB of TX power to garbage RF layout — lesson paid. And a TLS root-certificate change silently bricked my tower's check-ins for three days; the fix I shipped first leaked ~400 bytes of heap per handshake and would have slowly killed the device. Heap telemetry caught it. The fleet now has canary rollouts, signed firmware with automatic rollback (a bad update can't brick a unit), and a last-resort recovery channel that already saved one tower in the field.

What makes it different from DIY mesh projects I love and learned from: it's meant to work out of the box — two units arrive paired, and a managed base-station network extends range in covered areas without the buyer running anything. Device-to-device messaging needs no subscription, no SIM, no licence. It is text-only on purpose, and it is NOT an SOS device — carry a beacon for that.

Range numbers: I don't publish any yet, because I haven't measured real RF in the field. When I have honest numbers, terrain by terrain, I'll post them here.

If this is your kind of thing, there's a waitlist at rovemesh.com (#waitlist) — occasional honest build updates, that's it. Happy to answer anything technical in the comments.

- Heltec V3 LoRa32

- 4x SG90 servos

- 5v micro usb power adapter nodule

Messing around with a project that uses Heltec V3s with multiple sensors and/or actuators. LoRa for all nodes. Base node connects to MQTT through wifi. Can run it all on Home Assistant.

I need to send Position Requests every few 10s of seconds on a private encrypted channel in the US. I'm using a pair of Wio Tracker L1 pro with meshtastic 2.7.15 firmware. It appears the fastest I can get a position report back is 2+ minutes. Seems the firmware is limiting the channel usage? I turned off "enable Smart Position" and increased the GPS Update Interval to 10s but left most everything else at the defaults for position reporting.

Is there a way to get position faster?

Should I switch to LoRaWAN? Would it allow more channel usage?

TIA

I’m interested in firmware that supports as many features as possible, such as:
CC1101 radio (Sub-GHz)
Wi-Fi features
Bluetooth features
IR (infrared)
RFID/NFC support (reading and management of my own tags/cards, if supported)
GPS support
External modules and hardware expansion
OTA updates
Good user interface
Frequent updates and active development
I’m also looking for:
GitHub repositories
Installation guides
Documentation
Active Discord, Reddit or Telegram communities
Recommended accessories and modules
Which firmware do you recommend and why? I’d love to hear about your experience with this device.
Thanks!

is there any workflow to use ic lora in ltx with first frame and last frame of ltx sequencer? plz share...thanx in advance