We are experiencing a Downlink problem with TTN V3.
When the Gateway (connected to V2) is connected to Home LAN, downlink works as expected however when Gateway is connected with GSM network connection, no downlink reaches the device while Uplink still work.
There is a setting for RX1 Delay (set to 1), RX1 Data Rate Offset (set to 0) and RX2 Data Rate Index (set to 3), may I know how would one go about to configure to get Downlink working with GSM network for V3 please?
I set RX1-delay to 5, connected the Gateway to GSM network, restarted the Gateway and send a few Downlink requests to the device, after a few attempts one of the Downlink manage to reach the device.
I then tried with “Confirmed” Downlink and I can see that after a few tries, it does reach the device, however, it seems like the confirmed Downlink does not “clear” from the Downlink buffer and keep sending even when the device already received it.
Do I need to set the RX1 Data Rate Offset and the RX2 Data Rate Index values to something else other than 0 and 3 ?
I am testing an ESP32 with RFM95 node (ABP), gateway is Laird RG186 and distance between Gateway and test node is about 30 feet.
I am trying to move my devices from V2 to V3 but so far I already lost 3 devices when I perform downlink to update the NwKey, AppKey and DevAddr. The strange things is I can see the DeviceAddr from the Gateway traffic but there is no Live data from the V3 device console. It is like there are duplicate registered device that has hijacked the data …
Now I am worried to move the rest of the deployed devices. That is why I am performing tests with a test device.
Any good suggestion how I can move from V2 to V3 safely?
My Gateway is still on V2, do you have good guide on how to move my Laird Gateway from V2 to V3? Thank you.
I am also considering the TTI, I wondered would that help me to move my devices from V2 to V3?
Also, once my gateway is moved to V3, would I see the Gateways in the JSON request like V2?
I am not sure how to find out the latency from my Gateway. I would like to find out and understand exact what setting I need on TTN V3 to get every Downlink working … could you help? Thank you very much.
Yes TTN is deployed on AWS, and depended on the cluster you are deployed on you need to look at that latency, eu1 is deployed in eu-west-1, cant remember off hand were nam1 and au1 is deployed
Which code? Code dependent…all I’m telling you is the convention ( and remember we are effectively dealing in ratio’s)… not clear what you are looking at or how implemented… but that would be a logical conclusion/assumption if implemented correctly
Edit: ah posts crossed… see additional info now… yes that would be the reported level (referenced to 0dbm). If you search the forum you will also find lots of historic discussions about how nodes and GW’s might be calculating and reporting the values and how they and underlying algorithms used as part of the Semtech device calculations have developed and evolved (Refer to Semtech device specifications & application notes - GIYF!)
Rssi is ref 0dm, snr is a ratio (so just a dB), as above. LoRa can work with signals below the noise floor vs legacy modulation schemes such as fsk where you need a signal a decent amount above the noise floor, so it’s poss to see snr as either a +ve or -ve value depending on local rf environment…
Eventually I managed to upgrade my Gateway to TTN V3.
It still puzzled me why my Downlink requests doesn’t work consistently. Whenever I unplugged and plug back the power to the Gateway, the downlink works, uplink is being sent every 2 mins, however after a few downlinks (~ 6 times), downlink will stop working.
The above behaviour has been puzzling me for nearly a week since before I update my gateway to TTN V3. There were speculation that it is caused by network delays but with the help from @Johan_Scheepers, I can see that the delay was minimum on the cluster I was testing on.
Then there were speculation that the Gateway is very particular about the duty cycle and was asked to try with Uplink interval more than 5 minutes. I tried that and the strange behaviour still exist.
Then there were speculation on the RX1 Data Rate and was asked to test with 1, 2, 3, 4, 5 … etc. Tried that and the strange behaviour still exist!
… when you eliminates all the possible issues, you start to realised it must be something else, the question is “Why did the Downlink starts to work once I restart the Gateway” and “Why did it work for a few times and then it stop” ???
… eventually figured it out! …
There must be some kind of “Buffer” or “Tracking of Duplicate Requests” from the Gateway/TTN and now, if I send a different Downlink payload from the previous one, it works PERFECTLY regardless how many Downlink I sent and regardless of the transmission intervals. I set the RX1 Delay back to “1” now.
A strange one … but hope this help some who has been struggling to migrate to TTN V3
For V3 you should use 5 seconds not one. TTI choose that value after careful consideration.
Your message suggests you are sending a lot of downlink messages. Do you keep the fair access policy in mind? On the public network you are allowed a maximum of 10 downlink messages (including acknowledgments) per 24 hours. And 30 seconds uplink.
i need those two units
… eventually figured it out! …