Wednesday, March 08, 2006

Qualcomm GPS API restricted on Sprint phones

While trying the Garmin Mobile on a Sanyo CDMA phone equipped with Qualcomm Mobile Station Modem (MSM) chipsets I decided to look a little deeper into what's under the hood on this particular phone.

The MM7400 offers quite a punch for a phone with features that go way beyond what one would be used to from a plain, no-frills device. Streaming video, good sound quality, A-GPS, voice, great quality display and ease of use which makes things always better.

My beef with phones start when you try to add more to it than what comes with it. The Motorola has a way in that now allows me to add even my own GPS-based apps to it. But Sprint has a much bigger lock around this phone. Let's get to it.

Qualcomm GPS API

First, Qualcomm makes available the specification of its GPS API on this site, just fill the form and you can download two PDF's: one that describes the GPS package and another with usage guidelines. From the second paper you get that behind the scenes Garmin Mobile makes two types of calls: one that uses the network data mostly and another that makes more use of the capabilities of the phone itself.

gpsOne, the group of technologies used by Qualcomm for its location-based services works through "cell network-based trilateration" which uses with CDMA [...] advanced forward link trilateration (AFLT)". It makes use of the user plane through TCP/IP.

Trying to simplify the process here you have a Mobile Set operating in two basic modes: MS-Assisted and MS-based and you basically depend on a PDE (Position Determining Entity) server like those provided by SnapTrack (a Qualcomm company) that helps the phone track the satellites position so it can obtain its first fix.

In MS-Assisted mode assistance data is sent to the phone from the location server for every fix causing a much higher volume of data but providing a great accuracy and really fast TTFF (Time To First Fix) in the other hand MS-based mode works better for an application that is tracking the device's location so it can display its position on a moving map for example and consequently minimizing the data traffic to the network.

Sprint PCS Location Services

So far so good. That's what Qualcomm made available now on the Sprint side if you try to download the SDK from the Developer site you will see right away that things won't be that easy.

Version 2.0 of the Sprint SDK (Launchpad) doesn't include the GPS piece of the Qualcomm API, it spelled out on the name of the zip file itself. According to a post to the Sprint Forum the current "SDK does not include support for Location APIs. Currently, these are available only to Sprint partners in location services or partner prospects for location services under a non-disclosure agreement [...]."

Sprint wants to recoup the money put in the investment necessary to upgrade its network, which makes sense. But remember that this whole process got started with the mandate for the E911 services. [In fact, this might be really the case here because the E911 tax should already be covering these costs.]

This one is an old post, which doesn't reflect the current state of things, it seems that at some point the (compiled version) of the GPS classes were being distributed in the Sprint SDK so that applications like the GpsTester described there could possibly work but the lock was added and the compiled classes removed from the SDK. But nowadays GpsTester fails probably because it is not signed by Sprint to make use of their location server. This way it fails to connect and run on the device.

Still, there is hope

I had to check about adding my own apps to the Sanyo and this time it wasn't that hard to find a way in (please refer to the legalese at the i860 post). This site allows you to upload a J2ME midlet by sending a SMS with a "jump code" that points to the .jar on a Sprint compatible OTA server. The site also shows how you can create your own server with PHP and MySQL. GPSTester got installed thru this process, but it didn't quite work.

Signed apps, like GMapViewer can be installed from the embedded web browser itself and this one worked just fine (didn't check the search funtions) but there is no GPS support.

Update: Alexander Pruss built a dummy version of QJAE that you can use to compile code that makes references to it. This way you can load it on a device but still depend on access to their PDE. Check comments for more and the next update.

Update: According to Alexander Pruss: "Sprint prohibits unauthorized use of their PDE, and prohibits editing _policy.txt on the handheld to enable the API. Since they own their PDE, they have the right to prohibit its use."

Their advice for anyone interested in GPS is to use the Nextel platform with true GPS phones. If Assisted-GPS is the way to go, then it is time to put together an OpenSource PDE with a protocol that anyone can use and talk to.

Looking elsewhere

And looking back at the beginning of this technology, here is an interesting piece of history on this article about oneGps and E911 implementation options with a reply from SnapTrack.

Guess the next step will be to check which other vendors SDK's that use Qualcomm's and Brew GPS API: Brew Devices By Manufacturer

And here are some pointers on Brew development at the DevX site:

Meanwhile let's go back to the iDen API and real GPS for a change.

11 comments:

Alexander R Pruss said...

Things aren't quite so hopeless. The QJAE GPS API specs are available. I don't know java, but it only took an hour or two to write a dummy com.qualcomm.qjae.gps package (with dummy methods that do nothing) that was sufficient to compile the GpsTester source code against. I then just deleted the dummy code from the jar file before uploading to my Sprint Samsung A880.

To do this without signing, I edited the handset's /brew/__policy.txt (used BitPim to copy back forth between PC and phone) to include

blanket(oneshot): gps_api

in the "domain: untrusted section.

I still can't get GpsTester to work (it waits for the GPS and then gives a GPS timeout), perhaps because it requires network access and I haven't ordered Vision services (don't need them very much--I can install whatever I like on the phone with BitPim and I have a WiFi PDA and live on a campus with WiFi in most places). But I know it's connecting to the GPS API correctly, because the timeout error does come from the GPS API and because the first time I run it asks for permission to use location services. (If one doesn't want to be asked, one can put "allow" instead of "blanket(oneshot)" in the __policy.txt file. But it's nice to be asked, as it shows that it's working.)

(I tried developer-enabling the phone, but that had no effect.)

My dummy implementation of the com.qualcomm.qjae.gps classes doesn't is missing all the static finals, because the docs don't give their values. So you can't switch modes. Trial and error might let one reverse engineer these.

The EULA on the QJAE docs says you can use the docs to create a QJAE implementation. This means that I should be able to post my dummy QJAE implementation once it works OK.

gpsguy said...

Pretty clever. If you can set the mode to standalone (and the API actually gets through the hardware) you might not need to access their PDE. That would be perfect.

Alexander R Pruss said...

Stuff on the Internet (I did a lot of googling) imply that with Sprint, one always needs a PDE. The issue is that Sprint didn't include an antenna for receiving ephemeris data. The promising seeming one-shot no-download mode seems to require a PDE, but apparnely makes less use of it.

I updated my dummy QJAE implementation. It now includes the static final constants which the QJAE docs don't give values of (I managed to fool java into letting me get their values at load-time, and then had the handset display them and put them into the code). So everything that is needed for using the QJAE GPS API is there.

bill said...

"Stuff on the Internet (I did a lot of googling) imply that with Sprint, one always needs a PDE. The issue is that Sprint didn't include an antenna for receiving ephemeris data. The promising seeming one-shot no-download mode seems to require a PDE, but apparnely makes less use of it."

It's true that you need a PDE, but some sanyo sprint phones (mm-9000, mm-7500, m1) tag camera exif data with gps coords if you turn location on in the camera settings. That means there might be some PDE ip/port numbers lurking somewhere that bitpim could track down . . .

Eric said...

The location tag on pix is the lat/lon of the celltower.

Aziz said...

Interesting article. I'm working on developing an application that requires GPS functionality as one of it's main features. I've been able to successfully implement the GPS using JSR179 API, and it works fine in all emulators and on a few physical models - i670 and Blackberry 8300 (no actual GPS data, but I do at least get a LocationException).

The problem is, I have a tester phone from Sprint/Nextel (who we're partnered with). The phone is a Sanyo Pro-200, and whenever I attemp to use the GPS functionality, the application doesn't response (I think it's just stuck in the logic - I can close it and open it up fine by flipping the lid).

Do you think this has anything to do with the issues in your article (and the comments)? At least it'd be nice to know if it's actually supported or not.

Thanks,
Anthony Aziz

gpsguy said...

Hi Anthony, the specs mention Autonomous GPS but I doubt that is available for you.

Sprint most probably locked it availability and choose to force users pay $10 a month plus data traffic to obtain its location.

This policy doesn't seen to have changed. But at least you don't live in Egypt!

Aziz said...

I've found documentation that says access to restricted APIs (GPS, SMS, etc) on Sprint CDMA devices can only be accesses by authorized Sprint developers, with proper code signatures (through Verisign).

CDMA Signing Documentation (PDF):

http://developer.sprint.com/getDocument.do?docId=91801

Sprint's Professional Developer Program page:
https://developer.sprint.com/site/global/working_with_us/pdp/p_pdp.jsp

So that about sums it up. $5k a year for the fix. But what about this dummy qualcomm classes. Is it possible to just implement those classes, remove them from the jar, and then deploy with a signed application? Has anyone tried this (without having to modify the phone with BitPim - the application needs to be deployed to non-technical users)

gpsguy said...

Aziz, check the comments from Alexander Pruss above.

Aziz said...

I see that, however that link results in a 404. I followed some googling and links and found GpsTester app using the Qualcomm API, so I can try to write my own dummy code, but I'll have to look into this more. Eclipse let's me see all the public values of the Gps class, even though I can't seem to call them, so I'll have to test that out.

I also learned we're not actually partnered with Sprint, but we have a business relationship with a Sprint reseller. I think we may have to invest the money into getting into the PDP, yet.

I wish phones would just stick to doing the same thing :/ Hopefully MIDP 3 will also include some better enforcing on the specifications. What ever happened to write-once-run-anywhere, eh? (rant rant rant)

Aziz said...

I've dug up more information on this, and I believe I've got the definitive answer...

The ability to distribute an application that uses GPS (Qualcomm, JSR179, whatever) on Sprint CDMA phones is going to cost you $5000. This is a one-year membership that includes the signing and review of two applications (each application after that is another $2.5k). And that's if you're approved (you're business has to be software development, etc).

Look up the Sprint Professional Developer Plan on the Sprint Developer site for more information.

Also, the latest Sprint Wireless Toolkit includes the Qualcomm API classes.