Downside to Chirpstack on RAK7246?

So I am curious, is there a major performance hit with running the Chirpstack server on the 7246? I know that most of the other RAK products allow it, and I see it can be installed on a Pi, but since the developers didn’t, I am curious why.

I would be running a very small network and if would just be nice to not have a laptop involved as the Chirpstack server.

Thank you for joining RAK.
RAK7246 uses rpi zero w, chirpstack cannot be run on rpi zero w.

Well crud, that makes sense. I saw that there is instructions for installing it on a Pi, I didn’t realize not for the Zero W in particular.

OK, back to the laptop :slight_smile:

Move the HAT on to a bigger Pi, then install ChirpStack.

Although the installer does appear to allow you to run ChirpStack on the Pi0 but I haven’t tried it.

I expect with a suitable build and configuration it can be; its earlier version (still known as “LoRaServer”) runs on the tiny little MT7628 chips having a fraction of the memory in the “industrial” gateways). Also Chirpstack’s own pi image explicitly lists the pi zero W as a target: https://www.chirpstack.io/gateway-os/ (and in fact the RAK7246 specifically is listed as a supported target of the sd card image; they refer to it as the 2246 but link to the 7246 product page)

Computation wise, it would have to be a terrible inefficient implementation for the load of handling the amount of traffic a gateway’s radio can actually pull off the air to start to be a problem. And not having the network latency of exchanging information with an external server would likely counterbalance the degree to which the processor in the gateway is more limited than the sort of cloud instance that would traditionally run a server.

That said, there are two major concerns when running any network server on any gateway itself, rather than in the cloud:

  • You can really only have one gateway in the network, since most gateways are connected to the Internet by schemes that don’t have much support for peer-to-peer traffic as would be needed for one gateway to report to a network server physically contained in another

  • If something happens to the gateway or its filesystem (corrupted, failed, struck by lightening, lost, stolen) then unless backed up elsewhere, all of the node session address/key records will also be lost, which means you can’t simply replace the gateway and have things immediately start working again, but need to restore all the session details or wait for the nodes to register new sessions with the new server.

My take is that if the network server is already installed in the box, then it’s perhaps a useful introduction or demo. But really by the time use for any actual purpose is contemplated one should be pointing the gateway(s) at a network server in the cloud - be that any of hosted chirpstack, chirpstack on one’s own cloud instance, TTN, or something else.

Well written and makes sense. After thinking through it all, it is pretty clear that it isn’t worth the effort. I am Still muddling through things and trying to figure out how to make it all work for me and how to not overcomplicate things.

I started with TTN and migrated to Chirp, and I think it is a better solution for what I need. At the end of the day I just want the handful of payload bytes on my laptop, so it seems a little heavier than I need anyway, but it seems to be a popular option.

Remember that LoRaWAN and most network servers including Chirpstack and TTN are in-the-moment solutions.

So you’re going to need something beyond the gateway and network server to collect and archive the data when your laptop isn’t running.

If you do that in the cloud, it’s not a bad place to run the network server, either.

Or you can try the chirpstack gateway gateway OS image… it’s only going to cost you the bandwidth to download it and an SD card, if it doesn’t work you can always go back to a plain gateway image without.

The cloud is great, but for now, I don’t mind keeping everything on my lock network for development. I don’t want to make things more difficult than they need to be, so using something like ChirpStack seems to make sense, but I feel like there isn’t really good documentation out there for how to interface with it locally via some C/Python app.

But wasn’t that what you were arguing against earlier? Or are you just advocating grabbing an SD card and give it a whirl?

The key thing to understand is that you always interact with it via network mechanisms, even if both the network server program and the client are running on the same computer and using the loopback interface, it’s still conceptually a network interaction.

But wasn’t that what you were arguing against earlier?

As I explained before, running the network server on the gateway doesn’t scale to having more than one gateway or recovering from severe damage or loss to the gateway.

But you have to have a network server somewhere. If you’re unwilling to have it in the cloud, then the gateway which is going to stay running makes more sense than your laptop which won’t.

But remember you still need something to collect and save the data, otherwise you’ll only get that which comes in live while you are actually watching.

Use TTN and get a phone with mobile data. That way you don’t have to administer your portable Network & Application server and you get to keep all the data that your devices sends.