Re: thoughts on A-GPS offline
Daniel Willmann wrote: On Tue, 10 Mar 2009 15:18:23 +0100 Helge Hafting helge.haft...@hist.no 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
Am Mi 18. März 2009 schrieb Helge Hafting: Daniel Willmann wrote: On Tue, 10 Mar 2009 15:18:23 +0100 Helge Hafting helge.haft...@hist.no 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
On Tue, 10 Mar 2009 15:18:23 +0100 Helge Hafting helge.haft...@hist.no 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 helge.haft...@hist.no 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) ml-user+51571-985684...@n2.nabble.com: On Tue, 3 Mar 2009 06:47:26 -0800 (PST) mqy meng.qing...@... 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 meng.qing...@gmail.com 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
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
On Tue, 03 Mar 2009 12:31:00 +0100 Helge Hafting helge.haft...@hist.no 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
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 meng.qing...@gmail.com 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 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
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 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
On Sun, 1 Mar 2009 21:39:25 +0100 Raphaël Jacquot sxp...@sxpert.org 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
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
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
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 openm...@mazikeen.demon.co.uk 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
Re: thoughts on A-GPS offline
Cédric Berger wrote: On Wed, Feb 18, 2009 at 17:49, Al Johnson openm...@mazikeen.demon.co.uk 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
Helge Hafting helge.haft...@hist.no 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
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
Timo Juhani Lindfors wrote: mqy meng.qing...@gmail.com 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
On Wed, Feb 18, 2009 at 16:52, Helge Hafting helge.haft...@hist.no wrote: Timo Juhani Lindfors wrote: mqy meng.qing...@gmail.com 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
On Wednesday 18 February 2009, Cédric Berger wrote: On Wed, Feb 18, 2009 at 16:52, Helge Hafting helge.haft...@hist.no wrote: Timo Juhani Lindfors wrote: mqy meng.qing...@gmail.com 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 17:49, Al Johnson openm...@mazikeen.demon.co.uk 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
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
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
On Tue, Feb 17, 2009 at 10:40 AM, Ed Kapitein e...@kapitein.org 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
Ed Kapitein e...@kapitein.org 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
mqy meng.qing...@gmail.com 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
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 timo.lindf...@iki.fi wrote: mqy meng.qing...@gmail.com 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
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 e...@kapitein.org 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
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 timo.lindf...@iki.fi wrote: mqy meng.qing...@gmail.com 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
mqy meng.qing...@gmail.com 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