Re: thoughts on A-GPS offline
Am Mi 18. März 2009 schrieb Helge Hafting: > Daniel Willmann wrote: > > On Tue, 10 Mar 2009 15:18:23 +0100 > > Helge Hafting wrote: > [...] > >> It was just to be safe. The documentation states that you might not > >> get a fix _at all_ if either position or time is outside the claimed > >> accuracy. Now, maybe it works with 3km anyway after the fixes that > >> prevents the chip-crashing exception. I happen to live about 6km away > >> from where I work, so 9km was a nice safe value. The default is > >> 300km, and "100km allows a more optimistic startup." Perhaps such > >> rough estimates is all that is needed, if it is only used to figure > >> which satellites that can be seen. > > > > If you don't mind testing please try changing pacc to 100km and see if > > it affects TTFF adversely in your case. If not we could just use that > > as a default. > > Shouldn't be too hard to test. > > I think I know one side of having accurate pacc: > > The first fix can happen with only two satellites. I have seen this > happen several times. It surprised me at first, but it makes sense. With > two satellites (and a reasonable clock), you get a big circle of > possible positions. But then there is the data from the "approximate > position". It puts you at some height above sea level. The big circle > intersects the earth surface at some angle, so with height, we now have > two possible spots instead of a big circle. Usually, only one spot will > be close to the approximate position, so that is where you are. > > That is an "optimistic startup scenario". A too spread out pacc means > both possible spots are within pacc range, and the FR will have to wait > for a third satellite to break the tie. > > If you travel a long way and still report the old position with a fake > precision pacc, then you might be close to the other of the two possible > satellite-based positions. You could then get a fake fix on the wrong > spot. As you and/or the satellites move, the wrong spot will move around > in strange ways at strange speeds. When more satellites show up, the > device might get really confused if it keeps trusting the approximate > position. Perhaps even rejecting them as "reflected signals" for a > while. Of course, only the manufacturer will know the exact details of > what might happen. > > Helge Hafting Wow, I had to read your posting twice to get how brilliant this analysis is. cheers jOERG signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
Daniel Willmann wrote: > On Tue, 10 Mar 2009 15:18:23 +0100 > Helge Hafting wrote: [...] >> It was just to be safe. The documentation states that you might not >> get a fix _at all_ if either position or time is outside the claimed >> accuracy. Now, maybe it works with 3km anyway after the fixes that >> prevents the chip-crashing exception. I happen to live about 6km away >> from where I work, so 9km was a nice safe value. The default is >> 300km, and "100km allows a more optimistic startup." Perhaps such >> rough estimates is all that is needed, if it is only used to figure >> which satellites that can be seen. > > If you don't mind testing please try changing pacc to 100km and see if > it affects TTFF adversely in your case. If not we could just use that > as a default. Shouldn't be too hard to test. I think I know one side of having accurate pacc: The first fix can happen with only two satellites. I have seen this happen several times. It surprised me at first, but it makes sense. With two satellites (and a reasonable clock), you get a big circle of possible positions. But then there is the data from the "approximate position". It puts you at some height above sea level. The big circle intersects the earth surface at some angle, so with height, we now have two possible spots instead of a big circle. Usually, only one spot will be close to the approximate position, so that is where you are. That is an "optimistic startup scenario". A too spread out pacc means both possible spots are within pacc range, and the FR will have to wait for a third satellite to break the tie. If you travel a long way and still report the old position with a fake precision pacc, then you might be close to the other of the two possible satellite-based positions. You could then get a fake fix on the wrong spot. As you and/or the satellites move, the wrong spot will move around in strange ways at strange speeds. When more satellites show up, the device might get really confused if it keeps trusting the approximate position. Perhaps even rejecting them as "reflected signals" for a while. Of course, only the manufacturer will know the exact details of what might happen. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
On Tue, 10 Mar 2009 15:18:23 +0100 Helge Hafting wrote: > I do not get 7s every time. This was an ideal test, I was standing in > a place with good visibility. the gps used 9 or so satellites. Then I > stopped tangogps and restarted it, and timed it from the moment the > tangogps screen showed. (So as to not include the startup time for > tangogps itself). The TTFF is usually a little longer inside a bus or > building. Okay, this still sounds really promising and matches my experience. Even when riding my bike I now usually get a fix within the first minute, mostly within 30 seconds. Before uploading ephemeris this often took several minutes (sometimes it wouldn't get a fix until I stood still for 20 seconds even after riding around for ~10 minutes). > > so the chip knows which SVs to search for. So a pacc of 3km or 9km > > shouldn't have any noticable effect. This is just guesswork though, > > so any results on your part would be greatly appreciated. > > It was just to be safe. The documentation states that you might not > get a fix _at all_ if either position or time is outside the claimed > accuracy. Now, maybe it works with 3km anyway after the fixes that > prevents the chip-crashing exception. I happen to live about 6km away > from where I work, so 9km was a nice safe value. The default is > 300km, and "100km allows a more optimistic startup." Perhaps such > rough estimates is all that is needed, if it is only used to figure > which satellites that can be seen. If you don't mind testing please try changing pacc to 100km and see if it affects TTFF adversely in your case. If not we could just use that as a default. Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
Daniel Willmann wrote: > On Wed, 04 Mar 2009 13:59:07 +0100 > Helge Hafting wrote: > >> Thanks a lot! >> I needed this one too, and now get 7s warm starts! >> http://git.freesmartphone.org/?p=framework.git;a=commitdiff;h=ad2ec48cdb5ab9bdddc15adfc05cbd2e5b8a2cee > > 7s TTFF is pretty good. I got that once, but usually I have about 16s > TTFF. > I do not get 7s every time. This was an ideal test, I was standing in a place with good visibility. the gps used 9 or so satellites. Then I stopped tangogps and restarted it, and timed it from the moment the tangogps screen showed. (So as to not include the startup time for tangogps itself). The TTFF is usually a little longer inside a bus or building. >> I also raised pacc from 3km to 9km, as I often enough travel a bit >> more than 3km with the gps unit off. > > I'm interested to hear how that affects TTFF. The way I understand it > initial position is only used to calculate which SVs are in view so the > chip knows which SVs to search for. So a pacc of 3km or 9km shouldn't > have any noticable effect. This is just guesswork though, so any > results on your part would be greatly appreciated. It was just to be safe. The documentation states that you might not get a fix _at all_ if either position or time is outside the claimed accuracy. Now, maybe it works with 3km anyway after the fixes that prevents the chip-crashing exception. I happen to live about 6km away from where I work, so 9km was a nice safe value. The default is 300km, and "100km allows a more optimistic startup." Perhaps such rough estimates is all that is needed, if it is only used to figure which satellites that can be seen. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
I'm not using ogpsd. The parser is written by I myself. My strategy is to filter out dumped ALM/EPH messages which contain zeros after SV id in payload. Need more tests to verify this can avoid chip crash :) 2009/3/9 Daniel Willmann (via Nabble) : > On Tue, 3 Mar 2009 06:47:26 -0800 (PST) > mqy wrote: > >> >> I've verified the issue on GPS receiver in GTA02: >> >> When dump ALM/EPH messages, in several messages, fields follow SV ID >> field in payload are filled with zeros. > > Okay, so what you're saying is that this commit > http://git.freesmartphone.org/?p=framework.git;a=commitdiff;h=ad2ec48cdb5ab9bdddc15adfc05cbd2e5b8a2cee > doesn't fix the situation for you? > If that is the case could you please send me the ALM/EPH messages that > you get when the chip crashes so I can take a look at it? > > Regards, > Daniel Willmann > > > ___ > Openmoko community mailing list > commun...@... > http://lists.openmoko.org/mailman/listinfo/community > > signature.asc (204 bytes) Download Attachment > > > This email is a reply to your post @ > http://n2.nabble.com/thoughts-on-A-GPS-offline-tp2338403p2446510.html > You can reply by email or by visting the link above. > > -- View this message in context: http://n2.nabble.com/thoughts-on-A-GPS-offline-tp2338403p2447874.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
On Tue, 3 Mar 2009 06:47:26 -0800 (PST) mqy wrote: > > I've verified the issue on GPS receiver in GTA02: > > When dump ALM/EPH messages, in several messages, fields follow SV ID > field in payload are filled with zeros. Okay, so what you're saying is that this commit http://git.freesmartphone.org/?p=framework.git;a=commitdiff;h=ad2ec48cdb5ab9bdddc15adfc05cbd2e5b8a2cee doesn't fix the situation for you? If that is the case could you please send me the ALM/EPH messages that you get when the chip crashes so I can take a look at it? Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
On Wed, 04 Mar 2009 13:59:07 +0100 Helge Hafting wrote: > Thanks a lot! > I needed this one too, and now get 7s warm starts! > http://git.freesmartphone.org/?p=framework.git;a=commitdiff;h=ad2ec48cdb5ab9bdddc15adfc05cbd2e5b8a2cee 7s TTFF is pretty good. I got that once, but usually I have about 16s TTFF. > I also raised pacc from 3km to 9km, as I often enough travel a bit > more than 3km with the gps unit off. I'm interested to hear how that affects TTFF. The way I understand it initial position is only used to calculate which SVs are in view so the chip knows which SVs to search for. So a pacc of 3km or 9km shouldn't have any noticable effect. This is just guesswork though, so any results on your part would be greatly appreciated. Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
Stefan Schmidt wrote: > Hello. > > On Tue, 2009-03-03 at 12:31, Helge Hafting wrote: >> Daniel Willmann wrote: >> >>> Now that hot-/warmstart with ephemeris playback works with the framework >>> we should try to get an open server with aiding data available ASAP. >>> >> I hope that fso-gpsd gets updated soon too > > Already done: > http://git.freesmartphone.org/?p=framework.git;a=commitdiff;h=5271e445b327c2132eee6a1f43fcf58c37c67e00 > http://git.freesmartphone.org/?p=framework.git;a=commitdiff;h=0838645958d50df38e64429a27672570bf58f8b4 Thanks a lot! I needed this one too, and now get 7s warm starts! http://git.freesmartphone.org/?p=framework.git;a=commitdiff;h=ad2ec48cdb5ab9bdddc15adfc05cbd2e5b8a2cee I also raised pacc from 3km to 9km, as I often enough travel a bit more than 3km with the gps unit off. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
I've verified the issue on GPS receiver in GTA02: When dump ALM/EPH messages, in several messages, fields follow SV ID field in payload are filled with zeros. Daniel Willmann wrote: > > On Sun, 1 Mar 2009 14:25:14 -0800 (PST) > mqy wrote: > >> " >> UBX-AID-EPH and UBX-AID-ALM Messages for Satellite without valid >> Orbits When polling UBX-AID-EPH or UBX-AID-ALM messages, satellites >> without valid ephemeris or almanac data will >> return a complete UBX-AID-EPH or UBX-AID-ALM message with all data >> words set to zero. This doesn’t comply >> with the protocol specification. Furthermore, u-blox 5 receivers with >> firmware V5.00 and earlier can run into a >> floating-point exception when fed with such “empty” ephemeris. >> " >> >> Is that the cause :D > > Yeah, thought that at first as well, but almanac data was okay at that > point. The position was not, however. I guess the problem the chip > tripped over is similar in both cases though. > > Regards, > Daniel Willmann > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/thoughts-on-A-GPS-offline-tp2338403p2415564.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
On Tue, 03 Mar 2009 12:31:00 +0100 Helge Hafting wrote: > Daniel Willmann wrote: > > > Now that hot-/warmstart with ephemeris playback works with the > > framework we should try to get an open server with aiding data > > available ASAP. > > > I hope that fso-gpsd gets updated soon too - it'd sure be nice to > take advantage of a recently saved ephemeris when restarting gps > software. fso-gpsd doesn't need to get updated, it just uses ogpsd which is saving/restoring the ephemeris received from the SVs already. For the improved ogpsd you will need a recent version of frameworkd as Stefan has already pointed out. Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
Hello. On Tue, 2009-03-03 at 12:31, Helge Hafting wrote: > Daniel Willmann wrote: > > > Now that hot-/warmstart with ephemeris playback works with the framework > > we should try to get an open server with aiding data available ASAP. > > > I hope that fso-gpsd gets updated soon too Already done: http://git.freesmartphone.org/?p=framework.git;a=commitdiff;h=5271e445b327c2132eee6a1f43fcf58c37c67e00 http://git.freesmartphone.org/?p=framework.git;a=commitdiff;h=0838645958d50df38e64429a27672570bf58f8b4 regards Stefan Schmidt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
Daniel Willmann wrote: > Now that hot-/warmstart with ephemeris playback works with the framework > we should try to get an open server with aiding data available ASAP. > I hope that fso-gpsd gets updated soon too - it'd sure be nice to take advantage of a recently saved ephemeris when restarting gps software. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
On Sun, 1 Mar 2009 14:25:14 -0800 (PST) mqy wrote: > " > UBX-AID-EPH and UBX-AID-ALM Messages for Satellite without valid > Orbits When polling UBX-AID-EPH or UBX-AID-ALM messages, satellites > without valid ephemeris or almanac data will > return a complete UBX-AID-EPH or UBX-AID-ALM message with all data > words set to zero. This doesn’t comply > with the protocol specification. Furthermore, u-blox 5 receivers with > firmware V5.00 and earlier can run into a > floating-point exception when fed with such “empty” ephemeris. > " > > Is that the cause :D Yeah, thought that at first as well, but almanac data was okay at that point. The position was not, however. I guess the problem the chip tripped over is similar in both cases though. Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
From [ http://www.u-blox.cn/customersupport/gps.g5/ublox5_Fw5.00_Release_Notes(GPS.G5-SW-08019).pdf ]: " UBX-AID-EPH and UBX-AID-ALM Messages for Satellite without valid Orbits When polling UBX-AID-EPH or UBX-AID-ALM messages, satellites without valid ephemeris or almanac data will return a complete UBX-AID-EPH or UBX-AID-ALM message with all data words set to zero. This doesn’t comply with the protocol specification. Furthermore, u-blox 5 receivers with firmware V5.00 and earlier can run into a floating-point exception when fed with such “empty” ephemeris. " Is that the cause :D Daniel Willmann wrote: > > > Yes and that's what ogpsd does already. It has been saving/restoring > almanac for months, ephemeris was disabled up until recently because > there was a bug that prevented the GPS chip from doing anything useful > after they were restored to the chip. > > ... ... > > Regards, > Daniel Willmann > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/thoughts-on-A-GPS-offline-tp2338403p2406454.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
On Sun, 1 Mar 2009 21:39:25 +0100 Raphaël Jacquot wrote: > On Sun, Mar 01, 2009 at 08:31:16PM +0100, Daniel Willmann wrote: > > Now that hot-/warmstart with ephemeris playback works with the > > framework we should try to get an open server with aiding data > > available ASAP. > > is there a way to get the ephemeris data from the gps receiver at > some point ? it could be stored on the phone and used as a > calculation aide... Yes and that's what ogpsd does already. It has been saving/restoring almanac for months, ephemeris was disabled up until recently because there was a bug that prevented the GPS chip from doing anything useful after they were restored to the chip. The chip will use all available data to calculate the fix. With restoring ephemeris this means a time to first fix of about 16 seconds at the moment. Not sure how much faster we can get. Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
On Sun, Mar 01, 2009 at 12:57:30PM -0800, mqy wrote: > > U-blox receiver allows polling AID-EPH, AID-ALM data. > For each type, we can poll 32 messages for 32 satellites. > The precondition is: current fix is valid -- at least 3 SVs has valid EPH(or > ALM?) data. > > These data get invalid 2~4 hours later, > can be stored into files, and load into GPS receiver when needed and they > are valid. they can probably still be used to get a rough estimate ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
U-blox receiver allows polling AID-EPH, AID-ALM data. For each type, we can poll 32 messages for 32 satellites. The precondition is: current fix is valid -- at least 3 SVs has valid EPH(or ALM?) data. These data get invalid 2~4 hours later, can be stored into files, and load into GPS receiver when needed and they are valid. I've tried this, not sure whether it works or not, need more tests:) AGPS-online works fine. Raphaël Jacquot wrote: > > On Sun, Mar 01, 2009 at 08:31:16PM +0100, Daniel Willmann wrote: >> Now that hot-/warmstart with ephemeris playback works with the framework >> we should try to get an open server with aiding data available ASAP. > > is there a way to get the ephemeris data from the gps receiver at some > point ? > it could be stored on the phone and used as a calculation aide... > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/thoughts-on-A-GPS-offline-tp2338403p2406026.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
On Sun, Mar 01, 2009 at 08:31:16PM +0100, Daniel Willmann wrote: > Now that hot-/warmstart with ephemeris playback works with the framework > we should try to get an open server with aiding data available ASAP. is there a way to get the ephemeris data from the gps receiver at some point ? it could be stored on the phone and used as a calculation aide... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
Hello, On Tue, 17 Feb 2009 13:07:54 +0100 Rikard Nilsson wrote: > would it be possible to get the satelite information that we get from > u-blox from somewhere else? > somewhere that dont require user account? there are three possibilities that I see here: 1) mirror the data from u-blox somewhere 2) See whether we can use the information from http://www.ngs.noaa.gov/orbits/ to provide our own aiding data 3) Set up a stationary GPS receiver and use aiding data from there 1: Someone said that u-blox explicitly allows redistribution of their AGPS online data. This would be great since we already have all the data in UBX format. 2: Calculating almanac/ephemeris data from the files present in ftp://igs.ensg.ign.fr/pub/igs/products/ should be possible, but is far less straight forward than variant 1. Additionally to studying ICD-GPS-200 (http://www.navcen.uscg.gov/PUBS/gps/icd200/icd200cw1234.pdf) one would need to parse the sp3c format: ftp://igscb.jpl.nasa.gov/pub/data/format/sp3c.txt 3: This would be a pretty simple and good way of setting up our own aiding server if 1 doesn't work out. The problem with this approach is that we only get ephemeris for SVs in our view so if I set up one station in Germany it wont help at all in the US. This could be worked around by having many such stations all over the world. Now that hot-/warmstart with ephemeris playback works with the framework we should try to get an open server with aiding data available ASAP. Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
Yes, ogpsd within frameworkd saves/loads u-blox AID HUI/ALM/EPH messages. u-blox A-GPS online messages are of AID message types. Let's read the html content dumped from ghex: > b5 62 0b 01 30 00 2d 26 29 f3 ba ca 13 1a ec b7 6b 18 20 a1 07 00 00 00 ee > 05 c4 7a 67 0e 00 00 > > 00 00 f4 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 e8 ce b5 > 62 0b 31 68 00 03 00 > > 00 00 80 59 4d 00 00 91 7b 00 51 1b 68 00 06 8a 7e 00 cd 3c 55 00 f7 fb b4 > ff c4 3b 3c 00 2e 00 > > 00 00 3b 09 2e 00 d9 fc 3c 00 0e 2e 37 00 9c 27 f2 ff 05 3d fd ff bc 6c f6 > ff a1 db 1c 00 8f f7 > > 0d 00 7f c4 3b 00 0d c9 ff ff 33 17 41 00 25 59 00 00 22 32 c1 ff 24 44 0c > 00 e5 50 46 00 16 a4 > > ff ff 33 06 3c 00 e2 f7 b5 62 0b 31 68 00 06 00 00 00 80 59 4d 00 00 90 7b > 00 51 1b 60 00 06 8a > > 7e 00 cd 3c 55 00 f6 fb b4 ff c4 3b 20 00 82 ff 00 00 10 12 08 00 0b fe 20 > 00 75 5d 34 00 c2 12 > > ae ff 02 fb fd ff 4e 22 ec ff a1 0e 1d 00 79 ca 0d 00 7c c4 3b 00 0f 3c 00 > 00 d4 c1 f8 ff 26 f8 > > ff ff dc 30 0f 00 c4 df 0b 00 e7 c0 95 ff 0c a8 ff ff 3b 0b 20 00 2b 9d b5 > 62 0b 31 68 00 19 00 > > 00 00 80 59 4d 00 00 92 7b 00 51 1b 70 00 06 8a 7e 00 cd 3c 55 00 f0 fb b4 > ff c4 3b 6b 00 db 00 > > 00 00 1f a6 1e 00 ff 0c 6b 00 8a bb 31 00 cc bd ea ff 06 1a 0b 00 88 76 0a > 00 a1 9b 07 00 27 59 > > 0d 00 7f c4 3b 00 b8 39 00 00 22 17 98 ff 27 12 00 00 c8 d0 70 00 cd 13 27 > 00 b7 86 fa ff 77 a6 > > ff ff eb 11 6b 00 9e ee b5 62 0b 31 68 00 13 00 00 00 00 f1 4d 00 00 90 7b > 00 51 1b 60 00 06 8a > > 7e 00 cd 3c 55 00 e1 fb b4 ff c3 3b 0c 00 fb ff 00 00 46 46 04 00 57 00 0c > 00 29 41 2f 00 48 c4 > > d7 ff 02 49 00 00 75 0b a2 ff a1 b9 1c 00 3a 5d 0e 00 1c c3 3b 00 14 3d 00 > 00 cb 85 b9 ff 27 17 > > 00 00 68 fa 05 00 f0 fa 0d 00 07 56 28 00 c0 a9 ff ff 59 10 0c 00 30 ab b5 > 62 0b 31 68 00 0d 00 > > 00 00 80 59 4d 00 00 90 7b 00 51 1b 60 00 06 8a 7e 00 cd 3c 55 00 e8 fb b4 > ff c4 3b 29 00 0b 00 > > 00 00 c8 c3 25 00 b1 09 29 00 39 9f 24 00 00 9d 3e 00 01 0f 08 00 65 c0 ed > ff a1 85 1d 00 a4 18 > > 0e 00 7c c4 3b 00 94 e8 ff ff d3 5b 00 00 28 d7 ff ff 20 85 8f ff 3d 86 0f > 00 60 1c 5a 00 25 ae > > ff ff 94 01 29 00 0d b3 b5 62 0b 31 68 00 10 00 00 00 80 59 4d 00 00 90 7b > 00 51 1b 60 00 06 8a > > 7e 00 cd 3c 55 00 eb fb b4 ff c4 3b 1d 00 e7 ff 00 00 cd e8 09 00 9d f1 1d > 00 74 3a 31 00 84 6b > > 89 ff 02 a4 f3 ff 15 cc 98 ff a1 fa 0c 00 94 1a 0e 00 63 c4 3b 00 e7 d7 ff > ff 4a a6 fe ff 27 3a > > 00 00 19 e8 6d 00 f0 d2 20 00 cc 99 42 00 53 a6 ff ff 6f ee 1d 00 be a9 b5 > 62 0b 31 68 00 17 00 > > 00 00 80 59 4d 00 00 91 7b 00 51 1b 68 00 06 8a 7e 00 cd 3c 55 00 d5 fb b4 > ff c4 3b 66 00 06 00 > > 00 00 ec b1 32 00 a2 08 66 00 14 e9 2a 00 af 4b 56 00 02 2f 07 00 b4 41 f6 > ff a1 a1 1c 00 0f 39 > > 0d 00 7d c4 3b 00 91 31 00 00 68 58 fc ff 27 f3 ff ff e4 48 91 ff 75 ca 0e > 00 3b 50 5e 00 a1 aa > > ff ff 32 fe 66 00 28 bd b5 62 0b 31 68 00 07 00 00 00 80 59 4d 00 00 90 7b > 00 51 1b 60 00 06 8a > > 7e 00 cd 3c 55 00 e9 fb b4 ff c4 3b 1b 00 fd ff 00 00 ca fb 02 00 04 0a 1b > 00 d3 73 33 00 ad 74 > > 71 00 01 79 08 00 ac 04 2e 00 a1 5e 06 00 05 64 0d 00 45 c4 3b 00 bc df ff > ff 5a 61 74 00 27 c0 > > ff ff 7f 27 58 00 77 90 28 00 53 f6 32 00 7c a3 ff ff 10 10 1b 00 88 4b b5 > 62 0b 31 68 00 15 00 > > 00 00 80 59 4d 00 00 90 7b 00 51 1b 60 00 06 8a 7e 00 cd 3c 55 00 e7 fb b4 > ff c4 3b 5f 00 f0 ff > > 00 00 9a e3 03 00 51 06 5f 00 ad bd 3d 00 0f b8 df ff 07 f8 04 00 91 5c 7e > 00 a1 03 09 00 4a 19 > > 0d 00 7c c4 3b 00 3d 55 00 00 e3 4e 49 00 26 b8 ff ff 62 b9 0f 00 94 48 23 > 00 70 fd 28 00 9d a1 > > ff ff 27 18 5f 00 0c b6 b5 62 0b 30 28 00 19 00 00 00 ee 05 00 00 9f 60 59 > 00 b3 10 63 00 00 48 > > fd ff f7 0c a1 ff 64 8a b8 ff b0 01 ce ff 80 ec 45 00 e5 00 1f 00 ac f0 b5 > 62 0b 30 28 00 13 00 > > 00 00 ee 05 00 00 32 2a 53 00 f9 09 63 00 00 5c fd ff f1 0d a1 ff 4b ac 14 > 00 7d 23 f0 ff 37 ec > > . Each individual message format is: 1. head: b5 62; 2. the message class/id, e.g. 0b 01, 0b 30, 0b 31; 3. 2 bytes content length; 4. message content; 5. 2 bytes checksum. There is no message head in offline data file from u-blox (e.g, http://alp.u-blox.com/current_1d.alp), this prevents us from extracting (and/or calculate) AID data then load into u-blox GPS receiver. As of HUI/ALM/EPH, ANTARIS_Protocol_Specification(GPS.G3-X-03002).chm says: See ICD-GPS-200 for a full description of the contents of... Sigh, If freerunner has flash memory, the offline data can be directly submitted to u-blox GPS receiver. Helge Hafting wrote: > > Cédric Berger wrote: >> On Wed, Feb 18, 2009 at 17:49, Al Johnson >> wrote: >>> I may be misunderstanding the suggestion, but I don't think it had >>> anything to >>> do with data from ublox. The suggestion was to use data sent by other >>> freerunner users instead of the data supplied by ublox. >> >> As I understood the suggestion was in reply to : >> It is not a problem that user account is required when download u-blox online aiding
Re: thoughts on A-GPS offline
Timo Juhani Lindfors wrote: > > >> It is already possible to set up a free server for almanac data, as >> saving and loading almanac data works well and speed up TTFF some. > > But where do we get this almanac data? Can we redistribute what > u-box.com sends us? > Almanac data is valid for a couple of months, so normally you use the almanac that was auto-saved last time you used your gps. If someone set up a free server, then we can also upload almanac data there, and download it to speed up TTFF in cases where the gps hasn't been used for 2 months (or a newly flashed image overwrote the locally saved almanac). Of course, a locally saved almanac will usually do the trick, so such a service becomes more interesting when the epheremis can be saved as well. (once the bugs in ephemeris uploading gets fixed - currently this can fail rather badly, yielding no fix at all) Ephemeris data is only valid for 30min or so. Saving the ephemeris locally helps if your gps app crash and gets restarted, but it won't help you the following day. A server could help though. -- View this message in context: http://n2.nabble.com/thoughts-on-A-GPS-offline-tp2338403p2366825.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
> But where do we get this almanac data? Can we redistribute what > u-box.com sends us? AFAIK, the almanac data that framworkd saves from the GPS can come from u-blox but can also come directly from the GPS satellites. So we could try to setup some kind of peer-to-peer distribution of the data downloaded from the satellites. Of course, that presumes we have the right to distribute the satellite's data. Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
Helge Hafting writes:
> As far as I know - we do know the format. The SHR distribution
Yes frameworkd ogpsd has some info about it:
# Feed GPS with position and time
self.send("AID-INI", 48, {"X" : pos.get("x", 0) , "Y" : pos.get("y", 0) , "Z" :
pos.get("z", 0), \
"POSACC" : pacc, "TM_CFG" : 0 , "WN" : wn , "TOW" : tow , "TOW_NS" :
0 , \
"TACC_MS" : tacc , "TACC_NS" : 0 , "CLKD" : 0 , "CLKDACC" : 0 ,
"FLAGS" : flags })
# Feed gps with almanac
if self.aidingData.get( "almanac", None ):
for k, a in self.aidingData["almanac"].iteritems():
logger.debug("Loaded almanac for SV %d" % a["SVID"])
self.send("AID-ALM", 40, a);
Good to know that the hope is not lost! :-)
> It is already possible to set up a free server for almanac data, as
> saving and loading almanac data works well and speed up TTFF some.
But where do we get this almanac data? Can we redistribute what
u-box.com sends us?
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
Cédric Berger wrote: > On Wed, Feb 18, 2009 at 17:49, Al Johnson > wrote: >> I may be misunderstanding the suggestion, but I don't think it had anything >> to >> do with data from ublox. The suggestion was to use data sent by other >> freerunner users instead of the data supplied by ublox. > > As I understood the suggestion was in reply to : > >>> It is not a problem that user account is required when download u-blox >>> online >>> aiding data. >> It is a problem since u-blox might go out of business and you might >> not want to tell them where you are all time. Their server also might >> be down. There are plenty of reasons to remove dependency to any >> single party. > > The problem is that data from u-blox is a proprietary format, and as > far as I know, we do not know yet how to create the same data that can > be pushed to the GPS chip. As far as I know - we do know the format. The SHR distribution already saves such data before turning the gps off, and restores it when you turn it on so you get the first fix quicker. Not all the data is used at the moment, because the process sometimes fail yelding long startup times. But that should only be a debugging problem. It is already possible to set up a free server for almanac data, as saving and loading almanac data works well and speed up TTFF some. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
On Wed, Feb 18, 2009 at 17:49, Al Johnson wrote: > I may be misunderstanding the suggestion, but I don't think it had anything to > do with data from ublox. The suggestion was to use data sent by other > freerunner users instead of the data supplied by ublox. As I understood the suggestion was in reply to : >> It is not a problem that user account is required when download u-blox online >> aiding data. > It is a problem since u-blox might go out of business and you might > not want to tell them where you are all time. Their server also might > be down. There are plenty of reasons to remove dependency to any > single party. The problem is that data from u-blox is a proprietary format, and as far as I know, we do not know yet how to create the same data that can be pushed to the GPS chip. So for now we need to get this info from u-blox . Hence the account problem. I understood the suggestion just as way to cache this info in response to the availability problem for u-blox online service. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
On Wednesday 18 February 2009, Cédric Berger wrote: > On Wed, Feb 18, 2009 at 16:52, Helge Hafting wrote: > > Timo Juhani Lindfors wrote: > >> mqy writes: > >>> It is not a problem that user account is required when download u-blox > >>> online aiding data. > >> > >> It is a problem since u-blox might go out of business and you might > >> not want to tell them where you are all time. Their server also might > >> be down. There are plenty of reasons to remove dependency to any > >> single party. > > > > It is possible to start an open service, with mirrors. Interested people > > can set their freerunners to send in good aiding data when they have it > > (i.e. when using the gps and a network is available.) > > Infos downloaded from u-blox are only valid for some time. So if > server is down for more than just a short time, it won't help much. > And I did not check but not I am not sure u-blox terms of service > allow to redistribute... I may be misunderstanding the suggestion, but I don't think it had anything to do with data from ublox. The suggestion was to use data sent by other freerunner users instead of the data supplied by ublox. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
On Wed, Feb 18, 2009 at 16:52, Helge Hafting wrote: > Timo Juhani Lindfors wrote: >> mqy writes: >>> It is not a problem that user account is required when download u-blox >>> online >>> aiding data. >> >> It is a problem since u-blox might go out of business and you might >> not want to tell them where you are all time. Their server also might >> be down. There are plenty of reasons to remove dependency to any >> single party. > > It is possible to start an open service, with mirrors. Interested people > can set their freerunners to send in good aiding data when they have it > (i.e. when using the gps and a network is available.) Infos downloaded from u-blox are only valid for some time. So if server is down for more than just a short time, it won't help much. And I did not check but not I am not sure u-blox terms of service allow to redistribute... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
Timo Juhani Lindfors wrote: > mqy writes: >> It is not a problem that user account is required when download u-blox online >> aiding data. > > It is a problem since u-blox might go out of business and you might > not want to tell them where you are all time. Their server also might > be down. There are plenty of reasons to remove dependency to any > single party. It is possible to start an open service, with mirrors. Interested people can set their freerunners to send in good aiding data when they have it (i.e. when using the gps and a network is available.) Such a update gives away where you are, because the satellite constellation is only seen from part of the world. But I believe this part is large enough for privacy. People using the service don't need to give away much. In an extreme case they will download ephemeris data for _all_ satellites, and then do the processing based on approximate location in the phone itself. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
mqy writes: > It is not a problem that user account is required when download u-blox online > aiding data. It is a problem since u-blox might go out of business and you might not want to tell them where you are all time. Their server also might be down. There are plenty of reasons to remove dependency to any single party. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
It is not a problem that user account is required when download u-blox online aiding data. The download protocol is fairly simple, can be implemented within several hours in C. (1) appaly for a free account by sending a email to u-blox (2) format request package by filling in user/password/lat/lon and other optional data such as pacc, (3) submit request and get response data, (4) parse aiding data from the reply (it's a block of binary data after header lines), (5) write the binary data to GPS device. The binary data block contains about 50+ individual aiding messages The account is free. AFAIK, u-blox AsssistNow service should be one of the most open/free A-GPs services, and the up-to-14 days offline data is very attractive comparing to others. What I'm concern is: don't know how to eat the "big cake" without knowing the format -- unlike online data, there is no ubx binary message headers (0xB5, 0x62) inside offline file. I guess, each alp file (N days) should be contains the following data: time range(from, to): each file contains data of [1,2,3,5,7,10,14] days region IDs: the earth is divided into R regions each cover a (lat/lon?) area. satellite IDs: 24 satellites each has it's unique orbit. region visible satellites: at any time only several satellites visible to a user. differential almanac correction data: for each satellite (at the unit of hours). Nothing helps regardless where the data come from, if either don't know how to extract aiding data from offline data, or data format in-compatible. Rikard Nilsson wrote: > > would it be possible to get the satelite information that we get from > u-blox from somewhere else? > somewhere that dont require user account? > > /rikard > > On Tue, Feb 17, 2009 at 12:41 PM, Timo Juhani Lindfors > wrote: >> mqy writes: >>> I think get locations by cell id is especially useful in case of weak or >>> no >>> GPS signals. >>> I'll have a look at opencellid, thanks. >> >> Note also that ogpsd of frameworkd supports sending this off-line >> aiding data. >> >> >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/thoughts-on-A-GPS-offline-tp2338403p2340696.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
Well, i put a tarball together with my scripts and put it on my website. http://www.kapitein.org/openmoko Please read it carefully before installing. All feedback is welcome ofcourse. Kind regards, Ed On Tue, 2009-02-17 at 11:42 +0200, Risto H. Kurppa wrote: > On Tue, Feb 17, 2009 at 10:40 AM, Ed Kapitein wrote: > > Hi Rikard, > > > > Yes, take a look at www.opencellid.org. > > This will give you your rough location and you can use that to get the > > agps data for your area. > > > > I have some scripts that will do that for you, so just let me know if > > you are intressted. > > > > Kind regards, > > Ed > > Yes we're interested! > Show us what you have. I'd like to see things like these to be easy to > install & use, an ipkg package would be nice :) > When someone posted the agps program to opkg.org I was inspired to try > it and it seems to work very well, it's fast to get the fix. If agps > would get the rough location information from opencellid I suppose it > would be even faster (though gprs connection is the thing that slows > down this a lot). But using only opencellid would give you a rough > estimation of the location quickly also when you don't have time to > run gprs to download the agps data. Then if only this rough location > could be given to GPS so apps (tango, navit etc) could use it.. > > r > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
would it be possible to get the satelite information that we get from u-blox from somewhere else? somewhere that dont require user account? /rikard On Tue, Feb 17, 2009 at 12:41 PM, Timo Juhani Lindfors wrote: > mqy writes: >> I think get locations by cell id is especially useful in case of weak or no >> GPS signals. >> I'll have a look at opencellid, thanks. > > Note also that ogpsd of frameworkd supports sending this off-line > aiding data. > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
mqy writes: > I think get locations by cell id is especially useful in case of weak or no > GPS signals. > I'll have a look at opencellid, thanks. Note also that ogpsd of frameworkd supports sending this off-line aiding data. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
Should be. I think the major consideration of u-blox A-GPS is to speed up TTFF, decrease the TTFF from at 40 seconds or so to 10 seconds or so. A-GPS online needs network connection, if network connection is unavailable, AssistNow offline or something else are expected to provide initial aiding data such as almanach and/or ephemeris. Most of the time user know his/her location, but may unable to get GPS fix due to bad environment (e.g. buildings). If we have aiding data, we can submit them to GPS chip. What data to submit depends on your current location and time. Location can be specified by (1) picking up from map, (2) or last valid location recorded by GPS software (3) or from phone network (some service providers provide this kind of service with charge fee). I think get locations by cell id is especially useful in case of weak or no GPS signals. I'll have a look at opencellid, thanks. Rikard Nilsson wrote: > >> What about if we hack the data format of u-blox AGPS offline file, and >> extract data for current location and time? location can be specified by >> clicking map, time from local system time. If we could, we would be able >> to >> submit data to GPS chip as AGPS online message on demand. What do you >> think? > > Wouldnt it be possible to get the location from the gsm-network in some > way? > > /Rikard > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/thoughts-on-A-GPS-offline-tp2338403p2340272.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
Ed Kapitein writes: > I have some scripts that will do that for you, so just let me know if > you are intressted. Note that we can get the whole opencellid.org database and access it offline. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
On Tue, Feb 17, 2009 at 10:40 AM, Ed Kapitein wrote: > Hi Rikard, > > Yes, take a look at www.opencellid.org. > This will give you your rough location and you can use that to get the > agps data for your area. > > I have some scripts that will do that for you, so just let me know if > you are intressted. > > Kind regards, > Ed Yes we're interested! Show us what you have. I'd like to see things like these to be easy to install & use, an ipkg package would be nice :) When someone posted the agps program to opkg.org I was inspired to try it and it seems to work very well, it's fast to get the fix. If agps would get the rough location information from opencellid I suppose it would be even faster (though gprs connection is the thing that slows down this a lot). But using only opencellid would give you a rough estimation of the location quickly also when you don't have time to run gprs to download the agps data. Then if only this rough location could be given to GPS so apps (tango, navit etc) could use it.. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
Hi Rikard, Yes, take a look at www.opencellid.org. This will give you your rough location and you can use that to get the agps data for your area. I have some scripts that will do that for you, so just let me know if you are intressted. Kind regards, Ed On Tue, 2009-02-17 at 09:24 +0100, Rikard Nilsson wrote: > > What about if we hack the data format of u-blox AGPS offline file, and > > extract data for current location and time? location can be specified by > > clicking map, time from local system time. If we could, we would be able to > > submit data to GPS chip as AGPS online message on demand. What do you think? > > Wouldnt it be possible to get the location from the gsm-network in some way? > > /Rikard > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
> What about if we hack the data format of u-blox AGPS offline file, and > extract data for current location and time? location can be specified by > clicking map, time from local system time. If we could, we would be able to > submit data to GPS chip as AGPS online message on demand. What do you think? Wouldnt it be possible to get the location from the gsm-network in some way? /Rikard ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
