Project Logs

Collapse

• Power source woes

  piotrb5e3 • 01/05/2018 at 23:47 • 0 comments

  After some testing I conclude that a cr2032 is not a good choice for powering this project. A really large rail capacitance would be required to get a high enough current through the LED over the duration of the transmission. The losses on capacitor leakage would be unacceptable.

  Voltage measured over a 1Ω resistor in series with the LED. The first few pulses measure at around 500mA - just as planned.

  Unfortunately, even 800μF worth of caps wasn't enough to prevent the rail sag.
  

  The 300mV drop on the power rail corresponds to a 300mA lower current through the LED. The last few pulses are delivered at just 200mA. The range from which the message can be read clearly is around 10 meters, and requires pointing the receiver directly at the transmitter.

  And that's with delays between pulse trains increased twofold, halved pulse train length, and carrier duty cycle of 25%.

  I think that either 2 LR03's, or 3 NiMH 40H's with small solar panels will have to be used in this project.

• Going green

  piotrb5e3 • 01/04/2018 at 00:00 • 0 comments

  NO CR2032s WERE HARMED DURING THE FILMING OF THIS EPISODE. THE TL431 GOT SICK AND SOMEBODY LOST A CAPACITOR BUT THAT'S ABOUT IT.

  I built a configurable cr2032 replacement for development. It has 2 voltage modes: 3.0V and 2.75V, and 2 internal resistance modes: 20Ω and 40Ω. There's a current measuring jumper, and a connector for measuring the voltage across the "internal resistance".
  The schematic can be found here.

• A prototyping board

  piotrb5e3 • 01/02/2018 at 22:43 • 0 comments

  I built a prototyping board for this project. There were a few changes from the circuit posted in the last log entry. Here's the updated circuit.

  I tried to make it as generic as possible, so it can be used in other, future projects. 

• How do I drive LEDs again?

  piotrb5e3 • 01/01/2018 at 19:10 • 0 comments

  I designed a circuit to test different LED driving techniques, and measure their efficiency. Yes, this schematic has over 30 connectors/jumpers. Yay configurability!

  The full schematic can be found here.

• Capacitor leakage and choice of a switching device

  piotrb5e3 • 12/31/2017 at 00:15 • 0 comments

  One possible place of energy loss will be the capacitor array. Because of the high internal resistance of the cr2032 (tens of Ω) it's impossible to drive the LED at 500mA directly from the battery. At least a few hundred μF of capacitance will be needed to deliver the high current pulse. Electrolytics are no good because of their high leakage current (measured around 3μA with a 100μF low ESR one). MLCCs are the only option. 

  One of the stores I frequent has just what I need: generic 10μF 10V 1206 X7R capacitors. But what is their leakage current? I had a few of those laying around, so I quickly soldered "legs" to them and assembled a simple measuring circuit.

  On the left is a 3.3V regulated supply with an additional large smoothing capacitor (100μF). Then there's a 100kΩ resistor connected from the positive rail to one side of the 2 paralleled caps (lower right). The other end of the caps is connected to ground. A multimeter in voltage mode is connected across the resistor. Initially the resistor is shorted with a juper wire to let the caps fully charge. 
  

  The measurement came up 0.0 - 0.1 mV. Clearly we're dealing with a really low current here. I swapped the resistor for a 1MΩ one and measured again. This time it measured 4mV and quickly dropped to 2-1mV. After a minute it reads < 1mV. 1mV over 1MΩ is 1nA of leakage current, co we should be able to safely stack up to a 100 of those caps without worrying about battery life.

  Choice of a switching component

  If I'm reading it correctly, this datasheet implies that a base current in the range of tens of mA will be required to drive a 500mA load in saturation mode. Maybe we can do better? I searched the online catalog of the previously mentioned store for a logic level, low R_DS(ON) N-MOSFET. I managed to find the IRLML2502. It has R_DS(ON) of around 0.05Ω at 2.5V V_GS. Seems suitable. I'll get a few and test them against some generic BJTs.

• Guesstimating LED drive current

  piotrb5e3 • 12/30/2017 at 15:58 • 0 comments

  Let's see how much current can we put through the LED and still make the 1 year battery life goal.

  From the last log we have around 31ms of MCU activity time and 1.5ms of LED-on time. We also have around 180mAh of battery capacity left for transmitting the data.

  From the datasheet we get at most 2mA supply current in active mode using the internal 4.8MHz RC oscillator (divided by 4, all peripherals disabled). We'll try to calculate the maximum number of transmissions from a single battery depending on the LED drive current.

  The formula is:

  Where N_tr is the number of transmissions, Q_bat is the battery capacity, Q_tr is the capacity used by a single transmission, I_μ and t_μ are MCU current and time and I_D and t_D are LED current and time. We divide the calculated value by 365*24 = 8760 hours in a year to get the maximum number of transmissions in an hour.

  And the calculated values:

  LED current	Transmissions count	Max transmissions per hour
  10mA	8`415`584	960
  100mA	3`056`603	348
  250mA	1`482`837	169
  500mA	798`029	91
  1A	414`852	47

  We can safely aim for 500mA and 1 transmission per minute. Even with extra losses in the system we'll meet the 1 year battery life goal.

• Choosing the transmission protocol

  piotrb5e3 • 12/30/2017 at 14:37 • 0 comments

  As I've calculated in the previous log, around 70% of the total power consumption of this project comes from just the driving of the LED. The choice of protocol will have an enormous impact on battery life. My first choice was to use the NEC protocol. Let's see if we can do better.

  Let's look at protocols supported be the Arduino-IRemote library. We'll be using a 33% duty cycle (9μs LED on time).

  Name	Payload size (bits)	Max transmission time	IR on time (per transmission)
  NEC	32	86ms	8.937ms
  Denon	14	30.45ms	1.44ms
  Panasonic	48	90ms	9.108ms
  RC5	12	25ms	4.032ms
  RC6	19	24ms	4.032ms
  Sharp	13	31ms	1.728ms
  Whynter	32	102ms	9.507ms

  
  Let's start with the Denon protocol. Out of the available 14 bits 2 will be used for a checksum. This leaves us with only 12 bits for the password. 4000 combinations is not much, but for this project it should be enough.

• Rapid prototyping and back-of-the-envelope calculations

  piotrb5e3 • 12/30/2017 at 01:22 • 0 comments

  The choice of a microcontroller

  I searched my drawers for unused MCUs and came up with the following:

  Device	Current consumption (in power-saving mode)	Minimum voltage	Package
  ATmega328P	1μA	1.8V	DIP28
  ATtiny13A	4μA	1.8V	SOIC8
  AT89C2051	1mA(1)	2.7V	DIP20
  STM32F070F6P6	2μA	2.4V	TSSOP20
  STM32F051K8T6	0.8μA	2V	LQFP32
  STM32F103C8	2.6μA	2V	LQFP48

  (1) - it has a power-down mode, but the only way to exit it is a hardware reset

  We can discard ATmega328P and AT89C2051 because of large packages. Then STM32F051K8T6 and STM32F103C8 because of hard to solder packages. Looking at a generic cr2032 datasheet we see that the 1.8V minimum supply voltage of ATtiny13A isn't much of an advantage. But the STM32F070F6P6 is a much more complex device. Let's check if halving power consumption is worth it.
  

  Going back to the datasheet we read that a typical cr2032 has the capacity of around 200mAh. At 2μA it makes for 200mAh/0.002mA = 100000h ≈ 4166 days ≈ 11 years. At 4μA it's ≈ 5.5 years. Scaling it back to our 1 year battery life target we get 9% and 18% of power consumption going to the powered-down MCU respectively. A 9% total efficiency increase is not insignificant.

  Nevertheless I decided to go with the ATtiny13A, as it's a simpler design, and I'm already familiar with it.

  Let there be (invisible) light!

  I quickly wrote a short 38kHz bit banger for the ATtiny13A using the NEC transmission protocol (see the source code), and assembled a simple circuit (schematic PDF).

  This is the final iteration. At first I tried driving the IR LED directly from a microcontroller pin, but the range was poor due to a 40mA current limit. A MOSFET would be ideal, but none of those I stock has V_{GS (th)} < 3V.

  I used 2 10Ω resistors in series with a 3.3V regulated power supply to mimick the internal resistance of a cr2032 cell. Multiple large electrolytic capacitors are used to provide a low ESR power rail for high current LED pulses.

  I measured the peak current with an oscilloscope connected across two paralell 0.1Ω resistors. It peaked at 0.02V over 0.05Ω which gives us 0.02/0.05 = 0.4A = 400mA.

  I built a simple receiver and was able to read the transmitted data clearly across the hallway in my home - around 13m across. Field test will be required to check actual broadcast range. The receiver is a simple circuit with 2 status LEDs - the blue one blinks when the correct sequence was received, and the red one when an incorrect sequence was received.

  The envelope

  Let's dial down the current and consider a 100mA peak drive. A 32-bit transmission with the NEC protocol consists of a 342-pulse header, 32 bit markers of 21 pulses each, and a 21-pulse ending sequence. Each pulse is 13μs long. This gives us 342 + 32*21 + 21 = 1035 pulses per transmission, for a total of 13.455ms of high current draw. Additionally, the microcontroller will be active for at least 70ms at a current draw of around 2mA. This adds up to 13.455ms*100mA + 70ms*2mA ≈ 0.000413mAh.

  After substracting the power needed for the idling MCU we are left with around 160mAh of battery capacity. This will allow us to transmit around 387409 times. In a year, that makes for 387409/(365*24) = 44 transmissions per hour. It's 30% less than my intended target of once-per-minute, but at least we are in the right ballpark.

  One final note: electrolytic capacitors have a considerably high (tens of μA) leakage current. Because of that they should be avoided in low power applications. We'll have to do with just ceramics.

• Motivation and goals

  piotrb5e3 • 12/30/2017 at 00:16 • 0 comments

  The "Why?"

  This project starts as an entry for the Coin Cell Challenge, but I hope it will outlive it.
  I enjoy microcontroller projects and geocaching. Let's make something that will be fun not only for me, but also for others!

  The "How?"

  The basic idea is to make a beacon that periodically transmits a number. This number will be used a password for a virtual geocache.

  The device should be small and easy to hide. It should last a year on a single battery. The battery must be replaceable. It will be placed outside, so it must be weather-resistant (rain, snow, ice, direct sunlight, temperatures -20°C to +60°C). Transmission must have a broadcast range of at least 20m  (up to 50m if possible). It should follow a well documented protocol. The number should be hard to guess and contain a checksum.

  Construction of a receiver will be left to the geocacher, but example code and schematic should be included.

  The "What?"

  It looks like we'll be needing a microcontroller and some IR LEDs for this one. The rest is up in the air. Let's get prototyping!

View all 9 project logs