The Doom Box: Part I

I’ve long had a fascination for renewable energy – be it from wind, solar, or hydro-electric sources. Perhaps it’s just my penchant for penny-pinching, but the idea of free and (virtually) unlimited energy is something I find quite appealing. So, in February of 2009 (wow, has it been that long?) I bought my first SUN 90W, 18VDC photovoltaic (PV) panel:

Solar Panel (with voltmeter)

(As a side note, if that looks like a stock image, that’s because it is. However, it really is a picture of my very own panel and voltmeter. Stock photography is another hobby of mine which I may post on later.)

So, what did I have in mind for this 90W powerhouse? A reverse-UPS of course! What is a UPS, you ask? Well first off, UPS stands for uninterruptible power supply. You typically find these connected to computers, particularly server computers. Their purpose is to continue supplying power in the event of an outage. Essentially they’re fancy battery backup systems that can be switched on almost instantly in the event of a main power failure. Actually, some UPS systems run their inverters continuously and only rely on the mains input to keep their internal batteries charged.

Now most uninterruptible power supplies power their loads via a connection to the mains (120VAC) until an outage occurs. At this point the load is switched over to battery power. My plan for a reverse-UPS was just the opposite. I intended to power loads via solar and battery power until the battery reached a certain level of discharge (~70% of full charge so as to extend the life of my battery), then automatically switch over to mains power.

To accomplish this, I first bought a 63Ah deep-cycle lead acid battery and a SunSaver 15A MPPT charge controller from the Alternative Energy Store. While the MPPT feature on the charge controller did cost me a bit more, I think it’s a big plus, particularly for cloudy winter weather. So far I’ve been very impressed with the SunSaver’s performance:

SunSaver 15A MPPTThe next step was to obtain an AC inverter. I considered making one myself (as well as the charge controller), but opted to go COTS for convenience and safety. I may have it backwards, but I generally feel more comfortable using professionally-made devices when it comes to dealing with high voltage and current. (But of course I also fused just about every wire in the system – a very good choice, as you’ll see later.) I also wanted a pure sine-wave inverter for efficiency and smooth SSR switching (discussed later).

So with my battery-backed solar-powered AC source, all I needed was a means of switching between that and line AC. Paralell solid-state relays (SSRs) seemed to be the best solution because of their speed and easy of use. All I needed was an accurate and reliable way of controlling them. For that, I chose a simple 8-bit AVR microcontroller, the ATMega48. This is a great little MCU that can handle plenty of digital I/O and up to eight analog inputs. One of those inputs was wired up to monitor the battery. Several digital inputs went to switches and buttons, and two digital outputs went to the SSRs.

Switching from line AC to inverter AC was actually quite simple. Once you remove the digital “ON” signal from the SSR, it takes at most half an AC cycle to turn off (this is because its current must reach zero before turn-off occurs; see TRIAC). So, for a 60Hz AC source (standard here in the US), that means 8.3ms. To be safe, I went ahead and doubled that figure. So, to switch between relays, the MCU only needs to turn one off, wait about 16ms, then turn another on. Of course, the consequences of getting that timing wrong could be painful, so I was sure to thoroughly stress-test my code and electronics before running a powered test. So far, no fuses have been blown by crossed sources.

Here are a few images of the original completed system (before any revisions):

Doom Box (1)

Doom Box (2)

Yes, it’s made of wood. Pine, if I recall correctly. And yes, wood is flammable. I don’t plan on taking advantage of that fact. The cooling fan is there to keep everything well below flash point. It’s also intended to vent any hydrogen gas that may be given off by the lead-acid battery. Wood does have one plus though: it’s non-conductive.

Below is a close-up of the front panel, where all the user interaction happens. The large switch on the top left connects the solar panel to the charger. The bottom left connects the battery to the rest of the system (inverter, microcontroller, etc.). The left black button allows the user to force the battery to operate even if it’s below 70% of full charge. The right button allows the user to manually command line AC output if desired.

Doom Box (3)

Here are a couple shots with the lid removed. The system measures about 16″ x 12″ x 14″ and, with battery in place, weighs about 40lbs. I don’t remember exactly why we started calling it the “Doom Box” – perhaps it just sounded amusing. I suppose it is a potentially dangerous box to go sticking your hands in…

Doom Box (4)

Doom Box (5)I’m happy to report that the doom box worked quite well for a number of months. I strapped my 90W solar panel to a lawn chair, weighed that down with a cheap sack of marble chips, and put the whole thing out on my east-facing balcony. The AC output was connected up to an old laptop I run as a server. It draws about 35W continuously. So whenever the sun was out and the battery fresh, the laptop was powered entirely by the doom box. Once the sun moved out of view and the battery discharged to 70%, the box automatically switched the laptop over to line AC.

Unfortunately, given its location, the solar panel only saw direct sunlight for a few hours each morning, but that’s the best I could do at the time. As such the laptop was only off the grid for about 6-8 hours each day. I was also quite surprised at the difference in performance between direct sunlight and cloudy days. Very cloudy days cut down my power input by about 80-90%.

Well since this initial build I’ve modified the MCU to support a greater level of monitoring. Current sensors are now in place and the entire system is programmed to log and report its status via website. I’ve also added a second solar panel and battery. But that’s another post for another time. Stick around for dramatic stories of inverter failure!

Part II of this article may be found here!

Measuring Projectile Velocity

(Updated 9/6/2010 – scroll down for final results)

I’ve got a couple friends who enjoy building spud guns and other sorts of “just for fun” air rifles. They’re pretty nifty to shoot, especially since ammo is flexible. Even a wad of paper towels wrapped in tape will do the trick. All you need is something that forms a relatively good seal with the inside of the barrel.

So being the EE that I am, this got me to thinking: wouldn’t this be even more fun if we could measure muzzle velocity? It shouldn’t be all that hard; we could just hook up a couple LEDs and photo-detectors, fire through the beams, time it with a microcontroller, and voilà! So, that’s precisely what I did, except that I decided to go with a couple cheap laser diodes instead of LEDs. Here’s the end-product in all its wooden glory:

The Box

Top View

In the first image you can see one of the two laser diodes poking through the right side of the wooden enclosure (and held precisely in place by hot glue). The two lasers are aimed at PIN-type photodiodes which are mounted on the other side of the box, spaced 2″ apart, and covered with IR-blocking film (to prevent difficulties with ambient light):

Photodiodes Plus IR-Blocking Film

The two photodiodes are wired in reverse-bias as shown in the following schematic:

Sensor Schematic

Now if you’re unfamiliar with photodiodes, you can essentially think of them as light-dependent resistors. (Although to be precise, they should really be modeled using a light-dependent current source as discussed here.) In total darkness, they’ll exhibit very high resistance when reverse-biased. However, expose them to light, particularly infrared light (at least in this case), and their resistance drops substantially. Thus, whenever the laser beam is striking a photodiode, its resistance is quite low. When this happens to D1 in the schematic above, the voltage at point A rises closer to the 5V supply. However, if the beam is broken, the photodiode’s resistance rises, causing the voltage at point A to drop towards 0V (GND).

We can use this change in voltage to determine when the laser is being blocked by a projectile. This is done using a high-speed operational amplifier (op-amp) wired as a comparator. The potentiometer (POT) shown in the schematic above is tuned so that its output voltage is just between the “blocked” and “unblocked” voltages of the photodiodes. The outputs from the op-amp then saturate at 5V whenever the lasers are unblocked. However, if the lasers are blocked, the op-amps will output approximately 0V. This change from 5V to 0V then represents the entry of a projectile and is detected by an AVR microcontroller, the ATMega128. It’s part of a development board I’ve had for several years now, the Olimex AVR-MT-128 (details here). The development board really isn’t important at all – it simply provides screw terminals for easy connection to the AVR’s I/O.

So once the microcontroller powers up and initializes its LCD display, it sits and waits for its two inputs to change state. If the leading photodiode goes low (0V), an interrupt is triggered that starts an internal counter. The counter runs until the trailing photodiode goes low, at which point the counter is stopped, the projectile’s velocity is calculated based on the known separation between photodiodes, and the LCD display is updated like so:

Display Closeup

The “mode” you see displayed above indicates the speed of the MCU’s internal 16-bit counter. If a slow-moving projectile (less than ~150ft/s) is expected, you can use the pushbuttons to specify slow mode, which causes the internal timer to count at a much lower frequency. This allows slow-moving projectiles to be measured without counter overflow. However, if you’re firing high-speed projectiles, you’ll want to use fast mode. This will kick up the counter’s frequency to 16Mhz to provide better speed resolution.

My initial testing was performed by shooting rubber-bands through the lasers. It turns out they fly at between 40 and 80 ft/s depending on how much you initially stretch them. I also tested out the timing accuracy of the system by using an arbitrary waveform generator in place of the photodiodes. Results looked very good: fast mode accuracy should be less than 0.1% at speeds of about 1000 ft/s. Max speed is limited to 10,000ft/s.

Code for the ATMega128 can be downloaded here: fps_meter_code.zip.

Finally, the following is a fairly complete bill of materials in case you want to try this out:

  • PIN photodiodes: BPW34
  • Operational Amplifier: EL5444
  • 5V switching regulator (to power development board): V7805-500
  • Linear 3.3V regulator (to power lasers): UA78M33C
  • 1k resistors (in series with photodiodes)
  • 10k potentiometer (to set the photodiode “trigger” threshold)
  • Laser diode modules (pulled from two cheap laser pointers)
  • AVR development board: AVR-MT-128 (but really, a single ATMega will do)
  • IR-blocking film: Wowfil samples
  • Some scrap wood and screws

Update (8/29/2010): I have now tested the meter successfully with two different air rifles – a .20 and a .22 caliber pellet gun. The .22 was tested first and proved rather anemic. Initially it couldn’t even break through the cardboard box we were using to catch the pellets. With a few extra pumps its rounds reached 140ft/s, but that’s still rather slow. The rifle seems to have difficulty holding pressure. We had better luck with the 0.20 cal – its pellets reached a top speed of 590ft/s – this was enough to penetrate two layers of cardboard and nearly the full thickness of a piece of 1×6 pine wood. I should also note that using such small rounds made it slightly difficult to trip the laser sensors. However, once we had the rifle lined up properly and leveled, everything worked great!

Update the Second (9/6/2010): This afternoon I took the meter out to my uncles’ shooting range for a bit of live-fire testing. The first thing I learned is that the device I’ve made is called a chronograph and that apparently you can buy these for not much money. No doubt the store-bought varieties provide many additional features and are easier to use; but where’s the fun in that?

Well, we started out “testing” with a .45 ACP using standard Remington FMJ rounds (230 Grain). The chronograph was setup about eight feet in front of the table from which we were firing. I had considered firing at point-blank range, and while this would have been much easier, the smoke and flames from the barrel may have presented a problem for my electronics (i.e. inaccuracies, melted plastic, etc). Of course, the long-distance alternative could have led to my blasting my poor development board into oblivion. Thankfully, I’m a better shot than that; although just barely. To perform the test, I pinned a little black target to the back of the device, then aimed for the center of the dot. After a few tries, the round passed through both beams and registered about 850 ft/s – pretty much what you would expect for this type of ammunition (see this Wikipedia entry on the .45 ACP).

Range Test: .45 ACP SetupNext up, we tried out some Magtech Auto+P rounds – 185 Grain, JHP. As promised, these provided substantially more power. You could certainly hear and feel the difference. That is, when they would fire – a number of them were just a bit too long to fit completely in the chamber. I’m not sure whether this was a defect or if they were just too big for this particular gun. But anyway, a couple different shots both registered about 1150 ft/s:

Range Test: .45 ACP ReadoutSo after all of this testing, I’m thinking about making a couple of changes to the system. For one thing, having to adjust the threshold potentiometer for changing lighting conditions is a little frustrating. The IR-blocking film just isn’t quite cutting it, although I’m sure it helps. But I’d like to try using the AVR to dynamically generate one or two analog outputs for use as thresholds. I’ve actually done something very similar in the past with the same photodiodes. I simply programmed the AVR to ramp up its output voltage until the comparator switched state. Then it automatically reduced the output voltage a little to give some room for noise. This varying analog output, by the way, was created by adjusting the duty cycle of a low-pass filtered PWM output. Setting the filter’s cutoff frequency to less than 1/100th of the PWM frequency nicely converts a square wave into a DC value (and the lower the cutoff frequency, the smoother your final output will be).

To compensate for changing lighting conditions, I might also try connecting the two photodiodes directly to the analog inputs of the ATMega128. I’d still use the external comparator for timing measurements, but this would allow me to directly determine the best analog threshold to be generated by the AVR without the need for scanning. I could also add transistors to the lasers so that the AVR could turn them off briefly for calibration. I might also just high-pass filter the photodiode output to completely eliminate any shifting DC offset. I’ve tried this before on a similar project with good success.

The other thing I’d like to do is make the sensing area a little wider. It’s pretty tough to reliably hit two 1/8″ laser beams. Perhaps a couple of line lasers and photodiode arrays would do the trick. Or maybe there’s a better non-optical sensing option out there I haven’t heard of yet…?

DreamSpark Plug

Microsoft DreamSparkWhat do you think about when you think of Microsoft? An evil corporate giant? Frustrating software? Viruses and worms? Or perhaps you’re actually a fan of M$?

Well regardless of your opinion, if you’re a student in high school or college, Microsoft wants to give you some of their software – free. Indeed, full versions of Windows Server 2008 R2, Visual Studio 2010 Professional, and more, are free to download with no strings attached. The program is called DreamSpark, and was announced over two years ago by Bill Gates himself during a speech at Stanford University. Somehow I didn’t catch word of this until just a few months ago when I started to look into building a new server.

So why am I mentioning this? Well, to be honest, I am a bit of a Microsoft fan. I’ve been using their operating systems and software ever since the arrival of the 486. But I’ve also now taken advantage of the DreamSpark program to download and install Windows Server 2008 R2 Standard (an OS that would normally set you back more than $500). In fact, it’s now hosting this blog (and playing a few other roles as well).

In the future I’ll probably comment on my experience with Windows Server, but for now I’ll just say the setup was pretty painless. I’ve toyed with Linux servers in the past, and configuring 2008 was, by comparison, approximately one million times easier. So, thank you Microsoft! (And please, Linux users, be nice to my new server. K? Thx!)

Fun with FLIR

A little while back I posted about testing a Nichrome heater using a FLIR thermal camera. While I had the opportunity, I snapped a couple other pictures. First off, my laptop, a Lenovo Thinkpad T61p. As you may have guessed, the top image of the following composite was taken with the FLIR camera. The orange areas indicate high temperatures while the blue areas indicate lower temperatures.

Lenovo T61p Thermal Image

While it may look like flames are shooting out the left side of the laptop, that’s actually just the desk being heated by the CPU fan. And I’m sure you can guess where the processor is located – just under the caps lock. On the lower right part of the hand rest, you can also see the outline of my three fingers in blue. But those aren’t my fingers – what you’re seeing is merely a thermal “shadow” left by a brief touch that slightly cooled the plastic.

You’ll also notice that the screen is warmest right along the bottom edge. I’m guessing that’s where the back-light is located. And in case you’re wondering, the highest temperature in this image is approximately 95F.

Soldering Iron Thermal Image

This second and final image is, you guessed it, a soldering iron. And as you can see, the hottest part of this particular iron (indicated by white) isn’t the tip, but just above the tip. I also noticed that the iron’s temperature controller wasn’t all that accurate. The hottest point in this image is just over 600C, while the iron’s controller claimed 800C. Perhaps I hadn’t given it time to ready a steady-state temperature distribution?

LabVIEW: Managing Interactive SubVIs

I do a lot of LabVIEW programming. Quite a lot, in fact. Fortunately, I rather enjoy a good block diagram. Plus, the ability to work with virtual instruments (VIs) for control and data acquisition seems highly prized at RPI. Either that, or nobody else wants to do it.

When building programs with LabVIEW, I often find it convenient to group code into subVIs. This can really help clean up a messy block diagram. Occasionally I’ll employ a subVI for user interaction of some type – a sophisticated dialog box, or perhaps a sub-application of sorts. But just how is this done? By default, a when you drag a subVI onto your block diagram, its front panel won’t show when executed. To force the front panel to display when called, first right-click on your subVI, then select “SubVI Node Setup.” Then simply check the following:

SubVI Node Setup

If checked, the option to “Close afterwards if originally closed” will close your subVI once it’s finished executing, if it started closed. This is typically my preference, but there may be a time when you want your subVI to stay open after it stops.

Of course, there are a few other tricks you may wish to employ. Perhaps you’d like your application to be reset its subVI’s values to defaults. Or maybe you’d like to run the subVI, but only display its front panel when certain conditions are true. All this and more is possible with the “Static VI Reference” block, found under “Programming” → “Application Control” and shown here:

Static VI Reference

Place this block on your diagram. Now drag your subVI onto the “Static VI Reference” block you’ve just created. You’ll notice it takes on the same icon as your subVI. From here there are a world of possibilities. To see what I mean, move your cursor over the reference output of this block (as if you were wiring it) and right-click. Next, select “Create” and then “Method for VI Class.”

VI Methods

From here, you can choose to run the subVI, show or hide its front panel, reset its values to default and more. If you back up a step on this menu tree and select “Property for VI Class,” you can further alter the appearance of the subVI window, including hiding buttons (abort, run, etc.) from the toolbar and changing the window title.

Hopefully you’ve found these tricks helpful! I’ll try to post more from time to time.