My RAK Tracker 7200 ignores join accept from my 7258

Got a weird one. I’ve been prototyping an app using a 7200 tracker with a PiHat acting as my TTN connected gateway repeater. All worked well.

I’ve just today added a brand new 7258 to my gateways on the same account, and when my 7200 tries to OTAA join, all works well, I can see the join request go through, the accept comes back down, goes out from the 7258, but the 7200 ignores it. :frowning:

Latest code on the 7258, and the 7200 is running 3.1.0.11. I made no config change on the 7200. It continues to join the PiHat gateway just fine when I power it up, but it just ignores the response from the 7258. So strange.

Here is some output for you. Redacted some stuff with x’s. :wink:

##7258 Log of Join Request
Mon Apr 20 02:20:34 2020 user.debug lora_pkt_fwd[5328]: INFO: [filter] white list join filter is not enable
Mon Apr 20 02:20:34 2020 user.debug lora_pkt_fwd[5328]: Uplink Frame :
Mon Apr 20 02:20:34 2020 user.debug lora_pkt_fwd[5328]: 00 XX XX XX D0 7E D5 B3
Mon Apr 20 02:20:34 2020 user.debug lora_pkt_fwd[5328]: 70 XX XX XX FE FF A8 C5
Mon Apr 20 02:20:34 2020 user.debug lora_pkt_fwd[5328]: 60 23 1B B1 E1 83 DF
Mon Apr 20 02:20:34 2020 user.debug lora_pkt_fwd[5328]: rrd_statistic_up 359 uplinkTqByAirtime : dr = 5, timeonair = 56, tm = 1587349234
Mon Apr 20 02:20:34 2020 user.debug lora_pkt_fwd[5328]: rrd_statistic_up 361 uplinkTqByPkt : dr = 5, tm = 1587349234
Mon Apr 20 02:20:34 2020 user.debug lora_pkt_fwd[5328]: rrd_statistic_up 363 ChanBusyByAirtime chan 0, timeonair = 56, tm = 1587349234
Mon Apr 20 02:20:34 2020 user.info lora_pkt_fwd[5328]:
JSON up: {“rxpk”:[{“tmst”:1777600811,“chan”:0,“rfch”:0,“freq”:923.200000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:9.0,“rssi”:-18,“size”:23,“data”:“AHSQAtB+1bNwaht2/v+oxWAjG7Hhg98=”}]}

##7258 Packet for Join Request
{
“freq”: 923200000,
“chan”: 0,
“tmst”: 1777600811,
“utmms”: 1587349234645,
“rfch”: 0,
“stat”: 1,
“rssi”: -18,
“size”: 23,
“modu”: “LORA”,
“datr”: “SF7BW125”,
“codr”: “4/5”,
“lsnr”: 9,
“data”: “AHSQAtB+1bNwaht2/v+oxWAjG7Hhg98=”
}

{
    "MHDR": {
        "MType": "Join Request",
        "RFU": 0,
        "Major": 0
    },
    "JoinRequest": {
        "AppEUI": "70 B3 D5 7E D0 XX XX XX ",
        "DevEUI": "60 C5 A8 FF FE XX XX XX ",
        "DevNonce": "1B23"
    },
    "MIC": "DF83E1B1"
}

## TTN Application Device Packet of Join Request
{
“time”: “2020-04-20T02:20:34.838617793Z”,
“frequency”: 923.2,
“modulation”: “LORA”,
“data_rate”: “SF7BW125”,
“coding_rate”: “4/5”,
“gateways”: [
{
“gtw_id”: “eui-60c5a8fffexxxxxx”,
“timestamp”: 1777600811,
“time”: “”,
“channel”: 0,
“rssi”: -18,
“snr”: 9
}
]
}

##7258 Log of Join Accept
Mon Apr 20 02:20:38 2020 user.info lora_pkt_fwd[5328]: INFO: [down] PULL_ACK received in 193 ms
Mon Apr 20 02:20:39 2020 user.info lora_pkt_fwd[5328]: INFO: [down] PULL_RESP received - token[0:17] : )
Mon Apr 20 02:20:39 2020 user.info lora_pkt_fwd[5328]:
JSON down: {“txpk”:{“imme”:false,“tmst”:1783600811,“freq”:923.3,“rfch”:0,“powe”:20,“modu”:“LORA”,“datr”:“SF12BW500”,“codr”:“4/5”,“ipol”:true,“size”:17,“ncrc”:true,“data”:“IG5XQ2oUiwcqICTSvvSTeF4=”}}
Mon Apr 20 02:20:39 2020 user.debug lora_pkt_fwd[5328]: DownLink Frame :
Mon Apr 20 02:20:39 2020 user.debug lora_pkt_fwd[5328]: 20 6E 57 43 6A 14 8B 07
Mon Apr 20 02:20:39 2020 user.debug lora_pkt_fwd[5328]: 2A 20 24 D2 BE F4 93 78
Mon Apr 20 02:20:39 2020 user.debug lora_pkt_fwd[5328]: 5E
Mon Apr 20 02:20:39 2020 user.info lora_pkt_fwd[5328]: INFO: Packet ENQUENUE SUCCESS on sx1301 0

##7258 Packet of Join Accept
{
“freq”: 923300000,
“mode”: “timerstamped”,
“tmst”: 1783600811,
“rfch”: 0,
“powe”: 20,
“prea”: 8,
“ncrc”: true,
“modu”: “LORA”,
“datr”: “SF12BW500”,
“codr”: “4/5”,
“ipol”: true,
“size”: 17,
“data”: “IG5XQ2oUiwcqICTSvvSTeF4=”
}

{
    "MHDR": {
        "MType": "Join Accept",
        "RFU": 0,
        "Major": 0
    },
    "JoinAccept": "6E57436A148B072A2024D2BE",
    "MIC": "F493785E"
}

Yeah, so that’s really weird. Just sits there trying to join, even though I can see the accepts being sent back to it. :frowning:

##7200 Serial Output
at+join
OTAA:
DevEui:60C5A8FFFEXXXXXX
AppEui:70B3D57ED0XXXXXX
AppKey:06A5F5B244F04CAD950BFB3C6BXXXXXX
OTAA Join Start…
OK
[LoRa]:Join retry Cnt:1
[LoRa]:Join retry Cnt:2
[LoRa]:Join retry Cnt:3
[LoRa]:Join retry Cnt:4
[LoRa]:Join retry Cnt:5
[LoRa]:Joined Failed!
Go to Sleep
OK

Ideas?

Can you tell me the frequency band of RAK7258 you use? And your configuration gateway interface, the server you’re using. And the frequency band of RAK7200 configuration??

Nathan,
I had recently something with the same problem statement - the join accept was not send by the gateway. It was a problem of TX power lookup table. See as well No join possible with antenna gain 5. The issue was observable in the log.

Rudi

Rudi, that is a terrible one! I don’t see anything like that in the system log on the web interface (log level set to debug). No idea how to find log like that on the ssh interface for the 7258 either.

Although I did ssh in and verify the antenna_gain value in my global_conf.json was still set at 0, so I am not sure that is the problem I am having.

Hi Nicholas,

Yeah, I am just using the standard AS923 on both devices. The plan matches up perfectly.

On the 7200:
at+get_config=lora:channel

OK

Max_nb_chs=16:

==============LoRaWAN Channel List===============

  • 0,on,923200000,2,5; * 1,on,923400000,2,5; * 2,on,923600000,2,5; * 3,on,923800000,2,5; * 4,on,924000000,2,5; * 5,on,924200000,2,5; * 6,on,924400000,2,5; * 7,on,924600000,2,5;
    8,off,0,0,0; 9,off,0,0,0; 10,off,0,0,0; 11,off,0,0,0; 12,off,0,0,0; 13,off,0,0,0; 14,off,0,0,0; 15,off,0,0,0
    ===================List End======================

at+get_config=lora:status
OK.
==============LoRaWAN Status List================
Work Mode: LoRaWAN
Region: AS923
Send_interval: 480s
Auto send status: true.
Send_interval work at sleep
Join_mode: OTAA
DevEui: 60C5A8FFFEXXXXXX
AppEui: 70B3D57ED0XXXXXX
AppKey: 06A5F5B244F04CAD950BFB3C6BXXXXXX
Class: A
Joined Network:false
IsConfirm: false
AdrEnable: true
EnableRepeaterSupport: false
RX2_CHANNEL_FREQUENCY: 923200000, RX2_CHANNEL_DR:2
RX_WINDOW_DURATION: 3000ms
RECEIVE_DELAY_1: 1000ms
RECEIVE_DELAY_2: 2000ms
JOIN_ACCEPT_DELAY_1: 5000ms
JOIN_ACCEPT_DELAY_2: 6000ms
Current Datarate: 1
Primeval Datarate: 5
ChannelsTxPower: 0
UpLinkCounter: 0
DownLinkCounter: 0
===================List End======================

And over on the 7258, I’ve attached screenshot of the frequency plan which is just imported using the builtin frequency plan template for AS923. Sorry for screenshot, no idea how to find config or logs on the 7258’s ssh terminal.

What is this configuration?


And the configuration diagram to make the frequency band effective.

Hi there,

Yeah, looks good there. Here it is. All stock standard stuff as defined in the regional parameters for AS923 by lora-alliance.org. And I can see that the join accept that comes back does not have the optional CFList inside it, so the 7200 will for sure just be using the standard frequency plan as I pasted before.

I did not mess with anything. Left all the stuff default from the plans that are inside from AS923. No reason to muss with it. :wink:

I can see the join is going up on the standard 923.2, and the accept is coming back on 923.3, which the 7200 should totally be listening on. And it is coming down at SF12, power 20, with the 7200 sitting about a foot away from the 7258. I’m pretty sure it should hear that message.

And like I said, the 7200 has no problem joining the RAK PiHat gateway. Same app, same config.

server address:router.as2.thethings.network
image

OMG YOU ARE A LEGEND!!!

Faceplaming hard enough to make my forehead red right now. I wasted hours on this. But I am so happy I was right in trusting your hardware and doubting my skillz. :stuck_out_tongue:


| ___ / _ \ | | / / | | | () | |
| |
/ / /\ | |/ / | | | | _ __ | | ___ ___ ___
| /| _ || \ | |/| | | ‘
/ _ \ |/ _ / __/ __|
| |\ | | | || |\ \ \ /\ / | | | __/ | /_ _
_| __| |
/_| _/ / /||| _|_|_||//


RAK7200 version:3.1.0.11


========================================================
Please Configurate parameters within 30 seconds …
Configuration OK!
lorasend_interval: 480s
MPU9250 Init OK
GPS Init OK

Selected LoRaWAN 1.0.2 Region: AS923
Initialization OK,Current work_mode:LoRaWAN, join_mode:OTAA, Class: A
gps_timeout: 100s
OTAA Join Start…
[LoRa]:Joined Successed!
Start Search Satellite(about 100 seconds) …

Thank you for your trusting in RAK.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.