Region Channel Mask

LPWAN Nodes RAK7431
1

Hi,
Is it possible to change the channel mask on the RAK7431?

I have a RAK7431 set to AU915 FSB2. Unfortunately the device takes along time to connect using OTAA method and when successful alot of messages are missing.

Using a spectrum analyzer, taking a background reading before commencing my test, it looks like the RAK7431 is operating across the entire AU915 channel range 1 to 64 and not restricted to channels 8 to 15 as I was expecting.

I repeated my experiment with a RAK811 and this worked fine.

When querying the Region, channel mask and channels in the RAK7431 they look correct.

My device is running firmware 1.0062.

Any help to resolve this issue would be very much appreciated.

Regards

2

That’s in accordance with the LoRaWAN spec, which is written with the idea that the node knows nothing about the network it is trying to join, beyond the regional settings which reflect local radio regulations:

Granted, this is “inefficient” - a number of node stacks provide a way to “cheat” and specify the bandplan in use by a particular network, though it’s unclear if they can pass LoRaWAN certification, at least without putting that behind some unique explicit mode setting.

Just having previously enabled/disabled channels should not affect join behavior, because in the intent of the LoRaWAN spec a join is supposed to throw away and replace all session scope knowledge like that - in the intent of the spec, a join should let a node discover and move to a network with its gateways on a different sub-band.

3

Thanks for your reply Chris.
I’ll i’ve located a a copy of the LoRaWAN specification document and will read this to brush up my knowledge on the topic.

Just one final question, in the application server I can see the Joint Request message from RAK7431 and Joint Accept message sent from the application server on the correct downlink frequency, but for some reason the RAK7431 doesn’t appear to receive the message and join request fails and repeats the join process. I have noticed that with the RAK7431 within close proximity to the gateway (approx. 3m) the rssi and SNR seems to vary wildly in the uplink message e.g. rssi can range from -31 to -115 dBm on the same channel. Do you think this could be a configuration issue with my RAK2245 gateway configuration rather than an issue with the RAK7431 end node?

Note:
When viewing LoRaWAN frames in my application for the RAK7431, once successfully joined to the network, I noticed that multiple uplink messages with the same fcnt sequence number were received was well as missing frames as there were jumps in fcnt sequence number. Thus, I assume that messages not received by the application were on channels outside AU915 FSB2 and with regards to messages with the same fcnt that the RAK7431 did not receive a acknowledgment that the message was received and repeated the message with the same fcnt sequence number. Is this correct?

Sorry for all the question. I’m relatively new to LoRaWAN and obviously have some learning to do:)

Cheers

4

When you have the node so close to the gateway, its transmissions massively overload the receiver, become distorted and that distortion causes them to splatter over onto channels other than the ones on which they’re actually transmitted. The spurious signals are weak as they’re caused by the non-linearity of the receiver at overwhelming power level (or potentially also the transmitter), hence you see them as false -115 RSSI signals, which may be either valid or invalid at hardware CRC and LoRaWAN MIC level.

Modern network servers will pick the strongest frequency of any uplink, but in the overload case its also possible for the strongest true-frequency version to be corrupted and invalid, leaving only the false frequency ones. Those of course would trigger a join accept transmitted on a frequency other than the one where the node is listening.

Essentially, you want to avoid having nodes so close to a gateway - try for the best case RSSI to be say -50 or below.

I assume that messages not received by the application were on channels outside AU915 FSB2

This should not be happening after join, or more exactly after a series of MAC downlinks that configure the node to exclusively use the supported frequency subband.

First move your nodes a more reasonable distance from the gateway, then look at what if any problems remain.

5

Thanks for your advice.
I shall move my node further away from the gateway so that the RSSI is below -50 dBm and see how i get on.

Kind Regards
Greg

6

Hi Chris,
I setup my RAK7431 node up on in my garage some 30m away with the gateway setup in my house to ensure that the rssi was less than -50 dBm. Unfortunately, this did not resolve my issue with establishing a reliable connection i.e. the result was similar to before in that sometimes the node would connect successfully, but stopped and/or dropped packets as the fcnt was not in sequence.

When not connected, I can see numerous “Accept joint-requests” messages in the ttn device application live data page, so the messages are at least making it that far. When I look at the logs in my Pi Hat RAK2245 gateway, I can see "JSON up: {“rxpk…” and “JSON down: {txpk…” that I think are the node joint request and network server joint accept requests (see below). Thus, I think that the issue is due to my RAK7431 either not receiving or not properly processing the joint accept message from the ttn network server. Uplink and Downlink frequencies look correct for AU915 FSB2.

Edit:
Correction regarding downlink frequency, looking at the syslog in more detail the downlink frequencies from the GW to the Node cover downlink channels 65 to 71.

The only message displayed in the RAK7431 serial interface are “SYSLOG:4:OTAA Join Request” and “EVENT:7:OTAA_FAILED”. I’ve looked trough the RAK7431 documentation, but can find anything that would assist with debugging at the node.

Note:
Just to confirm I don’t have this problem if I configure other nodes e.g. Dragino LT2222, Dragino RS485-ln, RAK811 to name a few.

##############
FROM SYSLOG
##############
Oct 15 17:26:01 rak-gateway ttn-gateway[9187]: JSON down:
{
“txpk”: {
“imme”: false,
“tmst”: 335281892,
“freq”: 923.9,
“rfch”: 0,
“powe”: 27,
“modu”: “LORA”,
“datr”: “SF10BW500”,
“codr”: “4/5”,
“ipol”: true,
“size”: 33,
“ncrc”: true,
“data”: “IDRzpyYRZSn3OpLb2JXw1oZNdtuStNBXEf4tLyJ2v9cS”
}
}

Oct 15 17:26:01 rak-gateway ttn-gateway[9187]: JSON up:
{
“rxpk”: [{
“tmst”: 330281892,
“chan”: 1,
“rfch”: 0,
“freq”: 917.000000,
“stat”: 1,
“modu”: “LORA”,
“datr”: “SF10BW125”,
“codr”: “4/5”,
“lsnr”: 9.0,
“rssi”: -73,
“size”: 23,
“data”: “ADF0Ffn/CR+sXAkF/v8JH6w4r8XADo4=”
}]
}

Any suggestions?

If not, I think I’ll park this issue until I can afford to spend more time to resolve the issue.

Kind Regards
Greg