Another Reason to Beware Bargain Basement Bluetooth

I was debugging a Bluetooth-related problem on a Windows 7 machine recently, and I found another great example of why sometimes you get what you pay for, even when buying something as nominally standardized and homogeneous as a Bluetooth adapter. It so happens that this machine was using one of these $5 adapters with the fake antenna:

That was the first thing I noticed about these adapters. The second was that each and every one of them had the same address, 11:11:11:11:11:11. Someone didn’t feel like paying for a MAC OUI.. or an EEPROM.

Anyway, back to the present… I had been noticing that sometimes when sending a file to my cell phone from a Windows 7 machine, it would time out. It didn’t happen every time, but it seemed to time out more often than not. I dig a little deeper, and it looks like the file transfer application (fsquirt.exe) is never even getting a chance to open a connection to the phone! It is timing out far before that even happens. What’s the deal?

To make sense of this, it helps to understand a bit more about how the Bluetooth stack works in Windows 7. First a big caveat: I do not work at Microsoft, nor do I have any confidential information about the inner workings of Windows. All I have, really, are informed guesses based on my observations and perhaps a little reverse engineering to satisfy my curiosity.

The main actors here are:

  • fsquirt.exe — The GUI wizard which walks you through sending a file to a Bluetooth device. It lets you choose a device, then it sends the file via the standard OBEX protocol.
  • bthprops.cpl — Technically this is a control panel, but for historical reasons it also implements the public API for Microsoft’s Bluetooth stack. This includes entry points for enumerating attached radios, inquiring for nearby devices, and setting up service discovery records for the local machine. Applications can link to this as a DLL.
  • fdbth.dll — Microsoft’s applications, like fsquirt, actually don’t use the public APIs from bthprops.cpl to inquire for nearby Bluetooth devices. Those public APIs are synchronous: they don’t return until the Bluetooth inquiry is totally finished. It is of course much more user-friendly to display Bluetooth devices as they are discovered, and Microsoft’s apps do this by using an undocumented Function Discovery provider.
  • bthserv.dll — Some operations in bthprops.cpl go directly to the bthport driver using device ioctls, but there is a system-wide service which maintains a database with the state of all known Bluetooth devices. It’s also responsible for maintaining local SDP records. The APIs in bthprops.cpl communicate with bthserv.dll via local RPC calls.
  • bthport.sys — This is the kernel-mode driver which does most of the work. It receives remote name requests, inquiries, and many other operations in the form of ioctls from user-space code.

The important fact I learned while investigating this bug: Inside bthport.sys, there is a global FIFO queue of actions which contact remote devices. If anyone asks to read a device’s name, to perform an inquiry, or to establish an ACL connection with a remote device, it goes in this queue. From Microsoft’s perspective this probably simplifies handling unreliable Bluetooth radios quite a lot, since we never rely on the radio to handle more than one of these operations at a time. Additionally, Inquiry operations are rather heavy-weight, and depending on your link manager settings, you may not be able to do anything else while they’re in progress.

So, back to the hang. When I traced the communications between the USB dongle and the Windows 7 Bluetooth stack, I found this:

The setting: fsquirt has just finished the wizard pane where we’re looking for nearby devices. It notifies fdbth that it no longer needs to keep looking. But in its haste to prettify the UI as much as possible, it has already started asking for human-readable names for all of the Bluetooth devices within earshot. Those requests go into bthport’s queue. The fsquirt app wants to establish an ACL connection to my phone already, but it’s waiting in line behind one of these name requests.

In case you don’t have the Bluetooth spec memorized (I sure don’t), here’s a play-by-play of the USB log:

  • OUT 05 04… — The PC asks the Bluetooth dongle to get a human-readable device name for one of the nearby devices.
  • IN 0F… — Command is in-progress.
  • (Over 20 seconds elapse)
  • IN 03 0B 08… — Connection request finished, error code 08 (Timed out)

But wait! We never asked the device to create a connection! We asked it to read the other device’s name! This looks like a pretty grievous firmware bug in this decrepit little dongle. As we see below, Windows is pretty confused too. My “waiting” and “timed out” notes indicate the state of the fsquirt wizard. The timestamps aren’t saved in this log, but fsquirt is only willing to wait 10 seconds or so before giving up. It’s waiting on bthport, and bthport is waiting on any response, even a timeout, from the Bluetooth adapter.

And it keeps waiting, for 70 seconds. Why so long? It should never take that long for a Bluetooth device that’s actually present to respond. Well, actually it isn’t waiting on the remote device. It’s waiting on the radio itself. The radio is programmed to time out after a much shorter interval specified by Windows, in this case about 20 seconds. Windows is relying on the radio to implement this timeout. What we’re seeing here is an even longer failsafe timeout, to catch errors with the local radio. Like the one we just experienced.

When Windows finally gives up on waiting for our buggy radio to respond correctly to the remote name timeout, we can see it issue the next command. This time it’s the Create Connection command that fsquirt had been waiting on. But fsquirt is already long gone, and the user is already frustrated.

If we’re lucky, the user throws the buggy Bluetooth dongle out the window, not their PC.

New MacBook Pro + Fyre

Back when I bought my last Mac: USB and the Playstation 2 were new, Altivec and shiny plastic were in, and fans were almost starting to line up for the first Harry Potter movie. Oh, and warrantless wiretapping was still illegal. So, Apple, I guess it’s time to put all those hardware failures behind us and see if this relationship can work.

I’ve actually had a lot of fun hacking on Mac OS at work while developing VMware Fusion. Working on such a low-level software project, you see a lot of the ugliest parts of any OS. And there’s certainly a lot inside Mac OS that scares me. But there’s also a lot of cool technology in there. And best of all, I don’t have to futz with my ALSA settings for an hour if I want to watch a YouTube video. Win!

I’d been thinking about upgrading my aging Thinkpad to a 15″ MacBook Pro when it finally kicks the bucket. But darnit, those things are too reliable. So I needed a different excuse. I think it finally boiled down to:

  1. Faster CPU (and 6MB L2 cache.. drool…)
  2. More memory (4GB standard in a laptop. We truly do live in the future.)
  3. Runs Mac OS, Linux, and Windows- so I can develop software for all three
  4. Ooh, shiny!

It arrived this morning, and indeed it is quite shiny. I really do like the new Unibody design- and the large trackpad surface with pseudo-button is actually quite a lot nicer than the standard touchpad on my Thinkpad. (I’ll see how long I can resist the urge to do some low-level poking around in the touchpad, to see how its multi-touch protocol works…)

I think I’m a bad Mac user though. Just about the first two things I did were to install the Ubuntu 9.10 RC, and Windows 7. Then I had to continue my tradition and render a new background image:

Rendering some wallpaper for my MacBook Pro

This is using Fyre‘s cluster rendering support. The GUI and one rendering node are running in a 2-VCPU 64-bit virtual machine on my MacBook Pro. I have two more nodes running on a desktop Athlon64 machine running Linux natively. The total speeds here are pretty impressive- comparable to what David was able to get from running cluster nodes on every machine in one of the CS labs back in college. Isn’t Moore’s Law great? (And I’m sure the 6MB L2 cache helps :))


For anyone who hasn’t already seen it, Linus Akesson (of Craft fame) just released his first demo for the Parallax Propeller: Turbulence.

You can watch the high resolution video on, with an introduction by Linus himself. Or, if you have a Propeller board, he’s provided binaries and source code.

The demo is quite impressive, and he uses some extremely clever tricks to fit it all on a microcontroller with 32kB of EEPROM and no hardware multiply or divide. Linus released the full source code after an exciting reverse engineering contest uncovered many of his techniques. They include decompressing code from EEPROM at runtime, a novel video bus which uses extra I/O pins as fast inter-processor communication, and a nice looking dithering scheme.

Turbulence earned a well-deserved first place in the console/wild category at Breakpoint 2009. Congrats to Linus for showing us what this chip is capable of!

Spark Fun in Fortune magazine

Spark Fun Electronics is awesome. If you’re an electronics hobbyist who hasn’t heard of them, you’re missing out. While us hobbyists have long been able to get a huge variety of “reasonably” priced staple components from Digi-key, and crazy-cheap surplus components from places like All Electronics Corp. and B.G. Micro, I couldn’t help feeling like the industry was leaving hobbyists in the dust. If we wanted bargains on 10-year-old technology we were in luck, but the latest and greatest parts were getting more and more out of reach to the average hobbyist. Either there would be a minimum order of 5000, or they would be in a ridiculously small SMT package, or the data sheets would be proprietary. Most often, all of the above.

Spark Fun to the rescue! They really are the first online electronics store I’ve seen that’s really by hobbyists and for hobbyists. They buy the latest and greatest development boards, sensors, and other toys, put the specs up on their web site, build breakout boards, and sell them for very reasonable prices. As if that wasn’t enough, Spark Fun has become kind of a clearinghouse for custom hobbyist-designed platforms. They stock everything from MAKE staples like the Arduino, to special-purpose platforms like the Uzebox AVR-based game console.

Oh, and did I mention they’re in Boulder? If only I’d known while I was still in school…

Anyway, given how awesome Spark Fun is, I was really proud to see that Spark Fun was mentioned in Fortune Small Business magazine:

Moral dilemma…

Lately I’ve been interested in e-textiles and fabric sensor technology. For an example of something I find infinitely fascinating, take a look at this DIY fabric bend sensor. (Via talk2myshirt, the best named blog evar.)

In that project, many of the conductive textile materials were originally designed (or at least marketed) for electrostatic/electromagnetic shielding applications. Hannah Perner-Wilson, who invented this bend sensor, recommends buying materials from This web site appears to be catering to some tin foil hat-wearing clientelle who would buy microwave-shielded drapes or radio wave blocking baby blankets. Great.

The future of computer education

I just stumbled upon a web site which still sells the Elenco Micro-Master MM-8000 Computer Training Kit, a state-of-the-art piece of educational hardware which includes an 8085 processor, 256 bytes of RAM, and a convenient set of keyswitches and LEDs for entering programs and inspecting memory. I remember seeing these in magazines like Electronics Now in the early 1990s, and they sure haven’t changed.

Here’s an excerpt from the manual where they describe how to load your first program:

New oscilloscope!

For a while now, I’ve been looking for a replacement for my ancient 50 MHz Hitachi analog scope. This scope has served me well for the 10+ years I’ve owned it, but it’s kind of a junker. Slow, out of calibration, flaky triggers… I’d could probably get a similar scope for about $15 on eBay.

As much as I love the instant response and tactile feel of analog scopes, I’ve been doing several projects lately that really could benefit from a digital scope and a logic analyzer. I’ve frustrated myself for hours trying to capture one-shot signals with my analog scope, when a digital scope would have made the job a piece of cake.

So, I finally bought a Bitscope BS100U. It’s a PC-based oscilloscope. I was initially really skeptical about PC-based scopes, but they do have a few big advantages: They don’t hog desk space, it’s easy to export data to your own tools or capture screenshots for the web, and they tend to be cheaper than a standalone DSO with similar features.

Why a Bitscope, instead of something by Pico or another of their competitors? The Bitscope is really hacker-friendly. The manual includes full schematics, their communications protocol is documented online, and there’s a free API for extending their software. Did I mention it’s cross-platform? (Windows and Linux)

Best of all, the Bitscope is a mixed-signal scope. The BS100U has two analog inputs and eight digital inputs. I’ll still need to pull out my homebrew “Saxoscope” for high-speed continuous logic capture, but the Bitscope’s MSO mode should be more than sufficient for day-to-day use.

So, I just got it in the mail today. I may post a full review once I’ve had more time to use it. My initial impressions:

Pros: Small, opto-isolated, mixed-signal, easy to set up, good build quality, fairly powerful software, open design, cheaper than a Tektronix digital scope.

Cons: Kind of slow, software UI is pretty odd, more expensive than some competing PC-based scopes ($595 without any probes/pods). Bitscope web site is very rarely updated.

(Screen shot of some mixed-signal capture from the 10 megabit SPI interface on my Propeller ethernet driver)

Propane pixels

When I was little, I was afraid of fire. I had nightmares about being trapped in burning buildings. Pulse terrified me, even more so than It. I wasn’t scared of being burned- I had my share of encounters with a hot soldering iron or an overheated BJT. I was scared of fire’s power to consume everything I had and everyone I loved.

It seems oddly appropriate then that everyone these days has been calling me a pyro. Sure, I like candles, and I have far too much fun with that butane torch. I like campfires, but who doesn’t? I loved welding in high school metal shop.

Well, maybe I should admit to having some fascination with fire- because the Infernoptix Digital Pyrotechnic Matrix is one of the coolest things I’ve ever seen. It’s a single device that combines my latent pyromania with my love for unconventional display devices.

Their current design is a 12×7 matrix of valves which appear to be capable of producing fixed-size bursts of gas just behind a panel of pilot lights. They mention plans to extend the design to variable-size bursts and to include colored flame. This got me thinking about the scalability of pyrotechnic display devices.

The problem is really the valve-per-pixel nature of the design. Just like how early active-matrix displays were limited by the expense of including a transistor per pixel, these displays must include an expensive valve and nozzle for every single pixel. The display could be made much more economical if some method of multiplexing were employed. This could be mechanical multiplexing, chemical, etc.

My fascination with mechanically scanned displays has suggested an interesting design- picture a thin disc, spinning at a constant high speed. The rim of this disc has a small number of nozzles, perhaps only one or two. Concentric with this disc is a larger disc with pilot lights pointing inward. The nozzles on the rotating inner disc are controlled by very high-speed valves. A fan below the whole assembly provides a relatively constant flow of air upwards. This produces a cylindrical display in which a single high-speed gas nozzle traces a helical pattern across the display’s surface. The high-speed disc provides angular multiplexing while the vertical motion of air provides a continuously scrolling display surface.