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!
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.
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!):
Case
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.
Wireless
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.
Progress
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.
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 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…
Leave a Comment [7 Comments]
Debugging Lattice FPGAs for the Impatient
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
jtag> cable ft2232 vid=0xcafe pid=0xbabe interface=1 driver=ftdi-mpsse
jtag> bsdl path /Users/jboone/src/bsdl
jtag> detect
IR length: 8
Chain length: 1
Device Id: 00000001001010011001000001000011 (0x01299043)
Filename: /Users/jboone/src/bsdl/lfxp2_5e_tqfp144.bsd
jtag> svf <filename>.svf progress stop
detail: Parsing 23450/23458 ( 99%)detail:
detail: Scanned device output matched expected TDO values.
jtag>
This technique should work with the Bus Blaster, too, since it’s based on the FT2232H.
Leave a Comment [9 Comments]
Progress On My Software-Defined Radio
I’ll confess, I’ve kept some secrets from you. The fancy software radio baseband digitizer I mentioned back in November? I got it working not long after, and I’ve had some fun with it (see demo video, below). Here it is, connected to my ADRF6850 front-end board:
I wrote a quick-and-dirty capture program, starting with a libftdi (“master” branch) example program, stream_test.c. With it, I can sustain approximately 32MBytes/second. It appears my hard drive write speed is the bottleneck, as I get drop-outs periodically, but only if capturing to disk, not RAM.
I haven’t incorporated any low-pass filtering, or finished implementing proper digital downsampling of the raw baseband sample stream, so to test the system, I chose the most powerful signals available: FM broadcast. I captured about 8MHz of the local FM spectrum, centered around 101.9MHz, and was able to play it back and demodulate several channels using GNU Radio.
Up next, proper filtering, and some more interesting wideband signals! And maybe I should clean up my office before I make my next video…
Leave a Comment [6 Comments]
HackRF, A Software-Defined Radio Project
Michael Ossmann of Great Scott Gadgets is working on a new software radio called HackRF. His vision is to repurpose a highly-integrated transceiver IC to serve a wider tuning range, ideally from below 100MHz to over 4GHz.
I’m helping out with various tasks along the way. Here are the biggest challenges we’ve faced so far:
- Finding a front-end IC or combination of ICs that will convert 2.4GHz signals to/from baseband, digitize received baseband signals and “analogize” transmitted baseband signals. So far, the best solution seems to be a two-chip combination of the MAX2837 WiMAX transceiver and MAX5864 analog front end (quadrature ADC and DAC). This combination will get signals to/from 2.4GHz to digitized quadrature baseband data streams.
- Moving digitized baseband data between the HackRF device and the host PC — again, inexpensively and using little power. The most conventional, obvious interface is USB 2.0 high-speed. We’ve entertained several options: ARM microcontrollers, FPGAs, XMOS event-driven processors, and dedicated USB interface ICs like the Cypress CY7C68013 and FTDI FT2232H. In reviewing these options, we came across a new breed of ARM microcontrollers that have generalized high-speed interfaces on them. The most compelling so far is the LPC43xx SGPIO interface, which can be configured into arbitrary-width serial or parallel interfaces running at over 100MHz transfer rate.
- Understanding and configuring the Si5351C clock generation IC. Silicon Labs documentation for this part is rather scattered and inconsistent. Mike did a lot of testing with an oscilloscope to identify the true behavior of the IC.
- Interfacing the LPC43xx SGPIO interface to the MAX5864, which has two dual-data-rate (DDR) interfaces that the SGPIO port can’t directly interface to. Our current solution is to use a low-cost CPLD (programmable logic device) to convert bus widths, voltages, and clocking schemes.
- Keeping total power consumption to below USB 2.0 limitations. Mike opted to put a switching regulator on the board, which seems to work well, though we haven’t reached the point in development where we’re drawing a lot of current *and* trying to receive weak radio signals. It’s possible the switcher may produce enough noise to interfere with the radio circuitry.
Keep up with HackRF developments on the GitHub repository and Wiki, or join us in IRC (freenode.net #hackrf), or on the HackRF-dev mailing list.
Leave a Comment [2 Comments]
Piper (1998-2011)
ShareBrained’s chief quality inspector, Piper, left us in late December 2011.
Every package we shipped had a little bit of Piper fur thrown in, for good luck. Perhaps you still have your Chronulator box laying around somewhere? Look for little 2 cm (0.75 inch) strands of straight, stout black fur, the mark of quality!
Leave a Comment [0 Comments]
On Blogging and Modesty
Once again, I’ve neglected my blog. It’s not because nothing’s happening. On the contrary, many things have happened in the five or so months since I last posted.
I’ve given some thought to my relationship to blogging and social media, and why I seem to be so bad at it. I think it boils down to modesty:
- Modesty about wasting people’s time sharing things that aren’t finished. Until I make something work, end-to-end, I assume it’ll never work, or that people will criticize me for doing it wrong. And I don’t want to let people down.
Modesty about my writing abilities. My dad’s a journalist, so at some level, I have come to view writing as a professional activity. And I’m no professional writer.
Looking at these reasons for not blogging, I realize they’re a bunch of baloney.
When I read other hardware-oriented blogs (Dangerous Prototypes and Hack a Day come to mind), I don’t have the same expectations I do for my own blog. There are always quick little truffles of ideas and progress, posted all the time. I enjoy seeing the creativity and the process. Yes, finished products are nice (have I mentioned recently how awesome the Bus Pirate is?). But even the Bus Pirate is a work in progress. It’s gone through three major revisions since it was first announced. And these revisions were done with public input, which certainly made it a better product. And public involvement, to a great extent, made the Bus Pirate possible in the first place. I doubt Ian could’ve developed the Bus Pirate to such a degree, all by himself. He has dozens of people contributing. The process is what people want to hear about and participate in. And I could use some people pushing me and keeping me focused on what’s truly important about my projects.
As for my writing skills, I write just fine, thank you. The most important thing is that I communicate, not that my grammar is flawless. And I don’t need professional training or experience to communicate successfully. Ironically, in other fields of endeavor, I’m notorious for being anti-professional. I staunchly believe you don’t need to go to school to learn engineering skills, or hold down an engineering job to feel qualified to build things. What’s most important is passion. With passion, and some patience, you can acquire the skills to do most anything you want.
In the end, I’m taking this blogging stuff all too seriously. So I shall redouble my efforts to share what I’m doing and what I’m thinking. In the process, I hope to accumulate a crowd of smart and curious people who are interested in the same things I am, and will help turn some cool ideas into reality. Yay!
More to come, soon!
Leave a Comment [4 Comments]
Simple Chronulator Case Design
Taking a cue from Adam’s Chronulator case design, I experimented yesterday with a friend’s laser cutter, to make a Chronulator case that’s simple and easy for customers to assemble. Here’s the result:
What Chronulator case designs would you like to see in the ShareBrained store? Leave a comment, a Tweet, Facebook/Google+, e-mail, it’s all welcome!
Leave a Comment [0 Comments]
Facebook
GitHub
Google+
Twitter
YouTube