Tinkering with Gateway Firmware

Gateways
1

Hi all,

I would like to build a testbed to experiment with some changes to the LoRaWAN (firmware) as part of a research project. I have seen many resources on building a Raspberry PI gateway. I have also came across Dragino LG308 which uses open source Openwrt firmware.

My question is which one would be easier to work with? I expect Linux-based Pi to be easier to recompile a driver and reload than re-flashing Openwrt firmware.

Are these my only options? Are there things I need to know before I start? I would appreciate your thoughts.

Thank you,

2

A pi is generally easier to experiment on, especially as you can edit and compile on the device.

OpenWRT systems typically mean cross building from something else and uploading new code to the device, the advantage is they then end up far, far more robust against unexpected power loss and things that can generally mess up the state of something as complex as raspbian.

Worth noting however that gateway software doesn’t really have any participation in LoRaWAN at all. All a gateway does is send and receive raw LoRa packets. The actual protocol is a contract exclusively between the nodes and the servers; gateways don’t even possess the encryption keys to make sense of what they are passing back and forth. So apart from implementation issues, all of the “interesting” stuff happens in node and server code, not gateway code.

2 Likes
3

Thanks a lot for confirming.

I searched for RPi4 on the forum but it seems not many use it. Are there any particular reasons to get RPi3 and avoid 4?

4

Just that it’s relatively new - RAK ship their Pi based gateways with Pi4’s so they think it’s good to go.

1 Like
5

Rpi3 has lower power consumption than Rpi4. If you plan on running on batteries+solar or similar, power consumption could be something to consider.

1 Like
6

Thanks a lot for the replies. They are very helpful.

7

GW S/w will typically happily run on an RPi 2 (e.g. original Semtech IoT Starter Kit from 2014/15 that also ran embedded NS & Apps inc node parameter graphs/tables & generating Google track/GPS Maps when connected to the net) and can run on RPi0W (have a handful happily doing just that!) and naturally much lower power use than a 3, 3B/+ (as used for original Rak Pilots or the iMST Lite GW) or now RPi4’s.

2 Likes
8

The principle benefit for tinkering type activities with the more power hungry Pi’s is the speed of compilation! Develop on a Pi4, deploy on a Pi0!

2 Likes
9

I’d second that!

1 Like
10

Thanks for the helpful comments.
I tried to search for a RPi compatible concentrator but could not verify if they support to Class B nodes (LoRaWAN v1.1).

Dragino PG1301 looks to be a good module with open-source forwarder and support RPi4.

Any helpful tips?

Thanks again.

11

Class B is primarily a software feature of the network server not of the gateway, so this just repeats the point of my early reply: the gateway isn’t where the interesting things happen.

Additionally, class B is not supported by TTN, which makes this off-topic here.

(There are a few parts of class B that are special cases in the code paths packet forwarder code that runs a gateway, but they’re there in the source inherited from Semtech and so latent capabilities even in many gateways on TTN where they’ve never been commanded by the network to exercise that)

12

That sounds good. I do understand that the role of the gateway is somehow passive, but we are thinking to add some intelligence, at least for research purposes.

Thanks again for the help.