Loads of CRC errors

[Shankar Jayagopi]

Hi Guys,

Looks like there is a lot of CRC errors during transmission between conduit and 3 Laird lora nodes all within the same room.

Received	
CRC Errors	3118
Duplicates	10
Join Duplicates	1
Join Requests	66
MIC Failures	7
Total Packets	1904

Sent	
Duplicates Acked	231
Packets Acked	1772
Total Join Responses	66
Join Responses Dropped	0
Total Packets	1740
Packets Dropped	126

Can you let us know the plausible reasons for this?
Also when we restart the device, it is quite slow at the start, resulting in nodes have lot of packet losses.
These 3 nodes send packets almost every minute(with downlink). Every now and then we see sudden loss of downlink messages.

regards,
Shankar

[Jason Reiss]

Shankar,

In what region are you operating?

A assume the slow device that is restarted is the Conduit and not the lora nodes.

If you using EU868 then then the duty-cycle is also a factor in scheduling downlinks. In the latest versions of AEP you could try to disable the duty-cycle as a test to see if behavior changes. Also the duty-cycle is implemented as a sliding window, time-on-air starts at 0 and is accumulated until a transmission uses it.

CRC errors can be caused by environment or other devices (including distant LORA devices) using the ISM band.
Multipath effects and reflections may also appear on adjacent channels when devices are used in close proximity to the gateway.

[Shankar Jayagopi]

Hi Jason,

Thanks for your response.
I was trying to use the test":{"disableDutyCycle":true} but i was not able to add this via
https://AEP-IP/api/loraNetwork?method=PUT&data={"test":{"disableDutyCycle":true}}
it said

{
   "code" : 400,
   "error" : "[test] property is not set",
   "status" : "fail"
}

I tried adding to lora-network-server.conf, but when i restart the server and try to check the values shown by https://AEP-IP/api/loraNetwork, it goes missing.
What is the right way to add this configuration to lora server?

[Jason Reiss]

Can you upgrade the unit to 1.3.2?

Otherwise the “test” collection would need to be added to /var/config/db.json “loraNetwork” collection manually and restart the unit.
Then the API can set it.

[Shankar Jayagopi]

That really helped with the Duty cycle aspect of it.

But for a while when we were sending data to the server, we kept getting back empty packets in port 0.

LoRa Received downstream data on port 0
RSSI: 0SNR: 0data:

Why would server respond in port 0?
Btw, i had also reduced the nodeQueueSize to 1, coz we had some old response being sent out.

regards
Shankar

[Shankar Jayagopi]

I was looking at the logs and i saw the following:

Nov 11 20:24:09 mtcdt user.info lora-network-server: Frame transmitted to 00:00:00:04 via GW (00:80:00:00:00:00:c4:c9 Chan LC1 127.0.0.1:35817)  Seq# 1f
Nov 11 20:24:09 mtcdt user.info lora-network-server: Check response size: 00000004 sf: 7 bw: 0 dur: 56 < tm: 66 wnd: 1
Nov 11 20:24:09 mtcdt user.info lora-network-server: TransmitQueue canIncreaseDuration 0 66 0
Nov 11 20:24:09 mtcdt user.info lora-network-server: Band: 1 Time off air: 6100 ms
Nov 11 20:24:09 mtcdt user.info lora-network-server: Transmit UDP message to Gateway 197 bytes
Nov 11 20:24:42 mtcdt user.info lora-network-server: Parsing 1 rx packets
Nov 11 20:24:42 mtcdt user.info lora-network-server: SeqNo: 00000001 PrevSeqNo: 00000008 Duplicate: no^M
Nov 11 20:24:42 mtcdt user.info lora-network-server: Addr: 00:00:00:04 MIC Check: passed
Nov 11 20:24:42 mtcdt user.info lora-network-server: Packet accepted from Node 00:00:00:04  GW 00:80:00:00:00:00:c4:c9  (127.0.0.1)  Seq# 1  ADR enabled SF7BW125
Nov 11 20:24:42 mtcdt user.info lora-network-server: Schedule TX Time on air: 56 ms
Nov 11 20:24:43 mtcdt user.info lora-network-server: Queue app data 7 bytes
Nov 11 20:24:43 mtcdt user.info lora-network-server: Scheduled 12 bytes payload
Nov 11 20:24:43 mtcdt user.info lora-network-server: Frame transmitted to 00:00:00:04 via GW (00:80:00:00:00:00:c4:c9 Chan LC1 127.0.0.1:35817)  Seq# 20
Nov 11 20:24:43 mtcdt user.info lora-network-server: Check response size: 00000004 sf: 7 bw: 0 dur: 56 < tm: 61 wnd: 1
Nov 11 20:24:43 mtcdt user.info lora-network-server: TransmitQueue canIncreaseDuration 0 61 0
Nov 11 20:24:43 mtcdt user.info lora-network-server: Band: 1 Time off air: 5600 ms
Nov 11 20:24:43 mtcdt user.info lora-network-server: Transmit UDP message to Gateway 190 bytes
Nov 11 20:25:02 mtcdt user.info lora-network-server: Parsing 1 rx packets
Nov 11 20:25:02 mtcdt user.warn lora-network-server: Recv'd frame failed CRC check
Nov 11 20:25:10 mtcdt user.info lora-network-server: Parsing 1 rx packets
Nov 11 20:25:10 mtcdt user.info lora-network-server: SeqNo: bee27ba0 PrevSeqNo: 00000001 Duplicate: yes^M
Nov 11 20:25:10 mtcdt user.info lora-network-server: Addr: 00:00:00:04 MIC Check: passed
Nov 11 20:25:10 mtcdt user.info lora-network-server: Duplicate Packet accepted from Node 00:00:00:04  GW 00:80:00:00:00:00:c4:c9  (127.0.0.1)  Seq# 1  ADR enabled SF7BW125
Nov 11 20:25:10 mtcdt user.info lora-network-server: Schedule TX Time on air: 56 ms
Nov 11 20:25:11 mtcdt user.info lora-network-server: Frame transmitted to 00:00:00:04 via GW (00:80:00:00:00:00:c4:c9 Chan LC3 127.0.0.1:35817)  Seq# 21
Nov 11 20:25:11 mtcdt user.info lora-network-server: Band: 1 Time off air: 4100 ms
Nov 11 20:25:11 mtcdt user.info lora-network-server: Transmit UDP message to Gateway 166 bytes
Nov 11 20:26:59 mtcdt user.info lora-network-server: Parsing 1 rx packets
Nov 11 20:26:59 mtcdt user.info lora-network-server: SeqNo: bee27ba0 PrevSeqNo: 00000001 Duplicate: yes^M
Nov 11 20:26:59 mtcdt user.info lora-network-server: Addr: 00:00:00:04 MIC Check: passed
Nov 11 20:26:59 mtcdt user.info lora-network-server: Duplicate Packet accepted from Node 00:00:00:04  GW 00:80:00:00:00:00:c4:c9  (127.0.0.1)  Seq# 1  ADR enabled SF7BW125
Nov 11 20:26:59 mtcdt user.info lora-network-server: Schedule TX Time on air: 56 ms
Nov 11 20:26:59 mtcdt user.info lora-network-server: Frame transmitted to 00:00:00:04 via GW (00:80:00:00:00:00:c4:c9 Chan LC3 127.0.0.1:35817)  Seq# 22
Nov 11 20:26:59 mtcdt user.info lora-network-server: Band: 1 Time off air: 4100 ms
Nov 11 20:26:59 mtcdt user.info lora-network-server: Transmit UDP message to Gateway 166 bytes

The first time it sent the data, downlink worked. The next two times it didn’t.
Started saying “Duplicate: yes” . Why and how does it mark it as duplicate?
Why does it stop working suddenly like this.

[Jason Reiss]

The device is sending data without incrementing the sequence number.
The duplicate packets do not generate “up” mqtt messages.

… Seq# 1 ADR enabled
…
… Seq# 1 ADR enabled

SeqNo: bee27ba0 PrevSeqNo: 00000001 Duplicate: yes

bee27ba0 is uninitialized data and can be ignored

The empty packets on port 0 maybe the ADR MAC commands

[Shankar Jayagopi]

Ahhh, Is this something i should consult with the Laird board developers? Coz they don’t really give us a way to increment sequence numbers (LORAMACTxData), i would imagine this to be part of their firmware. (documentation)

But at the same time, I tried running sample program that came with the board, and it seems to be incrementing the sequence number (except a couple of times it failed). When i run my program sometimes it is a hit and sometimes miss.

[Shankar Jayagopi]

Looks like when choosing join by personalization the laird RM186 board generates wrong sequence numbers. I have sent an email to the support team.
Under OTA it seems to generate fine.

[Jason Reiss]

Thanks for the update. Glad you were able to find some answers.

[Author]

Posts