Cambridge Consultants discovered a better way to develop complex DSP systems when it re-engineered the Iridium satellite phone handsets.
The Iridium satellite communications system has had a chequered history. Conceived when it was still unclear whether cellular telephony would take off, by the time its constellation of low-earth-orbiting satellites was in place, the popularity of mobile phones was growing and Iridium's potential market was shrinking.
The constellation is complex, too. Some 66 satellites (plus a few spares) orbit at 17,000 mph to weave a net of transceivers overhead that can connect handsets anywhere on the planet to the telephone network. The satellites are moving so fast that each is only overhead for eight to ten minutes at a time, with calls being forwarded from one to the next 'like pass-the-parcel on the Wall of Death', as one observer put it.
'It's like sitting in a jet at Mach Four trying to use a cellphone,' said another. 'Things are moving so fast that special and general relativity come into play.'
No amount of special relativity could make Iridium's finances work, though, and the original venture went bankrupt, leaving a network of satellites in orbit, a set of assets on the ground, and a customer base. What it no longer had was a technology partner Motorola, who had developed large parts of the Iridium system, separated from the venture during its refinancing. This was fine, until the handsets and spares started running out.
Enter Cambridge Consultants,with a brief to ensure that the new business would have kit to sell to new customers as well as spares for existing customers as it grew. The trouble was, they didn't have much data to go on. Because the Iridium network was seen as a strategic asset by the US Department of Defense, much of the design information wasn't available, so the team spent three months reverse-engineering the existing handset and specifications, certain only that whatever they developed would have to work with the Iridium satellites' existing interface protocols.
According to Richard Traherne, head of wireless and commercial director at Cambridge Consultants, the specifications of the original handset had evolved during its development, with little documentation. The handset also contained custom analogue parts, made by Motorola, for which the team had to find replacements.
The team also decided to recreate the handset as a software-defined radio, in which the function of some of the original parts could be taken over by algorithms running on processors.
Monty Barlow, the team group leader in the wireless division of Cambridge Consultants, says the move to a software-defined radio architecture meant that the re-engineered handset could also be used as a platform from which other variants could rapidly be derived.
The re-engineered handsets problem
'We ended up with a software architecture where we could easily disable parts, such as voice, for power-consumption reasons,' says Barlow. This would enable the team to develop, for example, a lower-power dedicated Iridium data modem.
But there were challenges. The handset ran on a Motorola proprietary operating system, which had to be replaced. And the protocol stack, which negotiates the connection between handset and satellite, had to be ported to a new architecture largely whole, for fear of losing the optimisations that had been coded into it over time.
'That's one of the problems of the [re-engineered] handset,' says Barlow. 'Nearly all its code was written in assembly and nearly all of it was hand fiddled with. Plus we had to engineer quality into the code base to allow its portability.'
The upshot of Cambridge Consultants' work was that it was able to re-engineer the original handset and get it into production within 14 months quickly enough for Iridium to avoid supply problems. This was important because early in the life of the new Iridium organisation it had been making a third of its money from selling handsets and modems.
'We got to the point where they were selling equipment at a profit,' says Richard Davies, technology director of Cambridge Consultants' wireless business unit. 'I feel we made a huge impact on their business case.'
It was a change in Iridium's business model that drove Cambridge Consultants's next challenge.
'Iridium is a fixed-cost business with spare capacity,' says Traherne, so the idea was to build a transceiver offering a reasonable data-rate connection from anywhere on the planet, which other equipment makers could then include in their equipment. 'This should help to create an infrastructure of partners working with Iridium to build Iridium access into their products.'
The challenge was that, although the raw data rate of an Iridium channel is only 2.4kbit/s, the company wanted to enter the market with a 128kbit/s service that would be suitable for use on ships.
'Many people within Iridium said it was a nice idea but that the system couldn't do that, but the CEO hung on to the idea,' says Traherne.
According to Davies, the challenge was that the new data modem had to work with existing satellites that divide time and frequency in a fixed way, as well as fitting a power budget, meeting regulatory requirements and being economic.
According to Barlow, the original handsets had run their core algorithms in a 150MIPS, 16bit fixed-point DSP chip, running flat out to maintain a single session. Creating a 128kbit/s connection would mean maintaining 64 links at once, using 16 adjacent channels and over-sampling to get a reasonably robust bandwidth.
'The silly way to have done this would have been to multiply up what we had before by 64,' says Barlow. 'We probably could have done this on a 3GHz TI DSP part designed for cellular base stations, but then our solution would need fans,' which would have been problematic for equipment being used in a maritime environment.
Instead, the team decided to use a Picochip processor, which consists of an array of 16bit fixed-point processors and a programmable interconnection fabric, to run the key algorithms.
According to Barlow, the useful thing about the Picochip approach is that it enables design managers to partition a large project, knowing that the resources demanded by one part of the project won't affect another. With the Picochip array, each of the key radio functions could be allocated an individual processor, so the team developing that function would need only worry about working within those resources. This contrasts with trying to build similar functions as routines running on a single large DSP, where you might have to contend with resource scheduling and interrupt handling.
'If you try to do it at very high frequency in a DSP it is difficult,' says Barlow. 'It's really hairy to [work with] base stations moving at five miles per second relative to you.
'The Picochip approach allows you to write software with defined intercommunications,plus you can also make modules of modules. It also removes the idea of interrupts, to ensure determinism. In classic DSP, the whole concept is to try to avoid interrupts and schedule work. The fact that it has no interrupts means you get rid of all that pain.'
There are other advantages.
'Because of the Picochip approach we can add in pretty good diagnostics. We added a video diagnostics port at no hardware cost by programming one of the Picochip cores to drive video to the edge of the board at 40MHz. This enabled us to work through all the nuances of the system in real time. For example, as boats roll you need to switch between the 13 beams on our patch antenna array. Every minute you have to change to a different beam on a satellite to track it, and every five minutes you have to switch to a new satellite. In real time you can visualise stuff, and this enables teams of people with different perspectives to look at the problem at the same time. It's revolutionary.'
Barlow is also a fan of Picochip's cycle-accurate simulator, which means that the algorithms his colleagues test in a software environment will work exactly the same way when run on the hardware.
'With Picochip we have never seen a deviation between the simulator and reality to date,' he says. 'We have no defects in our digital signal processing beyond the simulation stage. The simulator was precisely the same as reality over millions and millions of cycles.'
For program managers, this is a huge relief, since it means that a key part of the system design can be relied on to work as predicted during the integration phase.
According to Traherne 'From the program point of view it's like magic. DSP is key to us and to have a design methodology that is deterministic derisks the project.'
The end result of Cambridge Consultants' efforts has been a 128kbit/s maritime transceiver, which incorporates 13 patch antennas, the RF circuitry and DSP in a single weathertight dome that can be mounted at the top of a ship's mast and only needs power and an Ethernet cable to start delivering data: all the smarts are in the dome.
As Davies says, that's quite a lot of smarts, given that the dome is likely to be pitching and rolling and the satellites are moving overhead extremely quickly.
'It's a bit like clay pigeon shooting. You've got to aim where you think the signal will be.