Midi Footswitch for DJ Mykey

Midi Footswitch Controller For DJ Mykey‘s Rane TTM57mk2 Mixer

This was a quick project to build and it’ll be fun to see what DJ Mykey can do with it.

Rane manual excerpt

Rane manual excerpt

Ripping a piece of maple

Ripping a piece of maple

Painting the base with truck bed liner

Painting the base with truck bed liner

Attaching switches to base

Attaching switches to base

Soldering TRS connectors

Soldering TRS connectors

Completed TRS cable

Completed TRS cable

Wiring inside the enclosure. There is a terminal block for each footswitch and a panel mount TRS jack for connection to a mixer.

Wiring inside the enclosure.
There is a terminal block for each footswitch and a panel mount TRS jack for connection to a mixer.

Completed MIDI footswitch controller

Completed MIDI footswitch controller

Completed MIDI footswitch controller

Completed MIDI footswitch controller

DJ Mykey

DJ Mykey

Wink Hub – Rooting via JTAG – Part II

In my last post I detailed the method I used to find the JTAG pinout.

This time, I’ll show how I configured openocd, loaded a custom u-boot via JTAG, and rooted the hub.

Step 1 – Setting Up OpenODC

The version of openocd in the Ubuntu Trusty repo is 0.7 and I wanted to use the latest (currently 0.10), so I compiled it from source. The process is fairly painless if you have all the prerequisites installed:

$ git clone git://git.code.sf.net/p/openocd/code openocd-code
$ ./bootstrap
$ ./configure --enable-buspirate --enable-ftdi
$ make -j4
$ sudo make install

On my first attempt to connect to the hub I got an “memory write caused data abort”, but a quick search led me to a helpful post with a solution. Click here to download my config file for the Wink hub that incorporates the fixes to the startup script.

You can also download my config the Olimex ARM-USB-OCD.

once openocd is built and your config files are in place you can start it with:

openocd -f olimex-arm-usb-ocd.cfg -f imx28evk.cfg

Step 2 – Loading A Custom U-Boot

The goal here is to build a custom version of u-boot, load it to RAM and execute it in place of the factory bootloader. This makes it easy to root the hub without risking damage to the hardware or filesystem corruption like some folks over at the XDA Developers forum have reported.

If you connect a 3.3V serial adapter to the UART on the hub you will see :

U-Boot 2014.01-14400-gda781c6-dirty (Apr 30 2014 - 22:35:38)

And this gives you an idea of where to start. To build the custom u-boot:

$ git clone git://git.denx.de/u-boot.git
$ cd u-boot
$ git checkout v2014.01 -b tmp
$ export ARCH=arm
$ export CROSS_COMPILE=/usr/bin/arm-linux-gnueabi-
$ make mx28evk_nand_config
$ wget http://jalderman.org/wink-files/wink-hub.patch
$ patch -p1 < wink-hub.patch
$ make -j4

My patch sets up the environment to (mostly) match the Wink u-boot, but sets init=/bin/sh and enables the “Hit any key to stop autoboot” function. As an aside, I searched for the Wink u-boot sources and wasn’t able to find them. This seems to be a GPL license violation.

Assuming u-boot compiles successfully, you need to know where to load it into memory using openocd:

$ grep __image_copy_start u-boot.map
                0x0000000040000100                __image_copy_start

Now start openocd in one terminal:

$ sudo openocd -f olimex-arm-usb-ocd.cfg -f imx28evk.cfg

And connect via telnet in another:

$ telnet localhost 4444
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger

Now reset and halt the CPU and load our custom bootloader into memory. NOTE: I’ve observed that the halt command doesn’t always work. Sometimes it’ll take multiple reset/halt commands to get the CPU actually halted and in a state where we can write to RAM. Watch the serial terminal output and it’ll be obvious when the CPU is properly halted.

> reset
> halt
> cd u-boot
> load_image u-boot.bin 0x40000100
downloaded 455212 bytes in 12.666913s (35.095 KiB/s)
> resume 0x40000100

If the above is successful, you’ll see a new u-boot prompt in your serial terminal window:

U-Boot 2014.01-dirty (Aug 24 2015 - 18:24:43)

CPU:   Freescale i.MX28 rev1.2 at 454 MHz
DRAM:  64 MiB
NAND:  128 MiB
*** Warning - bad CRC, using default environment

Video: MXSFB: 'videomode' variable not set!
In:    serial
Out:   serial
Err:   serial
Net:   FEC0 [PRIME], FEC1
Warning: FEC1 using MAC address from net device

Hit any key to stop autoboot:  0 

You can interrupt u-boot now, but if you simply let it run it’ll boot with init=/bin/sh which will allow you to remove the root password.

Step 4 – Getting Root

Delete the root password, add a getty to the serial port, and enable ssh. For detailed instructions, go here.

In summary:

/ # passwd -d root
/ # echo 'ttyAM0::respawn:/sbin/getty -L  ttyAM0 115200 vt100' >> /etc/inittab
/ # mount -a
/ # ubiattach -p /dev/mtd3
/ # mount -t ubifs ubi1:database /database
/ # echo '1' > /database/ENABLE_SSH

You’ll also want to add your public key to /root/.ssh/authorized_keys so that you can log in via ssh.

Next up: dumping a NAND image via JTAG.

Wink Hub – Rooting via JTAG

The Wink Hub is a really impressive embedded linux system. For $50 you get a device that can handle 6 different wireless protocols: Wifi, Bluetooth, Z-Wave, ZigBee, Kidde, Lutron.

The hub was initially rooted by a simple SQL injection attack. Once that was patched by a software update users then resorted to a brute-force nand-glitch method to interrupt u-boot. While this certainly works, a close look at the bare PCB reveals a safer and even more powerful way to gain unrestricted access to the system: JTAG

Wink Hub JTAG and UART connectors

Wink Hub JTAG and UART connectors

While the UART header has been helpfully labeled (dear Wink, not a good idea!), the JTAG pinout is not only unlabeled, it’s non-standard. Here’s how I reverse engineered the connector pinout. If you just want the pinout, feel free to skip to the image at the very bottom of this post.

First, I needed to remove the RF shield over the CPU. This pries off easily with a screwdriver. Next, I used an SLR camera on a tripod to take high resolution photos of the front and back of the PCB. These were then imported into the GIMP where I flipped the bottom PCB layer, set the top layer to 50% transparent, and aligned the two layers.

PCB layer photos imported into GIMP

PCB layer photos imported into GIMP

Next I grabbed an image of the CPU ball map from the datasheet and imported that as another layer, resizing it to match the physical outline of the CPU.

GIMP screenshot with cpu ball map added

GIMP screenshot with cpu ball map added

This allowed me to examine the bottom layer at the highest possible zoom, looking for vias in the area of the CPU JTAG balls. In the image below you can see where I scraped the solder mask from these vias to make them stand out better.

Bottom of board with vias exposed.

Bottom of board with vias exposed.

Now I was able to use a multimeter to find connections between these vias and the pins of the JTAG header. Here’s what I found:

JTAG pins overlayed on vias

JTAG pins overlayed on vias

Finally, a bit of educated guessing and some luck shows you which header pin maps to which JTAG signal:

JTAG connections

JTAG connections

I connected my Olimex ARM-USB-OCD and got a successful connection on the first try!

openocd connecting the the i.mx28 cpu

openocd connecting the the i.mx28 cpu

The connections are as follows:
Pin – Signal
1 – Vref
2 – N/C
3 – TDI
4 – TMS
5 – TCK
6 – TRST
7 – TDO
8 – SRST
9 – N/C
10 – GND

Diagram showing the JTAG pin header:

Wink hub JTAG pinout

Wink hub JTAG pinout

Next up: loading a custom u-boot and getting root! Click here for Part II.

1,000,000 digits of pi

Here are the first 1,000,000 digits of pi converted to rgb pixels. A mathematician will tell you that because pi is an infinite number, it cannot be proven to be “random” (really normal base 10). An engineer will look at this image and say “yup, that’s random”!

I created this with a short perl script and used imagemagick to convert raw rgb data to a png image.
My source code is available here: https://bitbucket.org/jalderman9/pi-in-rgb-color/src” title=”pi-in-rgb-color

pi rgb

Project Euler is awesome

I’ve found that Project Euler is a great way to keep my programming skills sharp and work on interesting problems that are a bit different that what I normally see from day to day.

Case in point:
Until today I’d never heard of an optical delay line or even considered why you might want one. Now I’ve written code that calculates the number of reflections of a laser inside an elliptical cavity. Cool!

Not only did I solve the problem, I opted for a bit of extra credit and decided to plot the light path as it bounces around inside the ellipse and eventually escapes back through the aperture at the top:

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



Another win for my palmarès!

Last weekend I raced the Death Valley Road Stage Race. The race took place on Saturday and Sunday, and both stages were BRUTALLY hard. Because of the high altitude (about 10,000 ft) I was literally seeing stars for the last 30 minutes or so of each race. I guess my body was performing a bit of a balancing act there, splitting oxygen between my brain and my legs!

The official results haven’t yet been posted, but I got 1st on stage 1, 2nd on stage 2, and 1st on GC.

Stage 1: 45 miles, 8200′ of climbing
Stage 2: 29.5 miles, 6500′ of climbing

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

Optimizing for Time of Use – Trackers vs Fixed Tilt

Most power companies have a tiered rate structure for electricity that makes energy generated during peak demand hours more valuable. In the northern hemisphere, you almost always get the maximum annual energy generation for a PV system by orienting the system due south (unless you have strange weather patterns, like cloudy mornings and sunny afternoons but that’s not typical). But if energy generated in the late afternoon/early evening (typical peak time) is worth significantly more the the power company, you can easily get a net benefit from altering the system azimuth to capture more energy during a specific time of day even though the result is a lower annual energy yield. You’re essentially trading annual energy for energy captured at a specific time of day.

With this in mind, I recently ran a performance analysis using actual time of use data for a large scale project, and the results were somewhat surprising.

First, the plots of annual energy vs. system azimuth (180 degrees is due south) for horizontal single axis trackers and fixed tilt PV systems:

Fraction of annual energy delivered versus system azimuth angle for single axis tracker and fixed tilt PV systems.

Fraction of annual energy delivered versus system azimuth angle for single axis tracker and fixed tilt PV systems.

Both systems deliver their respective maximum annual energy when the system azimuth is 180 degrees, but the overall effect of the azimuth rotation is quite small, even for large rotations of 20 degrees or so. There’s also some skew to the data due to the weather at the particular location I’m using. I should also point out that the single axis tracking system produces about 18% more energy at this location.

If we take the Time of Use factor (a value ranging from 0.6 to 2.5 depending on season and time of day) and multiply it by the hourly system output for each hour over the course of a year, we get some interesting results:

Annual Energy scaled by the Time of Use factor versus system azimuth angle.

Annual Energy scaled by the Time of Use factor versus system azimuth angle.

First, the fixed tilt system will deliver its greatest number of dollars per year when installed with an azimuth of 200 degrees (20 degrees West of South). Second, the single axis tracking system benefits very little from an azimuth rotation, and what little benefit there is occurs in the opposite direction (East of South). This is because the tracking system’s panels are already pointed to the West in the late afternoon, in a great position to capture sunlight during the period of peak demand. It’s a little counterintuitive, but rotating the tracker axis (the North-South axis) away from the sun actually points the panels more directly at the afternoon sun.

So to summarize, the tracking system produces 18% more annual energy, and doesn’t need any site-specific optimization of the install to maximize the benefit based on the Time of Use factors.