Node works but does not switch to SF7

How to get started
1

Hi all,

I am having problems setting up a Dragino LT-33222 node, I’m in Germany, so I use EU frequencies and nodes.

It IS able to join the network and DOES send packets including payload after the join, however it never seems to switch to SF7 although the node and one or more gateways are in the same office (10 m apart). BTW, same issue if I have only one gateway in operation.

What I see in my RAK7258 gateway is that after each uplink telegram, the gateway sends this:

{
"freq": 869525000,
"mode": "timerstamped",
"tmst": 541090308,
"rfch": 0,
"powe": 27,
"prea": 8,
"ncrc": true,
"modu": "LORA",
"datr": "SF9BW125",
"codr": "4/5",
"ipol": true,
"size": 17,
"data": "<REDACTED>="

}

{
"MHDR": {
    "MType": "Unconfirmed Data Down",
    "RFU": 0,
    "Major": 0
},
"MACPayload": {
    "FHDR": {
        "DevAddr": "26012056",
        "FCtrl": {
            "ADR": true,
            "RFU": 0,
            "FPending": false,
            "ACK": false,
            "FOptsLen": 5
        },
        "FCnt": 1,
        "FOpts": [
            {
                "CID": "LinkADRReq",
                "DataRate": 4,
                "TXPower": 1,
                "ChMask": "0xff00",
                "ChMaskCntl": 0,
                "NbTrans": 1
            }
        ]
    }
},
"MIC": "F4576028"

}

… which looks like a request from TTN to the node to switch spreading factor, but to no avail… next packet will be SF12 again.

What looks strange to me is that in the TTN console, I see an empty downlink packet, port 0 as response 2 seconds after each uplink packet, if I intertret the signs well enough.

Any ideas? Do I have to contact the vendor?

Thanks in advance
Andreas

2

It looks like this is being sent with TTN-EU868’s non-standard usage of SF9 (instead of SF12) in the RX2 window. Checking that the downlink is following the uplink by two seconds instead of one would confirm.

Your node won’t be able to receive these unless its firmware is aware of the unique behavior of TTN that differs from the LoRaWAN spec.

To complicate things somewhat further, apparently the TTN servers may eventually “give up” on you receiving their non-standard RX2 and start using the standard one.

There are exiting threads on this from people who operate devices in areas subject to it.

3

Are you using OTAA? If not:

Might apply.

@cslorabox the LoRaWAN standard allows using non standard RX2 spreading factors so the practice is perfectly within specifications and saves airtime which allows the gateway to service more nodes while staying within the legal airtime limits.

4

That would require that not only a MAC command to set the custom RX2 be sent, and received, but also that the firmware correctly handle that request.

Needless to say, lots of software unfortunately implements what it expects to see and has seen in testing - not every theoretically possibility.

When something does not seem to be working, putting attention into the unusual aspects is often productive. So in this case I’d either want to put debug output in the node firmware to see what receive mode it is actually putting the radio in, or if I couldn’t do that, get a cheap logic analyzer on the SPI lines between the node processor and radio chip. (Though if a disagreement over receive windows actually is the issue, an inability to put debug output in the firmware is also probably an inability to fix the issue preventing it from using the custom receive window)

If the receive settings agreed, I’d next check that the receive timing was actually correct, using a scope or logic analyzer either between the node transmit and receive, or better still between the gateway transmit and the node receive. And if the timing agreed, I’d then check if perhaps received packets were being discarded for some reason - or if MAC command parsing were failing.

5

That’s right, however for EU868 that MAC command is part of the OTAA reply so if the reply is received (which is a basic requirement for OTAA anyway) the MAC command will be received by the node as well. (And TTN does send OTAA replies using the standard RX2 parameters as documented in the LoRaWAN standards document)

That leaves only the issue of the stack processing it correctly and luckily I haven’t seen any issues in that regards with any of the current stacks. Four years ago the situation was different and that would be one of the first things to check.

6

Thanky you very much everyone - yes I was using OTAA from start. As I wrote, I am surprised that one device (which I installed about 10 days ago) works, while the other four (which I installed two days ago) don’t

I will talk to the vendor / producer… again thanks!

7

By default, the dragino device is set to use with TTN rx2 window. So it is SF9BW125. But we notice that TTN will some times change downlink to SF12 (even the DLsettings in Join Accept tell SF9) which cause the downlink no arrive.

For this case, can you show me the ttn gateway-traffic page? Do you set the end node to send packets with confirm?

Best Regards
Edwin

8

Hi Edwin,

here are all the packets occurring on the gateway when joining:

  -------- Join request on gateway:

"fType": 0,
"freq": 868300000,
"chan": 1,
"tmst": 4225487203,
"rfch": 1,
"stat": 1,
"rssi": -53,
"size": 23,
"modu": "LORA",
"datr": "SF7BW125",
"codr": "4/5",
"lsnr": 10.3,
"data": "REDACTED ="

"MHDR": {
    "MType": "Join Request",
    "RFU": 0,
    "Major": 0
},
"JoinRequest": {
    "AppEUI": "A0 REDACTED ",
    "DevEUI": "A8 REDACTED ",
    "DevNonce": "6506"
},
"MIC": "BCB1CA5A"

-------- Join Accept on gateway:

"freq": 868300000,
"mode": "timerstamped",
"tmst": 4230487203,
"rfch": 0,
"powe": 14,
"prea": 8,
"ncrc": true,
"modu": "LORA",
"datr": "SF7BW125",
"codr": "4/5",
"ipol": true,
"size": 33,
"data": "REDACTED"

"MHDR": {
    "MType": "Join Accept",
    "RFU": 0,
    "Major": 0
},
"JoinAccept": "REDACTED",
"MIC": "1CDE88BC"

-------- Data packet 0 on gateway:

"fType": 0,
"freq": 867100000,
"chan": 3,
"tmst": 4234056716,
"rfch": 0,
"stat": 1,
"rssi": -49,
"size": 22,
"modu": "LORA",
"datr": "SF12BW125",
"codr": "4/5",
"lsnr": 10.8,
"data": "REDACTED =="

"MHDR": {
    "MType": "Unconfirmed Data Up",
    "RFU": 0,
    "Major": 0
},
"MACPayload": {
    "FHDR": {
        "DevAddr": "26012056",
        "FCtrl": {
            "ADR": true,
            "ADRACKReq": false,
            "ClassB": false,
            "ACK": false,
            "FOptsLen": 0
        },
        "FCnt": 0
    },
    "FPort": 2,
    "FRMPayload": "02 9B 1E 0F F2 BE 8B F5 45 "
},
"MIC": "BC88B754"

-------- Data packet 0 on TTN router:

“time”: “2019-11-08T12:25:11.077650172Z”,
“frequency”: 867.1,
“modulation”: “LORA”,
“data_rate”: “SF12BW125”,
“coding_rate”: “4/5”,
“gateways”: [
{
“gtw_id”: “eui-REDACTED”,
“timestamp”: 2689999060,
“time”: “2019-11-08T12:25:11.06871Z”,
“channel”: 3,
“rssi”: -115,
“snr”: -7.8,
“latitude”: REDACTED,
“longitude”: REDACTED,
“altitude”: 274,
“location_source”: “registry”
},
{
“gtw_id”: “eui-REDACTED”,
“timestamp”: 4234056716,
“time”: “”,
“channel”: 3,
“rssi”: -49,
“snr”: 10.8,
“latitude”: REDACTED,
“longitude”: REDACTED,
“location_source”: “registry”
},
{
“gtw_id”: “REDACTED”,
“gtw_trusted”: true,
“timestamp”: 3802335284,
“time”: “2019-11-08T12:25:14Z”,
“channel”: 3,
“rssi”: -60,
“snr”: 11.25,
“latitude”: REDACTED,
“longitude”: REDACTED,
“altitude”: 270,
“location_source”: “registry”
}
]

This data packet 0 caused a downlink response that looks empty!

Payload: not provided
Fields: no Fields
Metadata: {}

Should I send this to support@dragino.com ?

9

Empty in what sense?

A LoRaWAN MACPayload consists of three fields:

FHDR FPort FRMPayload

If the only content is MAC commands encoded in the FOpts (which is part of FHDR), then FPort is 0 and there is no FRMPayload

In contrast the packet you quoted up the thread also included some downlink data along with the MAC commands, so it was sent on port 2.

Should I send this to support@dragino.com ?

What is there to suggest that this is a gateway problem?

10

Empty in what sense?

See enclosed screenshot.

I’m not sure if I can follow the technicalities of LoRa protocol but I hope edwin does…

13
131166×746 16.5 KB

I can’t really assume it is a gateway problem for I have been using three different gateways (all mine) here:

  • The old Things Network gateway
  • A RAK7258 gateway (this is where I got the data from)
  • The new TTIG Things Indoor Gateway.

… and the result did not change in any (for me perceptible) way.

Thanks for your replies and help so far!

11

Port 0 means only MAC data is present.
MAC data is not shown in the application, that is why it is empty. The gateway data should display the encrypted packet including MAC commands.

12

This is the response data packets as seen on the gateway:

"freq": 869525000,
"mode": "timerstamped",
"tmst": 423962404,
"rfch": 0,
"powe": 27,
"prea": 8,
"ncrc": true,
"modu": "LORA",
"datr": "SF9BW125",
"codr": "4/5",
"ipol": true,
"size": 17,
"data": "YPctASaFlgADUf8AAZ4TAe4="

"MHDR": {
    "MType": "Unconfirmed Data Down",
    "RFU": 0,
    "Major": 0
},
"MACPayload": {
    "FHDR": {
        "DevAddr": "26012DF7",
        "FCtrl": {
            "ADR": true,
            "RFU": 0,
            "FPending": false,
            "ACK": false,
            "FOptsLen": 5
        },
        "FCnt": 150,
        "FOpts": [
            {
                "CID": "LinkADRReq",
                "DataRate": 5,
                "TXPower": 1,
                "ChMask": "0xff00",
                "ChMaskCntl": 0,
                "NbTrans": 1
            }
        ]
    }
},
"MIC": "9E1301EE"
13

Exactly, that’s a downlink containing only MAC commands sent to accomplish the ADR scheme only.

And of course your problem is that it’s either

  • not being transmitted by the gateway (unlikely on a more than sporadic basis, but possible)

  • not being received by the node due to mismatched receive settings or wrong receive timing (quite likely)

  • not being honored by the node due to software bugs (possible but not the first guess)

14

Great, many thanks! That was all very helpful.

I think the vendor and / or manufaturer will look into it next monday :slight_smile:
Have a nice weekend!

I’l keep you updated in case someone else hit this rabbithole :slight_smile: