RPi4 with PiSupply HAT (RAK2247) and Gateway OS -> a lot of missing uplinks

Hi dear community,
I recently stared working with LoRa and wanted to start developing with an RPi4 and the HAT by PiSupply which is now equipped with a RAK2247 module.
I played with the Chirpstack Gateway OS images and also with the image supplied by PiSupply for a TTN gateway.
I did a lot of research so far but I really have no idea no why I can’t get my dev system working with Chirpstack.
I tried a full Gateway OS on the RPi and also my favored setup with just the base system and the net server and app server on a different machine (virtual container). Setup went well and everything seemed ok, gateway is online but when I tried to implement my first app with some devices using an RN2483 module troubles started.
I am now running with the TTN image successfully two devices and tested them in about 3km distance and it works, all uplinks are received and monitored in TTN.
Not so if I try the same with Chirpstack. Joining with OTAA works but when the devices send their uplinks there is a 90% drop rate at least. I really have no idea why, maybe someone can give me some hints?
I monitored the Concentratord on the RPi, the packets are not even logged in the log, only from time to time a transmission is received and logged and just some of them result in a process in the app (published MQTT packet and entry in the live view).
TTN works so far but I’d rather implement everything on my own servers so…

Any help appreciated…

˜Alexander

Ok, so no answers yet but I did some more research.
I managed to put up an SD card with the RAK LoRa Gateway from here: https://github.com/RAKWireless/rak_common_for_gateway
using the same hardware the ChirpStack Gateway OS Base uses, the RPi4B with that Pi Supply HAT and the RAK2247 SPI.
Was straighforward except that I had to modify the reset PIN used in that image because this setup relies on a different HAT. But then it worked. I changed the installation after the full script from that repo installed everything including a ChirpStack stack with gateway-bridge, network-server and application-server. I deactivated the last two and modified the gateway-bridge to use my virtual network and application server.
So in the end I have two SD cards one creating a ChirpStack Gateway base on Gateway OS Base and the other with the RAK gateway concentrator both having the same endpoint. I can switch back an forth within a minute.

And then I ran some tests, I added one device to an application, the device runs with an RN2483 module an I control it directly with a termianl app and send the commands.
The module was joined to the app and then I just tested sending uplinks.

The result is what I described in my first post. The ChirpStack gateway gets uplinks but no all!
I send manually an uplink about every 30 seconds with DR5 then ChirpStack gets 2, misses one, get the next, misses the next, gets 5, misses the next… Seems random.
The RAK gateway instead gets every single uplink, also seen on the app server live monitoring and my final endpoint, a Home-Assistant instance connected by MQTT to display the readings.

So? Any ideas? Anyone using the same setup?

~Alexander

Seems I figured it out.
The problem is the default settings o fthe RN2483, in the docs there are default channel parameters given which I expected to be set if the device is factory resetted but this is not the case.
Actualls 8 channels are active and used by the device. But the gateway I set up using Gateway OS respects the settings of the gateway profile which has only channels 0-2 active.
Using the RAK gateway all 8 channels are listening and it does not use the settings by the app server so… And so does the TTN gateway I also tested…

Think this is solved!

Yes, that sounds like your issue. Make sure that the gateway-profile channels and the channels configured in chirpstack-network-server.toml are in sync :slight_smile: Note that if you update the gateway-profile channels (to add the missing channels), that these will be applied in ~ 30 seconds automatically in the ChirpStack Gateway OS / Concentratord :slight_smile:

Thanks for the hints…
But I don’t get the logic behind all this, why can I configure channels in the gateway-profile on the app server and those get set on the gateway like “0, 1, 2” and others are deactivated but the network server has those still active and they get active on a device using OTAA. The device registers using channel 0-2 but then gets told he can use 3-7 too but the app server told the gateway not to listen… I don’t get this…

There are two separate concepts:

  1. The channels to which you configure your devices (which are configured in the chirpstack-network-server.toml configuration file). These channels are sent to the device during OTAA, or afterwards using mac-commands.
  2. The channels to which your gateways are configured.

The channels of 1. and 2. don’t have to be exactly equal! For example, you could configure ChirpStack Network Server to use 16 channels (which are sent to the device during OTAA). Then you could have two gateway profiles, each configured to 8 channels (e.g. 0 - 7 and 8 - 15). This would allow you to have a 16 channel network with for example two 8 channel gateways.

1 Like

Ahhh ok seems a more advanced topic.

Just to be sure not doing something really wrong I just set my channels to „0,1,2,3,4,5,6,7“ and didn‘t put 3-7 to extra channels with explicit frequencies set, is that ok? Because alls the docs tell me to just use „0,1,2“ and enter addtionals chans as extra, but as the settings are fixed in the network server I didn‘t see a point of adding those…

Just another question to the two concepts you described, how do the gateway profiles integrate to that?
Monitoring the logs I recognized that the app server tells the gateway to disable for example channels 3-7 if I have a profile with just 0,1,2. But using OTAA the devices still get the info to use all 8 channels. At least in my tests… I realized the changes from the profile have a little delay when the gateway is started but I thought I waited long enough to join a device but still this device then sent packets on other channels than those active in the profile.
I get your point but I am not sure this is working as intended so.

@Alex9779, did you manage to get this working? I’ve been having a similar issue but can’t seem to find enough information to sort it out.

I think I described it above, the problem was that my app or network server just listened to channels 0,1,2 because of my gateway profile in the app server, my devices though got the info by OTAA to use channels 0-7 so if a device sent uplinks not on 0,1,2 they were not routed…