Business and Software

The HTC Touch Diamond phone supports a built-in QualComm GPS receiver, which in most cases works fairly well, but its sensitivity to acquiring satellites quickly is still lacking.

In my experience, the moment I near the vicinity of a larger city, such as Toronto, and turn ON the internal GPS, it will almost always fail to lock-on any satellites.  This is without even getting into the downtown core with skyscrapers and other large buildings.

Before this, I used to use the OnCourse SiRF star III Bluetooth GPS Receiver with a simple PDA, which worked extremely well, even indoors.

So given that the HTC Touch Diamond phone has Bluetooth support, I decided to try using the OnCourse external GPS with it.

Within a few minutes I had the two devices linked over Bluetooth and configured the External GPS parameters under the Settings -> System dialog.








Unfortunately, it wasn’t quite that simple.

When it failed to work, I reviewed my steps including the External GPS parameters under Settings -> System dialog, and noticed that the GPS Hardware port was not being saved.





So, as usual, the first step is to ask for help from the Google oracle.  When that failed to retrieve a working solution, I rolled up my sleeves and went Registry diving.

I tested the various Windows Mobile Emulators I use for developing my software, and the External GPS parameters were being saved properly on them.  It was then just a matter of comparing the registry details with my HTC Touch Diamond phone.

The Windows Mobile Emulators contained a "Control Panel Configured Device" key located under [HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver\Drivers] that was missing on my HTC Touch Diamond phone.

So I added this missing key, copying also its parameters from the Emulator images, and the resulting setup was formed.

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver\Drivers]
"CurrentDriver"="Control Panel Configured Device"
"CurrentDriverExt"="Control Panel Configured Device"
"SleepOnNoData"=dword:000003e8
"RetryWaitOnError"=dword:00000003
"OutputBufferSize"=dword:00001000
"InputBufferSize"=dword:00001000

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver\Drivers\Control Panel Configured Device]
"CommPort"="COM2:"
"InterfaceType"="COMM"


  


When the "CurrentDriver"="Control Panel Configured Device", the GPS Hardware port setting is then saved properly, and I am able to establish a working connection with the OnCourse external GPS.

To revert back to using the HTC internal GPS, I simply rename the "CurrentDriver" registry keys to match their appropriate setting.


  


This may seem like an inconvenience to always having to rename a registry key every time I want to switch to using an external GPS, and ideally a little app that would do it for me would be better.  Maybe I’ll write one if there is enough interest.

I have said it before, and I’ll keep saying it, “user feedback is the single most important driver behind new features and improvements in my products”.  It doesn’t get simpler than that.

Most of the software I develop for Applied PDA is primarily for my own initial use.  Why build something that I won’t directly benefit from?

As the software gets used internally more each day though, various designs and features change.  It quickly becomes apparent that it is not enough to create something that only I can use, but that others can intuitively utilize as well.

So before anything gets released, it has to pass what I call I.B.U.T, “inside the building usability test”.   This is a hack title for a process which simply means that until everyone in the building can intuitively understand the software and are not afraid (or annoyed) to use it, it does not leave the building.

This enforces an active role to get local user feedback and in a way, requires an approval from everyone who might potentially be supporting the software.  A common software term for this is called “dogfooding”.

Such a process can delay the release of software for a short while.  But it also ingrains an attitude that the product is open to suggestions from its users, and that real people stand behind its virtual skin to provide a service in supporting its growth and maturity.

The formula is simple:  You talk + I listen = Better Software.

Many years ago there existed a gap between mobile PDA's and cellular phones.  The phone was essentially a mobile radio, and the PDA was a little computer that held all of your data, calendars, contacts, etc.

Then as time went on, the mobile phone absorbed most of these PDA functions.  The evolution of the phone turned it into a PDA with a cellular radio.  The PDA became a phone, and the phone became a PDA.  They are both the same thing now, branded as the new PDA.

No matter what you call it though, the point is that it is a versatile handheld instrument, used for communication with other people and machines (e.g. The internet).  This is the platform which will open access to computing in every corner of the world, and with it also, bring a piece of our software to empower people and their imaginations.

My vision is to have handheld instruments that are ubiquitous, intelligent, and indispensable to your exploration adventures around the world.  And the most important component of it I believe, is the software.

I enjoy hearing stories of people who give feedback of where they took my software.  From Antarctica, through the many ocean studies, to military equipment and robotics, it brings me much fulfillment to know that my software running on handheld devices has aided people in their exploration of our planet.

If you have a good story then please share it with us.  It just might inspire new development for more great applications.

Happy adventuring!