Hi all,
I’ve had pretty good success getting LoRaWAN nodes up and running using the Pro RF board. The next step in my progress is to start reducing power consumption, and I’ve tried quite a few things, but I am struggling to get anything that remotely resembles “low power.” I feel like I’m missing something obvious.
Best progress so far has been to disable the power LED (worth ~2mA), disconnect any peripherals from the board, setting A0-A5 and pins 0-13 low (worth ~1mA), and use the RTC library to get into sleep mode. On power-up, my multimeter indicates about 30mA, once some simple code starts running, it is around 57mA, and with sleep mode, it returns to about 30mA.
I did try to put the radio module to sleep, but in the LMIC library the hal_sleep function is empty, and LMIC_shutdown doesn’t make a difference.
I don’t really need to get down to the SAM datasheet levels of low-power, but getting down below 1mA would be great - just don’t have any idea how to get there.
So, after many more attempts to get this to use less power, including shutting off many peripherals on the SAMD21, I haven’t had much luck. Best I’ve seen is about 30mA during sleep. This includes bypassing the charging circuit and voltage regulator by using a second board to power it via the Qwiic connector. So, I think it must either be the SAMD21 that’s using the power even in sleep mode, or somehow the RFM95W.
Are you sure you’re not just measuring the burden voltage of your multimeter?
Sorry for the slow reply, but yes, I am sure of that. Other SAMD21 boards read much, much lower with the same DMM. And I’ve also tested with a CurrentRanger, pretty much the same results. FWIW, I was able to get a Moteino M0 board down to a reading of about 6uA out of the box… the CurrentRanger will have some error down that low, of course, but that’s about 5000x better regardless. And that was with the same radio module attached.
Hi mantonakakis,
Interesting. Theoretically, you should be able to get the Pro RF down to well below 30mA during sleep mode, especially if you are bypassing the 3.3V regulator on the board. What code are you using to try and enter sleep mode? Does it have any debugging/verification in it to check the SAMD21 and RFM95 are both in sleep mode? The examples for the RadioHead library do not use the sleep mode function but the function is built in to the library so you should be able to include it. Here is a direct link to that function in the [RF95.cpp file for reference.
If you can link the code you are using we can try and figure out what is causing the problem but as a guess, I think it is related to either the SAMD21 or RFM95 not going into or staying in sleep mode.](RadioHead/RH_RF95.cpp at master · PaulStoffregen/RadioHead · GitHub)
Yeah, I couldn’t find any obvious hardware that would eat up so much current, and the easy way of ruling out the radio module (desoldering it) is something I can’t really manage with the equipment I have. I was using the LMIC library for the radio, which successfully sleeps the module when used with another board (in any case, the module only uses significant power when in an active listening mode - LMIC configuration and function calls didn’t make any noticeable impact).
Mostly I was using the RTCZero library to set up a sleep timer, and sleeping with:
SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;
__DSB();
__WFI();
I did other things like disabling USB, ADC, SERCOMs, etc., but they only made a very minor difference. The SAMD21 was definitely going to sleep (power consumption dropped from about 60mA to 30mA).
I think it’s somewhat telling that whenever there is code running on the ProRF (even something like delay()), I don’t see less than about 60mA. Changing pin modes, disabling peripherals on the SAMD21, etc., makes an impact of maybe 1-2mA at best, the power LED doesn’t draw much more than 2mA…
On other boards with the same basic hardware (SAMD21, RFM95, voltage regulator), it’s closer to 10mA when running . An Adafruit Feather M0 LoRa runs about 300uA when put to sleep in the same manner, and the LowPowerLab board reads about 6uA when sleeping. All examples are measured when powered by the same single-cell lithium battery, about 4.2V fully charged.
I have the same problem, I am using the library of arduinoLowPower and the rf95 sleep, however the current is 30mA in deepSleep and 50 in normal operation, I attach the code in case you can give me some recommendation. Thank you.
#include <SPI.h>
#include <ArduinoLowPower.h>
#include <RH_RF95.h>
RH_RF95 rf95(12, 6);
int LED = 13; //Status LED
int packetCounter = 0;
long timeSinceLastPacket = 0;
float frequency = 915.0; //Broadcast frequency
void setup()
{
//pinMode(LED, OUTPUT);
//SerialUSB.begin(115200);
//SerialUSB.println("RFM Client!");
rf95.init();
rf95.setFrequency(frequency);
rf95.setTxPower(13);
rf95.setSpreadingFactor(7);
rf95.setSignalBandwidth(125000);
rf95.setCodingRate4(5);
}
void loop()
{
rf95.sleep();
SerialUSB.end();
delay(400);
LowPower.deepSleep(10000);
//SerialUSB.println("Sending message");
uint8_t toSend[2] = {packetCounter, packetCounter >> 8};
//SerialUSB.println(packetCounter);
//SerialUSB.println(toSend[0]);
//SerialUSB.println(toSend[1]);
rf95.send(toSend, sizeof(toSend));
rf95.waitPacketSent();
byte buf[RH_RF95_MAX_MESSAGE_LEN];
byte len = sizeof(buf);
if (rf95.waitAvailableTimeout(2000))
{
if (rf95.recv(buf, &len))
{
//SerialUSB.print("Got reply: ");
//SerialUSB.println((char*)buf);
//SerialUSB.print(" RSSI: ");
//SerialUSB.print(rf95.lastRssi(), DEC);
}
else
{
//SerialUSB.println("Receive failed");
}
}
else {
//SerialUSB.println("No reply, is the receiver running?");
}
packetCounter++;
//LowPower.sleep(4000);
//rf95.sleep();
//delay(200);
}
Hmmm, a deep sleep feature for this product would certainly be useful. I will reach out to the team that produced the documentation for this product and see if we can’t discover how to run it in deep sleep mode and add it to the hook-up guide.
Is with most things, prioritization is the next step. Should we produce additional documentation for this product I will ping this bug with a link to the information.
Thanks for sparking our interest in this topic!
Thanks for the follow-up! For reference, I am able to achieve ~8uA (yes, microamps) from a SAMD21 Moteino from LowPowerLab, with an external flash memory module and RFM95. That board also has on-board LiPo charger and LDO - so I would think this level of performance should be within reach for the SparkFun board. I may try getting low-power sleep to work on the ProRF again, and I’ll update here if I make any progress. I suspect it may be related to bootloader and pin configurations…
I do want to make it clear, though, that the ProRF board is indeed able to enter deep-sleep mode - it just uses ~3500x more power than it should in that mode. Since the point of LoRa is to achieve long range with low power usage (i.e. use cases where the device is not easily accessible), and especially if you’re going to include a JST battery port on this board, it would be nice for customers to be able to have projects that can run on the order of months or years before needing a recharge, rather than a couple days. As it stands, the 10 ProRF boards I have sitting next to me aren’t able to be used, because I won’t be able to recharge or swap the batteries every 2 days.
SOLVED! It’s a hardware issue. Currently acheived ~110uA sleep current.
Issue:
So I tried running the board directly from the 3V3 rail, no luck, still >30mA in sleep, >60mA awake, so I assumed it couldn’t be anything in the power circuitry. I dug into the schematic a bit deeper, and noticed VDDCORE is wired to 3.3V. Looking at the datasheet (and other implementations of the SAMD21), it’s either not common, or not recommended (the closest thing the datasheet says is to connect to 1.6-1.8V, per Table 38-1 on pg. 1009). I carefully cut the trace, and viola, 1.8mA sleep current, with the power LED still included. I disabled the power LED and now I am at 110uA sleep, ~13mA awake. I’m guessing part of the still somewhat high sleep current (<10uA should be possible for the processor alone) is the LDO (55-80uA quiescent current).
So, uh, maybe revise the board to fix that issue, and leave VDDCORE disconnected? Or at least add a note in the hookup guide, please!
EDIT: The other SparkFun SAMD21 boards don’t seem to share this issue. The SAMD21 Dev Breakout, SAMD21 Mini, and the RedBoard Turbo are all okay, with just a capacitor between VDDCORE and ground.
Hi again mantonakakis,
I just checked the schematics for this and our other SAMD21 boards and you are 100% correct. It looks like that was overlooked in the original design. We’ll forward this on to our Engineering and Tutorials teams to work on, at the least, adding in a note on the Hookup Guide or looking at a revision to fix that trace issue.
Thanks for sharing this information! I’m sure it will come in handy for other users with this version of the board trying to get the sleep current draw down to reasonable levels.
Did a fix ever get written up for this?
Whats the best way to cut the trace?
Thanks
Hi jchamilt,
A short answer is no, there has not been a revision to the Pro RF and there is no tip in our documentation as this is fix requires some very careful trace manipulation. If you have never worked with PCB traces before, [this tutorial can help give some good tips to get started. You’ll also want to download the Eagle design files from the “Documents” tab on the [Pro RF Product Page to follow along. I’ll try and outline this as best I can but the VDDCORE pin is literally next to the VDDIN pin and they are netted together very close to the IC so you if you want to try this, you will need to be extremely careful not to cut the trace for VDDIN. Here is a photo showing VDDCORE (Green Arrow) and VDDIN (Yellow Arrow):
You can kind of see in this photo (sorry for the terrible resolution, you can get better resolution photos showing the traces from the product page but seriously, if you are trying this fix please download and refer to the Eagle files) that both traces meet near C4 (the 0.1uF capacitor next to the SAMD21). You want to carefully cut the trace for VDDCORE (pin 43/Green Arrow) before it meets the rest of the 3.3V trace for that portion of the circuit. Also, you will need to be careful to not cut the trace for the other adjacent pins on the SAMD21.
One last time just because I cannot stress this enough, be very careful with this fix! If you manage to sever the trace on either side of VDDCORE you risk damaging the board and can render it useless.](SparkFun Pro RF - LoRa, 915MHz (SAMD21) - WRL-15836 - SparkFun Electronics)](How to Work with Jumper Pads and PCB Traces - SparkFun Learn)
Mark’s suggestion is exactly what I did, and it worked for achieving lower power usage (and brought sleep current down from 30mA to ~100uA with proper peripheral setup).
But, one note about cutting the traces - if you venture down that route, you will lose the connection to the decoupling capacitor between VDDCORE and ground, which would lead to stability issues. I would hope SparkFun revises the board if they’re going to keep selling it 
Ah, that’s a good point about the decoupling capacitor. With a clean power supply it should be okay but in battery-powered situations, that’s not always the case.
Also, a revision for this board to fix that issue is in the works but we do not have a firm ETA on when that is going to be completed.
Good to hear, thanks Mark!
Any update on this issue, is the hardware fix already available?
@TS-Mark
As a customer I would really appreciate to get information what is your plan regarding this problem. You have had several months time to think a solution. If you are not going to fix this issue then please be fair and tell it to us. At least then we can plan something else. There is no way one can make a battery device using this board if you dont fix this problem.
Hey piisku78 and mantonakakis,
We are actively working on a revision to this product. We just finished building up some samples of the new version yesterday, and we are currently verifying that the changes to the VDDCORE pin allow for super low power mode. However, we have only been able to get down to 460uA.
Besides (a) disconnecting VDDCORE from 3.3V, (b) disabling the power LED and (c) sleeping/disconnecting the RFM95, is there any other modifications that you have made to the board (v10) in order to achieve 110uA?
For reference, we am using the LowPower Arduino library by rocketscream and using the following simple sketch to call standby().
Initially, we tried using the RH_RF95 library to initialize the RFM95, but didn’t seem to actually put it into sleep mode (it was still pulling 2mA). When we ultimately cut the trace to the 3.3V pad on the module, my power dropped down to 460uA.
// #include "LowPower.h"
// //#include “RH_RF95.h”
// //RH_RF95 rf95(12, 6);
// void setup()
// {
// // rf95.init();
// }
// void loop()
// {
// LowPower.standby();
// }
Is there anything else we might be overlooking here?
Thanks!
-Pete
