I have a F9R-03B GPS module, and I am looking to have 30Hz fix output.
I have the following configurations but my fix only updates at a rate of 14~16Hz max, IMU updates at a rate of 45~49Hz. Can someone help me with why the fix data is not at 30Hz?
If you want any other piece of info please let me know I will try to get it.
I added the change, but I am getting 1Hz on my fix now. Is there anything else I need to do?
Excluding the CFG-NAV-RATE change, for a brief moment I was able to get 30Hz. But it has now stopped functioning. I am unsure on what exactly changed. Is there is some additional u-center changes I need to make sure I have to get consistent 30Hz? or maybe there is a different way (non u-center method) to write/flash the configurations?
I’ve never tested the F9R-03B, but these ‘types’ often need full sension fusion to maintain the max spec’d performance. This module might want odometer (wheel ticks, etc) in addition to the IMU to maintain 30hz in priority mode ?
Just a guess…
@rftop from the datasheet it does not seem to be the case, from my understanding those additional inputs help with “fix” or “lock” type scenarios or maybe even a more precise/accurate heading. I could be wrong, but that was my impression.
I did have a question somewhat associated with the same topic but from IMU pov instead of GPS. I hope it is OK to ask this question as a follow up question, if not I can start a new topic.
Question:
When DR (Dead Reckoning) is enabled, IMU default frequency being dropped to 15Hz from the default 100Hz. Which makes sense, but why does it drop down all the way to 15Hz?
Isn’t that too much of a falloff?
Side note:
When I set UART1 to 0 add_kv_u8(0x10740002, 0); // CFG-UART1-OUTPROT-NMEA: disable
I get around 30Hz on IMU. Not sure if it can be improved further. But just an observation.
That makes sense to me…when dead reckoning is active the buffer should re-use more of the older integration cycles. It uses a kalman filter that necessitates using the previous IMU data and GPS position to predict/calculate the new GPS position after considering the new IMU data. DR simply requires more math/resources/time from the processor and interface(s), which is why disabling uart1 showed an improvement
About 15Hz maybe being too much of a fall off…usually not; do you need more? The board is largely meant as a vehicle sensor rather than a logger so the fusion processing was the main design focus. Please note the IMU and the downstream filtering algorithms still receive the 100Hz IMU data but doesn’t output all of 'em
Check also what’s going on with UART2, this might default to 38400 baud NMEA (so around 3800 bytes/second)
Both UART1 and UART2 will log-jam with data if there is insufficient bandwidth to transmit pooled buffers faster than you can fill them, collectively.
Watch for $GxTXT “txbuf,alloc” warnings, it’s indicative that the system is choking. It drops data to recover.
UBX-ESF-RAW should spill multiple IMU sensor records, on the M8 series between 99 and 100 Hz, 10 packets/second, with about 9 or 10 records in each. Not sure on the F9R/F9K
I’m not sure if the ZED-F9R drops the speed or requires a common multiple between the IMU and GNSS-RTK rates, but it does only support 4 Hz (2 Hz in earlier firmwares), and uses these as anchor or fence-post fixes, to tether the splines / interpolation between them. As I understand it, it factors in the wheel-tick, accelerometer, gyroscope measurements at the rates it can, and it’s time-stamping and aligning them, so it can interpolate/extrapolate to a common point in time, as reported in the PVT message. It is anticipated that you use the 1PPS (TIMEPULSE) to establish time-transfer into the host system, so you can extrapolate your current position at the time when you have the data parsed and in-hand.
