Unable to join TTN


(Omerdekel) #1

I have a MultiTech Conduit AEP.
Im trying to get a RN2903 to connect and transmit to TTN

I tried to restart the TTN packet forwarder and the lora server.
What I see is that some of the packets do get passed on to TTN; however the Join command doesnt.

Somehow, earlier, it worked once. do not know how ro reproduce.

#### 2017-07-26 21:50:50 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 5
# CRC_OK: 60.00%, CRC_FAIL: 40.00%, NO_CRC: 0.00%
# RF packets forwarded: 3 (69 bytes)
# PUSH_DATA datagrams sent: 0 (0 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 0 (0.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
### BEACON IS DISABLED! 
### [JIT] ###
# INFO: JIT queue contains 0 packets.
# INFO: JIT queue contains 0 beacons.
### GPS IS DISABLED! 
### [PERFORMANCE] ###
# Upstream radio packet quality: 60.00%.
# Semtech status report send. 
##### END #####
INFO: [status] TTN send status success
INFO: [down] TTN received downlink with payload
INFO: [TTN] downlink 17 bytes
a7.46.66.e.d0.7b.eb.b.0.9a.11.12.0.8.0.0.20.a9.9.25.1f.b.3c.27.48.dc.4e.ad.3e.69.dc.a5.ac.end
lgw_receive:1165: FIFO content: 4 ab 2 7 17
lgw_receive:1184: [0 17]
Note: LoRa packet
lgw_receive:1165: FIFO content: 3 f9 2 5 17
lgw_receive:1184: [6 17]
Note: LoRa packet
lgw_receive:1165: FIFO content: 2 20 3 5 17
lgw_receive:1184: [2 17]
Note: LoRa packet
lgw_receive:1165: FIFO content: 1 d2 2 5 17
lgw_receive:1184: [3 17]
Note: LoRa packet
INFO: tx_start_delay=1497 (1497.000000) - (1497, bw_delay=0.000000, notch_delay=0.000000)
INFO: [up] TTN lora packet send to server "bridge.us-west.thethings.network"
INFO: [up] TTN lora packet send to server "bridge.us-west.thethings.network"
INFO: [up] TTN lora packet send to server "bridge.us-west.thethings.network"

Sending: mac set pwridx 5
Sending: mac set retx 7
Sending: mac set dr 3
Sending: mac join otaa 
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa 
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa 
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa 
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa 
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa 
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac join otaa 
Join not accepted: denied
Check your coverage, keys and backend status.
Sending: mac tx uncnf 3 01880618DEF4878D0003E8
Response is not OK: not_joined
Send command failed
1

Unable to Join TTN: devAddr is not the same in the console and in the Join Accept
(Jac Kersing) #2

To debug, open the console and go to your gateway, then go to "Gateway Traffic". Now try to join the RN2903. Do you see join requests in the console?

The log shows there are packets being sent to TTN so you should see some data in the console. If your join requests are not in the console, make sure your node is within radio reach of the gateway but not too close to it (keep at least 8 feet distance between antennas for reliable communications)


(Omerdekel) #3

Hi,
Thanks for the prompt response.
In the TTN gateway console I cannot see any traffic, however, I do see a data coming in the application data (see below the metadata - shouldn't the frequency be int he 915 range ?)
any ideas ?

{
  "time": "2017-07-26T23:57:05.127544209Z",
  "frequency": 903.9,
  "modulation": "LORA",
  "data_rate": "SF10BW125",
  "coding_rate": "4/5",
  "gateways": [
    {
      "gtw_id": "dox1",
      "gtw_trusted": true,
      "timestamp": 3593224372,
      "time": "2017-07-26T23:58:13Z",
      "channel": 0,
      "rssi": -99,
      "snr": -12.75
    }
  ]
}

(Arjan) #4

I'm afraid we need more details.

If you cannot see gateway traffic in TTN Console, then peek in the log from the gateway itself.

If your application is receiving uplinks from your node, then it has joined earlier and still knows its OTAA secrets. Then why would it even try to join again?

Also, is "gtw_id": "dox1" your gateway?


(Jac Kersing) #5

If you are not seeing the traffic in the gateway console and data is visible in the application the first question would be: Is the gateway that is receiving the data my gateway? Looking at the metadata of your packet the forwarding gateway is 'dox1'. Is that your gateway?

With regards to the frequency: The band is called the 915 band but that stretches from 902MHz to 928MHz. The used frequency is the first channel of subband 2 (starting at 902.3MHz with 200KHz increments, bands are 8 channels) which is what TTN is using, so perfect.


(Omerdekel) #6

Hi,
Yes - Dox1 is the gateway.
ill try to take a look at the logs again.


(Omerdekel) #7

Dox1 is my gateways.
ill try to reinstall the TTN packet forwarder and redefine the GW and app in TTN.


(Jac Kersing) #8

There is no need to reinstall the software as it seems to be working fine. Check the log file to see if any data is being sent.


(Arjan) #9

As an aside, this line:

…is a Join Accept. Comparing these bytes to some generic gateway code from:

…gets one:

                            1                        2                         3
 0  1  2 3  4  5  6 7 8  9  0  1 2 3 4 5  6  7 8  9  0 1 2 3 4  5  6  7  8  9  0  1  2  3
a7.46.66.e.d0.7b.eb.b.0.9a.11.12.0.8.0.0.20.a9.9.25.1f.b.3c.27.48.dc.4e.ad.3e.69.dc.a5.ac
                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  • 0…2 = TX PLL frequency
  • 3…6 = 0x0ed07beb = something related to timestamp
  • 9 = 0x9a = 0x0a | 0x80 | 0x10 = DR_LORA_SF10 with CR_LORA_4_5 and CRC enabled
  • 10 = 0x11 = data size = 17 bytes
  • 8, 14, 15 = 0x00 = not used
  • 16…33 = 0x20a909251f0b3c2748dc4ead3e69dca5ac = 17 bytes downlink

Those 17 bytes of downlink data are a Join Accept:

Message Type = Join Accept

In your application in TTN Console you should be able to tell if that DevAddr is indeed assigned to your node. Unfortunately, you need some more details to get the DevAddr from that downlink.


Most OTAA join request fail to downlink confirmation to node
(Omerdekel) #10

Hi,
I removed my GW and application from TTN and recreated them.
Problem solved :slight_smile: