search

Lora-net / packet_forwarder

A LoRa packet forwarder is a program running on the host of a LoRa gateway that forwards RF packets receive by the concentrator to a server through a IP/UDP link, and emits RF packets that are sent by the server. This project is associated to the lora_gateway repository for SX1301 chip. For SX1302/1303, the repository sx1302_hal must be used.
Other
726 stars 668 forks source link

TOO_EARLY when TOO_LATE #47

Closed gotthardp closed 3 years ago

gotthardp commented 7 years ago

Hello. I am getting

src/jitqueue.c:251:jit_enqueue(): ERROR: Packet REJECTED,
timestamp seems wrong, too much in advance (current=1213920578, packet=1213631788, type=0)

which is kinda weird because packet->count_us - time_us = 1213631788-1213920578 = -288790, which is definitely not > TX_MAX_ADVANCE_DELAY. The error should be TOO_LATE, not TOO_EARLY.

I guess this is an overflow error.

mcoracin commented 7 years ago

Hello,

Here we handle a 32-bits rolling counter. The rejection criteria are detailed in the jitqueue.c file: https://github.com/Lora-net/packet_forwarder/blob/master/lora_pkt_fwd/src/jitqueue.c#L224

TOO_LATE: happens when the packet time is before current time, but there is not enough time to program the downlink in the SX1301 buffer.

TOO_EARLY: the calculation on counter is unsigned arithmetic, so in your case (packet->count_us - time_us) does not equal -288790, but rather 4294678506. Which is definitely greater than TX_MAX_ADVANCE_DELAY. :)

It may be a bit confusing though. But anyway, the result is the same, downlink is rejected for a good reason.

chrissnow commented 7 years ago

Any reason not to just cast to int64 to fix this?

mcoracin commented 7 years ago

No, the main reason is the lack of time for all the testing necessary then when we change something in that part of the code. :) But I keep that in mind to come back on this. If you want to test it, don't hesitate to share a patch and your test results. :)

rbaldwin13 commented 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?__hstc=212684107.579a13689e43099691e328c9248e6ecc.1623103335314.1624470656297.1624635514661.6&__hssc=212684107.6.1624635514661&__hsfp=4176385453] 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.