You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yikes. Looks like a big hole in the compliance tests (and in my testing, sigh; but at least I've found it now).
Not only does the function processJoinAccept() not cater for US-style CFLists, but it hard-codes that all CFLists are EU style.
Result: in US and AU regions, the CFList (channel mask) is ignored. So if the LMIC is not configured for the network using LMIC_selectSubBand(), it will generally use the wrong channels for uplinks.
Solution is to add bandplan-specific CFList processing routines, and change processJoinAccept to call the bandplan handler instead of doing it itself.
Even with this fixed, users should be aware that TTN V2 does not send a CFList with JoinAccept in the US. Devices will function -- once the first regular uplink message hits subband 1, the network will download a proper netmask -- but it will take quite a while after the join. I observed delays of about 8 uplinks. You will have to check your network manual to confirm whether JoinAccept sends a CFList, and also confirm whether it tries to send the network mask as a reply to subsequent Class A uplinks. I have not yet checked TTN V3 behavior.
The text was updated successfully, but these errors were encountered:
terrillmoore
changed the title
US-like regions don't process JoinAccept CFList
US-like regions don't process JoinAccept CFList so don't adjust channel mask to match network
May 30, 2021
Yikes. Looks like a big hole in the compliance tests (and in my testing, sigh; but at least I've found it now).
Not only does the function
processJoinAccept()
not cater for US-style CFLists, but it hard-codes that all CFLists are EU style.Result: in US and AU regions, the CFList (channel mask) is ignored. So if the LMIC is not configured for the network using LMIC_selectSubBand(), it will generally use the wrong channels for uplinks.
Solution is to add bandplan-specific CFList processing routines, and change processJoinAccept to call the bandplan handler instead of doing it itself.
Even with this fixed, users should be aware that TTN V2 does not send a CFList with JoinAccept in the US. Devices will function -- once the first regular uplink message hits subband 1, the network will download a proper netmask -- but it will take quite a while after the join. I observed delays of about 8 uplinks. You will have to check your network manual to confirm whether JoinAccept sends a CFList, and also confirm whether it tries to send the network mask as a reply to subsequent Class A uplinks. I have not yet checked TTN V3 behavior.
The text was updated successfully, but these errors were encountered: