Rak811 node in JoinAccept/JoinRequest loop

I have a rak2245 gateway and a rak811 wisnode.

When I issue an at+join=otaa command the node never gets activated, although I see no errors in the logs.

I never receive a Join status success (as per the manual) at+recv=3,0,0

Here is one of the JoinAccept/JoinRequest pair:

Could anyone help me figure out what is wrong?
Please let me know what information I should provide to help debug this.

thank you.

Hi @steven1

What exactly is the problem. From the screenshot it seems like the node has successfully connected via OTAA. What exactly do you want to do?
Which manual are you referring to?

Regards
Vladislav

Hi there,

The problem is that the node never gets activated. It goes into a loop of JoinRequest/JoinAccept pair of messages and never finishes properly. The device shows “This device has not (yet) been activated.” in its Activation tab on the web interface. Actually, if you notice on the serial communication, an “OK” is issued in response to “at+join=otaa”, but it should also send “at+recv=3,0,0” (3 = STATUS_JOINED_SUCCESS), which I believe confirms joining.

Instead, after 8 minutes of trying I receive: “at+recv=6,0,0” (6 = STATUS_RX2_TIMEOUT) instead (this is not shown in the screenshot I posted earlier). Dureing those 8 mins, no AT commands can be send to the node (it isn’t responding, as it is waiting for the resulting at+recv message).

I am referring to Join-Otaa example of the RAK811 Lora AT Command User Guide V1.5 on page 31.

Any ideas/help would be most welcome on how to activate the node OTAA properly.

Hmm, are you sure you have the MSB, LSB, formating of the keys right. Loraserver is different than TTN. I just flashed anode to make sure and it had no issues. True I got no response on join but I was able to send packets without problems. Could you double check the keys.

I just swapped the app_key’s endianess and sent it via set_config and now loraserver generates a processing uplink frame error: “join-request to join-server error: response error, code: MICFailed, description: invalid mic”. If I send it as I had it the server accepts it.

Which firmware did you f;ash your node with? Are you able to get it “activated” ?
I see now that I receive an “at+recv=3,0,0” after roughly 4-5 minutes, but the device is still not activated on the web ui of the lora server.

Same as yours, but I use TTN. I have had this issue with other nodes from other manufacturers before too.
Just to make sure, do you receive repetitive join requests or 1 join request and 1 join ack and you are still not connected?

I receive many JoinRequests and JoinAccept messages for the entire duration until an at+recv=X,0,0 response shows up in the serial console. I actually moved the devices around and switched off some equipment in proximity and the node managed to activate once.

Yet, when I retry to at+join=otaa again it still takes several minutes for the OTAA negotiation and it can be unsuccessful. Is that like a normal timeframe and behavior?

The gateway and node are around 50 meters apart within a building. Should I expect faster and more robust comms, or is this typical?

That is so strange, not normal behavior at all. If you receive an accept you should be good. Got to think about it. Will get back on you.

you might send “at+get_config=ch_mask”,Check to see if the open channel is correct.

Here is the ch_mask setting:

# SEND ASCII>
at+get_config=ch_mask

# RECV ASCII>
OK
0,0007

Tried the ch_list also:

at+get_config=ch_list

# RECV ASCII>
OK
0,on,868100000,0,5;1,on,868300000,0,5;2,on,868500000,0,5;3,off;4,off;5,off;6,off;7,off;8,off;9,off;10,off;11,off;12,off;13,off;14,off;15,off

Are you sure the antenna connected to the gateway and node is 868 band? And he is that kind of model, is it convenient to take photos?

Are there any barriers between the gateway and the nodes?

I bought the EU868 RAK Wireless Gateway Discover Kit that included everything I use (https://bit.ly/2YFrY70).

So I believe that everything is operating at the right band. The gateway:

Is it ok to use it like this?
The node is equivalently used at its default config (its included antenna has a sticker writing 868 Mhz) as in the product picture.

I am testing inside a building and sure there are walls and doors, but building materials are normal concrete/bricks; it should work at a range of 30-50 meters right?

Hi @steven1,

It should indeed work through the walls, even outside a couple of hundred meters outside of the building at least. I Believe the issue is not in the hardware as you get the join accept, right ?
Have you tried ABP, or TTN, just so we know if the issue is only in the case of LoRa Server OTTA?

Regards
Vladislav

Yes, you said earlier that you did connect successfully. Can you connect the information sent by the server at the moment of your successful connection?

董巷
Mobile: +86 18146804729|E-mail:[email protected]| QQ1165798730

深圳市瑞科慧联科技有限公司 Shenzhen RAKwireless Technology Co.,Ltd.
深圳市南山区桃源街道平山一路新视艺创客公园B栋506室
Website: www.rakwireless.com | 微信公众号/官方微博:RAK瑞科慧联
Twitter: @RAKwireless | YouTube:RAK YouTube Channel

I managed to find something in the logs (at 22:41). That is the only instance where a successful negotiation has been established, but I don’t quite remember what I was doing at that moment.

May 23 22:40:06 gw lora-gateway-bridge[541]: time="2019-05-23T22:40:06+01:00" level=info msg="integration/mqtt: publishing event" event=stats qos=0 topic=gateway/b827XXXXXXXXXXXX/event/stats
May 23 22:40:06 gw loraserver[537]: time="2019-05-23T22:40:06+01:00" level=info msg="gateway/mqtt: gateway stats packet received" gateway_id=b827XXXXXXXXXXXX
May 23 22:40:06 gw loraserver[537]: time="2019-05-23T22:40:06+01:00" level=info msg="gateway updated" gateway_id=b827XXXXXXXXXXXX
May 23 22:40:06 gw loraserver[537]: time="2019-05-23T22:40:06+01:00" level=info msg="metrics saved" aggregation="[MINUTE HOUR DAY MONTH]" name="gw:b827XXXXXXXXXXXX"
May 23 22:40:29 gw loraserver[537]: time="2019-05-23T22:40:29+01:00" level=info msg="finished unary call with code OK" grpc.code=OK grpc.method=GetDevice grpc.service=ns.NetworkServerService grpc.start_time="2019-05-23T22:40:29+01:00" grpc.time_ms=2.645 peer.address="[::1]:48496" span.kind=server system=grpc
May 23 22:40:29 gw loraserver[537]: time="2019-05-23T22:40:29+01:00" level=info msg="finished unary call with code OK" grpc.code=OK grpc.method=GetDeviceProfile grpc.service=ns.NetworkServerService grpc.start_time="2019-05-23T22:40:29+01:00" grpc.time_ms=1.93 peer.address="[::1]:48496" span.kind=server system=grpc
May 23 22:40:36 gw lora-gateway-bridge[541]: time="2019-05-23T22:40:36+01:00" level=info msg="integration/mqtt: publishing event" event=stats qos=0 topic=gateway/b827XXXXXXXXXXXX/event/stats
May 23 22:40:36 gw loraserver[537]: time="2019-05-23T22:40:36+01:00" level=info msg="gateway/mqtt: gateway stats packet received" gateway_id=b827XXXXXXXXXXXX
May 23 22:40:36 gw loraserver[537]: time="2019-05-23T22:40:36+01:00" level=info msg="gateway updated" gateway_id=b827XXXXXXXXXXXX
May 23 22:40:36 gw loraserver[537]: time="2019-05-23T22:40:36+01:00" level=info msg="metrics saved" aggregation="[MINUTE HOUR DAY MONTH]" name="gw:b827XXXXXXXXXXXX"
May 23 22:40:53 gw lora-gateway-bridge[541]: time="2019-05-23T22:40:53+01:00" level=info msg="integration/mqtt: publishing event" event=up qos=0 topic=gateway/b827XXXXXXXXXXXX/event/up
May 23 22:40:53 gw lora-gateway-bridge[541]: time="2019-05-23T22:40:53+01:00" level=info msg="integration/mqtt: publishing event" event=up qos=0 topic=gateway/b827XXXXXXXXXXXX/event/up
May 23 22:40:53 gw loraserver[537]: time="2019-05-23T22:40:53+01:00" level=info msg="gateway/mqtt: uplink frame received"
May 23 22:40:53 gw loraserver[537]: time="2019-05-23T22:40:53+01:00" level=info msg="gateway/mqtt: uplink frame received"
May 23 22:40:53 gw loraserver[537]: time="2019-05-23T22:40:53+01:00" level=info msg="finished streaming call with code OK" grpc.code=OK grpc.method=StreamFrameLogsForDevice grpc.service=ns.NetworkServerService grpc.start_time="2019-05-23T22:36:34+01:00" grpc.time_ms=258956.6 peer.address="[::1]:48496" span.kind=server system=grpc
May 23 22:40:53 gw loraserver[537]: time="2019-05-23T22:40:53+01:00" level=warning msg="creating insecure application-server client" server="localhost:8001"
May 23 22:40:53 gw loraserver[537]: time="2019-05-23T22:40:53+01:00" level=info msg="rx info sent to network-controller" dev_eui=3238YYYYYYYYYYYY
May 23 22:40:53 gw loraserver[537]: time="2019-05-23T22:40:53+01:00" level=info msg="device gateway rx-info meta-data saved" dev_eui=3238YYYYYYYYYYYY
May 23 22:40:53 gw loraserver[537]: time="2019-05-23T22:40:53+01:00" level=info msg="device-session saved" dev_addr=0063xxxx dev_eui=3238YYYYYYYYYYYY
May 23 22:40:53 gw loraserver[537]: time="2019-05-23T22:40:53+01:00" level=info msg="finished client unary call" grpc.code=OK grpc.method=HandleUplinkData grpc.service=as.ApplicationServerService grpc.time_ms=56.542 span.kind=client system=grpc
May 23 22:40:53 gw loraserver[537]: time="2019-05-23T22:40:53+01:00" level=info msg="adr request added to mac-command queue" dev_eui=3238YYYYYYYYYYYY dr=0 nb_trans=1 req_dr=0 req_nb_trans=1 req_tx_power_idx=7 tx_power=0
May 23 22:40:53 gw loraserver[537]: time="2019-05-23T22:40:53+01:00" level=info msg="pending mac-command block set" cid=LinkADRReq commands=1 dev_eui=3238YYYYYYYYYYYY
May 23 22:40:53 gw loraserver[537]: time="2019-05-23T22:40:53+01:00" level=info msg="gateway/mqtt: publishing gateway command" command=down gateway_id=b827XXXXXXXXXXXX qos=0 topic=gateway/b827XXXXXXXXXXXX/command/down
May 23 22:40:53 gw lora-gateway-bridge[541]: time="2019-05-23T22:40:53+01:00" level=info msg="integration/mqtt: downlink frame received" topic=gateway/b827XXXXXXXXXXXX/command/down
May 23 22:40:53 gw lora-gateway-bridge[541]: time="2019-05-23T22:40:53+01:00" level=info msg="integration/mqtt: publishing event" event=ack qos=0 topic=gateway/b827XXXXXXXXXXXX/event/ack
May 23 22:40:53 gw loraserver[537]: time="2019-05-23T22:40:53+01:00" level=info msg="device-session saved" dev_addr=0063xxxx dev_eui=3238YYYYYYYYYYYY
May 23 22:40:53 gw loraserver[537]: time="2019-05-23T22:40:53+01:00" level=info msg="backend/gateway: downlink tx acknowledgement received" gateway_id=b827XXXXXXXXXXXX
May 23 22:40:53 gw loraserver[537]: time="2019-05-23T22:40:53+01:00" level=info msg="downlink-frames saved" dev_eui=3238YYYYYYYYYYYY token=37190

A larger log, with more context can be found here:
https://drive.google.com/open?id=1Qg6O8HLHeH8Xqmkeq82I38L3aENS56ly

If you have any further ideas, I’d be glad to try. Thank you.

Hi @steven1,

What about logs for the unsuccessful ones.
By the way have you verified all of the LoRa Server Setings, The gateway and device profiles. LoRaWAN 1.0.2, Class A, etc.
Can you post your configuration parameters for both the LoRa Server and Node in detail?
Thank you.

Regards
Vladislav

If you have modified the configuration as shown in the figure, and you can see from the logo that you have successfully connected, then do you try to send data through the node?

I have done minor modifications on the default configs of loraserver 3, but I just reverted all configs to defaults. Still the same problem, join request/accept loop.
Can someone at least confirm the firmware and Wisnode versions that are known to work? As I already wrote Wisnode is v1.2 and its loaded firmware: v2.0.3.4.
Should I try to load another firmware?

Is there some sort of delay I should add to the loraserver to make it work?

Is there any documentation at all on what a successful negotiation looks like? A sample log of the kit working properly?

Yes, I have something like this on this page: localhost:8000

I had it as 127.0.0.1 also, same behavior.