Not possible to schedule upstream packet using gps time
vaIgarashi opened this issue · 13 comments
I am getting always the same error TOO_EARLY. It's not metter what gps time provided. Internal current time are always a bit forward than packet time.
Here i am sending 2^63-1 as gps time:
[1551254529770610] JSON down: {"txpk":{"imme":false,"tmms":9223372036854775807,"freq":868.2999877929688,"rfch":0,"powe":20,"modu":"LORA","datr":"SF7BW125","codr":"4/5","ipol":false,"prea":8,"size":11,"data":"","ncrc":false}}
INFO: [down] a packet will be sent on timestamp value 4191569750 (calculated from GPS time)
ERROR: Packet REJECTED, timestamp seems wrong, too much in advance (current=4192340591, packet=4191569750, type=1)
4192340591 - 4191569750 = 770841 us
Your packet is 0.770841s too late.
Send it early enough to the packet forwarder to be transmitted.
(your tmms) - (now) = time in future
9223372036854775 - 1235838755 = 9.223370801×10¹⁵ seconds in the future.
It is not supported to schedule a packet 292471169 years into the future.
@reissjason The internal time diffrence are very low. Even with number overflow it's not a random luck. The gap are same for any tmms. We have tryed to send gps time with leap seconds, w/o leap seconds, with 1-60 seconds future from current gps time. Gap always the same and the response are always TOO_EARLY.
What is the tmms vs tmst of received packets?
How does it compare to the scheduled packets?
Here an example where i try to send tmms w/o leap seconds (utc - 315964800s - 2s):
Mar 6 07:49:31 klk-lpbs-062B9E local1.notice spf2: [1551858571154254] JSON down: {"txpk":{"imme":false,"tmms":1235893769179,"freq":868.3,"rfch":0,"powe":20,"modu":"LORA","datr":"SF7BW125","codr":"4/5","ipol":false,"prea":8,"size":11,"data":"","ncrc":false}}
Mar 6 07:49:31 klk-lpbs-062B9E local1.notice spf2: INFO: [down] a packet will be sent on timestamp value 1012433679 (calculated from GPS time)
Mar 6 07:49:31 klk-lpbs-062B9E local1.notice spf2: ERROR: Packet REJECTED, timestamp seems wrong, too much in advance (current=1012588153, packet=1012433679, type=1)
This packet is late, it needed to arrive at the packet forwarder at least 155ms earlier.
1012588153 - 1012433679 = 154474 us
It's scheduled in future for 2 seconds
(current_time - 2s) is in the future?
oops, should be +. Anyway, it's not correctly converted to internal time. the gap must be bigger
We have not had issues using this feature.
From your example.
1235893769179 -> UTC | Mar 06, 2019 | 07:49:11 | UTC
Logged at Mar 6 07:49:31 at the packet forwarder.
Timestamp is 20 seconds late?
Have you checked the clock sync on both side?
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.