news

GPSAccess FAQs
Updated 10/4/05

Why is GPSAccess so expensive!
It depends on your point of view. We created GPSAccess for corporate developers building serious mobile enterprise applications, not for hobbyists. If you make $50/hour as a .Net developer that means the cost of GPSAccess is about a day's wages. Even if you had all the necessary skill and toolsets we bet it would take you more than a day to create something like GPSAccess.

So the question is, does your company want to pay you for many weeks to create a home-grown GPS toolset, or pay for the equivalent of one day's work to have you be productive immediately?

With so many other inexpensive GPS libraries on the market, why would I need GPSAccess?
The primary benefit of GPSAccess is integrated bluetooth support. If that's not important to you, you don't need GPSAccess.
Other GPS libraries let you specify any COM port to open and immediately start to receive parsed GPS data. If that COM port is the bluetooth port, the Widcomm device-selector screen will pop up the first time and ask your user to select a device among all the bluetooth devices in the vicinity. After the first time you connect the Widcomm stack usually remembers the address of your GPS receiver as the "last-used" bluetooth device. So next time the GPS library opens that COM port the stack will automatically connect to the GPS receiver and skip the popup screen. So in the worst case your user only sees the device selector screen once. That's not so bad is it?

Here are some scenarios where that breaks down:

You also use a Bluetooth printer or connect to some other Bluetooth device. Now the "last-used" bluetooth device is no longer your GPS receiver. Your GPS library will open the COM port, successfully connect to the printer, and never get any GPS data.

Your GPS receiver loses power. Many GPS libraries don't recognize there is no longer any real connection on the COM port. You just stop receiving GPS data.

Your user turns off the PDA or lets it go idle which shuts it down. When the PDA is powered back up, the GPS library thinks it still has a valid serial port bluetooth connection, but it doesn't. You just stop receiving GPS data. And again, it may not even notify your application that a new connection is required.

Your user picks up a different GPS receiver from the front office in the morning. Now the GPS library opens the COM port, and the Widcomm stack tries to locate the old GPS receiver. When it can't, sometimes it pops up the device-selector screen, but sometimes it doesn't. The GPS receiver looks like it's on, the PDA application is working, and the user has no idea he's not receiving valid GPS data.

GPSAccess solves all these problems. But if these scenarios don't apply to your application, you probably don't need it. In the past year we've built several GPS solutions for clients with a large mobile workforce, and we can tell you from experience - these issues matter!

Can I show maps and driving instructions with GPSAccess?
GPSAccess does not provide mapping tools, it just feeds you the GPS data required by mapping tools. To show "you are here" maps, plot routes, get driving instructions, etc you need to use a separate mapping service such as Microsoft's MapPoint or VirtualEarth, or a separate mapping package such as TomTom or PocketStreets.

Can more than one application use the GPS data at the same time?
Let's say you need to get real-time GPS coordinates for logging purposes, but you also want to use an all-in-one mapping package like PocketStreets or TomTom. This presents a problem since both GPSAccess and these products want to open and use the same COM port. One good solution here is to use a comport-sharing "gateway" product like the one from www.franson.com. Now both tools think they are opening the COM port but the gateway actually sends the data to both. PocketStreets gets its GPS data for showing a map of your current location, and your application gets its GPS data for reporting back to the corporate office.

Can I use the new GPS API in Compact Framework v2.0?
The new Microsoft GPS API is an interface to a common access layer that hides the details of GPS hardware and the NMEA data. As far as we know it also requires GPS hardware devices that adhere to this standard, which aren't out yet. Also this API does not integrate Bluetooth access, it just opens a named COM port like any other standard GPS API.

Can I use GPSAccess on the desktop?
A desktop version of BTAccess using the Widcomm stack is still being considered.

What about the Microsoft Bluetooth stack?
The Microsoft stack is common on the desktop and on SmartPhones. And it's starting to appear on the newer PDAs for Windows Mobile 2005, replacing the Widcomm stack (for example on the Dell Xv51). So we plan to have a Microsoft-stack version of both BTAccess and GPSAccess, but no definite dates yet. If you're using the Microsoft Bluetooth stack now check out the Bluetooth and GPS wrappers from the folks at www.opennetcf.org.

Where can I get more details about how GPS works?
Here are some excellent resource sites:
Articles on GPS & Navigation Software:
http://www.gpsinformation.org/dale/PocketPC/wince.htm
http://www.pocketpcmag.com/_archives/Sep05/gpssolutions.aspx

Articles on growing GPS usage: http://www.microsoft.com/windowsmobile/articles/enterpriseGPS.mspx
http://www.microsoft.com/windowsmobile/articles/gps.mspx

General GPS info and details on NMEA GPS data format:
http://www.commlinx.com.au/NMEA_sentences.htm
http://home.mira.net/~gnb/gps/nmea.html
http://vancouver-webpages.com/peter/
http://en.wikipedia.org/wiki/GPS
http://en.wikipedia.org/wiki/Latitude
http://www.codeproject.com/vb/net/WritingGPSApplications1.asp

Other excellent GPS libraries:
http://www.gpsdotnet.com/
http://sourceforge.net/projects/gpsmobile/
http://www.opennetcf.org
http://www.franson.com/gpstools/

Mapping Tools and Services:
http://msdn.microsoft.com/mappoint/
http://www.microsoft.com/windowsmobile/downloads/pocketstreets/default.mspx
http://www.tomtom.com

GPSGate port sharing:
http://franson.com

	GPSAccess FAQs Updated 10/4/05
	*Why is GPSAccess so expensive!* It depends on your point of view. We created GPSAccess for corporate developers building serious mobile enterprise applications, not for hobbyists. If you make $50/hour as a .Net developer that means the cost of GPSAccess is about a day's wages. Even if you had all the necessary skill and toolsets we bet it would take you more than a day to create something like GPSAccess. So the question is, does your company want to pay you for many weeks to create a home-grown GPS toolset, or pay for the equivalent of one day's work to have you be productive immediately?
	*With so many other inexpensive GPS libraries on the market, why would I need GPSAccess?* The primary benefit of GPSAccess is integrated bluetooth support. If that's not important to you, you don't need GPSAccess. Other GPS libraries let you specify any COM port to open and immediately start to receive parsed GPS data. If that COM port is the bluetooth port, the Widcomm device-selector screen will pop up the first time and ask your user to select a device among all the bluetooth devices in the vicinity. After the first time you connect the Widcomm stack usually remembers the address of your GPS receiver as the "last-used" bluetooth device. So next time the GPS library opens that COM port the stack will automatically connect to the GPS receiver and skip the popup screen. So in the worst case your user only sees the device selector screen once. That's not so bad is it? Here are some scenarios where that breaks down: You also use a Bluetooth printer or connect to some other Bluetooth device. Now the "last-used" bluetooth device is no longer your GPS receiver. Your GPS library will open the COM port, successfully connect to the printer, and never get any GPS data. Your GPS receiver loses power. Many GPS libraries don't recognize there is no longer any real connection on the COM port. You just stop receiving GPS data. Your user turns off the PDA or lets it go idle which shuts it down. When the PDA is powered back up, the GPS library thinks it still has a valid serial port bluetooth connection, but it doesn't. You just stop receiving GPS data. And again, it may not even notify your application that a new connection is required. Your user picks up a different GPS receiver from the front office in the morning. Now the GPS library opens the COM port, and the Widcomm stack tries to locate the old GPS receiver. When it can't, sometimes it pops up the device-selector screen, but sometimes it doesn't. The GPS receiver looks like it's on, the PDA application is working, and the user has no idea he's not receiving valid GPS data. GPSAccess solves all these problems. But if these scenarios don't apply to your application, you probably don't need it. In the past year we've built several GPS solutions for clients with a large mobile workforce, and we can tell you from experience - these issues matter!
	*Can I show maps and driving instructions with GPSAccess?* GPSAccess does not provide mapping tools, it just feeds you the GPS data required by mapping tools. To show "you are here" maps, plot routes, get driving instructions, etc you need to use a separate mapping service such as Microsoft's MapPoint or VirtualEarth, or a separate mapping package such as TomTom or PocketStreets.
	*Can more than one application use the GPS data at the same time?* Let's say you need to get real-time GPS coordinates for logging purposes, but you also want to use an all-in-one mapping package like PocketStreets or TomTom. This presents a problem since both GPSAccess and these products want to open and use the same COM port. One good solution here is to use a comport-sharing "gateway" product like the one from www.franson.com. Now both tools think they are opening the COM port but the gateway actually sends the data to both. PocketStreets gets its GPS data for showing a map of your current location, and your application gets its GPS data for reporting back to the corporate office.
	*Can I use the new GPS API in Compact Framework v2.0?* The new Microsoft GPS API is an interface to a common access layer that hides the details of GPS hardware and the NMEA data. As far as we know it also requires GPS hardware devices that adhere to this standard, which aren't out yet. Also this API does not integrate Bluetooth access, it just opens a named COM port like any other standard GPS API.
	*Can I use GPSAccess on the desktop?* A desktop version of BTAccess using the Widcomm stack is still being considered.
	*What about the Microsoft Bluetooth stack?* The Microsoft stack is common on the desktop and on SmartPhones. And it's starting to appear on the newer PDAs for Windows Mobile 2005, replacing the Widcomm stack (for example on the Dell Xv51). So we plan to have a Microsoft-stack version of both BTAccess and GPSAccess, but no definite dates yet. If you're using the Microsoft Bluetooth stack now check out the Bluetooth and GPS wrappers from the folks at www.opennetcf.org.
	*Where can I get more details about how GPS works?* Here are some excellent resource sites: Articles on GPS & Navigation Software: http://www.gpsinformation.org/dale/PocketPC/wince.htm http://www.pocketpcmag.com/_archives/Sep05/gpssolutions.aspx Articles on growing GPS usage: http://www.microsoft.com/windowsmobile/articles/enterpriseGPS.mspx http://www.microsoft.com/windowsmobile/articles/gps.mspx General GPS info and details on NMEA GPS data format: http://www.commlinx.com.au/NMEA_sentences.htm http://home.mira.net/~gnb/gps/nmea.html http://vancouver-webpages.com/peter/ http://en.wikipedia.org/wiki/GPS http://en.wikipedia.org/wiki/Latitude http://www.codeproject.com/vb/net/WritingGPSApplications1.asp Other excellent GPS libraries: http://www.gpsdotnet.com/ http://sourceforge.net/projects/gpsmobile/ http://www.opennetcf.org http://www.franson.com/gpstools/ Mapping Tools and Services: http://msdn.microsoft.com/mappoint/ http://www.microsoft.com/windowsmobile/downloads/pocketstreets/default.mspx http://www.tomtom.com GPSGate port sharing: http://franson.com