Multi-tech conduit OTAA joinRequest is ok, but joinAccept not received by node

Happy to contribute my new Multi-tech Conduit to TTN for Breda, NL region, however I am having some issues receiving JoinAccept messages for OTAA on my mDot. I am using https://developer.mbed.org/teams/MultiTech/code/mDot_LoRa_Connect_Example_APP_EUI_KEY/ as an app starting point.

JoinRequest message is received by Conduit and forwarded to TTN router. UDP trail:

Gateway -> TTN (tcpdump udp port 1700)

{“rxpk”:[{“tmst”:62277212,“time”:“2016-05-31T11:30:23.882173Z”,“chan”:2,“rfch”:1,“freq”:868.500000,“stat”:1,“modu”:“LORA”,“datr”:“SF12BW125”,“codr”:“4/5”,“lsnr”:7.0,“rssi”:-24,“size”:23,“data”:“AI4CANB+1bNw16EAAAAAgABDb1JC5h0=”}]}

MQTT tail on activations shows positive join result:

{“metadata”:[{“frequency”:868.5,“datarate”:“SF12BW125”,“codingrate”:“4/5”,“gateway_timestamp”:62277212,“gateway_time”:“2016-05-31T11:30:23.882173Z”,“channel”:2,“server_time”:“2016-05-31T11:30:23.896219693Z”,“rssi”:-24,“lsnr”:7,“rfchain”:1,“crc”:1,“modulation”:“LORA”,“gateway_eui”:“008000000000AA51”,“altitude”:-1,“longitude”:4.79033,“latitude”:51.588}]}

Gateway <- TTN shows correct frequency (869.525) which is RX2 and is according to LoRaWAN 1.0 spec as far as I can see:

{“txpk”:{“codr”:“4/5”,“data”:“IGGX1ABpLwLzD492GiAL10pC+Wik1xI+y0K5Li88Kaco”,“freq”:869.525,“ipol”:true,“modu”:“LORA”,“powe”:27,“rfch”:0,“size”:33,“tmst”:68277212,“datr”:“SF9BW125”}}

However, the message never reaches my mDot (note this trail does not belong to the UDP one shown above):
[TRACE] Enable centi band
[TRACE] Initiating join…
[TRACE] Join Network - Auto OTA
[TRACE] Join attempt #16
[DEBUG] Send Join Packet with DR3
[TRACE] Number of enabled channels: 3 Mask: 00ff
[TRACE] Check freq: 0 - 868100000
[TRACE] Preparing frame
[TRACE] FRAME_TYPE_JOIN_REQ
[TRACE] PACKET: 23 bytes
[TRACE] BUFFER: 008e0200d07ed5b370d7a10000000080000891813407b4
[DEBUG] txPower: 11 AntG: 3 radioPower: 11
[INFO] TX Frequency: 868100000 SF: 9 BW: 125 kHz POW: 11 dBm
[DEBUG] Time on air: 23 bytes 205 ms
[DEBUG] Time off air: 20500 ms duty-cycle: 1.0 %
[ERROR] Failed to join network
[ERROR] failed to join network -4:Join Error

More info:

  1. My mDot is shown as activated in the ttnctl. When I use the provisioned keys (NetwSKey, AppSKey) in an ABP config it works fine and allows the mDot to send upstream messages that show up in my MQTT tail. However, not possible to send downlink messages.
  2. I tried both the poly and the latest basic pkt forwarder. Both end up with the same UDP trail as shown above.
  3. I use the latest libmDot
  4. When I use the lora-network-server (that acts as a very rudimentary server component, using an OTAA join procedure based on a out-of-band determined name and password, which are actually transformed into a normal OTAA fields), I am successful with OTA joining as well as receiving downlink messages. (the hardware works)
  5. The concentrator is not giving TX errors.
  6. I tried increasing RX windows and Join windows up to 30 seconds, but to no avail.

Questions:

  1. The Radio frequencies listed in the poly-packet-fwd are different from the ones used in the basic pkt forwarder. Why is that? What is correct?
  2. The second radio channel has value ‘tx_enable’ set to false. No such value exists in the basic pkt forwarder. Given the fact that I am not receiving downlink messages, including the joinAccept message could this have something to to with it since I am getting my joinAccept message delivered at 869.525 Mhz, i.e. not the joinRequest frequency, so my guess the second radio.

My final attempt will be to test with pure AT commands, but waiting for a good old RS232 cable -> USB cable needed for dev board.

1 Like

The frequencies for the poly forwarder are the TTN frequency plan. Those are correct when using TTN backend.

[quote=“jverhoeven, post:1, topic:2318”]2. The second radio channel has value ‘tx_enable’ set to false. No such value exists in the basic pkt forwarder. Given the fact that I am not receiving downlink messages, including the joinAccept message could this have something to to with it since I am getting my joinAccept message delivered at 869.525 Mhz, i.e. not the joinRequest frequency, so my guess the second radio.
[/quote]

You might need to set the frequency and spread factor for receive window 2. Quoting from a message by one of the members of the core team:

Many thanks @kersing for referencing EU RX2 parameters · Issue #155 · TheThingsArchive/ttn · GitHub. Indeed the spec says:

The RX2 receive window uses a fixed frequency and data rate. The default parameters are 15 869.525 MHz / DR0 (SF12, 125 kHz)

and looking back at other UDP trails in my setup they all mention SF9 indeed. I took the liberty to note that this issue should be labeled ‘bug’ since it deviates from the spec. I hope it is picked up soon.