Go Down

Topic: 12hr Sleep doesn't wake up (Read 1 time) previous topic - next topic



I am trying to get the MKR to report it'a battery voltage every twelve hours using the LowPower.sleep() function. i.er when it wakes up the default thing to do is report voltage.

In testing for short periods using LowPower.sleep(5 * 60 * 1000); it sleeps for exactly 5 mins no problem.

If I use LowPower.sleep(12 * 60 * 60 * 1000); it never wakes up.

Is there an upper limit to the timed interupt?


There is something weird with the compile of this call.  If you use L to implicitly declare a long number (ie: 30000L) the compiler throws an error.  I do not understand why it throws the error.

Try this:

uint32_t sleepTime;
sleepTime = 12 * 60 * 60 * 1000;
println( sleepTime );
LowPower.sleep( sleepTime );

And verify that the sleepTime being passed is correct.


Ok I can resolve this. The wake up works fine, it was the Multitech Conduit failing to pass the packet on.


Hi NeilE, Were you able to get sleep current below 1.16mA on the MKR WAN 1300?


Hi sslupsky,

No and i tried many combinations. It measures about 1158uA at best. I saw your other post saying that this a now a recognised issue with the version of the board. So good and bad news.

I was trying to do the firmware upgrade. I am on 1.12 (all 12 modules) and I see v1.16 is out there. I tried to load the MKRWAN.h example stand alone firmware updater but it won't compile as published so i got stuck.

Have you got this to work by any chance?



Hi NeilE,  I was able to update the firmware using the sketch MKRWANFWUpdate_standalone.ino.  Did you have all the files from that directory when you tried to compile the sketch?


Hi NeilE,

It gets worse.  I have not been able to get below 1.05mA in sleep with the VDD_TCXO modification.  Moreover, I have uncovered some design problems with the MKRWAN power supply.

I cross posted the following observations on the Github MKRWAN issue in case anyone else is following this at:


There is another problem(s) with the MKRWAN1300 design.

Having investigated the issue regarding the VDD_TCXO, I encountered erratic behaviour when power was applied to the Vbatt or VCC pins on the MKRWAN.

Looking at the power supply schematic for the MKRWAN, the VDD_USB pin of the Murata module is connected to the +5V net of the MKRWAN module.  When the MKRWAN is connected to a computer USB port, the voltage of than net will be close to 5V.  This voltage exceeds the maximum operating voltage of the VDD_USB pin (see Murata datasheet Table 2 - 3.6V) for the Murata module.  The voltage also exceeds the Absolute Maximum Ratings for the pin (see Murata datasheet Table 1 - 3.9V).  Thus, simply plugging the MKRWAN into a USB port will likely damage the Murata module.

Moreover, note 1 under Table 2 of the Murata datasheet reads, in part, that:

If the USB is not used, VDD_USB must be tied to VDD_MCU to be able to use PA11 and PA12 as standard I/Os.

When power is applied to the MKRWAN Vbatt or VCC, VDD_USB is floating and thus violates condition of note 1.  So, PA12 cannot be used to control VDD_TCXO in this condition.


Hi NeilE,

Good news.  When I corrected the VDD_USB issue by disconnecting it from the +5V net and attaching to the +3.3V net, the sleep current is about 8.5uA.


@sslupsky Well done, great work there.

I read your github page from the link above and I roughly follow it. It looks like a two step process

a) you cut/break the connection for VDD_TCXO
b) swap the connection to VDD_MCU from the 5V to the 3.3V feeds.

I can follow that on the schematic but I can't relate that to the physical v1 (since v2 is coming) board.

Any chance you could summarise your process (pics would be very usefull) of the mods to the board?



Hi NeilE,

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.

Go Up