The configuration does not get lost when the device is power off, correct?!
Yes. See the spec:
8.1 Configuration Concept:
The Current Configuration can be made permanent (stored in a non-volatile memory) by saving it to the "Permanent Configuration". This is done by...
When I configure it to use GPS and GLONASS satellites it will use them automatically in its position calculation?
If you don't do anything, it will use GPS and GLONASS. If you want to use GPS only or GLONASS only, you must configure it:
3 GNSS Configuration:
the UBX-CFG-GNSS message ... allows the user to specify which GNSS signals should be processed along with limits on how many tracking channels should be allocated to each GNSS.
"GNSS" is the generic term for a satellite navigation system; GPS and GLONASS are two specific satellite systems.
In my project I would need kind of a regular sample rate (around 10Hz). I can live with a GPS update e.g. only twice a second (writing 5 times the same value). But waiting/relying on the GPS driven update rate feels not so good at the moment.
This is a difficult concept for many people, so let me make sure you understand some things related to what you just said.
*1. * NeoGPS can quickly parse the GPS data, so you will have plenty of time to do "other things". NeoGPS will use less than 1ms/sentence, regardless of update rate or baud rate.
*2. * The ublox transmits data in bursts, 1 burst every second. If you configure it to send 5 different sentences, it will send 5 sentences every second. It sends the sentences one after another until they're all sent, then it goes quiet until the next 1-second interval. If each sentence is about 80 bytes, it will send 400 bytes every second. If the baudrate is 9600, it takes (400*11)/9600 seconds to send the 400 bytes, about 450ms. Then it doesn't send anything for the remaining 550ms.
But for a 10Hz update rate, it will try to send 400 bytes every [u]100ms[/u]. But it takes 450ms to send that many bytes, so... you must either reduce the number of sentences it sends, or increase the baudrate to 38400 or higher.
If you configure it to send only one sentence, 80 bytes would take 91ms, leaving a 9ms quiet time.
If you configure the baud to 115200, 400 bytes would take 38ms, leaving a 62ms quiet time. One sentence would take 8ms, leaving a 92ms quiet time.
*3. * The input buffers are only 64 bytes deep. If you don't call
serial.read() soon enough, you will start losing bytes. At 115200, 64 bytes takes 6ms. If you don't call
serial.read() every 6ms, you will lose data.
There are two things to consider for your cycle: your most time-consuming operations, and the operations you need to perform frequently.
1) If the most time-consuming operations take longer than the input buffer overflow time (6ms), they can only be performed during the quiet time. Obviously, they must take less than the quiet time + 6ms, or you'll lose data at the start of the next batch of sentences.
2) The operations you need to perform frequently (e.g., at 10Hz) must not take longer than 6ms. These can take place while the ublox is sending bytes. If this is an expensive calculation, you may be able to break it up into several smaller calculations. Then you can call
serial.read() in between the steps to avoid input buffer overflow.
In your case, you don't have to "wait/rely" on the GPS quiet time to do something, you just have to make sure you call
serial.read() frequently enough (i.e., at least every 6ms).
That's really the purpose of the NeoGPS examples: they show how to wait until the quiet time. You don't have to defer everything until then... just the things that you can't break into 6ms steps. For beginners, it's the safest place to do things, because they don't usually know how long something takes.
The examples also put all the GPS handling (
decode) in one routine,
GPSloop(). You can call that from multiple places, either from the main
loop(), or in between calculation steps from anywhere in your sketch.