Tao of Mac

Apr 24th 2006 · 4 min read

Universally Late

Yes, yes, we all know about the 17" . Despite Melo's lust, I feel no urge to buy a 3000 Euro breakfast tray, so I'll write about something else.

I've been spending some of my off-work time dealing with HSDPA devices, and think it's about time I jotted down a few generic notes regarding that.

As regular readers may be aware, there is plenty of information on how to get all sorts of Bluetooth, and PCMCIA modems working with , and most of them have mostly been variations on the theme of high-speed serial ports.

As we move to HSDPA and EV-DO speeds, however, the serial port paradigm starts getting a little brittle, since the chip-sets themselves have moved on and are now starting to sprout ailerons, go-faster stripes and all sorts of enhancements at the logic glue level that make it a bit (or rather, a lot) pointless to go to all the trouble of making the computer think there is such an anachronic thing as a baud rate setting involved.

What I've been seeing over the past few months are a number of HSDPA devices that (in one way or another) present themselves as a multi-function device with a plethora of data ports, except that the interesting ones aren't really serial anymore.

Now, if you've ever written NDIS drivers (and I did quite a bit of testing and debugging of those way back), you have a good idea of where this is going - device and driver combinations are starting to appear that make those high-speed ports look like a frame-based (i.e., Ethernet) interface at the OS level.

This is very nice for Windows users, and nearly as good for developers, since there are plenty of examples out there of how to write NDIS drivers - over a decade of Windows hardware development and the recent Wi-Fi and bonanzas have ensured these are valid, marketable skills, and there are entire companies specializing in providing skeleton drivers (some of which have tight relationships with chip-set vendors).

Interestingly enough, some of those drivers are hybrids, sporting a frame-based interface for data and a modem-like interface for device setup and connection establishment - and this is especially necessary for mobile devices, where there is more than a passing interest in obtaining information such as network status, signal levels and effective throughput (none of which are completely supported by the NDIS spec, although there is partial support for some of them and some quite creative approaches out there).

But although things are relatively stable on the Windows platform, the new emphasis on mobile connectivity hasn't yet made it completely through to the and universes - although there are kernel drivers available for some HSDPA cards, they are still essentially one-offs building upon previous drivers or, again, hybrid drivers that expose a serial port and an Ethernet-like interface to the OS.

My first point regarding this is that although this approach works - and is likely to work for a while yet - there might be a need for a new, Wi-Fi-like driver model with support for the peculiarities of the mobile WAN environment (like real roaming, SIM control, etc., etc.) without having to go through all the AT Commands' usual kludges.

However, given the fact that developers (and especially kernel developers) are likely to look for stability and common, well-known ways to go about implementing networking, we're likely to be stuck with the hybrid serial-Ethernet approach for some time.

There is a second point, though. Without some sort of unified driver model (or a straightforward way to transpose the NDIS model to ), porting this kind of driver from either Windows or to is going to be a pain, and the need to fundamentally re-write the drivers (as well as testing them as Universal binaries) is likely to make it rather painful for early adopters of these newfangled mobile technologies to use them in for a while yet.

For instance, the current crop of HSDPA cards all register as multi-purpose devices in - and that's when all the device ports are active upon device power-up.

Now, isn't exactly brimming with generic -to-serial drivers, so most of the time (unless you're exceedingly lucky) you can't even get at the control interface for the card - and, of course, the data portion requires a specific frame-oriented driver that someone has to write specifically for the card, because despite the shim, all cards are slightly different.

Throw in the need for Intel and PowerPC testing of either aspect of the driver, as well as the very real fact that users are still thin on the ground (despite their purchasing power and revenue potential for mobile operators), and you soon realize this is a niche in terms of potential market, required know-how and development skill sets.

Now consider that has (quite rightfully, in my honest opinion) decided to drop PCMCIA and go the ExpressCard route (which makes a lot of sense for real bus-intensive operations like media editing), and you'll be aware of at least half of the issues involved.

Despite this rather bleak picture, I'm optimistic about HSDPA and EV-DO support in - provided vendors can get decent reference drivers out the door, someone (if not the vendor or the operator, at least a specialized third party) will be able to get some of these broadband WAN devices working in , and, at least here in Europe, there will be no need for users to hop around from a Wi-Fi pinhead to another.

There are already some examples of this out there (and this is where my kicks in), but support for mobile broadband will, without a doubt, be late in more than a few instances when compared to Windows support - so we'll have to be patient for a while, and pick our options carefully.

This page is referenced in: