Hi there,
I’m facing a problem. Some ACK are not received by the node, mainly when this is far from the gateway (4km or more). In the Lora server I can see that all the uplink packets are received by the gateway and this send back the ACK. In some situations, the Gateway received the 8 uplink packets but the node doesn’t receive any downlink packet.
I believe the problem is related by any desynchronization caused by the distance.
I’d appreciatte any hint!
Thanks in advance
of course it could be for this reason.
usually devices behave this way when in an area of poor reception
Hi eugenev,
Ok, but why the Gateway listen to the packets from the node but not vice versa? That’s my doubt. I can’t understand why it works just in one way for far distances.
because they are different devices, which have different antennas, their mount heights, etc. the connection may be asymmetrical. many factors influence communication. these are the basics of radio communication
Similar issue here, albeit with gateway and nodes at close distance. I tested for 12 hrs with 2 minute interval and found 10% failed (not acknowledged) transmissions. This happens in Class A and Class C mode with with two different brand radio modules. Timing of the failed transmissions is seemingly random. Retransmissions generate another error:“frame-counter did not increment”. ChipStack was recently updated to the latest version. The gateway uses a packed forwarder.
Recommendations how to debug this further will be appreciated.
how close the distance between the device and gateway ?
at short distances close to the wavelength, device will jam itself due to interference with itself. or overload the gateway receiver.
Enable receiving all types of LoRa packets in packet forwarder
forward crc valid, forward crc error, forward crc disabled in other way you can’t see the errors in the chirpstack.
also, you can inspect the logs from endnode console output, if it possible.
Hi @eugenev,
Thank you for your reply. The gateway is far enough from the node to ensure no overload.
The packetforwarder in the gateway is not accessible for (de)selecting the error packets.
I am already monitoring the end node log data, however the radio module only returns “Tx_ok” or “Tx_noACK”. For the faulty transmissions, sometimes the uplink is received, but I also see that the uplink is not showing at all in the Chirpstack console. Tested at another location with low latency fiber optic Internet, getting the same error results.
I set the radio module to retransmit up to 5 x if not receiving an acknowledge, but these retransmissions generate frame counter errors.
Update:
Using ChirpStack, I got 10% failures when sending confirmed uplinks in Class A and C. Using the same setup, but now sending confirmed uplinks with TheThingsNetwork, no errors during 4 hours of testing (2 minute transmit intervals). Will contrinue testing and also will confirm results with a 2nd test site tomorrow.
I’d like to propose this as a bug. I find that confirmed uplinks in Class A and C mode often do NOT receive a confrmation ack from the network. Actually the Node receive times out as no response is arriving. As a result, the node is re-transmitting a number of times (I have tested with 5 x retransmit), but the node does not see an answer. After 5x trying, the node reports a transmit error as the uplink was not acknowledged. The uplink payload is received and displayed in the console. Chirpstack reports a frame counter error for each retry. Used two different brands node radio modules with the same result. Also tested with dummy load antennas to exclude RF overload as possible cause.
When tested with the same setup connected to TTN, no issues were observed.
I updated to the latest Chirpstack version last week. Verified from 2 different locations.
Please note that the ChirpStack Network Server rejects when an uplink is received with the same frame-counter. This is to make sure that it is not possible to perform a replay attack.
Best way to debug this issue is to keep track of what is received and sent by the gateway. E.g. when you see that the downlink is sent by the gateway, but not seen by the device, then potentially this could also be a (timing?) issue with the device. TTN might handle re-transmissions in a different way.
@brocaar Thanks Orne.
https://github.com/brocaar/chirpstack-network-server/issues/272 covers the same topic and a detailed explanantion. No use sending confirmed uplinks then as re-transmissions with the same frame count will be rejected (for good reason).
We confirmed this morning with “frame-counter validation” disabled that the node no longer generates “No-Ack” error messages, even with observed tx retries.
This solves this issue for me. Thank you @Fede @eugenev @brocaar
