One only has to ship one or two things via a container, receiving them strangely damaged on the other end, before you start to wonder about your shipper. Did they open this box and sort of stomp around a bit? Did I perhaps accidentally contract a submarine instead of a boat? Did they take a detour past the sun? How could this possibly have melted?
[Jesus Echavarria]‘s friend had similar fears and suspicions about a box he is going to have shipped from Spain to China. So [Jesus] got to work and built this nice datalogger to discover the truth. Since the logger might have to go for a couple of months, it’s an exercise in low power design.
The core of the build is a humble PIC18. Its job is to take the information from an ambient light, temperature, and humidity sensor suite and dump it all to an SD card. Aside from the RTC, this is all powered from a generic LiPo power cell. The first iteration can run for 10 days on one charge, and that’s without any of the low power features of the microcontroller enabled. It should be able to go for much longer once it can put itself to sleep for a period.
It’s all housed in a 3D printed case with some magnets to stick it to shell of the shipping container. Considering the surprisingly astronomical price of commercial dataloggers, it’s a nice build!
In lots of ways he has good reason to be excited. We all know that IR can communicate quite a bit, but when you’re clever about frequency and color and throw in some polarizers with a mix of clever algorithms for good measure you can get some very high bandwidth communication with anything in line of site. You can do it for low power, and best of all, there are no pesky regulations to stand in your way.
He wants to build a system that could be used for a PAN (Personal Area Network). To do this he’ll have to figure out a way to build the system inexpensively and using less than a watt of power. The project page is full of interesting experiments and quite a few thesis on the subject of LEDs.
For example, he’s done work on how LEDs respond to polarization. He’s tested how fast an LED can actually turn on and off while still being able to detect the change. He’s also done a lot of work characterizing the kind of light that an LED emits. We don’t know if he’ll succeed yet, but we like the interesting work he’s doing to get there.
Is your business card flashy? Is it useful in a pinch? Do they cost $32 each and come with an ePaper display? No? Well, then feast your eyes on this over-the-top business card with an ePaper display by [Paul Schow]. Looking to keep busy and challenge himself with a low-power circuit in a small package, he set about making a business card that can be updated every couple of months instead of buying a new stack whenever he updated his information.
Having worked with ePaper before, it seemed to be the go-to option for [Schow] in fulfilling the ultra-low power criteria of his project — eventually deciding on a 2″ display. Also looking to execute this project at speed, he designed the board in KiCad over a few hours after cutting it down to simply the power control, the 40-pin connector and a handful of resistors and capacitors. In this case, haste made waste in the shape of the incorrect orientation of the 40-pin connector and a few other mistakes besides. Version 2.0, however, came together as a perfect proof-of-concept, while 3.0 looks sleek and professional.
[David] created a great looking e-ink WiFi display project that works a little like a network-connected picture frame with a few improvements over other similar projects. With the help of an ESP8266 it boots up, grabs an 800×600 image over the network, updates the screen, then goes back to sleep. Thanks to some reverse engineering, he was able to make his own firmware for the onboard controller to handle the low-level driving of the display. Since e-ink displays require no power to hold an image and the rest of the unit spends most of the time either asleep or off, power use is extremely low. [David] hopes to go months without needing to recharge the internal lithium-polymer battery.
We previously featured another WiFi-connected e-ink display project that was in fact also the inspiration for this version. [David] uses a 4.3″ 800×600 GDE043A e-ink display and wrote his own firmware for the STM32F103ZE ARM CortexM3 SoC used as a display controller, a process that required some reverse engineering but was aided by the manufacturer providing a closed-source driver for him to use. [David] writes that some reverse-engineering work for this display had already been done, but he had such a hard time getting a clear understanding from it that he reverse engineered the firmware anyway and used the documents mainly for validation and guidance.
As a result, [David] was able to make use of the low-level driver electronics already present on the board instead of having to make and interface his own. E-ink displays have some unusual driving requirements which include generating relatively high positive and negative voltages, and rapidly switching them when updating the display. Taking advantage of the board’s existing low-level driver electronics was a big benefit.
The ESP8266 rounds out the project by taking care of periodically booting things up, connecting to the wireless network and downloading an image, feeding the image data to the STM32 to update the display, then disconnecting power from all non-essential electronics and going back to sleep. We especially like how the unit automatically creates a WiFi access point to allow easy (re)configuring.
There’s one more nice touch. [David] goes the extra mile with server software (in the form of PHP scripts) to design screens for the display with data like weather forecasts, stock prices, and exchange rates. Check it out in the project’s github repository.
Newly minted hams like me generally find themselves asking, “What now?” after getting their tickets. Amateur radio has a lot of different sub-disciplines, ranging from volunteering for public service gigs to contesting, the closest thing the hobby has to a full-contact sport. But as I explore my options in the world of ham radio, I keep coming back to the one discipline that seems like the purest technical expression of the art and science of radio communication – low-power operation, or what’s known to hams as QRP. With QRP you can literally talk with someone across the planet on less power than it takes to run a night-light using a radio you built in an Altoids tin. Now that’s a challenge I can sink my teeth into.
We’re pretty far away from a world full of wall-warts at this point, and the default power supply for your consumer electronics is either a microUSB cable or lithium batteries. USB ports are ubiquitous enough, and lithium cells hold enough power that these devices can work for a very long time.
USB devices are common, and batteries are good enough for most devices, not all of them. There is still a niche where& extremely long battery lifetimes are needed and tapping into mains power is impractical. Think smoke detectors and security systems here. How do power supplies work for these devices? In one of the most recent TI application notes, TI showed off their extremely low power microcontrollers with a motion detector that runs for ten years with a standard coin cell battery. This is one of those small engineering marvels that comes by every few years, astonishing us for a few minutes, and then becomes par for the course a few years down the road.
The first thing anyone should think about when designing a battery-powered device that lasts for years is battery self-discharge. You’re not going to run a battery-powered device for ten years with a AA cell; the shelf life for an Energizer AA cell is just 10 years. Add in a few nanoAmps of drain, and you’ll be lucky to make it to 2020. The difference here is a CR2032 lithium-ion coin cell. Look at the datasheet for one of these cells, and they can easily sit on a shelf for 10 years, with 90% of the rated capacity remaining.
With the correct battery in the device, you’ll need a microcontroller that runs at a sufficiently low power for it to be useful in the mid-2020s. The product for this is the CC1310, a very, very low power ARM Cortex-M3 and sub 1GHz transmitter in one package.
Once that’s settled, it’s simply a matter of putting a sensor on the board – in this case a PIR sensor – and a few analog bits triggering an interrupt occasionally. Have the microcontroller in sleep mode most of the time, and that’s how you get a low-power device with a battery that will last a decade.
We’ve all been there. You’re building up a microcontroller project and you wish that you could just add “one more feature” but you’re limited by the hardware. Time to start thinking. (Or, arguably, buy the next model up.)
The problem with potentiometers in low-power designs is that they’re always leaking power. That is, unless you switch them off when you’re not using them. So the ideal solution is to power the potentiometer from one GPIO pin on the microcontroller, and read its value with another. That’s two GPIO pins just for the potentiometer. But [Sam] needed to read input from a button too, and he was out of pins.
Not pressed: pot sees VCC and VCC/2
Pressed: pot sees VCC/2 and GND
His clever solution is to switch two resistors in or out of the circuit depending on the status of the pushbutton, so that the voltage range at the potentiometer is between either VCC and VCC/2 when the switch is pressed, or between VCC/2 and GND when the switch is not pressed.
If the ADC reads something higher than VCC/2, the microcontroller knows that the button is pressed, and vice-versa. The potentiometer’s setting determines exactly where the voltage lies within either range.
Done and done. If you find yourself in the similar situation of needing to read in values from a whole bunch of buttons instead of a potentiometer, then you can try using an R-2R DAC wired up to the pushbuttons and reading the (analog) value to figure out which buttons are pressed. (If you squint your eyes just right, this solution is the same as the R-2R DAC one with the potentiometer replacing all but the most-significant bit of the R-2R DAC.)