Technical Details

This project is built around the HackRF, a software-defined radio transciever. I programmed it to sample 20MHz of radio spectrum from an antenna, do a frequency analysis on the data, and display the results on a Noritake vacuum fluorescent display. I added the tuning wheel mid-afternoon on Sunday, and it really improved the interactivity of the display. It felt really cool to spin the wheel around and watch the spectrum scroll back and forth. Too bad I didn’t capture that in the video…

The HackRF’s microcontroller is an ARM Cortex-M4F + Cortex-M0 “dual core” chip. Both are running at 204MHz. The M4F has hardware floating point, which drastically simplifies the signal processing code.

The ARM grabs 512 complex samples at a time from the radio analog-to-digital converter (ADC). It applies a window function that reduces artifacts from sampling arbitrary chunks of a radio signal. The windowed samples are converted to frequency domain data through a 512-point fast-Fourier transform (FFT). The frequency data that comes out of the FFT (frequency vs. a complex vector) is converted to real magnitudes. I take the logarithm of each magnitude to get values vs. frequency that resemble decibels. Then, I scale the log-magnitude data to fit nicely on the vacuum fluorescent display, which is 384 x 32 pixels. For each frequency in the scaled data, I render a bar into a frame buffer I maintain in RAM, using cute bit-shifting tricks. Then, I render marks at 1MHz intervals to provide a tick-mark scale on the display. In the left corner of the display, I render minimum and maximum sample buffer values for each of the two sampling channels — this is so I can tell if I need to turn up or down the gain on the receiver. I draw the current tuning frequency in MHz at the center of the display. Lastly, I scan out each of the pixels, one byte at a time, into the VFD’s parallel 8-bit interface, using the display’s “Graphic DMA” mode.

The optical quadrature encoder runs purely on interrupts. Whenever a positive- or negative-going edge is detected on either of the two optical sensors, an interrupt is generated. Based on the current and previous values of the optical sensors, the software (borrowed from PJRC’s Encoder Library) decides if the wheel has moved, and if so, which way it has moved. Based on that decision, the tuning frequency is incremented or decremented.

There was a hairy bit of wiring between the HackRF and the VFD. I needed to interface the HackRF, which is a 3.3 Volt device, to the VFD, which communicates at 5 Volts. So I needed to translate several signals between those two voltages. I had an old circuit board from my Robotron-FPGA project that did exactly that, for a completely different purpose. But with enough wires and headers and disgusting rewiring, I made it work. But it wasn’t pretty. I had to keep poking it and twisting it, as some signals were intermittent and sometimes needed my help.

The Faire Experience

The HackRF can tune from below 10MHz (where it’s mostly amateur radio and AM radio stations), up through 6GHz. That includes *almost* every signal in common use. Until I added the tuning dial, I left the HackRF at about 840MHz, right in the middle of one of the cellular (mobile phone) bands. As you’d imagine, lots of cellular phones were in use at Maker Faire, so a lot of signals were jumping about on the display. People who really got the display would soon pull out their phones to make a call. Most of the time, their phones were operating in other cellular bands, but a few times we got lucky and could clearly see activity that came and went depending on whether they were in a call or not.

Late Saturday, a couple of hams (amateur radio operators) came by with their portable radio transcievers. I tuned the HackRF up to 440MHz and we could see peaks when they were transmitting. They were amused…

The first half of Sunday, I attached the optical encoder wheel and wired up the optical interrupters to the HackRF. The wheel was laser cut acrylic, cut before I left for Maker Faire. I cut a bunch of different designs, since I wasn’t sure exactly how everything would fit together ahead of time. The wheel was mounted on a Lazy Susan apparatus I bought at a hardware store. I drilled the wheel assembly to my display whiteboard, and then started attaching the optical interruptors with hot glue. Unfortunately, I needed a couple of 470 Ohm through-hole resistors to control the current through the interruptors’ LEDs, but I didn’t bring *any* resistors with me. So I went begging at the Radio Shack “Learn to Solder” tent, and they were kind enough to bust open one of their $60 electronics kits to give me $0.07 worth of resistors. While I was gone, somebody had forcefully cranked the wheel and broken off several of the teeth. I should’ve seen that coming! Fortunately, I had lots of other options from my laser cutting binge. I settled on a sandwich, consisting of the tooth pattern cut in paper with clear thin plastic on either side.

Once I got the encoder software working, I added a frequency display in the middle of the VFD. People would walk up and give the wheel a spin, looking around for interesting signals. There’s a lot of underutilized spectrum (at least where we were), so it wasn’t too exciting outside the cellular and 2.4GHz bands. The environment was also quite electrically noisy, so with a fairly insensitive receiver, long-distance bands (e.g. aviation) didn’t really show anything — those weaker signals were jammed by all the motors and Tesla coils nearby. I’m sure my antenna also wasn’t the best…

Despite the last-minute additions and general hackiness of the project, I had a lot of fun building it and talking with people about it. Events like Maker Faire are great as a reminder that you’re not the only person in the world who likes to nerd out on such obscure things!

It’s back from manufacturing, and the first few subsystems are being assembled. Any bets on whether it’ll work the first time? :-)

First fabricated Daisho project main boards are back from manufacturing.

Radio Spectrum Analyzer:
• HackRF Software-Defined Radio
• Noritake GU384X32L-3900 vacuum fluorescent display, for sale, cheap!

Robotron on an FPGA:
• Robotron-FPGA project source code and MC6809E adapter board design
• Motorola MC6809E microprocessor on sale at Jameco
• Robotron: 2084 Schematics
• Digilent Nexys 2 FPGA board
• Suzo-Happ Super Joystick

Leave a comment if you have questions!

I2C @ Dorkbot PDX 0×08

I had the (perhaps obvious) thought that the Linux kernel developers must also need FIFOs. Sure enough, they have a FIFO implementation called “kfifo“. And what an implementation! Through an exceptionally elegant trick of modular arithmetic, the code is so simple, it’s almost non-existent.

A FIFO needs to keep two indexes into a buffer array — an “in” index to where data is added to the FIFO, and an “out” index to where data is removed from the FIFO. When data is added, the data is placed at the “in” index of the array, and the “in” index is incremented. When data is removed from the FIFO, data is obtained from “out” index in the array, and the “out” index is incremented. This works just fine until the “in” and “out” indexes go past the end of the array. So you have to add code to check the “in” and “out” indexes after you increment them, and wrap them around to the start of the array when they go past the end. It’s also important to prevent adding new data if the FIFO is full, and prevent removing data if the FIFO is empty. More code, more conditionals, more spaghetti.

The kfifo code simplifies all those concerns. Instead of checking for “in” and “out” going past the end of the buffer array, it just lets them keep growing past the end. By observing that the wrap-around is just a form of modular arithmetic, and by requiring kfifos to have a length that’s a power of two, they can take the “in” and “out” indexes and logically-AND them with a bit mask that’s the length of the array minus 1. This turns an index into the value it would’ve been had you done the bounds checking and wrapping I described above. And because the “in” and “out” indexes no longer wrap, you don’t need complex code to calculate the difference between “in” and “out” to know how full the FIFO is — you just subtract “out” from “in”! But wait! What if you get to the point where “in” and “out” are so large that they wrap around the maximum value for their data type (probably an unsigned 32-bit or 64-bit integer)? Well, modular arithmetic again saves the day. If “in” equals 10 and “out” equals 2^32 – 10 (4294967286), and you subtract “out” from “in” using 32-bit math, you get… 20! How cool is that?!

Look Ma, no host! The Monulator displays the current aurora Kp index.

The one bummer about adding Wi-Fi to the Monulator is that it’s expensive. The Roving Networks (now Microchip) RN171XV module is about $30 US in quantity, which is simply too much. But then I stumbled across the TI CC3000 Wi-Fi module. It’ll do 802.11b/g in the 2.4GHz spectrum, for only $10 US in quantity. It’s exciting to think I could add Wi-Fi capability to the Monulator for a modest incremental cost!

I got a development board a couple of weeks ago, and have struggled mightily to get the CC3000 to talk with an ARM microcontroller and my Web server. But I have made real progress!

My rig for developing CC3000 driver code — CC3000 module, LPC11U14 dev board, Black Magic Probe, Bus Pirate, and HackRF (serving as a high-current power supply).

The CC3000 does not use a serial/UART interface like most of the other Wi-Fi modules. The CC3000 talks SPI. This is great, because SPI can transfer data very quickly (16MHz on the CC3000). SPI is also transfer-oriented, so sending and receiving commands is (arguably) simpler than managing command and data modes of a stream-oriented API (typical of a simple serial interface). Unfortunately, TI did a very poor job of documenting the CC3000′s command protocol. There’s some low-level documentation on their CC3000 Wiki, but details about command and response data structures is missing completely. I’ve had to wade through their “host driver” code to understand the protocol. In that process, I also learned that what TI posted to the Wiki is not always correct (a common Wiki phenomenon). Among the revelations, TI says the SPI interface uses a particular style of clock/data synchronization (CPHA=0, CPOL=0, but the next sentence, the datasheet and this forum post describe a CPHA=1 configuration.

Eventually, I got my own CC3000 driver code working, and was able to communicate with the CC3000 at a basic level. I saww that the firmware on my module was quite old (version 1.7, while the current version is 1.10.1). TI provides sample code for updating the firmware, but it only works for their MSP430 and Stellaris microcontrollers, Windows, and proprietary/closed development tools. That won’t work for me, so I ported the patch update code. This was rather scary, as I was sure I’d have a bug in my code and would brick my CC3000 module. At a couple of points, it looked like I had. But it turns out their bootloader and update process is robust, and I was able to back out my applied (and messed-up) patches and re-write them correctly.

I used to debug in a fancy IDE, but these days I like GDB –tui.

Commands issued to the CC3000 over SPI are wrapped in an “HCI” structure, which looks a lot like your ordinary RPC (remote procedure call). On top of the HCI layer, they’ve implemented an API modeled after BSD sockets. But it seems like their sockets implementation doesn’t behave quite the same as it does on a PC. For instance, when I’m connected to sharebrained.com via HTTP, my PC sockets test program disconnects after the HTTP body content is downloaded. On the CC3000 side, I receive no indication that the server has disconnected — the socket is not signaled as closed, and I see no indication via select(). So I’ll have to parse the HTTP response header (and I should anyway) to figure out when I’m done downloading. Not sure what I should do if no Content-Length is provided by the server. Time to break out the HTTP RFC…

The world’s fastest LabVIEW programmer Darren Nattinger suggested a throwback clock called The Chronulator. “I have one on my desk at home and I’m a big fan of it,” Nattinger said. “It uses a pre-programmed TI microcontroller and two analog ammeters to represent hours and minutes. It comes pre-built or as a solderable kit that you can put together. The source code is even available if you want to tinker with it.”

This explains the sudden up-tick in Chronulator orders from people with geeky e-mail addresses. Thanks to everybody who ordered a kit — I hope the intended recipient enjoys it!

Robotron: 2084 Flyer

What? You don’t know what Robotrons are? Let me clue you in. Robotron: 2084 is a video game from 1982, when video games were primarily an arcade experience. Yes, you had to leave your house and pay money to play video games!

Robotron is quite an amazing game. It seems simple by every measure, and yet it’s very hard to master. I think that’s why my group of friends love it so much.

Anyhow, a bunch of us planned to attend ToorCamp 2012, a technology/geek/hacker camp in Washington State. An idea was hatched to create an exhibit at ToorCamp, based on the story behind the game. So the Mobile Church of Robotron was born, in attempt to identify the Mutant Savior, the only being capable of saving humanity from the Robotrons, a breed of “perfect” robots created by humans.

Many Teensys and Arduinos and lasers and fog machines were pressed into service building an altar at which humans would be tested. It was brilliant:

Sadly, we did not identify the Mutant Savior at ToorCamp. But the search continues! Join the cause by reading the church literature, visiting us at a Dorkbot PDX meeting, or contributing to the ball of code that is the MCOR source code repository.

My contributions consisted of the LED sign which showed high scores. I had to reverse-engineer the sign, as the company that manufactured the sign refused to release documentation for the display’s protocol. So I replaced the CPU board with an Arduino. I’ll write up a bit about the process and publish the circuit board design and software soon.

I also built up a simple light controller for the totem pole erected outside the church. It’s based on an earlier controller that I designed for the Make: TV Dispenser Brian and I did for Maker Faire 2009.