Re: gpsd and AGPS
On Fri, 28 Sep 2007 21:21:54 +0200, Ken Yale [EMAIL PROTECTED] wrote: You have 4 great ideas to discard or supplement the location cache: 1) CellID database inside the phone. ...or on a server, updated with contributions from many users. Note that such database can even be used by non-GPS-capable devices (e.g. running OpenMoko) to find their approximate location -- you can't get any precision, but at least it gives you the city and district, enough for tasks like finding a café nearby. 2) Power-on after a long timeout with a prompt to discard location. 3) Flight mode with no destination typing. This one should probably also have a prompt. Software shouldn't try to be smarter than the user. 4) Change cell network. With (1) working, this will rarely cause loss of location; the current location aid will rather be replaced with location data associated with the CellID. If the new location aid doesn't contradict the previous one, we're having a case of overlapping networks, and the previous data (more precise) shouldn't be discarded. Each of these sparks additional ideas and opportunities for improving autonomous GPS: - invalidate location cache from sort of travel manager application that knows you're flying because of schedule, change of timezone, invoking flight mode, etc. Could tie into the airport destination planning to get a rental car, directions, local information, etc. Could be useful, but only if it's transparent to the user and behaves predictably. Another issue is driving through tunnels. Garmin receivers used to have this problem: when you drive into a tunnel, the signal is lost, and upon exit, the last valid location (entry point) is used as aid. Norway (where I happen to live, so I'm affected by the issue) has a lot of tunnels, including the longest one in the world which is 24.5 km long. After driving though such a tunnel, the cached location is a hindrance rather than an aid. As the result, immediately after exit the device could show your location in some unrelated point. They fixed this in newer versions of the firmware by using the map data: when you enter a tunnel, the device looks up on the map where its exit(s) are (sometimes tunnels have branches inside), and uses those locations as aids when the satellite reception restores. Garmin devices also show your inferred location while in the tunnel, based on the tunnel shape on the map and your average speed during some time before entry. Neo has a technical advantage here because its accelerometers allow to perform some dead reckoning (combined with map data, if available). -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
On Mon, 03 Sep 2007 21:24:45 +0200, Ken Yale [EMAIL PROTECTED] wrote: Normally, ephemeris satellite data is downloaded at 50 bps from the satellites, but only when the signal strength is above about -142 dBm. Live ephemeris data is good for about 2 hours. With a data connection (I use a USB TCP/IP bridge to a PC, and then to the network), we can download 7 days of ephemeris in 3 or 4 seconds, independent of GPS signal conditions. Wasn't the last sentence supposed to say almanac? As I understand, the ephemeris data is short-lived and doesn't make sense to cache ahead of time. The almanac, on the other hand, is valid for some days once acquired. - database of cellID -- initial position look up. I understand network operators cherish and protect this database. Sure, the cell operators won't gladly share this data with anybody, but there's still something that could be done: the phone could learn the CellID - area association and use it later (if we are registered at some cell we've already been at, we can't be miles away from where we were last time at this cell). -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
On Fri, 28 Sep 2007 16:39:43 +0200, Ken Yale [EMAIL PROTECTED] wrote: Sure, the cell operators won't gladly share this data with anybody, but there's still something that could be done: the phone could learn the CellID - area association and use it later (if we are registered at some cell we've already been at, we can't be miles away from where we were last time at this cell). [Ken] Exactly! This would be a good feature for an Open SUPL server. The Broadcom SUPL server has this feature also. Wow, I didn't think about that! I was thinking about accumulating the learned CellID - area data in the phone, but storing it on an open server would take it one step further, so that the users can benefit from each other's contributions. [Ken[ Your second point: presumed proximity based on most recent location is hard-coded into the GTA01 GPS already. However, the GPS must derate the accuracy of the position as a function of time. Most GPS receivers have this feature already. One problem is when you've flown across an ocean, and a 1-or-2 day old (or even 8 hour old) position would actually be a negative assistance. To avoid this, my Garmin does the following: if you turn it on after not having used it for quite some time AND satellite reception is difficult at the moment (happens when I turn it on before driving out of the garage), it asks you: Have you moved hundreds of miles/km since the last time? [Ken] This could be a feature to be added to the GLLIN by FIC: detect this large position change. Some ideas: - flight mode - tap the city (or airport code) your flying to. Typing should be optional, of course. So if you just enable flight mode without typing the destination, it should invalidate the recent location aid. Change of the cell network ID (not the cell ID), i.e. roaming, is also an indication that we have probably travelled far. However, this one should be used with care because some networks in urban areas have poor coverage so that the phone enters roaming now and then and connects to some other local cell network. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: gpsd and AGPS
Hello, Good questons. See comments below. Ken -Original Message- From: Alexey Feldgendler [mailto:[EMAIL PROTECTED] Sent: Fri 9/28/2007 12:57 AM To: List for OpenMoko community discussion Subject: Re: gpsd and AGPS On Mon, 03 Sep 2007 21:24:45 +0200, Ken Yale [EMAIL PROTECTED] wrote: Normally, ephemeris satellite data is downloaded at 50 bps from the satellites, but only when the signal strength is above about -142 dBm. Live ephemeris data is good for about 2 hours. With a data connection (I use a USB TCP/IP bridge to a PC, and then to the network), we can download 7 days of ephemeris in 3 or 4 seconds, independent of GPS signal conditions. Wasn't the last sentence supposed to say almanac? As I understand, the ephemeris data is short-lived and doesn't make sense to cache ahead of time. The almanac, on the other hand, is valid for some days once acquired. [Ken] Almanac and Ephemeris. The Broadcom LTO data service has been purchased by FIC for use with the Hammerhead chipset inside the GTA01. LTO is a 7-day prediction of the ephemeris. - database of cellID -- initial position look up. I understand network operators cherish and protect this database. Sure, the cell operators won't gladly share this data with anybody, but there's still something that could be done: the phone could learn the CellID - area association and use it later (if we are registered at some cell we've already been at, we can't be miles away from where we were last time at this cell). [Ken] Exactly! This would be a good feature for an Open SUPL server. The Broadcom SUPL server has this feature also. [Ken[ Your second point: presumed proximity based on most recent location is hard-coded into the GTA01 GPS already. However, the GPS must derate the accuracy of the position as a function of time. Most GPS receivers have this feature already. One problem is when you've flown across an ocean, and a 1-or-2 day old (or even 8 hour old) position would actually be a negative assistance. [Ken] This could be a feature to be added to the GLLIN by FIC: detect this large position change. Some ideas: - flight mode - tap the city (or airport code) your flying to. - discard position - force the GPS to discard the GPS position cache - reset gps - actually, this feaure is already there: gllin -recover on the command line has a Reset GPS button in the OMGUI. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: gpsd and AGPS
Hello Alexey, You have 4 great ideas to discard or supplement the location cache: 1) CellID database inside the phone. 2) Power-on after a long timeout with a prompt to discard location. 3) Flight mode with no destination typing. 4) Change cell network. Each of these sparks additional ideas and opportunities for improving autonomous GPS: - invalidate location cache from sort of travel manager application that knows you're flying because of schedule, change of timezone, invoking flight mode, etc. Could tie into the airport destination planning to get a rental car, directions, local information, etc. - the cellID and cell network information has a lot of potential. Ken Yale -Original Message- From: Alexey Feldgendler [mailto:[EMAIL PROTECTED] Sent: Friday, September 28, 2007 08:14 To: List for OpenMoko community discussion Subject: Re: gpsd and AGPS On Fri, 28 Sep 2007 16:39:43 +0200, Ken Yale [EMAIL PROTECTED] wrote: Sure, the cell operators won't gladly share this data with anybody, but there's still something that could be done: the phone could learn the CellID - area association and use it later (if we are registered at some cell we've already been at, we can't be miles away from where we were last time at this cell). [Ken] Exactly! This would be a good feature for an Open SUPL server. The Broadcom SUPL server has this feature also. Wow, I didn't think about that! I was thinking about accumulating the learned CellID - area data in the phone, but storing it on an open server would take it one step further, so that the users can benefit from each other's contributions. [Ken] Your second point: presumed proximity based on most recent location is hard-coded into the GTA01 GPS already. However, the GPS must derate the accuracy of the position as a function of time. Most GPS receivers have this feature already. One problem is when you've flown across an ocean, and a 1-or-2 day old (or even 8 hour old) position would actually be a negative assistance. To avoid this, my Garmin does the following: if you turn it on after not having used it for quite some time AND satellite reception is difficult at the moment (happens when I turn it on before driving out of the garage), it asks you: Have you moved hundreds of miles/km since the last time? [Ken] This could be a feature to be added to the GLLIN by FIC: detect this large position change. Some ideas: - flight mode - tap the city (or airport code) your flying to. Typing should be optional, of course. So if you just enable flight mode without typing the destination, it should invalidate the recent location aid. Change of the cell network ID (not the cell ID), i.e. roaming, is also an indication that we have probably travelled far. However, this one should be used with care because some networks in urban areas have poor coverage so that the phone enters roaming now and then and connects to some other local cell network. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 GPS (was Re: gpsd and AGPS)
On Tue, 04 Sep 2007 17:27:18 +0200, Harald Welte [EMAIL PROTECTED] wrote: Just to clarify this: We have both GTA02 prototypes with GL/Broadcom and with a a competing firmware-based AGPS solution. Will the choice between them have settled by the time GTA02 becomes available to order? Would be a disappointment to order a device and be unable to develop/test/use GPS software on it because the other kind of chip has been chosen. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
Hello, On 9/3/07, Ian Stirling [EMAIL PROTECTED] wrote: http://en.wikipedia.org/wiki/A-GPS http://wiki.openmoko.org/wiki/Server:A-GPS I just keep wondering how hard it would be for us opensource prople to set up a network of assistance servers? Would a PC with an usb GPS device (and suitable os and software of course) be able to function as an assistance server? -- Regards, Torfinn Ingolfsen ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
Torfinn Ingolfsen wrote: Hello, On 9/3/07, Ian Stirling [EMAIL PROTECTED] wrote: http://en.wikipedia.org/wiki/A-GPS http://wiki.openmoko.org/wiki/Server:A-GPS I just keep wondering how hard it would be for us opensource prople to set up a network of assistance servers? Would a PC with an usb GPS device (and suitable os and software of course) be able to function as an assistance server? The A-GPS data aren't so dynamic as it sounds. I guess this could easyly be done with ipgk updates. Satellites may drift, but not so rapidly that something unexpected happens in days. I think... Regards Tilman Baumann ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
Tilman Baumann wrote: Torfinn Ingolfsen wrote: Hello, On 9/3/07, Ian Stirling [EMAIL PROTECTED] wrote: http://en.wikipedia.org/wiki/A-GPS http://wiki.openmoko.org/wiki/Server:A-GPS I just keep wondering how hard it would be for us opensource prople to set up a network of assistance servers? Would a PC with an usb GPS device (and suitable os and software of course) be able to function as an assistance server? The A-GPS data aren't so dynamic as it sounds. I guess this could easyly be done with ipgk updates. Satellites may drift, but not so rapidly that something unexpected happens in days. I think... Satellite drift isn't the interesting problem. That can indeed be predicted quite well with more precise orbits. The interesting part is ionospheric weather. This varies on a few-minute timescale. This is what http://wiki.openmoko.org/wiki/Server:A-GPS could answer. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: gpsd and AGPS
Hello, I'll answer the questions you raise, and clarify some points. Ken --- LTO is there now and it is free for FIC customers. Great! Is there a url for wget, or is it more complex than this? I forget the URL, I can get it later. Just look at the source code for lto_get -- the default URL is hard-coded there. Or alternatively, at some time in the past weeks, 12.5 minutes of signal to download the almanac (12 - which is good for a fair while. (some 3K of data) http://www.colorado.edu/geography/gcraft/notes/gps/gif/databits.gif There is an almanac hard-coded into the GLLIN. The GLLIN will download one if there is 12.5 minutes of good signal strength. It is also kept in NVRAM.dat. The almanac just tells you which SVs are in the sky, and is not a substitute for ephemeris. Knowing what to look for shortens your search time, but you still need ephemeris. I assume you mean LTO in the above. There was a lot above, so I'll say mostly. Are there any nice graphs (or even NMEA logs) of comparisons between positions of the LTO files, and downloaded? (or see the above URL/wget question) No. Even with LTO, the GLLIN will attempt to download fresh ephemeris. I'm assuming that LTO files are not simply copies of the almanac - but more precise orbital data - the almanac has data errors of 1m. Correct. The Broadcom WWRN will predict the SV track and create ephemeris in advance of broadcast by the SVs. long-term-orbit files, (who knows, GL may go down under lawsuits, and the servers fall over, be eaten by giant mice, ...) to providing only a snapshot of the partial data obtained during a short fix, and asking the server to provide a position. Knock on wood -- GL kept the WWRN running 5 years with no service interruptions, and separately, Broadcom has had good luck in recent lawsuits. I'm not sure I addressed your point. Right now, GTA01 does not offer MS-Assisted. I notice you mention GTA01 only - is there any significance in this? Unfortunately, GTA02 does not have a Broadcom GPS device inside. Ken Yale ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
On Tue, 04 Sep 2007 10:19:19 +0200, Ken Yale [EMAIL PROTECTED] wrote: I notice you mention GTA01 only - is there any significance in this? Unfortunately, GTA02 does not have a Broadcom GPS device inside. Am I getting it right that while GTA01 used to contain a GPS receiver, GTA02 doesn't have one? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
Alexey Feldgendler [EMAIL PROTECTED] wrote : Am I getting it right that while GTA01 used to contain a GPS receiver, GTA02 doesn't have one? I think he was referring to the fact that he works for broadcom and it would be easier for him to advice if it did. GTA01 and GTA02 have a Global locate chipset. --- G O Jones ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
Alexey Feldgendler pisze: On Tue, 04 Sep 2007 10:19:19 +0200, Ken Yale [EMAIL PROTECTED] wrote: I notice you mention GTA01 only - is there any significance in this? Unfortunately, GTA02 does not have a Broadcom GPS device inside. Am I getting it right that while GTA01 used to contain a GPS receiver, GTA02 doesn't have one? Has. Different manufacurer. -- *Bartlomiej Zdanowski* Programmer Product Research Development Department AutoGuard S.A. Place of registration: Regional Court for the Capital City of Warsaw Registration no.: 029534 Share capital: 1 059 000 PLN Polish VAT and tax ID no.: PL1132219747 Omulewska 27 street 04-128 Warsaw Poland phone +48 22 611 69 23 www.autoguard.pl http://www.autoguard.pl ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
On ti, 2007-09-04 at 09:01 +, Giles Jones wrote: Alexey Feldgendler [EMAIL PROTECTED] wrote : Am I getting it right that while GTA01 used to contain a GPS receiver, GTA02 doesn't have one? I think he was referring to the fact that he works for broadcom and it would be easier for him to advice if it did. GTA01 and GTA02 have a Global locate chipset. Sigh. Broadcom acquired Global Locate. However, for whichever reasons, GTA02 will have a different GPS chip. On the IRC channel, I heard that the new chip/vendor is more co-operative with free software, at least. Have I missed something by the way and has gllin for GTA01, OpenMoko 2007.2 been released yet? Since we have a Broadcom guy here, Ken, you know what the deal is with that? -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
Mikko J Rauhala wrote: Have I missed something by the way and has gllin for GTA01, OpenMoko 2007.2 been released yet? Since we have a Broadcom guy here, Ken, you know what the deal is with that? I'm working on providing an EABI toolchain to Ken, so that we can get a corresponding gllin binary. -- - Michael Lauer [EMAIL PROTECTED] http://openmoko.org/ Software for the worlds' first truly open Free Software mobile phone ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
Mikko J Rauhala [EMAIL PROTECTED] wrote : Sigh. Broadcom acquired Global Locate. However, for whichever reasons, GTA02 will have a different GPS chip. On the IRC channel, I heard that the new chip/vendor is more co-operative with free software, at least. That's good then. Sorry but not all of us have the time to spend on the IRC channel. --- G O Jones ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
Ken Yale wrote: Hello, Correct. The Broadcom WWRN will predict the SV track and create ephemeris in advance of broadcast by the SVs. long-term-orbit files, (who knows, GL may go down under lawsuits, and the servers fall over, be eaten by giant mice, ...) to providing only a snapshot of the partial data obtained during a short fix, and asking the server to provide a position. Knock on wood -- GL kept the WWRN running 5 years with no service interruptions, and separately, Broadcom has had good luck in recent lawsuits. I'm not sure I addressed your point. Right now, GTA01 does not offer MS-Assisted. Indeed. I was meaning with a hypothetical open-source driver. I notice you mention GTA01 only - is there any significance in this? Unfortunately, GTA02 does not have a Broadcom GPS device inside. If by this you mean that it's not got the GL hammerhead in, I'm rather annoyed. At no point has anyone from the core team said otherwise, I've been spending much of my dev time on the GTA01 on doing utterly pointless dead-end work on reverse engineering the hammerhead, when it has presumably been known to the core team for months that this was the case. The hammerhead hardware is quite featured, and would actually be significantly better than a simple device that outputs NMEA data, with a suitable driver. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GTA02 GPS (was Re: gpsd and AGPS)
On Tue, Sep 04, 2007 at 01:19:19AM -0700, Ken Yale wrote: I notice you mention GTA01 only - is there any significance in this? Unfortunately, GTA02 does not have a Broadcom GPS device inside. Just to clarify this: We have both GTA02 prototypes with GL/Broadcom and with a a competing firmware-based AGPS solution. It is quite normal to analyze different competing options during product development. GPS RF performance, power consumption, per-unit cost, but also RD cost are aspects that need to be compared. But for openmoko, there is one other big aspect: The hard to quantify but present cost of using a non-free software component in our system. As everyone understands, the choice of a softgps with non-free software components on the main CPU (application processor) has quite severe implications for a project that is otherwise entirely open source. Our whole development model, build system and distribution system are just not in any way set up to deal with non-free software. We simply are neither used to, nor prepared to build, maintain and distribut any non-free software. In addition, the GL/Broadcom licensing terms make it impossible to use any of the established (GPL/LGPL licenses for programs that interface closely with the GPS chip (i.e. link to GLL, liblto or others). The community constantly pushes their finger into this single non-free component. While GL/Broadcom's technical support has always been excellent, the details of the proprietary software licensing and its impact on OpenMoko itself are unfortunately far from being optimal. But as of now, nobody can tell what will be in the final product. Not even I know anything for sure at this point. We're analyzing all our options. I'd like to use this opportunity to thank GL (and Ken, specifically) for all their technical support so far. Cheers, -- - Harald Welte [EMAIL PROTECTED] http://openmoko.org/ Software for the world's first truly open Free Software mobile phone ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 GPS (was Re: gpsd and AGPS)
ti, 2007-09-04 kello 23:27 +0800, Harald Welte kirjoitti: Just to clarify this: We have both GTA02 prototypes with GL/Broadcom and with a a competing firmware-based AGPS solution. Thanks for the clarification, and apologies for spreading the premature word out on the street that the change was pretty much decided already. I appreciate the more-than-usually difficult decision process with the chip, and Ian Stirling's reverse-engineering work so far. (While my particular family would most likely continue to enjoy a reverse-engineered driver on the GTA01 for quite a while, it does undoubtedly lessen the motivation to do so quite a lot if the work will not be useful on GTA02...) Access to more raw GPS data, such as with the Hammerhead, would certainly be a bonus if indeed said reverse-engineering would succeed (and I have no doubt it would, given some time and effort); on the other hand, FIC likely couldn't ship a fully free solution by default anyway, at least in/through the US (maybe elsewhere as well depending on contractual obligations), so it would remain a sort of blemish on the otherwise free OpenMoko. Anyway, keep up the good work (I'll take Harald's word for it ;), Ken, with the gllin build, and the OM team with the hard calls. I would encourage Ian to continue working on the Hammerhead RE, but again, no one can really blame one for losing motivation at least until the situation clears up. Especially what with pretty much volunteer work and all (I presume). Cheers all around, -- Mikko Rauhala - [EMAIL PROTECTED] - URL:http://www.iki.fi/mjr/ Transhumanist - WTA member - URL:http://www.transhumanism.org/ Singularitarian - SIAI supporter - URL:http://www.singinst.org/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 GPS (was Re: gpsd and AGPS)
Mikko Rauhala wrote: ti, 2007-09-04 kello 23:27 +0800, Harald Welte kirjoitti: Just to clarify this: We have both GTA02 prototypes with GL/Broadcom and with a a competing firmware-based AGPS solution. Thanks for the clarification, and apologies for spreading the premature word out on the street that the change was pretty much decided already. I appreciate the more-than-usually difficult decision process with the chip, and Ian Stirling's reverse-engineering work so far. (While my Not only mine! particular family would most likely continue to enjoy a reverse-engineered driver on the GTA01 for quite a while, it does undoubtedly lessen the motivation to do so quite a lot if the work will not be useful on GTA02...) Access to more raw GPS data, such as with the Hammerhead, would certainly be a bonus if indeed said reverse-engineering would succeed (and I have no doubt it would, given some time and effort); on the other hand, FIC likely couldn't ship a fully free solution by default anyway, at least in/through the US (maybe elsewhere as well depending on contractual obligations), so it would remain a sort of blemish on the otherwise free OpenMoko. Especially as it offers the possibility of providing interesting performances that may be hard to achieve with a higher level chip - for example being able to completely turn off the GPS chip for several minutes, turn it on for 1s, and using knowlege of the GPS signal structure to pick when that 1s is, to get best position. Anyway, keep up the good work (I'll take Harald's word for it ;), Ken, with the gllin build, and the OM team with the hard calls. I would encourage Ian to continue working on the Hammerhead RE, but again, no one can really blame one for losing motivation at least until the situation clears up. Especially what with pretty much volunteer work and all (I presume). Cheers all around, ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
Luca Cabriolu wrote: Hi all, I am trying to understand how AGPS can work with gpsd daemon. In my undestanding, when I have an UMTS/GSM module and a GPS module supporting AGPS, I can retrieve Assistance Data for AGPS from UMTS/GSM. I believe this can be done through an AGPS control software running on a host processor. All this collected Data should be passed to GPS module through gpsd, I believe. At this point I'd like to understand, if it is really possible to do it through gpsd and in which way this can be done. Someone please help me to understand the way in which AGPS actually works. http://en.wikipedia.org/wiki/A-GPS http://wiki.openmoko.org/wiki/Server:A-GPS AGPS is solely a marketing term. It covers several different techniques. Whatever the case - the current binary GPS solution does not support this sort of AGPS - at least according to its help info. So, you need to find out how your phone provider broadcasts the assistance data, or how it accepts information from the phone to postprocess into a position, and then find out if the TI chipset in the phone is able to download/upload this data. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
Hi Ian, thanks for your answer. I'd like to know how AGPS is currently supported on the NEO 1973. Can you help me to understand how it works from a software and a hardware point of view? Thanks. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
Luca Cabriolu wrote: Hi Ian, thanks for your answer. I'd like to know how AGPS is currently supported on the NEO 1973. Can you help me to understand how it works from a software and a hardware point of view? Fortunately, the answer is very simple. Unfortunately, that answer is It's not. The binary GPS program seems to have the ability to communicate with AGPS servers run by Global Locate - however, these require a subscription by some third party willing to buy service. I don't know the prices. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: gpsd and AGPS
Hello, The AGPS functionality is split into these components: 1) Hammerhead GPS silicon - performs GPS measurements under control of (2). 2) Computation library - converts the GPS measurements into positions. The library is embedded into the GLLIN control program. NMEA output is via named pipe /tmp/nmeaNP. 3) OMGUI - user interface to test the GLLIN: stop/start, show signal strength, etc. 4) liblto - library to examine LTO expiration date 5) GPSD - standard GPSD with extensions to control host-based GLLIN. Here's the status of each: 1) Hammerhead is proven to work very well on GTA01 - I have measured down to -160 dBm sensitivity. The GTA01 antenna is VERY good, and the FIC designers did a great job keeping GPS RFI out of the antenna. 2) GLLIN is complete and tested for LTO AGPS. More on this below. The EULA/SLA for GLLIN is currently bouncing back forth between FIC and Broadcom. 3) OMGUI is done, but I'm sure a GTK+ hacker will find lots of cool ways to zoom it up, add maps, etc. 4) liblto is also done. 5) GPSD is started. OMGUI/src/gllin.cpp can be used to finish it to start/stop GLLIN. I hear the FIC team has the IPC mechanism running on it. (I forget the IPC name: DB, ADB, DBM??) AGPS Status: There are many levels to AGPS. Even a standard autonomous GPS receiver has a simple form of AGPS by virtue of caching recent information: position, time, ephemeris, clock frequency, etc. The GLLIN has this level of AGPS, embodied in two NVRAM.dat files kept in gpsd directory. (You can test factory cold start of GPS by removing these files). Beyond that, the only AGPS capability in the GTA01 is LTO. This is long-term orbit data files downloaded from the network. The delivery of the files can be done via wget or the lto_get facility included with OMGUI. FIC has purchased LTO delivery for the GTA01 for the lifetime of the product with the price of the Hammerhead chip. LTO is there now and it is free for FIC customers. Normally, ephemeris satellite data is downloaded at 50 bps from the satellites, but only when the signal strength is above about -142 dBm. Live ephemeris data is good for about 2 hours. With a data connection (I use a USB TCP/IP bridge to a PC, and then to the network), we can download 7 days of ephemeris in 3 or 4 seconds, independent of GPS signal conditions. When the GTA01 can make a data call, SUPL will be tested on the GLLIN. The choice of which SUPL server to connect to will be a command-line option to the GLLIN. The SUPL protocol is an OMA standard, so there will be competition in this arena. Broadcom sells a SUPL server, and we'll use it to test the GTA01 when this is possible, but there will not be any automatic lock-in to a specific server. When GTA01 is productized and customized by large integrators, there may be such lock-ins performed by the integrators that is not under control of FIC or Broadcom. Such a lock-in will be to meet the needs of the integrators' customer base, and would not affect the developer community. Behind the SUPL server are a bunch of other complicated servers and services that most network operators are getting into place. Here's some of the things a SUPL server needs to play well with: - access to the GPS ephemeris. There is yet another standard for this data pipe, and competition in this area. Of course Broadcom has a product for delivery of the ephemeris, as to others. - database of cellID -- initial position look up. I understand network operators cherish and protect this database. - interface to E911. This seems reasonable, but I don't know for sure about it. With C-Plane AGPS, E911 is definitiely there. GLLIN should be capable of supporting MS-BASED and MS-ASSISTED SUPL requests. Typically, SUPL-NI (Network Initiated) requests are signalled via a SUPL-NI data packet sent via SMS. I doubt this is available on the TI Calypso. Unfortunately, the TI Calypso GSM chipset does not provide control-plane access, so RRC and RRLP assistance is not available. So you can see that direct access to LTO via TCP/IP bypasses lots of complicated infrastructure, and can be accelerated to suit your style of use of the GTA01. On WindowsCE devices, the LTO mechanism is enhanced by these features, all of which can be added to GTA01 by the OpenMoko community: - cache LTO on a PC. Upon PC==GTA01 sync; squirt the LTO to the GTA01 - on GTA01: detect data connection creation and retrieve LTO if needed - on GTA01: add a cron job. - for specialized GTA01 environments: store forward the LTO file as needed. I hope this helps, Ken Yale -Original Message- From: Ian Stirling [mailto:[EMAIL PROTECTED] Sent: Mon 9/3/2007 9:38 AM To: List for OpenMoko community discussion Subject: Re: gpsd and AGPS Luca Cabriolu wrote: Hi Ian, thanks for your answer. I'd like to know how AGPS is currently supported on the NEO 1973. Can you help me to understand how it works from a software
Re: gpsd and AGPS
Ken Yale wrote: Hello, snip my largely incorrect comments thanks for the response! AGPS Status: snip Beyond that, the only AGPS capability in the GTA01 is LTO. This is long-term orbit data files downloaded from the network. The delivery of the files can be done via wget or the lto_get facility included with OMGUI. FIC has purchased LTO delivery for the GTA01 for the lifetime of the product with the price of the Hammerhead chip. LTO is there now and it is free for FIC customers. Great! Is there a url for wget, or is it more complex than this? Normally, ephemeris satellite data is downloaded at 50 bps from the satellites, but only when the signal strength is above about -142 dBm. Live ephemeris data is good for about 2 hours. With a data connection (I use a USB TCP/IP bridge to a PC, and then to the network), we can download 7 days of ephemeris in 3 or 4 seconds, independent of GPS signal conditions. Ephemeris data is broadcast for 12 of every 30s, by each satellite about its own orbit. So, you can get a good position if you've had 30s clear view of the sky within the last two hours, in order to download those 500 or so bits per satellite. Or alternatively, at some time in the past weeks, 12.5 minutes of signal to download the almanac (12 - which is good for a fair while. (some 3K of data) http://www.colorado.edu/geography/gcraft/notes/gps/gif/databits.gif I assume you mean LTO in the above. Are there any nice graphs (or even NMEA logs) of comparisons between positions of the LTO files, and downloaded? (or see the above URL/wget question) I'm assuming that LTO files are not simply copies of the almanac - but more precise orbital data - the almanac has data errors of 1m. snip So you can see that direct access to LTO via TCP/IP bypasses lots of complicated infrastructure, and can be accelerated to suit your style of use of the GTA01. On WindowsCE devices, the LTO mechanism is enhanced by these features, all of which can be added to GTA01 by the OpenMoko community: - cache LTO on a PC. Upon PC==GTA01 sync; squirt the LTO to the GTA01 - on GTA01: detect data connection creation and retrieve LTO if needed - on GTA01: add a cron job. - for specialized GTA01 environments: store forward the LTO file as needed. The hardware supports in principle more than this - http://wiki.openmoko.org/wiki/Server:A-GPS details some possibilities. But broadly, any assistance model is possible - SMOP -, from downloading long-term-orbit files, (who knows, GL may go down under lawsuits, and the servers fall over, be eaten by giant mice, ...) to providing only a snapshot of the partial data obtained during a short fix, and asking the server to provide a position. I hope this helps, Ken Yale I notice you mention GTA01 only - is there any significance in this? Thanks for the info! ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
