Hi,
I am trying to understand the incoming data in my V3 console:
1: Recieve window 5 sec?
2: Scan for one of the 8 free channels?
3: Kind of confirmation?
4: What is this … Why so many downlink bytes?
Can anyone explain this in more detail?
These questions have been answered in other topics so you might want to read them as well.
TTN V3 uses RX1 time-out of 5 seconds, the stack force feeds a MAC commands to every node to make sure this setting is known.
The backend does not know your node already knows the channels used by TTN in Europe (the known channels are defined by choosing the right channel plan and additional preprogrammed channels are defined in advanced settings), as a result the stack tries to instruct the node to add the additional channels to its settings.
And the device status request is not a confirmation, it is a request from the backend to the node to get the node status.
All these settings add up to a significant sized downlink packet. And given the name of your node I assume you aren’t running a full size LoRaWAN stack so it might not handle the downlink with MAC commands correctly. As a result of the backend not getting confirmation off correct handling of the settings it will repeat this sequence for every uplink.
TTN V3 requires fully LoRaWAN compliant devices at the moment.
(See other forum topics for a discussion on that subject, we are not going to repeat it in this topic)