search

Lora-net / lora_gateway

Driver/HAL to build a gateway using a concentrator board based on Semtech SX1301 multi-channel modem and SX1257/SX1255 RF transceivers.
Other
917 stars 742 forks source link

Downlink ACK problem when two or more node working #55

Closed eydonmlau closed 7 years ago

eydonmlau commented 7 years ago

Hi, I have a problem , when I use one node to test downlink ACK PER, everything works fine(PER about 1.5%), But when I use two or more nodes to test ,I found some problem(PER about 20-30%), Here is step

  1. node 1 send a confirm data.
  2. server respond a ACK to node 1 by gateway.
  3. Gateway send the ACK to node 1 at time_0.
  4. Node 2 send a uplink to gateway at time_1.
  5. If time_1 - time_0 < 500ms, the problem comes, node 1 can not receive ACK. I check gateway log , it shows that gateway has sent the ACK successful , and power meter shows GW has sent the ACK How can I solve this problem ? thx Best regards.
mcoracin commented 7 years ago

Hello,

Which versions of lora_gateway and packet_forwarder are you using?

Could you put the packet forwarder logs here, especially the "JSON up" and "JSON down" traces.

Regards

eydonmlau commented 7 years ago

Hi,The packet_forwarder version is 2.2.1,The lora_gateway version is 4.0.0, Hardware is RPI3, Here are logs ,I found all the case is time_0 - time_1 < 1s ,not time_1 - time_0 < 500ms

time_0-time_1

Can the Just-In-Time mechanism solve this problem? Best regards.

mcoracin commented 7 years ago

Hello,

In the log you show, I think that what happens is that you get the second downlink request from the server, before the first one was actually sent over the air. So the first one is being replaced in the SX1301 buffer by the second one.

In the packet forwarder version you are using, there is no buffering for the downlinks, so as soon as a downlink request is coming from the server, it is placed by the packet forwarder in the SX1301 TX buffer. It will stay in the buffer until the SX1301 counter has reached the departure time. But if a new packet is put in the buffer before the SX1301 counter has reached the departure value, it is just being replaced.

So, yes, the "just-in-time scheduling" mechanism should definitely improve the situation! It will buffer the downlink packets in the packet forwarder, and program place it in the SX1301 buffer few milliseconds before its departure time (around 30ms). The goal is to optimize the usage of the SX1301 TX buffer which can hold only one packet at a time.

eydonmlau commented 7 years ago

Thanks for reply ,I think I get what you means . Just right now I use new version(pkt:4.0.1,lgw:5.0.1) to test, I still find some problem, Hardware is BBB. Here are logs. qq 20170619160806 Apparently, As opposed to the old version(2.2.1), This case lost second downlink request but not the first downlink, Does the "just-in-time scheduling" mechanism just detect the case but not deal with it ?

mcoracin commented 7 years ago

The "just-in-time scheduling" deals with the problem, as much as it can. :) Here you are requesting something that the SX1301 cannot do, because there is an overlap between the 2 downlink packets:

Downlink1: start_time:173369932 - duration:1084ms (17 bytes at SF12) Downlink2: start_time:173928228 - duration:78ms (12 bytes at SF8)

Downlink2 request starts 558.296ms after Downlink1, but Downlink1 duration is 1084ms, so the second downlink request is rejected because the gateway will be transmitting at the time of Downlink2.

If Dowlink1 datarate was SF7 for example, the request for Downlink2 would have been possible. That's the role of the "just-in-time scheduling", to detect downlink collisions and notify the server if one is detected. Without the JiT mechanism the above case would fail whatever the Downlink1 duration, with JiT mechanism, it would pass when possible.

Is that clear?

eydonmlau commented 7 years ago

Refer to the code , I got it , thank you . But I am wondering how did you calculate the duration? Another question , what should server do when txpkt ack is received? Just for statistics and do nothing?

mcoracin commented 7 years ago

For the duration, you can download this tool. Or refer to this function to have the details of the calculation: https://github.com/Lora-net/lora_gateway/blob/master/libloragw/src/loragw_hal.c#L1700

If the server receives an error on txpk_ack, it can decide to reprogram this downlink later. At least he knows that the downlink was not transmitted. It's up to him what to do based on the criticity of the information contained in the downlink.

eydonmlau commented 7 years ago

Thank you ! I close this issue.