Pytrack GNSS low power mode and lorawan

[NicolaC]

Hi,
I'm going to buy a pytrack ex. board but I need to know if the following workflow works:

1. Fipy in deep_sleep gets interrupt from accelerometer
2. When alive it can switch on the GNSS module in order to get ALT, LONG, LAT
3. When these value are available the FiPy send via LoraWan the GPS parameters
4. before to go to sleep Fipy sends "off" command or low power command to gnss
5. Fipy returns to sleep for 5 min or when accelerometer gets event (any radio, GNSS are switched off)

Could you confirm these ?
Thanks a lot
Nico

[NicolaC]

@jcaron said in Pytrack GNSS low power mode and lorawan:

enough

Hi Jcaron,
thanks for these information.
I will use in my custom PCB the sensor you mentioned (thanks for this info) cause I dont need the direction.
So the last configuration you suggest (about 10 month) should be the right direction for me.
Maybe I will implement the GNSS on board that will be switched on only when the operator (network server) will send a command in the RX windows of the Lora sensor; in this way we roughly Know where the object is in the last RX windows even if it will draw battery.
Thank you for the support, I'll keep you updated .
Nico

[jcaron]

@NicolaC There was a discussion on this topic here, you may find some figures in there, though there are lots of variables.

Waking up every 10 minutes will probably cost you dearly in terms of battery life.

If you use Pysense (or Pytrack) controlled deep sleep, you can get down to about 10-12 µA without accelerometer wake-up, just timer + wake on pin. With the accelerometer enabled my last attempts (a long time ago) brought it up to over 300 µA.

If you use the "native" deep sleep you should be able to get down to less than 20 µA with all sensors disabled. The accelerometer should use somewhere between 60 and 180 µA with the right settings IIRC. There may be other sensors that use less power. If the only thing that matters for you is "the thing moved", and you don't care about direction, how fast, etc, then a device like this one is cheap and will use no power at all until there's movement.

When you wake up (on timer or interrupt), it'll take at least 4 seconds to send your data and go back to sleep if you use SF12 (time to wake up, send the frame, wait for RX1 and RX2, go back to sleep), more if the network's RX delay is higher than the default 1 second, possibly a bit less if you use a faster data rate.

During the wake up time, count about 50 mA, though you should measure that more precisely based on your exact scenario, it varies a lot during the whole awake cycle, with a big short peak at startup, more high current draw during TX, less (but still in the tens of mA range) while waiting for RX1 and RX2. Last time I checked, the implementation of the LoRa stack means there's a thread polling state every ms, instead of using proper queue waiting, so you can't use light sleep modes.

That means that if you wake up every 10 minutes at stay awake 4 seconds, with deep sleep current at 10 µA and awake current at 50 mA average, your average current is about 340 µA. With a 2500 mAh battery, that's about 10 months. That's probably a bit on the optimistic side.

If you wake up more often, stay awake longer, or draw more power either awake or sleeping, your battery life goes down.

Note that you DO NOT join every time you wake up. You join once, save the LoRaWAN state, and then on each cycle you restore, send, save, sleep. That takes long enough.

[NicolaC]

jcaron,
Thanks a lot for reply: very interesting.

Lets say I will buy a Lopy and Pysense (no LTE and GPS) and I will switch off the Wifi and BLE at boot of my pycom board, how much will be my power consumption with the following configuration in your opinion :

• cyclic sleep every 10 minutes and sending few bytes (battery level and one generic byte of "alarm")

• accelerometer interrupt and sending few bytes (battery level and one generic byte of "alarm") to the LoraWan gateway ?

• if no Lorawan join procedure in the steps above have happened for 5 seconds (or a time you suggest) or a minimum time go to sleep again

In this configuration I would buy a Pysense and a Lopy just for testing but the next step will be to make a custom PCB with OEM pycom module but I need to know how to calculate battery usage. For this I need some info :

• current value in active mode (LoraWn Tx) and deep sleep?

• How many second it takes to join to lorawan gateway with OTA and send data

LTE is not mandatory for me but I wonder why (if it is not so) fipy doesnt power up the LTE and GPS using P-channel mosfet driven with fipy GPIO ?

Hope you can help in defining this power budget
Thanks a lot
Nico

[jcaron]

@NicolaC Broadly, yes. However:

• Deep sleep, especially for a Fipy and with a Pytrack attached, can be tricky. There are several ways of doing this, each with its own pros and cons, and it can be difficult to get something that is both stable and with actual low power draw. If you don't actually use LTE, you're probably better off using a module without the LTE modem, it adds quite a bit of complexity to the deep sleep issues.

• In my tests (a while ago) using the Pysense-controlled deep sleep rather than the native deep sleep, keeping the accelerometer on led to a relatively high sleep current (> 300 µA). I'm not sure this has been resolved since. It may work better with native deep sleep.

• It can take a while for the GNSS chip to get a fix after you start it. A cold start TTFF can take many minutes. Depending on the actual sleep mode you put the L76 in, you could get into cold start quite easily. Even if the L76 can retain the required data during the sleep periods, the data has limited validity, so once in a while it needs to listen to what the satellites send for a long while to refresh that data. There could be options leveraging A-GPS, though I'm not sure the L76 is able to do that (and I don't think I've seen anything in that direction on the forum). I have personally never used the Pytrack, so I can't directly comment on what is possible or isn't.

• You can definitely send data over LoRaWAN. However, remember that in many regions (e.g. the EU region) there are limits on how much you can "talk" (often 1% of the time), and the slower modulations (those that supposedly have the long ranges) mean that a single minimal frame will take over 1.5 seconds to send, so you can't send more often than once per 2.5 minutes on average. Much less if you send more data per frame. Also, depending on your application, remember that in the majority of cases LoRaWAN frames are not acknowledged, so you can't guarantee delivery.

• Even without waiting for the L76 fix, the whole wake-up-send-sleep cycle will take a few seconds (and can be very dependent on network settings — I had the issue of a network that set the RX window to 5 seconds, which nearly doubled awake time), and a lot more if you have a larger code base for a lot of processing (shouldn't be the case here). Frequent wake ups at 5 minute intervals will therefore draw quite a lot on your battery. If your device has an external power source, or it can be recharged regularly, it's not an issue. If your device needs to last a year on a single charge, it will most definitely be an issue unless you pack a really big battery.

Good luck with your project, let us know how things work out!