(Hat tip to the late Bill Strauss and The Capitol Steps' Lirty Dies.) A few moons ago I was thinking of ways to take my Palm OS Fossil Wrist PDA smartwatch mobile. It has no on-board networking libraries but can be coerced into doing PPP over its serial port (via USB) by using the libraries from my Palm m505. Of course, that then requires it be constantly connected to a USB port, which is rather inconvenient for a wristwatch.

But what if the USB connection could be made wirelessly? For a few years, real honest-to-goodness wireless USB devices were actually a thing. Competing standards led to market fracture and the technologies fizzled out relatively quickly in the marketplace, but like the parallel universe of FireWire hubs there was another parallel world of wireless USB devices, at least for a few years. As it happens, we now have a couple of them here, so it's worth exploring what wireless USB was and what happened to it, how the competing standards worked (and how well), and if it would have helped.

You can probably blame Wi-Fi for this: while early patents for Wi-Fi existed as far back as 1991, after the introduction of 802.11 in 1997 and Apple's use of 802.11b for the iBook G3 in 1999 people really started to believe a completely wireless future was possible — for any device. This was nevertheless another type of network, just one involving only one computer and one user over a short range, which was grandiosely dubbed the "personal area network," or PAN, or WPAN, depending on executive and blood alcohol level. Although initial forms of Bluetooth were the first to arrive in this space, Bluetooth was never intended to handle the very high data rates that some wireless peripherals might require, and even modern high-speed Bluetooth isn't specced beyond 50 megabits/sec (though hold that thought for a later digression). The key basis technology instead was the concept of ultra wide-band, or UWB, which in modern parlance collectively refers to technologies allowing very weak, very wide-spectrum (in excess of 500MHz) signals to become a short range yet high bandwidth communications channel.

Wideband, in this case, is contrasted against the more typical narrowband. In general radio transmission works by modulating a carrier wave of a specified frequency, changing its amplitude (AM), phase, and/or the frequency itself (FM), to encode a signal to be communicated. For terrestrial analogue broadcasting, a good example of narrowband radio, this might be an audio signal carrying some specified frequency range; for FM radio in the United States this audio signal ranges from 30Hz to 15kHz, enough to capture much of the human-audible range, plus various higher frequencies not intended for listening. This collective signal effectively becomes encoded into sidebands on one or both sides of the carrier frequency (even with AM), and per Carson's rule the higher the maximum modulated frequency of the encoded signal then the larger the sidebands (ergo, its bandwidth) must be. As a result, commercial radio stations in particular are often heavily filtered for coexistence to allow many stations to share the band: in the United States, within ITU Region 2, the Federal Communications Commission (FCC) divides the FM band from 88.0MHz to 108.0MHz into 100 "channels" of 200kHz each, putting the nominal carrier frequency in the middle of the channel to provide sufficient sideband width for modulation, and strictly regulates any spillover outside those channel boundaries. In practice, most adjacent U.S. FM stations are no closer than 400kHz, a balance between spectrum capacity and signal strength. This typically permits a maximum FM stereo modulated frequency of about 53kHz; frequencies in the aggregate range being transmitted that are unused or unnecessary can be repurposed as subcarriers to emit additional information, such as FM stereo's 19kHz pilot tone subcarrier used to signal receivers, or Microsoft's brief flirtation with one-way transmissions to SPOT smartwatches. Doing so is "free" because the subcarrier frequency is already part of the frequency range.

By contrast, signals like 802.11 Wi-Fi are wideband radio, or at least comparatively wid-er band, because they pass much higher bandwidths. Although 802.11 frequencies (except for the very highest 45/60GHz band) are generally divided into 5MHz channels, people typically only use channels 1, 6 and 11 with 2.4GHz Wi-Fi, for example (or, in later standards, 1, 5, 9 and maybe 13), which spaces them by 20MHz or more. Compare this with medium-wave AM radio, where channel spacing in the United States is just 10kHz and even 9kHz in some countries like Australia, or shortwave radio with only 5kHz spacing.

That brings us to UWB. UWB has its roots in impulse radar, which is a form of the more familiar pulsed radar (such as the traffic cop at the corner) using much briefer radio pulses. Radar also works on a carrier wave model, but instead of FM or AM, the radar carrier wave is merely pulsed on and off. This is necessary so that the detector during the "off" phase can pick up echoes of the radio pulse transmitted during the "on" phase, and for most applications of radar, the pulse-repetition frequency (PRF) is much less than the frequency of the carrier wave being pulsed. Shorter, more frequent pulses would have theoretically yielded greater precision at close range, but such capability was beyond the electronics available to early radar researchers who were more concerned with long-range detection anyway, where the off phase had to be of sufficient length to detect a distant reflection. By the 1970s, however, the technology had sufficiently advanced that the radar's PRF could approach its carrier frequency, making things like ground-penetrating radar possible. While higher frequencies couldn't travel through ground for great distances, they did yield much better resolution and therefore meaningful data.

To a basic approximation UWB uses the same principle as impulse radar: a series of pulses, potentially as short as picoseconds long, of a particular carrier wave. As the carrier wave itself isn't changing, all of the information is necessarily being encoded in the pulses' timing. Being discontinuous waves, Carson's rule doesn't directly apply to most forms of UWB, but the analogous Shannon capacity limit indicates that rapid modulation from a high PRF would also require significant bandwidth — hence, ultra wide-band. To mitigate UWB transmissions from interfering with narrower-band transmissions on the same frequencies, the pulsed transmissions can be made at very low power, often below the typical noise floor for other transmissions. Naturally this also necessarily limits its range to perhaps a hundred or so metres at most but also makes battery-powered operation highly practical. Its utility in location-finding is because time-of-flight can be measured very quickly and exactly due to the short pulse lengths; when fully active, an Apple AirTag typically transmits a pulse about every other nanosecond.

The FCC first approved UWB for low-power unlicensed use in February 2002 (for comparison, the first commercial Bluetooth device arrived in 1999), though communication systems were only allowed on the upper range from 3.1GHz to 10.6GHz and the FCC also made subsequent amendments. A standards group quickly emerged at the IEEE called the IEEE 802.15 Working Group for WPANs, addressing not only UWB but other WPAN-enabling technologies generally. The 802.15 WG had two arms, 802.15.4 for low bandwidth applications which we will not discuss further in this article (Zigbee is probably the most well-known in this category), and 802.15.3 for high bandwidth applications. Subsequently, the WiMedia Alliance was established that summer to capitalize on the new high-bandwidth technology, counting among other early members Eastman Kodak, Motorola, Hewlett-Packard, Intel, Philips, Samsung, Sharp and STMicroelectronics. 802.15.3 had obvious utility in determining precise location, but an extension called 802.15.3a in December 2002 sought to further enhance the standard for high-speed transmission of image and multimedia data. This team started with 23 proposals and whittled them down to two, DS-UWB (alternatively DS-CDMA) and MB-OFDM.

DS-UWB stands for direct sequence ultra wide-band, where the data is simply sent as pulses (as in binary pulse AM) over the entire frequency range in use. However, although the low power of UWB prevents it from interfering with higher-power narrowband signals, an additional layer is needed to prevent UWB transmissions from interfering with each other (i.e., multiple access). DS-UWB uses a system similar to cellular CDMA (code-division multiple access) where each transmitter modulates the data signal with an even higher frequency pseudorandom code known to the receiver, hence its alternative name of DS-CDMA. An interfering transmitter without the same code will have its signals attenuated during the decoding (despreading) process and be ignored. Additionally, by making the transmitted signal require more bandwidth than the original one, the composite signal becomes spread over an even larger frequency range and thus more resistant to narrow-band interference (i.e., direct sequence spread spectrum).

On the other hand, MB-OFDM (multiband orthogonal frequency-division multiplexing) instead employs a massive number of subcarriers to send its data. The basic principle of OFDM, which dates back to Bell Labs in 1966, is to divide up the desired digital signal into multiple bits transmitted in parallel on multiple simultaneous subcarriers. OFDM has many current applications, among others various standards for Wi-Fi and digital TV such as DVB-T and 802.11a/g/n/ac/ah. To avoid interference between the subcarriers yet maximize the channel's capacity, each subcarrier is separated by a minimum frequency distance usually computed as the reciprocal of the useful symbol duration, making each subcarrier orthogonal to the others surrounding it and easily discriminated. MB-OFDM as used here divides the approved range into fourteen 528MHz subbands of 128 subcarriers each, 100 of which are used for data transmission and the remainder for zeroes, guard tones and pilot signals. It solves the multiple access problem by hopping between transmission subfrequencies in a defined pattern (time-frequency coding), meaning each user ideally is on a different one at any given time while also avoiding narrowband intrusion on any one particular frequency. In practice the spec doesn't use all of the subbands simultaneously, bundling them into four bandgroups of three (with a fifth group of two, and a sixth group overlapping two others) and selecting a group as required by local regulation or to compensate for existing sources of interference.

Both technologies are mutually incompatible, and both received substantial and opposing corporate backing largely along the lines of existing patents. The MB-OFDM camp came together as the MultiBand OFDM Alliance in June 2003, founded by Texas Instruments and crucially joined by Intel, while the DS-UWB camp was largely led by Motorola and subsequently Freescale, its inheritor, who had significant investment in CDMA. Although MB-OFDM demanded obviously greater technical complexity, it also presented the prospect of much faster data rates, and as a result the MBOA continued to accrete members despite Motorola's protests. Motorola attempted to develop a compromise lower-speed Common Signaling Mode ("UWB CSM") so DS-UWB and MB-OFDM devices could coexist, but the process descended into squabble, and Motorola pulled out of the WiMedia Alliance to establish the competing UWB Forum in 2004 exclusively focused on DS-UWB with CSM.

As the standards argument raged in the background, OEMs meanwhile started evaluating potential market applications. After all, just about any potential short-range interconnect could be built on it; proposals to replace or reimplement Bluetooth with UWB were considered, as well as transports for IPv4 networking and FireWire (IEEE 1394). The original wireless USB concept in particular came from Motorola's new spinoff Freescale, who was determined to win the war anyway by getting their chipset to retail first, but also from Intel, who through its heavy influence on the USB Implementers Forum (USB-IF) persuaded the organization to adopt WiMedia's version of MB-OFDM as their officially blessed USB solution for high-speed wireless devices. In February 2004 Intel announced the formation of the Wireless USB (W-USB) Promoter Group, composed of themselves, Agere (now part of Broadcom via the former LSI Logic), Hewlett-Packard, Microsoft, NEC, Philips and Samsung, with an aim for products within the next year. Because the W-USB name clashed with Freescale's initial branding, Intel and the USB-IF eventually settled on CW-USB ("Certified Wireless USB") and the MBOA was merged into the WiMedia Alliance in 2005. Now that the attempt to make an IEEE standard had clearly stalled for good, WiMedia submitted its own specification to Ecma instead, published as ECMA-368, and the 802.15.3a Task Group subsequently disbanded in January 2006.

Both Freescale W-USB (later changed to Cord-Free USB and then Cable-Free USB, both of which we'll call CF-USB for short) and Intel CW-USB conceptually replicate the host-centric nature of USB 2.0, hewing more or less to the same basic topology but obviously without wires. Both systems supported up to 127 devices and necessarily the over-the-air connection was encrypted, both with AES-128. There were of course no compliant devices yet, nor compliant computers, so both competing standards required a dongle on the PC side and offered wireless USB hubs to connect existing peripherals. The main user-facing difference between Cable-Free and Certified Wireless USB was that CF-USB was intentionally, and in this case ironically, much closer to the wired USB spec. In particular, although CF-USB connections could only go point-to-point, just like a single cord — multiple devices could be connected, but they would have to be all on one hub, and additional dongles and hubs would be needed for more — all USB features and transfer types were supported, even isochronous transfers for real-time data. CF-USB also had the compatibility edge in that the other end would look just like a regular USB hub to the computer, so no software update was necessary. CW-USB, on the other hand, although its virtual bus was much more flexible and devices could be hosts to other devices, wasn't fully backwards-compatible with all USB devices and needed new drivers and operating system support.

CW-USB's new approach predictably yielded new bugs, slowing development. As a result, the simpler CF-USB devices did indeed progress faster, most notably Belkin's Cable-Free USB kit and Gefen's Wireless USB Extender which were demonstrated in 2006 at Winter CES and Macworld. These units used both Freescale's UWB radio and Canadian startup Icron's ExtremeUSB extender chipset, another UWB Forum member, presenting a reportedly perfect USB facsimile to the computer. The Belkin device as presented was a typical dongle-hub affair, but the Gefen set used smaller one-to-one transceivers between a computer and a target device, shown to attendees linking a Mac and a digital camera.

And that was it for CF-USB, because just a couple months later Freescale and parent Motorola unexpectedly pulled out of the UWB Forum in April, citing a desire to focus on their own CF-USB products. Neither of these CF-USB devices reached store shelves: Belkin was forced to retool around MB-OFDM after all, and Gefen completely abandoned their units in lieu of a new, non-UWB wireless USB system that I'll come back to later on. Freescale's team eventually suffered management departures and failed to release any future CF-USB hardware, after which the UWB Forum itself imploded in 2007.

In the meantime the hype around CW-USB grew, as shown in this period advertisement. Intel, startup Alereon and Kodak made the first public demonstration of CW-USB at the Intel Developer's Forum in September 2006. Using a USB PC dongle made by Taiwanese OEM Gemtek, exhibitors were shown a PC and a digital camera associating with each other and the PC downloading images from the camera to its desktop, which Intel claimed could run at up to USB 2.0's full 480Mb/s at three metres (110Mb/sec up to 10). One heavily anticipated application was as a docking station you could just walk up to: if you had been previously associated, then boom, you were connected. The bandwidth, Intel promised, would be real and it would be spectacular.

A few months later, Belkin's reworked dongle-hub kit — initially still called "Cable-Free" until Freescale objected — finally emerged for retail sale in 2007. Unfortunately, the chipset switch eliminated Belkin's Mac compatibility and it only came with Windows drivers. Worse, Belkin's hub took it on the chin in various reviews, citing an eighty percent reduction in throughput if the devices were just a foot away, and another 30% on top of that at four feet, with a maximum range of somewhere around six (or one big wall). This probably made it more secure, but definitely not more convenient, and far short of the claimed 10 metre maximum range. It doesn't look like Belkin sold very many.

Another vendor was D-Link, who produced both dongles and hubs along with a starter kit containing one of each. This NOS example, utterly unused in a sealed box, had an original MSRP of about $170 ($225 in 2025 dollars) but showed up on eBay for $12. I couldn't resist picking it up and a couple other cheap CW-USB products to play with, all of which carried the proud and official Certified Wireless USB logo. I made sure one of them was a docking station since that was intended to be the killer app.

In CW-USB parlance for "legacy" wired devices, the computer side is called an HWA (Host Wireless Adapter) and the device side, which could be a hub or an actual device, is called a DWA (Device Wireless Adapter), both of which could be built-in to compliant hardware. What's notable about these packages is that all of them come with an HWA, even though only one of them actually has a DWA hub: the D-Link starter kit (model DUB-9240), consisting of a DUB-2240 4-port DWA USB 2.0 hub and a DUB-1210 HWA. The TRULink #29596 Wireless USB to VGA and Audio Kit has two downstream devices with on-board DWAs, one for a VGA monitor (up to 1600x1200 or 1680x1050) and one for analogue audio, plus its own HWA; the Atlona AT-PCLink Wireless USB DisplayDock offers DVI video, 3.5mm (1/8") audio and two USB ports, officially for your mouse and keyboard. The dock base, interestingly enough, is not a CW-USB device itself: you have to plug a DWA into it (included) which can go in one of two ports depending on physical configuration. In the package Atlona also includes another HWA.

However, since they're all allegedly CW-USB 1.0 compliant, you should be able to use any HWA you want. (Theoretically. That's called "foreshadowing.") The D-Link and TRULink HWAs only support Windows XP SP3 and Vista — there was a short-lived Linux implementation that Intel themselves wrote, but it was very incomplete and eventually removed — and the Atlona HWA does too, but it also claims support for Windows 7 and even Mac OS X (Leopard and Snow Leopard). So our test system will be ...

... my late sister-in-law's black MacBook, the most powerful spec of the A1181 polycarbonate Intel models, a 2.4GHz Penryn Core 2 Duo T8300 running Snow Leopard 10.6.8. We'll use it to run the native Mac drivers as well as the Windows drivers. Unfortunately the optical drive in this laptop is shot and I haven't gotten around to replacing it, and this is one of the models where Boot Camp will not start the installer from an external drive, so we'll be running 64-bit Windows Vista Business — just because it's what I have around, no other particular reason — under VMware Fusion 4. This will limit our testing options a little bit but the native support will still be a good test of performance. (I'll have a note about its PowerPC support a little later, but you can completely forget about it on modern Apple silicon as it relies on forbidden unsigned not-notarized bad-for-ya don't-make-Tim-Cook-cry kernel extensions that will certainly blow up your computer and cause it to sing Virus Alert by Weird Al. Get out your Intel if you want to try this.)

That covers the HWA and the HWA-DWA link, but being "USB" (after a fashion) you also need a driver for the device it's connecting to. Fortunately the TRULink and Atlona video systems are both DisplayLink-based, supporting screen mirroring and spanning, for which (Intel) Mac drivers also exist.

In the D-Link box is the HWA-dongle, the DWA-hub and a power adapter for the DWA (5V, 3A). All three HWAs here are bus-powered. Interestingly, the D-Link DWA-hub has a sticker on the back warning you about insecure wireless access. This is commendable, but CW-USB does not use WEP, WPA or WPA2. (We'll get to something that does later on.) As CW-USB is effectively a network, there are MACs and PHYs, and so the HWA and any DWAs have MAC addresses. You'll also note that D-Link's DWA-hub has a PIN. This is part of the CW-USB association process, which is necessary because obviously you don't want malicious USB devices trying to talk to you, and you don't want your next-door neighbour possibly being able to use your printer or read tax returns on your thumb drive. (I didn't know that was deductable!) The process of association generates a new AES-128 session key and records both 128-bit host and device IDs for future recognition. This shared 384-bit association context remains in effect until explicitly disabled: the associated device now won't interact with HWAs it doesn't know, other than to potentially associate with them also, and the HWA will only talk to devices with which it has been associated. It is possible, and absolutely supported, for a device to be associated with multiple HWAs.

Association in CW-USB can be done one of three ways, either by factory pre-association (the TRULink and Atlona devices come pre-associated with their HWAs, for example), numeric association where the device provides an on-screen code (like Bluetooth pairing) or the PIN on the underside of the device can be manually entered (an alpha-numeric code like D0NTH4CKM3), or, uniquely, by cable association.

Cable association is where you physically connect the CW-USB device to your PC or Mac via USB cable, let it be recognized by the HWA's driver, and then disconnect it. It then continues to act connected, just via the HWA. The D-Link DWA-hub is cable-associated as part of the installation process, or can be associated by PIN; it is the only one of these three that is not pre-associated. All devices support pre-association and some sort of numeric association, but a physical USB port is naturally required for cable association. It is nevertheless the most secure of the three methods, first because you have to have physical custody of both the device and the computer, second because it's a new and unique key, and third because key creation and distribution occurs entirely via the cable and never over the air. Unfortunately it's not possible to blacklist the other association methods, so you'd better not let your neighbour get your PIN. (You pay how much in mortgage interest??) Some devices like the TRUlinks mercifully do support changing it, but that ability didn't seem universal in the devices I looked at.

In this case, all three devices support cable-association. The D-Link hub and the TRULink devices do so via their USB ports, but the Atlona dock does it by plugging the DWA into the computer instead of the docking base itself.

The reverse process is also obviously possible to de-associate a device, and you can outright block devices as well, though this may require some fiddling if they were pre-associated. Similarly, most devices, including this one, have a reset button which will clear the association context(s) stored in them, removing any undesired linkages.

Let's get the D-Link kit installed in the Vista VM.

With the CD inserted, the D-Link splash screen comes up. The HWA appears to have been made by WiQuest. They were possibly the biggest of the WiMedia startups, booting up in Texas in 2003, yet despite their chipsets having an 85% share of the wireless USB market flamed out in 2008 — a pretty damning summation of how not big the wireless USB market ultimately got. A few pieces of WiQuest and their IP are now part of modern Staccato Communications. The installer is very clear that you are not to plug in either the dongle or the hub until installation is complete and the hub has been cable-associated. After the files are written, cable association begins. Here we plug the hub (DWA)'s association port directly into the MacBook with a regular USB cable. VMware will pass this through to the Windows guest. Windows Vista recognizes the hub ... ... and cable association is complete. The Wireless USB Control Center is a fairly simplistic application showing all associated devices and their statuses. As we don't have the dongle-HWA installed yet, the hub-DWA is listed as associated but not connected. The dongles get better reception if they are oriented vertically, so a stiff bendy USB cable is included in the package which you can plug the dongle into. We connect that, which is also passed through to the Vista guest, and its bright orange light illuminates ... ... Vista sets up the new device driver after approximately 83,481 UAC prompts ... ... and the hub is connected. There isn't much else you can do here except deassociate the device, or, if a new device appears in the list, attempt to associate with it. Likewise, the Advanced tab doesn't let you do much more other than change the channels in use. Here, on a United States system, all of the ones we'll explore in this article defaulted to channel 13. As a first test, we'll just plug in a regular old USB thumb drive, the exact same drive we were using to copy things into Vista, so we know it works directly connected. Active ports on the hub glow orange. I expected to see Windows configure the device, but instead we got a very surprising error: Windows couldn't even determine what the device was. I'm prepared to admit this might be the VM. In fact, my first attempt at this was with Virtual PC 7 running the included Windows XP SP3 on the Quad G5, and while Windows XP under VPC7 would associate the hub and see the HWA, the HWA kept stuttering and dropping off the bus, even with the G5's performance cranked up to cheesegrater tornado.

But this wasn't true for all the devices I tried.

For example, I plugged in a iConcepts PDA adapter, which is better understood as a Prolific PL-2303 RS232-to-USB converter, and it was immediately recognized. However, note well: the device is completely unseen by Mac OS and thus by the VMware Fusion host, even though its guest can see it. Although I found it initially surprising that VMware didn't ask me about the device when I connected it, upon reflection it's perfectly logical that wireless USB devices wouldn't be seen at all by the Mac because we've effectively constructed a new and separate USB bus completely outside of it. For all the devices I connected to the hub-DWA, VMware was absolutely unaware of all of them, including the hub itself; the only device the MacBook and therefore VMware saw was the HWA. This is probably good from a performance view though possibly bad from a device control view. After scaring up a signed Vista x86_64 driver for Prolific devices, Windows now sees and installs the device, connected to the wireless hub. And as proof of operation, Prolific's chip tester correctly identifies the chipset on the new COM3: we just installed (the others are provided by VMware). That's good news, because the original task that caused us to embark on all this was getting the Palm smartwatch both networked and mobile. USB Palms emulate a serial port but only appear on the USB bus when there is activity, such as kicking off a HotSync. Notice the only thing connected to the MacBook is the HWA (all ports are on the left side of this model), but with the watch connected to the hub-DWA the Vista VM sees the new USB device appear. For the driver we'll pull out Fossil's Wrist PDA CD. Unfortunately, this is circa 2001, so some of you may already have guessed what's going to happen. The installer runs, and installs Palm Desktop and the HotSync software successfully, buuuuut ... ... because it's an unsigned driver, Windows Vista refuses to load it, and HotSyncing still won't work. I didn't feel like futzing with this more and a regular user would have likely have given up at this point. However, the fact the Prolific did connect and does appear to work suggests this should work on, say, Windows XP.

Let's see if the Atlona AT-PCLink natively in Snow Leopard can do any better. It's time to bring on the docking station.

Opening the box, which was also an NOS unit. The PCLink's dock base has two USB ports and two USB ports. The two USB ports (on the top and front) are for where you want to put the DWA, since if you mount this somewhere you'll still want to keep the DWA vertical for best reception. The two USB ports (on the rear) are for your devices, officially the keyboard and mouse, but other low-speed devices will also work since internally it's just a hub (a wired printer would likely be a common application). The DVI video port and 3.5mm audio port are here too, along with the wallwart power port.

The DWA and HWA are on the left, both based on the Wisair WSR601 single-chip system. Wisair was a 2001 startup enterprise of the Israeli RAD Group specifically oriented around UWB, and as such was one of the earliest chipset designers for CW-USB. Indeed, the revised Belkin wireless hub also reportedly used a WSR601, so it's possible this Mac driver could work with that device too. RAD eventually spun Wisair off but its fortunes foundered along with the rest of the wireless USB ecosystem, and it went into receivership in 2012.

The HWA dongle fits nicely in the MacBook's ports, and the jet black colour matches nicely too. A green LED blinks with activity: no blinking indicates no paired device, and blinking rate generally correlates with throughput. The DWA's twin configurations. Since we were using it on a table, I put the DWA in the top slot instead of the front one. The most recent set of drivers I could get was version 120.36.1.0. No more obviously recent version appeared on Atlona's Wayback copy. I noted with amusement that an old version of the installer was in the Trash, making the .dmg double the size it needed to be. A help alias points to a small HTML-based manual, but the Windows version has a full PDF available on the disc. Installation complete. When we restart, a new menubar icon appears which I can well imagine some users confused with Wi-Fi. It has two arcs and a dot. When all are hollow, no HWA has been detected. Upon plugging in the HWA, the dot at the corner goes solid and the HWA starts hunting for a device in range. Since it comes pre-paired with the dock and the dock was barely six inches away, it didn't have long to wait. Now connected, the rings all go solid, and you are hooked up to the dock base. If we look at the status in the System Profiler, we can see the difference when the dock is connected. With the HWA plugged in, we see the dongle (and a suspicious serial number). With the HWA connected to the dock, however, the driver sets up — as we observed in VMware with Vista — a whole new USB bus of its own, because of course it is, headed by the HWA. While both devices are called a "Wireless HWA Dongle" (you can change this), their USB product IDs differ and this entry is in fact for the DWA.

To my great delight, while installing it on the MacBook I noticed that the installer was Universal (even to 10.2! but that's because it's a BitRock InstallBuilder package) and had a Universal payload, even though Atlona said explicitly it wasn't compatible with PowerPC. I grabbed my great big A1139 17" DLSD PowerBook G4 1.67GHz, the last and mightiest PowerBook which I use as a portable DVD player and Leopard 10.5.8 test system, to see if it would work.

The installer does indeed run. Being BitRock, it's actually Tcl under the hood. Fun fact. And the menubar icon does indeed appear. However, despite the HWA being visible in System Profiler, it's never recognized by the kernel extension and both the menubar icon and the preference pane insist no host is present. I suspect this is endian-related. So here's the uninstaller. That works too. Back on the MacBook, we'll go ahead and install the DisplayLink driver now. This are pretty standard and I used the most recent one I could get from Atlona's Wayback, which was version 1.7. It's a regular Installer package. After a restart, when the Mac gets in range of the dock, the screen flashes like a second monitor has been connected (because, as far as Snow Leopard is concerned, one has been) and a new "virtual monitor" appears. We'll come back to this in a little bit when we talk about performance. For now, let's proceed with our original mission: can we get the Fossil Abacus smartwatch to sync this way? To the best of my knowledge there never was a first-party Palm Desktop that ran natively on Intel. (You can, of course, compile pilot-xfer, but that doesn't give you the rest of the PIM, and Mark/Space's Missing Sync does not run on Mavericks or later.) Fortunately, this is Snow Leopard, so we have O.G. Rosetta. I just installed the version that came on the Fossil CD. Installation and setup all went pretty uneventfully. And here we are in Palm Desktop, which works perfectly under Rosetta. We can just plug the watch's sync cable into the back of the dock ... ... kick off a HotSync from the watch ... ... the HotSync conduit answers ... ... and the sync runs and completes with no errors. Yay! Again, look, Ma: no wires! (From the watch to the MacBook, anyway.) Periodically and possibly coincidentally, the icon started occasionally flashing a "1" in the menu bar during and after the test sync. This seems to indicate other interfering activity on the WiMedia bandgroup in use (we'll get to how we know the bandgroup is 1 in a moment). I didn't notice much slowing when this happened, but a HotSync isn't a particularly high-speed transaction either. Besides the menubar icon, the Atlona driver package also installs a Wireless USB Manager prefpane in System Preferences. (This, too, is Universal and has a PowerPC executable, and it, too, didn't work.) The Wireless USB Dongle appears, which is actually the DWA in the dock, and no other devices. While you can rename them, and even block them, you cannot disassociate the default device. More importantly, there is no option to actually associate or pair a new device. (Remember what I said about foreshadowing?) This restriction appears to be entirely due to the software and isn't unique to the Mac version; the Atlona manual indicates that the Windows version can't associate new devices either, other than possibly another Atlona dock. Officially it can be re-paired with its original DWA and that's it. The Advanced menu, like the D-Link control centre, is mostly for changing radio frequencies. There's no pairing option there ... ... and no other candidate devices are listed, even when I plugged in and turned on the D-Link hub-DWA. I also tried connecting the D-Link hub with a cable to see if it would associate that way, and still nothing happened. You could plug in a hub into the dock itself, I suppose, but you can't add any additional devices directly.

I did search the hard disk to see if I could figure out where the pairing data was stored and maybe forge an entry of my own, and after some digging around I found /System/Library/WUSB/CBA.app/Contents/Resources/DB.plist, which lists associated devices. (The very location of this .plist again suggests it wasn't intended for user modification.) Here is the relevant portion, with keys suppressed:

You can identify the WiMedia bandgroup (1, 3.1GHz to 4.8GHz), the 128-bit host and device IDs, and the 384-bit association context (which includes both IDs) in the key-value pairs. Yes, I could insert another device entry easily enough, but I wouldn't know the AES key the other end is using, so I couldn't compute a valid context.

Since this driver is running natively and we're not paying a VM tax, let's see how well video streaming worked since oodles of cableless bandwidth was just about the entire use case for wireless USB.

Here I've simply mirrored the MacBook to my wife's Samsung secondary monitor. The dock is about a foot from the MacBook, out of frame to the left. The Samsung doesn't support exactly the native resolution of the MacBook which is why it looks squashed, but you can see it correctly detected the model. How well does it perform? A good stress test is high-resolution video, which the manual warns you against because it would be choppy. We don't let manuals tell us what to do in this house. Manuals are suggestions. Manuals can sometimes be wrong. Let's play the Snow Leopard welcome video and prove it wrong. (The Snow Leopard welcome video has audio in a separate file, so this comparison movie has no sound.)

And, well, the manual wasn't wrong. There is a slight but noticeable lag and there are many dropped frames of video on the mirrored side; the best that could be said is it's watchable. Think "playing YouTube videos over Microsoft Teams screen share" and that would be about right.

On the other hand, it does work rather better as a separate monitor you can span to. This was probably its strongest suit, and I could see myself absolutely using it this way were it not for the fact that other things are also too slow. Let's plug that same USB drive in and try copying the 10.6.8 combo installer, which is a 1.09GB file. With the USB thumb drive connected directly to the MacBook, it takes roughly a minute, give or take. (System rebooted between attempts to ensure no caching.) With the AT-PCLink, not so much. Dum de dum. The estimated time warbled a bit even though the laptop wasn't moving, and was about six inches from the dock, but was pretty close to the original estimate; my two tries came in at around 10 minutes or roughly 1.9 megabytes (15 megabits) per second in this very unscientific analysis. That's not even close to the promised maximum speed, let alone USB 2.0 directly connected. No wonder these things didn't fly off the shelves.

That said, in my testing the effective range came out better than I thought, even though it remained far short of the promise; it still maintained a connection even around the corner through a couple walls about 10 feet away. Speeds started suffering but it did generally work. When I got down the hall from it, though, the link was lost. It recovered pretty well from this when I moved back into range, considering, but if you stay out of range too long then the Mac may think the devices are gone which is not something you want happening with mounted filesystems.

I'm not going to say much about the TRUlink package here except that it also has its own HWA, but unlike Atlona's, its driver lets it associate with other devices and this is supported and documented in the manual. However, I can't tell what chipset it has; the System Profiler identifies it as a "Cables To Go HWA" with vendor $10aa (Cables To Go, TRUlink being their brand) and product $0001. Regardless, the Atlona Mac driver will not talk to it. I think their HWA is more professional looking with the screw-on antenna, but that also makes it a bit bulkier than Atlona's HWA, and it only does screen and audio sharing with no USB hub functionality at all — if you want that, you'll have to go get one separately. A nice touch are the PIN association labels and the ability to change them, though the supported PINs are only four digits (cue Spaceballs luggage joke) and the change tool doesn't work in Vista 64-bit.

Were there alternatives to CW-USB other than CF-USB? Surprisingly, at least one, which was sold by two companies. You'll remember I mentioned that when Freescale bailed out on CF-USB Gefen bailed out too, but unlike Belkin Gefen exited UWB completely. Instead, when released in 2007 the revised Gefen Wireless USB Extender, now branded the Gefen Wireless USB 2.0 Extender, used a much more familiar wireless transport: 802.11g. Yup — it's USB over Wi-Fi.

Completely dispensing with the device-to-device single port original, the 2.0 version was totally redesigned and, with a four-port hub instead, bigger. In a functional sense the new Gefen is yet another dongle-hub kit, except the "dongle" (which Gefen calls the "sender") is the same size as the hub (which Gefen calls the "receiver"), and both also require their own individual power supplies — you'd only have a net reduction in the cables on your desk by moving nearly everything to the receiver. On the other hand, the build quality is excellent and the metal cases are as tough and rugged as its $400 MSRP (about $600 in 2025 dollars). The Gefen kit, however, is actually a rebadge — of Icron's second attempt at the market, the same Canadian company that created the ExtremeUSB chipset for the doomed original CF-USB units. After the UWB Forum cratered, Icron looked for another wireless option to pair with their chips and found it in 802.11g, creating the Icron WiRanger extender in 2007 which they themselves also sold at retail and licensed to Gefen. Even the physical layout, ports and LEDs are exactly the same; only the case and labels differ, though the Gefen-badged version seems to be more common. Icron calls the sender the LEX ("Local EXtender") and the receiver the REX ("Remote EXtender"). Interestingly, the WiRanger is badged as a "Cable Free USB 2.0 Hub" — no dash, mind you — despite not actually being real Slim Shady Cable-Free USB.

In some ways the new system was less functional than the CF-USB prototype, in some ways more. It remained OS-agnostic and required no new drivers, simply appearing as a regular USB hub to the computer the sender is connected to. Being 802.11g, however, you're still limited to 54 Mbit/sec and indeed half the minimum 110 Mbit/sec claimed by CF-USB, so you might wonder how it can support the full 480 Mbit/s of USB 2.0. The answer is, it doesn't — you get 54 Mbit/s, which all fourteen potentially connected devices must share, and what can't be buffered or retransmitted gets dropped on the ground. Gefen's and Icron's documentation differ on what's not supported — Gefen says no isochronous transfers, Icron says no bulk transfers, and I tend to believe Icron because it's their hardware — but both are clear that high-bandwidth devices like UVC webcams are going to have a bad time: "Icron Technologies Corporation does not guarantee that all USB devices are compatible with the WiRanger and only recommends the product be used with keyboard, mouse, and some flash drives."

Unlike CW-USB's association mating ritual, these devices ship paired, or they can be paired in the field by pointing their IR windows at each other to generate a new shared key. The code stays internal to the devices, so you don't have to junk them if someone got your PIN. (You thought your A/C qualified for a tax credit?) Unfortunately, the encryption is limited to achingly insecure 64-bit WEP despite the fact pretty much any 802.11g radio would have supported at least WPA. It can be placed on other 2.4GHz channels to avoid interference and has much better range than the CW-USB transceivers did (about 100 feet), but in this case that would be a minus because now a wardriver could potentially crack into your device traffic and — worse than your nosy neighbour — remotely fuzz your USB stack at will. Fun, huh? For this go-around, we're going to hook it up to the 15" 1.25GHz iMac G4 running Tiger 10.4.11 hulking near the kitchen. This is the machine I usually do my Palm OS work on since all my old build tools are on it and it's near the Belkin Bluetooth PAN that some of my devices use. Here's the base USB tree before everything comes up. When the receiver and sender are in range of each other, they will automatically link. This can take up to thirty seconds according to the manual, but here it took about ten. At that point, a new hub appears, like any other USB hub. That's all there is to it.

I wanted to do some performance tests with it, but strangely macOS Sequoia will not recognize the sender when connected to my M1 MacBook Air, even though it worked fine connected to the Raptor POWER9 in Fedora 41 and was seen as a hub there too. So we'll do the tests on the MacBook as well, which also had no problem seeing and using the pair. Again, we'll just copy that same 1.09GB combo installer and see how long it takes.

Because it's a 54Mbit/s radio, I was prepared to see it take substantially longer than the Atlona, but it came up with an 11-minute estimate ... ... and took 11 minutes with the sender about three feet away from the receiver. That's not much slower than the Atlona, which supposedly could do the full 480Mbit/s at that short distance yet here it never did. Let's try the watch now. Kicking off a HotSync with the watch connected to the receiver. Here we're using pilot-xfer from the command line instead of Palm Desktop. This isn't particularly fast, even at close range. It transfered 1777K in 132 seconds, i.e., 13.46KB/sec (107.68Kbit/sec). Compared to a wired sync it's about ten times slower, and transmission tended to be rather bursty. Still, it completed successfully. So let's try for the brass ring and have the watch completely networked through the iMac, since it's already set up to provide PPP-over-USB to a connected device. We'll use the trusty USB-TCP Bridge here, with its code modified for the Fossil's product and vendor IDs, though you could also use Slirp or usb2ppp. I'm able to trigger PPP from the watch in the other room and surf Gopherspace from the watch, just as before. It actually doesn't feel much different in terms of speed from a direct connect and I didn't find it particularly unstable. Of what we've explored here, the Gefen box seems the least complicated solution, though the receiver pulled a bit more battery power and of course you'd need a host around to connect through. As such I'm still using the "Raspberry Pi in a camera bag" notion for the time being, but it's nice to see it can work other ways.

My experience with the Gefen/Icron extender was generally consistent with other reviews that found it adequate for undemanding tasks like printing. However, it doesn't look like either Icron or Gefen sold many of them, likely due to their unattractive price tag. Icron did announce plans for a much faster wireless USB solution on the 60GHz band using 802.11ad, which with its 7 Gbit/s capacity would easily handle USB 2.0 and even 5 Gbit/s 3.0, but it doesn't seem like the device was ever offered for sale. Although Icron still sells extenders, now as a division of Analog Devices, all of their current products are wired-only.

As for CW-USB, by 2008 few laptops on the market offered the feature, and even for those that did like the Lenovo ThinkPad X200, it was always an extra option. That meant most computers that wanted to connect to a CW-USB device still needed a HWA-dongle, so they still took up a port, and HWAs never got produced in enough numbers to be cheap. On top of that, it further didn't help matters that anything close to the promised maximum bandwidth was hardly ever observed in real-world situations. Device makers, meanwhile, mostly chose to wait out greater availability of CW-USB capable computers, and since that never happened, neither a large number of computers with built-in CW-USB nor CW-USB devices were ever made before the standard was abandoned.

The last stand of UWB as a device interconnect was ironically as a proposal for Bluetooth 3.0+HS, the 2009 optional high-data-rate specification. 3.0+HS introduced AMP (Alternative MAC/PHY) as a bolt-on method, in which low-speed Bluetooth would be used to set up a link and then the high-speed data exchange would occur over the second transport, originally MB-OFDM. With CW-USB fading from the market, however, the WiMedia Alliance closed its doors in 2009 and shed its existing work to the USB-IF, the W-USB Promoter Group and the Bluetooth SIG. This move was controversial with some WiMedia members, who consequently refused to grant access to their intellectual property to the new successor groups, and instead AMP ended up being based on 802.11 as well. The AMP extension was little used and eventually removed in Bluetooth 5.3.

Is there a moral to this story? I'm not quite certain. As so often happens, the best technology didn't win; in my eyes CF-USB had the potential for being more widely adopted because of its simplicity and compatibility, but was ruined when Freescale got greedy and it never recovered. That said, the real question is whether wireless USB itself, with all of its broken promises, was the right approach for the WPAN concept. It's certainly not an indictment of ultra wide-band, which is used today more than ever before: many chips are still produced that implement it, the best known undoubtedly being Apple's U1 and U2 chips in iOS and iOS-adjacent devices like the AirTag, and such chips continue to be widely used for things such as precise location fixing and local interactions. UWB has also been used for diverse tasks like tracking NFL players during games or parts during factory assembly, and for autonomous vehicles in particular it's extremely useful.

However, the use of UWB for high-bandwidth applications has yet to return, and probably the biggest reason is because Bluetooth and Wi-Fi now exceed any throughput and ease-of-use promises made by available UWB silicon. Heck, almost all the pictures in this article were pushed from my Pixel 7 Pro to the M1 MacBook Air via Quick Share, in a way not unlike AMP: Bluetooth is used to identify nearby devices on the same Wi-Fi network, and, if available, Wi-Fi is used to push the data. AirDrop, too, by using Bluetooth to create a peer-to-peer Wi-Fi link. Printers speak Wi-Fi now and so do many cameras, scanners and multi-function office devices, and low bandwidth HIDs like most of today's wireless keyboards, mice or game controllers can all connect with Bluetooth. It turns out that the promise of the WPAN came true after all, slowly and gradually through the evolution of existing technologies, without wireless USB — and we just never noticed.

Maybe that's the moral.