Project Logs

Collapse

• Power-down of <1nA? with Just-in-Time Regulation

  Andy • 11/28/2020 at 12:35 • 0 comments

  TL;DR

  I took advantage of the ATmega1284p's wide operating supply voltage (e.g. 1.8v to 5.5v) and low power sleep state and developed something where the microcontroller can actually sip it's power-down supply current from an automatically rechargeable low-leakage on-board capacitor until more power is needed, effectively lowering the average power-down current *from the battery* to less than 1nA.

  (Yes, that ATmega1284p is actually on and in power-down mode - video at the end of the log.)

  Part One

  Phew.  Was that really a TL;DR?!

  Those following along will remember the above photo from the end of the last project log.

  And yes, that ATmega1284p on one of my Pro Mini XL (v2) boards really is "on" and in power-down mode.

  Don't believe me?  Let's wake it up then by grounding INT0...

  See the LED light up despite drawing less than 1nA?  It's alive alright!

  So what's going on?!

  Well...

  Have you ever noticed that after you disconnect power from some devices, they remain on for a little while?

  See that power LED on your phone/laptop charger slowly fading off in to the abyss of nothingness?

  There can be a number of reasons for this.

  But the one that interested me recently was that of the remaining charge stored in the on-board capacitances.

  On-board decoupling capacitors, for example, for the ATmega1284p are typically 100nF, maybe an additional 1µF thrown in there too.

  You might also have a 10µF sat on the output of your boost converter or LDO!

  It occurred to me that all those capacitances are just energy stores that a powered-down microcontroller could be happily sipping.

  If it's powered-down state was low enough, say, less than 1µA...

  So long as the voltage this capacitance supplies doesn't fall below the microcontroller's minimum, well, why not make use of it?!

  But how to stop it from eventually falling below that minimum?

  Why, with some nanoamp-sipping intelligence to periodically measure the supply voltage available and recharge the capacitor(s) up again - but only when necessary!

  The charge level could then be configurably and/or programmatically set (even by the microcontroller itself!) and then this new supply voltage system - a sort of "Just-in-Time" Regulator - could be forgotten about when powered-down.

  And that's exactly what the video below demonstrates.

  There are no huge electrolytics hiding in there, just the ordinary capacitances associated with a regulator and decoupling.

  But you could, of course, add one if you wanted to extend maximum potential power-down period.

  I've set the "regulated" maximum and minimum to 5v and 1.8v respectively, and am using a switchable boost converter to get 5v from those two AA batteries - that's why the in-rush current is in mA.

  I'll update this log with more details about what's going on in the video, probably on Monday.

  But I've been able to successfully power additional nA circuitry, for example, custom battery measurement, real-time clocks and sensors from this just-in-time regulator (JiTR?) all without too much impact on the maximum potential power-down period.

  More details on all that soon!

  And again, thanks to various awesome Internet folk and resources including Nick Gammon, Jean-Claude Wippler (JeeLabs), Charles Hallard (ch2i), Pascal Moreau (MySensors) and others - you all helped make this possible.
  

• How Low Can It Go? Pro Mini XL and nA Power-Down

  Andy • 11/27/2020 at 18:17 • 0 comments

  TL;DR

  I got the Pro Mini XL (v2) to power-down below 100nA and still wake up from an external interrupt - photos, video and code below.

  Your mileage may vary (YMMV) because the ATmega1284p is only spec-ed to power-down at 150nA from 1.8v in the datasheet, but here's the proof some of their chips can operate lower:

  In More Detail

  In the photo above the Pro Mini XL (v2) has been fused to run at 1 MHz with it's Brown-out Detection (BoD) turned off - allowing it to operate, seemingly happily from a fresh 1.5v AAA battery.

  The video below shows it first powering up, doing a bit of low-power housekeeping and then powering-down to less than 100nA:

  
  

  Board pin 2 (INT0) had been configured as an active-low wake-up interrupt and so when I ground it, you can see that the board springs to life again, before powering back down.

  The code (available here) would actually light the on-board LED if the forward voltage was high enough, sadly 1.5v won't cut it so it appears off.

  But the photos and video below shows the same board, same code just with a regulated 1.8v supply drawing roughly 1nA more whilst in power-down and the "proof-of-life" LED being lit (bottom corner) when it's awake.

  It's awake - honest!

  And by way of comparison at 3v, running directly from those two AA batteries, it just peaks over 100nA:

  Again, same board, same code - just varying the supply voltage:

  Now...

  Thanks to various awesome Internet folk and resources including Nick Gammon, Jean-Claude Wippler (JeeLabs), Charles Hallard (ch2i), Pascal Moreau (MySensors) and others, I've also been developing something that enables any Pro Mini to draw these few nA from an automatically topped-up "storage" - a sort of "just-in-time" regulator - cutting the power-down battery draw to basically zero.

  I'll write more about it soon, but here's a photo and video (to follow) to whet your appetite:

  Believe it or not, in the above photo, the board is actually in power-down and can happily remain there for a configurable amount of time.

  Again, same board, same code, but watch what happens when I trigger the interrupt...

  See the LED light up at the bottom corner of the board - it's alive!

  
  

  I'll update this log with more details soon!

• No Pain, Just Memory Gain:Using the Pro Mini XL with The Things Network

  Andy • 07/04/2019 at 00:38 • 0 comments

  TL;DR

  I got the Pro Mini XL working with the Arduino-LMIC library. It’s performing OTAA to The Things Network over LoRaWAN. And it’s reporting temperature and humidity measurements from an SI7021 sensor - with 80% program memory to spare!

  (Note: There’s no SI7021 sensor connected in the central photo - I added it in later when my extra female pin headers finally arrived!)

  In Brief

  I’ve been running out of memory.

  Whilst trying to develop/debug a Pro Mini 328P-based low-power temperature/humidity sensor node on The Things Network over LoRaWAN, I’ve been reaching the 32KB program memory limit and 2KB dynamic memory (SRAM) limit.

  Then it occurred to me.

  Why not test the pin-compatible, drop-in replacement benefit of the Pro Mini XL?

  Essentially, all I needed was more program memory and SRAM.

  So I updated the pin-mappings, replaced the 328P for the XL, recompiled.

  Shazam!

  Everything just worked!

  And now my existing Arduino sketch was only using 20% of the program memory!

  Now to add more sensors: GPS. Altimeter. Barometer.

  Hmmm, what else could I fit, I wonder...?!

  Gettng Started

  I began tinkering with all things LoRaWAN back in 2016 during a commercial farm monitoring project.

  Farmer "Dave" needed to monitor the temperature and humidity of a 120+ acre farm.

  But it was approx. half an hour’s drive away from the main HQ.

  Initial research into low-power, long range radio transceivers led me to LoRa and LoRaWAN.

  I soon discovered that I had just missed out on a Kickstarter campaign for The Things Network (back in 2016), but I pre-ordered myself a Gateway, Node and Uno anyway.

  Whilst I waited for the official development devices to arrive, I did what any impatient "Tech Tinkerer" would do...

  I DIYed my own.

  Using a Raspberry Pi 2 and LoRa concentrator board for the gateway (more on that below!) and a nice supply of Pro Mini 328P clones with Hope RFM95 radio modules for the nodes, I was all set.

  So I set up a LoRaWAN system of solar/battery powered nodes and a gateway to provide the environment visibility Farmer "Dave" needed.

  All was ticking along nicely.

  Until one day a blaze of fire consumed one of the barns and almost all of the tech perched on top of it!  (Thankfully, no one was injured and the fire was contained quickly.)

  So I was invited back to upgrade and reinstall a new one.

  The (Main) Problem

  In a word: freezing.

  Farmer "Dave’s" farm sits at over 4,000 feet up in the mountains, so it gets cold.

  Very cold.

  Especially at night.

  It can get so cold that it will freeze the fruit buds when they’re just starting to emerge… and then that’s it.

  Your entire crop is gone - for another year!

  So how to stop the buds from freezing?

  You can only resort to defensive measures (e.g. water sprinklers, etc.) when you’re almost positive a freeze is imminent.

  That's because it might actually cost tens of thousands of dollars to do so.

  Especially in a state with severe drought like California.

  In a perfect world you would monitor as much about the local environment as possible to help you predict when freezing might occur.

  Temperature, humidity, altitude, barometric pressure, wind speed, etc. all play a factor to a greater or lesser degree.

  You might also want some sort of location information from a GPS perhaps, to tie all that environment information to a specific area.

  On large scale farming, you could get micro-climates specific to one area of a field that differ from another area - depending upon the geography and topology.

  However, using the Pro Mini 328P as the microcontroller for the LoRaWAN nodes had previously constrained the number of sensors I could comfortably hang off it.

  With only 32KB program memory, I ended up limiting myself to an SI7021 to monitor temperature and humidity.

  But now I was revisiting the problem with my freshly minted Pro Mini XLs.

  I wanted to see how easily I could...

  Read more »

• Benefits or Limitations: The ATmega 328p Pro Mini

  Andy • 04/26/2019 at 11:33 • 0 comments

  "Any benefit can become a limitation."
                                                     (Anonymous)

  I’m sure you’re all pretty familiar with the ubiquitous Pro Mini.

  Or at least, this guy, his cheap (~$2) counterfeit cousin!

  Based around the ATmega 328p, the “trusty” Pro Mini quickly became a feature of many of my DIY electronic projects.

  There wasn’t a sensor or actuator I couldn’t connect to it via some sort of associated circuitry.

  And then there were the libraries!

  Awesome people around the world had written code to interact with almost anything and everything else.

  But that was sometimes where I would hit my first limitation.

  32KB Program Memory

  Over the years, feature-creep™ has resulted in some of my projects pushing the limits of the 328p’s 32KB program memory.

  For example, pan/tilt stepper solar-powered sun-tracking long-range wireless over-the-air programmable crop monitor...with camera and display anyone?!  ;p

  Once I started stacking libraries, adding features and increasing the number of external entities I was interacting with, my compiled code size (understandably) started to balloon.

  Sketches that would get too far above 90% of the program memory fell prey to memory leaks.

  Others would, of course, simply exceed the compiled 32KB limit altogether.

  At first, I would attempt to fix the memory leaks, then it was optimize the code, add #IFDEFs to debugging portions and finally play with compiler flags.

  If you’re wondering at this point whether all this effort was worth it, well, quite frankly so was I!

  Learning to write better code is great.

  But I could see the other members of the ATmega family of microcontrollers like the 2560, 1284p (and even the 644p) glittering off in the distance like so much fool’s gold.

  [To be continued with…]

  No Built-in Wireless

  The Need for Speed

  Running Out of GPIOs

  Fixed Pin Position Interfaces

  That Regulator & Power LED

  Why Pin-Compatible?

  Why Size-Compatible?

• 32-Bit & Wireless: The Pro Mini nRF52​

  Andy • 04/25/2019 at 14:07 • 0 comments

  Above: Pro Mini nRF52 (right) shown next to a Pro Mini 328p clone (left).

  (Note: An early development Pro Mini nRF52 shown with edge SMA, through-hole and U.Fl antenna pads.)

  In the beginning

  Shortly after the Pro Mini XL was born, I could feel the 32-bit world calling with its technological siren song.

  Microcontrollers in this space boasted faster speeds, even more program memory, DMA, etc.

  All very enticing for solving my Pro Mini problems.

  One of the realizations I came to after creating the Pro Mini XL, was that I was obviously still board-stacking.

  Many of my more recent projects had gone wireless, especially in the area of Home Automation.

  I found myself adding nRF24s, RFM69s, 95s or RN2903s to get the range and/or protocols I needed.

  And then there was encryption, “uniquification”, and over-the-air updates.

  I had boards with ATSHAs, EUIs and additional SPI Flash amongst other things.

  Add power distribution, monitoring, battery charging and actuators and we’re already at a 5+ board stack!

  So I took the 32-bit world’s red pill (or rather “Blue Pill”) and began to explore.

  I decided to focus my initial efforts on 32-bit microcontrollers that had built-in radios that I was already using.

  This lead to the natural selection of Nordic’s nRF52832.

  Benefits

  The nRF52832 is a 64MHz ARM Cortex M4 CPU (with FPU), 512KB flash (!) and a built-in 2.4GHz transceiver.
  

  The transceiver also supported Bluetooth 5, Bluetooth Mesh and ANT - which all sounded interesting.

  Scratch one radio board from my stack.

  Just as interesting was 128-bit AES/ECB/CCM/AAR (for encryption), 64KB RAM and 32 configurable GPIOs.

  Scratch at least one more board from my stack.

  All of this board-scratching sent me ferritting about for how to best get my hands probes on one.

  What confronted me was a veritable sea of modules and dev. kits, many of which were breadboard hostile.

  Most of the modules I saw had castellated pads requiring mounting to another PCB before use in my stack.

  A Pro Mini-sized board only leaves approx. 13mm between the right and left hand side edge pins.

  Modules that had metal shielding (for FCC certification, etc.) were simply too wide.

  Did I care about metal shielding or FCC certification?  At this point, no - I just wanted something to play with.

  So all the modules were either too wide to fit between the pins or I was going to be looking at some sort of oversized mounting PCB with 2.54mm SMD pin headers.

  Other dev. boards in the line up that were 2.54mm pin-friendlies like Adafruit’s Bluefruit or SparkFun’s Dev. Board weren’t Pro Mini pin-compatible.

  They made up a sea of different pin-out and board layouts

  All-in-all, rather non-friendly to an 8-bit Pro Mini native seeking his fortune in the 32-bit land of opportunity!

  So, I decided to roll my own.

  Limitations

  Since the nRF52832 was available in a QFN-48 package, this gave me more routing room than the 1284p.

  But I’d never worked with a QFN package like that before and didn’t know whether my “skillz” were up to it.

  Not one to shy away from a challenge though, I sketched out Nordic’s reference circuit schematic and began.

  I opted for the extra DCDC componentry to enable some lower power operations for later experimentation.

  After a rough place-and-route, the essentials fit quite nicely between my self-imposed prison of Pro Mini pins.

  However, the question then became, what exactly to route out, and where to?

  SWD vs. FTDI

  First on the list were the SWD programming pins.

  I had very limited JTAG/SWD experience coming, as I did, from the FTDI-world of the 8-bit ATmega.

  So my first thought was whether there was some sort of half-way house to ease my transition.

  Nordic’s SDK for the nRF52832 described a bootloader that could update the firmware of the device via UART.

  That sounded ideal.

  The device simply needed to be “reset” into a state in which...

  Read more »

• 8-Bit Bigger Brother: The ATmega 1284p Pro Mini XL​

  Andy • 04/25/2019 at 12:47 • 2 comments

  Above: Pro Mini XL (right) shown next to a Pro Mini 328p clone (left).
  

  (Note: An early development Pro Mini XL shown with ATmega 1284, without crystal osc. or reset switch.)

  In the beginning

  My first attempt at another Pro Mini became what I’ve come to call the “Pro Mini XL.”

  When compatibility is a key for ease of use, it makes sense to simply traverse a microcontroller family tree, if you can.

  The ATmega family members above the 328p that stood out to me were the 644p, 1284p and 2560.

  Upon initial investigation, the 2560 was immediately taken off the table.

  At 100 TQFP pins, it would simply never fit.

  A Pro Mini-sized board only leaves approx. 13mm between the right and left hand side edge pins.

  And even the smaller 64-pin QFN package of the 2561 at 9mm² would be too tight to route around.

  I didn’t want the extra expense of moving to a 4-layer board, mainly because I had a lot of 328p Pro Minis to replace.

  The 644p looked more promising in it’s 44-pin TQFP and QFN packages, but only when compared alone.

  For the same sized package (12mm² TQFP or 7mm² QFN), the 1284p was simply superior in every way.

  Benefits

  You can play your own game of 328p vs. 1284p spec sheet summary “Top Trumps” and note the differences.

  Those that mattered the most to me were:

  • 4x the Program Memory
    • 128KB vs. 32KB
  • 8x the SRAM
    • 16KB vs. 2KB
  • 4x the EEPROM
    • 4KB vs. 1KB
  • One extra UART
  • One extra 16-bit Timer

  Moving to a larger package, had the natural benefit of more programmable I/O pins to wiggle (32 vs 23).

  Upon further investigation, some other notable benefits that peaked my interest were:

  • One extra interrupt pin
  • Two extra analogue ports
  • JTAG interface

  And all this was purely additive to the 328p’s features (low power, PWM, WDT, QTouch, etc.) without forfeiting any of note.

  But.

  Would it fit?

  Limitations

  All this extra memory and added features came at a size cost.

  Or at least it did, way back when the 1284p was first released!

  Although my initial back-of-the-envelope calculations showed that 12mm TQFP pads would “likely” fit between approx. 15mm pin-to-pin through holes, the devil is (as always) in the details.

  You can see from the photo above that the 1284 in a TQFP is almost half the size of the whole PCB itself!

  Underneath that chip is a veritable spaghetti-junction of tracks and vias to try to route everything in and out.

  And I didn’t manage to route every pin.

  But even forfeiting as much as 8 pins (and some admittedly useful chip features) was still worth the benefits of extra program memory, etc. in my mind.

  I ended up having to stretch/bend/throw-up on some PCB design constraints that I usually set in stone.

  Things like routing into keep-out areas and on the outside of edge pins, just to name a few.

  I’ve not encountered any issues with “flexing” them yet though.

  Filtering caps should be much closer to the chip and I’d like more of them too.

  But, of course, the 800Lb gorilla in the room is the lack of an on-board regulator.

  I thought long and hard about this one whilst examining many of my existing project PCBs.

  In the majority of cases, I was handling project power elsewhere, usually in some sort of distribution board.

  Once a project had grown in size and scope, I rarely tapped anything off of the 328p Pro Mini’s regulator anymore.

  So, in the end, I bit-the-bullet and abandoned trying to fit one and the Pro Mini XL was born:

  Summary

  • 8 unrouted pins.
    • 25, 26, 32, 33, 40, 41, 42, 43.
  • Compromised design constraints.
  • No on-board regulator.
  • Fewer filtering caps.

  Improvements

  Pad size is a problem; everything is much bigger than I think it needs to be.

  Decreasing TQFP pad size by half might enable me to get some more pins/tracks routed.

  The same goes for the crystal and reset switch.

  Better part selection might...

  Read more »

View all 6 project logs