OTAA ok, 12h later I get denied, reboot gateway --> OK again ...!?

End Devices (Nodes)
45

That could well be the case. I do not know the typical response times for IP traffic for your GSM provider.

For join the windows are at 5 and 6 seconds ± 20 microseconds after the node transmitted the packet, windows length depends on the implementation but is probably about about 0.3 seconds at SF12.

No, it is false for ONE of the radios. The other radio takes care of all transmissions.

You should be using the configuartion from TTN Github That one is set correctly.

That seems to be the case.

Looking at multiple traces you provided I am sure your gateway receives data late. Looking at the latest trace:
11:04:50.435723 is join request.
11:04:55.914887 is join accept response
Time difference is 5.479164 seconds. That should have been at most 4.9 seconds to allow the gateway software some processing time. (The relative timestamp tmst in the join request is 998979548 microseconds, in the accept it’s 1003979548. So TTN wants the gateway to send the join accept 5000000 microseconds after receiving the join request.)

10:52:06.493745 uplink packet from node
10:52:07.880705 downlink response.
Time difference is 1.38696 which again is well beyond the limits. (Timestamps being 235026052 and 236026052, hence 1000000 microseconds difference.)

The thing to look at now is why the data is getting to your gateway late. That is something network related between your gateway and TTN router because TTN sends data in a timely manner for other gateways.

1 Like
46

Just noticed that the 3rd logs were sent from a different gateway IP address? Is that to be expected, or is it a different gateway?

47

@arjanvanb,

same gateway, I am using DHCP and the ABP log was made at a different time.

48

Hi @kersing, @arjanvanb,

I post the answer that I’ve got finally from Kerlink Support. They have also failed into the attempt of connecting to TTN over GSM.

Hello Mr Forte,

I installed the “the thing network” packet forwarder. When using GSM, I received multiple join procedures from the mote and no data packets. The join procedure isn’t successful.
Do you receive multiple join procedure?

When using Ethernet, it works perfectly and I can reboot my mote as many time as I want without any problem (no need to reboot the station).

It seems like there is a problem with your packet forwarder.
In my opinion, a too high ping with the server might be the problem. Also, there may be a bad synchronization between the server and the station. When receiving a packet from the server the packet forwarder display something like that:

INFO: [down] a packet will be sent on timestamp value 123126684

Displaying the current timestamp may be a good start to see if there is a problem.

As you are not using official Kerlink packet forwarder I cannot help you more. To begin with, we usually recommend our client to use our packet forwarder with the Semtech server but their server is not working with OTAA right now.

Your json files are OK. There are two front-ends able to handle radio frequencies. The “tx_enable: true” field defines which front-end will send packets. The defined frequencies (868.1 MHz / 868.3 MHz / 868.5 MHz) that are configured into radio 1 are only used to receive packets.

There is a point I cannot check myself. The json files describes the radio calibration parameters: Did you check them with the following instruction?

wiki:calibration [Wirnet™ Station]

Also, make sure your station is at least 5 meters away from your motes. I doubt it will solve your problems but it is recommended.

I dug deeper into the problem and there are few considerations I would like to share with you:

  • As far as I understood, after the uplink transmission the end-node will open an RX1 slot at the same frequency used for the uplink, and a second receive window (RX2) at a fixed frequency that should be set according the one used by TTN server. On my own Kerlink Gateway there are two radio front-ends able to handle the set of Lora frequency, one only used to receive packets from end-node, and the second one to transmit packets from the server to Lora side. In my case, I am using the 3 standard channels from Lora specification (868.1/868.3/868.5) to send uplink packets: these same frequency cannot send data packets back according to the way are configured into Kerlink Gateway, so I guess that I will never receive downlink within RX1 slot. Therefore, I should focus on the only RX2 slot. TTN uses f=869.525 MHz (SF9BW125), but this frequency is not set into none of the two radio front-ends (see TTN Github). In addition, the “ttn-abp.ino” arduino sketch provided along with LMIC library clearly states:
 // TTN defines an additional channel at 869.525Mhz using SF9 for class B
    // devices' ping slots. LMIC does not have an easy way to define set this
    // frequency and support for class B is spotty and untested, so this
    // frequency is not configured here.

As result, above all said, I will never get downlink packets in RX2 window as well. Taking a step back, I would like to post once again a log that I simply got running a very basic ABP arduino sketch.

/* ABP activated device. Downlink packet sent to endnode 1 sec after "Hello World!" uplink.
However, LMIC.dataLen=0 on Arduino side meaning no downlink packet has been received. */

10:19:53.487901 IP 2.43.193.163.33372 > 52.169.76.203.1700: UDP, length 247
        0x0000:  4500 0113 067b 4000 4011 ee1c 022b c1a3  E....{@.@....+..
        0x0010:  34a9 4ccb 825c 06a4 00ff 832b 0135 c100  4.L..\.....+.5..
        0x0020:  0000 024b 0803 0571 7b22 7278 706b 223a  ...K...q{"rxpk":
        0x0030:  5b7b 2274 6d73 7422 3a31 3433 3539 3937  [{"tmst":1435997
        0x0040:  3637 352c 2274 696d 6522 3a22 3230 3137  675,"time":"2017
        0x0050:  2d30 312d 3237 5430 393a 3139 3a35 332e  -01-27T09:19:53.
        0x0060:  3438 3733 3032 5a22 2c22 6368 616e 223a  487302Z","chan":
        0x0070:  322c 2272 6663 6822 3a31 2c22 6672 6571  2,"rfch":1,"freq
        0x0080:  223a 3836 382e 3530 3030 3030 2c22 7374  ":868.500000,"st
        0x0090:  6174 223a 312c 226d 6f64 7522 3a22 4c4f  at":1,"modu":"LO
        0x00a0:  5241 222c 2264 6174 7222 3a22 5346 3742  RA","datr":"SF7B
        0x00b0:  5731 3235 222c 2263 6f64 7222 3a22 342f  W125","codr":"4/
        0x00c0:  3522 2c22 6c73 6e72 223a 372e 322c 2272  5","lsnr":7.2,"r
        0x00d0:  7373 6922 3a2d 3333 2c22 7369 7a65 223a  ssi":-33,"size":
        0x00e0:  3236 2c22 6461 7461 223a 2251 4830 6141  26,"data":"QH0aA
        0x00f0:  5361 4142 5141 424e 7863 3963 5a54 4d79  SaABQABNxc9cZTMy
        0x0100:  6a36 4342 4676 5571 6679 5938 5a6b 3d22  j6CBFvUqfyY8Zk="
        0x0110:  7d5d 7d                                  }]}
10:19:54.295617 IP 52.169.76.203.1700 > 2.43.193.163.33372: UDP, length 4
        0x0000:  4500 0020 2dc5 4000 2c11 dbc5 34a9 4ccb  E...-.@.,...4.L.
        0x0010:  022b c1a3 06a4 825c 000c 6f5c 0135 c101  .+.....\..o\.5..
10:19:54.936678 IP 52.169.76.203.1700 > 2.43.193.163.44112: UDP, length 174
        0x0000:  4500 00ca 2e13 4000 2c11 dacd 34a9 4ccb  E.....@.,...4.L.
        0x0010:  022b c1a3 06a4 ac50 00b6 ac81 0100 0003  .+.....P........
        0x0020:  7b22 7478 706b 223a 7b22 696d 6d65 223a  {"txpk":{"imme":
        0x0030:  6661 6c73 652c 2274 6d73 7422 3a31 3433  false,"tmst":143
        0x0040:  3639 3937 3637 352c 2266 7265 7122 3a38  6997675,"freq":8
        0x0050:  3638 2e35 2c22 7266 6368 223a 302c 2270  68.5,"rfch":0,"p
        0x0060:  6f77 6522 3a31 342c 226d 6f64 7522 3a22  owe":14,"modu":"
        0x0070:  4c4f 5241 222c 2264 6174 7222 3a22 5346  LORA","datr":"SF
        0x0080:  3742 5731 3235 222c 2263 6f64 7222 3a22  7BW125","codr":"
        0x0090:  342f 3522 2c22 6970 6f6c 223a 7472 7565  4/5","ipol":true
        0x00a0:  2c22 7369 7a65 223a 3134 2c22 6461 7461  ,"size":14,"data
        0x00b0:  223a 2259 4830 6141 5359 4141 5141 426b  ":"YH0aASYAAQABk
        0x00c0:  5a74 4a6d 7634 3d22 7d7d                 ZtJmv4="}}

As you can see the downlink packet was sent back on Lora side on the 868.5 MHz frequency, which belong to “radio 1” Kerlink front-end, for which the “tx_enable” is set to FALSE. Now the questions I keep asking to myself are:

  1. Has the gateway sent this packet anyway?
  2. Has the gateway discarded this packet since it cannot use that frequency for transmission?
  3. Is the node supposed to say (in its uplink packet) which frequency the server must use for eventually sent downlink packets?
  4. Is the node really listening on 869.525 MHz with the current LMIC library implementation? (@matthijs)

Sorry if I was too long, despite that I think that sharing such experiences is of great value for anyone who, just like me, is eager to gain truly knowledge and understanding on Lora.
Of course, as always, I look forward to get your considerations.

Thanks again, wish you good day!

2 Likes
49

Nice research salvatore_forte ! We are struggling with the same questions. How do we know for sure if the node receives back from the TTN server in its either first or second receive window the payload the network server sends back downstream.

you mention : [quote=“salvatore_forte, post:48, topic:2025”]
However, LMIC.dataLen=0 on Arduino side meaning no downlink packet has been received.
[/quote]

Where do you see in your tcpdump -XX on the packet_forwarder that de dataLen is 0 ?
When I paste my txpk hereafter, one can see that size of the sent packet by the packet_forwarder is 29. Does this mean the LMIC.dataLen= 29 ?

12:23:20.022556 IP 52.169.76.203.1700 > 10.10.10.2.34773: UDP, length 195
0x0000: 84eb 18e5 5232 e48d 8cd3 5fe4 0800 4500 …R2…_…E.
0x0010: 00df e345 4000 3111 d048 34a9 4ccb 0a0a …E@.1…H4.L…
0x0020: 0a02 06a4 87d5 00cb 4b1f 0100 0003 7b22 …K…{"
0x0030: 7478 706b 223a 7b22 696d 6d65 223a 6661 txpk":{“imme”:fa
0x0040: 6c73 652c 2274 6d73 7422 3a32 3337 3237 lse,“tmst”:23727
0x0050: 3838 3034 2c22 6672 6571 223a 3836 392e 8804,“freq”:869.
0x0060: 3532 352c 2272 6663 6822 3a30 2c22 706f 525,“rfch”:0,“po
0x0070: 7765 223a 3237 2c22 6d6f 6475 223a 224c we”:27,“modu”:“L
0x0080: 4f52 4122 2c22 6461 7472 223a 2253 4639 ORA”,“datr”:“SF9
0x0090: 4257 3132 3522 2c22 636f 6472 223a 2234 BW125”,“codr”:“4
0x00a0: 2f35 222c 2269 706f 6c22 3a74 7275 652c /5”,“ipol”:true,
0x00b0: 2273 697a 6522 3a32 392c 2264 6174 6122 “size”:29,“data”
0x00c0: 3a22 5946 6358 4153 5941 5a67 7342 6858 :“YFcXASYAZgsBhX
0x00d0: 716e 7657 486b 4376 446d 5139 5447 5a66 qnvWHkCvDmQ9TGZf
0x00e0: 2b37 665a 7373 4f55 673d 227d 7d +7fZssOUg=”}}

With mqtt I can show in Node-red the device/down/scheduled and device/down/sent topics. There is also a device/down/ack topic that should conclude the transmission which acknowlegdes the reveiving of the sent packet from the gw. In my case, I see none of these. I am not sure if this has got to do with it. Any clue on this part ?

Please do continue your research on the downlink capability of TTN, hopelfully we can contribute too. On another post we talked about it too : Dragino GPS Tracker.

Have a nice day !

1 Like
50

Hi @wdebbaut,

many thanks for the support, the replies that I have got from all of you have been very helpful so far! To answer your question:

Where do you see in your tcpdump -XX on the packet_forwarder that de dataLen is 0 ?

“dataLen” is a parameter declared within the LMIC struct, I just printed it out inside the arduino sketch, and this has allowed me to do a bit of debugging also on end-node side. As I said before, basically it gives you the number of bytes of the received payload. In my case always =0, indicating that I am not getting any packet at all.

Now I am wondering if the “txpk” I see in the log you posted is the actual JOIN_ACCEPT message to deliver to node, or just an acknowledgement, also considering what @arjanvanb said few posts ago:

the size of the acknowledgement might give you an indication if the gateway thinks all is fine? The NONE is 29 bytes, the TOO_LATE is 33 bytes.

In my case, the size of the sent packets is always 33 bytes, further confirming that the message is arriving too late. In order to make a fair comparison with the missing reception of downlink packets I am facing, would you be so kind to post the complete log you get running tcpdump command? Precisely, you might start from the uplink message (JOIN_REQUEST) sent from gateway to TTN, and then the downlink that follows.

I repost my log (OTAA not working) for your comprehension:

/* OTAA activation tentative. Device not activated! JOIN_ACCEPT message forwarded to endnode
5 seconds after JOIN_REQUEST */

11:04:50.435723 IP 31.157.192.137.49457 > 52.169.76.203.1700: UDP, length 243
        0x0000:  4500 010f c9ec 4000 4011 0e57 1f9d c089  E.....@.@..W....
        0x0010:  34a9 4ccb c131 06a4 00fb c605 01d9 6700  4.L..1........g.
        0x0020:  0000 024b 0803 0571 7b22 7278 706b 223a  ...K...q{"rxpk":
        0x0030:  5b7b 2274 6d73 7422 3a39 3938 3937 3935  [{"tmst":9989795
        0x0040:  3438 2c22 7469 6d65 223a 2232 3031 372d  48,"time":"2017-
        0x0050:  3031 2d32 3754 3130 3a30 343a 3530 2e34  01-27T10:04:50.4
        0x0060:  3335 3131 315a 222c 2263 6861 6e22 3a30  35111Z","chan":0
        0x0070:  2c22 7266 6368 223a 312c 2266 7265 7122  ,"rfch":1,"freq"
        0x0080:  3a38 3638 2e31 3030 3030 302c 2273 7461  :868.100000,"sta
        0x0090:  7422 3a31 2c22 6d6f 6475 223a 224c 4f52  t":1,"modu":"LOR
        0x00a0:  4122 2c22 6461 7472 223a 2253 4638 4257  A","datr":"SF8BW
        0x00b0:  3132 3522 2c22 636f 6472 223a 2234 2f35  125","codr":"4/5
        0x00c0:  222c 226c 736e 7222 3a31 312e 382c 2272  ","lsnr":11.8,"r
        0x00d0:  7373 6922 3a2d 3335 2c22 7369 7a65 223a  ssi":-35,"size":
        0x00e0:  3233 2c22 6461 7461 223a 2241 4730 7a41  23,"data":"AG0zA
        0x00f0:  5042 2b31 624e 774c 6439 376a 746d 5761  PB+1bNwLd97jtmWa
        0x0100:  5144 675a 3552 3932 4e77 3d22 7d5d 7d    QDgZ5R92Nw="}]}
11:04:51.254810 IP 52.169.76.203.1700 > 31.157.192.137.49457: UDP, length 4
        0x0000:  4500 0020 b229 4000 2c11 3b09 34a9 4ccb  E....)@.,.;.4.L.
        0x0010:  1f9d c089 06a4 c131 000c 6d8b 01d9 6701  .......1..m...g.
11:04:55.914887 IP 52.169.76.203.1700 > 31.157.192.137.44731: UDP, length 198
        0x0000:  4500 00e2 b68a 4000 2c11 35e6 34a9 4ccb  E.....@.,.5.4.L.
        0x0010:  1f9d c089 06a4 aebb 00ce a1a4 0100 0003  ................
        0x0020:  7b22 7478 706b 223a 7b22 696d 6d65 223a  {"txpk":{"imme":
        0x0030:  6661 6c73 652c 2274 6d73 7422 3a31 3030  false,"tmst":100
        0x0040:  3339 3739 3534 382c 2266 7265 7122 3a38  3979548,"freq":8
        0x0050:  3638 2e31 2c22 7266 6368 223a 302c 2270  68.1,"rfch":0,"p
        0x0060:  6f77 6522 3a31 342c 226d 6f64 7522 3a22  owe":14,"modu":"
        0x0070:  4c4f 5241 222c 2264 6174 7222 3a22 5346  LORA","datr":"SF
        0x0080:  3842 5731 3235 222c 2263 6f64 7222 3a22  8BW125","codr":"
        0x0090:  342f 3522 2c22 6970 6f6c 223a 7472 7565  4/5","ipol":true
        0x00a0:  2c22 7369 7a65 223a 3333 2c22 6461 7461  ,"size":33,"data
        0x00b0:  223a 2249 4779 6469 494b 5073 6b77 3064  ":"IGydiIKPskw0d
        0x00c0:  5230 7654 4234 686e 3463 4f48 6462 6b64  R0vTB4hn4cOHdbkd
        0x00d0:  5967 622f 4458 6874 2f6c 4872 4f79 4222  Ygb/DXht/lHrOyB"
        0x00e0:  7d7d                                     }}

With regard to my log, I can definitely say:

  • “tmst_rxpk”=998979548 us / “tmst_txpk”=1003979548 us (difference = 5 sec, so TTN tell the gateway to send the downlink packet 5 sec after the received uplink)

  • “time_rxpk”=11:04:50.435723 / “time_txpk”=11:04:55.914887 (difference = 5.479164 sec, so the downlink message arrives later than the time scheduled by TTN for sending message back to end-node).

51

…but you’re not using Class B devices, right? (TTN does not support that anyhow.)

For a node it will be set AFTER a successful OTAA Join, as the Join Accept then includes those values and the node will configure those. However, for the Join Accept itself, TTN will use the standard, being 869.525 MHz / DR0 (SF12, 125 kHz). So, even if regular downlinks do not work, the Join Accept should. (And it does, for some time after you restart the gateway. So if the node uses the right channels, then the gateway must do so too?)

I find the findings about radio configuration in the Kerlink interesting, but not my cup of tea so I have no answers to that. But remember that after a restart your gateway is surely sending the OTAA Join Accept and the node surely receives it. And for subsequent downlinks we’ve seen that for you (@salvatore_forte), the packets arrive at your gateway too late to be received by a node (if even sent by the gateway when being too late anyhow). So I doubt there is also a problem in the channel configurations… (I’d guess you’re misinterpreting the gateway’s configuration.)

If anyone else is facing the same problem, but with downlinks arriving at the gateway in time: any chance that after the first OTAA Join Accepts/downlinks the gateway’s radios are configured differently, or are left in some weird state…? And: how many nodes can join after a restart of the gateway?

When referring to YFcXASYAZgsBhXqnvWHkCvDmQ9TGZf+7fZssOUg=, that is an unconfirmed data down. It’s not a Join Accept, like mine was.

52

Your above Base64-encoded txpk packet of IGydiIKPskw0dR0vTB4hn4cOHdbkdYgb/DXht/lHrOyB indeed is 33 bytes, but it is a Join Accept. Your log above does not show if the gateway sent anything back to the server to acknowledge whether or not it forwarded it.

In my explanation of “Line E” above, I was referring to the size of txpk_ack acknowledgement packets, which in my logs are not Base64 encoded but plain readable JSON. These packets are sent from gateway to server, so can simply use JSON as they have no size limit; the Base64 txpk is sent from server to node (via the gateway) and is binary-encoded according to the LoRaWAN specifications, to save bandwidth.

53

You are right so far.

No, both are set to receive data from nodes if you are using the TTN configuration. One will also be used to transmit.

Your gateway will be able to send at any frequency requested by TTN. You do not configure the transmit frequencies in the json files.

Wrong assumption.

Again, the transmit frequencies are not specified in the global_conf.json file.

As I stated before, the cause of you issues is timing. You are only confusing yourself by looking elsewhere. Again, the information you posted clearly shows the data to transmit is received at the gateway after it should have been transmitted. As such the node will never receive it. To solve you issue you need to find why the network connection is ‘slow’ or why its speed varies over time.
One thing you could try is to start a ‘ping www.google.com’ on the gateway and look at the times response time for the ping packets.

1 Like
54

If you use tcpdump you can easily find this. Look at the tmst values of the packet going to TTN and the return packet. If the difference is 1000000 (normal downlink) or 5000000 (join accept) the data is for RX1. If the difference is 2000000 (normal downlink) or 6000000 (join accept) the packet is for RX2.
Also, if the "freq"uency is set to 869.525 the response is for RX2.

55

A great many thanks Kersing !

I am not testing the OTAA join accepts as salvatore_forte does. I am merely investigating if überhaupt our Dragino lora node receives normal data back from TTN.
And indeed, it receives the payload back from TTN when I use the ttn send node in nodejs to resend the same payload back (“hello from lora”).
Secondly, all receptions are in the second receive windows on the 869.525 Mhz SF9BW125 and not in the first receive window. Differences in tmst showed indeed this as you explained. We programmed the node for RX2 permanently.

This opens doors for further research …

56

I did what you advised, running a ping to ‘www.google.com’ on gateway. The response time is very slow (avg=450 ms).

64 bytes from 216.58.212.164: seq=47 ttl=47 time=417.250 ms
64 bytes from 216.58.212.164: seq=48 ttl=47 time=676.519 ms
64 bytes from 216.58.212.164: seq=49 ttl=47 time=456.166 ms
64 bytes from 216.58.212.164: seq=50 ttl=47 time=415.243 ms
64 bytes from 216.58.212.164: seq=51 ttl=47 time=434.571 ms
64 bytes from 216.58.212.164: seq=52 ttl=47 time=413.974 ms
^C
--- 216.58.212.164 ping statistics ---
53 packets transmitted, 53 packets received, 0% packet loss
round-trip min/avg/max = 397.838/440.910/676.519 ms

Since, as @arjanvanb has recalled more than once, at the startup of the gateway I can activate my device with OTAA most of time, I also tried to run a ping in this situation, and the response time in this latter case looks reasonable:

64 bytes from 216.58.212.164: seq=84 ttl=47 time=83.362 ms
64 bytes from 216.58.212.164: seq=85 ttl=47 time=82.625 ms
64 bytes from 216.58.212.164: seq=86 ttl=47 time=81.899 ms
64 bytes from 216.58.212.164: seq=87 ttl=47 time=81.176 ms
^C
--- 216.58.212.164 ping statistics ---
89 packets transmitted, 88 packets received, 1% packet loss
round-trip min/avg/max = 65.290/85.200/104.836 ms

If I simply kill the ping and run it back once again I can see things going as slow as shown before (with avg_response to ping of 450 ms). It’s really frustrating since I can’t find out a reasonable explanation to this behavior. I wrote to Kerlink but an asnwer is yet to come.

1 Like
57

Given the behavior you are noticing I would suggest you contact you mobile internet provider and ask them what could be causing this. As far as I know people are using Kerlink gateways successfully on mobile networks in other countries.

58

I was wondering, could the sim card itself be the problem? Should I use a sim card specifically thought for M2M/IoT applications? The one that I am currently using is provided by Vodafone, with standard voice and 3G data traffic enabled (the same one I would use with a smartphone).

59

I don’t know if another SIM would be more appropriate. It depends on the offering of Vodafone in your country. Why not give them a call?

60

Hi all,

quick update about the downlink problem I was facing over 3G connection. I moved my application, gateway and nodes on Loriot and I got some benefit. First of all, I am able to activate my device through OTAA with no restriction at all. The JOIN_ACCEPT always reaches the concentrator after few seconds a request has been sent to the server. Moving forward, with regard to normal downlink, I have noticed that not all packets can reach the node before the second listen windows has been closed, so many packets get lost. Few questions I would like to ask are:

  • Class A devices are supposed to open 2 receive windows (with a delay of 1 sec and 2 sec respectively) after the end of the transmission. In my case, the downlink packets are always received in the RX2 windows and transmitted over the frequency 869.525 MHz. Is the server making the decision of which channel and RX window has to be used?

  • If this is the case, the timestamp that I can see in the downlink packet is set by the server and based on the timestamp of the uplink packet? If the hwclock of the gateway is not sync with server, could this generate a problem?

Your feedback is very welcome!

61

Maybe Loriot sends the response a lot earlier than TTN. I imagine there may be several reasons why TTN is sending instructions to gateways as late as possible:

  • It allows TTN to choose another gateway as late as possible, or change the RX window to allow more urgent responses for other nodes to be sent.
  • It allows TTN to drop responses and downlinks for nodes that have exceeded the (future) fair access policy, in favor of responding to nodes that have used less air time.
  • Maybe TTN assumes that gateways do not implement a queue of packets to be transmitted? (And that is probably true for most gateways, as gateways are often referred to as “packet forwarders”.) By only sending the packets to the gateway when they are about to be transmitted, TTN can still add newer responses for other nodes, that are to be sent earlier. (Like: a Join Accept is to be sent after either 5 or 6 seconds, while a regular downlink is to be sent after 1 or 2 seconds. If no queue is implemented then the gateway could not be used for any other transmissions between receiving the Join Accept and actually transmitting it.) I’m just assuming things here.

If Loriot is sending responses much earlier than TTN, then that might solve your problem now, but might be troublesome when the network usage increases. Again: I’m just guessing here.

So: with Loriot, how soon exactly do you receive responses on the gateway?

 

Yes, of course limited by the specification: for the OTAA Join Accept itself these are fixed. One should surely not set any specific RX2 channel before performing the OTAA Join.

After OTAA, in the configuration as sent in the Join Accept, TTN tells the nodes which channel and spreading factor is used for RX2. (That only applies to regular downlinks.) For ABP one needs to configure that manually, for OTAA one should not.

Yes, but like Kersing explained earlier: relative to the tmst value in the request:

That said, if OTAA is working then problems with regular downlinks are not in scope of this topic, I feel.

62

I feel like might be valuable for anyone has followed this discussion since the first place to get some news about the downlink issue experienced with both ABP and OTAA (the join response is basically a downlink packet as well). I have found out that if a ping to the DNS server is executed in background continuously, the network link is fast enough to get downlink packets on due time at the end-node. I have managed to run tests for both OTAA join procedure and ABP standard downlink, and the result is consistent. However, this is just a workaround and I don’t want to believe that the cellular connection feature was supposed to work in this way.

In the ‘knetd.xml’ I have changed the ‘link_timeout’ and ‘ip_link’ parameters as below:

<!--frequency of connection monitoring -ping- (in seconds) -->
<CONNECT link_timetout="3"/>
<!-- DNS servers will be pinged if commented or deleted. Some operators can block the ping on there DNS servers -->
<CONNECT ip_link="8.8.8.8"/>

Also, in ‘network’ I decided no to use peerdns by switching the GPRSDNS parameter to false.

# Update /etc/resolv.conf to get dns facilities
GPRSDNS=no
# PAP authentication
GPRSUSER=
GPRSPASSWORD=

I would like to know if the changes I have made are equivalent to a basic ‘ping 8.8.8.8’ command manually launched from the shell. I hope you can give me support on this matter.

1 Like
63

I was also having a timing issue with my 3G connected gateway. Unable to join via OTAA, I could see the accept packet arrive at the gateway, from TTN, but it was too late for the node to receive it.
After manually adding a ping to the gateway this solved the issue
Thanks for the post

64

Hi guys,
from this thread I didn’t understand if the issue was somehow resolved but today I am experiencing the problem for the first time since I have set-up IMST gateway. After first OTAA join accepted on RN2483 (fw 1.0.3) I was happy and considered done. Today I powered up the modem again and after mac join otaa just received “denied”. After sys factoryRESET and set appeui and appkey, join was accepted.
Is this standard behavior with OTAA ?