-
Notifications
You must be signed in to change notification settings - Fork 30
ZED-F9K / ZED-F9R Priority Navigation Mode #6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi Simon, You are probably exceeding the bandwidth of I2C at 400kHz. The module will "throttle" the messages if its internal buffer becomes full. PVT is 100 bytes. ATT is 40 bytes. INS is 44 bytes. Together that is approx 1840 bits. At 30Hz, the bit rate will be ~55K bits/sec. But that's without overheads, and/or any delays inside your logging code or SD interface. Are you polling the messages? Or using the "Auto" methods? Do you have any other messages enabled? Maybe you could use SPI instead? Our library supports that too. I hope this helps. I'll leave this issue open for a while, just in case anyone else has better ideas. Best wishes, |
If you still have the NMEA GSV messages enabled - they are by default - you will get dramatically more messages when outdoors compared to indoors. Maybe try disabling all NMEA messages using the port settings? |
Thanks for the quick reply @PaulZC! I believe we turn off all messages apart from UBX via Basic code is as follows:
|
Hi Simon, What happens if you increase your tick frequency? Maybe to 99Hz? I'm wondering if the incoming data and tick samples are "beating" in some way? Correct, I tend not to use the F9R. And I don't have a F9K... I have had the F9P outputting and logging RXM RAWX data at 20Hz, but that was using SPI not I2C. Best, |
Hi Paul, I set the tick frequency to 1kHz and also observe that when the F9K is in a GPS denied area (dead-reckoning mode) it will output a solution at 30Hz. The issue only arises when the module is actively calculating a location based on satellite data. Best, |
Hi Simon, It still makes me think that you have an extra message enabled - in Battery-Backed-RAM. Perhaps something like UBX-NAV-SAT. That would explain an increase in the number of messages outdoors. Perhaps try:
after And/or you could connect u-center via USB and check UBX-MON-COMMS. That will show how much data is flowing through each port. Did you get a reply from u-blox re. whether it is possible to upgrade the F9K firmware? Best wishes, |
Hi Paul, We tried your suggestions, but unfortunately none of these are allowing us to receive location updates at 30Hz. I also went ahead and ordered a ZED-F9R (we upgraded to the latest firmware on this device) but are seeing the same behavior as in the F9K. Once the module get a fix, the rate drops drastically (in case of the F9R it's to around 10Hz). For our use case it is very important that we can obtain the 30Hz, do you have any idea where this issue is coming from? Is this a problem with the module itself or with the library? |
Hi Simon, I will try to find time to write a data-logging example for PVT, ATT and INS at 30Hz. I have a ZED-F9R I can use for testing. I won't be able to put it in a vehicle, but I will be able to test it with a good satellite signal. It will take me a few days though - I am busy working on other projects at the moment. Please ping me if I have not replied by the end of the week. Best, |
Hi Simon, I'm taking a quick look at this... So far, I can get the expected output at 20Hz, but it drops back to 1Hz when I try 25Hz. Here's my code:
I'm going to try opening the I2C pull-up jumper links. Then I'll try SPI. More later, |
Hi Simon, Same result on SPI. I'm OK at 20Hz, but as soon as I try to push it to 25Hz it drops back to 1Hz. Investigating further, I connected u-center simultaneously. If I run my example at 20Hz and then try to change CFG-RATE-MEAS to 40ms, the VALSET is NACK'd. I.e. the module thinks 40ms / 25Hz is not supported... This is without an antenna attached - to replicate your indoor measurements. I don't know where this leaves us? I think I need a coffee... More later, PS: Here's the SPI code in case it comes in useful:
|
OK. The trick is:
|
Full SPI code:
|
Ah. OK. I2C is still having problems - even at 400kHz: I think SPI is the way forward for you.... Here's the hybrid example:
|
Hi Paul, I was just about to write you. We came to the exact same conclusion! I've uploaded a screenshot of our settings from this ublox post
EDIT: by using these settings we are also able to achieve 30Hz via I2C at 400kHz. |
Hello,
we would like to receive PVT, ATT and INS solutions at 30Hz from the ZED-F9K.
As a base example, we have modified line 58
myGNSS.setNavigationFrequency(30)
in Example7_OutputRate. When indoors (in a GPS denied area), this works well and we can poll the model at 30Hz without any problems. However, when going outdoors and having Fix Type 3 or 4, the rate drops down to 5-8Hz. We are using an ESP32 and connect the ZED-F9K via I2C at 400kHz.We have also tried the same module with a direct USB-C connection and using the ublox-ros node and are able to obtain data at 30Hz even in Fix Type 3 and 4 scenarios.
Does anyone know why this may be happening and potential solutions?
Thanks
The text was updated successfully, but these errors were encountered: