Troubleshooting
Log analysis
Packets forwarding
To identify the paquets in the logs, here are some examples of how they are logged:
Uplink packet forwarded:
JSON up: {"rxpk":[{"tmst":3842996084,"chan":2,"rfch":1,"freq":868.500000,"stat":1,"modu":"LORA","datr":"SF12BW125","codr":"4/5","lsnr":9.5,"rssi":-4,"size":28,"data":"gMsjASaAF+YBAxPTxQ0IIePC3Loi1RikdEA9DA=="}]}
Downlink packet forwarded:
JSON down: {"txpk":{"imme":false,"tmst":3844996084,"freq":869.525,"rfch":0,"powe":27,"modu":"LORA","datr":"SF9BW125","codr":"4/5","ipol":true,"size":17,"ncrc":true,"data":"YMsjASalalkDVf8AAeeRmP4="}}
Stats report (every 30 seconds) with 3 packets :
### [UPSTREAM] ### # RF packets received by concentrator: 3 # CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00% # RF packets forwarded: 3 (84 bytes) # PUSH_DATA datagrams sent: 4 (757 bytes) # PUSH_DATA acknowledged: 100.00% ### [DOWNSTREAM] ### # PULL_DATA sent: 3 (100.00% acknowledged) # PULL_RESP(onse) datagrams received: 3 (576 bytes) # RF packets sent to concentrator: 3 (51 bytes) # TX errors: 0
Network Server connectivity
Checking fist connection
When you start the forwarder, it will try to connect directely to the server and pull some data from the server.
If it succeeds, you will see the following message:
[down] PULL_ACK received in XX ms
This means the forwarder could contact the server.
How the UDP Packet Forwarder handles re-connection
The packet forwarder is connected to the server through UDP. This means that the forwarder itself does not know whether it's connected or not. When using an unstable connection, if the used network configuration changes (e.g. VPN) or during Network Server maintenance, it may happen that the connection is lost. In that case, restarting the forwarder will make it reconnect. To ensure that the forwarder reconnect automatically (without a manual restart), the autoquit_threshold=3 option is set by default. This option makes the forwarder autoquit if a number of consecutive datagrams (3) have not been acknowledged by the server.
Check connectivity quality
When the packet forwarder sends or requests some data, it is acknowledged by the server. The number of acknowledgment are visible in the stats log. A stats log is shown every 30 seconds and show the statistics for the last 30 seconds.
The log looks like this :
### [UPSTREAM] ### # RF packets received by concentrator: 3 # CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00% # RF packets forwarded: 3 (84 bytes) # PUSH_DATA datagrams sent: 4 (757 bytes) # PUSH_DATA acknowledged: 100.00% ### [DOWNSTREAM] ### # PULL_DATA sent: 3 (100.00% acknowledged) # PULL_RESP(onse) datagrams received: 3 (576 bytes) # RF packets sent to concentrator: 3 (51 bytes) # TX errors: 0
In this log, we can see that 4 datagrams have been sent:
# PUSH_DATA datagrams sent: 4 (757 bytes)
And all of them have been received by the server:
# PUSH_DATA acknowledged: 100.00%
Also we see that 3 data requests have been made to the server and all of them have been received :
# PULL_DATA sent: 3 (100.00% acknowledged)
If the acknowledgment are not at 100%, this means you have a problem with the server connectivity. This could typically occur on unstable connections (typically bad LTE).
One datagram may contain 0 or more packets. If you are interested about packets, you'd rather check the "packets" lines.
Packets CRC status
When packets are sent by the end node, a control sum is added to verify the integrity of the data that is sent. If the LoRa base station does not receive exactly what has been sent by the end node, the comparison of the received CRC and the computed CRC of the data does not correspond. We say that the CRC is bad (actually, it's often the data that is bad) or that the CRC check failed. Packets with a bad CRC are generally not usable and should be dropped.
There can be multiple reasons why packets with a bad CRC are received:
- The end node sends a bad CRC because it's faulty
- Part of the data is not demodulated correctly because of a bad reception quality, e.g. the end node is too far from the base station or there is too much attenuation
- Part of the signal is jammed by another emitter, e.g. another end node or a GSM-R antenna nearby
Whether receiving packets with bad CRC or not is a problem depends on your use case and environment.
First, keep in mind that the LoRa base station receives packets from any end node, not just yours. Your end nodes are generally in good range of your LoRa network, but the others nodes may not. Most often, bad CRC packets come from other end nodes. If you operate a LoRa base station in a populated area where there are many end nodes, you will always receive some bad CRC packets. Having a bad CRC rate of 30% can be common in such environment.
If the base station is in a controlled environment and you have many bad CRC from your own end nodes that should be covered, you may check the signal/noise ratio (SNR) and signal strength (RSSI) of the valid packets to identify which end node has a bad "link" and may have bad CRC packets. There is no absolute values to define a good reception, but generally speaking the RSSI should be above -120dB and the SNR above -10.
Common issues
Failed to start the concentrator
Symptom: It may happen that you get the following message when starting the forwarder:
ERROR: [main] failed to start the concentrator
Cause: This typically happens after a improper shutdown/restart of the forwarder, this can also happen when you stop the forwarder just after starting it (even from the GUI).
Diagnostic: the LoRa concentrator is in a bad state.
Solution: reset the concentrator
There is no possibility at this time to reset the concentrator from the GUI. As a workaround, you can restart the gateway from the Manager UI top-right menu.