Hi!
I have been trying to send messages through the RFM9X and the Raspberry Pi 400 to The Things Stack with success, but when the RAK 2245 Pi HAT receives the uplink from the RFM9X, it does not send the downlink “fast” enough to comply with the uplinks it receives, as you can see in the attached image. Could it be configured in a different way, so that the uplinks that reach the RAK are balanced with the downlinks it sends to the end device? Is there any way to increase the TX_POWER of the RAK? I listen to you, thank you very much in advance.
Please talk me through that conclusion.
Have you checked the log of the packet forwarder running in the gateway? What does it tell you?
Based on the RSSI and SNR shown there is absolutely no need for that.
If you can see the time when a message is received in the END DEVICE, in the left photo, you can see how some of the messages arrive at the RAK, where all the packets arrive, but the RAK only sends a few of them from the RAK to the END DEVICE.
What I see is a misbehaving node that is uplinking every 5sec - breaching TTN FUP and possibly DC restrictions? - havent looked at details but if that triggers DL’s that are too frequent (as also seems to be the case - with your node not handling the MAC commands?) the RAK will likely be better behaved and wont send anything if it is then potentially at risk of breaching DC - enforced by the NS - need more data to be sure. If RAK saturates wrt DC then NS may command other GW’s in range to service the node - expand the messages to look at metadat of any other GW’s that are handling the messages…
TTN FUP = MAX 30sec total uplink time per day, MAX 10 DL per day - latter should really be thought of as max 10 per week or even 10 per week if not to have excessive impact on other community users…
Apart from the egregious breach of the TTN Fair Use Policy and the almost certain breach of local laws (blue lights, handcuffs, court appearance, fines etc), the actual problem appears to be the configuration of the device / setup on the console that is set to the very ambitious 1 second on the Rx1 that is being repeatedly sent by the NS and not being acknowledged by the device.
The gateway just does as it’s told, if it doesn’t get the downlink in time to be able to send it or it gets too many requests that means it will breach the local legal requirements, no amount of re-configuration is going to help.
Increasing the power output of the gateway is not going to help - the device is clearly close enough for the power output being used for the downlink.
In the first instance you need to decrease your send rate to acceptable levels and rather than trying to use an Rx1 of 1second, given the extra elements in v3, move to the 5 second default that is now in place.