Elsys device packet loss - US_902_928

End Devices (Nodes)
1

Hi all,

I’m having packet loss issues with an installation of 20 Elsys sensors (ERS CO2, Sound, Desk and EMS Desk) in the US_902_928 region.

I have a single Multitech Conduit MTCAP-915-041A located in an adjacent building approx 60m from devices.

I have two IM buildings break beam people counters in the same install that are rock solid, so I must have configured something incorrectly in the Elsys phone app when programming the devices.

I’ve configured the Elsys sensors to use OTAA with ADR, with DR0 min (SF10 125), DR1 default (SF9 125) and DR4 max (SF8 500)(https://www.thethingsnetwork.org/docs/lorawan/regional-parameters/ US902-928 Data Rates)

In the Elsys app, the frequency plan I selected is the vanilla US915 and I have left the sub-band as ‘Band0 Ch:0-7’. The notes in the app for sub-band say 'only in combination with hybrid mode, i.e. US915 hybrid, which I have NOT selected.

For the packets that do get through, I’m seeing RSSI values above -100 and SNR values above 0. Most sensors are sitting at SF7.

One thing I have set that may be unusual is link period to 8 and link threshold to 2. I was advised by a supplier in the UK to to do this. I would appreciate feedback on whether this is generally necessary or not.

It’s clear from monitoring the f_cnt that all the Elsys sensors are regularly rebooting to try and re-join (assuming a function of the link period setting)

Reading the link below, I note reference to sub-band-2. Does this mean I should be using the Elsys app setting 'US915 hybrid and ‘Band2 Ch:16-23’? https://www.thethingsindustries.com/docs/reference/frequency-plans/

I’ve included two screenshots of my settings from the Elsys app below for reference.

I will try the hybrid and sub-band-2 setting when I can next access the sensors.

Any advice would be appreciated.

Thanks

Elsys1
Elsys

2

Both the GW and the devices have to be on same plan, recommendation is US915 FSB2 for TTN - how have you configured the Multitech GW? If GW correctly on FSB2 then yes move all devices that arent working to FSB2! Assume the IM Break Beams are configured same as GW? (Hence working). If not constrained to a sub-band then if following spec and truely random as you can imagine with 64 channels available and GW listening on 8 there will be occasional hits but statistical mismatch. There is also an assymetry to uplin/downlink channel choices to consider. Joins can then also take a long time, so best use defaults defined by TTN recommended plans to keep life simple -) Also then allows for GW to contribute to wider community coverage. Note: if you have many sesnors on a commercial deployment then you might also want to talk to the TTI core team about commercial instance of TTS :wink:

3

Leaving aside the potential mismatch of sub-bands, 20 sensors with a link check period of 8 has a high probability of breaching the Fair Use Policy &/or muting the gateway for a period of time on its duty cycle. Hopefully the Elsys only reboots after two lost Link Checks and isn’t using confirmed uplinks because that would require the gateway to be transmitting.

Not sure about when to use ADR & try to force a minimum of DR4 - between the LNS asking to reduce the DR (which it clearly does if the devices are actually on SF7 and the device having an existential crisis about the request from the LNS vs the settings from the human, that is also likely to provoke a pile of downlinks.

And we all know what happens to a gateway when it’s transmitting. Which exacerbates packet loss.

I think the whole lot is over configured when a lot of LoRaWAN with ADR is about devices sorting themselves out.

I would however look at sticking a TTIG in the middle of the actual building itself. It would only take something large & metal (aka truck) to sit in the signal path to the gateway which by being in another building is a funnel shape to compromise signals as well.

And then there is the commercial use, paging @rish1!

1 Like