Tag Archives: softare

Reverse Geocache Boxes


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:

What is this thing???

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 different variations.

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.


Locking mechanism


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:





One more photo for scale:



Here’s a quick video showing an attempt to open the box:


PCB and Schematic:

schematic png image
pcb png image
eagle schematic
eagle pcb
Bill Of Materials


Source code (I use avr-gcc on Ubuntu):

C sources



Wireless IV Curve Tracer for long term field testing

Wireless IV Curve Tracer

Wireless IV Curve Tracer
Wireless IV tracer

The Problem

At work, we have a long term test facility with dozens of PV modules of various makes and models that are wired up to instrumentation that records IV curves once per minute, all day every day. The hardware for this testing does a great job in terms of accuracy and resolution, but has some shortcomings: it’s expensive (~$20K minimum), and requires a lot of wiring which means it isn’t very flexible. If I want to set up a new panel, or move an existing panel to a new location, I usually have to run new wiring for the PV module, a relay bank, and the DAQ hardware.

The hardware below was designed and built as a personal project in an attempt to address the shortcomings of a traditional IV measurement setup. The hardware and software are open source. If you find what I’ve done useful, I’d love to hear about it!

My Solution

The IV tracer pictured above (my working prototype) has just two wires to connect to the panel under test. Other than that, it’s completely self-contained and portable. When the panel isn’t being measured, the logic circuitry is put to sleep and the panel’s power is instead used to charge a small lithium ion battery. Even in complete darkness, the IV tracer can run from the battery for a couple of weeks, and as soon as the sun comes out, the battery is quickly recharged.

The IV data is transmitted as ASCII text using an Xbee in transparent serial mode. On the receiving end, a simple USB-Serial adapter is connected to a linux PC and a very basic logging script.

The complete IV tracer cost me about $140 to build, which is a huge cost savings in addition to the time saved from not having to mess with miles of wiring.

The Hardware

The hardware consists of two parts:

1) A “Power Module” that charges a small Lithium Ion battery and provides a regulated 3.3V power source. It also includes an onboard relay that allows it to be disconnected from the panel during IV measurements.

2) A “Logic Module” that performs the IV measurements and handles wireless data transmission.

Each module fits on a 1.97″x3.4″ PCB, and standard screw terminals provide for wire connections between the two PCB’s. The PCB’s and battery are mounted on a small section of DIN rail in a NEMA 4X enclosure, with short male/female MC connector pigtails for connection to the panel under test. The entire assembly measures just 7.1″x5.1″x3″ and weighs about one pound.

To measure an IV curve, relay K1 (see schematics below) is activated, switching the power module out of the circuit. Capacitors C1 and C2 provide a load to the panel, and voltage and current are first buffered by the MCP604 opamp and fed into the MCP3202 two channel SPI ADC. With the Atmega644p clocked at 7.37 MHz, and the SPI clock running at FOSC/8, it takes about 100 microseconds to capture each IV point (50 us for V, 50 us for I). In practice, the panel’s current varies with irradiance, and hence the IV curve acquisition time varies as well. Under full sun, it takes about 150 milliseconds to capture a 150 point IV curve. With the panel completely shaded, it can take about 4 seconds. A very simple software algorithm is used to determine which samples to store and when the IV curve is complete.

Once the IV curve completes, the Xbee is woken up, and the data is transmitted as comma-separated text, along with a unique ID number. The ID for each IV tracer is set via a 6 position dip switch on the logic module.

The Xbee coordinator can handle a maximum of 10 sleeping end devices, which means for a large test setup of 40-50 IV tracers, the PC on the receiving end will need a USB hub with 4-5 Xbee USB/serial adapters. Some simple text parsing can then pull out the IV data and present it in whatever format is required. I use a perl script to strip the ID numbers and sort the IV curves into separate directories for each test module.

The Software

The software is written in C and compiled with avr-gcc on linux. I used an Atmega644P, but other AVR micros would probably work with minor modifications.

In addition to the IV datapoints, the microcontroller also measures battery voltage and keeps a rolling window of Isc measurements. Since Isc is a good proxy for irradiance, I’m using this measurement to increase the time between IV measurements during periods of darkness. Since the Xbee coordinator expects all the endpoints to “check in” periodically, we can’t just sleep all night long, but this at least provides a basic way to conserve battery.

So… does it work?

Yes! Below are some sample IV curves. This is a plot of the raw data from the device, and you’ll notice that it doesn’t truly measure short circuit current. When the relay contacts close, it takes about 5-10ms for the current into the capacitors to reach a peak value due to inductance. In practice, this isn’t all that important, because we can simply extrapolate back to Isc. In fact, I have to do the same thing even when measuring IV curves with $5K electronic loads.

Sample IV curves

Sample IV curves

Downloads and links

Note: the design of this IV tracer is licensed under a Creative Commons license Attribution-NonCommercial-ShareAlike 3.0 Unported

PCB files (these will work with the free version of Eagle):
NOTE: These are my revised boards based on the first prototypes, and I haven’t had a chance to test them yet. I’ll update this page once I verify these designs.

Logic Module schematic
Logic Module PCB
Power Module schematic
Power Module PCB

Logic Module Schematic
Logic Module PCB
Power Module Schematic
Power Module PCB

C source code

Either the 1000 mAh battery from Sparkfun
or the 900 mAh

NEMA 4X enclosure from McMaster-Carr