@toppert
Some of power banks can support low current mode. Some of tem must be turned in this mode by special press on the button, some work from the start. But many do not support low current mode at all.
E.g. "Mi" power banks support this mode - but as @seb say already it is super inefficient.
You can got longer time from battery then from powerbanks.

@luke said in SiPy hardware integration.:

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.

Please see here: https://github.com/wipy/wipy/tree/master/hardware/ExpansionBoard-v1.2

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.

@sandking

So you used a 5v usb charger and connected it to Vin?

@crumble

>>> os.uname() (sysname='LoPy4', nodename='LoPy4', release='1.15.0.b1', version='v1.8.6-849-baa8c33 >>> import gc >>> gc.collect() >>> gc.mem_free() 2558368

@jonnyboy said in SiPy -> AWS Device Example - CA file not found:

CA file not found

Can you try formatting the file system and re-uploading the files again, you can do this by running the following from the REPL:

import os os.mkfs('/flash')

It could be the the file system has become corrupt, it might be worth trying to upload the files via USB if at all possible.

@rcolistete

the code is in main.py and runs stand alone.

The pysense is supplied by a tp4065 (charge battery by a solar panel) connect to usb.

@robert-hh Thanks for that (and your assistance on my other question).

I would be interested in your thoughts on how the "main" thread would check these flags as that goes back into using some kind of event/interrupt to know the timer/sensor readings have read something in. My first thoughts would be a while loop with a sleep count and checking periodically but feels like that is not the correct way to go about it.

At this stage I am currently working with two or three period alarms executed from the "main" thread and a single secondary thread that is in a while loop and constantly sleeping looking for values at certain intervals which it then does the "heavy" processing and sending.

@crumble - Yes I must admit I need to get out of some of my older habits to focus more on efficiency than simplicity/readability. However, I must admit I have been struggling to find material on how Micropython, specifically, works with allocation of memory for objects/variables/functions and what is the most efficient practice. Most examples go back to pure Python requiring multiple libraries to do memory statistics, even then not actually demonstrating what is the best way.

Simple questions as to how the GC works, if I need to set variables to 'None' at the end of a function, or the use of a list over three distinct variables. The only way I am really finding it is by doing it both ways and testing it with gc.mem_free() which is time consuming and feels more like guess work. Would be interested on your point 4 about modules and compiling at boot time.

@seb
JWT tokens use HMAC
and this lib can be used for it
https://github.com/micropython/micropython-lib/tree/master/hmac

@bradnz I had your same problem. With the new release I solved

It is indeed mentioned in this post.
So I'll be able to get rid of the expansion board but not the deep sleep shield for it to be fully efficient
That's exactly what I was thinking but I wanted to be sure about especially about the current since it worked but I was sure there will still be current consumption problems without the shield.
Thank you for your fast reply, this will reduce the size of my project.

I just made a mistake with the pins, the one I needed to not change were G12, G13 and G14 and not like mentionned above.

I'm still interested if I could use those Pins for input and then somehow deinit so that the communication still works.

@marto Hi thanks for pointing that you, you are correct the updater tool only shows instructions for the expansion board at the moment. I have passed this on and it should hopefully be changed soon. I will now remove the text about carefully reading the updater instructions because that clearly caused confusion.

I will also pass on your OS details so make sure it gets investigated at the same time as the Mac OS issues.

@jerryhjones The latest version for MacOS is 1.1.2.b1... can you please check that you have the latest version?

Also can you please provide more details as to how you apply power to the board?

What kind of TTL adapter are you using?

@bradnz Exactly which version of deepsleep.py did you use? There are many commits which mention version 1.0.0 for this file.

I am trying your solution, but it's not working for me on LoPy.

@aptusmarvin
I have upvoted your messages, then you can now post without delay
and i suppose also include images directly to the forum

@misterlisty Micropython uses the prefix u for its modules to indicate, that it may be a subset of what you have in CPython. For compatibility, the names without u are also provided. So, the genric name in MicroiPyhton is uos.uname, while os.uname is also possible. Likewise, you can write

import uos
or
import os

There are some deviations from that simple rule. Like in CPython, you can use _io, whereas in Micropython it's called uio (not u_io), and _io is not known. Also, why some modules have a non-u alias and others not is unclear. You could change that easily in mpconfigport.h of the respective port.

Further to this, I have found even more weird. I simply cannot get this Pycom SiPy device with a deepsleep module attached to wake every 30mins. Its so random.

@crumble if I needed to fix the floating pins issue, what resistor size would you suggest, and would this be pull up or pulldown? Also what commands in the SW would I need to ensure that P17/P18 doesnt wake the module from deepsleep if I do this? (Assuming of course that these are the only two pins I need to control - P10 is used to communicate with the deepsleep module, but I dont think this needs a pullup / pulldown on my board?)

Any help would be appreciated.

Cheers.