US915 Join Frequency Pattern Randomisation

[Carl-P4]

Using Tag V4.4.4 Via ST Supplied LRWAN_V2.0.0 package,
We have noticed that the first join at power-up of the device is always in the same band, the first 8 channels of the first band.

How do you direct the first join to a randomised band, so that a number of the same devices powered up at the same time don't attempt to use the same band.

Re-joins after the first join appear to be randomised and occur using different channels it seems, which is what is needed.

Also we are using ADR, should the application manually vary the Datarate the join is requested at, again to reduce air time if we are close the gateway.

.. EDIT ..
After further investigation I thought LmHandlerJoin needed to be called again if a join fails. But debug logging has shown the stack will automatically cycle through different frequencies attempting to join.

Testing on a single unit shows the sequence of frequencies it tries to always be the same order. Tested version V4.4.7. US915

0s069:TX on freq 902500000 Hz at DR 0
10s126:TX on freq 905300000 Hz at DR 0
20s126:TX on freq 905500000 Hz at DR 0
30s126:TX on freq 908100000 Hz at DR 0
40s126:TX on freq 909700000 Hz at DR 0
50s126:TX on freq 910900000 Hz at DR 0
60s126:TX on freq 912500000 Hz at DR 0
70s126:TX on freq 913700000 Hz at DR 0

How can I force these join attempts to be more random so that if multiple units are powered up their join sequences are all different.

It looks like Nvm.RegionGroup1.JoinTrialsCounter increments for each failed attempt. But I dont see an interface to adjust it.

What is the suggested method for randomising this process and if I want to adjust the join attempt rate, how is this done?

Thanks,

[mluis1]

We don't know which changes ST has made on their fork of this project.

By default this project uses all 64+1 channels. The join frequencies selection follows the recommendation provided by the Regional Parameters specification

The channels frequency selection order should be always random as the MAC layer uses a random number generated by the Radio hardware to seed the pseudo random generator. This means that every time LoRaMacInitialization API is called a different pseudo random sequence will be used.

LoRaMac-node/src/mac/LoRaMac.c

Lines 3835 to 3836 in 05353ff

	// Random seed initialization
	srand1( Radio.Random( ) );

Therefore, the only possibility to always get the same sequence across end-devices would be if the Radio always return the same random number.
The only possibility for the radio to return the same random number can only happen if the Rx RF path is saturated by an high power RF signal close to the end-device (almost unlikely to happen).

[mluis1]

On my side it is also working if I enable EU868 and US915 region. I have also tried using EU868 and US915 as active regions.

Do you have the possibility to try with another hardware?
Just in case your current hardware is malfunctioning for some reason.

[Carl-P4]

Ahh I think I've seen a difference. When I moved to the latest ST build for the tests, I didn't change TCXO Enable pin assignment, which would cause the radio not to function and then not provide a RSSI for the seed.

[mluis1]

Indeed that could be the reason for the observed issue.

[Carl-P4]

Another thing I've noticed is the RegionBaseUSComputeNext125kHzJoinChannel chooses a band to try based upon groupsCurrentIndex which is supplied from the NVM structure (RegionNvmGroup1->JoinChannelGroupsCurrentIndex). If you are not using NVM this always starts at zero putting the first attempt in the first band? Is having the app randomise this value on boot helpful.

[mluis1]

Changing the way RegionNvmGroup1->JoinChannelGroupsCurrentIndex is initialized will not bring any improvement as the randomly selected sub-band will not necessarily be the one you are expecting and the JoinRequests may cycle anyway up until you reach the right sub-band.

The US915 and similar regions are expected to run under 64 channels gateways and everything would work smoothly. However, a lot of LoRaWAN networks are only deploying 8 channels gateways. Doing so, introduces drawbacks and everyone must accept the compromises that come with it. The compromise is that one needs to accept that it may take several trials up until we reach the right sub-band. Once the network is joined then everything will work as expected as the Network Server will tell the end-devices what channels it can use.