Daylight Logger for Gardening Part 2

Previously we established (loosely) the need for a sunlight logging device.  We came up with a basic design plan and the requirements of each necessary element.  And here is what I built:

It's a bit more complicated than I may have led you to believe, but not all that much so.  Let's take a look at the blocks.

Memory:

The memory is nearly as expected straight off the data sheet.  I have the address and write protect lines wired low to make life simpler.  R7 & R8 provide the expected pull up resistors for the I2C protocol but there is an LED in parallel with the SCL signal.  D2 is basically my status LED and the only means by which I can communicate with a user.  The SCL signal is used because the memory chip will not respond to "spurious" changes on that line.  An I2C start condition requires the SDA line to go low while the SCL line stays high.  So as long as the SDA signal stays high, the memory chip will ignore changes on the SCL line.

Communication:

Q1 & Q4 are setup so that no current flows while not sending or receiving data.  Since the device will spend most of the time logging, it's prudent not to have any excess idle current draw.  Q1 didn't have to be a FET, but it just made it easier to deal with inputs that could range something like +/-12 volts.  The TX pin of the MCU is combined with another feature of the circuit, so Q4 will turn on during normal operation for small amounts of time, but R3 was sized to reduce power consumption.

Detector:

The first major change to the detector is the addition of Q3.  It takes only small amount of time to measure a light sample, so the circuit really spends most of its time idle.  The amplifier has a quiescent current of  230uA which isn't half bad, but not as good as zero.  The ambient light sensor is much worse, drawing several mA in full sunlight.  So Q3 is only turned on just prior to reading sample, which in turn supplies power to the light sensor and amplifier.  As a side effect, Q3 also turns on, but hey, I only had so many I/O pins to work with.  I also added a pot to adjust the sensitivity of the sensor.  The sensor will try to allow a current proportional to the amount of light (voltage source permitting) so the amount of resistance will directly have an effect on the voltage seen by the ADC.  A lower resistance will provide less sensitivity, and a wider input range, while a higher resistance will max out and clip quite quickly.  R2 is included only so that while programming the PIC12F1572, the amplifier output and data line of the programming tool don't drive each other directly.  You may have noticed that the memory is never powered off; it has a standby current of only 1uA, and more importantly, the signal for Q3 cannot be used to turn it off and on while also being used as the TX line for communications.

Nearly finished design

Microcontroller:

As stated before, the PIC12F1572 doesn't have a ton to do, but it does make this whole thing work, and keeps the batteries alive.  When power is turned on, LED D2 lights up and the device sits in a "ready" state.  At this point it will accept requests from a PC to dump previous logging data, and assists in calibration.  By exposing the light to full sunlight, the potentiometer can be adjusted by a watching the LED.  Steady on means that the ADC is maxed out, and a rhythmic blink indicates that the ADC is reading between max and min values.  So ideally, one would adjust the pot until the LED is steady, then back off slightly until it blinks.  A slow blink indicates the battery is low.

How does the micro know that battery is low?  Well I think the solution is rather ingenious, but I strongly doubt I'm the only person to come up with it.  I already discussed the fixed voltage reference used to ensure consistent ADC results over varying levels of battery.  So why not measure the voltage reference using the battery as the upper ADC voltage.  As the voltage of the batteries drops, the measured value of the fixed reference gets larger.  Consider an 8-bit ADC result (0-255) with the voltage reference set tot 2.048 and the battery supply at a nominal 3V.  We can come up with the equation Vref/Vbat*resolution = result.  By substitution we get 2.048/3*255 = 174.  That means a reading of 174 indicates a full battery.  Our low end is unfortunately only 2.7V (that's the minimum input supply of our op amp, I would/will change op amps for future revisions, but it was one that I had on hand), but we can calculate that value too.  2.048/2.7*255 = 193.  If we reada value larger than 193, we cannot assume that our op amp is properly biased.  And that is all there is to it, just periodically make the measurement and blink the LED if necessary.

Now that covers the "ready" state of the device. but how do we get it to take light readings?  By pushing reset button S1.  Yes, the reset button.  And yes, it does reset the device.  This is another clever trick that I will pat myself on the back for.  The PIC12F1572 has a control register that keeps track of the cause of a reset.  Early in the code, that register is read to determine whether power was just supplied or the button was pushed.  If the button was pushed, the device skips the "ready" state and starts a 16 second timer to allow a user to place the sensor.  Then, for the next 24 hours, the circuit takes sunlight readings at approximately two minute intervals, after which it goes into a permanent sleep state.

Here is a screenshot of the program I made to accompany the project.  It lets you connect to the device via a serial port and download the light data, as well as save or import the data as a CSV file.  You can see that this particular data set is for a rather sunny day with little shade (though I hadn't calibrated it before running this test).  It should also be noticeable that I began logging on the latter part of sunset as the beginning of the graph is mostly nighttime.  Sunrise should be pretty obvious by that dramatic ramp up in recorded light.  I'm actually quite proud of my background that I drew up.

Although it's an embarrassingly ugly construction, I'll show the working prototype anyway.  There was definitely a lot of design after the fact leading to a bit of chaos.  But I temporarily stuck it to the lid of a salsa jar (my "weatherproofing") using a little putty and it works just fine.  We can look into a few of the design hurdles in the next post.

Daylight Logger for Gardening

While I don't much like to garden personally, a certain someone really wanted to improve my landscaping as well as grow a variety of vegetables and herbs and whatnot.  As we shopped for various plants and seeds I took note of the sunlight requirements listed on each.  Generally it was a qualitative statement such as "Full Sun" or "Partial Shade".....  Well what does that really even mean?   Being the engineery kind of guy that I am I needed something more quantitative.  So a quick internet search while at the store yielded answers as such:

Full Sun = 6 or more hours of direct sunlight daily
Partial Sun/Partial Shade = Between 3 and 6 hours of direct sunlight daily
Full Shade = Less than 2 hours of direct sunlight daily

However, the more reading you do on certain plants you find that while six hours may constitute the minimum requirement if you will, many plants will do better with even more sunlight.  And all of this kind of begs more questions: what about the variations in amount of shade?    Are these aggregate amounts of sun daily? (and from what I've figured out, yes)  Is sunlight at certain times better than others?  But most importantly, what kind of sun do I get in my yard?

I live in a neighborhood with many old and massive oaks.  While the neighborhood is by no means new, when built they did a good job of leaving many of the existing trees.  So areas of the yard that may be next to the sidewalk and nowhere near a tree might get lots of morning shade due to the oaks behind the neighbor across the street.  Then late morning and afternoon sun.  Then late afternoon shade.  Then early evening sun.  Just from observation working outside or mowing the lawn I've noticed that the amount of sun can swing both directions several times throughout the day.  It'd be interesting to find out how much.....  Especially if I want optimize my planting (and yes, normal people don't "optimize" their gardens, nor is the effort likely worth it).

The Project:
Where to start.  Basically, we need to measure the sunlight a bunch of times over an interval, say one complete day.  We then must store those measurements and then be able to recall them for consumption later.  This will also have to run off of batteries and be resilient to weather.  That should pretty much cover it.

Sunlight Detection:
Measuring the sunlight won't be all that much different than the IR detector used in the Virtual Whammy Bar.  Instead of a narrow spectrum detector though, we'll use an ambient light sensor.  This is more or less the same idea as an IR photo sensor except its response resembles our ability to see light.  I believe such devices are used to automatically turn on the head lights in newer cars when it gets dark.

That's the fundamental circuit.  It'll have to evolve going forward, but functionally it will remain the same.  I probably could do away with the buffer on this one,  Our ambient light sensor sources quite a bit of current.

Memory:
The memory chip will be a Microchip 24AA08.  Why?  Because I had a couple.  It's a whopping 1KB, though marketed as 8Kb (B = bytes, b = bits).  At least the 1K actually equals 1,024.  I had larger memory, but it was SRAM instead of EEPROM.  It does have a 1uA standby current, which is convenient for our battery powered circuit.  The I2C interface is handy too as I have to manually bit-bang the protocol.

ADC/Microcontroller:
We'll actually be using the internal ADC of the microcontroller, which is a Microchip PIC12F1572.  I showed it separately only be cause it needs a little consideration.  Since our circuit will be battery powered, the circuit voltage will vary over the life of the batteries, which means we can't use our circuit power as the ADC's positive voltage reference.  Fortunately the micro contains a fixed voltage reference module.  By manipulating the appropriate registers you can get a 2.048V reference, which can also be connected to the ADC module.  I'm taking a guess that the light sensor is less dependent on the applied voltage as it is to the applied light, as its response is to allow current flow.  Truthfully, I don't know the actual part number of the ambient light sensor, but some datasheets I've looked into support my conclusion.  But regardless of the voltage from the batteries, the ADC will always measure the incoming light based on a 0 to 2.048V scale.

Our microcontroller does all of our grunt work.  It will schedule when to take light measurements, store the results in the memory, and communicates via a serial port with a PC.  It'll perform a few other functions we'll discuss later, but these are it's core responsibilities.

In the next post I'll show the resulting circuit and discuss more details of the design.

USB-to-Serial Mod for Sort of an Embedded Guy

I was first introduced to embedded design back in college where we had two classes based on the Motorola 6800 and 68000 series microcontrollers.  One class focused on the architecture and the other on assembly and the instruction set.  I immediately wanted to make a project of my own.  Unfortunately the classes were a little too theoretical and didn't detail the necessary steps to actually get a circuit up and running.  But even so, I managed to order myself a Microchip ICD2 decently cheap and a couple of DIP packages (and oops, a QFN chip) as samples.  It was all very exciting, until I unboxed it realized I needed a serial COM port, and my computer didn't have one.  Off to the electronics store to buy a USB to Serial adapter.

So that is all well and good until you get comfortable blinking lights and such, and want your little circuit to talk to a computer.  I actually used a MIDI port as my first serial interface because I had musical devices in mind.  A fun learning experience, but in the end I did end up getting a USB ICD2 down the road freeing up the serial adapter.  Then started a different set of issues.

To comply with RS-232 standards, the adapter not only inverts the signal, it bumps it up to 12V.  Your garden variety embedded circuit will be 3.3V or 5V.  Inverting the signals and dealing with the voltage difference can be handled easily enough though, with a 74x04 Hex Inverter or a couple of transistors.  It just crowds the bread board and is one more thing to assembly to get a circuit up and running.  Also, that DB9 connector is a pain and you're stuck tethered about 12 inches from the USB port.

Possible Solutions:

1. Make a breakout board.  Seems easy at first, except the DB9 headers I have don't fit into a .100" grid due to offset rows.  The target circuit would also have to power the circuitry needed to invert and convert the voltages.  You could remove the DB9 and solder direct or use a different connector, but still not the best idea.
2. Remove the DB9 and add a .100" header or solder pins directly to the PCB of the adapter.  I actually did this, it made hooking it up easier, but destroying the plastic housing of the adapter made things kinda hairy.  There was pretty much no more strain relief, and everything was exposed and unprotected.  It just wasn't a comforting setup.
3. Buy a breakout module off the internet.  This is actually probably the best idea.  They're small, cheap, and self contained.  As a matter of fact, I could just take an Arduino Nano and blank the program of the chip (it'd probably be cheaper than a breakout module).  Then I'd get a 3.3V and 5V supply with it as well.  But then I'd always be tempted to make something else out of it....  And what fun is that?  I already have this adapter, let's make something out of it.
4. Build a module based around the PCB of the adapter.  The 5V from the USB bus can power any extra circuitry, and even the target device if needed.  And, it uses up stuff I already have!

Shown above is my resulting device.  As an afterthought I added J4 to support the original function of the adapter.  It turned out that after I built this, the one thing I wanted to test it on already had circuitry built in to invert and level shift the voltages.... Oops.  I had to include jumper J3 so that the output of my hex 74ALS04 wouldn't fight against the output of from a RS-232 device.  The output of U2.6 would be unpredictable with nothing plugged into J2, resulting in a situation where it could try to drive +5V while a RS-232 device tries to drive -7V or even lower.  I don't know if there is enough short circuit protection in these IC's for a 12V differential, but I don't want to find out.  De-soldering chips is a huge hassle.  The jumper also makes the circuit look like it has more features!

Speaking of short circuits, I added a few resistors in places to protect stuff.  The 120R resistors take the brunt of improper connections, though probably survive too long.  But they are easier to replace.  In retrospect, I should have gone larger, but I won't fix that issue until something starts on fire.  We'll just pretend they're fuses.

The 4.7K resistor essentially handles my "level shifting".  While the datasheet says the 74ALS04 can handle up to +7V, that may be dependent upon the supply voltage.  I'm showing my estimation of the input circuit.  Protection diodes D1 & D2 may or may not exist.  If they don't, a +7V input is no big deal as the emitter of Q1 won't take any current.  On the other hand, a -7V input will likely draw excessive current.  R3 of my circuit above limits that to a safe amount.  Now if the diodes do exist, the positive input could present an issue.  Any voltage above Vcc (+5V) plus the diode drop (typically spec'd at .3V from what I've seen from datasheets) will be seen as a short across D1.  Again, the 4.7K resistor limits the current.  The same also goes D2 with negative input voltages.  Anything below -.3V starts to short across the diode.  There are likely some small resistors (or perhaps just inherent resistances) in series with D1 & D2, but they may not be up to par.

I could probably just use the diode check of my multimeter across the input of a 74ALS04 with respect to the supply pins to determine the presence of the protection diodes; but at the time of writing this I'm sitting in a coffee shop.  And besides, I've already soldered it all together.  Better safe than sorry.

Photo taken from USBGEAR.com

Above is a similar adapter to what I started with.  The little box in the middle of the cord houses the PCB and a ton of potting material.  Below is my finished little module.  Not the greatest piece of workmanship, but I did get to use my router table.  My skills with the hot snot need improvement, but overall I'm happy with the result.  It's heavy enough that attached cables don't force it to move or twist, and the solder side is protected from any incidental contact with parts lying on my desk.  And best of all, I made it.

Not pretty, a bit messy with the hot glue, but it's worked really well so far.

Use an Arduino with Atmel Studio

The Arduino line of embedded platforms have become pretty popular among hobbyists and for prototyping or quick proof of concept.  Depending on the type of news you follow on the internet, you've probably heard about all sorts of projects people have done using them.  I've even seen them for sale in electronics stores.  And for good reason, Arduinos have a lot to offer.

The Setup:

All said and done, Arduino really comes down to being a combination of a custom compiler, a bootloader, and a minimum set of hardware so as to require nothing more than a USB cable.  The compiler reminds me of the pairing of C# and .NET: the language syntax is clean and easy to use, and the API abstracts you from all the granular detail.  Everything is handled thru wrapper functions that makes the hardware nearly invisible.  No digging around in datasheets for esoteric bit settings and flags to get peripherals to work, they take care of it for you.  The bootloader removes the need for a programming tool, and thus external hardware.  And finally, the hardware consists of an Atmel Atmega328 with enough components to power, communicate serially over USB, reset, and access the I/O of the microcontroller.  But what's really nice is that the initial investment is only the cost of the Arduino board itself.  The IDE is provided free of charge and loaded with example programs to get you started.

So I purchased a Nano (one of the several flavors offered), plugged it in, and got started.  The first thing I noticed is that it just shows up as a generic COM port in Windows.  This will be helpful later.  But I did what most people would do, the proverbial "Hello, World!" of embedded systems: blinking an LED.  And behold!  My will was manifest upon the physical world.... in the form of a small little light... turning on and off at one second intervals....  Well hey, it only took 2 minutes, and that's the power of the Arduino.  (and the IDE actually has code for a Blink program included which kinda takes the fun out of it, but it can be modified as I did to do things like blink at different rates based on input)

However, I found myself feeling rather constricted by the platform.  I wanted to have full control over that Atmega chip!  I guess the Arduino isn't meant for me....

The Solution:

Atmel provides their own IDE, Atmel Studio, intended for C/C++ development on their microcontrollers.  It's actually built in top of Microsoft Visual Studio and inherits many if the features.  The problem is that it requires specific programming tools.  So even if I write a program, I can't get it into the chip.  This is where understanding what the Arduino is came in helpful.

At the end of the day the Arduino isn't dumping Arduino code to the microcontroller.  It's sending a compiled binary the same as Atmel Studio would.  But how?  Turns out the Arduino IDE has an option for verbose output when compiling and loading a program.  The IDE uses a command line tool called AVRDUDE which supports programming Atmel chips using a myriad of tools (including the Arduino bootloader).  I can just copy the command line arguments to write any .hex file I want.  AVRDUDE can be downloaded or comes with the Arduino IDE.

So problem solved.  Build the program in Atmel Studio, copy the binary into the AVRDUDE directotry (or type the whole build path in the command line), open a console window and away we go.

Well actually, this kinda sucks.  It's a bit of a hassle.  You gotta move around between a few windows and manually do a bunch of stuff.  It gets old.  Fast.  But there is a better way.  Visual Studio (again, the underlying software for Atmel Studio) allows for custom commands.  In the image below you can see that I've created a tool using AVRDUDE and just copied all the command line arguments that I used above.  The important pieces to note are that the initial directory is set to the build directory of whatever project is open so that the path to the .hex file is unnecessary, and the same goes for the name of the .hex file.  I've also checked the box for "Use Output window" as it's nice to see any messages from AVRDUDE.  The only caveat is that you need to manually change the COM port argument if you use a different USB port.  Otherwise, assign the tool to the button and the process becomes quick and easy.

But wait!  There's more!  We have ourselves a programmer, but not a debugger.  Truthfully, that's a bigger hurdle, but we can at least come up with a way to easily get feedback from the Atmega328.  Since we're using an Arduino, we've already got ourselves a convenient COM port by default.  We can just have our code spit out info over the UART to allow for visibility into its operation.  I went ahead and wrote myself a simple console application in C# that takes a COM port and baud rate as arguments and will run in Atmel Studio the same as AVRDUDE.  Not nearly as powerful as a debugger, but still useful enough.

The Finish:

Well there we have it.  With only an Arduino board (and not just the Nano I'm using) and a USB cable we have a simple Atmega development platform.  We can use the Atmel software with a somewhat seamless workflow by only adding some command tools.  This may not be for everyone, as the Arduino platform in and of itslef provides a lot of functionality, but for some, this may give you extra flexibility with the Atmel chip to do what you want.  Alright, I've typed Arduino way too many times....

Whammy Bar Display Select Revisited Part 4

I started to simulate each diode again while paying attention to the model parameters, and sure enough, I deduced the culprit. A little value called 'n', which is the "emission coefficient" or the "ideality factor" depending on where you look. By observation, LED's with a smaller 'n' value worked better than those with a larger one. What effect does 'n' have? Let's look at Schockley's equation:

If we consider all other variables to be constant other than 'n' and '$V_D$' (the voltage applied to the diode), we can look at how the diode will behave. For n = 1, we find that the current through the diode increases quite rapidly as the voltage applied is increased. In fact, if n = 0 you have an ideal diode for any positive $V_D$ (yes, dividing by zero is undefined, but the limit as you approach a zero denominator is infinity, giving rise to a huge exponent). On the other hand, if n begins to increase, we can see that any increase in $V_D$ starts to produce a smaller increase in the current thru the LED. Now the LED appears more ohmic, requiring more voltage to carry more current. This should demonstrate why 'n' is called the "ideality factor". An ideal diode is a perfect conductor when a forward voltage is applied. Let's compare some values of 'n':

LTSpice doesn't let you use a value of n = 0, so i used n = 0.01. But you can see that the slope for the smaller values is much steeper than larger values. Another thing to note is that the "on" voltage increases with n as well. The knee (part of the curve as a diode transitions from off to on) is also becomes much more gradual too.

So what does this all mean again? The ideality factor determines the performance of the LED's in biasing the transistors. A larger 'n', being less ideal, behaves more like the resistors we initially simulated, whereas a smaller value behaves more like the ideal voltage sources.

Does this matter? Well, maybe. First off, if the current thru the LED connected to the base is only a single order of magnitude (or less) smaller than the current going thru the active LED, it may be somewhat visible. That's no good. Also, this circuit will likely run off of a battery. If i can drive the LED with 10uA of bias current instead of 300uA, that is considerable savings, especially considering the whole device only draws around 7mA. And those bias currents are cumulative. To display an "8" requires seven segments. At 300uA a segment that's a whopping 2.1mA worth of bias, ouch. I'll take the 70uA please.

So what does the Virtual Whammy Bar circuit do? Good question. The seven segment display appears to be a Fairchild MAN74A, and fortunately there is a datasheet. And it has graphs:

 Looks nice and steep to me. My guess is that we'll find the real thing performs well.

So it was a little difficult to measure currents since my circuit is already built on a PCB and I don't have the spare parts to mock it up on a breadboard. My test then, was to set a breakpoint in the software right after the "TENS" display was activated. This way I wasn't measuring average voltages as the displays are strobed on and off with duty cycles based on the brightness. What did I measure? the voltage between the Emitter and Base of Q1. Why? Well, the more ideal the LED's the closer to 0 this measurement will be, whereas the worse the LED's are, the closer the value will be to a diode drop. What did I get? 176mV. That's pretty good. And that was with 6 segments illuminated. It may not be a definitive test but I'm gonna go ahead and say there's a lot of current gain goin' on here and call it a success.

Well that more or less concludes my offshoot into this whole topic. It was a whole lot of work and discussion over such a small thing, but I hope you found it interesting nonetheless. What started as an accidental mis-wiring turned out to be kind of a neat phenomenon. Until next time...

Whammy Bar Display Select Revisited Part 3

So let's simplify the original circuit again. I've replaced the diodes this time with voltage sources to approximate ideal diodes in the forward active region. And look at the results. The current gain nearly equals β, but the current is also near enough to saturation. So we're turning the LED fully on but using very little base current to do so. However, we don't have to tweak anything to optimize this; using a different transistor (with a unique β) and you'll still see a similar current thru V1. Using a 2N2222 yielded 2.606mA, a difference of about 10uA. Changing the forward voltage drop of V1 and V2 will only adjust the "saturating" current thru V1. It's like the circuit is self adjusting. Let's look at the characteristic curve and load line:

So the Y-intercept of the load line is the theoretical max current of the circuit and is given by Imax = (Vcc-V1)/R1 = 3.3mA. The X-intercept is the maximum voltage that can be dropped across Q1 for the given circuit: Vmax = Vcc-V1 = 3.3V. I put the cross hair as close as possible to the intercept point, and sure enough, we see our 2.6mA from the simulated circuit. While our operating point is somewhat close to the saturation region, the gain indicates that there is very little saturation occuring. Again, changing the transistor or voltages of V2 & V3 will give similar results.

At this point I've done a few examples and a bunch of math and analysis, but why again? Well initially, our simulated LED's were behaving either like the resistors or like the voltage sources depending on the particular part that was used. The question is why do they operate differently?

Whammy Bar Display Select Revisited Part 2

 

Let's start by looking at the circuit in a more traditional manner by using passive loads. Above I've shown the simulation results using 1K resistors instead of LED's. Of course, this circuit saturates rather dramatically. We only see a gain of 1.6. Using Ohm's law and assuming a Vb for the transitor of about .7V, we find that R2 can only draw around 700uA more than R3 before Q1 saturates. Our above simulation confirms the estimate. Why is this? Well if we remove R1 altogether (it doesn't change the circuit in any significant way) we can derive the following equations:

I(R2) = (Vcc-Vc)/R2 with ideal saturation: I(R2) = (5-0)/1000 = 5mA

I(R3) = (Vcc-Vb)/R3 with subsitutions: I(R3) = (5-.7)/1000 = 4.3mA

Current Gain = I(R2)/I(R3) = 5/4.3 = 1.163

The approximate calculations match fairly close to the simulation results. It turns out that Vb is greater than the assumed .7V diode drop due to the fairly large base current. Also, Vc cannot be pulled all the way down to 0V. Even so, the number differ only slightly. And besides, the ultimate point is that any additional current thru R2 is going to be related to the difference in voltage between Vb and Vc, essentially the diode drop from base to emitter. Typically we'd push a much smaller current through the base by using an appropriate resistor so that we can drive a large load from some no so tough part, such as a microcontroller. So by using identical resistors on the base and collector, we don't really see much advantage. But we do with the LED's.....