search

Lora-net / LoRaMac-node

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

ABP works but OTAA does not #581

Closed Lozeonjyu closed 5 years ago

Lozeonjyu commented 5 years ago

Hi all,

I am using Nucleo L073 board + sx1261 shield and trying to get the code running.

For now, I can use ABP method to send out data and read on the webpage through my gateway. But I couldn't use OTAA, there is an Rx 2 timeout and keep saying 'Duty-cycle restricted'.

Does anybody have clues? Thanks a lot.

ABP log:

###### ===== ClassA demo application v1.0.RC1 ==== ######

DevEui      : 01-02-03-04-04-03-02-01
AppEui      : 70-B3-D5-7E-D0-00-B3-AC
AppKey      : 01 01 01 01 01 01 00 00 00 00 01 01 01 01 01 01

###### ===== JOINED ==== ######

ABP

DevAddr     : 26021A8C
NwkSKey     : 2B 7E 15 16 28 AE D2 A6 AB F7 15 88 09 CF 4F 3C
AppSKey     : 2B 7E 15 16 28 AE D2 A6 AB F7 15 88 09 CF 4F 3C

###### ===== MCPS-Request ==== ######
STATUS      : OK

###### ===== MCPS-Confirm ==== ######
STATUS      : OK

###### ===== UPLINK FRAME 1 ==== ######

CLASS       : A

TX PORT     : 2
TX DATA     : UNCONFIRMED
00 

DATA RATE   : DR_0
U/L FREQ    : 914700000
TX POWER    : 0
CHANNEL MASK: FFFF FFFF FFFF FFFF 00FF 

###### ===== MCPS-Request ==== ######
STATUS      : OK

###### ===== MCPS-Confirm ==== ######
STATUS      : OK

###### ===== UPLINK FRAME 2 ==== ######

CLASS       : A

TX PORT     : 2
TX DATA     : UNCONFIRMED
00 

DATA RATE   : DR_0
U/L FREQ    : 902900000
TX POWER    : 0
CHANNEL MASK: 00FF 0000 0000 0000 00FF 

###### ===== MCPS-Indication ==== ######
STATUS      : OK

###### ===== DOWNLINK FRAME 0 ==== ######
RX WINDOW   : 1
RX PORT     : 0

DATA RATE   : DR_10
RX RSSI     : -43
RX SNR      : 2

###### ===== MCPS-Request ==== ######
STATUS      : OK

###### ===== MCPS-Confirm ==== ######
STATUS      : OK

###### ===== UPLINK FRAME 3 ==== ######

CLASS       : A

TX PORT     : 2
TX DATA     : UNCONFIRMED
00 

DATA RATE   : DR_3
U/L FREQ    : 902300000
TX POWER    : 9
CHANNEL MASK: 00FF 0000 0000 0000 00FF

OTAA log:

###### ===== ClassA demo application v1.0.RC1 ==== ######

DevEui      : 01-02-03-04-01-02-03-04
AppEui      : 70-B3-D5-7E-D0-00-B3-AC
AppKey      : 01 01 01 01 01 01 00 00 00 00 01 01 01 01 01 01

###### ===== MLME-Request - MLME_JOIN ==== ######
STATUS      : OK
###### ===== JOINING ==== ######

###### ===== MLME-Confirm ==== ######
STATUS      : Rx 2 timeout

###### ===== MLME-Request - MLME_JOIN ==== ######
STATUS      : Duty-cycle restricted

###### ===== MLME-Request - MLME_JOIN ==== ######
STATUS      : Duty-cycle restricted

###### ===== MLME-Request - MLME_JOIN ==== ######
STATUS      : Duty-cycle restricted

###### ===== MLME-Request - MLME_JOIN ==== ######
STATUS      : Duty-cycle restricted

Update:

However, sometimes when it goes back to ###### ===== JOINING ==== ######, it can join and send the data continuously. I notice that the spreading factor is 10 at the first several data then it goes back to SF7.

ConnyBusy commented 5 years ago

Hi @Lozeonjyu, from your logs I can see you have modified the chmask to just 8 channels of 125KHz and 8 of 500KHz and using US region. From loRaWAN v1.0.3 and later this is not allow for OTAA activation due to join algorithm for US /AU. This requires devices to select channels for each join procedure from each block of 8 channels i.e. Block 1, Block2 ...Block8, Channel 64(500Khz) and repeat the again if joining was not successful. See Regional Parameters. image

The Duty-Cycle restricted is the implementation in line with section 7 of the LoRaWAN requiring a back-off. image

Whenever you observe anything you are not sure of, it's a good thing to go back and read the specification.

Lozeonjyu commented 5 years ago

@ConnyBusy Thanks for the reply. However, I haven't modified anything on LoRa mac and it should be the algorithm from the code itself to select the subband. You can check the first frame of ABP log that all channels are open. But thanks for the clue anyway, digging into specs should be a good way to go.

ConnyBusy commented 5 years ago

@Lozeonjyu ,

What I find strange in your ABP logs is that after the Uplink Frame 1 I don't see any downlink but in Frame 2 the channel mask is already modified. Why is that so?

Concerning the SF10 and SF7 you are seeing: It looks like your server is re-configuring the uplink of your node. looking at your ABP logs: You will see that after Uplink Frame 2 the Node receives a downlink with port set to 0 meaning a mac command in Frame Payload field. In the Uplink Frame 3 the node's TXPower index is set to 9 (from 0 in Frame 2) and DR_3(from DR_0 in Frame 2) which means it was a LinkADR MAC Command.

mluis1 commented 5 years ago

As there is no activity for quite long time we close the issue.