Electronics for Curious Brains.

ShareBrained Technology makes electronic kits and devices for music, radio, and timekeeping. The Chronulator is our first product -- an analog, retro-ish clock with modern, programmable guts. Like all our (future) products, the Chronulator hardware and software are open-source. So you can customize it to look and work however you choose. Read more about the Chronulator or take a look at our gallery.


Maker Faire 2013

I showed two hacks this year: The HackRF radio spectrum analyzer, and Robotron on an FPGA. More details soon! Until then, here are links to more information:

Leave a comment if you have questions!

Leave a Comment [0 Comments]

Sailing the I2Cs with the Bus Pirate

A while ago, I spoke at Dorkbot PDX about using the Bus Pirate to explore devices with I2C interfaces. I’ve been remiss in posting my slides from that talk, so here they are:

I2C @ Dorkbot PDX 0x08

Leave a Comment [0 Comments]

Use The Source! Linux kfifo Rocks.

In embedded software development, there’s frequently a need for a FIFO implementation. Right now, I need to buffer data between my CC3000 Wi-Fi module and an HTTP parser. The CC3000 most efficiently delivers data from a Web server in large blocks (“large” in the embedded world meaning 256 bytes or more). But my HTTP parser will want to consume received data in single-byte increments — looking for breaks between header lines, for instance. So I need something between the two entities to hold on to the extra data that comes out of the CC3000 while the HTTP parser is doing its work. That’s where a FIFO comes in. I can read large blocks from the CC3000 when the FIFO gets empty, filling it back up, and the HTTP parser can grab bytes one at a time.

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?!

Leave a Comment [4 Comments]

WiFi Module For $10?

Last July, I experimented with adding Wi-Fi to the Monulator prototype. With Wi-Fi, a Monulator wouldn’t need to be plugged in to a PC to retrieve information. So far, it’s working great! I have a Monulator that’s scraping a NASA Web site every five minutes, indicating how likely it is I can see an aurora borealis where I live. (Sadly, no auroras yet — they’re very rarely visible at 45 N latitude.)

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…

Leave a Comment [21 Comments]

Chronulator on List of Engineer Gift Ideas

The Chronulator was featured prominently in a National Instruments blog post, “Yes, Virginia: You CAN Buy an Engineer a Good Gift“:

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!

Leave a Comment [0 Comments]

Mobile Church of Robotron at ToorCamp 2012

A group of Dorkbot PDX Dorks got together on a project to identify the Mutant Savior that will deliver the last human family from the brutal tyranny of the Robotrons.

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.

Leave a Comment [0 Comments]

Dorkbot PDX at Portland Mini Maker Faire

Last weekend, I joined my Dorkbot PDX compatriots in exhibiting our projects at the Portland Mini Maker Faire. It’s no surprise that half the photos in this photo gallery are of Dork projects! Where else can you find people who are into beekeeping, rocketry, high-altitude ballooning, aerial photography, robotics, and geometrical metalworking? If you haven’t attended a local Dorkbot meeting, find one near you and GO!

Leave a Comment [0 Comments]

Monulator Design Evolution

Thanks everybody for sending me your Monulator thoughts. I’ve meditated deeply upon them. Here’s what I’m thinking now (more comments welcome!):


Many commenters say a case isn’t essential. I’m convinced this is biased by many of my commenters being Chronulator customers, which are definitely a DIY breed. :-) I’m certain there’s a class of users who would rather design their own case, or mount a bunch of bare Monulators in a rack in a server room. But that’s a relatively small group of people. So I’m still investigating a case. Here’s a sketch of what I’m thinking, from a mechanical standpoint:

Monulator Case Rough Mechanical Sketch

I hope to employ a common manufacturing trick — keeping the cost of injection molding down by creating only one, symmetrical part. Two of these parts would fit together to produce the complete case.

The plastic will be translucent so that the RGB LED lights up the case from within. That should look super-cool…

I read a Wired article about hardware projects on Kickstarter, and how milled aluminum is de rigueur among Kickstarter projects, and isn’t much more expensive than injection molding, at least for small volumes. I do dig aluminum. But aluminum doesn’t allow for a nice rosy RGB LED glow through the case… So maybe for my next project.


The Monulator must get data from somewhere. The simple and cheap solution is to send data via USB, so that’s how I designed it. But USB isn’t ideal. You’ll need to have a PC running all the time, fetching data from a sensor or the Internet, and passing it to your Monulator. The obvious solution is to support some form of wireless. But cheap wireless (like ZigBee or proprietary wireless chipsets) still needs a computer and compatible wireless dongle at the other end to fetch the data. A Wi-Fi device would be great, but they’re expensive and power hungry, and would require a LOT of code on the microcontroller to implement TCP/IP and HTTP and parsing of the data source. But it turns out I was totally wrong about Wi-Fi…

Wishi, who I met via the HackRF project, prodded me to think again about wireless. We Tweeted back and forth about Digi XBees, which I thought only implemented ZigBee or custom wireless protocols. It turns out they also offer Wi-Fi modules, in the same popular XBee footprint, and for the surprisingly reasonable price of $35 US. With a Wi-Fi module, the Monulator could sit anywhere in your house or office and show you fresh data all day and night, regardless of where your PC or laptop is.

Of course, incorporating a $35 Wi-Fi module as a standard feature would dramatically increase the selling price of the Monulator. In fact, I was hoping to sell the Monulator for $35… So instead, I’m redesigning the circuit board to accept an XBee module, and you, the customer can buy the module and solder it in if you want. I might also offer a Kickstarter upgrade where I’d solder the extra Wi-Fi components for you.

Data Sources

A few commenters pointed out Web sites and monitoring software that would be great to interface to a Monulator: Cosm and StatsD / Graphite. I have yet to look into them, but it’d be great to have lots of sources for interesting data.


I bought a few of wireless modules — a few Digi XBees (ZigBee and Wi-Fi), and an XBee-footprint-compatible Wi-Fi module from Roving Networks. Last night, I hacked around a bit with the Roving Networks module (which has some HTTP support) and got it to download the latest Facebook stock price from Yahoo! Finance. I also got it to download the time until the next bus stops outside our house, which should be handy for my wife…

In addition to the wireless modifications I mentioned above, I’m revising the circuit board to work better with a case. I’ve enlarged the circuit board so that it can rest against flanges in the case, which would provide support for inserting and removing the USB cable. The circuit board might also provide some structure to the case. If I leave the back of the case wide open (exposing the circuit board), the circuit board could act as a light baffle for keeping the LED light from leaking out.

I’ve switched the USB connector from a mini-B to a full-size type B connector. Yes, that’s the same chunky cable you see on the back of printers and most USB hubs. Considering how the circuit board needs to mate with the back of the meter, all other USB connector styles would require the connector to come out the side of the Monulator’s case. I don’t like that, because it’ll look ugly and prevent you from stacking several Monulators side-by-side. So the USB cable will go into the back.

A bunch of my initial prototype work is now posted to a new GitHub repository, so have a look. And if you have new ideas or comments, please share them!

Leave a Comment [3 Comments]

The Monulator

Steampunks, IT crowd, data visualization geeks! I have something interesting for you: The Monulator. It’s a riff on my first product, the Chronulator, a clock which tells the time using analog panel meters. However, the Monulator reports whatever information you want — chance of precipitation, time until your next meeting, Twitter mentions, CPU load, stock market change, or a million other things.

The Monulator: USB-controlled analog panel meter with RGB backlight.

The Monulator is controlled via USB from a computer (laptop, desktop, server, Android, etc.). It can also display any color using its RGB LED. Imagine a Monulator showing you some fun or important information, at a glance, color-coded.

The Monulator is an open-source hardware and software design, so it’s eminently hackable.

Inside The Monulator, a USB-controlled analog panel meter with RGB backlight

I have several working prototypes already. I have also started discussions with a manufacturing partner. But there are a few details I still need to work out, and I’d love to get advice from the InterWebs. Here’s what I’m wondering:

  • What information would be cool to show on a Monulator?
  • How should I fund an initial manufacturing batch? Kickstarter?
  • How important is a case?
  • Is 0 to 100 a good default scale?
  • Who wants to help me test the hardware and write software?
  • How do I make the meter faces interchangeable?

Let me know what you think! Comment below, send me an e-mail at ideas@sharebrained.com, or follow me on Twitter.

Leave a Comment [7 Comments]

Patching and Building KiCAD on Mac OS X Lion

I use EAGLE schematic and PCB layout software because I was lucky to get an EAGLE 4.16 Professional license for very reasonable price from a former employer. I upgraded it to EAGLE 5.x, though I felt a bit gypped by what I got for the money. And now, EAGLE is at version 6, and I’m once again having a hard time justifying the upgrade price.

But there’s a more important consideration than price. As I am a purveyor of open-source hardware, EAGLE isn’t ideal software. It’s a closed-source product, and is pay-ware. So it fails on both the “free-as-in-freedom” and “free-as-in-beer” tests. Yes, EAGLE is available in a “free” version, but is quite limited, especially for my designs, which tend to exceed those limits — both in terms of size and number of layers.

So what to do? There are two popular open-source packages for schematic capture and PCB layout: gEDA and KiCAD. I’ve always liked KiCAD in principle, and have tried a number of times to use it on Mac OS X, but the project’s support for Mac is tepid at best. KiCAD is also dependent on wxWidgets, whose Mac OS X support lags other platforms. There are a number of Mac OS X builds of KiCAD out there, which have patches applied and are reasonably stable. But I wanted to build KiCAD (and wxWidgets) from source so I could participate in mainlining Mac OS X improvements — especially for multi-touch trackpad gestures. Here’s a video of the touchpad improvements I made:

Below are my patches and notes for how to build wxWidgets and KiCAD on Mac OS X Lion, from their respective repositories. I’m assuming you have Xcode 4.3.2, and bzr and cmake installed somehow (I used MacPorts 2.1.0).

My patches to wxWidgets and KiCAD fix a CMake line formatting bug, a wxWidgets overlay bug, and a Boost #include bug. (Two of these patches are updated from KiCAD patches I found elsewhere.) The patches also add hacked-in support for the Mac OS X touchpad “magnify” event, so I can use the pinch-zoom gesture. I also modified the mouse scrollwheel support to implement horizontal and vertical scrolling using trackpad gestures.

Here are my build notes, derived from several posts I found about how to build on Mac OS X:

git clone git://gist.github.com/2763241.git
svn checkout http://svn.wxwidgets.org/svn/wx/wxWidgets/trunk wxWidgets
cd wxWidgets
patch -p0 <../2763241/wxWidgets-kicad-overlay.patch
patch -p0 <../2763241/wxWidgets-magnify-macosx.patch
mkdir build-debug
cd build-debug
../configure --enable-debug --enable-unicode=yes --disable-shared --enable-monolithic --with-opengl --with-expat=builtin --enable-aui --with-osx_cocoa --with-macosx-version-min=10.7 --prefix=$PWD/../build-debug CFLAGS=-DMAC_OS_X_VERSION_MAX_ALLOWED=1070 CXXFLAGS=-DMAC_OS_X_VERSION_MAX_ALLOWED=1070
cd ../..
bzr branch lp:kicad
cd kicad
patch -p0 <../2763241/kicad-cmake-line-formatting.patch
patch -p0 <../2763241/kicad-boost-polygon-sort-adaptor.patch
patch -p0 <../2763241/kicad-magnify-macosx.patch
mkdir build-xcode
cd build-xcode
cmake -DwxWidgets_CONFIG_EXECUTABLE=$PWD/../../wxWidgets/build-debug/wx-config -DwxWidgets_wxrc_EXECUTABLE=$PWD/../../wxWidgets/build-debug/utils/wxrc/wxrc -DKICAD_TESTING_VERSION=ON -DCMAKE_CXX_FLAGS=-D__ASSERTMACROS__ -G Xcode ..
open -a Xcode kicad.xcodeproj

At this point, you’re looking at the KiCAD project in Xcode, and can select the particular tool or application you want to build. I’ve noticed some odd behavior in Xcode, where it can’t find #include file pcb_plot_params_lexer.h during the first build attempt, but works fine if you build again.

There are still plenty of bugs to fix. For instance, the overlay stuff doesn’t seem to draw correctly when you move an object in the eeschema. It seems as if the overlay size isn’t set correctly, but seems to fix itself if you resize the eeschema window. Hmmm…

Leave a Comment [9 Comments]