The SparkFun ZED-F9R GPS Breakout is also equipped with an on-board rechargeable battery that provides power to the RTC on the ZED-F9R. This reduces the time-to-first fix from a cold start (~26s) to a hot start (~2s). The battery will maintain RTC and GNSS orbit data without being connected to power for plenty of time.
I’m investigating the Hot Start, especially to keep IMU calibration and alignment between uses. To have a hot start, one have to perform a reset with “controlled GNSS stop” (and storage of data in BBR) before power off. So I did. Then, I made drive tests (car with dynamic set to automotive and auto-alignment activated):
15 mn drive (IMU calibration and coarse alignment reached)
3 hours stop.
5 mn drive: no alignment preserved. Calibration and auto-alignment restart from ground. Coarse alignment reached.
couple of seconds stop.
10 mn drive: alignment preserved (indeed, not exactly same values as before shut down).
So, what is the expected duration of parameters preservation with the battery? (one plenty :lol: )
How long time does it need to fully charge the battery?
It can take up to 48 hrs to fully charge the backup battery https://learn.sparkfun.com/tutorials/sp … w-breakout and it after being fully charged it should last quite some time…for the GPS it’s good for up to a year, I imagine the calibration adds a bit of load to that…but I’d guess at least a few weeks? Let us know here after you’ve tested it!
The recollection of sensor fusion on the likes of the NEO-M8L, M8U, M9V and ZED-F9R, F9K has been a recurrent topic over at the u-Blox forum. I have asked them to look into this and perhaps formulate an app note covering the methods and expectations. At some level the host needs to be able to recover current settings, and be able to push them back, at the very least to get the rough settings to relatively optimal values to reduce the fusion time. Temperature is a factor with sensor, and clocks, etc. I don’t see any settings related to compensation for that.
Battery expectations too, there’s going to be some transient data that can be held in BBR, but some of the fixed and established physical relationships that aren’t going to change can presumably pushed into FLASH in many application use cases. The UPD-SOS methods allowing for host-side storage, and the VALKEY space can be enumerated, although not everything is documented in the publicly visible specifications.
Maybe, my understanding of F9R is wrong. It seems that when using Automatic IMU-mount alignment, it is always restarting with IMU orientation set to 0.
If the F9R starts in Automatic IMU-mount alignment mode, changing roll, pitch and yaw of the IMU is not effective. It is staying at 0.
If the F9R starts in User-defined IMU-mount alignment mode, on can change roll, pitch and yaw but, once switching to Automatic IMU-mount alignment mode, changes are lost and orientation back to 0.
Then, in User-defined IMU-mount alignment mode, if setting an orientation, saving data (using saveConfiguration in sparkfun V3 library) and switching power off, then, at next start (even after 10 hours), orientation was preserved.
So, my initial expectation for data backup was wrong and the trouble don’t seems to come from battery and/or BBR (although saveConfiguration save to BBR and flash in parallel).