LoPy Lora - randomly goes offline/unable to sent messages for few hours

[mronday]

Hi All,

We're developing an product that measures temperatures of 6 sensors and sent the data over an private lora network (OTAA) to an Lora Kerlink Gateway (https://www.mcs-nl.com/producten/ifemtocell_indoor_lora_gateway/)

Our interval for sending the data is every 15 seconds (for testing purposes, could be somewhat longer if we use this solution in the final product) and there are between 10 and 40 active nodes per Gateway.

We know this interval requires a lot of airtime for lora, that's why we setup an private lora environment and we also don't mind if we lose some messages along the way.

But we've an problem that randomly one of our LoPy's won't be able to sent messages to the gateway successfully for about 1 to 3 hours. So then there are a lot of messages in a row that are being missed by the gateway.

In the logs of our Kerlink Gateway we noticed that when we're missing data of an LoPy the CRC_FAIL rises.

The strange thing is thus that one LoPy is for 1-3 hours in a row not seining data correctly to the gateway. After 1-3 hours we receive the data again from the LoPy and we see that the frame counter is increased during the 1-3 hours downtime.

We don't have any clue anymore how to solve this, so hope your guys have some suggestions for us to test, and solve this problem! If you need meer information, please ask and I will provide it!

Thanks!

======= GATEWAY LOG =======
Mar 20 08:02:18 klk-wifc-0306F4 local1.notice spf: ### [UPSTREAM] ###
Mar 20 08:02:18 klk-wifc-0306F4 local1.notice spf: # RF packets received by concentrator: 10
Mar 20 08:02:18 klk-wifc-0306F4 local1.notice spf: # CRC_OK: 80.00%, CRC_FAIL: 20.00%, NO_CRC: 0.00%
Mar 20 08:02:18 klk-wifc-0306F4 local1.notice spf: # RF packets forwarded: 8 (1107 bytes)
Mar 20 08:02:18 klk-wifc-0306F4 local1.notice spf: # PUSH_DATA datagrams sent: 9 (2999 bytes)
Mar 20 08:02:18 klk-wifc-0306F4 local1.notice spf: # PUSH_DATA acknowledged: 100.00%
======= GATEWAY LOG =======

[jcaron]

What region are you in? What frequencies are you using? What data rate(s)? Are you using ADR? What are the observed RSSIs and SNRs? What's the distance? Are you indoors or outdoors? What antennas are you using (both on the LoPys and on the gateway)? Are the 15 seconds randomised?

[mronday]

@jcaron

Thanks for responding!

What region are you in?
Europe

What frequencies are you using?
686.1

What data rate(s)?
Min = 0 max = 5

Are you using ADR?
No

What are the observed RSSIs and SNRs?
RSSI Between 60-76 dBm
SNR Between 8-10.8 dB

What's the distance?
Between 6 and 20 meters

Are you indoors or outdoors?
Indoor

What antennas are you using (both on the LoPys and on the gateway)?
On the gateway standard external antenna
In our nodes, an PC81 Taoglas antanna (internal)
https://www.taoglas.com/wp-content/uploads/2015/06/PC81.07.0100A.dB_.pdf

Are the 15 seconds randomised?
No

[jmarcelino]

Hi @mronday

I'm not saying it's the cause of the problem but unless it was tested and really as intended sticking an antenna, especially one of that type, to any metal surface - even worse to the metal RF shield of the LoPy - is a bad idea.

[mronday]

@jcaron

Screenshot gateway RX messages

Our Lora channels in LoPy
lora.add_channel(0, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=5)
lora.add_channel(1, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=5)
lora.add_channel(2, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=5)

[mronday]

@jmarcelino

Hi Marcelino,

We've also some old test models with an external antenna (like the one on the gateway). Those nodes also having this strange problem of going offline for a few hours randomly.

Thanks for reply anway, we'll change the position of the antanna's within the case.

[robert-hh]

@jcaron said in LoPy Lora - randomly goes offline/unable to sent messages for few hours:

Are the 15 seconds randomised?

Very interesting. That is indeed a valid & good question, that could explain the beat character of the effect.

[mronday]

@robert-hh

Hi Robert,

Could you explain the beat character? Do you mean that because we didn't randomize the 15 seconds, it explainable that an node is offline for a few hours?

[robert-hh]

@mronday Yes, because then two nodes may try to send at the same time and interfere. Since the clocks of the node are not exactly the same, that situation will disappear after a while, and come back. For that, the difference of the crystals can be in the order of 10^-6, which is totally reasonable. A randomize send timing would avoid longer periods of collisions.

[jcaron]

@mronday A few comments:

1. If you keep the 15 second interval and go beyond SF8, you'll be in breach of the duty cycle regulations. Remember they are not imposed by the networks, but by national/transnational regulations. Those bands are shared, they imply limits on power and duty cycle (or LBT-AFA, but that's another topic).

2. Even at SF7, on a single channel, 10 nodes emitting every 15 seconds implies an average collision rate of over 5%. If you get to 40 nodes, the collision rate will get to 25%. If you increase the SF, well, you'll quickly get to 100% collisions...

3. The fact that your interval is fixed (but not 100% exactly) means that two nodes that emit very close one after another can drift into colliding every time, then back into being slightly apart, and so on. If you randomise the interval, you would more likely see collisions spread a bit randomly rather than concentrated on a single node (it should actually be two, isn't that the case?).

4. If you check your logs, you probably have another node emitting at nearly exactly the same times, don't you? And it should also fail during approximately the same periods.

My advice:

1. Forget about sending every 15 seconds. This is definitely not what LoRa was intended for, and you'll run afoul of regulations quite quickly (not to mention power issues if you're running on batteries...).

2. Use more frequencies to reduce the risk of collisions.

3. Add a random element to your interval. You'll have collisions, but they won't be a long series affecting the same two nodes for a while, it'll be more random and probably more manageable.

[mronday]

@jcaron

Hi Jcaron,

Thanks for your explaination.

1. We'll make te intervals longer so that we don't breach the regulations.

2. I understand what your saying, but could you describe how you calcluate the collision rate?

3. The strange thing is, that almost every time it is a single node who is not recieved well by the gateway. Not always two nodes at the same time. They are indeed close to each other, but we're now testing it with one node, to see how that works.

4. We'll add a random interval.

I'll post if this changes solved our problem.