A few years ago I was responsible for developing the software that was bundled with an early GPS card, aptly called the Marco Polo. This unit had GPS chips and a neat little antenna unit made by Garmin, all designed to pop in to the PCMCIA slot on a laptop.

It worked very well, and pre-delivery testing of our new software allowed me to check out some of the fundamentals of the set up process, so that I could write the user manual. In particular I needed an understanding the issues of cold and warm restarts, and the likely time to get a first-fix. Such information was critical to user education and acceptance, saving clients calling with unnecessary questions.

That research came back to me a couple of weeks ago when I encountered a field-based 'Pocket PC' user clutching his GPS enabled PDA, and grumbling that the device would not give him a location (I think the words he used were somewhat more expletive) - he sometimes had to wait for 20 minutes or more for a fix. He had even developed various rituals including wandering down the street, which he thought speeded things up a bit but did nothing for his temper if it was raining. He needed to have an accurate location for his work, so he often had to wait and fume.

Operational nuisance

As it's now popular to locate your staff with GPS, the time taken if there is no accurate fix therefore becomes an operational nuisance. During a restart, GPS is apt to report the last position you were at when it was last switched off, or even to start in some neutral state, certainly not the instant where and when you might need. Misleading, eh?

The problem with GPS, especially if built in to smart phones or in laptops, is that devices can take ages to get a first fix unless it has an up to date clock and almanac. Smart phones can provide that clock from the network to speed the fix time, but they also have the annoying habit of needing to be reset when software crashes.

Resets can cause the GPS to lose track of time and, for the want of anything better, default to a historic date and time, usually in January 2005, leaving the little chips in the device completely confused and the user placed temporarily in space and time totally unrelated to their actual location. Until the GPS clock in your device is completely correct it cannot estimate your position. It's a bit like Sleeping Beauty, but looking for its expected satellites in the sky, rather than Prince Charming bursting through a thicket of thorns, but being disappointed when all is not what was expected.

All this means a cold GPS start-up can easily take half an hour, as several things have to happen. First the unit has to get its clock exactly right, using signals from any passing satellite, and then has to fumble through its almanac to match which ones should be in the sky corresponding to wherever it is. Once all that is clear, then it can go about the precision timing measurements need for a fix.

Integrated GPS devices, like Sat-Nav units tend to have a process to keep time even when 'off' and can remember where they were last, so have a flying start when you switch them on, but a smart phone initiating a big reset can be a different matter. In either case, users need to be trained to locate GPS devices where they can synchronise quickly. That means a place with a good sky view. Time is money, and time spent with rituals to achieve an accurate fix is often time wasted!

NFC - what's that?

The IT business excels in jargon and when a weighty document expounding the benefits of NFC technology landed in the MCUG in-tray, but with no word of explanation as to what then letters actually meant, I decided to do some research. Near Field Communications (NFC) is a catch-all phrase being used for familiar technologies such as RFID tags, and familiar things like Oyster Cards that are used by millions of commuters as cashless payment on London Transport.

The concept of NFC is that it attempts to harmonise the many 'wireless' systems that are intended only to communicate over a few inches. As an example, in the case of the Oyster Card, the idea is that you actually make the device so insensitive or 'short range' that it needs to touch the reader. The concept of needing to touch is part of the discussion going on within the groups working on the technologies.

The argument goes that if you have, say, an NFC sensor in your water-meter-reader's PDA and you want to be sure that he or she reads the correct MFC enabled meter, then touching that meter to achieve a read provides physical intention and confirmation. This short range use reduces power consumption and removes ambiguity of what is to be connected to what. Of course, touching really means 'hold it very close'.

The same holds true for payments, where, as a user of an NFC enabled phone with embedded payment system you would only wish to pay for goods at your NFC enabled supermarket checkout, and not for the guy with a full trolley of shopping in the next aisle too!

Bluetooth could be considered a form of NFC technology, except that it can have a range of many metres. What you connect to in Bluetooth can be ambiguous, so passwords must be exchanged to identify the intended channel; the term NFC is currently therefore somewhat loose.

The interesting idea for those of us working in the service or utility sector is that a standardised set of NFC enabled devices and readers could be more flexible than technologies like bar codes, and enable, say, meter reading or data collection in one direction, and the making and receiving of small payments in the other.

Mass markets such as parking meters, coffee machines and other small-cash systems should drive device prices down, and spin off should give this service industry a technology for easily gathering and exchanging data at a micro level. This is a standardisation initiative to watch, and as it matures, to lever in to our world of service, spares, repairs, and micro payments.

MCUG Forum 2009

The MCUG forum is now confirmed for next March after a gap of four years. An event manager has been appointed and the venue in Sutton Coldfield booked. We are returning to the familiar user case study-based conference previously held in Warwick, complete with exhibits, user vehicles, and a chance to spend some quality time immersed in the technologies and business issues reviewed from an end-user perspective. Keep an eye on the MCUG web site.