Repeated Ack_lost events

[RiccMasia]

To start off, I have went through all similar issues regarding this problem. I have increased gateway_timeout and push_ack_timeout configurations in both gateway and server. This mostly solved the issue apart from one time, when my gateway is reset/connects to the server. The very first ack is lost, but all subsequent ones are acknowledged. So what I understand what the problem is, is that once an ack is lost, the server reports this event with the interval set as "stat_interval". The argument for this event, which says the amount of acks lost in percentage, is convergently decreasing to 0 (as for acks_set/percentage acknowledged it goes from 1/0, 2/50, 3/67, 4/75, etc.). So as soon as one ack is lost, my event log is endlessly flooded with this warning.

It isn't clear to me if this is a server issue on this end, or if my gateway (Microchip gateway from development kit) is very basic and simplistic in this reporting. Nonetheless, repeating ack_lost messages while acks from previous to current report weren't actually lost seems like false events to me. Any inputs into this?

[lcse66]

I experience the same problems. Once an ack_lost event appears this is displayed as an alarm at each diagnostic cycle which, in my case, is sent by the gateway every 5 minutes. However, this only happens on one gateway model, not on all. According to the packet forwarder's technical documentation, the upstream packet of type "stat" contains some state indicators (rxnb, rxok, rxfw, ackr, dwnb, txnb) but it is not explicitly indicated whether these are partial numbers (from the previous stat packet) or totals (since gateway startup). So in one case (Robustel) the data is total, I suppose similarly to what @RiccMasia reported; in another case (MikroTik) the data is partial and consequently does not cause repeated alarms.

I think the problem arises from a lack of specification. To resolve it would be necessary that the server takes into account the type of gateway, or that can be specified in the gateway configuration.

Robustel R3000-LG

{
   "stat":{
      "time":"2023-08-23 12:05:07 GMT",
      "rxnb":82664,
      "rxok":58956,
      "rxfw":58956,
      "ackr":99.9,
      "dwnb":4650,
      "txnb":4509
   }
}

MikroTik wAP LR8 and SICE ATRT0812

{
   "stat":{
      "ackr":100.000000,
      "dwnb":1,
      "rxfw":7,
      "rxnb":12,
      "rxok":7,
      "time":"2023-08-23 12:04:51 GMT",
      "txnb":1
   }
}

From LoraWAN packet forwarder (PROTOCOL.TXT):

It is possible for a packet to contain no "rxpk" array but a "stat" object.

json
{
	"stat":{...}
}

That object contains the status of the gateway, with the following fields:

Name	Type	Function
time	string	UTC 'system' time of the gateway, ISO 8601 'expanded' format
lati	number	GPS latitude of the gateway in degree (float, N is +)
long	number	GPS latitude of the gateway in degree (float, E is +)
alti	number	GPS altitude of the gateway in meter RX (integer)
rxnb	number	Number of radio packets received (unsigned integer)
rxok	number	Number of radio packets received with a valid PHY CRC
rxfw	number	Number of radio packets forwarded (unsigned integer)
ackr	number	Percentage of upstream datagrams that were acknowledged
dwnb	number	Number of downlink datagrams received (unsigned integer)
txnb	number	Number of packets emitted (unsigned integer)

Example (white-spaces, indentation and newlines added for readability):

{"stat":{
	"time":"2014-01-12 08:59:28 GMT",
	"lati":46.24000,
	"long":3.25230,
	"alti":145,
	"rxnb":2,
	"rxok":2,
	"rxfw":2,
	"ackr":100.0,
	"dwnb":2,
	"txnb":2
}}