Engineer, Hacker, Tinkerer, Geek

Tag Archives: code

A couple weeks before Christmas, my family received a package from me containing this odd looking box, which began life as a simple jewelry box:

I included a USB cable with it, along with very basic instructions to “recharge the box as needed”. I didn’t provide any clues as to what they were supposed to DO with the box or what might happen if they pressed the big silver button on the lid.

So what was it? A Reverse Geocache box of course. The first such box that I’m aware of was built by Mikal Hart, and his work has inspired others to create a number of differentvariations.

I decided this type of puzzle would make a great Christmas present, and set out to build two of them (one for my family and one for my in-laws). For my own effort, I wanted to improve on the original concept in one key way, and that was to make it re-usable by anyone, including those that know nothing about electronics or programming. A secondary goal to was to keep the electronics nice and compact so that there would be room in the box for interesting contents (aside from the electronics, which are mostly uninteresting to my family members). To accomplish my goals, an Arduino wasn’t going to cut it — instead I designed a custom PCB that stacks directly below the LCD module that I chose for the project.

Here’s the PCB layout and an actual assembly during the test phase. You can see the 3″ x 1.85″ controller board mounted on the back of the LCD with some 1/4″ standoffs. A standard 0.1″ header connects the LCD to the control board to keep the wiring simple.

Here you can see the control board, GPS, servo, and Red/Green illuminated momentary switch mounted on the underside of the lid. A handful of small wood blocks were used along with some #6 wood screws. Power comes from a 2000 mAh lithium polymer battery, and is charged by the MAX1811. I opted not to cover the electronics because I wanted to show off my work. Hopefully nobody tries to put anything conductive in the box without wrapping it up first!

The locking mechanism is actuated by the servo. A brass hook rotates down around a pin held in place by two small brass plates. This part was a bit tricky to fashion, but in the end all I needed was just a drill, hacksaw, and a small file.

The target location and the maximum number of attempts are stored on the micro SD card, along with a csv file containing a timestamp and the location of each open attempt. To reprogram the box, you can either edit the lat/long files from your computer, or simply take the box to the desired location and select “Set new location” from the menu. Once configured, the box re-starts and the puzzle begins. Here’s what it looks like after a re-start:

Once the user presses the button, they see “Searching for signal” and a steadily moving progress bar. If a valid GPS fix is obtained, they get the distance to the target and then either “Access Denied” or “Access Granted”. In addition, the button blinks red or green. If the box is not at the target, it displays the number of attempts as well. After 30 seconds, they see “going to sleep…” and a short countdown, after which the display and the button turn off and the microcontroller goes into sleep mode to await the next button press.

Of course, with a locked box like this you’ll need a way to get it open in an emergency. I built in a backdoor, but I’m not telling the secret!

Once either the puzzle is solved or the backdoor is used to open the box, additional button presses bring up a menu. Options are to lock/unlock the box, get the battery status (displays the voltage), get the current GPS lat/long, set the new target location, and re-start the puzzle. Options are selected by holding the button down for 3 seconds. Here’s a few examples:

Rather than completely powering down between uses, the microcontroller turns off all the peripherals and then goes into sleep mode. I initially thought it would be nice to take periodic GPS fixes (with the screen off) so that it could have a very fast warm start when the user pressed the button, but I ended up not implementing that feature. Even though it’s powered on all the time (albeit mostly sleeping), battery life is acceptable. It should last a few weeks in standby, and will easily stay alive long enough for 50 tries or more. The microcontroller measures the battery voltage after each button press, and if the battery gets low, the user is prompted to re-charge, which is simple thanks to the mini USB port located on the back of the box under a protective cap:

Thanks to the California Energy Commission we can see what a real inverter efficiency curve looks like, and compare it to the pvwatts model.

It turns out that the pvwatts model doesn’t match reality very well. The pvwatts nominal efficiency of 92% is well below the average of current inverters, and the 4th order polynomial is a rather poor fit to the shape of the efficiency curve.

The plot below shows the measured efficiency curve for a SatCon PVS-135 (green) and the pvwatts model (blue). Clearly there’s quite a bit of room improvement.

I’ve created a log function to model the inverter and plotted that in red. Substituting the improved model in pvwatts calculations results in about a 4.5% increase in annual energy.

Even if you don’t know what inverter will be used in a particular case, just increasing the nominal efficiency inside pvwatts from 92% to something around 95% seems reasonable given the test data on the CEC site.

Just about everyone in the solar energy world is familiar with pvwatts, but how many of them have actually had a chance to examine the source code? I’m just digging into it now, and I’ve already found several areas that could use some improvement. Considering how widely accepted this calculator is, the code is quite a shock. The algorithms make sense, but the implementation is a bit frightening.