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

The packet forwarder is connected to the server through UDP. This means that the forwarder itself does not know natively 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, but the packet fowarder continues to run. In that case, restarting the forwarder will make it reconnect.

To identify if the forwarder is still connected to the server, you can check the stats report in the logs. When the packet forwarder sends or requests some data, is 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.

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

sudo rc-service reset-lgw restart