Re: saving and restoring GPS data for U-blox chip quicker startup
Abdelrazak Younes wrote: >> I dont see any benefits over the "save on >> gpsd exit" or "save on 'gps off' in settings menu" method, except that just >> another daemon steals CPU time and consumes RAM. > > Of course such solution should be integrated in an already running gps > daemon. gpsd already decodes some messages, it could be improved to > retrieve and save those additional aid messages. No more RAM would be > needed. I don't plan to use gpsd so my solution would be a replacement > for it. Such daemon shouldn't consume more than one megabyte of RAM, > actually I would say much less than a megabyte. Nice... I had the same doubt too. Now I'm just waiting for your posts with linked code :P -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: saving and restoring GPS data for U-blox chip quicker startup
Fabian Henze wrote: > On Saturday 30 August 2008 at 10:59:29, Abdelrazak Younes wrote: >> A better solution would be to just configure the Ublox to send the >> ephemerises and almanacs as soon as they are received. A simple daemon >> would watch for these messages and store them appropriately when they >> are received. > > Why would this be a better solution? Because it is safer and cleaner to save things as soon as they are received. > I dont see any benefits over the "save on > gpsd exit" or "save on 'gps off' in settings menu" method, except that just > another daemon steals CPU time and consumes RAM. Of course such solution should be integrated in an already running gps daemon. gpsd already decodes some messages, it could be improved to retrieve and save those additional aid messages. No more RAM would be needed. I don't plan to use gpsd so my solution would be a replacement for it. Such daemon shouldn't consume more than one megabyte of RAM, actually I would say much less than a megabyte. Abdel. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: saving and restoring GPS data for U-blox chip quicker startup
On Saturday 30 August 2008 at 10:59:29, Abdelrazak Younes wrote: > A better solution would be to just configure the Ublox to send the > ephemerises and almanacs as soon as they are received. A simple daemon > would watch for these messages and store them appropriately when they > are received. Why would this be a better solution? I dont see any benefits over the "save on gpsd exit" or "save on 'gps off' in settings menu" method, except that just another daemon steals CPU time and consumes RAM. Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: saving and restoring GPS data for U-blox chip quicker startup
digger vermont wrote: > On Sat, 2008-08-30 at 10:59 +0200, Abdelrazak Younes wrote: > >> There is at least two that I know of, some ruby script: >> http://docs.openmoko.org/trac/browser/developers/alphaone/u-blox >> >> And some python script in the FSO framwork. Look >> "framework/subsystems/ogpsd/" >> > > I just looked. It's in ubx.py. There was also recently a warmstart > patch committed. > > digger > > Nice! but that patch you mention is for FSO only, right? No ASU benefits there... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: saving and restoring GPS data for U-blox chip quicker startup
Abdelrazak Younes wrote: > There is at least two that I know of, some ruby script: > http://docs.openmoko.org/trac/browser/developers/alphaone/u-blox > > And some python script in the FSO framwork. Look > "framework/subsystems/ogpsd/" > Cool. What's the requirements to get alphaone's ruby scripts working in OM2008.8? Aside from "opkg install ruby"... >> I'd like to see the freerunner's GPS do the same any other GPS device >> does: save the almanac/ephemeris data to storage upon shutdown and >> restore it upon powerup. > Right. I just receive my freerunner today. So I may start my own plan > this week :-) > > Excellent. :) >> So, I took the protocol datasheet >> (http://www.u-blox.com/customersupport/gps.g3/ANTARIS_Protocol_Specification(GPS.G3-X-03002).chm) >> and tried to coerce the chip into vomiting the stored information (we >> should take care to do it after working for at least 2 or 3 minutes with >> a good reception level). >> > > A better solution would be to just configure the Ublox to send the > ephemerises and almanacs as soon as they are received. I didn't know that was even possible... great! > A simple daemon > would watch for these messages and store them appropriately when they > are received. > > Makes sense. > Yes. The FSO is capable of doing that AFAIU. I have some code that do > that in C++ already, I'll publish them as soon as I port them to the FR. > My code will be able to read and decode a number of messages, including > raw data (pseudorange measurements). > > Wonderful. Just make sure you're not duplicating efforts with someone else... :) >> 2 - a simple hook into the UI gps on/off button script, forcing process >> (1) to ask for info and store it on file upon gps shutdown, and to >> rewrite that info into the chip on startup. >> > > I don't think we need any manual intervention here. The above described > daemon should just be reading only the device. Another program should be > responsible of writting the aid data as soon as the GPS is started. > Ideally this program could also be able to write manually encoded > messages based on commonly used formats for ephemerises (RINEX) and > almanacs (Yuma). > > >> Who's working on this? I'd happily beta-test it. >> > > I will, hopefully in the coming weeks :-) > > Fine. Keep us posted! > Abdel. > > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: saving and restoring GPS data for U-blox chip quicker startup
On Sat, 2008-08-30 at 10:59 +0200, Abdelrazak Younes wrote: > Vasco Névoa wrote: > > Hi all. > > Hi Vasco, > > > I don't know how far anyone has gone in this subject, so I took the > > liberty to experiment. > > There is at least two that I know of, some ruby script: > http://docs.openmoko.org/trac/browser/developers/alphaone/u-blox > > And some python script in the FSO framwork. Look > "framework/subsystems/ogpsd/" > I just looked. It's in ubx.py. There was also recently a warmstart patch committed. digger 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: saving and restoring GPS data for U-blox chip quicker startup
Vasco Névoa wrote: > Hi all. Hi Vasco, > I don't know how far anyone has gone in this subject, so I took the > liberty to experiment. There is at least two that I know of, some ruby script: http://docs.openmoko.org/trac/browser/developers/alphaone/u-blox And some python script in the FSO framwork. Look "framework/subsystems/ogpsd/" > I'd like to see the freerunner's GPS do the same any other GPS device > does: save the almanac/ephemeris data to storage upon shutdown and > restore it upon powerup. I don't know much about GPS, but I imagine this > would accelerate the startup, and it wouldn't hurt much if the device > has changed geographical location in between (like after a plane trip, > for example.) Right. I just receive my freerunner today. So I may start my own plan this week :-) > > So, I took the protocol datasheet > (http://www.u-blox.com/customersupport/gps.g3/ANTARIS_Protocol_Specification(GPS.G3-X-03002).chm) > and tried to coerce the chip into vomiting the stored information (we > should take care to do it after working for at least 2 or 3 minutes with > a good reception level). A better solution would be to just configure the Ublox to send the ephemerises and almanacs as soon as they are received. A simple daemon would watch for these messages and store them appropriately when they are received. > > Basically: > > # Listen to the GPS port. Don't use gpspipe or any other "complicated" > stuff because of internal filtering cutting the binary messages. U-blox > binary protocol messages start with 0xB5 0x62. > [EMAIL PROTECTED]:~# hexdump /dev/ttySAC1 | grep 62b5 > # If you're suspicious of this, take a look at the direct output of "cat > /dev/ttySAC1" and you'll be convinced when you see the ASCII output > temporarily replaced by binary garbage. :) > > # Ask the u-blox chip for it's stored gps data, by sending the AID-DATA > poll message (equivalent to sending AID-INI + AID-HUI + AID-EPH + > AID-ALM, we could send each one alone if desirable): > [EMAIL PROTECTED]:~# ./ubxgen.py 0B 10 00 00> AID-DATA.ubx > [EMAIL PROTECTED]:~# cat AID-DATA.ubx> /dev/ttySAC1 > > # out pours the requested data... > (down at the end of this message) > > Now, this is just a start for a "proof of concept", and I think it has > potential. The output is already in the same format it takes for input, > and is separated into 4 different message categories, allowing us to > modify some of the data if needed. > > So, what would be needed for this feature to be implemented? > 1 - some process capable of writing and reading "ublox-binary" at > /dev/ttySAC1; Yes. The FSO is capable of doing that AFAIU. I have some code that do that in C++ already, I'll publish them as soon as I port them to the FR. My code will be able to read and decode a number of messages, including raw data (pseudorange measurements). > 2 - a simple hook into the UI gps on/off button script, forcing process > (1) to ask for info and store it on file upon gps shutdown, and to > rewrite that info into the chip on startup. I don't think we need any manual intervention here. The above described daemon should just be reading only the device. Another program should be responsible of writting the aid data as soon as the GPS is started. Ideally this program could also be able to write manually encoded messages based on commonly used formats for ephemerises (RINEX) and almanacs (Yuma). > > Who's working on this? I'd happily beta-test it. I will, hopefully in the coming weeks :-) Abdel. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
saving and restoring GPS data for U-blox chip quicker startup
Hi all. I don't know how far anyone has gone in this subject, so I took the liberty to experiment. I'd like to see the freerunner's GPS do the same any other GPS device does: save the almanac/ephemeris data to storage upon shutdown and restore it upon powerup. I don't know much about GPS, but I imagine this would accelerate the startup, and it wouldn't hurt much if the device has changed geographical location in between (like after a plane trip, for example.) So, I took the protocol datasheet (http://www.u-blox.com/customersupport/gps.g3/ANTARIS_Protocol_Specification(GPS.G3-X-03002).chm) and tried to coerce the chip into vomiting the stored information (we should take care to do it after working for at least 2 or 3 minutes with a good reception level). Basically: # Listen to the GPS port. Don't use gpspipe or any other "complicated" stuff because of internal filtering cutting the binary messages. U-blox binary protocol messages start with 0xB5 0x62. [EMAIL PROTECTED]:~# hexdump /dev/ttySAC1 | grep 62b5 # If you're suspicious of this, take a look at the direct output of "cat /dev/ttySAC1" and you'll be convinced when you see the ASCII output temporarily replaced by binary garbage. :) # Ask the u-blox chip for it's stored gps data, by sending the AID-DATA poll message (equivalent to sending AID-INI + AID-HUI + AID-EPH + AID-ALM, we could send each one alone if desirable): [EMAIL PROTECTED]:~# ./ubxgen.py 0B 10 00 00 > AID-DATA.ubx [EMAIL PROTECTED]:~# cat AID-DATA.ubx > /dev/ttySAC1 # out pours the requested data... (down at the end of this message) Now, this is just a start for a "proof of concept", and I think it has potential. The output is already in the same format it takes for input, and is separated into 4 different message categories, allowing us to modify some of the data if needed. So, what would be needed for this feature to be implemented? 1 - some process capable of writing and reading "ublox-binary" at /dev/ttySAC1; 2 - a simple hook into the UI gps on/off button script, forcing process (1) to ask for info and store it on file upon gps shutdown, and to rewrite that info into the chip on startup. Who's working on this? I'd happily beta-test it. My data (not really relevant, and probably incomplete because of the grep) 4c0 3030 2c38 3030 302c 2a30 4236 0a0d 62b5 500 4ba0 62b5 020b 0048 550 0007 d55d 62b5 310b 0008 0001 560 f745 62b5 310b 0008 0002 570 ff46 62b5 310b 0008 0003 580 0747 62b5 310b 0008 0004 590 0f48 62b5 310b 0008 0005 5a0 1749 62b5 310b 0008 0006 5b0 1f4a 62b5 310b 0008 0007 5c0 274b 62b5 310b 0008 0008 5d0 2f4c 62b5 310b 0008 0009 5e0 374d 62b5 310b 0008 000a 5f0 3f4e 62b5 310b 0008 000b 600 474f 62b5 310b 0008 000c 610 4f50 62b5 310b 0008 000d 620 5751 62b5 310b 0008 000e 630 5f52 62b5 310b 0008 000f 640 6753 62b5 310b 0008 0010 650 6f54 62b5 310b 0008 0011 660 7755 62b5 310b 0008 0012 670 7f56 62b5 310b 0008 0013 680 8757 62b5 310b 0008 0014 690 8f58 62b5 310b 0008 0015 6a0 9759 62b5 310b 0008 0016 6b0 9f5a 62b5 310b 0008 0017 6c0 a75b 62b5 310b 0008 0018 6d0 af5c 62b5 310b 0008 0019 6e0 b75d 62b5 310b 0008 001a 6f0 bf5e 62b5 310b 0008 001b 700 c75f 62b5 310b 0068 001c 770 f5a2 004d 8a90 62b5 310b 0008 001d 780 d761 62b5 310b 0008 001e 790 df62 62b5 310b 0008 001f 7a0 e763 62b5 310b 0008 0020 7b0 ef64 62b5 300b 0008 0001 7c0 ec44 62b5 300b 0008 0002 7d0 f445 62b5 300b 0008 0003 7e0 fc46 62b5 300b 0008 0004 7f0 0447 62b5 300b 0008 0005 800 0c48 62b5 300b 0008 0006 810 1449 62b5 300b 0008 0007 820 1c4a 62b5 300b 0028 0008 850 0001 ffea 7fa6 62b5 300b 0028 0009 880 0034 0001 312f 62b5 300b 0028 000a 8b0 000f dc57 62b5 300b 0028 000b 8e0 001b 0002 6f29 62b5 300b 0028 000c 910 001b ffd1 0a32 62b5 300b 0028 000d 940 000f 0023 5e7a 62b5 300b 0028 000e 970 0032 ffe2 4ccb 62b5 300b 0028 000f 9a0 ffda ffe9 f7a8 62b5 300b 0028 0010 9d0 ffed 000e 7eba 62b5 300b 0028 0011 a00 0004 0005 40f0 62b5 300b 0028 0012 a30 0039 ffed 0192 62b5 300b 0028 0013 a60 0014 0004 c1c7 62b5 300b 0028 0014 a90 001e 000d 676b 62b5 300b 0028 0015 ac0 001c 0006 faab 62b5 300b 0028 0016 af0
