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.
This was a quick project to build and it’ll be fun to see what DJ Mykey can do with it.
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.
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
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 *(.__image_copy_start) .__image_copy_start 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 Trying 127.0.0.1... 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 BOOT: NAND, 3V3 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.
Delete the root password, add a getty to the serial port, and enable ssh. For detailed instructions, go here.
/ # 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.
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
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.
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.
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.
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:
Finally, a bit of educated guessing and some luck shows you which header pin maps to which JTAG signal:
I connected my Olimex ARM-USB-OCD and got a successful connection on the first try!
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:
Next up: loading a custom u-boot and getting root! Click here for Part II.
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
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:
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.
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:
One more photo for scale:
Here’s a quick video showing an attempt to open the box:
PCB and Schematic:
Source code (I use avr-gcc on Ubuntu):
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!
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 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 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 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.
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.
C source code
NEMA 4X enclosure from McMaster-Carr
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:
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:
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.
The web version of PVWatts doesn’t take into account the effect of one row of panels/trackers casting a shadow on another, and neither does it account for backtracking in the morning and evening to avoid shading. Essentially, you are modeling the performance of a single tracker.
NREL has a page devoted to derate factors here which provides a rough approximation for a shading derate based on GCR (ground coverage ratio), but in reality the affect of backtracking is dependent on location.
With this in mind, I modified the PVWatts source to calculate the correct incident angle (function incident2) for a horizontal single axis tracker given a GCR, and ran the simulation for a number of GCR’s and locations. Here is a sample result:
With small changes like this I’m getting closer to a model that accurately predicts real world performance.
Either that or I’m doing it wrong: