Chirp Stack Gateway Rock Pi 4B+ + Nebra LoRa HAT (GL5712-UX / SX1301+SX1302) working on Armbian Trixie — setup script + full writeup

datastream · May 23, 2026, 9:51am

After several weeks of debugging I have a fully working ChirpStack v4 gateway running on a Rock Pi 4B+ with a Nebra Indoor LoRa HAT. I’ve written it up and published a setup script because there was almost nothing documented for this exact hardware combination.

The two problems that took the most time:

The Armbian SPI overlay system silently ignores overlays on current Trixie builds for the Rock Pi 4B+. The script uses the rk3399-spi-spidev overlay which actually works, and falls back to direct DTB editing if needed.
The GL5712-UX concentrator module (found in older Nebra HATs) has a hardware inverter on the NRESET line. HIGH = chip in reset, LOW = chip running. This is the opposite of the standard SX1301 reference design. If anything holds NRESET HIGH — including a GPIO daemon — the chip never comes out of reset and SPI returns 0x00 for everything. The fix is to let chirpstack-concentrator own NRESET exclusively via sx1301_reset_chip/sx1301_reset_pin in the TOML, and only hold POWER_EN in the systemd service.

The repo covers both GL5712-UX (SX1301) and RAK2287 (SX1302) modules with auto-detection.

GitHub: GitHub - mowaxuk/chirpstack-nebra-rockpi-Mowax: chirpstack-nebra-rockpi-made by Mowax · GitHub

Hope this saves someone else the same pain. Happy to answer questions.

Jeff-UK · May 23, 2026, 2:39pm

How soon will you be repurposing the firmware and targeting TTN deployment? Can’t tell exactly from picture but guess you are not far from either the TTN-Newcastle or TTN-Tyne Valley, Consett or even Durham Communities who would always welcome another Gateway! If not deploying to TTN are you peering with TTN? (PacketBroker)

Whilst this Forum is for LoRaWAN in general it is focussed on TTI/TTN and is paid for by TTI so whilst your story is welcome and good for others to follow we always look for the right tie-in and relationship to TTI/TTN.

datastream · May 23, 2026, 2:57pm

Great shout, and yes, I’m in Gateshead, so TTN-Newcastle is exactly my local community, good spot!
The build was quite a journey getting here, the SX1301 concentrator gave me a serious fight before it finally came good, but the gateway is fully working now.

ChirpStack v4 supports PacketBroker peering natively which would allow my existing private gateway to also share coverage with TTN without any extra hardware, I’m going to look into getting that configured. Rather than just running everything privately it would be great to give something back to the community and get some Gateshead coverage on the map, I don’t think there’s much around here so it could be a useful addition.

Give me a bit of time to get it set up properly and I’ll report back with how it goes. Looking forward to being part of the local community!

Jeff-UK · May 23, 2026, 4:09pm

Have done some mapping in the general area and always disappointed that visits to Gibside yield no coverage despite having 3-6 trackers with me each visit! Another GW in the Gateshead area would be welcome - even if just peering - higher up around Whickham to Greenside area and into the hills helping to get coverage into the Tyne Valley…..

General coverage per TTNMapper:

Where might you fit? Will test on next trip up later in summer!

datastream · May 31, 2026, 4:47pm

Update — TTN Peering progress (almost there)

Private ChirpStack v4 is fully working. Now trying to peer with TTN and hitting a wall I could use some help with.

Setup:

chirpstack-mqtt-forwarder second instance pointing at eu1.cloud.thethings.network:8883
Gateway registered: mowax-gateshead-01 (EUI 7243C4FEFEDF60B9)
API key: lns-key-3 with RIGHT_GATEWAY_LINK scope
TLS connects cleanly every time
Concentrator backend connects and reports correct gateway EUI

The problem: After a lot of repeated MQTT connection attempts during debugging (working through CONNACK 5 auth issues, trying different key scopes etc), I’m now getting “Connection closed by peer abruptly” on every attempt — TLS handshake succeeds but the connection is dropped immediately before any MQTT exchange.

This feels like a rate-limit or temporary block on my end from TTN’s side rather than a config issue — all the credentials and config are confirmed correct.

Questions:

Has anyone seen TTN rate-limit a connection after repeated failed attempts? How long does it typically take to clear?
Is there anything on the TTN console side I can do to reset it?
Any other explanation for “Connection closed by peer” after TLS succeeds but before MQTT completes?

Here’s the TTN Mapper coverage for the area — I’ve circled roughly where I am. Sitting at 118m ASL so I get good coverage to the north and east toward Gateshead/Newcastle. The Silver Hills to the west will limit me in that direction but I can literally see Blaydon from my window so I’m hopeful for some of that Tyne Valley gap Jeff mentioned. Once TTN peering is sorted and the Heltec mapper arrives I’ll do a proper drive/walk survey and post results.

Happy to share full journal output if useful.

stevencellist · May 31, 2026, 9:36pm

Hold up.. those hexagons look a little familiar. How did my mapping website pop up here?

Registering your gateway as a TTN gateway is not the right way. Since it then looks like a normal gateway, TTN will attempt to schedule downlinks through your gateway if it appears to be the optimal one. But either your setup will not accept/schedule downlinks, or you will eventually run into collisions between Chirpstack and TTN.
Chirpstack offers Multiplexer which suffers from the same problem. You can mark a server as uplink only but then it will simply discard downlinks or also suffer from scheduling conflicts.

The official way is to use Packetbroker. You can check out Packetbroker documentation here: Quick Start | Packet Broker Documentation

descartes · May 31, 2026, 9:38pm

Ask @Jeff-UK, his boundaries know no limits.

Jeff-UK · May 31, 2026, 10:07pm

Post a little higher up - both the Kroonos (so only my trackers at this time) and the wider TTNMapper coverage - most Kroonos points dont appear on main Mapper site (I have to look at individual device heatmaps) but TTNMapper includes historic data from wider local communities as well as my other GPS enabled devices that dont feed into Kroonos (Dragino, iMST/SMTC LoRaMOTE’s, RAK5205’s,811’s etc…..)

@datastream as Steven re-enforces; per my initial post and as you noted, Peering and specifically using PacketBroker is the way forward in this situation if you dont want to put a TTN directly supporting firmware build on the GW. You can’t have 2 LNS fighting to control 1 GW - not least as neither knows what duty cycle has been consumed by the other and in our part of the world you risk not only compromised performance for both networks you also risk

….Hi Nick, am currently pushing those boundaries around Geneva/Montreux/Lac Leman and south east side of French Jura once again!

datastream · May 31, 2026, 10:22pm

The duty cycle point is well made and honestly hadn’t fully clicked until you spelled it out. Two LNS with no shared duty cycle accounting on the same gateway is a recipe for both a broken network and a letter.

Good news — already actioned. Emailed join@packetbroker.net this evening so the request is in the queue. Will update the thread once I’m through the approval process and have passive roaming working properly.

@stevencellist — didn’t expect the dev himself to drop in, thanks for the steer!

Heltec mapper arriving, will do a proper survey run and post results here.

datastream · June 1, 2026, 9:15pm

Quick update and a change of plan after some great advice in this thread.

I’ve switched approach entirely, I’ve decided to go a step further. I have a spare Rock Pi 4B+ with a Nebra HAT sitting unused, so the plan is now:

Box 1 (current Rock Pi): Private ChirpStack v4 for my own IoT devices, indoor antenna, completely separate from TTN.

Box 2 (spare Rock Pi): Dedicated native TTN community gateway, proper outdoor antenna on the roof with a cable run. No ChirpStack involved, pure TTN. At 118m ASL I’m hoping to make a decent dent in that Tyne Valley gap you mentioned Jeff.

One question while I’m here, can anyone explain why ChirpStack’s MQTT forwarder couldn’t authenticate to TTN’s LNS properly? TLS handshake succeeded every time, credentials confirmed correct, but kept hitting CONNACK 5 and then eventually “connection closed by peer” after repeated attempts. Thinking the latter was a rate-limit from hammering the endpoint during debugging rather than a fundamental incompatibility.

descartes · June 1, 2026, 9:50pm

We can surmise but the details are more in the hands of TTI devs.

I suspect more a fundamental “that’s not what the MQTT is for”. And you haven’t said where you set that up in the console but as there are no options in the Gateways section for MQTT, this is an informed wild stab in the intuitive guess:

TTS supports gateways via the old style UDP Packet Forwarder and Basic Station. AFAIK, there is the old KickStarter gateway that uses MQTT but they are special to TTS.

The MQTT broker that runs on TTS is only used to send out device data and receive downlink requests. That’s all it is configured / authorised / allowed to do. Some hopefuls have tried to use it as a general purpose broker and totally failed. I suspect you are the first to try using it for gateway but as it’s setup in Applications, there was some signalling about how that may not work out.

You were probably disconnected as you won’t have subscribed to any of the topics for an application. But as I said above, only the TTI devs can really confirm.

Most important thing is that you’ve got the gateways setup.

And if you wanted to, you could get another one and run TTS OS - or ditch the pesky CS and use the TTS goodness.

datastream · June 1, 2026, 10:50pm

Thanks for the detailed response, that clears up a lot. You’re right that I wasn’t explicit enough about how I’d set it up, so let me explain properly.

What I’m running
The current setup is a Rock Pi 4B+ with a Nebra Indoor LoRa HAT (RAK2287 module, SX1302 concentrator), running Armbian Trixie on kernel 6.18, EU868. The software stack is ChirpStack v4 feeding into chirpstack-mqtt-forwarder. The private network is fully working and serving my own sensors.

TTN — current state
The gateway is already registered in TTN console as mowax-gateshead-01 (EUI: 7243C4FFFEDF60B9). I’m not using the application MQTT or trying to push gateway packets through that, I take your point about why that wouldn’t work.

The connection isn’t live yet, repeated failed attempts during debugging triggered a rate-limit (I think) on my WAN IP, so I’m waiting for that to clear before bringing the service up. Config and credentials are confirmed correct at this point.

Dedicated TTN gateway — coming in the next couple of days

Rather than sharing resources with the private ChirpStack machine, I’m building a dedicated second Rock Pi 4B+ with its own Nebra HAT running the full stack independently, its own concentrator, its own mqtt-forwarder pointed at TTN. That way the private ChirpStack machine and the TTN gateway are completely separate with no shared components.

That machine is being built over the next couple of days, with a 10 metre LMR400 feed to a 6 dBi 868 MHz antenna on the roof at approximately 118 metres above sea level in Gateshead. That should give reasonable coverage across the Team Valley, Low Fell and Gateshead, and potentially into parts of Newcastle depending on line of sight.

I’ll be mapping coverage with a Heltec V4 ESP32-S3 LoRa running TTN Mapper firmware once it arrives.

I appreciate the suggestion, but given I have sensors already provisioned on the private ChirpStack instance I’d rather keep that intact. The dedicated TTN machine keeps everything clean and separate.

Any thoughts?

descartes · June 2, 2026, 8:22am

I was only referring to how you’d got the MQTT credentials.

So where DID you get some MQTT credentials from?

Huh? Please re-read my explanation. You can’t push any data to the MQTT broker other than downlinks, so any disconnect is because the connection is dormant having not subscribed.

There are no credentials for a PacketForwarder and rather a lot for BasicStation which work on different ports to MQTT so should just work. So it’s not clear what you have going here.

IF you get the V4 working, do let us know how - you can ask about it on the Heltec forum - someone has just opened a thread on that very topic. The LNA & PA switching are currently a dark art as those that can haven’t got hold of one to investigate yet and Heltec haven’t released firmware for their own board(s) that work.

The better choice would be a Heltec Tracker v1 - integrated GNSS module. The v2 is like the LoRa v4, interesting but borked.

Jeff-UK · June 2, 2026, 8:50am

Per Nick, unlikely (wont!) to work - you need GW firmware build running either the now legacy SMTC UDP PF (easiest as ‘just works!', with minimal config no Auth) or BasicStation (more complex set up using Auth Key etc.), or look to the Kersing MPPF - only the TTKGW (The Things KickStarter GW) supported/supported MQTT GW connection on TTS/TTN.

You don’t (need to) run TTNMapper specific firmware on the tracker node - just get it working as a ‘normal’ device - may not be straight forward per Nick - feeding (broadcasting) GPS data to TTN connected gateways/network…….you then use the TTN Webhook in the Application you set up to feed your device data to TTNMapper.org from the TTN/TTS LNS and Application Server.

Use the min Ant gain needed to just compensate for any feed/connector losses - the higher the gain the more directional the RF beam with increased risk of nulls depending on pattern properties - best stick with more uniform 2.1/3dbi ant’s where possible (may mean keep feed shorter where you can). Unlike say Helium there are no points or prizes for getting GW’s to Xmit to other distant GW’s - we are only interested in uniform and consistent device coverage in surrounding areas.

Good - but please still look to get the CS unit peering with TTN through PacketBroker - then we get 2 lot of coverage & capacity for the price of one!

descartes · June 2, 2026, 2:30pm

But get @Jeff-UK to buy the Net Id from the LA for you!

Jeff-UK · June 2, 2026, 3:55pm

Still sounds like Nick might be ready to offer the interest free permanent loan to help cover the cost?! Guess am too used to seeing people talking of peering private TTS instances vs. CS….

datastream · June 6, 2026, 4:29pm

The dedicated TTN community gateway is now live in Gateshead.

After a fair bit of pain getting there, mowax-gateshead-01 is online and covering the Gateshead/Newcastle area on EU868. Running Basic Station on a Rock Pi 4B+ with a Nebra Indoor LoRa HAT with a 6dBi outdoor antenna mounted on the roof — the whole point is reach, pulling in devices as far across Gateshead and Newcastle as possible for coverage mapping.

The module fitted in the Nebra HAT SX1301 It has a hardware inverter on the NRESET line which means the polarity is opposite to every other module. That alone cost a couple of days.

One side effect of the roof-mounted 6dBi, if you’re sitting directly below the antenna you’re in the null zone and SNR drops significantly. At distance and angle is where the gain antenna earns its keep, which is exactly what coverage mapping needs.

Full writeup, working Docker config, GPIO notes, and a post-mortem of the TTN DevNonce floor problem are all in the repo:

https://github.com/mowaxuk/ttn-nebra-rockpi-mowax

Coverage mapping runs incoming with a Heltec V3, will post results once I’ve been out with it.