MKRWAN1300 high current in sleep mode

@sebbad Have you make any progress with reducing the power consumption of the MKRWAN1300? I too am experiencing 1.16mA when sleeping.

@gproduct I think you have a floating input that is causing your 1.6mA. If you edit wiring.c and comment out the section to configures all gpio as inputs you should get to 1.16mA. Have you made any further progress?

I think the remaining milliamp comes from a hardware issue. The murata module has a temperature controlled oscillator, which is powered via one of its pins. It seems that this oscillator is not internally shutdown when the module goes to sleep. Instead, I have seen designs where the oscillator is powered via a GPIO of the host controller allowing to disable the oscillators power supply. In the arduino design, however, the oscillator is directly connected to the power supply.

I have posted a similar question in the Arduino forum, and am quite surprised (and disappointed) that the designers of this module do not comment on this. I hope this will issue will be considered in a future revision of this platform.

1 Like

@sslupsky – replying here instead of continuing the discussion on github :wink:

I haven’t made extensive research for low power, but I doubt I would make it better than you.
As @sebbad mentions the current draw most probably comes from the Murata module, and we have no impact on that.

I decided to workaround the problem with a TPL5110 and I am very optimistic with that – I need to control power anyway for my sensors.

Linked to that I have submitted some simple merge requests to support “ABP after OTAA” and externalize additional data through the Library.
It is pending review, but if you are interested my Library and firmware are available here.
The firmware is labeled 1.1.6-B02.

It is working fine for me, I am still looking at one additional feature: currently there is (afaik) no way to know when a send is complete (unless you ask packet confirmation which I don’t want), so I need to wait a couple of seconds before cutting power to ensure the packet is sent.

Hi @Amedee, You are likely aware now that there is a hardware design problem with the existing board that prevents it from achieving a sleep current below 1.15mA. I dropped off a couple boards today to have them modified to correct the defect. I should get them back later today.

Hi @sebbad, The Arduino guys got back to me today about this and acknowledged the issue with the VDD_TCXO pin. They are planning a v2 release but I have not heard when that will be available.

I dropped off a couple boards today with a guy that has an Oxford laser to have them modified to correct the defect. I should get them back later today to test them.

@Amedee, @sebbad There is another problem with the MKRWAN1300 related to the power supply for the Murata module. VDD_USB needs to be connected to the same supply as VDD_MCU.

The good news is that with the modifications to VDD_TCXO and VDD_USB I was able to achieve a sleep current of about 8.5uA.


@sslupsky Great to hear that 8.5µA are possible!

Could you please tell us the modifications you have done?

I assume the currennt measurement was done while powering the board by battery!?

Is it possible to do these changes without expensive tools?

Sorry, a lot of questions, but i realy like the board but suffer from the bad deep sleep values.

@aschroeder, Here are the instructions to do the mods and a photo.

Regarding the VDD_TCXO modification, in my opinion the best method is Option 2 that involves using a laser if you have access to one. With Option 1, there isn’t much space between the via and the Murata module to solder a wire to the trace after you drill the via.

tcxo and usb repair v3.pdf (1.4 MB)

1 Like

Good job for publishing the details, but for me this is a first, using a laser to rework a board.

I have a green laser which is great for pointing out stars in the sky, will that do ?

Hi @LoRaTracker LOL! Off the top of my mind I do not think the star pointer will work well. I had access to an Oxford laser with a 20um spot size. They are used for laser micro machining, micro drilling, etc.

Hey @sslupsky!

Thank you for the detailed information - great job. Unfortunately i think we have to wait for the next version from Arduino. Tinkering with an oxford laser is beyond our possibilities :frowning: .


I don’t have the the hardware nor the skills to modify the PCB, so I pursued the TPL5110 route.

There is obviously some overhead, but at least the sleep current is under 50 nA…

Running (I attached a small display for debugging):



Difficult to tell from the pictures, but are you feeding the Adafruiit TPL5110 thingie with 2 x AA LifePo4 in series as the power supply ?

Pictures are misleading, I was out of battery holder so I add to hack a bit for testing :roll_eyes:

I actually use a single 700mA LiFePo4 – one of the 2 batteries in the picture is a ‘dummy cell’ used as placeholder (which can be used when you want to replace 2 ‘dry’ cells by a LiFe)

This is BTW another stupid annoyance of this device: it has an 1/3 voltage divider, so the maximum you can measure is 3v using the 1v reference. So by the time your LiFe reaches 3v, it is almost empty…

1 Like

Hello Amedee
Sorry if the question is silly but how do you achieve such low current with the TPL5110? I looked at the specs and it says 20uA in Sleep mode. Am I missing something?

here it says 20uA:
and here it says 35nA:

So I guess there must be a typo on the Adafruit website

Right, the Adafruit data don’t make too much sense…
It can vary a bit, but you should stay way below 1µA

Thank you Amedee

I am a newby and I appreciate your help.

It sounds like the TPL5110 approach is an easy fix for nodes which are not low-power by design and only need to wake up at regular intervals. I have two questions if you may:

1/ from an energy efficiency point of view does it always make more sense (when possible) to completely switch off the device like above or can the overhead of a cold start be worse than a deep-sleep in some cases? Maybe this question very much depends on what’s in the Setup() function.

2/ in one of my applications I wish to wake the node through an external interrupt. I see that on the Adafruit TPL5110 board there is a button to manually wake the device. In your opinion could this be hacked and used as an external trigger?

Thank you

Re. 1: it really depends how long you need to setup()… If you want to drive e.g. particle sensors which typically needs to warm up, the problem won’t be the sleep time but the overall power usage when awake. The few mA in sleep won’t weight a lot against the awake power. Also do you want to be awake once a day or every minute? that will make a big difference as well.
I typically use a very basic spreadsheet where I enter my awake/sleep power usage and duty cycle to get an idea on the theoretical lifetime…
But most sensors don’t require a long setup time.

Re. 2: absolutely it is not a hack it is a feature of the TPL5110, when you pull M_DRV to VDD it will wake-up your device.

I think I already posted it, but I don’t see it immediately, I have published a proof of concept implementation which can help you to start. I have nodes running now for months on a 700mAh LiFePO4 battery.

Now, in my opinion this is only worth if you already have MKR nodes. If you don’t already have these consider something else which is designed with low-power in mind.

Thanks a bunch.

I have been playing with various boards such as the AirBoard+mDot, the MKR WAN 1300 (where is rev 2.0…?) and the Adafruit Feather 32u4 lately but most of them don’t achieve low enough current in sleep mode to enable non-rechargeable-battery-powered nodes with long life-time applications.

I just discovered your blog as well as the MiniLora project which I might look at closer. Lots of really interesting reading ahead :))

One thing I am also interested in is how to handle sensors which require too much current to be powered through a regular digital IO pin. In such case it seems a mosfet is the way to go to switch them ON/OFF.

All this to say you might see me around every now and then with questions… :slight_smile: and hopefully answers to newbees when I am savvy on the topic

@sebbad, I just have the same issue, and modem.sleep() won’t work because it’s not implemented in the AT firmware of Murata module, even if it’s on the MKR1300 library. That’s why it always return false and that’s a shame