Closed dragino closed 2 years ago
Enable CF-List and it is fixed.
Glad you were able to solve your problem with that Option. Sorry it was mislabeled as US915 only. We moved the CF-List functionality into a lib didn't update our wording when the lib was updated to support more regions.
EU868 ADR function issue in Helium Platform.
17 bytes Join Accept example: Join accept { "category": "join_accept", "description": "Join accept from AppEUI: A840410000000100 DevEUI: A84041xxxxxxxx", "device_id": "7fc0xxxxxxxxxxxxxxxxxxxxxxxxxad", "device_name": "LHT65N-xxxxxx-TEST", "id": "d0e85497-60bd-437c-bb79-d91ee58eb6de", "inserted_at": "2022-08-31T12:04:45", "organization_id": "9xxxxxxxxxxxxxxxxxxx62f", "reported_at": "1661947485021", "reported_at_naive": "2022-08-31T12:04:45", "router_uuid": "64xxxxxxxxxxxxxxxxxxxxxx7338", "sub_category": "undefined", "updated_at": "2022-08-31T12:04:45", "payload": "IAlOapbeECe/tzqaxRgoy30=", "payload_size": 17, "port": 0 }
33 bytes Join Accept example:
We don’t know in what case Server will send which type of Join Accept. We see both cases happen in the same devices by resetting the device.
The case of 17 bytes Join Accept doesn’t include the CFList (Channel Frequency List) for EU86, If a sensor gets this Join Accept, the sensor will only have the default 3 channels for EU868 and miss the 5 optional frequencies, which is defined by LoRaWAN Server. We can see all uplink packets only cover 3 frequencies (868.1, 868.3, and 868.5MHz)
If a sensor gets a 33 bytes Join Accept, the sensor will get the CFList and work at 8 frequencies.
For the 17 bytes Join Accept case. Server tried to send an LINK_ADR_REQ with channel mask 0xFF (which Means 8 channels). According to LoRaWAN protocol v1.0.2 and v1.0.3. End Device will discard this LINK_ADR_REQ MAC command and send a LinkADRAns, Because the Channel Mask ACK Bit = 0 or End Node DR not match ADR_REQ, Server considers the LinkADRAns fail and keep sending LINK_ADR_REQ.
For the 33-bytes Join Accept, there is no issue for ADR.