When Im trying to send data from server … The following happens
src/jitqueue.c:251:jit_enqueue(): ERROR: Packet REJECTED, timestamp seems wrong, too much in advance (current=3244624583, packet=2092530435, type=0)
What did i miss?
When Im trying to send data from server … The following happens
src/jitqueue.c:251:jit_enqueue(): ERROR: Packet REJECTED, timestamp seems wrong, too much in advance (current=3244624583, packet=2092530435, type=0)
What did i miss?
That is probably because the NS wasn’t able to send the response in time. This could be caused by mis-configuration or high latency between the GW and NS.
how to solve this …??
You could increase the rx_delay
for example (chirpstack-network-server.toml
), to allow for a longer rountrip time between the uplink and downlink. You might need to re-activate your device(s).
Are you using a cellular gateway?
mine is RAK2245 wireless
Hi @brocaar
we have set rx_delay=5
in chirpstack-network-server.toml
but we are not getting any success. still, we are getting below error in packet-forwarder
src/jitqueue.c:251:jit_enqueue(): ERROR: Packet REJECTED, timestamp seems wrong, too much in advance (current=3244624583, packet=2092530435, type=0)
@brocaar
Why does that happen on a CLASS-C device? Class-c listens on rx2 infinitely, so it might worth to schedule transmission on RX2 rather than RX1? Could I force NS to schedule transmission on RX2 settings?
A Class-C device could still send a Class-A uplink, in which case the NS might send a Class-A timestamped downlink back to the device.
The latest ChirpStack test versions contain a refactored downlink queue handling, in which case a failed Class-A downlink for a Class-C device would be sent again using Class-C parameters.
@brocaar
Sir can you please tell me why these error messages are printing in lora packetforwarder while receiving a downlink message and these downlink messages are not going to node …
ERROR: concentrator is currently emitting
INFO: [jit] lgw_status returned TX_EMITTING
I have been seeing this error as well, and am currently digging into packet forwarder (its possible this is the same as your issue, but need more pkt_fwd logs to confirm)
Here is what is occurring, to the best of my understanding:
So, how can this happen? It seems to me that either the JIT scheduler time-on-air calculations are not 100% correct, or the overhead/fudge factor is not enough. In other words, JIT queue scheduled packet 2 at time index B too early. Its calculations must be off.
We can see things such as the below in jitqueue, so already know “fudge factor” is a thing here…
#define TX_START_DELAY 1500 /* microseconds */
/* TODO: get this value from HAL? */
#define TX_MARGIN_DELAY 1000 /* Packet overlap margin in microseconds */
/* TODO: How much margin should we take? */
Other things to consider:
Digging into pkt_forwarder a little more… in jit_enqueue where it calculates the time slice needed for the packet:
case JIT_PKT_TYPE_DOWNLINK_CLASS_A:
case JIT_PKT_TYPE_DOWNLINK_CLASS_B:
case JIT_PKT_TYPE_DOWNLINK_CLASS_C:
packet_pre_delay = TX_START_DELAY + TX_JIT_DELAY;
packet_post_delay = lgw_time_on_air(packet) * 1000UL; /* in us */
break;
libloragw for your gateway contains lgw_time_on_air()
, so that implementation might be different. The code directly after the above switch statement is where it finds the timeslice for this packet, using another TX_MARGIN_DELAY
constant. This is where I’ll be focusing on debugging the issue, but perhaps there is an easier or higher level approach
How is this problem solved?