PSM

[kjm]

I tried https://docs.pycom.io/tutorials/networks/lte/power/ and deepsleep current dropped to 300uA (x10 normal but still low enough to be usable in a solar powered situation like mine). Better still the fipy took 0 secs to attach when it woke up, very nice. I'd like to wakeup for 30s every 10 mins do some uploads/downloads then deepsleep for 9.5mins. Can someone tell me how to modify

lte = LTE(psm_period_value=1, psm_period_unit=LTE.PSM_PERIOD_1H,
          psm_active_value=5, psm_active_unit=LTE.PSM_ACTIVE_2S )

to achieve this? Also how to check what values the telco decides to offer?

[kjm]

I revisited this, turns out the drop to 300uA was caused by me flicking the range switch on the old school ammeter I was using to monitor current. Without the brief interruption to supply caused by the range switch the PSM current is 20mA, hardly battery friendly.

[kjm]

Finally got 25uA deepsleep with PSM on a cat M1 FiPy (1.20.2.rc9 with LR5.2.1.0-48829) via https://development.pycom.io/tutorials/lte/power/. We're having trouble understanding the purpose of these period/active timers in that the modem is still attached when it wakes from deepsleep regardless of whether its actual period/active duty cycle matches that specified in

lte = LTE(psm_period_value=1, psm_period_unit=LTE.PSM_PERIOD_1H,
          psm_active_value=5, psm_active_unit=LTE.PSM_ACTIVE_2S )

Setup lte to be 10s active every hour then actually be 20s active every 10 mins & the scheme seems to work, which is nice, but what's the point of specifying a duty cycle if there's no need to stick to it?

[peterp]

@kjm PSM doesn't really have an impact on the deepsleep current. The LTE modem is basically off after lte.deinit(), regardless of PSM or not. It should reach the same consumption. When the modem is turned on again (lte.init()) with PSM it is still attached and does not need to attach again, so it saves the time and power for that.

The PSM period is how long the network will remember the device even though it was off (lte.deinit(), with or without deepsleep). The module is allowed to come back earlier, but not later.

The active time is for how long the modem will be able to receive a downlink after an uplink. It does not impose a limitation on when an uplink is allowed.

[kjm]

@peterp thnx Peter. Given your explanation it would seem reasonable to set both timers as long as possible?

Also do you know if the timers effect how long it takes for deepsleep current to drop to a low value. In our testing we notice a pulsing current behaviour after machine.deepsleep that persists for up to a minute before dropping to 25uA but we can't see a link between the pulsing duration and the period/active values we choose.

[jcaron]

@kjm The period is how long you can sleep, so you could indeed hike it up as much as possible.

When you wake up and send data to the network (uplink), the network will know you are active, and take the opportunity to send queued data to the device (downlink). You tell the network how long you remain active so they know how long they have to send that data. So the active value should be shorter than the actual time you remain awake after the uplink. Otherwise the network could send data too late, thinking the device is awake when it isn't any longer.

Note that in both cases, it's only a request, the network is not forced to honour it, it will send back the actual values it chose.

[peterp]

@kjm probably Period you can safely set to as long as possible. I can't think of any downside of this being 'too long' as long as the network accepts your setting.

Active time, depends a bit more on your use case I'd say and probably also warrants some extra experimentation that firmware version/provider behaviour results in lowest consumption. For lowest power, you want this to be as short as possible. If you want to be reachable for downlink, well then this determines how high you want to put it.

For the pulsing after lte.deinit(detach=False);machine.deepsleep() - I'm not 100% sure right now.

Ah, I was too slow with typing - yes, what @jcaron said ;)

[kjm]

@jcaron Network queued data is a new concept for me. Currently I do a https POST to a server & expect a prompt server reply confirming reception. Similarly I use GET if I want something from the server & likewise expect a prompt reply. Where does networking queueing work it's way into this?

[James Pruet]

@kjm Any chance you could share some code or particulars you did to get down to the 25 uA during deepsleep with PSM? I'm getting 300 uA and the pulsing you mentioned.

[kjm]

@James-Pruet Long time since we did that James, pretty sure we just followed the tutorial

# main
# period 1h, active 10s
lte = LTE(psm_period_value=1, psm_period_unit=LTE.PSM_PERIOD_1H,
          psm_active_value=5, psm_active_unit=LTE.PSM_ACTIVE_2S )
print(lte.psm())
attach()
connect()
http_get()
print("deinit")
lte.deinit(detach=False, reset=False)
print("deepsleep")
machine.deepsleep(55 * 60 * 1000) # 55m

My memory of that episode is we had to wait for a good half minute or so from the start of deepsleep for the current to finally plunge down to 25uA