Sodaq One power consumption

ONE
1

Gentlemen,

I am trying to lower the power consumption of the Sodaq One.

I use the following basic code:

void setup()
{
delay(10000);

USBDevice.detach();
delay(1000);
}

void loop()
{
SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;

__WFI();
}

This results in 25mA current, once the _WFI is reached.

Probably some devices (UBlox, MicroChip 2483) are powered on by default?

How to bring back the current to the absolute minimum?

Axel

2

The main things you need to do is make sure the GPS is off, and also put the LoRa module in sleep mode.

To ensure the GPS is off set GPS_ENABLE to OUTPUT and LOW.

To put the LoRa module to sleep for 60 seconds you will need to open Serial1 at 57600 and send (with line endings, e.g. using println()) the following command: “sys sleep 60000”. The duration is specified in milliseconds.

3

Hi Gabriel,

I changed the code according to your suggestions:

void setup()
{
delay(10000);

Serial1.begin(57000);
Serial1.println("sys sleep 60000");

pinMode(GPS_ENABLE, OUTPUT);
digitalWrite(GPS_ENABLE, 0);

USBDevice.detach();
delay(1000);

}

void loop()
{
systemSleep();
}

void systemSleep()
{
// SAMD sleep
__WFI();
}

Now have 8 mA.

Better, but still much to high.

Any ideas?

Axel

4

That figure is about right when the LoRa module is active.

I think there is an issue with your code and the LoRa module is still active.

Serial1.begin(57000);

You should use 57600 as the baud rate for the LoRa module.

5

Hi Gabriel,

Typo’s and dyslexia.

But with 57600 same result.

But this figure belongs to the LoRa module?

Is there a way we can verify the LoRa module is not active?

After one minute current is 11 mA.

Axel

6

I did some more testing and disabled the LSM303 too. Current is now 8,843 mA.

However, I noticed then when I omit the __WFI() call, the current stays also 8,843 mA.

The line : > SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk; is just before this call.

Is the DeepSleep failing or does the CPU use that little current that I don’t see the difference?

7

Here is an example which brings down the current to 50uAs.

The trick seems to be that you have to add a small delay after putting the LoRa module into sleep mode.

8

Hi Gabriel,

It works! (of course thinks Gabriel).

I was very close: my second sketch did have the delay, but in the mean time before I repaired my type,I also changed some other things.

Thanks again Gabriel!

Axel

9

@GabrielNotman, I don’t get anywhere near 50 uA when using this sketch. It’s 0.8 mA for me. If I add

USBDevice.detach();

Then the current drops to 0.36 mA, still not close to 50 uA. I disconnected the active GPS antenna, just to be sure, but that does not make any difference in sleep mode.

Any ideas where this remaining power use can be? I’m powering via USB, does that make a difference?

10

Are you using the sketch I provide above?

If so I would recommend measuring the current while powering the board with a battery.

11

@reneh You probably lose some power in the USB-to-3.3 V regulator. With a 3.7 V LiPo battery, I get a sleep current of about 70 uA with Gabriel’s sketch.

12

With some tweaking and tuning, I have the sleep current now down to 176 uA for the universal tracker software!

13

That is also what I am seeing. With the default sketch from Gabriel, no modifications whatsoever I get also something like 170 uAmp. So no where near the 50 uAmp.

14

Another thing that I see is that the power usage changes a lot. By flashing exactly the same code into the same device and using the same battery and measuring equipment, I see a different power usage every time the device boots. And the difference is rather big. One time it can be a steady 3 mA the next time a steady 300 uA and often I see it fluctuating between 200 uA and 500 uA.

15

I’ll have another look at it this evening.

If you are seeing such fluctuations, it is likely some component on the board is not powering down correctly. The 3mA reading suggests that it might be the LoRa chip.

16

I tested two version of the SodaqONE, tonight a Rev.2 board (BETA) and a Rev.3 board.

Using the above sketch the Rev.3 board read at ~45uAs, and the Rev.2 board at about ~53uAs.

One thing I would suggest is power cycling the board after uploading the test sketch. There are instances when the LoRa chip becomes unresponsive after programming the board. The power cycling the board resets the LoRa chip.

17

Hello Gabriel, do you also see these values after initializing the LoRa module, waking it up, sending a message and then putting the board into deep sleep? What we see is the following sequence after programming + a power cycle;

  • board does power up (~ 40 - 50mA)
  • setup runs, GPS powers down, LoRa powers down, LSM303 powers down, USB disconnects, we sometimes go to ~ 70 uA. But often it stays at 3 mA
  • In case we’ve seen the 70 uA we send a LoRa msg, then put the device back into deep sleep. In that case we never see anything in the micro amps, always milli amps.

It appears that when the LoRa chip has been used for transmitting anything, it refuses to go back to sleep.

We use code derived from Sodaq One Tracker (main code) and we use Sodaq libraries for the other parts (so we replaced the ublox code with the sodaq gps lib because we only power down the GPS, nothing else.)

The device wakes up every hour to send a status message and then goes back to deep sleep. At least that is what we try to do, the board always stays at 3 mA or higher.

18

My guess is that in some case it may be trying to send the command to the LoRa module to enter sleep mode to soon after the transmission. This is then resulting in that command being ignored.

Try adding a 10 second delay before trying to send the LoRa module to sleep and see if that fixes the issue.

19

I tried the timeout of 10 seconds but no success. The device stays at 6mA. (The last 10 times I loaded my sketch onto the board it was 6mA)

20

My bad, the universal tracker runs a watch-dog timer. A 10 second delay is sufficient to trigger the watch-dog timer to reboot the board if you have used the standard method delay(uint32_t ms).

The method sodaq_wdt_safe_delay(uint32_t ms) should be used instead.