LTE timeout should be configurable

[coderbyheart]

Searching for LTE connection... timeout in 10 minutes

Currently it seems to be fixed to 10 minutes.

[coderbyheart]

The config property is called celt.

See bifravst/bifravst@5797295

[simensrostad]

This LTE timeout is possibly not needed. The idea is that the modem is configured at boot by the application and that the modem decides when it timeouts the different LTE network modes. As of right now the timeout is in the app to perform a blocking wait of connected to LTE network responses from the modem. Instead the application should only configure the modem and start performing other tasks, and just ask the modem if a connection is valid every time it wants to publish data

[coderbyheart]

The modem has a configuration value for the timeout: LTE_NETWORK_TIMEOUT, which defaults to 600 seconds.

This should be configurable by the application to adapt to the respective use case and to fine tune energy consumption. Depending on the use-case scenario 10 minutes might be rather long (e.g. for a slow moving / not moving device).

[coderbyheart]

Relevant source code: https://github.com/NordicPlayground/fw-nrfconnect-nrf/blob/0f8ceeac22120af2ddd927e4bc6aa9222f0e37e4/lib/lte_link_control/lte_lc.c#L258

[simensrostad]

Yes, but that option is compile-time atm. I believe the lte_lc.c module is currently being reworked to an extent. @jtguggedal Could you shed some light on some of the future improvements of the link controller module, and how it will handle different network modes and corresponding timeout?

[jtguggedal]

Currently the only way to set a connection timeout is the compile time CONFIG_LTE_NETWORK_TIMEOUT. I'm working on adding an async alternative that simply calls a connect function and then waits for a "LTE connected" event. The app can then decide how long it wants to wait for that, which can be configured runtime if one desires. Note that the timeout settings are app-side only, and the modem searches forever if it's not stopped by the app.

Currently, a workaround is to let the app send an AT command to the modem to stop searching for network. The lte_lc_connect call will still block untilthe timeout expires, but the modem will not actually be searching. It's hacky and probably not what you want anyway, but it's doable.

[simensrostad]

So, postpone this implementation until the new features in the link controller are in place. From an energy perspective doing a blocking wait at boot for connection probably doesn't have a lot of overhead, since the link controller thread sleeps in between "modem callbacks". My concern is that during this time the application can do other stuff like, search for a GPS fix and obtain time. So that when the device eventually connects to LTE, atleast time has been obtained. This way a potential DNS/NTP request can be avoided since the date time module can rely on GPS time. But on the other hand. From a developer point of view it is nice to have a confirmed LTE connection right after boot. So I guess it depends on the intention of the cat tracker firmware. Do we want to provide the most energy efficient solution possible given the circumstance or make room for such "developer friendly solutions".

[coderbyheart]

Do we want to provide the most energy efficient solution possible given the circumstance or make room for such "developer friendly solutions".

The goal is to show the most energy efficient way (ULP!), we have enough developer friendly samples which don't consider energy efficiency to make it easy for humans.

So, don't implement a hack, just to have a fake timeout. I wan't this solved with a real configurable timeout, if this is not possible right now, then let's revisit this later.

[coderbyheart]

Haven't heard about this, so I assume it's not supported right now.
If needed please start a new discussion here.