Guys, Here are more comments to recent GPS related posts on this list. Hope you'll find some answers here.
------------------------------------------------------ On Thu, Jan 25, 2007 at 02:38:20PM +0100, Michele Manzato wrote: > Some additional questions on this subject: > > 1. Is there any "A-GPS standard" whatsoever? no. It's a broad term for many variants of GPS THE SUPL (Secure User Plane) standard is promulgated by OMA, and being investigated worldwide. The carriers love 'em and hate 'em: LOVE: not a big need to add N.E. (low $$) HATE: the carriers don't own the position fix (loss of $$) The handset communicates using the OMA SUPL standard using objects encoded in ASN.1 to a SUPL server anywhere on the net (that the carrier allows access to). (On the other side of the SUPL server is a reliable feed of ephemeris from GPS receivers all over the world. This is part of Global Locate's WWRN business, and is distinct from the LTO and the chip business. The WWRN biz is standards based and quite competitive.) Impressive performance results from AGPS when properly deployed. There are some absolutely kick-ass AGPS handsets in Japan: full VGA, and with Java's JSR179: many, many applications right away. The eventual goal is C-Plane, where the assistance data is via the telephony control plane. Kinda the opposite of SUPL, so much more intensive protocol efforts. But by far the fastest way to get a position fix, and most reliable for E911. > 2. I have heard elsewhere (Wikipedia) that in A-GPS the computation > effort is shared between the device and the A-GPS Server. According to > a previous post, the device just downloads the ephemeris table so > there isn't any actual "computation sharing", but rather a download of > a pre-computed table download. Correct? THERE are four basic sorts of GPS: Autonomous - the standard hand-held device that gets a fix in 1 to 3 minutes outdoors, or never indoors. Enhanced Autonomous "etonomous" - maybe this is what you heard about. Global Locate predicts the satellite orbits for 2, 4, 7, or 10 days in advance, and you download that. AKA "Long Term Orbit" or LTO. Marketed as "Quick GPS Connection" by HP, and "Express GPS Connect" by Global Locate. The advantage is you can get a 40 kB burst in seconds vs. 50 bits per second (or 0 bps if you're indoors) from the sky. You can cache and forward this file at your heart's content. Consumers don't pay for it: the device maker pays a little bit extra per chipset for this data. MS-Based - The handset tells the SUPL/C-Plane server it's MSISDN and cell tower info. The server responds with exactly the specific SVs that are visible right now, and the ephemeris for them. The MS (handset/mobile station/fill in your telephony GCA here...) computes the position for use on the handset. It can also send the information back to the server. The ephemeris is good for (on average) about 2 hours. MS-Assisted - The server tells the MS what measurements to make. The device responds with the measurements. The server computes (and "owns") the position. No ephemeris at all. This is a rather simple explanation, as the call flows are a little more involved. > 3. A-GPS involves additional data traffic and thus (potential) > additional costs. Does it use a normal GSM/GPRS IP-based data > transfer? does it use some out-of-band GSM/GPRS control messages? or > does it get data from broadcasts in the local cell (e.g. GSM > cell-broadcast)? C-PLANE is in the future, and not a part of Neo1973. OpenMoko AGPS will be configured by the user to connect to whatever SUPL or LTO server(s) you prefer. However, location information is very, very sensitive, so Sean and I have talked a lot about how to preserve QoS and security between competing GPS applications. Here's an example problem about security that touches on security, QoS, and other system issues: 1) Secure application needs position for reporting to a vertical-integrated application, with 50m accuracy. Needs it NOW, and so the LTO/MS-B scheme is desired. 2) Pedestrian application wants to do geo-blogging and needs to preserve battery power, and 100m accuracy is more than sufficient because we don't want to burn a lot of power. Etonomous or autonomous is fine. 3) Malicious app wants to deny service, so it starts the AGPS daemon with a connection to the wrong SUPL server, and asks for 5m accuracy periodic position fix. So app (1) can't get access to the AGPS connected to it's server. I would hope the OpenMoko community creates a network connectivity QoS agent that can trade off the cost vs performance vs power vs environment of the Neo1973 to make intelligent decisions based on these factors: - GPRS $$$$, WiFi $$, BT $, USB to a PC $0? - Power/Environment - GPRS most? Plugged into the wall/carkit - Burn, baby, burn! - User perferences about importance - high for MS-A, low for LTO?, but during E911, telephony regulations set the rules, not OpenMoko. Microsoft has something called the "Connection Manager" that deals with similar issues on Windows CE PocketPC. > 4. if the answer to above is GPRS: is it possible to estimate in > advance how much additional traffic (in Kbytes/day of full operation)? 2 days LTO is about 23 KB 7 days LTO is about 59 KB. > 5. Are there any known estimations on the overall (A)GPS performance > on the Neo (esp. fix time) SORRY, this is a Sean question. I can tell you it is really amazing. > 6. Coming to the Neo1973. In order to save costs, can the "Assisted" > function in A-GPS be disabled through software API? THE LTO fetching is the chance for some creative use of web-page caching, store & forward, etc. All sorts of scenarios are possible. The most "hands free" are one of these schemes: 6.1 Whenever the Neo1973 detects a really low cost data connection (USB sync to a PC, WiFi, etc), just get the latest LTO. 6.2 Have a cron job on your PC get LTO every 6 hours, then push it (or pull it) whenever your Neo1973 is connected to the PC. I saw some sync discussions in the community... 6.3 Variant on 6.1: don't *open* an expensive GPRS connection, but if one is already started, then piggyback on it. 6.4 ..... Of course, I've only discussed the Etonomous variant of AGPS. The MS-B and MS-A configurations have more complexity due to call flows and cost. > 7. Is it possible to tell whether A-GPS is actually in use or not? <rant> SEAN and I discussed some really fun things the GPS icon could show: - the "age" of your LTO - if the GPS is is running now, and if so, does it have a fix or not. - etc. The way we left it, there was plenty of chances for the OpenMokoids to get GPS-related info and map it into the GPS icon in non-linear ways. My personal favorites are: - make a portion of the GPS icon (e.g. the "solar panels") blink green for 0.5 seconds when there is a position fix, or purple if it is trying, but doesn't have anything yet. - Add solar panels to the GPS satellite icon if the signal strength is better - Change the GPS satellite body color if the LTO is getting "stale" - Or just superimpose those boring cell-phone indicators we're all used to. Sigh. </rant> ... So of course you could add the AGPS server info here. But Harald is right, this is a (boring compared to the fun stuff above) config item. If you have SUPL that you're paying for with some sort of operator plan, for the QoS and security reasons, you'll want some security on which SUPL server is selected. > 8. Is it possible to tell/know which is the A-GPS server currently in > use? yes. ------ _______________________________________________ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community