FiPy, Nb-IoT and Deepsleep

[tuftec]

I have been experimenting with the use NB-Iot on the FiPy and using deepsleep to save power.
After some assistance from Pycom support, I now appear to have working, stable code that uses relatively low power.

I have, however, found that the method I am using to connect to the NB-IoT network after coming out of deepsleep can typically take 20 seconds or so (using Vodafone network in Australia). This is considerably longer than the reconnect time for LoRa and Sigfox networks.
From discussion with colleagues using other IOT devices, I believe that reconnect times should be more like 3 seconds or so.
Is there a preferred method of re-connection after coming out of deepsleep that otimises the connect time (makes it as small as possible)?

I am essentially using the method as described in the LTE sample code given in the documentation. I do not do anything different from initial connection to a re-connection after deepsleep. I feel that there must be a method that recognises that the device has been previously connected and thereby minimises the time to reconnect.

[jcaron]

@tuftec LoRa and SigFox do not “reconnect”, once connected, provided the state is maintained in the device, they just send frames when you ask them to (there’s no need to “keep the connection alive” or anything like that with those).

I haven’t used either of the LTE techs, but have you checked past threads on PSM and eDRX? I’m not even sure they apply to NB-Iot rather than Cat-M1, though.

[agotsis]

@tuftec @jcaron I've been observing similar behavior, actually it takes 20-30 secs for me to connect to my local MNO, and some times even 2-3 minutes. I've noticed that this is dominated by the attachment procedure (lte.attach(...)), while the connection (lte.connect(...)) takes 2-3 seconds at most.

So, before deep sleep if I issue a lte.deinit(dettach=True,reset=True) command in order to fully deactivate the modem, then after waking up it will again take a lot of time to attach to the network. I tried not to detach the modem before deep sleep, just simple force lte.disconnect(), and the indeed the reconnection happened immediately. But then you lose all the benefits of deep sleep, since the modem remains practically active during deep sleep (I measured the current consumption and was around 150 mA).

I guess what @jcaron suggests is to leave the modem attached during deep sleep and save some power using the PSM/eDRX mechanisms. Haven't tried that yet, to be honest.

Cheers.

[tuftec]

I will research the PSM and eDRX threads, although I do not know what these are at this point.

It is important that the LTE modem is fully powered down to save battery power. Others I know, using other technology, do exactly this but do not seem to have the long reconnect times.
NB-IoT and presumably CAT-M1 is supposed to remember that a device was connected to a cell and it should not need to go through re-registration (attach) every time.
Is it possible to just re-establish the data connection without the reattach process after a deepsleep? Maybe using lte.deinit(dettach=False) will achieve this (do not dettach from the network). Or will this just leave the LTE modem powered up?

[agotsis]

@tuftec Actually lte.deinit(dettach=False) doesn't force dettaching, but it seems to leave some LTE modem functionalities open, causing deep sleep currents of 100-150 mA. Maybe this could be a bug of the LTE firmware or the FiPy firmware?

P.S. I have also just checked committing lte.send_at_cmd('AT+CFUN=0') and lte.send_at_cmd('AT+CFUN=1'), and again it takes a long time to attach.

[tuftec]

There appears to be clearly something wrong with the design implementation of the LTE functions.

NB-IoT is intended for low power, low data rate applications. It should be possible to power up, connect, send data and then go back to sleep within a few seconds.

In it's current state, the NB-IoT functions offer no advantages over a 3G/4G modem connection.

[robert-hh]

@tuftec This matches my observations. After power up, The Fipy with NB-IoT needs about 20 seconds to get connected. If power is maintained, the connection takes about 4 seconds. I have another NB-IoT module, SIM 7020E, which takes after power at least 2 seconds to run. Most of the time it is already connected, when the Pycom module us booted. So it looks as if the sequans modem or the Pycom software is re-doing a lot of stuff which is not needed for a re-connect.

[tuftec]

@robert-hh My thoughts exactly.

[jcaron]

@robert-hh there’s a long thread in the announcement of one of the 1.20 release candidates which was supposed to include support of PSM and eDRX. Haven’t read it all (I don’t use LTE), but I believe there may be interesting pointers in there. Not sure if the conclusion was positive though.

[robert-hh]

@jcaron Yes, I recall. That's still on my interest list. I have no real need for NBIot at the moment, so I just observe the behaviour, but did not try to optimize (yet).