In contrast to EU868. AU915 and US9* have more channels than typical gateways are supporting, this is solved by the network selecting a group of channels, the semtech-loramac uses a channel mask to implement this.
Is there a way to set the channel-mask from RIOT or do i need to uses the semtech interface directly?
This parameter is not wrapped in the contrib RIOT API but you can use LoRaMacMibSetRequestConfirm to set a channel mask (or default channel mask). Similar to what is done with the RIOT semtech-loramac_get/set functions (see here).
The corresponding constants in loramac-node are MIB_CHANNELS_DEFAULT_MASK and MIB_CHANNELS_MASK. See also ChanMaskSetParams_t for a description of the param struct.
I agree that it would be nice to extend the RIOT support with this configuration.
Thank you,
this was the right direction. But while testing i found there are some regulatory changes in AU915, that made the channel mask not work. I will provide a backport (may also include the US915 changes, untested) as soon as i finish that work.
May be the semtech-lorawan pkg is due for a update from upstream. Upstream has a lot of changes especial to the next release ((improved) class B support timing …) (Riot is at upstream 4.4.1 (2018-03) current is 4.4.5 going for 5)
Updating the package is indeed required and must be done one day. Not only it contains new LoRaWAN class B support but there is also multicast support and new radio drivers, among other things. If possible I also think that RIOT should use the radio driver code provided in the package when using LoRaWAN from loramac-node instead of the RIOT ones. As you can see, only the sx127x drivers are available in RIOT but the package provides support for sx126x and lr110. Last improvement I see is to rename the package from semtech-loramac to loramac-node, but this would be a complete API change…
I see U got a plan.
Maybe we should make the plan a feature request, if some one wants to hunt issues/features for lorawan. It is a little bit difficult for me since the hardware i use i owned by another project. (where i did the initial implementation)
I think for this cases it might also make sense to directly use the pkg API instead of wrapping all functions. This is what I started to do in https://github.com/RIOT-OS/RIOT/pull/15664. It’s required to migrate the msg based loop to Event Queues, but it shouldn’t be a hard task (and it’s actually way more efficient).