Developers

Watch the Skies

Martyn Davies — Tue, 23 Feb 2010 09:36:06 GMT

My travels took me recently to Jodrell Bank, one of the World’s first radio telescopes. The 76m dish (which can be seen from 30km away) is a famous landmark in the UK, bound-up with the Space Race and often used in TV programmes (fictional and non-fictional) related to science.

The Manchester University astronomers picked this site because the electric trams of the city caused too much interference to their experiments. Today also it is a “quiet zone” and Jodrell Bank visitors are encouraged to power-off their mobiles. In any case, the mobile coverage is poor; presumably because the cellcos have agreed not to come too close with their cell towers anyway.

One story that I hadn’t heard before was about Luna 9, the unmanned probe sent to the moon in 1966 by the USSR. The scientists at Jodrell Bank pointed the telescope at Luna 9 and managed to record some of its transmissions. Thinking that the stream sounded a bit like a fax, they quickly borrowed a fax machine (fax was an exotic and rare technology then) and rigged it up so that they could play the Luna message into the fax machine. To everyone’s surprise, what came out was a close-up photograph of the moon, which was subsequently published in the UK newspapers, and all over the world.

If you read my last blog, you’ll know that I was an enthusiast for the FORTH language years ago when I was a student. Interestingly, the FORTH language was written by Charles H. Moore, who needed a portable programming language for controlling radio telescopes. I wonder if there is any FORTH code running there still at Jodrell Bank?

Vintage Computing and Gaming

Martyn Davies — Tue, 26 Jan 2010 14:45:00 GMT

This is my first post of 2010 on the Developer blog, so let me first wish you all a Happy New Year!

At the end of 2009 I had the opportunity to enjoy some computer industry nostalgia. My first computer was the Jupiter ACE, a machine made by Jupiter Cantab Ltd., one of perhaps 15 UK companies at that time trying to build and market computers. It was a machine inspired by the Sinclair computers, but was different in that it used a language called FORTH. Most machines at the time were either programmed in some form of BASIC, or directly in machine code. FORTH was designed originally as an operating system for radio telescopes, and has some very interesting characteristics. I loved FORTH and I loved my Jupiter ACE.

As it turns out I was not the only one to love my ACE. If you look at the Jupiter ACE Resource Site (http://www.jupiter-ace.co.uk) you will see that a small team of enthusiasts are trying to save every detail of the hardware and software that they still can. As it happened, I still have some Jupiter ACE software on cassette tape, and the good people at the Jupiter ACE Resource Site were able to read the information in from the tape (which was 20+ years old) and recover the software.

The result is that they were able to resurrect a game called “Snake” that I wrote at the time. In a rather interesting juxtaposition of old and new technology, you are now able to use YouTube to see what my game looked like. Take a look here:

http://www.youtube.com/watch?v=cSH8mZ72Ud0

Obviously the technology looks very crude compared to today’s games like the Xbox, but I’m pleased to have my small contribution to games recorded in history.

Focus on the Developer

Martyn Davies — Wed, 09 Dec 2009 10:53:19 GMT

These are trying times for the industry, as in most of the world we fight back against the recession. I’m heartened, however, by signs of companies investing in their developer programmes, and reaching out to the software development community.

Mobile is still an area of frenetic activity. Most famous, I suppose, is Apple and the iPhone. A runaway success since its launch, the iPhone has frightened the handset manufacturers, galvanized mobile app developers and excited the cellcos. The iPhone SDK and developer programme is, in my view, a brilliant lesson to us all in how to execute a programme to get meet the needs of software developers.

Also in the mobile SDK area we see Android making good progress at recruiting software partners, and attracting handset partners. Google’s Android Developer Challenge attracted a lot of new apps and created excitement. Symbian also refocused on open source, and are making headway in their own reserved, British way. Developer programmes in the mobile carriers, like Orange and Vodafone are also great areas of activity. Vodafone have been talking about mobile “widgets” for a while, i.e. self-contained web apps (using Javascript and CSS) that can run on a mobile phone. Samsung have also been trying to stir up interest in widgets with their own developer challenge for the Omnia. Equipment and software vendors are also building their developer outreach. Just in the last few days we’ve had announcements from Syntellect (reaching out to CT-ADE developers), and Ericsson (reaching out to web developers).

As equipment providers ourselves at Dialogic, we understand the importance of developers and our APIs in creating opportunities for our product. We recently ran our own innovator challenge for developers, and if you’re interested in the results, you can see them here:

http://www.dialogic.com/press/press_releases/pr-2009-1023-innovatoraward.htm

We’re going to run another developer challenge in 2010. If you’ve got any ideas about how that should look, or how we could better help you develop for Dialogic platforms, we’d be happy to hear your comments.

The Birth of Wireless

Martyn Davies — Wed, 11 Nov 2009 23:52:25 GMT

I was recently with our service provider division in Hyannis, and had a little bit of time for some sightseeing on the Cape Cod coast. I didn’t know this before I arrived, but Cape Cod was one of the first places on Earth to have a wireless transmitter station. In 1903, Italian inventor Guglielmo Marconi established wireless stations at Wellfleet, MA, USA; Cape Race, Nova Scotia, Canada; and Poldhu, Cornwall, UK. So I stood on the site of the Wellfleet wireless station, which sent the first ever transatlantic wireless message, which was an exchange of greetings between President Roosevelt and King Edward VII, sent of course in Morse Code.

This marked the start of a new era of communication, since transatlantic communications had already been possible (via undersea cables) for perhaps 20 years before that point. But of course wireless meant also that ship-to-shore communication was possible, as well as between fixed sites. Interestingly, these wireless stations are part of the RMS Titanic tragedy in 1912, since the ship was in contact with Cape Race in the hours before it struck the iceberg and sank. Radio was then an innovation on ships, and was very much used for routing messages from the passengers. The sinking of the Titanic was one of the events that helped people to see that there was a safety aspect to radio systems also.

Now of course we take these wireless links for granted, and when I switch on my mobile phone in Cape Cod, there is a rapid transatlantic exchange of messages with my cellco’s Home Location Register that authorizes my phone to work in the USA. It’s transparent to us, and we never think about it anymore.

The Marconi station closed in 1920 (by which time many commercial wireless services existed), and today it has quite literally fallen into the sea, but there are some small pieces of evidence there of the birth of the wireless industry. I like to think that the innovation started at Wellfleet is still going strong in Cape Cod and in Dialogic. Looking out across the blue Atlantic, it felt anyhow like there was some kind of connection across the century.

SMS Telemetry

Martyn Davies — Mon, 19 Oct 2009 10:47:52 GMT

Last week I stumbled across an inexpensive electronics kit that allows SMS messages to monitor and/or control things in the home. This board has 8 control outputs and 4 monitoring inputs, and is designed to link to a cheap Nokia phone handset via a serial cable. I imagine that the phone, cable and SMS board could be bought for under $50. Add to this a prepay SIM card, and for a minimal spend, you have a system that can be programmed to respond to a range of commands sent via text message.

Given that people increasingly have electronic systems in the house that record information to computers, it would be possible to link these systems to SMS to be able to remotely control and monitor a whole variety of systems. For example, one friend of mine has an electronic weather station at home, so imagine being able to check via SMS if it is raining there. Another friend has a system that measures the power usage in the home; for him it might be interesting to be able to send a text and get a response back giving the current power usage? Perhaps from this information he could also conclude whether other members of the family are at home?

These kinds of telemetry system were just science fiction when I was a teenager interested in electronics, and even ten years ago they would have been expensive enough to limit their use to mission-critical industrial use. However, with the falling costs of prepay and SMS, coupled with the falling cost of electronics and computer systems, we can expect that these applications will become all too common in the coming years. The cellcos themselves are expecting that demand for 3G/GSM SIM cards will continue to grow in the coming years, not just for humans (who increasingly will have more than one phone), but also for robotic or automated systems that need a phone number for applications like remote control.

Come to eComm !

Martyn Davies — Wed, 07 Oct 2009 10:42:47 GMT

I'm very honoured to have been chosen again as a speaker at the eComm conference in Amsterdam later this month. eComm is a unique gathering of entrepreneurs, thinkers, internet and telecom industry experts who come together to talk about the future of communication. This is the first time the conference has run in Europe, so a great opportunity to take part without travelling to the opposite side of the world. There's still time to register, so please come along and join us!

Spinning Plates

Martyn Davies — Tue, 06 Oct 2009 15:12:59 GMT

We tend to take multi-tasking applications for granted these days, as the tools and APIs for developers have really become very user-friendly. In fact even the term "multi-tasking" has been absorbed into mainstream business jargon, because it's so much understood that not just machines, but people also need to be able to execute many tasks at the same time.

I was reflecting this week on a system I worked on years ago where the “multi-tasking” was actually provided by the application programmers themselves. The system had a 64kbyte space that you could swap a small code overlay into. This is not a typo: 64 kilobytes, rather than megabytes. If your app exceeded 64k, then you had to split it into multiple overlays which would be swapped in and out of the same space one at a time.

The most difficult part was that you absolutely could not block, or delay in your overlay at any time, otherwise the system would hang. The concurrency (or I should say apparent concurrency) depended on each application running in a few hundreds of milliseconds and then quitting again, leaving the space free for another user task.

Now modern operating systems like Linux and Windows manage tasks for you, by automatically pre-empting apps in order to share the CPU and other resources fairly. You could say at the time (in the 1980’s) that operating systems were not that sophisticated, at least not in desktop computers. UNIX existed then, but had yet to become popular outside of universities. Back then only minicomputers (like VAX) and mainframes (like the IBM System/370) had fully preemptive multitasking.

Through the 90’s I worked with UNIX operating systems that brought more convenience with multi-processing, so you could use the ‘fork()’ command to make an identical copy of your process, and therefore create sub-processes, each in their own safe address space. Later on Windows popularized ‘threading’, or lightweight processes, which were adopted in Linux/UNIX and now even on embedded systems like phones.

In some ways threading brings back a little of the “danger” of those early times. Threads all share a single address space, so it’s possible for one thread to corrupt the memory and spoil the environment for all of the co-operating tasks. The tradeoff is that threads are much lighter (both the CPU and memory usage) for the system to manage, so you can have many more of them in a single server.

Making threads communicate safely, and rendezvous with each other safely still requires care and skill from the software engineer, but in a lot of ways our development environments are really a very comfortable environment compared with those of twenty years ago.

Crash and Call

Martyn Davies — Fri, 11 Sep 2009 07:53:49 GMT

I saw that the GSMA are backing an initiative called eCall, which aims to put a device into cars that can automatically contact the emergency services in a crash, and tell them your position, direction and vehicle identification in order to speed-up emergency response. This is part of a wider umbrella of technologies now referred to as Machine-to-Machine (or M2M), that communicate some kind of telemetry automatically over a network, to a central computer.

In many developed countries, penetration of mobile phones is now exceeding 100%, not only because people often have more than one phone (for example work phone; personal phone), but because increasingly machines themselves have a phone number; a mobile terminal; a SIM identity. To give some examples: high-end cars have for some years used locator devices that can report the position of the vehicle (In some cases the insurers require such a device to be fitted because the risk of theft is high and the recovery percentage low). GSM modules are now cheap to buy (and thanks to the prepaid revolution, cheap to run), and can be used in applications like remote video surveillance, or simply triggering an alarm via SMS. The same modules can be used for other straightforward telemetry applications like regular weather reporting from inaccessible locations, or for measuring domestic gas or electricity usage without the need for a man-and-van operation reading meters. As the price of wireless modules continues to fall, we can expect a lot more of these M2M services to emerge. This is of course great news for telcos, who can expect ‘mobile phone’ penetration to reach 200% and beyond.

As for eCall, I think it’s an interesting application but devices reporting your location stir up a lot of strong emotions. Many people resent nearly any new safety measure applied to vehicles, so perhaps this is a “double whammy”. Automated speed cameras are still highly controversial. Truck drivers fought against the tacograph (that measures how long they drive in a day), dubbed “The Spy in the Cab”. In various countries there has been resistance to the compulsory wearing of seatbelts in cars (still very strong in the United States), and resistance to the prohibition of using hand-held phones while driving. The GSMA can expect vocal resistance to their project, even though its aims are laudable.

Combining Video and SMS

Martyn Davies — Fri, 21 Aug 2009 16:39:12 GMT

This week I was reading a newsletter sent around by Kirusa, who are business partners with Dialogic. The newsletter talks about Voice SMS, which is a service that Kirusa are enabling for some telcos now. It's worth explaining what this service is, as it builds on regular SMS to create a whole new service, including video technology from Dialogic.

The basic idea is that instead of making a voice call, you make a video call (to their recipient's number but with an extra '*' at the start). The service intercepts the call and connects you to a video server that allows you to record a video message using the camera on your 3G handset. Once you're happy with the message, you hang-up, and the service sends an SMS to the recipient, giving a special link number for them to call. When they call that link (another video call), they can view the video message that has been left. So it's a kind of store-and-forward video-mail application, linked into SMS for ease-of-use.

There are a number of ways that you could implement this service with Dialogic products, but in fact the route Kirusa chose is to use the Vision gateway, which provides the 3G video magic, transforming the video stream into IP/RTP so that next-gen media server platforms can manipulate the audio and video.

SMS has proved to be a great money-spinner for the telcos; a simple idea, but able to be used as a building block to provide messaging (very importantly with billing attached) in all kinds of different service models.

Movies on Your Handset

Martyn Davies — Wed, 19 Aug 2009 16:24:39 GMT

3G services may be lagging behind in the USA, but efforts to get video to the handset still carry on apace. Video rental giant Blockbuster have just announced a deal allowing Motorola handset users to view movies on their phones. I'm not sure what technology they are using, as it seems to require a special application that comes pre-installed on the handset, but it is an interesting move.

Blockbuster have changed their business substantially in recent years, moving from store-based DVD rental into a postal service (ordering DVDs online), and even a web-viewing portal, so for a smaller fee you can watch on demand on your PC screen. It makes sense for them to also address the smaller screen that we all carry around in our pockets.

For myself, I think my eyesight is these days too poor for watching 2-hour movies on such a tiny screen, but I know this will find an audience in a much younger age group. Convenience and personalization is what mobile technology is about.

Sysinternals Lives On

Martyn Davies — Wed, 29 Jul 2009 12:24:27 GMT

One of Microsoft's more brilliant ideas in recent years was to hire Mark Russinovich and absorb his Sysinternals company into Microsoft. Mark still maintains an interesting blog about the internals of Windows at Technet, and is a now Technical Fellow at Microsoft. When I first heard about Microsoft buying Sysinternals, I must admit that my heart sank, but MS have preserved the legacy of the company, and many of the useful tools the company provided are still available today. In particular, a great utility called DebugView is one that I have probably been using for 10 years.

If you are a Windows developer and haven't used DebugView, then you really ought to get to know it. DebugView intercepts messages generated by applications using API calls like OutputDebugString and displays them in real-time in a scrolling display window. I know that some debuggers also do the same, but DebugView is a small self-contained app that can be copied onto a remote machine (perhaps on a customer's site), and can collect debug output from a live environment which may not have developer tools installed. It works with Windows apps that have a GUI, or those that run as a service or from the console, so it is an invaluable part of the developer's toolbox.

This is Your Father's Codec

Martyn Davies — Mon, 20 Jul 2009 13:24:56 GMT

Today's TDM networks represent audio in G.711 format, also known as the mu-Law or A-law codec. This codec has been around since the 1970's when digital networks started to carry audio as digitised data. According to sampling theory you need to sample at least twice as fast as the highest frequency that you want to preserve, so 8000 samples/sec was chosen as the sampling rate, allowing frequencies of less than 4kHz to be represented. Since telephone networks have been engineered for a long time to use only part of the voice spectrum (perhaps 3.5kHz), then this was a suitable engineering compromise for the digital age.

I've heard several people refer to A-law and mu-Law as "uncompressed" audio, but this is not at all true. Actually, each 8-bit sample is split into two parts, an exponent and a mantissa (if you've ever done any work on representing real numbers in a computer you'll be familiar with this was of working). So the exponent gives the overall magnitude, and the mantissa gives the fine detail. It's a logarithmic representation, which happens to work well for the human ear, and usefully it allows us to pack 12 or 13 bits of resolution into only 8 bits.

Coding and decoding for G.711 is a relatively cheap operation (for a CPU), which must have been a deciding factor back in the early days of computing. For example, the A-Law decoder looks like this:

absval = (sample>>4) & 7;       //exponent
lower = (sample & 0x0F)<<1;    //lower 4 bits of value

switch(absval)
{
    case 0: amplitude =   lower|0x01;     break;
     case 1: amplitude =   lower|0x21;     break;
     case 2: amplitude = (lower|0x21)<<1; break;
     case 3: amplitude = (lower|0x21)<<2; break;
     case 4: amplitude = (lower|0x21)<<3; break;
     case 5: amplitude = (lower|0x21)<<4; break;
     case 6: amplitude = (lower|0x21)<<5; break;
     case 7: amplitude = (lower|0x21)<<6; break;
}

So for a handful of shifts, ORs and ANDs you can recover the audio sample into PCM format (i.e. really uncompressed) that is suitable for whatever processing comes next (saving to file, DTMF detection etc).

Now in the VoIP age, people are starting to feel limited by G.711 resolution, and in fact many VoIP systems allow alternative codecs to be used. Between VoIP and mobile there has been an explosion of development of many different codecs in the last 20 years, using the much more powerful and ubiquitous CPUs that we now have. Wideband codecs are now increasing in popularity, for example AMR-WB (G.722). Wideband codecs have a wider sample size, so that more frequencies can be represented, making the audio more akin to broadcast radio in terms of sound quality. There are even technologies like TFO (transcoder free operation) that aim to retro-fit wideband technology to existing TDM networks. Ultimately we can imagine the humble telephone producing broadcast quality audio, and that will be a huge step forward in usability.

Moon 40

Martyn Davies — Thu, 09 Jul 2009 14:56:10 GMT

On the 20th of this month will be the 40th anniversary of the first Moon landing, Apollo 11, famously taking Neil Armstrong and Buzz Aldrin for man’s first Moon walk. The Lunar Excursion Module (LEM) was fundamentally a simple machine which was designed to fall to the Moon rather than fly, with one giant rocket motor underneath and some smaller attitude thrusters that allowed the spacecraft to be rotated so that the main engine could potentially point in any direction when it fired. Control of the descent was therefore by means of a number of rocket engine “burns” that could slow the fall of the LEM. This certainly is a “brute force” method of flying; as with Earth flying machines like a helicopter or the Harrier jet, if you have a powerful enough engine it’s possible to bludgeon the laws of physics into submission.

Later on (in the late 1970’s), the idea of landing the LEM inspired a series of popular computer games, probably most famously the “Lunar Lander” arcade game from Atari. I first saw versions of lunar lander in the early 1970s, running on programmable calculators, and specifically the Science of Cambridge MK14 (an early single-board microcomputer), the first computer that I ever programmed. In the computer game, the program modelled the amount of fuel in the craft, the altitude and the speed, and of course the moon’s gravitational pull of 1.6N/kg. By pressing a button you could “burn”, which used fuel and slowed descent. If you studied Physics or Applied Maths at school you would have had the formulae needed to create this program, and you could even do the necessary calculations by hand. Where the computer becomes important is in the dynamic nature of the calculations: as you burn fuel, the mass of the craft decreases, and therefore the force of the engine creates more acceleration as the flight continues.

The real LEM had a dry weight of around 4000kg, with another 11,000kg of fuel at the start of the flight, and the descent started from a height of 15km. Unlike the game of course, the Apollo 11 descent had two men’s lives depending on the outcome, and the flight did not go smoothly. Armstrong famously landed the LEM (codenamed “Eagle”) with only a few seconds of fuel left in the tank, after deciding that the landing site was too rocky and deciding to fly along the surface for a while, looking for a new site. If you’ve ever played “Lunar Lander”, you’ll know that flying along at constant height is a very expensive operation in terms of fuel, so this is a high-risk strategy.

The LEM also experienced some computer problems during the short flight, with the Apollo Guidance Computer giving “program alarm 1202” repeatedly, causing Armstrong to ask Mission Control whether he should abort the landing. In subsequent analysis, the experts from MIT concluded that the computer overloaded because of the data coming from both the rendezvous radar and the ground radar at the same time. The boffins imagined that only the ground radar would be on during the descent (to give accurate height readings), while the rendezvous radar would be used after takeoff. Armstrong, being a test pilot, was planning for possible emergencies, and if the landing should be aborted, he wanted to be able to find “Columbia” (the command/service module) as quickly as possible as they burned away from the Moon’s surface. You might say that the user exercised that software in the way that the programmers had not foreseen; a problem that’s still all too common in software engineering today.

I would like to think that with today’s technology it would be much easier to go to the Moon: we have faster , smaller computers; superior materials like plastics and carbon fibre; more sophisticated fuels and engine technologies. Certainly the one thing that hasn’t changed in the last 40 years is the courage that it would take to land on the Moon, and we have to pay tribute to the 12 men that have done it.

Burning Rubber, But Not Gas

Martyn Davies — Mon, 08 Jun 2009 13:45:42 GMT

The Isle of Man Tourist Trophy, or “TT”, is one of the Worlds most famous and iconic motor races, where the public roads of the island are turned into a motorcycle race track. A 38 mile (61km) course takes bikes around the island at speeds of up to 200mph (320kmh), with the fastest bikes averaging around 130mph (209kmh) over the lap.

This Friday, an important new page will open in the history of electric vehicles: the TTXGP. The aim of the TTXGP is to build and race a zero-carbon superbike around the standard course, for two laps. Although any zero-carbon technology is allowed, the entrants are all electric, powered by batteries; 76 miles is a long way, so clockwork or rubber-band powered is not going to be an option, and there are certain public safety issues associated with nuclear powered motorbikes, even supposing you could find a rider willing to sit on one.

Visually, the bikes look very much like petrol bikes, and in fact usually a standard road bike is the starting point for constructing the electric version. Brakes, suspension, frame, controls are all fairly standard, but what is usually the petrol tank is now generally full of batteries. The motors are electric, with no gearbox, and of course these vehicles are pretty much noiseless.

The electric technology looks somewhat puny in comparison with the petrol bikes, but the electric vehicles are expected to be able to reach top speeds of around 70mph. Of course it is hoped that if this kind of racing becomes a regular fixture, then this will drive innovation in battery and motor technology. As any engineer will tell you, you can have a hundred ideas on paper about how to build something, but the execution of building something is where the really great innovation comes from.

I’m looking forward to seeing what these bikes can do on Friday, and also hoping that this does create practical road bikes in the not-too-distant future. An electric bike with a range of, say, 200 miles at speeds of up to 70mph seems to me like a useful vehicle for commuting.

Picture courtesy of TTXGP

The Growth of mHealth

Martyn Davies — Fri, 05 Jun 2009 08:55:35 GMT

There's an interesting report here from the UN Foundation and Vodafone, talking about mHealth, that is applications of mobile technology to health problems in the developing world. Because mobile has grown so fast, and costs have fallen rapidly, the mobile phone has leap-frogged the land-line and the personal computer and rapidly become the most pervasive communications device in places like Africa and Latin America. Land-lines will never catch up now (because the infrastructure cost is too high), and in terms of personal computing, the phone is the first computer many Africans will see, and in many cases the only Internet-connected device. The UN report shows that there are approximately 10 times as many mobiles available as computers, so the potential effect is profound.

But mHealth is not necessarily about the Internet at all, and in fact many of the successful applications are delivering value through basic voice and text functions. One example is disease tracking, where field workers can report malaria outbreaks, or cholera spread using IVR or text-based applications. This allows quicker central understanding of what's happening in the population, and allows a meaningful medical response. Another example is in communication of health information. Where there are few health workers addressing the needs of a large and distributed population, it is not possible to reach everyone in person to communicate information about staying healthy. SMS texting is a useful channel for sending information out widely, without depending on people visiting clinics. The report also talks about remote monitoring, where TB patients are given mobiles so that remote health workers can monitor their condition, and also remind the patients to take their drugs. The evidence shows that compliance of patients is greatly increased, meaning more chance that they will make a recovery, but also (importantly) pass on the disease to fewer others.

A lot of the tools that we have available through phones (IVRs, USSD menus, text, voice SMS etc) look primitive compared to the kind of communication available to Internet users in the richer North of the planet, but it's easy to overlook the radical effect that simple technologies can have on the poorer communities of the World.

The Lost Computers

Martyn Davies — Thu, 28 May 2009 13:27:15 GMT

I recently visited Bletchley Park in Milton Keynes in the UK, which is famous for code-breaking during World War II. Now it is a museum, but as well as recording the history of code-breaking, it also hosts the National Museum of Computing. Their collection starts with the WWII machines, such as the Colossus, used for breaking the Lorenz cipher. This early digital computer was a partially programmable device using thousands of valves as logic gates, and in fact they have a working copy of Colossus that was rebuilt from scratch over 10 years by volunteers. Today it sits there reading input from paper tape and generating a fantastic amount of heat as it goes through its deciphering program. This computer would not fit inside my house.

The Colossus display

The Bletchley collection contains air-traffic control equipment, mainframes and a whole collection of home computers from the microcomputer revolution of the 1980s. Where possible, the machines are put back into working order, so the ICL mainframe is there with its washing-machine sized hard disks spinning as they did in the 1970s. The Cray Y-MP still awaits repair, but of course today a gamer's graphics card probably has more floating-point CPU performance.

The collection has great significance for me, as many of the machines I saw over the last 30 years are machines that I have seen or owned. The DEC PDP8 is a machine that a schoolfriend and I tried to get from Oxford University when they threatened to throw it out. The Research Machines 380Z and Commodore PET were the earliest machines we saw in our school. Home microcomputers like the BBC Micro and Sinclair ZX81 were the machines that my friends used during the 1980s. Some of the calculators (like the HP34 and HP71) I owned until quite recently, but I'm ashamed to say that I threw mine out!

I'm glad that someone somewhere is collecting this stuff, as the rapid changes in computing over the last few years makes everything obsolete in such a short time. We tend to throw things away even before they are old enough for us to worry about the historical significance. Even though the CPUs were puny and the capacity insignificant by modern standards, these are landmarks in technology, as important as the evolution of steam engines or early aeroplanes. If you get a chance, do go to Bletchley Park and take a look.

ICL 80Mb hard disk. My 1Gb USB drive is on top for scale.

Nokia and the Boot

Martyn Davies — Fri, 08 May 2009 15:51:25 GMT

I enjoyed this poster today (for the Telegraph newspaper) with a boot labelled "A Nokia, 1979".

You might not realize this, but until the early 1980's Nokia was largely an industrial company in the rubber production business. A small investment in switching equipment, and then early mobiles led to involvement in the GSM standards, and ultimately to the company they are today with a $50 billion turnover, largely from telecomms.

Quite a nice accident to have, and an illustration that you can never tell which products are going to be the killers.

Happy Birthday, Dear Algorithm

Martyn Davies — Wed, 06 May 2009 13:55:24 GMT

Dijkstra's algorithm (to find the shortest path between two nodes) was published in June 1959, so it's about to enjoy its 50th birthday. The great thing about fundamental algorithms is that they can be applied in all kinds of different ways. Dijkstra's algorithm obviously applies to real-world route finding, and I'm sure that inside your car's SatNav system you'll find it lurking there; but networks (data and voice) are much more important than they were back in 1959, and this is a whole new application area.

In multinode data networks, it's still necessary to find the shortest path, in hops or in time, sometimes weighting hops in terms of real-life cost in order to give a "least-cost" route. Routing IP packets depends on finding the best routes from "A" to "B" without looping. In voice networks, a more subtle form of "shortest" is needed: that is, the path with the lowest latency. Latency is much more of a problem today than it was in the past because the 'nodes' in VoIP networks are often processing elements that add delay as part of the transformation they perform, e.g. transcoding, echo cancellation, tone detection and squelching.

So Happy Birthday, Dijkstra's algorithm; may you continue to find new applications.

Innovator Competition

Martyn Davies — Tue, 28 Apr 2009 08:03:23 GMT

We've launched a developer contest that runs through until October, and those of you who already regularly visit the Dialogic DEN should be prime candidates to take part.

You can find full details of the competition here, but in brief the idea is to create an innovative new application that incorporates one of more of the Dialogic products. A panel of judges comprises our own Jim Machi, plus three indepedent outsiders, and the winners will be announced in October this year.

You are completely free to decide which products to go with, so that might mean using our .NET or C APIs with board-level products, our our media gateway for SIP to TDM conversion, or scripting VoiceXML, CCXML, MSCML, MSML with our media servers. The choice is up to you. The most important thing for us the the innovation.

Good luck!

Calculating Easter Day

Martyn Davies — Thu, 09 Apr 2009 11:30:30 GMT

With Easter approaching, I was thinking about the calculation for Easter day. Back in the 1970s I had one of the first affordable programmable calculators, the Sinclair Cambridge Programmable, and this came with a book of algorithms for calculating all kinds of interesting things, mainly science and engineering related. It even had a rudimentary version of the Lunar Lander game, although with only the altitude and speed shown on the display, you had to use your imagination.

One of the sample algorithms offered with the calculator was a routine to work out Easter day for any given year.

Easter Day is a moving feast, based on the movements of the moon. Specifically you have to work out the date of the Paschal Full Moon, then Easter day falls on the following Sunday. As usual Wikipedia has extraordinary levels of detail on the available algorithm, and as far as I remember the steps for the Sinclair calculator looked like those listed under Anonymous Gregorian algorithm:

a = Y mod 19
b = floor (Y / 100)
c = Y mod 100
d = floor (b / 4)
e = b mod 4
f = floor ((b + 8) / 25)
g = floor ((b - f + 1) / 3)
h = (19a + b - d - g + 15) mod 30
i = floor (c / 4)
k = c mod 4
L = (32 + 2e + 2i - h - k) mod 7
m = floor ((a + 11h + 22L) / 451)
month = floor ((h + L - 7m + 114) / 31)
day = ((h + L - 7m + 114) mod 31) + 1

So in other words in a series of quite simple fixed point calculations you can go from the year number to a month (March or April) and a day number. Quite simple and elegant, and ideal for my calculator, which only had a 36 steps (operations) in its memory.