CFList appended to Helium Join Accept ?

[pdvaneijk]

I am not able to find any documentation on the format of you Join Accept. Are you sending the Channel Frequency list as part of the Join Accept to tell the LoRaWAN device which channels to use ?

I am loosing a large amount of traffic on my LR1110 based tracker and I assume it is because it is trying to use all 64 channels.

[macpie]

Yes, we only support 8 channels, the list is sent on the first uplink after join if I am not mistaken.

[lthiery]

@macpie CFList should be in the JoinAccept in some regions such as EU868. The channel mask solution is only relevant for schemes like US915.

@pdvaneijk what region are you operating in?

[macpie]

Sorry, I was mistaken CF list is sent in join accept (see https://github.com/helium/router/blob/master/src/device/router_device_worker.erl#L1209)

[pdvaneijk]

I am operating in 915Mhz. I have an oyster tracker from Digital matter that has aswesome connectivity to Helium and does not loose a single FNCT when sitting stationary in my backyard. Then I have a Browan LR1110 based tracker that seems to lose >75% of all its uplinks just looking at the frame counts coming into the Helium console.

[pdvaneijk]

I am in Los Gatos CA on a Hill and from where I live in discovery mode my gateway can see almost 200 helium gateways so I now connectivity is not the problem. I should not be losing this many packets.

[pdvaneijk]

The LR1110 is a new Semtech chip that uses an internal 32-bit micro running an embedded modem that manages all things LoRaWAN and it relies on the CFList in the Join Accept. Without it it will try to use more than 8 channels....

[pdvaneijk]

Guys, I don't see a 915Mhz channel list in the link you sent me.....

CFList = case Region of 'EU868' -> %% In this case the CFList is a list of five channel frequencies for the channels %% three to seven whereby each frequency is encoded as a 24 bits unsigned integer %% (three octets). All these channels are usable for DR0 to DR5 125kHz LoRa %% modulation. The list of frequencies is followed by a single CFListType octet %% for a total of 16 octets. The CFListType SHALL be equal to zero (0) to indicate %% that the CFList contains a list of frequencies. %% %% The actual channel frequency in Hz is 100 x frequency whereby values representing %% frequencies below 100 MHz are reserved for future use. mk_cflist_for_freqs([8671000, 8673000, 8675000, 8677000, 8679000]); 'AS923_AS1' -> mk_cflist_for_freqs([9222000, 9224000, 9226000, 9228000, 9230000]); 'AS923_AS2' -> mk_cflist_for_freqs([9236000, 9238000, 9240000, 9242000, 9246000]); _ -> %% Not yet implemented for other regions <<>> end,

[lthiery]

Guys, I don't see a 915Mhz channel list in the link you sent me.....

CFList is not used in US915. The LoRaWAN specification says "it shall be ignored".

What happens instead is that ADR Commands [with the channel mask] are sent as MAC commands in the downlinks which are responses to the uplink frames. It's really quite annoying, since you can lose quite a few uplinks until the MAC command via downlink is registered and the devices's channel mask is updated.

That being said, it seems like even over time, the downlink and the channel mask isn't being registered by your LR1110? Usually after 10-20 frames, the device catches it, adjusts the subband mask, and starts working fine.

[pdvaneijk]

Let me run this by R&D and get back to you

Patrick

From: Louis Thiery @.> Sent: Thursday, May 27, 2021 11:41 AM To: helium/router @.> Cc: Patrick van Eijk @.>; Mention @.> Subject: [SPAM:] Re: [helium/router] CFList appended to Helium Join Accept ? (#322)

Warning - External Email

---

Guys, I don't see a 915Mhz channel list in the link you sent me.....

CFList is not used in US915. The LoRaWAN specification says "it shall be ignored".

What happens instead is that ADR Commands are sent as MAC commands in the downlinks which are responses to the uplink frames. It's really quite annoying, since you can lose quite a few uplinks until the MAC command via downlink is registered and the devices's channel mask is updated.

That being said, it seems like even over time, the downlink and the channel mask isn't being registered by your LR1110? Usually after 10-20 frames, the device catches it, adjusts the subband mask, and starts working fine.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/helium/router/issues/322#issuecomment-849855291, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUHSXOHOJJ53ZV3IQEEYNP3TP2G25ANCNFSM45UYCPTQ.

To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.

[lthiery]

Let me run this by R&D and get back to you

One thing you could suggest is that when there is a successful join on US915, that the first data frame use the same subband. That would be compliant with the specification while also having a practical bias and reducing the amount of uplinks required before catching a downlink with a channel mask.

[pdvaneijk]

Lets see what R&D says. They are the LoRaWAN experts.

One comment though, I have ADR mode turned off because technically you are not supposed to use it on a device that moves around a lot. I will turn it on, force a rejoin and see what happens

[lthiery]

I have ADR mode turned off

Yeah it's a little difficult in the US since the channel mask tends to be really important but its set via an "ADR Command". In this case, I think enabling ADR on the device but disabling it on the LNS ends up being a fair compromise.

[lthiery]

And just to be clear @pdvaneijk , ADR is disabled by default on the Helium LNS, but even when its disabled, we still transmit the channel mask via ADR command. We just don't touch the power output and data rates.

[pdvaneijk]

Well that is a very important piece of info. You should really explicitly state that in the settings field of the label in the console where you can turn ADR on and off.

[JayKickliter]

Lets see what R&D says. They are the LoRaWAN experts.

Thanks. We may very well have a bug. It's been difficult to implement the spec correctly due to the way it varies from region to region.

I have an oyster tracker from Digital matter that has aswesome connectivity to Helium and does not loose a single FNCT when sitting stationary in my backyard. Then I have a Browan LR1110 based tracker that seems to lose >75% of all its uplinks

Do you know which LoRaWAN stack each of them use?

[pdvaneijk]

I just rejoined and saw a DL with 2 MAC commands, one link-adr-req had a channel mask in it. We shall see what happens

[pdvaneijk]

From Semtech R&D: I would NOT agree that the LoRaWAN spec says the “US915 CFList shall be ignored”. There are two formats for the CFList, one with frequencies (for regions such as the EU) and one with channels (such as the US). There is a byte called CFListType that tells which type you are using. Helium’s code seems to only support the frequency-based CFList (CFListType=0x00). As such, sending a frequency list in the US will be ignored because it is the wrong type. However, you can send a properly formatted CFList with the channel plan (a channel mask) and the appropriate CFListType (=0x01) in the US.

So if you guys in the future plan to support "real" ADR, where you start changing SFs and TX power levels, you will have to implement the the above mentioned channel list for NA because you would not want to change TX power and SFs on moving devices.

[pdvaneijk]

@JayKickliter: the Oyster tracker from Digital matter belongs to my stepson Marvin Fussell, I assume it came from a batch from Helium directly. I did not have to enable ADR on that one. The Browan LR1110 based tracker uses our Modem-E software. It is based on the 1.0.3 version of the spec. I do not know whose stack we based it on. I can find out. This tells you more about our Modem-E:

https://lora-developers.semtech.com/uploads/documents/files/Understanding_LoRa_Basics_Modem-E_Sept2_Approvd-Final.pdf

[lthiery]

From Semtech R&D: I would NOT agree that the LoRaWAN spec says the “US915 CFList shall be ignored”. There are two formats for the CFList, one with frequencies (for regions such as the EU) and one with channels (such as the US).

Interesting. I think I must've last investigated this before this 2020 regional spec. It still refers to what my previous understanding was:

For LoRaWAN® 1.0.1, the US902-928 does not support the use of the OPTIONAL CFlist appended to the Join-Accept message. If the CFlist is not empty it is ignored by the end device.

The next sentence though explains how CFList may be used, so that's great. Thanks @pdvaneijk

[pdvaneijk]

In version 1.0.2 (circa 2016) the regional parameters got its own separate document. What was left in the main L2 v1.0.2 specification was a mention of the optional CFList in the Join-accept and reference to the Regional Parameters specification for content. The Regional Specification associated with v1.0.2 L2 spec says that CFList is ignored in the US (circa 2017). The channelized CFList was introduced in the v1.0.3 Regional Parameters (circa 2018). It has stayed in v1.0.4 (circa 2020).

[ogimenez-smtc]

Hi,

As mentioned by Patrick, CFList should be ignored by v1.0.1 and v1.0.2 devices in US915 region and is optional v1.0.3/v1.0.4. I admit that I never used Helium network, but if users are not declaring the LoRaWAN version of their devices during enrollment you might use the CFList by default: it should be ignored by v1.0.1/v1.0.2 devices but will help for v1.0.3+

Patrick device is using a v1.0.3 stack, to help with this 8 vs 64 channels issue the stack transmits the first 8 uplinks in the same block than the accepted joinReq.

[michaeldjeffrey]

Fixed in https://github.com/helium/router/releases/tag/2021.06.24.0