saving and restoring GPS data for U-blox chip quicker startup

Abdelrazak Younes younes at
Sat Aug 30 10:59:29 CEST 2008

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:

And some python script in the FSO framwork. Look 

> 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
> (
> 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.
> root at om-gta02:~# 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):
> root at om-gta02:~# ./ 0B 10 00 00>  AID-DATA.ubx
> root at om-gta02:~# 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 :-)


More information about the community mailing list