High sleep current

[sslupsky]

Hello, I've been working with the MKRWAN1300 and evaluating the sleep performance. I believe I have successfully achieved sleep. However the sleep current is 1.16mA. Is it possible to achieve a sleep current with the MKRWAN1300 of less than 1.16mA?

I have found community reports for other SAMD21 products that achieve a lower sleep current. However, I have not found a report that confirms a sleep current less than 1.16mA for the MKRWAN1300 is achievable.

My hardware configuration is 3.3V power is applied to the Vbatt input. USB is disconnected. A0 (DAC output) is connected to A1 (ADC input).

At the moment I suspect a bug in the MKRWAN firmware preventing the Murata device from sleeping properly but I haven't found anything yet.

Wiring.c in the Arduino library was updated to remove initialization of the IO as floating inputs. I have attached my sketch below for reference.

#include <Arduino.h>
#include <ArduinoLog.h>
#include <ArduinoLowPower.h>
#include <MKRWAN.h>
#include <ZeroRegs.h>
#include <RTCZero.h>
#include "arduino_secrets.h"

#define SLEEP_PERIOD ( (uint32_t) 5000 )

// ADC configuration
#define extSensorPin PIN_A1
#define extSensorEnablePin 1

LoRaModem modem;
static uint32_t msgCount = 0;
bool regsShown = false;
// RTCZero rtc;

// Uncomment if using the Murata chip as a module
// LoRaModem modem(Serial1);

// Please enter your sensitive data in the Secret tab or arduino_secrets.h
String appEui = SECRET_APP_EUI;
String appKey = SECRET_APP_KEY;

void blink( int numBlink = 1, unsigned int speed = 200 ) {
  int i;
  while ( numBlink-- ) {
    digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
    delay(speed);                       // wait
    digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
    delay(speed);                       // wait
  }
}

void printTimeStamp(Print* _logOutput) {
  char c[12];
  int m = sprintf(c, "%10lu ", millis());
  _logOutput->print(c);
}

void printNewline(Print* _logOutput) {
  _logOutput->print('\n');
}

void reboot() {
  NVIC_SystemReset();
  while(1) ;
}

void pinStr( uint32_t ulPin, unsigned strength) // works like pinMode(), but to set drive strength
{
  // Handle the case the pin isn't usable as PIO
  if ( g_APinDescription[ulPin].ulPinType == PIO_NOT_A_PIN )
  {
    return ;
  }
  if(strength) strength = 1;      // set drive strength to either 0 or 1 copied
  PORT->Group[g_APinDescription[ulPin].ulPort].PINCFG[g_APinDescription[ulPin].ulPin].bit.DRVSTR = strength ;
}

void InitIO() {
  //  Note:  wiring.c initializes all GPIO as inputs with no pull ups ... it has been modified to eliminate this

  // Configure digital pins used by the application
  pinMode(LED_BUILTIN, OUTPUT);
  pinMode(extSensorPin, OUTPUT);
  pinStr(extSensorPin, 1);
  digitalWrite(extSensorEnablePin, LOW);

  // Configure the ADC
  analogReadResolution(12);
  analogWriteResolution(12);
  analogReference(AR_INTERNAL1V65);
}

void alarmEvent() {
// RTC alarm wake interrupt callback
// do nothing
}

void setup() {
  Log.begin(LOG_LEVEL_VERBOSE, &Serial, true);

  InitIO();

  Serial.begin(115200);
  int waitForSerial = 5;
  while (!Serial && !Serial.available() && waitForSerial ) {
    delay(2000);
    blink(2);
    waitForSerial--;
  }
  Log.notice(F("Start" CR));

  // initialize the RTC - need to do this or the sleep function is unreliable after reset
  // rtc.begin(false);
  LowPower.attachInterruptWakeup(RTC_ALARM_WAKEUP, alarmEvent, CHANGE);

//  Log.notice(F("Reset modem ..." CR));
//  modem.restart();  // This does not work for some reason
  Log.notice(F("Initialize modem ..." CR));
  if (!modem.begin(US915_HYBRID)) {
    Log.error(F("Failed to start module, rebooting MKRWAN in 1 seconds ..." CR));
    delay(1000);
    reboot();
  };
  Log.notice(F("Your module version is: %s" CR), modem.version().c_str());
  Log.notice(F("Your device EUI is: %s" CR), modem.deviceEUI().c_str());

  int connected = modem.connected();
  if ( !connected ) {
    int joinFailed = 0;
    while ( !connected && joinFailed < 10 ) {
      connected = modem.joinOTAA(appEui, appKey);
      if (!connected) {
        Log.notice(F("LoRaWAN network not joined, retry join in 60 seconds ..." CR));
        blink(1);
        delay(60000);
        joinFailed++;
      }    
    }
  }
  if ( connected ) {
    Log.notice(F("LoRaWAN network joined" CR));
    modem.setPort(10);
    modem.dataRate(3);
    modem.setADR(true);
    blink(3);
  }
}

void loop() {
  blink(3);
  Log.notice(F("Wake" CR));

  // Dump SAMD21 registers
  if ( Serial ) {
    if (! regsShown ) {
      ZeroRegOptions opts = { Serial, false };
      printZeroRegs(opts);
      regsShown = true;
    } 
  } else {
      regsShown = false;
  }

  digitalWrite(extSensorEnablePin, HIGH);
  analogWrite(PIN_A0, 1024);  // apply voltage to DAC to test analog input
  delay(10);
  int extSensor = analogRead(extSensorPin);
  digitalWrite(extSensorEnablePin, LOW);
  int err;
  String msg = "Sleep Test:" + String(msgCount) + ":" + String(extSensor);
  modem.beginPacket();
  modem.print(msg);
  err = modem.endPacket(true);
  if (err > 0) {
    Log.notice(F("LoRa message sent: %l, vwc = 0x%x" CR), msgCount, extSensor);
    msgCount++;
    blink(2);
  } else {
    Log.notice(F("LoRa error sending message: %l, vwc = 0x%x" CR), msgCount, extSensor);
    blink(1);
  }

  delay(1000);
  blink(3);
  LowPower.deepSleep(SLEEP_PERIOD);
}

[facchinm]

Hi @sslupsky,

we've been tracking down the issue and it is an hardware problem indeed.
The issue is related with VDD_TCXO being always on, also when the module goes into deep sleep modes.
With the actual hardware the minimum power consumption is 1.15mA as you correctly found out.
We are going to produce rev2 of the boards with this problem fixed; if the target is not a 10-years battery powered device the current revision is still fine, otherwise we'll provide a replacement board as soon as it's available via the usual support channels.

[sslupsky]

@facchinm Thank you for the update, this is helpful to understand the problem. Page 8 of the Murata Specification BP-ABZ-B (Reference circuit) says:

_for VDD_TCXO connection
Option1: Connect VDD_TCXO to VDD
Option2: Connect VDD_TCXO to PA12 to make sure MCU can control TCXO on/off

The board designer selected option 1 but really we need option 2 to achieve low power.

Does the firmware have the ability to control the VDD_TCXO using PA12? If I can arrange to cut the power plane connection (using a laser) slightly to the left of the via above pin 48 and wire pin 48 to pin 1, will that fix the problem? Can you confirm if you have been able to test this in your lab and what power consumption you achieved by turning VDD_TCXO off?

[facchinm]

@sslupsky I can confirm that cutting the (tiny) net between the via and the module brings the consumption down to the expected 30uA (this completely breaks the transmission capabilities); I've not been able to solder the right side of the net with PA12 testpoint but the code already controls that pin (see https://github.com/arduino/mkrwan1300-fw/blob/master/Drivers/BSP/MLM32L07X01/mlm32l07x01.c#L138) so, if you were able to do this operation, I expect the board to behave exactly as v2

[sslupsky]

@facchinm Thank you. I will see if I can get this done today and test it.

When do you expect the v2 board will be available?

[sslupsky]

Hi @facchinm I have a company here that has a laser that can cut an annulus around the via from the bottom of the board. I dropped off two boards and asked them make the modification to both boards. I'll let you know how they turn out when I get them back.

I would like to order 50 pcs of the v2 board. Any idea yet when I could do that?

[sslupsky]

Hi @facchinm, I have made the modification however there is still an issue.

When powered by USB, the board boots, the sketch does its customary wait for serial timeout and then joins the LoRa network using OTAA. After this the sketch sends a LoRa message and then goes to sleep. When you look at the PA12/VDD_TCXO pin on an oscilloscope, I can see it toggle from 0V to 3.3V when the Murata module is accessing the LoRa network. Everything appears to work as expected.

When powered by applying 3.3V to the Vbatt terminal block (or directly to the VCC pin), the sketch does its customary wait for serial timeout and then fails to join the LoRa network. When you look at the PA12/VDD_TCXO pin on an oscilloscope, I can see the pin toggle to about 1.0V when the Murata module is attempting to access the LoRa network. It appears to me there must be some kind of contention between the PA12 pin and something else but I haven't figured it out yet. I have checked and there is no short between the PA12 pin and VDD or GND or either of the two traces (MISO and SCK) that run close by the via. I suspect that what ever is causing the wrong signal levels on PA12 doesn't power up the TCXO and this is why the module will not join the LoRa network. Since there doesn't appear to be any external reason for contention I can only conclude that the contention is coming from inside the module. Is there some other control signal internal to the Murata module connected to VDD_TCXO? Is there some power sequencing issue causing the module to behave differently?

Oddly, if I apply 3.3V to the Vin pin on the module, the sketch does its customary wait for serial timeout and then joins the LoRa network using OTAA. After this the sketch sends a LoRa message and then goes to sleep. When you look at the PA12/VDD_TCXO pin on an oscilloscope, I can see it toggle to 3.3V when the Murata module is accessing the LoRa network. Everything appears to work as expected. The sleep current is about 5.08mA. If I subtract the current used for the power LED of 4.03mA that still leaves about 1.05mA. This is not much different from when the VDD_TCXO was wired to +3.3V and certainly not close to the 30uA you mentioned earlier.

[sslupsky]

Hello @facchinm, 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 (see my post above).

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.

I think this last note explains the erratic behaviour I noted above in my earlier post regarding application of power to the Vbatt or VCC pins.

[sslupsky]

@facchinm, Good news. When I corrected the VDD_USB issue by disconnecting it from the +5V net and attaching to the +3.3V net, the board boots, the sketch does its customary wait for serial timeout and then joins the LoRa network using OTAA. After this the sketch sends a LoRa message and then goes to sleep. When you look at the PA12/VDD_TCXO pin on an oscilloscope, I can see it toggle from 0V to 3.3V when the Murata module is accessing the LoRa network. Everything appears to work as expected.

The sleep current is about 8.5uA.

[facchinm]

@sslupsky I forgot to tell you about the VDD_USB change, my bad. I wrongly thought it wasn't necessary to achieve low power but only needed to be fixed because we were (are) out of specs. Glad to hear you fixed both the problems.
Even lower power consumption can be achieved by powering the board from Vbatt with less than 3.3V (2V is the minimum to wakeup the samd core, probably the radio needs a bit more anyway).

[sslupsky]

@facchinm That's interesting. Do you have any information regarding the output power of the radio at the lower voltages? If I use 20 dB output power, will I still get 20 dB out at 2.7, 2.5, 2.3V? Also, do you know if receive sensitivity affected by the supply voltage? Overall, if the link budget is not affected then I would prefer to use a lower voltage.

[facchinm]

Link budget will surely be affected under 2.4 V (from the datasheet)

When module is on +20dBm operation, the supply of the voltage should be set from 2.4V to 3.6V

However I tested the radio functionality (both RX and TX) with an indoor gateway at very low voltages (just over 2.1V) and the communication is not affected.
Of course they are corner cases (it will probably won't work so well in open field)

[sslupsky]

I will reduce my power supply to 2.4V and see report back.

[ghost]

@facchinm Martino, is ABX00017-B the version of the board that should allow to reach the low power consumption mentioned above? @sslupsky seems to have a fixed it (my full respect for his work!) however I do not feel comfortable to try what he described in https://forum.arduino.cc/index.php?topic=568151.0

[mjunior-fitec]

Hello @facchinm !
Please give us some reliable information about this issue. It's been more than 2 months you told that Arduino team had a solution for the power problem and we still don't know when a rev2 will be available.

I need to buy some 80 pieces, and it would be very important to know when the corrected board will be ready, 'cause this can influence our buying decision. I have 5 pieces here and will try to correct them, following @sslupsky directions. As soon as I have results I will share with you guys.

Thanks in advance.

[sslupsky]

Hi @facchinm ,

I found one other hardware item that you may be already aware of.

I designed a board to hold the MKR WAN. The board has a battery, low power switching regulator, led, sensors, connectors among other things. One of the techniques I use to switch off the battery involves the +5V net from the MKR WAN header. I have noticed that the voltage on this net was a little over 1V with nothing connected to the USB port or the VIN on the MKR WAN. Moreover, the voltage only appears when the MKR WAN is awake.

I tracked the problem down to the SAMD21 USB port. When the SAMD21 is awake, the USB port pins drive a voltage onto the USB data lines. The MKR WAN has ESD protection device (D1) connected to the data lines and the protection devices are connected to the VUSB net. I have observed that when the USB port is not connected to an external device, the ESD diodes forward bias and put VDD - 0.7 V onto the MKR WAN VUSB net. Moreover, I have observed that the MKR WAN usb power supply switches (Q1a and Q1b) turn on and the VUSB voltage is applied to the +5V net. The undesired turn on of the switches is likely because the voltage divider on the gate of Q4.

The consequence of this are two fold: One, it caused the FET I was using to turn off the battery to turn on which subsequently turned off the battery when I did not want that to happen. I believe I can correct this at my end by using a voltage divider on the gate of the FET. The second consequence is a increase in power consumption when the device is awake. I think (but haven't tried yet) that if you detach the USB port the USB pins are tri-stated and any pull ups are turned off. Is this understanding correct? If this turns out to be the case, then the power consumption issue can be addressed as well.

So, if the board rev is not yet complete, you might consider evaluating the voltage divider on the gate of Q4 and adjusting the values of these resistors to prevent turn on when VUSB is below about 3V.

[mbeneck]

@facchinm I'm also curious about a timeline for V2 rev that addresses this issue. Even if its just a really rough estimate, i.e. weeks/months/a year that would help me to decide how far to pursue reworking existing boards. Thanks!

[sslupsky]

Hi @facchinm . ETA I received from customer support for the next board revision back in September was two months. It is March 2019 now. Can you tell me if the next hardware revision is available? I manually modified 50 boards back in October and it cost me more to mod the boards than it did for the mkrwan's. I would really like to avoid the additional cost this time around :-)

[cp-boettcher]

Hello, we want to carry out a citizen science project next year. We would order up to 100 pieces. It would be extremely interesting for us to use v2 because we have to change the batteries far too often at the moment. Will the revised v2 be available soon? Best regards

[paddygoat]

Please give us some indication of when rev2 boards are available ..... Please? .... grovel ... grovel ..... Pretty Please? .... more grovelling .....

[aheit33]

@sslupsky are you interested in selling any of your modified devices?

[sslupsky]

@aheit33 The last batch of boards I modified has been all used up. I could make arrangements to modify some additional boards. How many do you need?

I think the new version might be getting close to release. Check with @facchinm and see if there is a time table for release of the new board.

[facchinm]

@aheit33 the boards are surely coming by mid october, I'm not able in this moment to give you a precise date but within a month they'll be generally available.

[sierrasprout]

@facchinm Hello, are the rev2 boards w/low power fix released and available? Many thanks.

[facchinm]

@sierrasprout yup, they are here https://store.arduino.cc/mkr-wan-1310 😉

[sierrasprout]

@facchinm Thank you!

[loppylulu]

Hello guys,

Do you have any idea if this is a problem for the NB 1500 as well?

[humbertokramm]

I'm sorry, I only detected this problem in 2020. As I understand it, I have to change the VBUS power supply for the murata module from 5V to 3V3.
I also need to change the power supply from the VDD_TXC0 from 3V3 to the PA12 of the murata module. But my question is ...
how do i set the PA12 pin to release 3V3 when the module exits sleep mode?

[sslupsky]

@humbertokramm Are you using the 1300 or the 1310?

Regarding the 1300, I believe the Murata firmware controls the TXCO using PA12. So, you do not need to change anything else, you just need to make the hardware modification and "it just works".

However, IMO, it would be cheaper to use the MKR WAN 1310, if that is an option, than to make the modifications to the 1300. The caveat is that to achieve the same power consumption level that as the 1300, you need to disable the 1310's power supply (there is a jumper for this) and use a separate 3V supply.

[humbertokramm]

@sslupsky , I am using 1300 😔
last night i went to do some current measurements on it and discovered this problem.

I have two here. And I am developing a prototype. I will have to be very skilled to make this change, as I don't have many options.

These modules had been stored for a long time, and I decided to return to this subject due to the pandemic. I did a firmware update recently, so I think it must be updated with the murata firmware.

[sslupsky]

@humbertokramm The murata firmware update process is very different from updating the Arduino IDE. You flash an "update sketch" to the 1300 and then run it. The update sketch then flashes the murata device with an image of the murata firmware binary contained within the sketch. I believe the latest release version of the murata firmware is 1.2. There is another version being tested at the moment but it breaks the protocol between the murata device and the samd mcu. That requires quite a bit of change on my end so I haven't worked with it much yet.

The changes to the 1300 are quite tricky to make. You need to very precisely cut some traces and drill out a via.

It is unfortunate the 1310 power supply was not optimized for improved power consumption. Sleep current of more than 100uA is a major concern for battery powered applications.

[humbertokramm]

good to know that in time.
I was reluctant to put a lithium battery and a solar panel in my application, but I see that it will have to be a solution.

[LDBM]

Hi,
I just posted on the arduino MKR forum this post about power usage in sleep mode . Is it the same issue as what has been described in this thread here? I am stuck at 600uA and would like to get to 100uA or less if possible. Thanks.
L.

[tipo1000A]

Looking at MKR WAN 1310 schematic Murata PA12 is not connected to anything (except DP flashing pad).
So this issue was not fixed in MKR WAN 1310? Or am I missing something here...?

[sslupsky]

@tipo1000A The Murata wiring problem was fixed with the 1310. There is an issue with the power supply though so you need to disconnect the onboard power supply by cutting the jumper to achieve the lowest power consumption.

[tipo1000A]

How Arduino (SAMD21) puts Murata module into "Sleep"?

[sslupsky]

@tipo1000A It doesn't, the module controls sleeping. If there is nothing to do, the module goes to sleep automatically.

[Dicko87]

I am also wanting to achieve low power consumption when sleeping using the WAN1310 but I can only get down to 4mA. I have not cut a solder jumper as I am powering from 3.7V LiPo. If I cut the jumper, the battery connector won’t work, so can I then use the 3.7V and apply that to VIn or does Vin have to be 5V? Any help to achieve low power would be great, thanks.