LT-22222 with LPS8 gateway on Meshed AU915: repeated OTAA joins, no uplinks

End Devices (Nodes) Dragino
4

DIY devices failling to receive OTAA accept (ie, “activation”) messages is a common problem traceable to subtle timing or configuration issues in the custom code or port.

With a more “factory” device it’s a bit puzzling - unclear if the best approach is a support request, or to try to get the code (Dragino is relatively good about that by their site seems to be momentarily offline) and build a version with debug output to a serial port and try to figure out what exactly is going wrong.

Of course these things are best investigated in the context of a gateway you control, where you can get debug output to verify that it actually transmitted. In complex cases it’s useful to put one scope probe on the gateway transmit LED and another on a GPIO the node blips when it starts a receive window, and make sure the two properly line up…

1 Like
5

Just one minor note: the fact that TTN sees the Join Request (yellow/orange icon in the gateway’s Traffic page), accepts it and shows you an Activation (yellow/orange icon in the application/device’s Data page), and a Join Accept (green icon in the gateway’s Traffic page), implies that the configuration in TTN matches the configuration of the device. :+1:

I assume descartes was referring to the logs on the LPS8 gateway hardware (not the gateway Traffic in TTN Console, which indeed looks good).

1 Like
6

Yup, try to see what the gateway says it is actually doing rather than what the TTN servers have requested.

1 Like
7

thanks for your comment. I was hoping that using factory kit and components from same supplier I’d avoid having to debug or get a multimeter out :slight_smile:

8

Thanks for your helpful comments, appreciate that.
Here are the logs from the gateway - unfortunately they mean nothing to me :frowning:
image .
I did find some info on dragino’s wiki page " OTAA Join Process Debug" but I haven’t been able to get to grips with it either!

9

Please don’t post logs as images, but post them as text.

You’d be looking for lines like the following; this looks fine but others may not:

TX rejected

Also, it makes little sense to look at random parts in the log. Instead, look at the parts at the time of an uplink for which you know TTN told the gateway to transmit a downlink (in your case: the OTAA Join Request and its Accept). You should see the gateway sending the uplink (the Join Request) to TTN in a PUSH_DATA, and then receive details about the downlink (the Join Accept) from TTN in some PULL_RESP.

1 Like
10

Thanks again - I see what you mean.
This is from the gateway:

Logread RxTxJson:
Fri Oct 2 19:10:08 2020 daemon.info lora_pkt_fwd[1673]: RXTX~ {"rxpk":[{"tmst":191817379,"time":"2020-10-02T11:10:08.978056Z","chan":8,"rfch":0,"freq":917.500000,"stat":1,"modu":"LORA","datr":"SF8BW500","codr":"4/5","lsnr":10.5,"rssi":-25,"size":23,"data":"ALsagpF6QUCouxqCMf9BQKifyfh1maA="}]}
Fri Oct 2 19:10:14 2020 daemon.info lora_pkt_fwd[1673]: RXTX~ {"txpk":{"imme":false,"tmst":197817379,"freq":923.2,"rfch":0,"powe":14,"modu":"LORA","datr":"SF10BW125","codr":"4/5","ipol":true,"size":33,"ncrc":true,"data":"IHgbBFAU/SqXS4WuNbIqr5CyH20TEuIRwcd89ye979vi"}}
Fri Oct 2 19:10:17 2020 daemon.info lora_pkt_fwd[1673]: RXTX~ {"rxpk":[{"tmst":200308820,"time":"2020-10-02T11:10:17.497451Z","chan":3,"rfch":0,"freq":917.400000,"stat":1,"modu":"LORA","datr":"SF12BW125","codr":"4/5","lsnr":10.8,"rssi":-22,"size":23,"data":"ALsagpF6QUCouxqCMf9BQKimfW9u9a0="}]}
Fri Oct 2 19:10:21 2020 daemon.info lora_pkt_fwd[1673]: RXTX~ {"txpk":{"imme":false,"tmst":205308820,"freq":917.4,"rfch":0,"powe":14,"modu":"LORA","datr":"SF10BW125","codr":"4/5","ipol":true,"size":33,"ncrc":true,"data":"IA3NP3bsPon/HQckwtPmbguwyrPIfjZT8Di3RndSZ6pN"}}

This is from TTN traffic, Join Request, Event Data
{
“gw_id”: “eui-a840411eb93c4150”,
“payload”: “ALsagpF6QUCouxqCMf9BQKifyfh1maA=”,
“dev_eui”: “A84041FF31821ABB”,
“lora”: {
“spreading_factor”: 8,
“bandwidth”: 500,
“air_time”: 28288000
},
“coding_rate”: “4/5”,
“timestamp”: “2020-10-02T11:10:09.125Z”,
“rssi”: -25,
“snr”: 10.5,
“app_eui”: “A840417A91821ABB”,
“frequency”: 917500000
}

11

You’re only showing the communication between gateway and TTN now. And you’re showing two pairs for Join Request/Accept for the gateway log, and a single one from TTN Console.

This is your Join Accept:

So, the Join Accept arrived at your gateway. But was it in time?

A Join Accept for RX1 should be sent 5 seconds after the Join Request was received, which happened at 19:10:08. For RX2 that is 6 seconds. The value for tmst at which the downlink should be transmitted, 197,817,379, is 6,000,000 microseconds after 191,817,379 at which the uplink was sent to TTN. So: TTN wants the gateway to use RX2. Receiving the downlink at the gateway at 19:10:14 may be just in time, or a bit too late, when comparing to 19:10:08.

The other pair is set to transmit after 5 seconds, hence RX1.

So: what does the other log view that you showed earlier give you around that time?

If the gateway transmitted the Join Accept then you’ll need to investigate why the LT-22222 did not receive it. That will be a bit harder to debug; I don’t know the device.

12

Hi @Sgrobler, the gateway appears to RX the join request with an RSSI of -25dBm. This is very strong. Are the device and the gateway very close? I suggest that you move the device to be at least 15 feet (this is in the USA, 5m in new money) away from the gateway and preferably on the other side of a wall to reduce the power levels.

1 Like
13

They’re about 6ft apart at the moment. Is there a downside to having too much power?
Edit: its down to -59 now…

14

There certainly is, with too much power data may be received by the gateway on a neighboring channel due to crosstalk. When the response is being sent on that channel the node probably won’t receive it as it listens on the original channel.

1 Like
15

What regional settings are these systems supposed to be operating in ?
What country are you located in?

16

For TTN, 917.5 SF8BW500 seems to suggest it’s AU-915? If yes: are you using Meshed?

For RX2 in AU-915, regardless the uplink, a downlink should use 923.3 MHz SF12BW500 (DR8), but you’re seeing 923.2 SF10BW125 (DR2) in the first example above.

For RX1 the downlink depends on the uplink, but an uplink on 917.4 SF12BW125 (DR0) should also yield a downlink on SF12BW500 (DR8), but you’re again seeing SF10BW125 in the second example.

So either you’re indeed running into the crosstalk that @kersing mentioned, or it seems the gateway’s configuration has a mismatch somewhere? (Probably in TTN as it’s using the wrong settings for the dowlinks.)

And what other details did that give you?

17

Yes its in Australia: AU-915. I am using Meshed. “TTN-meshed-router” in my gateway settings and "and “meshed-router” in TTN gateway settings. Sub-band 2(916.8-918.2MHz) in my gateway settings, and same in the LT22222.

Where would I look to see fix a setting in TTN? Couldn’t see anything there for uplinks or downlinks?

The console on the LT22222 gives this output. lots of RX timeouts…

DRAGINO LT-22222-L Device
Image Version: v1.4.2
LoRaWan Stack: DR-LWS-003
Frequency Band: AU915
DevEui= A8 40 41 FF 31 82 1A BB
Enter Password to Active AT Commands

[1114]***** UpLinkCounter= 0 *****
[1115]TX on freq 917500000 Hz at DR 6
[1148]txDone
[6135]RX on freq 923900000 Hz at DR 13
[6160]rxTimeOut
[7151]RX on freq 923300000 Hz at DR 8
[7210]rxTimeOut

[8150]***** UpLinkCounter= 0 *****
[8151]TX on freq 917800000 Hz at DR 0
[9638]txDone
[14641]RX on freq 926300000 Hz at DR 8
[14702]rxTimeOut
[15641]RX on freq 923300000 Hz at DR 8
[15701]rxTimeOut

18

Here are some of the settings in the device - do any of these look like they need adjusting?

AT+ADR=1
AT+TXP=0
AT+DR=6
AT+DCS=0
AT+PNM=1
AT+RX2FQ=923300000
AT+RX2DR=8
AT+RX1DL=1000
AT+RX2DL=2000
AT+JN1DL=5000
AT+JN2DL=6000
AT+NJM=1
AT+NWKID=00 00 00 00
AT+FCU=0
AT+FCD=0
AT+CLASS=A
AT+NJS=0
AT+RECVB=0:
AT+RECV=0:
AT+VER=v1.4.2 AU915
AT+CFM=0
AT+CFS=0
AT+SNR=0
AT+RSSI=0
AT+TDC=6000
AT+PORT=2
AT+RX1WTO=7
AT+RX2WTO=7
AT+CHS=0
AT+CHE=2
916.8 917.0 917.2 917.4 917.6 917.8 918.0 918.2

19

I’d not look at the device settings. Instead, check the frequency plan (and router) in the gateway settings, and the handler in the application settings.

Given that specific downlink channel: any chance you ever configured the gateway to use AS923? What’s your gateway’s ID? (Or what do the CLI ttnctl gateway status your-gateway-id and ttnctl gateway info your-gateway-id and https://www.thethingsnetwork.org/gateway-data/gateway/your-gateway-id give you?)

20

Ah, it’s https://www.thethingsnetwork.org/gateway-data/gateway/eui-a840411eb93c4150 There you have it:

{
  "eui-a840411eb93c4150": {
    "id": "eui-a840411eb93c4150",
    "description": "LPS8",
    "owner": "sgrobler",
    "owners": [
      "sgrobler"
    ],
    "location": {
      "latitude": redacted,
      "longitude": redacted,
      "altitude": 0
    },
    "country_code": "au",
    "attributes": {
      "brand": "Dragino",
      "frequency_plan": "AS_920_923",
      "placement": "indoor"
    },
    "last_seen": "2020-10-04T08:05:34Z"
  }
}

More fun:

ttnctl gateways status eui-a840411eb93c4150
  INFO Discovering Router...                   
  INFO Connecting with Router...               
  INFO Connected to Router                     
  INFO Received status          GatewayID=eui-a840411eb93c4150

           Last seen: 2020-09-29 14:14:39.801302027 +0200 CEST
           Timestamp: 0
       Reported time: 2020-09-29 14:14:39 +0200 CEST
      Frequency Plan: EU_863_870
              Bridge: gs.v3.
          IP Address: 58.7.170.44
            Location: not available
                 Rtt: not available
                  Rx: (in: 0; ok: 0)
                  Tx: (in: 0; ok: 0)

and:

ttnctl gateways info eui-a840411eb93c4150
  INFO Found gateway                           

          Gateway ID: eui-a840411eb93c4150
      Frequency Plan: AU_915_928
              Router: meshed-router
         Auto Update: off
               Owner: Sgrobler
        Owner Public: yes
            Location: (redacted, redacted, 0)
     Location Public: yes
       Status Public: yes

               Brand: Dragino
           Placement: indoor
         Description: LPS8

Something has been messed up big time? (Maybe using ttnctl gateway status does not work well with Meshed, or maybe you once registered it using EU868, given the older “Last seen”? Its output may be coming from the EU router?)

1 Like
21

That would explain it all :slight_smile: Thanks for taking the time to help me with this!
No idea how it got screwed up like that.
Don’t think I registered it in any of those frequency plans.
I had tried deleting it and re-registering. Once on www.thethingsnetwork.org and then on console.thethings.meshed.com.au.
I certainly dont see any of those settings from the TTN console:
image

22

And the application’s Handler? And maybe you can try ttnctl yourself as well, to see if that gives you different results when not run from Europe?

1 Like
23

You were right - Join Accept frequency was wrong.
Good news - problem solved. It all came down to the firmware in the device (LPS8 gateway) not being correct. Edwin at Dragino sent me a link to a new firmware and bingo - problem solved :smile:.

Many thanks to everyone for your comments and encouragement.

3 Likes