LoRaWAN ADR: how to get connectivity state from the app?

[tve]

I'm happy that the LoRaWAN layer implements ADR as well as ADR back-off: yay!

What I'm wondering is how to track some notion of connectivity in the app so it can make decisions, e.g., stop sending long messages if they're going nowhere or eventually try a fresh join (I think that's kind'a recommended although a double-edge sword with LW1.0.x).

BTW, is there a reason for getLastToA() as opposed to including that in the LoRaWANEvent_t?

[StevenCellist]

We could add a function that returns adrFcnt - fCntUp, which translates to the difference between the current uplink counter and the uplink counter when the last downlink was received - that should be it? Feel free to send in a PR for that :)

eventually try a fresh join (I think that's kind'a recommended although a double-edge sword with LW1.0.x

That is something that maybe isn't the brightest idea in LW 1.0.x indeed, as that means you completely lose the ability to send uplinks. I've seen plenty of situations with my previous generation sensor boxes where gateways were receiving uplinks just fine, but a downlink pretty much always failed to arrive at the nodes. Probably some weird gain on the antennas. LW 1.1 has a dynamic rejoin scheme, but I've never heard someone actually using it, and TTS doesn't provide any interface for it and they don't have plans to add this until LW 1.2 drops, so I've not bothered to implement it.

is there a reason for getLastToA() as opposed to including that in the LoRaWANEvent_t?

Umm.. one existed before the other. But I guess it makes sense to move it into the event, as there's also a somewhat useful ToA to be reported for downlinks as well. Feel free to send in a PR ;)

[HeadBoffin]

What I'm wondering is how to track some notion of connectivity in the app so it can make decisions, e.g., stop sending long messages if they're going nowhere

There are whole swathes of functionality in the core spec (mostly link check) plus the recommendations in TR007 that should solve this for you.

[StevenCellist]

Please enlighten me on your reasons to not provide a function like the one proposed?

[tve]

I don't know the exact intentions of @tve, but I do see some use in providing a function that tells the user how many messages have been sent without any subsequent downlink. This has not much to do with LinkCheck, and it provides some useful insight into the state of the ADR back-off mechanism.

Yup!
I don't know what my intentions are :-). Yet...

I did read TR007 and what occurred to me is the ADR mechanism is basically layer zero when it comes to monitoring the connectivity. It has (relatively speaking) a lot of info. So it seems to me that anything at a higher layer should leverage that info before adding additional up/downlinks.

I appreciate HeadBoffin pointing out that it's better to keep the smarts at the server end and just put "remote knobs" into the firmware that the server can tweak. Makes a lot of sense.

From past experience, the #1 form of failure I see is a gateway dropping out, often leaving a backup gateway with lower signal strength to take up the slack. The way things currently are it will be the LoRaWAN.cpp ADR layer that deals with this. The question is whether anything else needs to be done. In many cases no: the user should get some alert and know that batteries are being drained faster to make up for the lower signal strength. Someone then needs to fix the failed gateway...

In some cases it may however be necessary to prioritize battery drain. For example, a solar-powered node may no longer be able to run through the night or run through a series of cloudy days and should perhaps reduce the frequency of transmissions to compensate. Right now the power level in the Event struct and getLastToA provides enough information about the energy consumption. Maybe that's enough. I don't know how nbTrans factors into that, does it? Even if the decision is taken at the server end it somehow needs to be sent there (as far as I can tell the server end knows the DR but not the TX power).

I don't know what to think about the number of TX w/out RX. IIRC every 64th uplink should be confirmed. So if that number goes much beyond 256 that means 4 confirmations were missed. That also means the server can't say "decrease your interval to save power". Whether the device should take action is tricky: damned if you do, damned if you don't, as you guys have pointed out.

I suppose that after umpteen unconfirmed uplinks ADR starts to back off, which means increased power consumption, thus any mechanism that reacts to energy consumption will handle it. Maybe the best course of action is to track energy consumption, periodically send that to the server which can send downlink commands if necessary, and possibly implement some energy consumption governor in the end device (could be as simple as a leaky bucket rate limit based on energy consumption to make battery life predictable).

[HeadBoffin]

as far as I can tell the server end knows the DR but not the TX power

The 'standard' ADR mechanism is to only reduce the Tx power once you've run out of DR's to reduce. So if the device is on DR5, the algorithm will command a reduction in power - which helps - but it's not like the other end where its moved to DR0, half the uplinks aren't getting through due to time on air and it's burning battery.

For solar I do part some smarts in to the firmware, but app side monitoring can detect a radical change of DR and act instantly - however it may take time for the device's process to bring the DR up to a point that it is being heard again. The way round this is for the once a day housekeeping uplink (battery levels, other info) to send at DR2 (1 & 0 have to be restricted, per LoRa Alliance guidelines). At which point your app server has time to send reconfiguration - like move to DR2, reduce uplink frequency and once the device is regularly back online, you can investigate & adjust accordingly.

IIRC every 64th uplink should be confirmed

This is just a really cr@p default - if you send once every 15 minutes you are doing that every 16 hours which if the device is in a good place (see example below) seems pointless.

If you analyse uplink data and see a device is heard by three gateways and it's on DR4, doing a confirmed uplink once a week seems about right as it's not having to shout too loud and there is redundancy in reception. If it's on DR3 and only heard by one gateway, maybe every other day. All of this is entirely subjective and dependent on the application.

If you need the data but don't necessarily need it to arrive on time, then having the uplink include some overlapping data can fill in the gaps. And/or hold some history on the device and resend on request.

I suppose that after umpteen unconfirmed uplinks ADR starts to back off

Implementations vary - not even looked at RL inside as I've already got my stuff as user code.

Maybe the best course of action is to track energy consumption, periodically send that to the server

No need, you know the Time on Air from the uplink meta data - which is all the device can report anyway unless you do actually monitor coulombs consumed which is a whole bag of 'mostly works'. I'm testing one of the MAX17048 smart battery charge modules which is more of a lookup table with some smoothing - solar stops charging but it thinks we are 79% because the charger stops at 4.1V, not 4.2V. So not smart at all.

to make battery life predictable

You'd need a lot of data, battery batch numbers and battery temperatures to do that. Do-able but a fair amount of data science. I'd look at the requirements to see how you can make the uplink interval as long as possible, particularly if you send once an hour with temperature readings at 10 minute intervals - there are some sweet spots on uplink sizes and if you send delta's based on the first reading in a row it can be very efficient.

That and hack on the Rx1 sleep window as that tends to burn 33 to 50% of battery on the better DR's.

[tve]

Thanks for all the experience, lots to chew on, appreciated!

I need to wrap my mind around the implications of LoRa in terms of reliability, I'm more used to FSK where I see significant variations in reliability hour by hour.

That and hack on the Rx1 sleep window as that tends to burn 33 to 50% of battery on the better DR's.

Is that an EU868 thing? I'm using US915 and there RX1 is short while RX2 takes a long time.

WRT energy monitoring I was more thinking about keeping track of it explicitly. E.g. calculating it based on TX power and ToA using a small look-up table (plus data acquisition power, which tends to be a constant).

The 'standard' ADR mechanism is to only reduce the Tx power once you've run out of DR's to reduce.

I'm still confused about this a bit, haven't looked into how this can be customized in ChirpStack. When using small batteries the current drawn by 14dBm (and more so by 22dBm) is tough to deliver, likely reducing battery life. (For example, a Jauch Li-SoCl2 1/2AA states 15mA max continuous.) It seems to me that an ADR profile that first reduces power to a non-stress level would be beneficial.

I also find confusing the fact that "An end-device SHALL acknowledge the successful receipt of a command that specifies a higher TX power than it is capable of using. In that case, the end-device SHALL operate at its maximum possible power." While this makes sense, it does mean that in the case of a lower power device it takes several power reduction steps before anything actually changes. Maybe the answer is simply that the server should have an ADR profile that matches the device's capability.

[HeadBoffin]

Is that an EU868 thing? I'm using US915 and there RX1 is short while RX2 takes a long time.

Nope, it's the LoRaWAN Network Server you are using thing - most Rx1's are set to 5 seconds to give time for an integration to pass back a downlink (if necessary) and for the LNS to queue it with a gateway for the gateway to tx. The Rx2 window is typically 1s after the Rx1.

I was more thinking about keeping track of it explicitly

I'm not sure battery chemistry allows for such precision/science/accuracy - you've many many very small uses of the mAh rating of the battery - I've devices that have run for 150,000+ uplinks on part used Lithium Energisers (used for High Altitude Balloon mission, so by no means starting out full) - these were test devices close to hand so I wasn't trying anything other than just leaving some to run and with Lithium you are drop a bit at the start and then it's pretty much the same voltage until they fall off a cliff. Just manufacturing variations alone could change the figure by thousands of uplinks. Or you have a device that gets the full summer sun for two hours and it runs out of juice six months ahead of the one in the shade.

Additionally, the vast majority of devices settle down to a DR after a dozen or so uplinks, at which point you can estimate battery life server side. They rarely bounce up & down unless you've got your ADR Link margin too low &/or delivery trucks park next to the device for a few days, blocking the signal.

When using small batteries

Mostly we don't. There are some that try to run LW off a coin cell with varying levels of success. But mostly we ensure that the battery can deliver. And that's 15mA continuous - what is the spec for bursts up to 1 second long? The Saft version is 100ma for 0.1 seconds - making for a viable option for a smaller device that doesn't need to uplink frequently - and that battery can do 35mA continuously so is OK for EU full power current draw on the newer radios. There are many devices with smaller batteries, some time they have a supercap to smooth out the load, but the vast majority of devices are using 2 x AA cells - more readily available for the end user and a heck of a lot less expensive.

It seems to me that an ADR profile that first reduces power to a non-stress level would be beneficial.

Indeed. And having the ADR profile match the device would be good - but this sort of thinking is outside the realms of the great & good that populate the ivory towers of corporate world. Semtech made recommendations and we are in IBM land where no one would challenge the King. Changing the code should be feasible.

What are you hoping for with this power measurement? As there is a radio attached, voodoo, black magic and the dark arts are all going to intervene in a highly tuned system to mess up your plans. Pretty much all the vendors have loads of caveats and clauses on the bold "battery life up to 10 years", some provide some basic calculators, some have some extremely detailed calculators, but none can account for environmental issues.