Lora Server to GW MQTT ACK: "TOO EARLY"

ChirpStack Gateway Bridge
1

I have a system that is using a LAIRD GW and Gemtek GPS Tracker nodes. In general it’s working, but I’ve been exploring other GW MFG’s and just learning about the system.

I also have a Tektelic Pico GW which is not working properly with the same Gemtek Nodes, and I’m trying to learn how to use the system to debug.

For debugging, I learned through the forums that I can subscribe to MQTT GW topics and see various things. When just observing my system with the Laird GW I noticed that occasionally I get “TOO EARLY” ack messages. Are these from the GW? In this case the node is sending confirmed data, the LORA stack is typically responding with and unconfirmed acknowledge and things are usually working. Shown below is a sequence of RX/TX/ACK where it’s working; followed by one where it’s “TOO EARLY”.

I read the description of “TOO EARLY” from https://www.loraserver.io/lora-gateway-bridge/use/data/
but it’s still not clear to me. Looking below. I see an RX with timestamp 1507119195 followed by TX with timestamp 1508119195. I’m using US902-928 in this case with RX1 Delay 1 s.

Does this error mean that the GW time and the server time are not synchronized? Even though the server tried to send a TX with the correct timestamp did it arrive at the GW too early based on the GW timing? Are there configurations that might help me fine tune the timing?

================================================================================================================================================================

gateway/c0ee40ffff2939d6/rx {“rxInfo”:{“mac”:“c0ee40ffff2939d6”,“timestamp”:1501025924,“frequency”:904900000,“channel”:5,“rfChain”:1,“crcStatus”:1,“codeRate”:“4/5”,“rssi”:-21,“loRaSNR”:10.8,“size”:24,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:7,“bandwidth”:125},“board”:0,“antenna”:0},“phyPayload”:“gJlKN/6AIQADnTp6XYRHNhANmx/q9n9q”}

gateway/c0ee40ffff2939d6/tx {“token”:41886,“txInfo”:{“mac”:“c0ee40ffff2939d6”,“immediately”:false,“timestamp”:1502025924,“frequency”:926300000,“power”:20,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:7,“bandwidth”:500},“codeRate”:“4/5”,“iPol”:null,“board”:0,“antenna”:0},“phyPayload”:“YJlKN/6gIAADnxEc”}

gateway/c0ee40ffff2939d6/ack {“mac”:“c0ee40ffff2939d6”,“token”:41886}

================================================================================================================================================================

gateway/c0ee40ffff2939d6/rx {“rxInfo”:{“mac”:“c0ee40ffff2939d6”,“timestamp”:1507119195,“frequency”:904700000,“channel”:4,“rfChain”:1,“crcStatus”:1,“codeRate”:“4/5”,“rssi”:-51,“loRaSNR”:10,“size”:24,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:7,“bandwidth”:125},“board”:0,“antenna”:0},“phyPayload”:“gOtVsv6AMAEDeduB/TI2P6qmu155Paum”}

gateway/c0ee40ffff2939d6/tx {“token”:1115,“txInfo”:{“mac”:“c0ee40ffff2939d6”,“immediately”:false,“timestamp”:1508119195,“frequency”:925700000,“power”:20,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:7,“bandwidth”:500},“codeRate”:“4/5”,“iPol”:null,“board”:0,“antenna”:0},“phyPayload”:“YOtVsv6gLgHUghg6”}

gateway/c0ee40ffff2939d6/ack {“mac”:“c0ee40ffff2939d6”,“token”:1115,“error”:“TOO_EARLY”}

================================================================================================================================================================

2

Just as a follow up. When I look in the loraserver.toml I see entries for time configuration as shown below. If I’m getting issues in timing between my server and GW (based on network latency I suppose) am I supposed to try to tune timing via these type settings?

Thanks,
Patrick

#Time to wait for uplink de-duplication.
#
# This is the time that LoRa Server will wait for other gateways to receive
# the same uplink frame. Valid units are ‘ms’ or ‘s’.
# Please note that this value has influence on the uplink / downlink
# roundtrip time. Setting this value too high means LoRa Server will be
# unable to respond to the device within its receive-window.
deduplication_delay=“200ms”

# Device session expiration.
#
# The TTL value defines the time after which a device-session expires
# after no activity. Valid units are ‘ms’, ‘s’, ‘m’, ‘h’. Note that these
# values can be combined, e.g. ‘24h30m15s’.
device_session_ttl=“744h0m0s”

# Get downlink data delay.
#
# This is the time that LoRa Server waits between forwarding data to the
# application-server and reading data from the queue. A higher value
# means that the application-server has more time to schedule a downlink
# queue item which can be processed within the same uplink / downlink
# transaction.
# Please note that this value has influence on the uplink / downlink
# roundtrip time. Setting this value too high means LoRa Server will be
# unable to respond to the device within its receive-window.
get_downlink_data_delay=“100ms”

3

The timestamp is an internal timestamp to the gateway. E.g. it starts counting at 0 on boot and then keeps counting. The issue probably is that the downlink timestamp already occurred when it received the downlink transmission request. Probably this means that the roundtrip between the uplink and downlink is > 1s. When your gateway is operating on an unreliable network, you could increase the rx-delay in the loraserver.toml configuration for example.