Thursday, February 24, 2011

Ubertooth spectrum analyzer

I took a break from hardware and manufacturing concerns tonight and sat down to write some code. I probably should have worked on the USB bootloader, but instead I wrote a simple spectrum analysis function for the Ubertooth platform. Similar to other transceiver IC spectrum analyzers (like my IM-Me implementation), it tunes its receiver to one frequency at a time and records the received signal strength before hopping to the next frequency.

For now I'm just dumping a table of values to a file and plotting it with gnuplot. In the future perhaps a more sophisticated user interface could be built, maybe integrating with Mike Kershaw's Spectrum Tools or something like that. In this plot, you can see a busy 802.11g network on channel 1 (centered at 2412 MHz) and some Bluetooth traffic (a device performing an inquiry scan) throughout the band.

While testing this, I tried pushing the limits of the CC2400's tuning range for the first time. The device I tested functioned with its receiver tuned from 2268 to 2794 MHz. (The supported range is 2400 to 2483.) I didn't actually generate test signals to validate that it could see stuff throughout the entire range, but my guess is that it is usable across the whole tunable range but with degraded performance at the extremes.

The spectrum analysis code is available in the Ubertooth repository and will be included in the next release. Let me know if you do anything interesting with it. There are just a few days left to pick up one of the first batch of boards by making a pledge on Kickstarter.

Wednesday, February 23, 2011

a year without ice

For the first time in several years, Lars and I are sitting out of the World Ice Art Championships. I'm rather busy with other things this year, and Lars would have had even more difficulty than usual taking time off work. I'm pretty sure we'll be back at it next year, but this time I'm enjoying watching the Single Block Classic web cams from far away in Colorado.

Of course, this winter hasn't been entirely without ice. I haven't picked up a chisel yet, but Lars made a few sculptures (with help from Celso) for his school's winter ball, and both of us have started experimenting with new methods of producing our own ice for carving.

For sculpting, it is almost always desirable to have very clear ice, not white ice, but making a sizable chunk of clear ice is tricky. The problem is that liquid water contains quite a bit of air and often some sediment or other impurities that become more obvious when frozen. As the ice forms, the crystal structure forces the air into pockets that become large enough to see, and all those little bubbles make the ice white. White ice is often unappealing visually, and it is structurally weaker.

The most common technique used to produce commercial carving blocks is to continuously circulate the liquid water as it cools, keeping the top surface in particular from freezing before the rest of the block does. Without this recirculation, ice naturally forms on the top surface first, forming a barrier that prevents air from escaping the rest of the block. Lars had the idea that, instead of recirculating the water, we could keep the top surface from freezing first by simply heating it directly. Here you can see him extracting a large block from the giant "Ice Cube Tray" in his yard. I believe he used a small aquarium heater to do the job, and he was pleased with the result.

I want to try the same thing in Colorado, but I don't have weather so cold as Lars does in Fairbanks. I am afraid that a simple aquarium heater might produce too much heat, but I will give it a try. I figure the worst case scenario is that I have to build my own temperature control device. Not wanting to handle ice cubes as big as Lars's, I picked up a 20 gallon trash can for my experiment. I didn't even have a simple heater when some particularly cold weather came to town recently, so I just filled the bin 3/4 full of well water and set it outside to freeze. This is so I'll be able to compare subsequent results with heating to the result without heating.

As you can see from the block of ice split in twain, the result was terrible. Not only was the entire block full of tiny air bubbles, but a large air pocket formed in the center. When mostly clear ice has a central region with lots of little bubbles, that region is called the "feather." This is far worse. Interestingly, I didn't even have to split the ice myself. I pulled it out of the trash can on a relatively warm day and only looked at the surface. A day or two of above-freezing temperatures later I found that it had split apart on its own!

Thursday, February 17, 2011

Throwing Star LAN Tap

Not long after I designed the 5-in-1 Network Admin's Cable several years ago, I built the first Throwing Star LAN Tap. It is a simple cross of CAT5 cable spliced together to permit in-line monitoring of Ethernet connections. As a passive (unpowered) device, it is limited to sniffing 10BASE-T and 100BASE-TX, and each sniffing connector monitors only the network traffic going in one direction. You just insert it in-line on a target Ethernet connection (between a computer and a switch, for example), and then you can use monitoring tools like tcpdump or Wireshark on a computer attached to one or both of the sniffing connectors. The sniffing ports are receive-only, so there is no danger of your monitoring station accidentally transmitting packets onto the wire.

Despite its limitations, the device has come in handy countless times over the years. It is small enough that I can keep it in my backpack all the time. To sniff traffic in both directions, you have to monitor on two ports, but you'd be surprised how often sniffing just one direction at a time is sufficient for monitoring and troubleshooting tasks.

In 2007, Jason MacPherson wrote to me describing his extension of the Throwing Star LAN Tap design. (Alas, the link he sent is now broken.) He didn't bother with the throwing star form factor, instead opting to build his device in a box. The cool thing he did was to use the complete pinout of the 5-in-1 cable (all eight conductors) such that his tap could be used for monitoring either Ethernet or RS-232 serial connections. Why didn't I think of that?

Ever since then I've thought about building a new throwing star using Jason's approach. Another improvement I've had in mind is to switch from male RJ-45 plugs to female sockets. Although the male version is nifty and tiny, it invariably must be used with two or three couplers. Plus the tabs eventually break off the plugs, which is particularly annoying when they are attached to a very carefully spliced device.

Within the past year I've learned how to design printed circuit boards, so I decided to try building a female throwing star. There was one new problem I had to solve: how to handle 1000BASE-T (Gigabit Ethernet). Because 1000BASE-T signals travel in both directions simultaneously on each individual wire, it is impossible to build a passive tap for the technology. To properly tap 1000BASE-T, you need an active device such as a powered LAN tap or a switch with a monitor port. In a pinch, though, it is nice to be able to pull something out of your bag to get the job done, so I opted to make my throwing star compatible with 1000BASE-T in the only way I could, by breaking 1000BASE-T:

Since 1000BASE-T uses two more pairs of conductors than 10 or 100 Mbit Ethernet, I bypassed each of those extra pairs with a 220 pF capacitor. (Disregard the erroneous 22 pF marking in the photos.) This filters out the high frequency signals of 1000BASE-T, forcing the target devices to revert to 100BASE-TX which can then be monitored. The capacitors don't adversely affect lower frequency RS-232 signals, so all eight conductors function when monitoring serial connections. Sure, it's an ugly hack, but it's an ugly hack that fits in your pocket.

I figure that most folks who are interested in Bluetooth monitoring have occasion to sniff Ethernet from time to time, so I'm getting a bunch of kits produced, and I'll drop one into each reward package sent to backers of Ubertooth One on Kickstarter at the $100 level or higher. I'll also include a bare PCB with the $15 and $30 reward packages. I'm thinking about handing out PCBs as business cards at hacker cons, but I can't decide if it is a really good idea or a really bad idea. What do you think?

Open source design files are here.

Update: Throwing Star LAN Tap Kits are now available.

Sunday, February 06, 2011

Project Ubertooth: Building a Better Bluetooth Adapter

Video of my presentation, Project Ubertooth: Building a Better Bluetooth Adapter, at ShmooCon 2011 is now online. You can download the entire video in high quality from shmoocon.org or watch it in your web browser. In the presentation, I demonstrated Ubertooth One, the world's first open source, widely available, low cost Bluetooth test tool, and I described my two year design journey starting as an electronics novice. This was one of the most fun talks I've ever given, and I want to thank ShmooCon for making it happen and everyone who attended for participating. I'm making the slides available, but, as is typical of my presentation slides, they really don't stand alone.

Shortly before the presentation, I was interviewed by Hak5. The interview covered a lot of ground and included quite a bit of discussion beyond the content of the presentation.

At ShmooCon I announced the start of a pledge period on Kickstarter to fund an initial production run of Ubertooth One boards, and the pledge goal was met in just four days! There is still time remaining in the pledge period for anyone who would like a board. Thank you to everyone who has pledged support!

Wednesday, February 02, 2011

first Bluetooth Low Energy packets

A package arrived today containing my first Bluetooth Low Energy equipment. Bluetooth Low Energy is a new wireless technology within the Bluetooth specification suite. It provides capabilities similar to Basic Rate Bluetooth, which has been around for ten years, but consumes less power while doing so. Consumer Bluetooth Low Energy products likely won't hit the market for a few months, but engineering development tools have recently become available.

This kit from Texas instruments contains a two small CC2540 development boards, one in the form of a keyfob and the other in a USB dongle form factor. For now I'm not interested in developing firmware for the CC2540. Frankly I'm annoyed that TI has chosen not to document the internal radio properly. Despite its limitations, however, this kit provides a quick and easy way to generate Bluetooth Low Energy wireless packets over the air, and I'm using it (so far just the keyfob) to help me develop Low Energy sniffing capability on the Ubertooth platform.

It only took a few minutes to tweak the Ubertooth code such that it would demodulate Bluetooth Low Energy packets properly, but I don't have much in the way of automated packet detection or decoding. Using a fairly crude method, I've searched through the demodulated bits to find the advertising packets transmitted by the keyfob. These are packets transmitted on one of only three advertising channels in an effort to locate another device to communicate with.

One of the key differences between Basic Rate and Low Energy is that Low Energy devices are able to locate each other and initiate communications using this advertising method much faster than Basic Rate devices ever could. Basic Rate devices waste a lot of power keeping connections alive; Low Energy devices will just tear down connections entirely and go to sleep knowing that they can wake up and find each other again very quickly. One of the reasons the method is fast is that advertising is only done on three channels, and that makes it easier for a passive observer to capture the process.

I've also captured the packets using a USRP. Glancing at the waveform and spectrogram, it is difficult to distinguish this packet from Basic Rate Bluetooth. I haven't written any GNU Radio code to demodulate the raw waveform, but I am replaying the recorded file through the USRP as a simple way to produce a repeatable test vector.