How do GPS modules store the satellite orbit data?

[peter-h]

For example the NEO-M9N. I am sure it has no battery backed RAM, and an EEPROM would wear out too fast.

So these modules must be doing a cold start each time. That should take 12.5 mins, but the reality is they are far faster in getting a fix.

How does this work?

[Peabody]

The $13 GoouuuTech module I got from Amazon a couple years ago has an EEPROM, a 24C32.  I don't know exactly how it all works, but the time from power up until the LED starts blinking at 1Hz seems to depend on how long ago it was powered down.  I guess the longer it has been away, the more satellites it needs to acquire.  Something like that.

https://www.amazon.com/dp/B07P8YMVNT

By the way, for $13 you get a genuine GoouuuTech module, not some cheap imitation.

[David Hess]

For example the NEO-M9N. I am sure it has no battery backed RAM, and an EEPROM would wear out too fast.

EEPROM would not wear out too quickly, especially if a log type of data structure was used.

I wonder how often the data for each satellite is updated.

[SiliconWizard]

The NEO-M9N module does have a pin for using an external backup battery. I don't know how you integrated it. If you claim no battery backup, then I'm assuming you didn't connect this pin to a battery in your system.
If not, the module has a "software backup" mode, which basically saves the data to internal flash. It's described, although poorly, in the manuals (there are several of them apart from the datasheet). The software backup is triggered by a command as far as I can tell, so here again, unless you explicitely triggered a backup, it shouldn't happen.

Now I vaguely recall that you may be using this module for getting GPS time? If so, then you don't need a "fix", and no surprise you get a first time message pretty fast. I think it only needs one satellite, so as long as reception conditions are not too bad, you should get a first message with time in a matter of a few seconds only after power-on.

If, OTOH, you're talking about a full fix, then that's another matter. But 12.5 min? Are you sure? Where did you get this figure from?

[langwadt]

The NEO-M9N module does have a pin for using an external backup battery. I don't know how you integrated it. If you claim no battery backup, then I'm assuming you didn't connect this pin to a battery in your system.
If not, the module has a "software backup" mode, which basically saves the data to internal flash. It's described, although poorly, in the manuals (there are several of them apart from the datasheet). The software backup is triggered by a command as far as I can tell, so here again, unless you explicitely triggered a backup, it shouldn't happen.

Now I vaguely recall that you may be using this module for getting GPS time? If so, then you don't need a "fix", and no surprise you get a first time message pretty fast. I think it only needs one satellite, so as long as reception conditions are not too bad, you should get a first message with time in a matter of a few seconds only after power-on.

If, OTOH, you're talking about a full fix, then that's another matter. But 12.5 min? Are you sure? Where did you get this figure from?

https://en.wikipedia.org/wiki/Time_to_first_fix

[amyk]

Also from that article:

Many receivers can use as many as twelve channels simultaneously, allowing quicker fixes (especially in a cold case for the almanac download).

[peter-h]

Indeed I use it for time, but in the http server status page there is a position link created also.

Not implemented a battery; they always fail after some years (in the 10-20 timeframe, for lithium primary cells) and go short-circuit, so completely stopping the device working unless measures are taken (mostly, in consumer products, they are not taken).

So this module should be doing a cold start every time.  I've just timed a cold-started NEO-M9N at 3:45 and that is a very poor scenario indoors. This is to a 3D fix, too.

What prompted me to post the question is that I am testing a particular aviation gadget (a Sky Echo 2) whose GPS appears to be spectacularly crap.

[reodor]

Flash can handle a huge number of writes. They have flash based hard disks nowadays.

If you implement brown-out detection and a large enough capacitor, you may be able to save the data to flash only at power off.

[peter-h]

Sure but this is a little module. No room for a big cap...

[brucehoult]

Flash can handle a huge number of writes. They have flash based hard disks nowadays.

If you implement brown-out detection and a large enough capacitor, you may be able to save the data to flash only at power off.

Or once every six months when the almanac changes.

It's been quite some time since I used a GPS without a cellular network (which allows almost instantly knowing the time and the location of at least the tower you're talking to, and triangulated from several if you're not in the mountains). My original Cambridge GPSNAV (https://www.cumulus-soaring.com/store/cai-gps-nav) in 1994 had only an 8 channel receiver and took some time to get an initial fix if you hadn't used it for six months, and almost as long if you'd travelled to the other side of the world. Once it was upgraded to a 12 channel engine it was much faster. I have an original Garmin eTrex which was 12 channel from the start. I remember using it to find my way across Chicago (driving) to my host's house in 2001 -- no maps, just a pointer and distance. I don't remember using it since I got an iPhone 3GS in 2009 :-)

[SiliconWizard]

Yes, if you don't want to use a backup battery, you can use the "software backup" feature as I mentioned. It's a command to send to the module. It only needs to be updated every 6 months indeed so there's no way it would wear out the internal flash. It should decrease the TTF to 20-30 s max, even shorter outdoors.

But the NEO modules are pretty good and a lot of cheaper GPS modules out there have much worse performance. The antenna plays a big role too.

[Benta]

Why would an EEPROM wear out too fast?
Real EEPROMS (not Flash) can be written at least 100k times and have data retention time spanning decades. With wear-levelling algorithms I see no reliability problems.

[Andy Chee]

Sure, if you buy just the chip or die, there will be no battery.

But as an eBay/Amazon module, hopefully there is one like this (button battery top left PCB);



Alternatively, perhaps you can implement power management in your off-board microcontroller i.e. a large reservoir capacitor, power-fail detection, and save data on power-loss.

[Peabody]

My module has both an EEPROM and a button cell.  The module is several years old, and I can't measure any voltage on the cell, which appears to have three tiny spot welds on the top connector, so would not be replaceable.  But it still seems to work ok.

[tszaboo]

Flash can handle a huge number of writes. They have flash based hard disks nowadays.

If you implement brown-out detection and a large enough capacitor, you may be able to save the data to flash only at power off.

Yes these modules usually have several megabytes of flash. Ephemeris data is ~ kilobytes, and you can use them for quite some time.
So if you have a buffer for it, with a hundred slots, then overwrite it thousands of times, it will work practically forever.

[peter-h]

It is nontrivial to arrange a data save every 6 months in an embedded system which has say a 3 day supercap backup for the RTC, and no internet access

I think in some situations one would trigger a save on every power-down, depending on how long it takes (only if there is a current GPS fix obviously).

[Siwastaja]

It is nontrivial to arrange a data save every 6 months in an embedded system which has say a 3 day supercap backup for the RTC, and no internet access

Why would that matter, though? Here's a simple algorithm: once full set of almanac has been received, compare to the existing in flash. If identical, don't write. If not, write. This way it will be written again every 6 months. After boot, and before the new almanac has been received, try to use the one existing in flash. If it has been expired during longer off-time, then getting the fix for the first time will be slower.

[SiliconWizard]

It is nontrivial to arrange a data save every 6 months in an embedded system which has say a 3 day supercap backup for the RTC, and no internet access

I think in some situations one would trigger a save on every power-down, depending on how long it takes (only if there is a current GPS fix obviously).

You get the time and date from GPS. You just need to store the last save date and compute how much time has elapsed since the last save when the device gets a date from GPS.
What did I miss?

[ejeffrey]

It is nontrivial to arrange a data save every 6 months in an embedded system which has say a 3 day supercap backup for the RTC, and no internet access

It's a GPS! You don't need a battery backed RTC.  You would only consider writing the backup when you have accurate time from the satellites.

[langwadt]

It is nontrivial to arrange a data save every 6 months in an embedded system which has say a 3 day supercap backup for the RTC, and no internet access

I think in some situations one would trigger a save on every power-down, depending on how long it takes (only if there is a current GPS fix obviously).

You get the time and date from GPS. You just need to store the last save date and compute how much time has elapsed since the last save when the device gets a date from GPS.
What did I miss?

the almanac so you know which and where the satellites are without spending minutes downloading it at 25bps ?

[peter-h]

once full set of almanac has been received, compare to the existing in flash

Can you get access to that data, for this module?

It's a GPS! You don't need a battery backed RTC.  You would only consider writing the backup when you have accurate time from the satellites.

It's a good point that you get valid date/time (actually there is no "valid" flag; you just have to do a sanity check for the year being >2024 etc) regardless of the almanac validity.

[brucehoult]

It is nontrivial to arrange a data save every 6 months in an embedded system which has say a 3 day supercap backup for the RTC, and no internet access

Why would that matter, though? Here's a simple algorithm: once full set of almanac has been received, compare to the existing in flash. If identical, don't write. If not, write. This way it will be written again every 6 months. After boot, and before the new almanac has been received, try to use the one existing in flash. If it has been expired during longer off-time, then getting the fix for the first time will be slower.

Even using an out of date almanac is going to be a lot faster than none.

[peter-h]

OK; I can see there are commands for reading out the almanac, etc.

[WatchfulEye]

The alamanc was useful in the past, when receivers had few parallel channels, and each channel had limited computational power. In order to decode the signal from a particular SV, the receiver must be able to lock the Doppler shifted frequency and code phase of each signal. From a cold start, that required using a DSP correlator on each channel to search the required parameter space (SV code, Doppler shift, Code phase).

In the days of limited parallel channels and weak DSP, this search could be excessively long, hence the alamanc provided coarse bounds which could be used to limit the search space at warm start.

These days GPS receivers have enough channels that they can receive all satellites simultaneoulsy, and enough correlator cores to simply brute force search the entire parameter space in a few seconds, hence no meaningful difference in performance between a true "cold" start (invalid almanac) and a "warm" start (valid almanac, but no valid ephemeris).

[peter-h]

Thanks - that explains a lot.