RAK7258 connected to TTI with LNS - AS923 Channel plan

LPWAN Industrial Gateways / Concentrators RAK7258
1

Issue: RAK 811 based device (and other vendor modules) connect to TTI via RAK7258 sometimes

Setup :
RAK7258 with 1.2.0065_Release_r209 using “Basic Station” - AS923
RAK811 with v3.0.0.14.H_20200810 using OTAA - AS923
TTI channel plan - AS_923_925

Details: Sometimes my devices connect to TTI but most of the time fail with

UplinkChannelNotFound
UplinkChannelNotFound1554×243 21.6 KB

I’m using “Basic Station” (connection details below) and can see gateway is connected in TTI gateway status tab

NetworkConfig
NetworkConfig1666×810 79 KB

Based on discussion with helpful TTI support people I need to use this channel plan

I fired up the web admin tool navigated to the Channel plan tab

ChannelPlanAdvanced
ChannelPlanAdvanced1709×856 122 KB

Can’t change the channel config, what am I missing ?

@KiwiBryn

2

Getting the nodes to transmit on the correct frequencies is really a node problem rather than a gateway problem; the gateway settings only control which possible transmissions are passed to the network server. So the TTI stack complaining about a signal on an improper channel isn’t really an issue which originates with a gateway, but rather either your node or something else transmitting on the wrong frequency, or being so close to the gateway that it overloads it and falsely appears on frequencies other than the one it is actually transmitting on.

In terms of setting the gateway channel plan, you cannot directly set channel frequencies. Rather you have to set the the center frequency of each of the two front end radio ICs, and then set the channels as differences from those (up to about +/- 200 KHz, maybe 250 KHz limit)

If you look at a traditional global_conf.json type gateway configuration file for the bandplan you want to use, you can manually extract a working set of center frequency and offset settings from that, and put it into the web configuration widget.

3

Hi all,

The RAK811 device config appears to match the AS_923_925.yml above

at+version
OK V3.0.0.14.H
at+set_config=lora:region:AS923
OK
at+get_config=lora:channel
OK *
0,on,923200000,2,5; *
1,on,923400000,2,5; *
2,on,923600000,2,5; *
3,on,923800000,2,5; *
4,on,924000000,2,5; *
5,on,924200000,2,5; *
6,on,924400000,2,5; *
7,on,924600000,2,5;
8,off,0,0,0;
9,off,0,0,0;
10,off,0,0,0;
11,off,0,0,0;
12,off,0,0,0;
13,off,0,0,0;
14,off,0,0,0;
15,off,0,0,0

Off todo some more research

Thanks

@KiwiBryn

4

The RAK811 device config appears to match the AS_923_925.yml above

Since you didn’t state the frequency of the rejected join request, it’s hard to know if that’s somehow not yet in effect, or if there’s a problem like being too close to the gateway causing phantom reception on a different than actual frequency due to overload.

5

In the logs for they are mostly 924.6MHz which fail. But, every so often there is a 923.4MHz one which succeeds.

Shouldn’t join requests be 923.2MHz & 923.4MHz?

I also tried a couple of RHF76-052 module based devices and they fired up and worked reliably after a firmware update.

So much to learn, still in the “drinking from a firehose” phase.

@KiwiBryn

6

Fail exactly how? Join requests can fail for many reasons - not being heard, wrong keys, illicit nonce re-use, and then all the various ways in which a join accept can fail to get back to the node.

Additionally it appears that the TTI folks have developed the “funny idea” that they should ignore uplinks on channels a node should ultimately use, if they don’t actually remember that they’ve yet told it to use those.

7

From the first post in the thread

Details: Sometimes my devices connect to TTI but most of the time fail with

image

The join request is dropped with message “Uplink channel not found”.

From the logs the failed join requests are on 924.6MHz

For AS923 shouldn’t join requests be on 923.2MHz or 923.4MHz?

8

Your picture is illegible even when magnified, but it’s clear it doesn’t include any details of the rejected messages such as frequency. It’s not clear that your belief as to what that is based on another source is actually applicable to the particular message being rejected.

I suspect though that this is ultimately a problem with TTI’s stack that you’ll need to pursue with them. (As I mentioned before, they seem to have a uniquely odd idea that they should ignore messages they actually receive, if they don’t remember having configured the node to that channel.)

Given full air details of the exact transmission triggering the error will be critical in any case.

9

Sorry I copied ‘n’ paste the image from the first post rather than re-uploading it. I didn’t realise that the image quality had been reduced from the thumbnail in the preview.

Below is representative of the RAK Gateway request logging after my RAK811 end node has been power cycled

Every so often I see a successful join on 923.2/923.4MHz

09:27:33923.4-479.25-CRC_OKLORA4/5SF7BW125-57----AppEUI70 B3 D5 7E D0 00 00 00DevEUI60 C5 A8 FF FE 77 7C 32{
“freq”: 923400000,
“chan”: 1,
“tmst”: 238779451,
“utmst”: 1612211254166,
“rfch”: 0,
“stat”: 1,
“rssi”: -47,
“size”: 23,
“modu”: “LORA”,
“datr”: “SF7BW125”,
“codr”: “4/5”,
“lsnr”: 9.25,
“data”: “AAAAANB+1bNwMnx3/v+oxWCvzQmEgD0=”
}{
“MHDR”: {
“MType”: “Join Request”,
“RFU”: 0,
“Major”: 0
},
“JoinRequest”: {
“AppEUI”: "70 B3 D5 7E D0 00 00 00 ",
“DevEUI”: "60 C5 A8 FF FE 77 7C 32 ",
“DevNonce”: “CDAF”
},
“MIC”: “3D808409”
}

09:27:38923.4–14NO_CRCLORA4/5SF7BW125-72----{
“freq”: 923400000,
“mode”: “timerstamped”,
“tmst”: 243779451,
“rfch”: 0,
“powe”: 14,
“prea”: 8,
“ncrc”: true,
“modu”: “LORA”,
“datr”: “SF7BW125”,
“codr”: “4/5”,
“ipol”: true,
“size”: 33,
“data”: “IA1g5+XgG33Qu7SjSG2uk+TEQx8SCME1m185DFzY9LNl”
}{
“MHDR”: {
“MType”: “Join Accept”,
“RFU”: 0,
“Major”: 0
},
“JoinAccept”: “0D60E7E5E01B7DD0BBB4A3486DAE93E4C4431F1208C1359B5F390C5C”,
“MIC”: “D8F4B365”
}

Most of the time the join requests are on a selection of other frequencies and there is no “Join Accept” response.

09:15:55924-519.75-CRC_OKLORA4/5SF7BW125-57----AppEUI70 B3 D5 7E D0 00 00 00DevEUI60 C5 A8 FF FE 77 7C 32{
“freq”: 924000000,
“chan”: 4,
“tmst”: -459107597,
“utmst”: 1612210556272,
“rfch”: 0,
“stat”: 1,
“rssi”: -51,
“size”: 23,
“modu”: “LORA”,
“datr”: “SF7BW125”,
“codr”: “4/5”,
“lsnr”: 9.75,
“data”: “AAAAANB+1bNwMnx3/v+oxWA5eGjRu1E=”
}{
“MHDR”: {
“MType”: “Join Request”,
“RFU”: 0,
“Major”: 0
},
“JoinRequest”: {
“AppEUI”: "70 B3 D5 7E D0 00 00 00 ",
“DevEUI”: "60 C5 A8 FF FE 77 7C 32 ",
“DevNonce”: “7839”
},
“MIC”: “51BBD168”
}

09:16:00924–14NO_CRCLORA4/5SF7BW125-72----{
“freq”: 924000000,
“mode”: “timerstamped”,
“tmst”: -454107597,
“rfch”: 0,
“powe”: 14,
“prea”: 8,
“ncrc”: true,
“modu”: “LORA”,
“datr”: “SF7BW125”,
“codr”: “4/5”,
“ipol”: true,
“size”: 33,
“data”: “IEJK4ghZBoHoS/1X0+mTZSd2W/0a96XFaqa5nx6p1tHD”
}

10

Is a packet with a bad hardware CRC, there will be no response to that

“rssi”: -51,

Indicates your node is too close to your gateway; this is known to sometimes cause errors

11

I moved the device to the far end of the property and now on the first couple of power cycles it’s looking positive

11:09:16923.2-3312.25-CRC_OKLORA4/5SF10BW125-371----AppEUI70 B3 D5 7E D0 00 00 00DevEUI47 A9 B2 69 00 3E 00 3C{
“freq”: 923200000,
“chan”: 0,
“tmst”: 2045997012,
“utmst”: 1612217356350,
“rfch”: 0,
“stat”: 1,
“rssi”: -33,
“size”: 23,
“modu”: “LORA”,
“datr”: “SF10BW125”,
“codr”: “4/5”,
“lsnr”: 12.25,
“data”: “AAAAANB+1bNwPAA+AGmyqUdCLJppSts=”
}{
“MHDR”: {
“MType”: “Join Request”,
“RFU”: 0,
“Major”: 0
},
“JoinRequest”: {
“AppEUI”: "70 B3 D5 7E D0 00 00 00 ",
“DevEUI”: "47 A9 B2 69 00 3E 00 3C ",
“DevNonce”: “2C42”
},
“MIC”: “DB4A699A”
}

I may have been unlucky with the request/response sequence I selected in previous reply

I don’t have all the detail but this is one of the ones I had noted as failed but the CRC is OK.

Join Request,20:50:43,924.6,-40,7.75,-,CRC_OK,LORA,‘4/5’,SF7BW125,-,‘57’,-,-,-,AppEUI 70 B3 D5 7E D0 00 00 00, DevEUI 60 C5 A8 FF FE 77 7C 32

Part of me me wonders why I got a 923.2 & 923.4 MHz join request every so often and they were the only ones worked.

The rest of me is thinking don’t really need to know it works well enough time to move on.

Thanks

@KiwiBryn

12

Hmm, this

“rssi”: -33,

Would not be consistent with that. Rather it indicates something sitting right next to the gateway

I don’t have all the detail but this is one of the ones I had noted as failed but the CRC is OK.

Join Request,20:50:43,924.6,-40,7.75,-,CRC_OK,LORA,‘4/5’,SF7BW125,-,‘57’,-,-,-,AppEUI 70 B3 D5 7E D0 00 00 00, DevEUI 60 C5 A8 FF FE 77 7C 32

No frequency information on that, odd parsing but what still looks like a worrisomely close RSSI which can lead to misidentification of frequency, even if the packet is received without CRC error. Sometimes in situations of overload you’ll even see the same packet received both on the true frequency, and on additional false frequencies.

13

I moved device even further away and it is now in a galvanised steel garden shed…

12:06:53923.2-599.75-CRC_OKLORA4/5SF10BW125-371----AppEUI70 B3 D5 7E D0 00 00 00DevEUI47 A9 B2 69 00 3E 00 3C{
“freq”: 923200000,
“chan”: 0,
“tmst”: 1208230428,
“utmst”: 1612220813553,
“rfch”: 0,
“stat”: 1,
“rssi”: -59,
“size”: 23,
“modu”: “LORA”,
“datr”: “SF10BW125”,
“codr”: “4/5”,
“lsnr”: 9.75,
“data”: “AAAAANB+1bNwPAA+AGmyqUfuvORPW7I=”
}{
“MHDR”: {
“MType”: “Join Request”,
“RFU”: 0,
“Major”: 0
},
“JoinRequest”: {
“AppEUI”: "70 B3 D5 7E D0 00 00 00 ",
“DevEUI”: "47 A9 B2 69 00 3E 00 3C ",
“DevNonce”: “BCEE”
},
“MIC”: “B25B4FE4”
}

14

That’s still pretty strong, maybe not problematically so, but still shouting-in-your-ear strong.

15

Your comment in the last post about the RSSI caught my attention…

Distance + tin shed should’ve had more impact. So, I went back and checked

47 A9 B2 69 00 3E 00 3C. is Seeeduino LoRaWAN/GPS device
60 C5 A8 FF FE 77 7C 32 is RAK811 Wisnode

The Wisnode rssi is -75,

From logging in my application the Seeeduino device accidentally powered up just before my last post.

Need to walk away for a bit

Thanks