Salve Harald, Sean! I fear AGPS from globallocal is a coockoo's egg - they anounced that their AGPS chips cost only 5 US$ - I fear they will make money with their AGPS server services http://www.globallocate.com/NETWORK/NET_AGPS_SERVER_Frameset.htm Like selling cheap pringer or mobiles and make the money with ink or the phone tariff.
There are sources like http://igs.ifag.de/index_ntrip_cast.htm to get the GNSS data streams over the internet - for free. I'm registrated an can use their casts. The globallocal answers on my questions are diffuse and the information that AGPS is not usable without globallocate server > "Would be a RTCM 2.3 Typ 17 stream enough for AGPS?" > If it has a TCP/IP portal on the network side to reach LTO or > AGPS servers, and > would need a NAL on the handset side to connect to the GPS > control stack. NAL= > The AGPS features currently only expect a NAL (network abstraction > layer) to reach the AGPS servers. Routing to a server > "Would the binary from gobal locate allows to define an own routings to > a server?" > Right now the NAL is built in and assumes TCP/IP. > If you configured the AGPS NAL for a local proxy, then rerouted > to whatever you choose, you're all set. free routing possible, but what is the protocoll of the AGPS data that the globallocal chip expect? > "Would it be possible to run an own server (runnning open software)?" > You would need to: > - develop a SUPL protocol stack SUPL = a protocol from OMA, Open Mobil Alliance - where is it documented? > - get an assistance data feed. Network operators pay big $$$ > for this from > commercial providers. Developing your own is a major task. Just some stations - ntrip_cast for the beginning > - get authority from cell providers and network operators for > AGPS to go through them GPRS/SSL > (Note the "own" position fix for MS-A above: you could get > between an operator > and $$, a dangerous place to be!) > - develop a database of {cell-tower ==> lat,long,alt} > So it is a pretty big job with some major hurdles. O2 in Germany serves lat,long for free. There is also a chip from atmel "ublox" with Assist-Now(TM) and AFAIK is their documentation linkt to a Assist-Now(TM)-AGPS server. Maybe I don't know enough, but for me it smells like that globallocal AGPS is only used with AGPS servers - and with the risk that this server knows the location of every globallocal user after connection. I will go on this topic - but I fear that AGPS from globallocal is not open enough to feed my mobil with own data - independend of globallocal server. If this would be true, it would be disapointing. I would like to pay more for a device when AGPS would be independend of third party servers. Without asking globallocal again, do you have some more documentations about SUPL and NAL? Greetings, rob Sean Moss-Pultz schrieb am Sonntag, den 03. Dezember 2006 um 23:13h: > Robert- > > Sorry for the time it took me to get back to you on this one. Hopefully you > still remember your original question: > > " Sean I just want you to ask your AGPS experts - when you have to ask > externaly e.g. open local - you could wait a day for me doing a bit more > research: > "Would be a RTCM 2.3 Typ 17 stream enough for AGPS?" > "Would the binary from gobal locate allows to define an own routings to > a server?" > "Would it be possible to run an own server (runnnig open software)?" > > Here is your answer from a senior engineer at Global Locate: > > --- > > There is an "open" GPS > hw/fw solution out there, but it is open only because the fw side of it > went belly-up and the hw side decided to keep the silicon in their > catalog. But there's few PhDs in signal processing or navigation to > support it. PhDs have less time on their hands than GUI developers, > evidently. > > About the questions: > > What is the context? AGPS protocol stack support on a handheld, or > The AGPS server on the network side? > > I'll assume he's discussing the handset side. > > First some background. > > MS-A AGPS > server sends minimum ephemeris to handset (age is about 2 hours > or less) > handset replies with measurements; > server computes (and "owns") the position > Data rates are moderate, but the same for each position > > MS-B AGPS > server sends ephemeris for local conditions (age is about 2 > hours) > handset computes (and "owns") the position > data rates are about the same, but can be smaller for subsequent > fixes. > > LTO > LTO gets to handset via: > - GPRS > - WiFi > - Bluetooth > - USB > Only about 40KB needed every 2 days, although we prefer every 6 > hours for safety > if it is cheap enough. > > The AGPS features currently only expect a NAL (network abstraction > layer) to reach the AGPS servers. > For the LTO, same thing. > Right now, our only NAL is for TCP/IP, as User-plane (SUPL) for OMA > support is easiest. > In future, C-Plane may be offered by some GSM BBs and we can use that if > the network supports it. > > "Would be a RTCM 2.3 Typ 17 stream enough for AGPS?" > If it has a TCP/IP portal on the network side to reach LTO or > AGPS servers, and > would need a NAL on the handset side to connect to the GPS > control stack. > > "Would the binary from gobal locate allows to define an own routings to > a server?" > Right now the NAL is built in and assumes TCP/IP. > If you configured the AGPS NAL for a local proxy, then rerouted > to > whatever you choose, you're all set. > > "Would it be possible to run an own server (runnning open software)?" > You would need to: > - develop a SUPL protocol stack > - get an assistance data feed. Network operators pay big $$$ > for this from > commercial providers. Developing your own is a major task. > - get authority from cell providers and network operators for > AGPS to go through them > (Note the "own" position fix for MS-A above: you could get > between an operator > and $$, a dangerous place to be!) > - develop a database of {cell-tower ==> lat,long,alt} > So it is a pretty big job with some major hurdles. > > --- > > Hope that helps! > > -Sean > _______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
