Packet Forwarder - packets rejected

Gateways
1

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?

2

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.

3

how to solve this …??

4

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).

5

Are you using a cellular gateway?

6

mine is RAK2245 wireless

7

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)

8

@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?

9

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.

10

@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

11

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:

  1. LNS sends at least 2 downlinks to the gateway that end up being scheduled for downlink quite close to each other
  2. Packet forwarder schedules both packets in JIT queue at their calculated time slice (note the emphasis on calculated)
  3. Packet forwarder sends ACK to LNS on both packets as they were successfully scheduled in JIT queue (LNS considers them complete and removes from LNS queue)
  4. At time index A (packet 1 jit time), pkt forwarder emits the downlink frame on air
  5. At time index B (packet 2 jit time), pkt forwarder attempts to emit packet 2, but packet 1 is still being transmitted

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:

  • Gateway/packet forwarder system load/priority (is jitqueue getting the real-timeness it needs?)
  • SPI/interface clock speed to lora radio. Unexpected delays starting packet 1?
  • Any other stuff that could goof up timings of jitqueue sending commands to radio
  • What else could produce “packet is already emitting”?
12

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

13

How is this problem solved?