Fundamental Software Solutions

On a past project, we had been challenged with Windows Mobile and GPS.  Specifically, our customer wanted to have a display of the position of his crew on the street from back at the control center.  GPS provides the positions, but there is a huge penalty in terms of battery power.  On some of our test phones, it was better for the battery to have the GPS tracking on permanently, as gathering the first sample sometimes took too long, and of course took too much power to provide little result. On others, just the GPS startup delay would draw sufficient power for the battery to drain within a morning of in-field testing around downtown buildings and other GPS-holes.

The project had been canceled, but our thoughts still moved forward.  We often find repeat requests for the same thing relatively close to the same time, and we had to know how to solve this.  Google Maps (mobile) was doing something with cell towers, and could the average company also head this way with satisfactory results?

After reviewing some previous internet articles (Google mmaps MCC MNC LAC CELLID) on the subject of tower-provided coordinates, we threw together a demo in a little under a week that incorporated tower position gathering, optimal power management, app waking and a web service that not only collected the tower and location positions, but also provided a map of the subject(s) that were being tracked.

There are some obvious issues that were somewhat difficult, yet vital for this project.

1. Battery
   No matter how little you wake a device, you still are waking it.  Smart-phones seem to handle this better, but the general idea is wake it, do the smallest amount you need to do and then shut it down.
   
2. Power States
   The Windows Mobile is a complex device, and you properly have to manage the power states.  (Imagine waking the device and attempting to update a position when the network is powered-off!)  Finding the right power state that both accomplished the task and kept the user from accidentally dialing when his phone awoke within his pocket was a challenge.
   
3. Sample Rate
   If you are like me, waiting 10 minutes for an update on location was painful.  Especially during testing.  However, if you wake a device and transmit (our packet happens to be around 128-238 bytes each update) then you start to either wear on your data plan, or the battery over time.
   
4. Precision
   We have used a couple of things to maximize precision.  First, we have a technology that we implement called Supplemental Tower Positions.  When a tower is known to be somewhere, we can supplement or correct the location.  Since the location information is all done on the server side, the phone doesn't need to process anything more than Wake, Transmit and then Sleep.

What's next?

The technology is relatively boundless.  Once we have position information, it is possible either at the phone or home base to calculate other things or otherwise add value.  The technology, although implemented here very one-way, could be adjusted to add two-way communications.  A quick search and click by a service rep at the office could schedule for the closest maintenance worker in the field, for example, all through the same communications system. 

You could also outline GPS zones, where it would be possible to say that a rep was "at home" or "in the office" automatically by seeing where his phone was (or wasn't). 

Positioning could also have effects for unlocking or controlling secrets.  IT managers may encrypt a password or entry code with a GPS position or positions.  The IT Staff can then only retrieve the passwords for the systems when at that position.  For home alarms, perhaps the alarm knows you are at the door and automatically turns off.  If you are away, it knows and alerts the authorities.

Source Code

We are not currently ready to release any source-code.  Since the service hits our public web server, we can't allow free downloads except upon specific circumstances or special request, sorry.

I had the pleasure of creating and working with some "always up to date" applications on my Windows Mobile Device, and have tested some other manufacturer's products that do similar things.  One thing I really hate is having to set peak times or configure when data transfers should occur in every application differently.

For some people, it may be beneficial to have mail syncing at a separate schedule than for something like phone-coordinate tracking, but sometimes it is nice to should be able to set those settings ONCE if I choose, and let all my software follow that one setting.  For example, I often reset ActiveSync's schedule when I travel to avoid costly data transfers when I don't need to check my mail.  I really hate when I get the bill the next month after I forget one app!  Maybe allow the user to choose "follow activesync" or "use custom settings" or something like that if you need more precision than just M-F and a start/end time.  For most of our customers, ActiveSync's schedule is exactly what they needed.

So, For all the developers out there making software that communicates over the air - I have posted some source code(below) that will tell you if the current time is "syncable" and if not, will tell you the next time when a transfer should be allowed.

For example:

if(FSSI.Mobile.ActiveSync.Settings.IsInPeak(DateTime.Now))
{
   // Do something.
}

or, to check when the next sync time is (such as when planning when to wake the device to Sync....)

DateTime TimeToWake = DateTime.Now + new TimeSpan(60,0,0);
TimeToWake = FSSI.Mobile.ActiveSync.Settings.MakePeakTime(TimeToWake);
if(TimeToWake == DateTime.MaxValue)
{
     // The sync settings say that no future days are valid (no sync days)
}
else
{
     // TimeToWake is set to the next available Sync time on or after the passed in value.
}

Project Source and Demo Project:

• GetActiveSyncPeakTimes.zip (10.93 kb)