I’m porting the Semtech’s stack on a new hardware. My configuration is:
US 915 region
LoRaWAN 1.0.3
Laird RG1xx Gateway
TTN server v3
OTAA
The gateway has channels 8-15 and 65 enabled.
Initially, all channels are enabled on the end-node, after joining, the channel mask is set to FF00 0000 0000 0000 0000. I believe this is done by the network server in the Join Accept packet.
A few confirmed uplinks work perfectly, receiving an ACK for each uplink.
After an arbitrary number of uplinks, a NACK is received and the channel mask is set to enable all channels i.e.: FFFF FFFF FFFF FFFF 00FF
On receiving the next ACK, the channel mask is inverted, it is set to: FF00 FFFF FFFF FFFF 00FF.
Why does this happen?
Any suggestions on where to debug?
As expected, on the next uplink a NACK is received, then the end-node transmits on all channels until it sends on an enabled channel and received ACK again and the cycle continues.
I’d be happy to provide any more information if needed.
First it would be good to note that there’s no such thing as a NACK in LoRaWan, only a falure to receive an ack for any one of a variety of causes both routine and anamolous. Software might treat that as an NACK, but that’s a local assumption.
Next, there’s something of a strategy and recommendation conflict, between Semtech’s official stance that a node trying to join a network should try all possible channels, and the practical reality that a node trying to join a network with a known bandplan like TTN can be far more power and airtime efficient by trying only the channels in the applicable TTN bandplan. Not infrequently you can come across code which was partially modified to change behaviour in the most common path (for example starting with just the TTN channels enabled) but where this modifications miss other less common paths that may still implemnt the original authors’ intent, or possibly be rare case bugs in the base code.
It’s probably going to be more effective to search through the code and identify and understand the operation of each part that can touch the channel map, rather than try to see it change in live debugging.
Eternal logging of verbose debug messages from a test node can be useful, too. I’ve often used a pi to collect the logs, especially where that means being able to watch the experience of a node at a more typical distance from a gateway than one located in the lab would be. Care has to be taken that serial output doesn’t spoil the critical timing between transmit and following receive windows, but with care to how logging fits with the stack it can be done safely.