I was trying to connect my RAK7268 gateway to the things stack using the UDP packet forwarder mode (as the basics station mode is not yet supported for 7268). I am using a Microchip WLR089 module for my end device and have it set up to push uplink messages on a keyboard event.
I successfully set the device up and got it to join the network and send data to it. I can see this data on both the Lora packet logger on the RAK and the things stack console. However, my problem is that around 75% of my uplink messages don’t even reach the gateway in UDP mode.
When I tried changing the mode to network server mode (using the built-in network server running on the RAK gateway) I can see that 100% of my uplink messages are correctly received without missing a single frame.
This is a mixture of elements - but I believe you are saying that when your gateway is connected to TTN using the packet forwarder only a quarter of the uplinks sent from your WLR089 arrive - although it’s not clear if you mean they don’t get to the gateway or if they don’t get to the web console.
How is the WLR setup - ABP or OTAA?
Which LoRaWAN version & regional parameters on TTN are you using?
Are you using TTN v2 or TTS CE (TTN v3)?
How often are you sending?
The uplinks form the WLR don’t make it to the gateway itself, I don’t see them in the lora packet logger. The frame counters jumps a few values.
WLR is on OTAA
Lorawan 1.0.3 and regional 1.0.3A
I am using TTN V3 (the things stack cloud edition)
I am sending a 5 byte payload (airtime 46ms) every 15 seconds, so I think well within 1% duty cycle. But the uplinks miss even if I send every couple minutes or so.
I do not have an SDR. But what I did to confirm my uplinks are actually being transmitted by the WLR is, I switched the gateway to use the built-in network server mode from packet forwarder mode. When I did this my gateway received every single uplink that my WLR sent. I used the Lora packet logger to view this.
Ah! I see I keep getting DevNonce too small errors when I try to use MAC v1.0.4 with Regional PHY 1.0.2B. So could not join the network to test if data was being received correctly.
This deployment of the things stack is their new free tier option which is exactly the same as the things stack cloud (hosted and managed by the things industries) except it has device, gateway and user caps to remain within the free tier.
EDIT: I just deleted and recreated the device on the things stack to reset the devNonce. I could join the network now. Received first two uplinks and missed the third. So still missing with v1.0.4
Not really a definitive test as you’d need to be sure the exact same MAC commands are being issued by Chirpstack (the version of which isn’t very v1.0.4 aware) to compare them.
It may well be that the configuration coming down from TTS precludes the ability to send so many messages in such a short space of time.
This will get old very very quickly ever time you try to do a test. I’d recommend using ABP whilst developing and use the CLI to reset the DevNonce if you switch to OTAA.
Was this at one packet every 15 seconds? The TTI official view is that 10% packet loss is the norm, so you may want to leave it running for a few hundred packets to get a larger test set of data.
And then, as whilst 15 seconds may be legal, it is a rather unusual configuration that may well be caught up with the back end processing that isn’t obvious. Perhaps set it to 1 minute for an hour to see what happens.
I was setting up Chirpstack on GCP the past couple of days. Finally got it working. Gateway using UDP packet forwarder, Chirpstack gateway bridge running on gcp. None of my uplinks/downlinks were dropped with Chirpstack. So I guess I have somehow configured the things stack incorrectly.
