Hi All,
I’m trying to use TTN Stack V3.13.3 installed in my infrastructure. I could install and add my gateway, create an application and a device in that application. But when I try to send SF12(DR0) message from my node, I can see it arriving in my gateway (TTNStack GW Console) but it does not arrive at TTN Application. It does not work with SF11(DR1) too but works with SF10, SF9, SF8 and SF7 (DR2 → DR5).
I even tried to configure dwell time false to up and downlink on yml file with no sucessful.
Could anyone make it work? Or have any experience with this?
is AU915 constrained wrt on air dwell time in the same way as US915 or have you perhaps misconfigured install such as to effect such a limit? With US915 and (IIRC) a 400ms dwell time limit LoRaWAN Is essentially unusable beyond SF10 and even at SF10 message length is constrained compared to other territories - (again IIRC) a limit around 10/12 byte payloads.
How big is your payload and is system configured correctly or constrained by regulation? In reality it would be the transmitter that is constrained (the node in this case) but you say you see message arrive at GW - it may then be the backend rejecting as “illegal” message.
Another option might be if signal marginal or at limits of channel frequency/poorly set up/matched then message integrity checks might be failing on longer messages which would cause GW to possiby not pass received message on due to MIC fails!
WIthout going to check I dont have direct answers but just flagging options - also is AU915SB1 the usual recommended plan (with GW & Node freq/channel options all correctly set up & matched?)
Late here, a bit tired and just thinking aloud wrt possibilities!
/ off!
The other common thing to look at is all appropriate keys (DEV EUI, APP EUI etc.) entered correctly - if message at GW but not at application one of the most common problems is mis-match between how App is set up and actual keys used…though fact you suggest working ok for DR2-> DR5) suggests that isnt problem here…make sure node & GW have sufficient seperation to ensure no overload at margins of longer messages…
What is the LoRaWAN version and Regional Parameters version of the end device ? For the record, the standard changed the meaning for DR0 between versions 1.0.1 and 1.0.2
We have made transmission requests aware of the regional parameters version in 3.14, so I’d recommend checking it out if you can, and see if it fixes your issue.
Hi @adrianmares, it was in 1.0.2. Now I’ve changed to 1.0.3 and I can receive the package, but now I have another problem.
If I get a new device, with lora counter low, it works perfecttly.
But if I create a new device at my platform and get an old physical device already transmitting for a long time (counter high +/- 18000), I can see messages at my gateway but it does not forward to application.
AU915 does not have dwell time limitations but I did a test to confirm.
At the end of the day, it was the LoRaWAN version and Regional Parameters version. Now it works perfect with new devices as I’ve explained in my previous post to Adrian.
Regardas
For new nodes the packet should be 0-16384. Anything else will be rejected by the stack as invalid. For running nodes the counter should be max 16384 above the last processed packet counter to be accepted.
Note: this does not apply to LoRaWAN version 1.0.4 and above.
That’s not correct. I’m glad you are working but AU915 devices definitely have a DR2 starting point that they aren’t able to go below until ‘TxParamSetupReq’ is sent by TTS (or the local stack implementation isn’t fully compliant, not uncommon for this subtle point). You said earlier you’d configured no dwell, which would also do it.
is AU915 constrained wrt on air dwell time in the same way as US915 or have you perhaps misconfigured install such as to effect such a limit? With US915 and (IIRC) a 400ms dwell time limit LoRaWAN Is essentially unusable beyond SF10 and even at SF10 message length is constrained compared to other territories - (again IIRC) a limit around 10/12 byte payloads.
