search

Lora-net / LoRaMac-node

Reference implementation and documentation of a LoRa network node.
Other
1.88k stars 1.09k forks source link

OTAA, join accept packet cannot received #151

Closed adonislixi closed 7 years ago

adonislixi commented 7 years ago

@mluis1 Hi ~ I use Stm32L072CBTx to run the tag with master branch. The data receiving and sending(ABP mode) is ok. But when I intend to test join procedure, cannot receiving the join accept packet.. My environment : LoraWan server is Loriot, which has been received and sended the accept packet. image

GateWay Log show that I has sended the join accept. image

But, the LoraNode still cannot recveivd the joinAccept .
why....who can help me。

mluis1 commented 7 years ago

When decoding your JoinReq message it looks like that the gateway log isn't in sync with the server log. If we decode the JoinReq base64 message we get the following:

Base64: AAMAfL4DAHy+AAdkDTF10dK9CJX/vA= Hex: 00 03 00 7c be 03 00 7c be 00 07 64 0d 31 75 d1 d2 bd 08 95 ff bc

MType: 0x00 AppEUI: BE7C0003BE7C0003 DevEUI: D2d175310D640700 Nonce: 08BD MIC: xxBCFF95.

I may have wrongly copied the base64 message but it looks like that there is a missing byte in the JoinReq message. The AppEUI looks good but the DevEUI doesn't correspond to the one in the server log.

My advice would be that you verify that all the elements are coherent.

As you said that the timings look good then the other possibility to have the Join procedure failing is that some parameter is wrong. (AppKey, DevEUI, AppEUI)

There is another thing you may try if you have the possibility to debug the code on chip. You may put a break point at line 980 of LoRaMac.c file. When the node receives the JoinAccept the debugger should stop at that line and then you may perform a step by step in order to see why the node refuses the JoinAccept.

adonislixi commented 7 years ago

Hi thx for reply..

I check my code in debug mode , I think the deviceEUI is right, this is my GW log(previously may lost some pices), as below:

JSON up: {"rxpk":[{"tmst":7267988,"chan":5,"rfch":0,"freq":433.500000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":10.3,"rssi":-12,"size":23,"data":"AAMAfL4DAHy+bAAdkDTFl0f7CeIXzvY="}]} INFO: [up] PUSH_ACK received in 50 ms INFO: [down] PULL_RESP received - token[0:0] :)

JSON down: {"txpk":{"tmst":12267988,"freq":433.5,"rfch":0,"powe":14,"modu":"LORA","ipol":true,"datr":"SF7BW125","size":33,"data":"IEk2TVb3KiytULA1ZqOau1boAkfQ6LR33tLa3mszvfBv","imme":false,"codr":"4/5"}} 58.c0.0.0.bb.2b.f8.9.0.97.21.10.0.8.0.0.20.49.36.4d.56.f7.2a.2c.ad.50.b0.35.66.a3.9a.bb.56.e8.2.47.d0.e8.b4.77.de.d2.da.de.6b.33.bd.f0.6f.end

by the way, If the JoinReq's DevieEUI is wrong, the server will not log "send joion accept", as figure show previously。。。。

mluis1 commented 7 years ago

Yes, the new JSON is well formatted now.

So, if I understand well the node does receive the JoinAccept as it stops at the break point isn't it?

Thus, when the message is decrypted does the message content look good? Does the MIC check succeed?

As I said before if the node is receiving the JoinAccept message and the node doesn't accept it then it is most certainly that you have some parameter that is wrong some where.

When the node receives the JoinAccept there is only 2 ways to have the node refuse the message.

  1. The node has already joined the network. Variable is equal to
  2. The MIC check fails for some reason. (May also imply that the decryption didn't work)
adonislixi commented 7 years ago

It does not received the JoinAcept, I don't stop it in the break point。 Actually，I find the Dio0 irq is not triggered。。 So，the node don't go to the “OnRadioRxDone”function，it just not recived the JoniAcept Packet。。。

mluis1 commented 7 years ago

It means then that you still have issues with the timings. The reception window isn't opened at the right time.

You need to verify that your rtc-board.c file is correctly implemented. On another issue (#123) where you have participated, I have proposed an rtc-board.c/h files implementation for the STM32L0 could you please try them on your project if it solves your issue.

Something you can try as well is to try to open the window earlier in time for some more time and see if the JoinAccept is received in those conditions.

I can't do nothing more as I don't have access to your platform. The only thing I can do is provide you some ideas on how to debug. Right now I'm getting out of ideas.

adonislixi commented 7 years ago

thank u for your advices. I am focus on the rtc issues. I find that , in RTC-irq , RTC tmer is not precise , I don't what is wrong..

by the way, I use stm32L072, I use your new rtc code in issue (#123)..

adonislixi@foxmail.com

From: Miguel Luis Date: 2016-10-31 18:10 To: Lora-net/LoRaMac-node CC: adonis lee; Author Subject: Re: [Lora-net/LoRaMac-node] OTAA, join accept packet cannot received (#151) It means then that you still have issues with the timings. The reception window isn't opened at the right time. You need to verify that your rtc-board.c file is correctly implemented. On another issue (#123) where you have participated, I have proposed an rtc-board.c/h files implementation for the STM32L0 could you please try them on your project if it solves your issue. Something you can try as well is to try to open the window earlier in time for some more time and see if the JoinAccept is received in those conditions. I can't do nothing more as I don't have access to your platform. The only thing I can do is provide you some ideas on how to debug. Right now I'm getting out of ideas. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

adonislixi commented 7 years ago

@mluis1 hi~ thank ur help.. I can rrecieved the JoinAccept , by import the issue #114 . However , I found that everytime join succeed the tag retried many times, and used very low DR(DR10 ,DR 11).

I wonder is that I opened the RecvWindow1 too early and preamble was too short ,so I cannot catch preamble, or It's a Hardware problem ?

mluis1 commented 7 years ago

Could you please indicate on which branch your code is based?

So far we are unable to understand your latest issue. Could please provide some more detailed explanation of the issue in such a way that we are able to reproduce it.

ckt1010 commented 7 years ago

Hi @mluis1 , I have same problem as adonislixi. Gateway can get OTAA join accept packet, but node can't. I use stm32l052c8 MCU. I already used your "rtc-board-stm32l051c8.zip" and tested RTC precision is work fine. I notice every time it will fall in to "SX1276OnDio1Irq" function, which means rxtimeout. But I test this rx1 timeout time only have about 25ms then rx2 timeout time have about 134ms. Is this reasonable? And I can't found any setting about this timeout time, did I miss something? Thanks!

adonislixi commented 7 years ago

Hi @ckt1010 it seems that we have same problem. Actually I found my really issue is that hight speed(SF7,8 or 9) packet had a very high loses rate.

The JoinReq default use SF7..

我的数据报文，用SF7, 8 丢包率超级高。SF9就ok。Join的报文降速以后是可以join成功的

ckt1010 commented 7 years ago

Hi @adonislixi , You said is right! when I change it to SF9, node can got accept packet now! Thanks! But I just wonder, why uplink can use SF7, but downlink have such problem. @mluis1 Dude, could you please give some explanation? Thanks!

adonislixi commented 7 years ago

do u have the problem, data packet transition use SF7 or SF8 , with high loses rate ?

adonislixi@foxmail.com

From: Tim Cheng Date: 2016-11-14 19:12 To: Lora-net/LoRaMac-node CC: adonis lee; Mention Subject: Re: [Lora-net/LoRaMac-node] OTAA, join accept packet cannot received (#151) Hi @adonislixi , You said is right! when I change it to SF9, node can got accept packet now! Thanks! But I just wonder, why uplink can use SF7, but downlink have such problem. @mluis1 Dude, could you please give some explanation? Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

mluis1 commented 7 years ago

As we can't reproduce your issues it is quite hard to provide you a solution.

If you aren't receiving the downlinks at the highest speeds it means that either the gateway is sending them at the wrong time or that the end-device is opening the windows at the wrong time.

  1. Gateway sending at wrong time. Can you please verify your link latency between the gateway and the Network Server? If the time to have the JoinReq arriving at the server, having the server generate the JoinAccept and send it to the gateway is bigger than 5 seconds (Join Rx1 slot delay) then you need to investigate how you could reduce the latency.
  2. End-device opening windows at the wrong moment. As I already proposed on a previous answer, you may try to open the windows earlier in time and for longer time.

In order to reduce the amount of problems I would try first to use ABP instead of OTAA. By doing so you avoid the Join procedure issues and you can debug your system more easily. Once in ABP setup your end-device to send Confirmed Uplinks. Then try the different datarates and check that you get all the ACKs. Once you have your system validated using the ABP mode you can switch back to OTAA.

ckt1010 commented 7 years ago

hi @mluis1 your recommend is make sense. But I still curious about that rxtimeout setting. Do you think that 20ms timeout is available? And how did you set that value? Sorry for disturbing...

ckt1010 commented 7 years ago

@adonislixi en... for me, I can't receive any packet at SF7

mluis1 commented 7 years ago

Can we close this issue? It looks like that the problem is the one described on issue #159.