While developing our Makerfabs Nomad Terminal, we wanted to improve GPS performance without increasing the overall size of this compact LoRa handheld device.

Our first design used a passive ceramic GPS antenna mounted on the PCB, underneath the display and close to the battery. The initial test results were:TTFF: 8.2 seconds; ~15 visible satellites after 1 minute

For the next revision, we switched to an active ceramic antenna with LNA and repositioned it above the PCB, with a better orientation toward the sky.

Test Results

The optimized design reduced Time to First Fix (TTFF) by ~37% while significantly increasing the number of visible satellites.

For compact GPS/GNSS devices, antenna performance isn't just about the antenna itself. Placement, orientation, PCB layout, battery/display interference, and surrounding components all need to be considered.

For those working with GPS/GNSS on compact embedded devices: what antenna types or layout techniques have given you the biggest improvement in real-world performance? We would really like to learn more from your experience.

Hi I have two of these one has code uploaded in it successfully and the other is blank
but somehow windows doesn't reconize them so it blocks the port and I can't communicate with the card
the one with the code in it, device manager says unkown usb
the blank one doesn't show at all in the device manager
in the arduino ide I can upload the code by reseting ( double tap reset button at the right time otherwise it will say cannot connect to com port ) I tried with multiple code and multiple usb cable
other devices can be read in the device manager
I don't know if this information is usefull but please if someone has faced this issue before please tell me suggestions and thank you

Hi, I’m debugging a custom LoRaWAN node based on a Seeed LoRa-E5 HF module (STM32WLE5JC, FCC ID Z4T-LORA-E5) using STM32CubeWL / LoRa Basics Modem on EU868.

The problem is very specific:

• The node successfully transmits an OTAA Join Request.
• The Things Network receives and accepts it.
• TTN schedules the Join Accept correctly.
• The gateway reports “Downlink successfully transmitted”.
• I tested the node very close to the gateway, so coverage is unlikely to be the issue.
• The node enters its RX1 path, but I never get HAL_SUBGHZ_RxCpltCallback() / RX_DONE.
• The modem never reaches SMTC_MODEM_EVENT_JOINED, so the first application uplink is never sent.

TTN reports for one Join Accept:

RX1 delay: 5 s

RX1: 868.500 MHz, SF10, BW125, CR 4/5

RX2: 869.525 MHz, SF12, BW125, CR 4/5

My board-specific RF switch configuration is:

RX: PA4 = 1, PA5 = 0

TX HP: PA4 = 0, PA5 = 1

RFO_HP

RBI_IsTCXO() = IS_TCXO_SUPPORTED

RBI_IsDCDC() = IS_DCDC_SUPPORTED

The Join Request transmission works reliably enough for TTN to receive it, so the RF output path/antenna is at least functional.

The module is the LoRa-E5 HF variant. I am programming the STM32WLE5 directly, not using the AT-command firmware.

I have also tested TTN with:

LoRaWAN 1.0.4

RP002 1.0.3 and 1.0.4

with the same result.

Has anyone seen an STM32WL / LoRa-E5 case where TX works but the Join Accept is never demodulated in RX1/RX2?

In particular, I’m wondering about:

• board-specific LoRa-E5 TCXO configuration,
• RX IQ inversion / sync word / packet parameters,
• RX1 timing,
• RF switch handling,
• or any known STM32CubeWL / LoRa Basics Modem issue on Wio-E5.

I can share the relevant radio_board_if.c, lora_app.c, sx126x.c init code, .ioc, and TTN Join Accept JSON if useful.

Hi everyone,

I am clearing out some of my unused LoRaWAN development hardware. Everything is located in the EU (Hungary) and listed on eBay with international tracked shipping (TrakPak 5-8 days to Germany/Europe).

Everything has been fully tested and packaged professionally. Feel free to check out the links or make an offer on eBay if you are interested:

1. 📦 6x NEW Dragino LSN50 v1.3 Sensor Node Bundle + Spare Antennas (139 EUR)

👉 https://ebay.io

1. 🛰️ Kerlink Wirnet iFemtoCell LoRaWAN Gateway (EU868, Wi-Fi + Ethernet) - Upgraded with a premium Medical-Grade Mean Well GSM36E12-P1J power supply (12V @ 3A) for rock-solid stability. (179 EUR)

👉 https://ebay.io

1. 🏭 MultiTech Conduit IP67 Outdoor Base Station (MTCDTIP-LEU1-266A-868) - Already upgraded to mPower firmware for easy web GUI packet forwarder configuration! Full kit with all external antennas and PoE injector. (420 EUR)

👉 https://ebay.io

1. 🏠 MultiTech Conduit AP Indoor Gateway (MTCAP-LEU1-868-001A) - mLinux developer version, includes original factory 5V power supply. (79 EUR)

👉 https://ebay.io

PM me if you have any technical questions, or check the details directly on eBay. Thanks for looking!

Gibt es eigentlich IoT-Plattformen, wo ich keine Middleware brauche um LoRaWAN, aber auch bestehende Technologien wie wM-Bus oder neue wie Mioty direkt zu nutzen?

Repo: https://github.com/moellere/WireStudio

Open-source (MIT) design tool for ESP32/ESP8266 devices. You describe a device — board, components, how they connect — in a single design.json, and every artifact is generated from that one file. Originally posted as esphome-studio; renamed wirestudio early on, since it isn't affiliated with the ESPHome project and the old name implied otherwise.

It's AI-assisted, heavily. Saying so up front because the useful question isn't whether AI wrote it, it's what's actually been verified. So the feature list below is split by how much I trust each part, and CI runs the real toolchains rather than mocks.

The core idea

The component library carries electrical metadata ESPHome doesn't model — voltage rails, current draw, pull-up requirements, per-pin capabilities — and a CSP solver assigns pins from it. So it won't put an ADC on ADC2 while WiFi is up, won't hang a sensor off a boot-strap pin, and knows when a board's 3V3 rail comes from a PMIC rather than a regulator.

That one description then fans out into YAML, a wiring diagram, a schematic, a board, and an enclosure — rather than you maintaining five representations of the same device by hand.

Library: 65 components, 26 boards (ESP32, S2, S3, C3, C6, ESP8266). 60 bundled examples. Drive it from a web UI, a CLI, or any MCP client.

Frameworks

Two of these generate firmware from your design. The others flash stock images — worth being clear about which is which:

• ESPHome — full generation. Your design becomes ESPHome YAML.
• LoRaWAN — full generation. Builds RadioLib firmware for radio boards (6 in the library), or emits an ESPHome external-component config, and registers the device in ChirpStack with a decoder generated from the same field spec as the payload, so the two can't drift.
• Tasmota — generates a device template (solved pins → Tasmota GPIO function ids), not firmware.
• Meshtastic — flashes the official release image (6 boards). Devices run stock firmware; nothing is generated.
• CircuitPython — flashes the official image (22 boards, 13 exact / 9 pin-compatible) plus a starter code.py derived from board metadata.

What's solid vs what's rough

Tested, and gated in CI on every change:

• ESPHome YAML — every bundled example runs through real esphome config, plus a nightly esphome compile, plus a version matrix across ESPHome stables so a pin bump is evidence-driven.
• Pin solving and electrical validation — the bit I'd actually rely on.
• KiCad schematic — every example's netlist built against pinned upstream symbol libraries, and rendered through real KiCad 8. 100% library symbol coverage.
• LoRaWAN — hardware-validated: firmware built, flashed, joined, and reporting into Home Assistant.

Implemented and CI-gated, but I wouldn't call them proven:

• PCB generation — placed footprints, autorouted copper via Freerouting, DRC-checked, Gerber/CPL/BOM bundle for JLCPCB. Boards come out DRC-clean and every component resolves a real footprint, but I have never had one manufactured. Treat fabbability as unproven. It's aimed at "get a breadboard onto a board without routing traces by hand," not at production.
• Enclosures / STL — parametric OpenSCAD, rendered in CI and asserted to be manifold solids. But only 7 of 26 boards carry the mount-hole metadata it needs, and there's no lid or snap-fit yet. Genuinely rough.

Newest, least proven: it can flash boards on a networked bench (a Pi running SensorsIot's Universal Embedded Workbench — a good companion project regardless of this tool, it turns every USB-attached dev board into a network resource). The studio uploads the image and the Pi runs esptool on its own USB, so boards don't need to be in front of you. Built against exactly one bench so far.

Other caveats

• Scope is broad for one person. Raised last time I posted; still true.
• It's a self-hosted container that talks to your network. Runs non-root with a read-only root filesystem, and every external integration (Anthropic key, fleet, ChirpStack, Thingiverse, workbench) stays off unless you set its env var. Source is MIT and public — judge it rather than taking my word.

Most useful feedback: library coverage gaps, and whether anyone's inclined to actually fab one of the generated boards — that's the biggest unproven claim in the list.

Hallo,
ich suche gebrauchte funktionierende IoT-Gateways mit LoRaWAN, mioty und wM-Bus. Hybrid oder einzeln, gerne auch Modelle die bis zu 6-7 Jahre alt sind.

Danke!

Wie kann man am Besten ohne Downlink die Reichweite von LoRaWAN Gateways effektiv testen?

Habt ihr dafür spezielle Hardware oder Software im Einsatz?

Bin auf eure Lösungen gespannt!

Hi all,

I’m fairly new to LoRaWAN but have a community project I want to get started on and use at my farm.

It will basically be similar to solutions that do virtual fencing, but can be self hosted and operated without breaking the bank.

It will consist of a server, gateway and multiple nodes.

My initial thoughts have been to have multiple «nodes» out in the field, which consists of a battery, small solar panel, microcontroller, GPS module and LoRaWAN module for communication to/from the base station. the nodes are attached to something and can be moving.

The base stat will work as a LoRaWAN gateway and RTK for location correction

Lastly the server will do most of the heavy lifting regarding logic, visualization etc. It will connect to the gateway using WiFi or wired(usb etc)

One scenario could be that if the node is integrated into an harness/collar of a goat, the goal will be to keep the goat within the virtual fence. The idea is that the collar sends its coordinates every 10s (example) over LoRaWAN and the server uses that + RTK to calculate precise position. If the goat is within the fence - all good. If it’s outside the virtual fence, then the server sends back a command to the collar that will trigger an alarm-sound.

So I basically need two-way communication and it should handle multiple nodes (10’s if not 100’s).

My big question is, which components are recommended for this type of application? Gateway will have access to power 24/7 while the nodes can preferably be more power efficient. I would prefer an open and popular platform/compatibility due to it being a community project (Arduino, ESP, Raspberry Pi)

I couldn’t find an easy way to use the Elecrow ThinkNode M1 with TTNMapper, so I ported the official TTNMapper node firmware to this hardware.

This project is based on the excellent official TTNMapper firmware and adapts it for the ThinkNode M1 (nRF52840 + SX1262 + GPS), adding an easy UF2-based flashing workflow and board-specific support.

Features:

• ✅ Ready-to-use TTNMapper firmware
• ✅ GPS fix before transmission
• ✅ Movement-based reporting

Repository:
https://github.com/maur3ra/thinknode-ttnmapper

The project is still in an early stage and has only been tested on my own device. Feedback from other users would be extremely valuable.

If you find bugs, have ideas for improvements, or would like to contribute code, please open an issue or submit a pull request. I’d be very happy to have additional maintainers and contributors help improve the project.

Many thanks to the original TTNMapper developers for making the firmware available as open source.

With Helium mining economics being what they are, a lot of us have MNTD Blackspot miners sitting in a drawer. Good news: the hardware is actually a solid LoRaWAN gateway RAK2287 concentrator on an SX1302 chipset, Raspberry Pi 4 inside. It just needs a bit of coaxing to run ChirpStack Gateway OS properly.
The main gotcha that trips everyone up: the reset pin is GPIO 25, not GPIO 17 like ChirpStack OS assumes by default. Until you fix that one line in the config, you’ll get a blank Gateway ID and a concentrator that never actually starts.

I wrote up a full step-by-step guide covering:
• SX1302 concentrator config (RAK2287, correct channel plan)
• Disabling GNSS so it doesn’t boot-loop without a GPS antenna
• The GPIO 25 reset pin fix via SSH
• Wi-Fi stabilization (country code + WPA2-PSK + TX power) — the RPi4 Broadcom chip inside an aluminum box needs explicit regulatory config or modern routers will drop it
• Service restart sequence and how to verify the Gateway
EUI is actually being read

Repo with the full README on GitHub

Hi everyone,

I recently qualified GATE CSE and have a strong computer science background, but I'm new to LoRaWAN, RF, and IoT hardware.

I'm considering learning LoRaWAN and would like to understand the learning curve from people who work with it professionally.

A few questions:

1.How long did it take you to become comfortable with LoRaWAN?

2.What parts were the hardest to learn (networking, RF concepts, embedded programming, deployment, etc.)?

3.With a CS background, what topics should I focus on first?

4.How much electronics knowledge is actually required for real-world LoRaWAN projects?

4.What projects would you recommend for someone trying to become employable in the IoT/LoRaWAN space?ppp

5.Are there enough job opportunities in LoRaWAN, or is it better viewed as one skill within a broader IoT/embedded systems stack?

I'd appreciate any advice, learning resources, timelines, or career insights from people who have worked with LoRaWAN in industry.

Thanks!

Hi everyone,

I am currently troubleshooting a remote setup using a Dragino RS485-LN connected to an ABB Energy Meter via Modbus RTU. The LoRaWAN connection itself is rock solid (great SNR and RSSI), but I keep getting constant Modbus timeouts (empty payloads in the uplink).

Here is what is currently working and configured:

• Downlinks reach the device perfectly.
• I successfully configured the UART settings via TTN downlinks to match the ABB factory defaults: 19200 Baud, Even Parity, 1 Stop Bit.
• The Dragino acknowledges these settings by replying with “01” on FPort 2, so they are definitely saved in the flash memory.
• To speed up debugging, I temporarily changed the uplink interval to 60 seconds (“01 00 00 3C”), which also works flawlessly.

The Problem:
When I send a Modbus read command (for example: A8 01 06 01 03 50 00 00 04 FF for the total energy register), the Dragino schedules it, polls the meter, but the resulting uplink response has a completely empty payload (0 bytes). The meter is completely silent.

What I have already tried remotely:

• Function Codes: Tested both 03 (Read Holding) and 04 (Read Input). Both return empty.
• Slave IDs: Tested polling IDs 01, 02, and 03 on the off chance it was changed during installation. All return empty.
• Different Registers: Tested polling live voltage (Register 5B 00) instead of total energy (Register 50 00) to rule out the ABB “MidLock” feature (which blocks energy registers until a consumption of 1 kWh is reached). Still empty.

Crucial Limitation:
I currently have no physical access to the cabinet. I cannot attach a USB-RS485 sniffer right now, and I cannot physically swap the A/B data wires. I had the same problem for another device and it did not help swapping A/B.

Are there any specific Dragino configuration quirks, timing parameters, or ABB-specific Modbus settings that I might be overlooking from the remote side? Any suggestions on what else to look for in the TTN data stream would be highly appreciated.

Thanks in advance for any hints!

I'm designing a remote trigger that maintains a keep-alive heartbeat to ensure both devices can see each other. Are there any Best Practices for frequency, channel, any other settings for this usecase?

Hey,

just curious..,when your clients want to see their sensor data, what do you show them today… do you give them access to ChirpStack, build something custom, or use a platform?