As a general rule one should not modify the files under mac directory of LoRaMac-node project.
As @adrianmares mentioned it is not recommended to limit the channels usage for the Join procedure. In addition by doing so the end-device is no more LoRaWAN certifiable.
An end-device operating in bands like AU915 and US915 must be able to use all 64+8 channels.
The problem that we encounter is that 64+8 channels gateways are quite expensive and only a few network operators are able to invest and deploy them.
As most people can only afford to buy 8 channels gateways or maybe 16 channels gateways the network operators such TTN decided to select one of the available 8 blocks.
Therefore some compromises must be accepted because of the use of 8 channels gateways.
The biggest compromise that we must accept is that more than one JoinReq attempt maybe necessary before the JoinAccept is transmitted/received.
To speed up the Join procedure the LoRaWAN Regional Parameters specification provides an algorithm description for such task.
LoRaMac-node project implements the recommended algorithm. This means that when an end-device tries to connect to TTN at minimum 2 JoinReq uplinks will be transmitted before the network is able to send the JoinAccept.
Concerning the CFList.
As it can be observed in previous specification excerpt the end-devices must use either DR0 or DR4 to send JoinReq uplinks in order to be LoRaWAN compliant.
This means that the network server should be able to send the CFList within the JoinAccept message. In US915 region the downlink data rates use 500 kHz bandwidth. According to FCC rules there are no restrictions on payload sizes as the dwell-time limitations do not apply.
FCC dwell-time limitation only applies for 125 kHz bandwidth data rates (uplinks).
To solve the original issue what we need to know is why the end-device did not receive the CFList or if received why it did not applied it.
The provided logs do not allow to know if the network has really sent the CFList and if it has sent we don’t know if its contents is correct.
Some debugging steps must be done in order to know the origin of the issue.
With LoRaMac-node if one really needs to limit the number of channels it is best to use the stack provided APIs to perform such changes.
Example on how to limit the channels to the 1st block of 8:
/**
* Main application entry point.
*/
int main( void )
{
...
mibReq.Type = MIB_PUBLIC_NETWORK;
mibReq.Param.EnablePublicNetwork = LORAWAN_PUBLIC_NETWORK;
LoRaMacMibSetRequestConfirm( &mibReq );
mibReq.Type = MIB_ADR;
mibReq.Param.AdrEnable = LORAWAN_ADR_ON;
LoRaMacMibSetRequestConfirm( &mibReq );
#if defined( REGION_EU868 ) || defined( REGION_RU864 ) || defined( REGION_CN779 ) || defined( REGION_EU433 )
LoRaMacTestSetDutyCycleOn( LORAWAN_DUTYCYCLE_ON );
#endif
mibReq.Type = MIB_SYSTEM_MAX_RX_ERROR;
mibReq.Param.SystemMaxRxError = 20;
LoRaMacMibSetRequestConfirm( &mibReq );
#if defined( REGION_AU915 ) || defined( REGION_US915 )
// Enabling 1st block of 8 channels (0-7) + channel 64
uint16_t channelMask[] = { 0x00FF, 0x0000, 0x0000, 0x0000, 0x0001, 0x0000};
mibReq.Type = MIB_CHANNELS_MASK;
mibReq.Param.ChannelsMask = channelMask;
LoRaMacMibSetRequestConfirm( &mibReq );
mibReq.Type = MIB_CHANNELS_DEFAULT_MASK;
mibReq.Param.ChannelsDefaultMask = channelMask;
LoRaMacMibSetRequestConfirm( &mibReq );
#endif
LoRaMacStart( );
mibReq.Type = MIB_NETWORK_ACTIVATION;
status = LoRaMacMibGetRequestConfirm( &mibReq );
...
}
Therefore to enable the 2nd block of 8+1 channels one needs to change
uint16_t channelMask[] = { 0x00FF, 0x0000, 0x0000, 0x0000, 0x0001, 0x0000};
To:
uint16_t channelMask[] = { 0xFF00, 0x0000, 0x0000, 0x0000, 0x0002, 0x0000}; // Enabling 2nd block of 8 channels (8-15) + channel 65
