search

helium / router

router combines a LoRaWAN Network Server with an API for console, and provides a proxy to the Helium blockchain
Apache License 2.0
69 stars 32 forks source link

Including CFList in LinkAdrReq when it's already in the JoinAccept #687

Closed lthiery closed 2 years ago

lthiery commented 2 years ago

When I have a device that has CFList via JoinAccept enabled (US915), I can see that Router still proceeds with the routine of trying to send LinkAdrReq in response to the Data Frames.

This is redundant as if the device is already sending a Data Frame, you can assume it received the JoinAccept and the included Channel Mask.

macpie commented 2 years ago

Will fix

pvolodin commented 2 years ago

I can see that Router still proceeds with the routine of trying to send LinkAdrReq in response to the Data Frames.

Are you sure there's no need to change the device's DR/TX power? In this case ChMask shall also be present.

Oliv4945 commented 2 years ago

Be careful, as there is no way to provide the device's LoRaWAN specification version to the router, this will be a breaking change:

I have devices using the same profile (with ADR on) that are v1.0.2, v1.0.3 and v1.0.4. The v1.0.3/v1.0.4 parse the CFList and use the correct channel plan, but the v1.0.2 will ignore it (as per specification), for those the subsequent LinkAdrReq is useful.

1.0.2 regional parameters: image

lthiery commented 2 years ago

1.0.2 devices should have a LoRaWAN profile on Console that has CFList disabled in that case? (ie: coordinated out of band)

I guess it's not too bad of a thing to maintain for backwards compatibility, but if we are doing so, perhaps we remove the CFList toggle altogether.