[Neo1973] AGPS - globallocal cuckoo's egg? Re: AGPS server questions
Robert Michel
openmoko at robertmichel.de
Wed Dec 13 13:57:42 CET 2006
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
>
More information about the community
mailing list