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:
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.
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.)
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!
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.
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 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!
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.
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.
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.
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!
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:
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.
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!
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 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.
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?
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 make 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…
I’m working with FPGAs and CPLDs a lot lately. Usually, the development tools require vendor-specific programming cables. I don’t have the vendor programming cables, but I do have an FTDI FT2232H integrated onto my board that I can wire to the Lattice XP2 FPGA as a JTAG interface. Combined with urJTAG, I was able to program my board’s FPGA. There were several hurdles:
- urJTAG requires a BSDL file for programming. I was able to download a BSDL file for my FPGA from the Lattice Web site.
- urJTAG can only program using SVF files, at the moment. I tried the new STAPL support, but it crashes. It might be something wrong with my build environment.
- Lattice Diamond does not output SVF files. I needed to download the separate ispVM System program.
- ispVM System outputs an SVF file that urJTAG doesn’t like. Use the “Rev D” SVF output option.
- SVF programming of the XP2 flash is extremely slow. I’m not sure, but I think the SVF has a delay that accounts for time required to erase the flash. I eventually realized that, for development, I could load a bitstream into the FPGA’s SRAM far faster.
Here’s what a programming session looks like:
jtag> cable ft2232 vid=0xcafe pid=0xbabe interface=1 driver=ftdi-mpsse
jtag> bsdl path /Users/jboone/src/bsdl
IR length: 8
Chain length: 1
Device Id: 00000001001010011001000001000011 (0x01299043)
jtag> svf <filename>.svf progress stop
detail: Parsing 23450/23458 ( 99%)detail:
detail: Scanned device output matched expected TDO values.
This technique should work with the Bus Blaster, too, since it’s based on the FT2232H.