Beforehand, I was using TTN and I’d been able to uplink messages every 2s and the TTN server would read it fine. Now I am migrating to Loraserver. The gateway and device configurations are the same, except the Network Server Address which the gateway forwards messages to (changed from router.us.thethings.network to my lora server ip).
The gateway is Laird, model Sentrius RG1xx. Firmware Version: Laird Linux gatwick-laird-93.7.2.10
Checking the device debug log I see the device is enqueueing packets and completing them every approximately 2 seconds. However, when I check Loraserver/Lora-app-server/Lora-gateway logs the server is receiving the device messages every 30~40s.
Since my setup works well when I use TTN, I believe there should be something with Loraserver setup that I am missing here.
Ouch, that was a gross violation of the TTN acceptable use policy.
Look at the gateway’s raw traffic page and see if it is seeing anything that might plausibly be your message. The device address is in the unecrypted part of a packet so it’s fairly easy to pull out.
If messages are being received, make sure they are valid - correct MIC, non-rewound frame count, etc.
If message aren’t being received check that you are sending on the frequencies the gateway monitors and haven’t been lead off course by an incorrect channel map downlinked from a misconfigured server. Make sure the radio is really being commanded to transmit and that your LoRa stack isn’t stuck in some odd state waiting for something.
Take a look at this table - it is for 10 bytes payload. It shows some kind of minimum waiting times between uplinks.
Also the device have to open RX2, if there was no response on RX1. RX2 is delayed at 2 seconds after the end of the transmitted uplink.
If you flood the air - you can break messages from other user’s devices!
Do not do that, please!
