search

Lora-net / LoRaMac-node

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

Class C Downlink had a problem #477

Closed jcjheng closed 5 years ago

jcjheng commented 6 years ago

MCU Board：NUCLEO-L152RE LoRa Board：SX1261 Evaluation Board (PCB_E406V03A 4117)(sx1261dvk1bas) FW：Git LoRaMac-node-master v4.4.1 Region：AS923 GateWay：Kiwi AS923 gateway Node = MCU Board + LoRa Board + FW + Region

Test 1：Node = Class_A，GateWay setting Downlink Window = RX1 Window，By OTAA Test 1 Result：Join OK，Uplink OK，Downlink OK

Test 2：Node = Class_A，GateWay setting Downlink Window = RX2 Window，By OTAA Test 2 Result：Join OK，Uplink OK，Downlink OK

Test 3：Node = Class_A，GateWay setting Downlink Window = RX1&RX2 Window，By OTAA Test 3 Result：Join OK，Uplink OK，Downlink OK

Test 4：Node = Class_C，GateWay setting Downlink Window = RX1 Window，By OTAA Test 4 Result：Join OK，Uplink OK，Downlink Failed (not receive any packet)

Test 5：Node = Class_C，GateWay setting Downlink Window = RX2 Window，By OTAA Test 5 Result：Join Failed (not receive any packet)

Test 6：Node = Class_C，GateWay setting Downlink Window = RX1&RX2 Window，By OTAA Test 6 Result：Join OK，Uplink OK，Downlink Failed (not receive any packet)

About the ClassA，not any problems， But ClassC have Problem in Downlink， So have any issues in here? Please help. Thanks.

ygaklk commented 6 years ago

On my side, with the sx1261, I observed problems on Rx2 windows only if my packet is longer than 15-20 bytes (included LoRaWAN header). This is independant from classA or C in my case, but by definition it occurs more frequently in classC due to the long Rx2 window.

By debuging DIO1, I observe that the TimeoutIRQ is firing every 50ms during the Rx2 window. Perhaps the root cause of the issue...

mluis1 commented 6 years ago

Could you please check that the proposed fix corrects the issue?

BenAtPip commented 5 years ago

Would any involved party have an update on this issue? Seems to be persistent in devices which I have operating on AS923 on this FW

mluis1 commented 5 years ago

We have proposed a fix back in July 24th and so far we didn't receive any feedback.

@BenAtPip Could you please provide more information on the observed issue.

Without a description of the observed issue it is very hard to reproduce it and to fix it. We can't fix what we don't understand.

BenAtPip commented 5 years ago

Hi Miguel,

I've been in communications with our network provider and supplier, we observe that end devices on the FW are now servicing downlinks by implementing the change proposed in this thread by user "DominusFulguris": https://github.com/Lora-net/LoRaMac-node/issues/533

The problem we were observing was end devices in Class A, as either OTAA or ABP, were not servicing MAC commands, as it appears they did not change the reception window correctly. It appears the issue may be that the network and the end devices are operating on different versions of the LoRaWAN standard, and as a result do not have DR's which align 1:1 correctly. This is currently a hypothesis which is being tested.

Thank you for your response.

mluis1 commented 5 years ago

We believe that the current implementation is compliant to the LoRaWAN Specification v1.0.3 and LoRaWAN Regional Parameters v1.0.3revA specifications.

It means that the network server must also be using the same set of specifications.