OTAA device stays in Join Request

1

Hello, I’m trying to configure my Cubecell using the OTAA authentication since ABP worked just fine.

I followed the configuration method in https://www.chirpstack.io/application-server/use/devices/#device-provisioning with Generic Arduino LMIC-based devices and the only thing I get is a Join Request, nothing more

imagen
imagen1840×900 102 KB

I’m using the code from the framework arduinoasmicro650x sensor basic example. I believe I configured the keys well I don’t know why it stays in Join Request.

2

check the req’s of key settings LSB or MSB into device. is your device profile for that device turned to OTAA ?

3

The Chirpstack says that the Device EUI field must be entered as LSB and the Application EUI and Application Key in MSB, The device profile is turned to OTAA

https://www.chirpstack.io/application-server/use/devices/#otaa-devices

The cubecell I’m using is the cubecell capsule sensor from heltec.

Here is the Log of the gateway:

Sun Jan 1 00:24:14 2012 daemon.info lora_pkt_fwd[9417]: REPORT~ # RF packets forwarded: 1 (23 bytes)
Sun Jan 1 00:24:14 2012 daemon.info lora_pkt_fwd[9417]: REPORT~ # PUSH_DATA datagrams sent: 1 (242 bytes)
Sun Jan 1 00:24:14 2012 daemon.info lora_pkt_fwd[9417]: REPORT~ # PUSH_DATA acknowledged: 100.00%
Sun Jan 1 00:24:14 2012 daemon.info lora_pkt_fwd[9417]: REPORT~ ### [DOWNSTREAM] ###
Sun Jan 1 00:24:14 2012 daemon.info lora_pkt_fwd[9417]: REPORT~ # PULL_DATA sent: 5 (100.00% acknowledged)
Sun Jan 1 00:24:14 2012 daemon.info lora_pkt_fwd[9417]: REPORT~ # PULL_RESP(onse) datagrams received: 0 (0 bytes)
Sun Jan 1 00:24:14 2012 daemon.info lora_pkt_fwd[9417]: REPORT~ # RF packets sent to concentrator: 0 (0 bytes)
Sun Jan 1 00:24:14 2012 daemon.info lora_pkt_fwd[9417]: REPORT~ # TX errors: 0
Sun Jan 1 00:24:14 2012 daemon.info lora_pkt_fwd[9417]: REPORT~ # TX rejected (collision packet): 0.00% (req:2, rej:0)
Sun Jan 1 00:24:14 2012 daemon.info lora_pkt_fwd[9417]: REPORT~ # TX rejected (collision beacon): 0.00% (req:2, rej:0)
Sun Jan 1 00:24:14 2012 daemon.info lora_pkt_fwd[9417]: REPORT~ # TX rejected (too late): 0.00% (req:2, rej:0)
Sun Jan 1 00:24:14 2012 daemon.info lora_pkt_fwd[9417]: REPORT~ # TX rejected (too early): 0.00% (req:2, rej:0)
Sun Jan 1 00:24:14 2012 daemon.info lora_pkt_fwd[9417]: REPORT~ # BEACON queued: 0
Sun Jan 1 00:24:14 2012 daemon.info lora_pkt_fwd[9417]: REPORT~ # BEACON sent so far: 0
Sun Jan 1 00:24:14 2012 daemon.info lora_pkt_fwd[9417]: REPORT~ # BEACON rejected: 0
Sun Jan 1 00:24:14 2012 daemon.info lora_pkt_fwd[9417]: REPORT~ ### [PPS] ###
Sun Jan 1 00:24:14 2012 daemon.info lora_pkt_fwd[9417]: REPORT~ # SX1301 time (PPS): 662891248

Sun Jan 1 00:24:22 2012 daemon.info lora_pkt_fwd[9417]: RXTX~ {"rxpk":[{"tmst":670615451,"time":"2011-12-31T23:24:22.272603Z","chan":2,"rfch":1,"freq":868.500000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":7.8,"rssi":-28,"size":23,"data":"AAAAAAAAAAAAamXfgcqTa4TG/6Ncc9Y="}]}

Notice the date is wrong because the gateway isn’t connected to internet and can’t update his date.

5 
Mon Aug 3 08:59:49 2020 daemon.info lora_pkt_fwd[1646]: REPORT~ ################## Report at: 2020-08-03 07:59:49 UTC ##################
Mon Aug 3 08:59:49 2020 daemon.info lora_pkt_fwd[1646]: REPORT~ ### [UPSTREAM] ###
Mon Aug 3 08:59:49 2020 daemon.info lora_pkt_fwd[1646]: REPORT~ # RF packets received by concentrator: 3
Mon Aug 3 08:59:49 2020 daemon.info lora_pkt_fwd[1646]: REPORT~ # CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
Mon Aug 3 08:59:49 2020 daemon.info lora_pkt_fwd[1646]: REPORT~ # RF packets forwarded: 3 (69 bytes)
Mon Aug 3 08:59:49 2020 daemon.info lora_pkt_fwd[1646]: REPORT~ # PUSH_DATA datagrams sent: 3 (728 bytes)
Mon Aug 3 08:59:49 2020 daemon.info lora_pkt_fwd[1646]: REPORT~ # PUSH_DATA acknowledged: 100.00%
Mon Aug 3 08:59:49 2020 daemon.info lora_pkt_fwd[1646]: REPORT~ ### [DOWNSTREAM] ###
Mon Aug 3 08:59:49 2020 daemon.info lora_pkt_fwd[1646]: REPORT~ # PULL_DATA sent: 6 (100.00% acknowledged)
Mon Aug 3 08:59:49 2020 daemon.info lora_pkt_fwd[1646]: REPORT~ # PULL_RESP(onse) datagrams received: 0 (0 bytes)
Mon Aug 3 08:59:49 2020 daemon.info lora_pkt_fwd[1646]: REPORT~ # RF packets sent to concentrator: 0 (0 bytes)
Mon Aug 3 08:59:49 2020 daemon.info lora_pkt_fwd[1646]: REPORT~ # TX errors: 0
Mon Aug 3 08:59:49 2020 daemon.info lora_pkt_fwd[1646]: REPORT~ # BEACON queued: 0
Mon Aug 3 08:59:49 2020 daemon.info lora_pkt_fwd[1646]: REPORT~ # BEACON sent so far: 0
Mon Aug 3 08:59:49 2020 daemon.info lora_pkt_fwd[1646]: REPORT~ # BEACON rejected: 0
Mon Aug 3 08:59:49 2020 daemon.info lora_pkt_fwd[1646]: REPORT~ ### [PPS] ###
Mon Aug 3 08:59:49 2020 daemon.info lora_pkt_fwd[1646]: REPORT~ # SX1301 time (PPS): 183340377

Mon Aug 3 09:00:08 2020 daemon.info lora_pkt_fwd[1646]: RXTX~ {"rxpk":[{"tmst":202773667,"time":"2020-08-03T08:00:08.479722Z","chan":1,"rfch":1,"freq":868.300000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":10.0,"rssi":-23,"size":23,"data":"AAAAAAAAAAAAamXfgcqTa4Reohickpc="}]}

I thought it could be the date but no, even with the date fixed the problem of Join Request persist.

6

if device not joins, and you see continious join requests then something wrong in OTAA keys or in DevEUI or all together. try to revert them.

1 Like
7

Well, you are right… I change the DevEUI to MSB format and now it works. Welp, that’s the solution, thank you!

1 Like