If you use Pytrack/Pysense-controlled sleep, the PIC will power down completely the FiPy (it's not sleeping, it's completely off), stop USB, etc, and go to sleep. On a Pytrack you can choose to power down the GPS as well. Don't remember about the other sensors on the board. 3V3_Pymodule will be shut down. 3V3_Sensors can be kept on, though I don't remember if it's always on or if there's an option to shut it down as well.
If you use machine.deepsleep, the FiPy will go to sleep, but I believe the Pytrack/Pysense will continue to work as usual, with everything powered. You probably need to take a few steps to reduce its power draw. Don't think there's anything in the libraries for that, you'll probably have to talk to the PIC and/or sensors directly, and I'm not sure there's a way to make the PIC go to sleep without shutting down the FiPy (though I don't know how much the PIC itself draws).
@lukesaber To compute your power requirements, if you are running a "wake up, send data, go back to sleep" pattern:
define T as the duration in seconds of reference period of your choice (1 hour = 3600, 1 day = 86400...)
define N as the number of times your device will wake up in that period
define D as how long your device will we awake each time it wakes up (in seconds)
define IA as the power consumption when awake (in mA, but you can use any unit as long as it's the same for IS and the result)
define IS as the power consumption when sleeping (ditto)
Then the average power consumption is:
(N * D * IA + (T - N * D) * IS) / T
T = 3600 (1 hour)
N = 3 (wakes up 3 times an hour)
D = 10 (stays awake for 10 seconds)
IA = 100 mA (average power consumption while awake)
IS = 0.010 mA (10 µA, average power consumption while sleeping)
If you want to have enough power for 2 days, then you need a battery with a 40 mAh capacity (0.84325 * 24 * 2). I think nearly any battery will do.
Now, the exact figures for D, IA and IS can vary a lot, based on:
what sensors/peripherals you may have that you need to power, and whether you power them all the time or only when you are awake
what you need to do while awake
how you send (LoRa, SigFox, LTE, Wi-Fi, BLE...), at what power level, at what data rate
how long it takes for handshakes, ACKs, receive windows, etc.
and probably a lot more things.
Ignoring any sensors or other peripherals, while awake, the power consumption is usually somewhere between 50 mA (module active, not sending or receiving) and 200 mA (when sending). How long you stay awake will usually range between 3 and 10 seconds. Power consumption during deep sleep should be somewhere between 10 and 20 µA depending on the exact setup.
So with 3 wake-ups per hour, for 2 days of battery life, your worst case scenario, not counting any sensors or peripherals, (200 mA when active, 10 seconds active, 20 µA in deep sleep) is about 80 mAh.
You need to add the requirements for your sensors/peripherals on top of that.
If you don't go to deep sleep for whatever reason, then the figures are drastically different, but you can keep the same logic. Just replace IS with the power consumption while idling.
@robert-hh The hearbeat LED flashes when the board and code are working properly. If I notice that the data is not updating, I'll go look at the board and the heartbeat LED won't be flashing. I'll hit the reset button on the board and everything will work normally again.
I think I'll setup an identical rig but power the USB power port from a variable DC supply. Then I can turn the voltage down and see what happens.
I've been working with SiPy modules for a little while, and I have some questions and comments.
They are generally a nice, well engineered product, but:
For the moment, I'd like to move away from the Pycom expansion board and replace it with my bespoke board incorporating the sensors and actuators that I need, but stick with purchases of Pycom processor modules (the DIP style, not OEM) right now during this "pilot production" phase. The move to the Pycom OEM hardware on my board might come later.
When programming the device using a UART (such as the FTDI chip on the Expansion Board) is any special hardware needed, or just a plain connection to the 3.3V UART logic levels? Do any of the handshaking lines such as CTS and RTS need to be connected to control any resets or similar, or is two-wire TXD/RXD (plus power and ground) all you need?
An open schematic for the Expansion Board would be a good move IMHO. OK, sure, you want to keep the hardware design of your microcontroller/RF modules proprietary and closed. I can live with that as long as I have the integration information I need to build my system. But an open reference design for the Expansion Board makes it a lot easier for engineers who are integrating your modules into custom hardware - it should get you more sales of Pycom MCU modules, not less.
It would be really nice to not need to re-implement the whole battery charger circuit etc from scratch - and it would be nice to see unambiguously how the FTDI serial chip is wired and what serial lines are mandatory to successfully talk to the Pycom module and deploy code.
OK, sure. There are a couple of bugs in the hardware that cause the high deep-sleep current. I get it. It happens.
But sometimes it feels a little like I want to buy your product, but it feels hard. It feels difficult for me to use the SiPy (or LoPy or whichever) module the way I need to use it, and I wonder why I don't just build my own system from scratch starting with a bare ESP32 and CC1125 and open-source MicroPython.
I'm considering moving to Pycom OEM hardware modules in future, but at the moment I want to move to a "semi OEM" model, consisting of Pycom DIP modules (such as the SiPy, but not exclusively) with the Pycom module plugged in to my bespoke motherboard base that I have designed.
The SiPy product page promises us a system, using the SigFox radio, that draws 0.5 uA in standby. That's a property of the SiPy board itself, not a property of the expansion board, deep sleep shield, or PySense board or whatever. I'd like to be able to purchase the SiPy product and have a product that meets the marketed specifications.
The page that discusses the high quiescent current deep-sleep issue mentions that "We will redesign the WiPy 2.0, LoPy 1.0 and SiPy 1.0 over the next few months in order to remove this deep sleep issue whilst enhancing the product performance to include 4MBytes of RAM and 8 Mbytes of flash.", but how close is this to reality? Are we going to see SiPy modules shipping with the relevant hardware changes soon, or is it a year away?
Please see the LoPy for this, we opted to combine the LoPy and SiPy into one product line with the fixed deep sleep.
I can't just buy one blob of Pycom proprietary hardware and firmware, and stack it on top another blob of proprietary hardware, and then buy the Deep Sleep Shield which is yet another blob added to the stack, just to get the deep-sleep power budget down to where it's expected to be. It's physically too bulky, among other factors.
I think having control of the VDD_SDIO power domain that powers the external flash memory when the device is in deep sleep mode is a really important function. Micro-power and sleep performance are crucial in wireless sensor networks or IoT systems, and even if you needed to sacrifice a GPIO pin it's worth sacrificing a GPIO pin. Similarly with the mode of the DC-DC regulator - moving it permanently to eco mode for low quiescent power draw sounds like a very good idea.
The ESP32 already incorporates an ultra-low-power internal coprocessor designed for exactly this reason, handling wake ups and deep-sleep micropower interrupts from external hardware. So adding the PIC10F322 on the add-on board really feels like an inelegant hack, because it's redundant. The ESP32 itself should already be equipped to natively meet this exact use case.
We are planning to add support for programming the ULP co-processor from micropython so stay tuned for that. As for the PIC, this was necessary as it completely removes power from the pycom module as a work around for the deep sleep issue. Therefore the co-processor would not work in this scenario.
The schematic of the deep-sleep shield has been released, but the schematic is quite trivial really, it's hardly more than just a high side FET driven by the PIC10F322.
The PIC10F322 firmware is really the important part, and it would be really useful if it was released. This means I can use the same code on a bespoke base-board with the Pycom modules, add the power-switching PIC10F322 to the board, and get the micropower performance as advertised - from the Pycom modules I've already purchased and from others I'll purchase in future before hardware changes are pushed through the stock pipeline.
We are considering open-sourcing the firmware but at the moment there are no concrete plans around this.
This doesn't undercut any sales of Pycom microcontroller modules - but it makes it much easier for users in such a position to buy and use your product.
Similarly, I'd really like mechanical CAD drawings of the Pycom modules and expansion board. It would really make it a lot easier when I'm designing a mounting case for these boards. Dimensions, mounting hole locations (for the Expansion Board etc) and clearance distances would be really valuable information. (Once again, it's about making it easy for people to use your product in their application, therefore making it easy for people to buy your product.)
Please check the datasheets on the docs website, the mechanical specs of the modules are definitely there. We also have KiCAD footprints for all modules on github.
For that kind of longevity you're better off ditching the secondary cells (rechargeable) and going for a primary cell. I would recommend looking at the SAFT LS or LSH series. They are the best energy density to size batteries available.
@fsergeys You should measure power draw from battery, not USB. There's a lot more going on when powered via USB, it's not representative of what happens when you're running on battery.
You can definitely use the Pytrack's deep sleep (use the PyTrack library) to power down completely the WiPy, but you shouldn't see much of a difference when running from battery in the case of a WiPy 3.
I am using the expansion board 2.0. I have no deep sleep shield yet (Pycom forgot to send the deep sleep shield with the order of the lopy 2 weeks ago. They told me a deep sleep shield is on its way now)
We deinit the WLAN from start because we don't use it.
We charge just using the micro-usb cable. It is configured with the jumpers at 450mA charge current.
In the battery test we did, we intentionally drained the battery fully to see how long it would last. We expected the LoPy to stop working eventually, but expected we would be able to recharge it using the USB connection at that point.
Can the deep sleep shield -if used on the LoPy 1- recharge a drained battery by just plugging the USB-cable in after the battery was exhausted and shut off by the deep sleep shield?
@robert-hh Things are much better now it's wired correctly! :-) The batteries and the converter have been at room temperature for the last few hours and my LoPy and sensor are working fine. Thanks again for your help Robert.