MicroPython Forum (Archive)

loboris wrote: ↑

Wed Sep 12, 2018 9:41 am

@seonr
The modules are quite expensive, I don't understand why would shipping to Australia be so much higher than to the rest of the world. I've got 10 pieces for 67.4 US$ and FREE SHIPPING (to EU).

Cheapest I can find for the shielded is AUDS$10.9 each from Banggood. That's better than the $15 from Ali Express. I might grab one to see what I can do with it.

It also looks like though the module is shielded, it's not certified, so kinda pointless as a shielded module in my mind. If it's going to be un-certified, I'd rather improve my own antenna design and get a custom shield for the entire TinyPICO.

loboris wrote: ↑

Wed Sep 12, 2018 9:41 am

Another disign issue I've noticed.
You are routing pin #16 to the board connector. This pin is used as CS for the internal Flash on ESP32-PICO-D4 and cannot be used for anything else.

Hmm, you are right, though it is listed as a general purpose I/O in the table, but on the schematic is for flash only. Same with 17. bummer. I'll try to get 12 or 14 over to that pin for rev 2.

Thanks for pointing this issue out

Seon
unexpectedmaker.com

loboris wrote: ↑

Wed Sep 12, 2018 9:41 am

Another disign issue I've noticed.
You are routing pin #16 to the board connector. This pin is used as CS for the internal Flash on ESP32-PICO-D4 and cannot be used for anything else.

Dammit, I'm kicking myself about this; I was aware of those reserved pins and still missed it! Thanks Loboris!

So lots of progress has been made on the TinyPICO... so I thought I'd post a link to the youtube playlist where I am vlogging the progress of the board iterations.
https://www.youtube.com/playlist?list=P ... gDfEC9qk-r

I have made lots of changes to rev2 even since my rev2 livestream yesterday, the board is now smaller... 18x30mm and the power path has been optimised to power down or standby any ICs and LEDs not needed when no USB cable is plugged in.

The board also now has 15 GPIOs broken out instead of the 13 on rev1.

I'm hoping to have rev2 boards sometime next week to assemble.

Cheers
Seon
unexpectedmaker.com

Thought you may be interested in a quick update: Seon has assembled a couple of the Rev 2 boards!
I don't have one in my hands yet but MicroPython was running quite well on my Rev 1 unit!

Sorry if I missed this question, I did browse the 4 pages of posts but did not notice it.

With the device in deep sleep mode, USB disconnected and powered by battery / power supply, what is the current drawn ?

Many Thanks

Hey devnull,

With the lowest sleep I was able to get the PICO TinyPICO pulls approx 160uA from battery and approx 7mA from USB. I'm honestly unsure what that mode is - I am assuming it's the RTC timer + RTC memory mode, as I am using both in the tests to wake it up and remember sleep count, but it could actually be that the ULP co-processor is powered on. I need to do more research.

I had a lower quiescent current LDO (AP2112K) on there that took it below 150uA, but it browns out with antenna initialisation in MicroPython, so I had to switch to a different LDO which pulls approx 25uA more

It's not the lowest current pull I've ever seen on battery, but it's it's pretty good.

I am about to assemble revision 4 hopefully today, so I'll re-test as I keep optimising component counts each revision.

Cheers,

Seon
unexpectedmaker.com

@seonr
I have used HT7833 LDO which has quiescent current of only 4 uA.
ESP32 in deepsleep mode draws ~5 uA, I was able to get total 15-20 uA in deepsleep on custom board with MicroPython.
Typical active current is 40-60 mA with WiFi not activated, depending on CPU speed and activity.

Be shure to have 0.1uF + 10 uF (minimum) capacitors near ESP32 VDD3P3_CPU pin to avoid brown out during WiFi initialization. Also PCB power traces (LDO input, +3.3V, GND) should be at least 0.3mm.

@loboris
Thanks for that info... the HT7833 looks great! I've added some to my next LCSC order

I did some digging, and I still have the ULP on or at least sensors on, so I am actually in 100uA sleep mode on the PICO... I can't see how (using the Arduino IDE anyway) to get the PICO into the next deeper sleep mode with just the RTC timer and RTC memory running, to get it to the lower 10uA or even just the RTC timer at 5uA

Also, yes all my power traces are min 12mil (> 0.3mm ) plus I am using 4 layers, so I am using power planes for distribution. My VDDA_3P3 did only have a 0.1uF, so I have added a 10uF for rev5, thanks. It's also using 16mil for trace.

Seon
unexpectedmaker.com

After more digging my bottleneck on the TinyPICO in deep sleep current draw is the CP2104 It pulls approx 90uA and there doesn't seem to be an easy way to "un-power" it when only running off battery.

I ripped the CP2104 off one of my test boards as I am now under 10uA in deep sleep if I bypass my current LDO. My meter can't measure any lower than 10uA so it might be 5uA, who knows

So, I may be able to get TinyPICO closer to 110/120uA in deep sleep on battery, but that's likely the best it will be.

Seon
unexpectedmaker.com

Hi;

Yes, that is precisely the problem I have with the weemos and similar eps8266 / esp32 breakout boards, they all have onboard USB which results in this power drain when running on battery power, and is fine if all you ever use them for is breadboarding !

The thing is, (maybe like others too), I would potentially use these boards in low volume production runs as well as for development, if of course it was medium or high volume then I would use the device directly and not use a breakout.

In another thread, I am asking about small, low power devices, with no LEDs or onboard USBs that such up power and this is why I am interested in this.

So maybe don't just consider this to be used for breadboarding only, it can also be integrated into a PCB in low volume production runs !

Ideally, it would also be good to be able to completely disable LEDs without resorting to unsoldering them from the board, as these also draw power and can draw unnecessary attention to the device when you want it to be silent and invisible !

Again, personally, I also kind of agree with @roberthh about not having 3v3 and gnd pins repeated, which is really great for breadboarding but again, if these are to be used in low volume production, then another one or 2 ports might make the difference between the device being usable or not

Just my two penneth


Afterthought - why not add a jumper (pads or header) that will completly disable USB so that it can be used for both development and low production runs ?!