Ok, I got a mission here. I found several threads touching this problem but none really hit to the point, and epilogues are too vague to be of real help to the most, so I’m willing to clear up things and reach a stable point. I’ll try to be as more clear and succinct as possible, and I hope in a constructive “debate”.
I have a Kerlink Wirnet Station expected to work by GPRS using SPF. It is configured and surfs as expected.
Ping round-trip is about 400ms. I tried the same with a WiFi/GPRS HUAWEI soap and situation is more or less the same, so the gateway should be not to blame.
As mote I have a Libelium Waspmote P&S! with LoRa, or an Arduino MKRWAN 1300 … you choose, the outcome is the same.
In this example I use the Libelium EU, datarate: “SF = 9, BW = 125 kHz, BitRate = 1760 bps”.
Obviously TTN account with both configured gateways and nodes.
Assume LoRaWAN keys are all correct.
Nodes are flashed with a simple task: joinOTAA and send with confirmed uplink a string of about 20 bytes.
Nodes send the uplink (both JoinRequest or ConfirmedDataUp), network server receives and replies, but nodes cannot receive the downlink (both JoinAccept or UnconfirmedDataDown) in 95% of cases. So they keep retrying till giveup (or occasional success).
So I took the tcpdump of Kerlink and (useful) Gateway Traffic of TTN console to understand what’s going on.
aside: Kerlink tcpdump is possible with tcpdump -xi ppp0 -n -v port 1700.
Confirms don’t reach the nodes because the gateway won’t radio-transmit downlinks complaining a “TOO_EARLY” scheduling in reply with SPF packet TX_ACK.
aside: little explanation: “TOO_EARLY” means that the scheduled time from NS is back in time respect to the internal timer of the gateway, that is “too much in advance”. This fooled me for long, so I put here this hint.
A debug example case follows.
- node sends PUSH_DATA with JoinRequest (EDIT: actually is the gateway that envelops the received bytes in a PUSH_DATA)
- gateway detects at 10:20:12.013977 and forwards to NS with tmst of 702008636
- NS replies PUSH_ACK at 10:20:13.514408, nearly 1.5 seconds later
- node sends another PUSH_DATA at 10:20:18.296313, nearly 5.3 seconds after first JoinRequest
- gateway forwards it with to NS with tmst of 708289364
- NS sends back PULL_RESP with JoinAccept (for first request) at 10:20:18.791382, nearly 5.8 seconds later than the first JoinRequest, and with a scheduled time in tmst of 707008636, the usual 5 seconds after the request.
Gateway’s timer is already at 708289364 (as you can see in the second JoinRequest), so the gateway cannot schedule the downlink for transmission at 707008636, as it is already in the past.
This happens only with GPRS, as Kerlink with Ethernet mode goes OK.
With private ChirpStack I can adjust the RX1Delay (as stated in other threads also) to 5 seconds that is enough to accomplish the handshake successfully.
I tried changing the RX1Delay node-side, but it seems not to help.
So, when facing a situation like this, what do we need to do to get it through using TTN and GPRS?
Most relevant referenced threads: