i believe there is an issue with handling the device address. i am using OTAA to connect an end node to your network server and when i switched to class c i cant send a downlink before i send an uplink. after i send the first uplink form the end node then i can send downlinks whenever and it is received on the end node. i noticed that the scheduled downlinks have the wrong device address assigned and not the latest one after the join request. this address is updated after the first uplink which should not be the case and which explains why i only have this problem with class c and not a since in class a zou always have to do an uplink before the receive windows open. i havent tested class b but i believe it would have the same problem
It’s OUR network server - this isn’t TTI tech support, this is the TTN community forum. We are all in this together.
And there is no way a device can receive a downlink without it having joined the network first - and most devices join & send an uplink in short order thereafter. This is the LoRaWAN spec, nothing to do with TTN/TTI specifically.
But you could change the firmware on your mystery device that you’ve given us no hints about making it really hard to answer so that it does a join and then waits, if its switched to Class C, for a downlink.
Only other issue is that I don’t think TTN supports Class C - you’ll have to pay for a TTI instance to use it.
The device does join the network as class a and then i switch to class c. the end node start listening for downlinks. so this all happens after i join the network. this behavior seems to be in multiple end nodes one of them is the RAK3172 module.
Again i dont think the problem is related to class c but because the device address isnt updated until after an uplink has happend. This can be seen if you join the network with OTAA and then check the end devices address under the network layer in general settings.
also i believe it does support class b and c
also my gateway can also host the network server and using the network server on the gateway i had the expected behaviour
Can you check the LoRaWAN specification? I seem to remember a device should send an uplink when it switches class to inform the NS. So you should have at least one uplink with the correct device address anyway.
i just checked LoRaWAN-1.0.4-Specification-Package and it says that the network server should’nt send a downlink before it receives an uplink in class c (this is in section 6.2.7) so that expalins why i have to do an uplink before. but the weird thing is that the network server does in fact send a downlink its just the wrong address
1 Like
What sketch do you use as a base? Or have you written your own?
As most floating around are on 1.0.3 or older.
my end node is using version 1.0.4 actually this specific join procedure didnt exist in 1.0.3.
Sounds like you should file an issue on github regarding this behavior.
Just to summarise, the bug you’ve found is that if you tell the NS to send a downlink before the device has sent an uplink, the NS does even though it doesn’t hold the correct information. Whereas if the NS didn’t have this issue, you or the NS wouldn’t be able to send a downlink until an uplink had arrived.
So whilst there may be an issue with the NS, is there anything preventing you from sending a downlink after you’ve had the confirming uplink from the device???
The NS need to know where the node is to send the downlink via the correct gateway, that is why you need a uplink first.
If the node have never sent the uplink the NS. The NS will need to send the downlink via all gateways in the world to get it to the node.
Best is you log a issue on github.