Ensuring delivery of Class C msgs

[Alan Hyde]

Hi everyone

We are implementing a 60 node LoraWAN network on a 500 acre vineyard. Key function is to control 55 irrigation valves via Class C lorawan messages to open/close valves. It is critical that messages are received. In our prototyping we probably have about 90% reliability however some messages are lost (for reasons we cannot fully determine yet). We have the confirmation flag turned on on our messages to the nodes (which are Pycom Lopy4) and can see the confirmations on the LoRaWAN server except when we lose our messages.

I'm interested in learning how others have implemented functionality in either their applications or in LorAWAN server to check for confirmation messages and take appropriate action if confirmations not received. Ideally I would like this handled in LoraWAN server but could also implement in the application (Nodered based) if required.

Thanks in advance for any pointers/examples.

Regards

Alan

[Gert Vestergaard Larsen]

Hi Alan,

Interesting project! 

Lost messages can be caused by many reasons. Is it both uplinks and downlinks that are lost, or perhaps only uplinks? Are you only seeing lost messages as a reply to a downlink? Are you sending downlinks as unicast or multicast? If more nodes will reply with an ACK at the same time the Gateway might only receive the first incoming. I haven't tested confirmed messages that much. Is the ACK sent immediately or on the next uplink?. Do you have more than one Gateway? The Gateway could be busy sending a downlink and thereby be missing the uplinks (I believe most Gateways can't receive while transmitting?). What data rate are you using for RX2 downlinks? Do you use ADR or are the nodes using a fixed uplink data rate? Another reason could be interference. But I guess there is not much RF in the vineyard. Testing LoRa in our office, we see a lot of noise that tend to be higher on some channels. So depending on which channel a node is using for an uplink, the message can sometimes be too weak to be received.

/Gert

 

 

--
You received this message because you are subscribed to the Google Groups "LoRaWAN Server Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lorawan-serve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lorawan-server/74d6035d-1809-4773-8da1-5471f1207ae3%40googlegroups.com.

--

Venlig hilsen / Best Regards

Gert Vestergaard Larsen
Software developer

Bødker Balles Gård 24-26
8000 Aarhus C
Denmark
Tel: +45 7199 2525
E-mail: g...@amplex.dk
www.amplex.dk

[Petr Gotthard]

Hi Alan,

 

one way forward is to reduce the losses as suggested by Gert, another way forward is to implement Class C retransmissions. It could/should be done inside the lorawan-server, but it currently isn't-- the Class C are just sent and never retransmitted.

Yet another solution would be multiple-transmissions, i.e. sending the same downlink multiple times. It's also not implemented though and more spectrum consuming.

 

Regards,

Petr

 

______________________________________________________________
> Od: "Gert Vestergaard Larsen" <g...@amplex.dk>
> Komu: "Alan Hyde" <alan....@gmail.com>
> Datum: 18.12.2019 11:39
> Předmět: Re: Ensuring delivery of Class C msgs
>

> CC: <lorawan...@googlegroups.com>

Hi Alan,

Interesting project! 

Lost messages can be caused by many reasons. Is it both uplinks and downlinks that are lost, or perhaps only uplinks? Are you only seeing lost messages as a reply to a downlink? Are you sending downlinks as unicast or multicast? If more nodes will reply with an ACK at the same time the Gateway might only receive the first incoming. I haven't tested confirmed messages that much. Is the ACK sent immediately or on the next uplink?. Do you have more than one Gateway? The Gateway could be busy sending a downlink and thereby be missing the uplinks (I believe most Gateways can't receive while transmitting?). What data rate are you using for RX2 downlinks? Do you use ADR or are the nodes using a fixed uplink data rate? Another reason could be interference. But I guess there is not much RF in the vineyard. Testing LoRa in our office, we see a lot of noise that tend to be higher on some channels. So depending on which channel a node is using for an uplink, the message can sometimes be too weak to be received.

/Gert

 

 

On Wed, Dec 18, 2019 at 12:15 AM Alan Hyde <alan....@gmail.com> wrote:

Hi everyone

We are implementing a 60 node LoraWAN network on a 500 acre vineyard. Key function is to control 55 irrigation valves via Class C lorawan messages to open/close valves. It is critical that messages are received. In our prototyping we probably have about 90% reliability however some messages are lost (for reasons we cannot fully determine yet). We have the confirmation flag turned on on our messages to the nodes (which are Pycom Lopy4) and can see the confirmations on the LoRaWAN server except when we lose our messages.

I'm interested in learning how others have implemented functionality in either their applications or in LorAWAN server to check for confirmation messages and take appropriate action if confirmations not received. Ideally I would like this handled in LoraWAN server but could also implement in the application (Nodered based) if required.

Thanks in advance for any pointers/examples.

Regards

Alan

--

[Alan Hyde]

Gert

Thanks for your reply. A bit more information in response to your questions.

1. I'm sending unicast messages and its the downlink to the device that I'm losing. 

2. While in prototype mode I'm only sending downlink messages to one node at a time.

3. Only using 1 gateway - Laird Sentrius using Semtech packet forwarder

4. Using ADR and haven't paid much attention to actual DR being used

5. We are in remote rural location so very little RF in the region

I'll keep testing and experimenting and appreciate any suggestions and changes to my setup that might improve robustness.

best regards

Alan

On Wednesday, 18 December 2019 21:39:19 UTC+11, Gert Vestergaard Larsen wrote:

Hi Alan,

Interesting project! 

Lost messages can be caused by many reasons. Is it both uplinks and downlinks that are lost, or perhaps only uplinks? Are you only seeing lost messages as a reply to a downlink? Are you sending downlinks as unicast or multicast? If more nodes will reply with an ACK at the same time the Gateway might only receive the first incoming. I haven't tested confirmed messages that much. Is the ACK sent immediately or on the next uplink?. Do you have more than one Gateway? The Gateway could be busy sending a downlink and thereby be missing the uplinks (I believe most Gateways can't receive while transmitting?). What data rate are you using for RX2 downlinks? Do you use ADR or are the nodes using a fixed uplink data rate? Another reason could be interference. But I guess there is not much RF in the vineyard. Testing LoRa in our office, we see a lot of noise that tend to be higher on some channels. So depending on which channel a node is using for an uplink, the message can sometimes be too weak to be received.

/Gert

 

 

On Wed, Dec 18, 2019 at 12:15 AM Alan Hyde <alan...@gmail.com> wrote:

Hi everyone

We are implementing a 60 node LoraWAN network on a 500 acre vineyard. Key function is to control 55 irrigation valves via Class C lorawan messages to open/close valves. It is critical that messages are received. In our prototyping we probably have about 90% reliability however some messages are lost (for reasons we cannot fully determine yet). We have the confirmation flag turned on on our messages to the nodes (which are Pycom Lopy4) and can see the confirmations on the LoRaWAN server except when we lose our messages.

I'm interested in learning how others have implemented functionality in either their applications or in LorAWAN server to check for confirmation messages and take appropriate action if confirmations not received. Ideally I would like this handled in LoraWAN server but could also implement in the application (Nodered based) if required.

Thanks in advance for any pointers/examples.

Regards

Alan

--
You received this message because you are subscribed to the Google Groups "LoRaWAN Server Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lorawan...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lorawan-server/74d6035d-1809-4773-8da1-5471f1207ae3%40googlegroups.com.

[Alan Hyde]

Thanks Petr

I plan to to test sending each transmission multiple times and see if that improves reliability. We are in quite remote rural location so hopefully I will not interfere with spectrum capacity too much. 

Have you seen any code/logic for tracking fcnt and only retransmitting if ack not received. It certainly would be simpler to just to make multiple transmissions upfront if that improves reliability.

Thanks and regards

Alan

On Wednesday, 18 December 2019 22:22:26 UTC+11, Petr Gotthard wrote:

Hi Alan,

 

one way forward is to reduce the losses as suggested by Gert, another way forward is to implement Class C retransmissions. It could/should be done inside the lorawan-server, but it currently isn't-- the Class C are just sent and never retransmitted.

Yet another solution would be multiple-transmissions, i.e. sending the same downlink multiple times. It's also not implemented though and more spectrum consuming.

 

Regards,

Petr

 

______________________________________________________________
> Od: "Gert Vestergaard Larsen" <g...@amplex.dk>

> Komu: "Alan Hyde" <alan...@gmail.com>

> Datum: 18.12.2019 11:39
> Předmět: Re: Ensuring delivery of Class C msgs
>

[Petr Gotthard]

Concerning 4)

Please note the transmission channel abilities are NOT symmetric. The device and the gateway have different antenna size and power capabilities, so downlink (gateway to device) may be a bit harder to receive than uplinks. There is an "RX1 DR Offset" parameter, which lowers the data rate of downlinks by a certain number. Please have a look at the signal quality reported by the devices and try changing the offset to 1 or 2. The percentage of lost downlinks may decrease.

 

Petr

______________________________________________________________
> Od: "Alan Hyde" <alan....@gmail.com>
> Komu: "LoRaWAN Server Users" <lorawan...@googlegroups.com>
> Datum: 19.12.2019 06:05

> Předmět: Re: Ensuring delivery of Class C msgs
>

Gert

To unsubscribe from this group and stop receiving emails from it, send an email to lorawan-serve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lorawan-server/b1140577-7142-432f-8e16-cf5c514393c7%40googlegroups.com.

[Alan Hyde]

Thanks Petr

I'll look into the offset parameter and experiment.

cheers

Alan

On Thursday, 19 December 2019 19:05:47 UTC+11, Petr Gotthard wrote:

Concerning 4)

Please note the transmission channel abilities are NOT symmetric. The device and the gateway have different antenna size and power capabilities, so downlink (gateway to device) may be a bit harder to receive than uplinks. There is an "RX1 DR Offset" parameter, which lowers the data rate of downlinks by a certain number. Please have a look at the signal quality reported by the devices and try changing the offset to 1 or 2. The percentage of lost downlinks may decrease.

 

Petr

______________________________________________________________
> Od: "Alan Hyde" <alan...@gmail.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/lorawan-server/b1140577-7142-432f-8e16-cf5c514393c7%40googlegroups.com.