Problems with US915 with RAK4631-LPWAN-Tracker example code

WisBlock
1

Hi,
I have been working with this code successfully with ChirpStack for a short while using EU838.
A colleague of mine in the US wants to use it with US915 - so I tested that single change and it stopped working - or to be more precise it then failed to join. I also reset the ChirpStack network server to 915 using gateway-config.
I’m wondering if it is data size problem. It’s still using DR3.
Can I get more diagnostics?

Thanks
Alan

2

Hi Alan,

if it stops to join, it didn’t even try to send data. It will only send data after successfully joining.

In the gateway, can you see the join request packets coming from RAK4631?
If you reset the Chirpstack network server, did you setup a new application and setup the device?
Are the EUI’s and keys matching?

3

Hi Bernd,
Thanks for your quick reply.
I hadn’t looked at the gateway frames previously, but, yes, the join request arrives and is accepted. This is repeated about every minute.

But the serial monitor output on the device does not believe it.
It says “Did not join network yet”.

Thanks
Alan

4

Hi Alan,
On the gateway, can you see on which frequency the join accept message is sent?
What Gateway are you using?

5

Hi,
I thought I replied yesterday, but I forgot to press the button . Sorry.
I have grabbed the uplink and downlink packets and put them here . Not very elegant I’m afraid!
The gateway is a RAK7248 with standard RAK firmware.

[
    {
        "downlinkMetaData": {
            "gatewayID": "dca632fffede8df9",
            "txInfo": {
                "frequency": 927500000,
                "power": 20,
                "modulation": "LORA",
                "loRaModulationInfo": {
                    "bandwidth": 500,
                    "spreadingFactor": 10,
                    "codeRate": "4/5",
                    "polarizationInversion": true
                },
                "board": 0,
                "antenna": 0,
                "timing": "DELAY",
                "delayTimingInfo": {
                    "delay": "5s"
                },
                "context": "d2EtQw=="
            }
        },
        "phyPayload": {
            "mhdr": {
                "mType": "JoinAccept",
                "major": "LoRaWANR1"
            },
            "macPayload": {
                "bytes": "3rS3KdX68t8qf3nI"
            },
            "mic": "f24952ef"
        }
    },
    {
        "uplinkMetaData": {
            "rxInfo": [
                {
                    "gatewayID": "3KYy//7ejfk=",
                    "time": "2021-06-01T13:41:42.173108Z",
                    "timeSinceGPSEpoch": "1306590121.173s",
                    "rssi": -117,
                    "loRaSNR": -15,
                    "channel": 7,
                    "rfChain": 1,
                    "board": 0,
                    "antenna": 0,
                    "location": {
                        "latitude": 52.90276,
                        "longitude": -2.71642,
                        "altitude": 113,
                        "source": "UNKNOWN",
                        "accuracy": 0
                    },
                    "fineTimestampType": "NONE",
                    "context": "d2EtQw==",
                    "uplinkID": "7Qsso1YuQqeV3IkUOrNJmg==",
                    "crcStatus": "CRC_OK"
                }
            ],
            "txInfo": {
                "frequency": 905300000,
                "modulation": "LORA",
                "loRaModulationInfo": {
                    "bandwidth": 125,
                    "spreadingFactor": 10,
                    "codeRate": "4/5",
                    "polarizationInversion": false
                }
            }
        },
        "phyPayload": {
            "mhdr": {
                "mType": "JoinRequest",
                "major": "LoRaWANR1"
            },
            "macPayload": {
                "joinEUI": "70b3d57ed00201e1",
                "devEUI": "ac1f09fffe03f101",
                "devNonce": 42132
            },
            "mic": "3d80c697"
        }
    }
]
6

Hi guys,

Just to let you know I have a similar problem with the RAK4631-DeepSleep-Lorawan example, i’m using the RAK 7268 gateway (network server mode) and it gets stuck on the lmh_join() line.

The Rak gateway does acknowledge the join:
{
“applicationID”: “3”,
“applicationName”: “rak_OTAA_test”,
“deviceName”: “wisk01”,
“devEUI”: “8888888888883333”,
“timestamp”: 1622674060,
“devAddr”: “0228e07d”
}

But the LoRaWAN_OTAA_ABP demo does work.

Any help will be appreciate.

7

Hi,

I switch to my Linux PC and I was able to pass the join part removing the sub-band setup, removing this line:
lmh_setSubBandChannels(1);
Hope this helps.

8

Looking into packets, I see the Gateway forwards the Join Accept packet on 927.5 MHz. That is not a frequency used in US915 and the node will not receive the packet. Can you check the channel plan in the gateway and in the LoRaWAN server.

And another thing, I forgot about the lmh_setSubBandChannels() functions. Usually it is only needed for regions that offer more than 8 channels. On EU868 it is ignored.
On US915 there are (if I remember correct) 72 channels, so all three parts (Node, gateway and network server) have to define a sub set of channels (only 8 channels are used).
Which channels should be used depends on your network server. TTN uses the sub set #1 which means channels 8 to 15. That’s why we put lmh_setSubBandChannels(1) in the example. What channel plan is defined in your gateway
sub set 0 = channels 0 to 7 and 64
sub set 1 = channels 8 to 15 and 65
…

9

Hi Bernd,
All I can find on the server relating to this is in the chirpstack-network-server.toml file. It has this line:

enabled_uplink_channels=[8,9,10,11,12,13,14,15]

Note that this exact server configuration works fine at US915 for the GPSTracker.ino example.

Thanks
Alan

10

In this case remove the command lmh_setSubBandChannels(1) from the code.

11

Hi,
Thanks.
That worked
Alan