Closed brocaar closed 3 years ago
In an effort to improve our customer support experience and in recognition that our support backlog on GitHub has historically exceeded the capacity of our engineering team, we have taken the difficult decision to focus on the most contemporary issues reported and to close all others without confirmation of resolution.
Our belief is that issues which have remained unresolved and unaltered for extended periods of time are less likely to continue to pose a significant problem to the user than when they were originally filed. More contemporary issues however may still be relevant and hence are more appropriate to prioritize.
For those users who remain interested in resolution of a reported issue that was closed, we are encouraging usage of our developer portal forums [https://forum.lora-developers.semtech.com/] and commercial support portal [https://semtech.force.com/ldp/ldp_support] as the preferred avenues to receive support. We will continue to monitor the GitHub issue trackers as well, but want to encourage all users to take advantage of the increased community presence on the developer portal. For commercial customers, we highly recommend using the commercial support portal which is uniquely tailored to service such support requests.
If I understand correctly, the
packet_pre_delay
andpacket_post_delay
are used to detect potential collisions in the JIT queue.I do not understand why there is a difference between Class A/B/C packets and beacon packets in this calculation. For the gateway, I don't think there should be any difference with regards to type. It needs to schedule a LoRa or FSK modulated frame and there shouldn't be any collision. A gateway can't transmit two packets simultaneously + it needs some margin to forward the packet to the concentrator.
I believe the
/* As defined in LoRaWAN spec */
is referring to:In my understanding, this refers to the scheduling of Class-B ping slots, which is handled by the Network Server. However, this does not mean that a gateway can't sent other downlink frames, does it?
If I understand the code above correct, then it means that when a gateway has a beacon in its queue, it doesn't allow to schedule any frame
TX_START_DELAY + BEACON_GUARD + TX_JIT_DELAY
before this beacon, which is roughly 3 seconds. Why would this be needed?What would be the issue with changing this code to just: