Hi!
I’m making final adjustments to our instance for a production launch.
So far I have an AU915 configuration with this channels enabled: [0, 1, 2, 3, 4, 5, 6, 7, 64]
DataRates on service profile are between DR_0 and DR_5 (according to 1.0.3 spec)
The Gateway Profile also has the same channels enabled.
Our LoraMac base nodes are working almost perfect (RN2903A behaves very weirdly), but the only thing that seems odd is the received ChannelMask in the end device after Join.
ChannelMask is FFFF FFFF FFFF FFFF 00FF and it should be 00FF 0000 0000 0000 0001
Having this issue, the first uplink HAS te be confirmed in order to make the GW hear the first packet… then the ChannelMask gets updated and the end device works like expected.
Is there something I’m missing? Maybe I miss the channel configs or the loraserver config.
Thanks in advance!
Are you sure that isn’t pre-existing static configuration of the node, or its firmware misinterpreting something?
Can you capture and share the content of the join accept’s CFlist if one is present?
The same device in other NS works fine. I’ve tried OrbiWise with a local supplier (I don’t have access to NS logs to see the frames)
Here is a JoinAccept donwlink:
It’s always the same behaviour, I send a confirmed message that takes several tries (2-20) and then, the channel mask gets updated and all the uplinks arrive perfectly with no package loss at all.
It’s not a huge problem but it’s a production server an it scares me a little 
The JoinAccept doesn’t seems to have a CFList, the device profile is 1.0.2A.
Thanks in advance!
Do you have the following in your loraserver.toml configuration (in the [network_server.network_settings] section):
enabled_uplink_channels=[0, 1, 2, 3, 4, 5, 6, 7, 64]
(see: Configuration - ChirpStack open-source LoRaWAN<sup>®</sup> Network Server)
The JoinAccept doesn’t seems to have a CFList, the device profile is 1.0.2A.
That is expected, the CFList channel-mask was added in 1.0.3.
Sounds like your node is actually following the part of the LoRaWAN spec that says it should fairly try all the possible channels, and not just the subset you know your gateway(s) to support. Once you do actually get an ADR message through you get an updated channel configuration that way.
Personally, I’d change the code of the node to force it to only try channels you know you support, in particular I’d look for and disable anything in the path that handles receipt of the join accept which might re-enable all channels in the absence of a CFList, overriding any initial configuration in your program.
Presumably, you are not trying to make something that works on any network, but rather something that works well on yours.
1 Like
Thanks.
I obviously need to read the specs more carefully
I’m going to try 1.0.3 in my end device but the initial confirmed message does the job.
