Hi, I’m going to use my Boron as a stand alone enpoint, and it will live on battery. So I was wondering what are the best practices to keep current consumptions as low as possible. As there are no parameters listed in the datasheet, I would like to know about how much current consumption can I expect.
Cheers
Currently decissions haven’t been fully made which of the wealth of sleep modes the nRF chip provides should be leveraged into the user API level and how.
So it’s a bit early for this kind of questions.
Hence the best bet would be to pull up the nRF52840 datasheets and study what’s there
For general info you can start here
https://docs.particle.io/datasheets/wi-fi/argon-datasheet/#technical-specifications
I think the problem is not about the nRF but the radio module Sara r410m which is the one that connects to the network. According to the datasheet, it has a Power Saving Mode which drains just about 6 micro amps! Have you discussed about making this accesible from particle?
It’s all part of a bigger plan to integrate the MCU sleep modes and network coprocessor (u-blox for the Boron, ESP32 for the Argon) sleep modes.
Once complete, the possibilities are really great for very low power operation. The SARA-R410M has great low-power modes as does the nRF52840, plus the nRF52 can go into sleep mode and wake up when the modem sends data across its serial connection.
Exciting stuff! Just not ready yet.
Thats exactly what I want to do! Any idea of when is going to be accessible?
To add to the “when” question, I would love to know when just the standard sleep modes (system.sleep, deep sleep, sleep_network_standby) will be available on the Boron and other Mesh devices. Right now we can’t do any sort of sleep testing whatsoever.
I would like to perform some field testing with the Boron but it’s just not ready yet. I would have expected Particle to put out a new firmware by now that is halfway there. Explore new sleep methods later, but at least implement the old ones.
I’m itching to see how much better the sleep states are on the new platform. The electron wasn’t good enough for me. I’m going to look to see if I can call directly into the nRF5 SDK to perform power down modes… unless someone beats me to it 
I second the ‘when’ question. Any ETA for sleep mode functionality?
Boron Sleep modes are essential.
Are all the Sleep modes available on the E Series LTE modules.
Seems like this would be the way to go while all they get all the new MESH hardware stabilized.
This is from another post, but possibly more useful here.
I’ve been performing some preliminary testing with Boron LTE to track any connectivity problems:
Awake and Publishing every 5 minutes on battery power only.
2,000 mAH li-po (same that ships with Electrons),
Mini Solar Panel 2W / 6V into USB connector.
The SoC drops ~20% over night.
Recharges in ~ 1 hour of good sunlight.
I’m using pmic.setChargeVoltage(4208).
All scheduled publishes are making it to the Cloud Endpoint.
;
It appears that the Boron LTE will make a good replacement for Electron in many projects, especially as the System Firmware progresses.
Operating a Stand-Alone Boron LTE (Solar) will be fairly easy.
I would love to figure out how to get the PMIC to enter and stay in CV mode for a while during the end of the charge profile, if anyone has suggestions.
@Rftop this is good data. Do you have a chart showing time-series SOC profiles for both the Electron and the Boron over several days?
@Darmitage Yes, but the Electron has several Sleep Modes available. Currently, the Boron doesn't.
The only way that I know to reduce Power Consumption on a Boron is to use the EN pin and an external timer.
I'll publish my results on this post once the 3xAA test is complete. Looks like the Boron will far exceed the calculated 4,000 Startup/Publishes on 3xAA batteries. It's at 3,600 right now.
I've got the test rig ready to perform power measurements over several hours for a Boron tomorrow.
That test will be continuous Cloud Connected to define an average current per day to be used for Power Budgets. I think that will give you the info you're looking for.
Considering low power usage is one of the primary use cases for these products, it’s really odd that the devs put sleep mode on the back burner.
Peter
@gothamsound, Particle has not put this on the back burner. Instead, they were focusing on getting device setup working and making the mesh communications more reliable so that users could get started off on the right foot. The nRF52840 provides a LOT of sleep capabilities so bringing these to the DeviceOS is a lot of work. It is one of the top items on their list.
The Following Measurements were performed with a Photon, a 16-Bit ADS1115, and the µCurrent GOLD to measure the Power consumption of the Boron when powered with constant 4.00V via it’s Li-Po Connector. It measures 100+ differential 16-bit readings each second for Voltage and Current.
This produces a lot of data.
In summary, a Cold Startup for a Boron LTE running "empty" Code on 0.8.0-rc.25 takes 20 seconds, with the current ramping up to 100 mA, consuming 2 mWh.
After that, the current is 17 mA until the 23 minute mark, ramping back up to 97 mA for 5 seconds, every 23 minutes.
**For a 1 Hour Period @ 3.99 V (ave) on Li-Po connector:**
The average Current is 19.6 mA.
The average Power is 0.078 watts
The Energy is 0.078 watt-hours, or 78 mWh.
Any Publishes by the User, variable request, etc, would consume an additional 1-2 mWh each.
The Test with 3xAA batteries & Enable Pin is still running. It's at 6,000 Publishes and no-where near complete. Average MCU time per Cycle is 12 seconds (1 cycle per minute). It might hit 10,000 Publish cycles.
Hey folks – wanted to pop in to echo @peekay123’s comment that Sleep Modes are a priority, but must by necessity take a back seat to some of the outstanding issues affecting “normal” mesh usage in the community.
Take for example the SOS-7 issue for which we’ve identified the root cause (in Nordic’s 802.15.4 driver) and should be releasing a fix for this week…it just doesn’t make sense for us to be focused on adding sleep mode features while some devices are unable to go more than ~2 minutes without resetting.
Fortunately, most of the highly critical issues affecting mesh usage have been resolved, so we can start to spread our efforts a bit more evenly between stability/reliability improvements and driving towards feature parity between Gen 2 and new Gen 3 platforms.
Know as well that sleep modes, perhaps along with enabling Bluetooth APIs, are at the top of our list!
@will
I understand Particle's current situation and the position it's in from the Gen3 launch.
I'd like to mention that people are also excited about the Boron as a Low Powered "Electron", especially since it's advertised as such. As you already know, Cellullar.command() and a Sleep Mode or two would get us moving 
.
A stand-alone Boron is a great product without even considering Mesh Service (that's an honest compliment).
I hope the Boron doesn't get left behind while the Mesh fires are being extinguished in the interim.
Most importantly, I want to say Great work !
@will Thanks for replying. I agree that normal powered on usage must take priority. I am using it very much along the lines that @Rftop mentioned, as a low powered Electron.
I look forward to full sleep functionality. In the meantime, I will use a this with a vibration switch to mimic the wake on move functionality.
If I wanted to stick to a quick and dirty software-only method, what commands are advisable to consume the least amount of power while idle?
I would guess Cellular.off() - any other suggestions?
Thanks,
Peter
The previous results are no longer valid.
The Boron LTE interacts with the Cloud, cell tower, etc, differently since yesterday’s tests.
Yesterday, the modem’s current would ramp up every 23 minutes. Now it does this every minute.
This causes a 43% increase in the baseline energy consumption ( Hourly increased from 78 mWh to 112 mWh ).
10-minute logs from Yesterday and Today:
The Code on the Boron LTE (0.8.0-rc.25) is
SYSTEM_THREAD(ENABLED)
void setup() {
}
void loop() {
}
Something significant changed yesterday.