Best practices: Raw data logging rates

[adamgarbo]

Hi Paul,

Following-up on our conversation regarding best practices for changing the raw data logging rates, I wanted to share a couple of quick results from a logging test today.

Test setup:

• MicroMod Data Logging Carrier Board
• MicroMod Artemis Processor
• SparkFun GPS-RTK-SMA Breakout - ZED-F9P
• 6600 mAh LiPo
• GNSS Multi-Band L1/L2 Surveying Antenna (TNC) - TOP106

Configuration:

• Both systems are identically configured except for how the logging rates are set.
• The code is custom but has the DataLoggingExample4 from the u-blox library at its core.
• Both tests were conducted at the exact same time and were run for 1 hour.
• Results screenshots below are taken from Emlid's new and very handy tool "Emlid Studio" for processing .ubx data, which runs RTKLIB under the hood.

Test 1:

• Measurement and navigations rates set to one second

Code:

gnss.setNavigationFrequency(1);

Results:

• Very typical output for my location.
• Several uninterrupted connections to GPS and GLONASS satellites.
• Many L2 only signals.

Test 2:

• Measurement rate set to 1000 ms and navigation rate (ratio) set to 15.

Code:

gnss.setMeasurementRate(1000);  // Set the measurement rate to 1 second (1000 milliseconds)
gnss.setNavigationRate(15); // Set the navigation rate (ratio) to 15 to produce a solution every 15 s

Results:

• It's immediately clear that something is up.
• It appears that in many cases it was not possible for the receiver to achieve an L2 lock.
• Many of the L2 only signals are also missing.
  

Discussion

• It's appears that L2 performance is severely degraded when increasing the navigation rate to 15.
• I have tried difference combinations of receivers, processors and antennas to ensure that this isn't a hardware issue.
• I'm currently waiting on the NRCan PPP outputs from the above two RINEX files. I'm very curious to see what the results will be.

I'll update this issue later on!

Cheers,
Adam

[adamgarbo]

NRCan Ultra-rapid PPP results:

Test	Latitude (+/- cm)	Longitude (+/- cm)	Height (+/- cm)
1	0.077	0.113	0.232
2	2.550	2.778	6.660

[adamgarbo]

Hi @PaulZC,

I have decided not to use the .setMeasurementRate(1000) and .setNavigationRate(15) functions for my current project, and instead switch back to setNavigationFrequency(1), which we know works reliably.

However, I'd still curious if you have any thoughts on what could be causing the large gaps in logged data. Could this be a bug?

Cheers,
Adam

[PaulZC]

I wonder if this is something to do with low power modes?
Are you changing the receiver management configuration (UBX_CFG_RXM)?
Maybe even with the default configuration, the modules tries to be clever and save power because it knows you only want an update every 15 seconds...?
I must admit I've only ever used setMeasurementRate and setNavigationRate to adjust 'normal' things like PVT. Maybe something strange happens when logging RAWX at such slow rates?
All the best,
Paul

[adamgarbo]

Hi Paul,

It could be a possibility that the receiver is trying to save power between measurements. The Interface Description does note for UBX-CFG-RATE:

When using power save mode, measurement and navigation rate can differ from the values configured.

It could be that a power-saving mode is enabled by default that I'm not aware of, which only activates with a sufficiently slow logging rate.

Regarding commands issued to the receiver, with the exception of setAutoPVT(), they are identical to the DataLoggingExample4. I also did a factory reset of the receiver to be sure.

gnss.setI2COutput(COM_TYPE_UBX);                  // Set the I2C port to output UBX only (disable NMEA)
gnss.saveConfigSelective(VAL_CFG_SUBSEC_IOPORT);  // Save communications port settings to flash and BBR
gnss.setNavigationFrequency(1);                   // Produce one navigation solution per second
gnss.setAutoPVT(true);                            // Enable automatic NAV-PVT messages
gnss.setAutoRXMSFRBX(true, false);                // Enable automatic RXM-SFRBX messages
gnss.setAutoRXMRAWX(true, false);                 // Enable automatic RXM-RAWX messages
gnss.logRXMSFRBX();                               // Enable RXM-SFRBX data logging
gnss.logRXMRAWX();                                // Enable RXM-RAWX data logging

I'll try to look at the power save modes in more detail when I have some time. I'll keep this issue open for now in case other users may be looking to do something similar!

Cheers,
Adam

[PaulZC]

Many thanks Adam,
Paul

[adamgarbo]

Hi @PaulZC,

I'm starting to look into this issue again with version 2.0.17 of the library.

I'm hoping you can quickly clarify: when running the example "Example25_MeasurementAndNavigationRate" with a measurement rate of 5000 ms and navigation ratio of 12, should we be seeing outputs being produced every second?

I remember this being a bit confusing. The (myGNSS.getPVT()) is polling for new data constantly, but haven't we instructed the receiver to only produce new navigation every minute?

Cheers,
Adam

10:11:32.677 -> �SparkFun u-blox Example
10:11:33.049 -> Current measurement interval (ms): 5000
10:11:33.049 -> Current navigation ratio (cycles): 12
10:11:33.084 -> New measurement interval (ms): 5000
10:11:33.084 -> New navigation ratio (cycles): 12
10:11:43.067 -> Lat: 454256683 Long: -756951548 Interval: 9.94s
10:11:43.549 -> Lat: 454025067 Long: -757031881 Interval: 0.48s
10:11:44.072 -> Lat: 454025850 Long: -757032429 Interval: 0.51s
10:11:45.075 -> Lat: 454004726 Long: -757067749 Interval: 1.00s
10:11:46.074 -> Lat: 454000885 Long: -757076242 Interval: 1.00s
10:11:47.059 -> Lat: 454000719 Long: -757077429 Interval: 1.00s
10:11:48.074 -> Lat: 453999240 Long: -757079044 Interval: 1.00s
10:11:49.074 -> Lat: 454001804 Long: -757077089 Interval: 0.99s
10:11:50.084 -> Lat: 454000331 Long: -757077176 Interval: 1.00s
10:11:51.079 -> Lat: 453997257 Long: -757079287 Interval: 1.00s
10:11:52.080 -> Lat: 453995489 Long: -757080058 Interval: 1.00s
10:11:53.091 -> Lat: 453996233 Long: -757074066 Interval: 1.00s
10:11:54.063 -> Lat: 453996541 Long: -757062945 Interval: 0.98s
10:11:55.075 -> Lat: 453996846 Long: -757054382 Interval: 0.99s
10:11:56.074 -> Lat: 453998557 Long: -757047640 Interval: 1.00s
10:11:57.045 -> Lat: 453998745 Long: -757054270 Interval: 1.00s
10:11:58.038 -> Lat: 453999472 Long: -757057873 Interval: 0.99s
10:11:59.084 -> Lat: 453998960 Long: -757065169 Interval: 1.02s
10:12:00.092 -> Lat: 453996505 Long: -757074134 Interval: 0.99s
10:12:01.093 -> Lat: 453994818 Long: -757082242 Interval: 1.00s
10:12:02.042 -> Lat: 453994357 Long: -757085953 Interval: 0.98s
10:12:03.053 -> Lat: 454009682 Long: -757050282 Interval: 1.00s

[PaulZC]

Hi Adam,

Running Example25 unmodified on a SparkFun ATmega328P RedBoard and a ZED-F9P GPS RTK2 breakout, I get PVT updates every 60 seconds:

Best guess, something is falling over in your case and the module is resetting back to its default 1Hz? The 9.94s interval, followed by 0.48s and 0.51s, is a little suspicious.

Maybe try going back to the factory defaults?

Best wishes,
Paul

[adamgarbo]

Hi Paul,

Very strange indeed! I'm using the same test setup as listed above. All of the components are new and the only change is that the I2C jumpers were cut. I uncommented the factory reset code in the example but now it seems like no data is received.

Changing to a measurement interval of 1000 ms and navigation ratio of 1 works without issue:

13:53:15.883 -> �SparkFun u-blox Example
13:53:21.355 -> Current measurement interval (ms): 1000
13:53:21.391 -> Current navigation ratio (cycles): 1
13:53:21.391 -> New measurement interval (ms): 1000
13:53:21.391 -> New navigation ratio (cycles): 1
13:53:21.982 -> Lat: 454002319 Long: -757057125 Interval: 0.60s
13:53:22.985 -> Lat: 454002267 Long: -757057245 Interval: 0.99s
13:53:23.984 -> Lat: 454002195 Long: -757057373 Interval: 0.99s
13:53:24.984 -> Lat: 454002140 Long: -757057449 Interval: 1.00s
13:53:26.000 -> Lat: 454002009 Long: -757057512 Interval: 1.02s
13:53:27.002 -> Lat: 454001810 Long: -757057729 Interval: 0.99s
13:53:27.975 -> Lat: 454001624 Long: -757057955 Interval: 1.00s
13:53:28.990 -> Lat: 454001449 Long: -757058116 Interval: 0.99s
...

However, changing back to 5000 ms / 12 does not seem to work:

13:53:52.623 -> �SparkFun u-blox Example
13:53:58.122 -> Current measurement interval (ms): 1000
13:53:58.122 -> Current navigation ratio (cycles): 1
13:53:58.157 -> New measurement interval (ms): 5000
13:53:58.157 -> New navigation ratio (cycles): 12
13:53:59.003 -> Lat: 454000767 Long: -757064160 Interval: 0.84s

I can see the PPS LED blinking every second but no position updates after 15 minutes.

I enabled debugging and took a peek at what was happening. It looks like after a bunch of timeouts, the I2C falls apart and starts an endless loop.

14:07:09.545 -> Sending: CLS:NAV ID:PVT Len: 0x0 Payload:
14:07:09.545 -> sendCommand: Waiting for No ACK response
14:07:09.545 -> checkUbloxI2C: OK, zero bytes available
14:07:09.545 -> checkUbloxI2C: OK, zero bytes available
14:07:09.579 -> checkUbloxI2C: OK, zero bytes available
14:07:09.614 -> checkUbloxI2C: OK, zero bytes available
14:07:09.648 -> checkUbloxI2C: OK, zero bytes available
14:07:09.648 -> checkUbloxI2C: OK, zero bytes available
14:07:09.683 -> checkUbloxI2C: OK, zero bytes available
14:07:09.719 -> checkUbloxI2C: OK, zero bytes available
14:07:09.753 -> checkUbloxI2C: OK, zero bytes available
14:07:09.753 -> checkUbloxI2C: OK, zero bytes available
14:07:09.787 -> checkUbloxI2C: OK, zero bytes available
14:07:09.821 -> checkUbloxI2C: OK, zero bytes available
14:07:09.858 -> checkUbloxI2C: OK, zero bytes available
14:07:09.858 -> checkUbloxI2C: OK, zero bytes available
14:07:09.895 -> checkUbloxI2C: OK, zero bytes available
14:07:09.930 -> checkUbloxI2C: OK, zero bytes available
14:07:09.963 -> checkUbloxI2C: OK, zero bytes available
14:07:09.963 -> checkUbloxI2C: OK, zero bytes available
14:07:10.001 -> checkUbloxI2C: OK, zero bytes available
14:07:10.034 -> checkUbloxI2C: OK, zero bytes available
14:07:10.068 -> checkUbloxI2C: OK, zero bytes available
14:07:10.068 -> checkUbloxI2C: OK, zero bytes available
14:07:10.103 -> checkUbloxI2C: OK, zero bytes available
14:07:10.137 -> checkUbloxI2C: OK, zero bytes available
14:07:10.137 -> checkUbloxI2C: OK, zero bytes available
14:07:10.171 -> checkUbloxI2C: OK, zero bytes available
14:07:10.208 -> checkUbloxI2C: u-blox bug? Length lsb is 0xFF. i2cPollingWait is 25
14:07:10.245 -> checkUbloxI2C: I2C error: endTransmission returned 4
14:07:10.245 -> checkUbloxI2C: I2C error: endTransmission returned 4
14:07:10.245 -> checkUbloxI2C: I2C error: endTransmission returned 4
14:07:10.245 -> checkUbloxI2C: I2C error: endTransmission returned 4
14:07:10.245 -> checkUbloxI2C: I2C error: endTransmission returned 4
14:07:10.245 -> checkUbloxI2C: I2C error: endTransmission returned 4
14:07:10.245 -> checkUbloxI2C: I2C error: endTransmission returned 4
14:07:10.245 -> checkUbloxI2C: I2C error: endTransmission returned 4
14:07:10.279 -> checkUbloxI2C: I2C error: endTransmission returned 4
14:07:10.279 -> checkUbloxI2C: I2C error: endTransmission returned 4
14:07:10.279 -> checkUbloxI2C: I2C error: endTransmission returned 4
14:07:10.279 -> checkUbloxI2C: I2C error: endTransmission returned 4
14:07:10.279 -> checkUbloxI2C: I2C error: endTransmission returned 4
14:07:10.279 -> checkUbloxI2C: I2C error: endTransmission returned 4
14:07:10.932 -> checkUbloxI2C: I2C error: endTransmission returned 4
14:07:10.932 -> waitForNoACKResponse: TIMEOUT after 1409 msec. No packet received.
14:07:10.932 -> 
14:07:10.932 -> Sending: CLS:NAV ID:PVT Len: 0x0 Payload:
14:07:10.965 -> Send I2C Command failed
14:07:10.965 -> 
14:07:10.965 -> Sending: CLS:NAV ID:PVT Len: 0x0 Payload:
14:07:10.965 -> Send I2C Command failed
14:07:10.965 -> 
14:07:10.965 -> Sending: CLS:NAV ID:PVT Len: 0x0 Payload:
14:07:10.965 -> Send I2C Command failed
14:07:10.965 -> 
14:07:10.965 -> Sending: CLS:NAV ID:PVT Len: 0x0 Payload:
14:07:10.965 -> Send I2C Command failed
14:07:10.965 -> 
14:07:10.965 -> Sending: CLS:NAV ID:PVT Len: 0x0 Payload:
14:07:10.965 -> Send I2C Command failed
14:07:10.965 -> 

Cheers,
Adam

[PaulZC]

Hi Adam,

Which version of Apollo3 (Artemis) are you using?

Thanks,
Paul

[adamgarbo]

Hi Paul,

Currently using v1.2.3. I know a lot of work has been done with v2.x since this summer. Do you reckon it's safe to make the switch yet?

Cheers,
Adam

[PaulZC]

Hi Adam,

Apollo3 v2.1.1 has a 'feature' which makes communication with the u-blox modules problematic. I just wanted to make sure you weren't using that. If you are going to upgrade, go with v2.1.0 for now - until v2.2.0 is released.

Here's what I get with:

• MicroMod Data Logging board
• Artemis Processor
• ZED-F9P GPS RTK2 (not the SMA version)
• Apollo3 v1.2.3
• SparkFun u-blox GNSS Library v2.0.17
• Example25 (unmodified)
• I2C jumper links open on both the Data Logging board and the ZED-F9P board

A little weirdness, but only a little.

If I add:

Wire.setPullups(0); // Disable the internal pull-ups on the Artemis (Apollo3 v1)

after:

Wire.begin();

I get:

So, right now, I can't replicate what you're seeing...

Cheers,
Paul

[adamgarbo]

Hi Paul,

Thanks for checking on your end. Our setup is almost identical except for the hardware version of the ZED-F9P.

I tried incrementally increasing the navigation ratio while keeping the measurement rate constant at 5000 ms. It looks like it begins to fail at a ratio of 3 or higher.

�SparkFun u-blox Example
16:05:49.817 -> Current measurement interval (ms): 1000
16:05:49.817 -> Current navigation ratio (cycles): 1
16:05:49.817 -> New measurement interval (ms): 5000
16:05:49.854 -> New navigation ratio (cycles): 1
16:05:49.891 -> Lat: 454001160 Long: -757070006 Interval: 0.04s
16:05:50.846 -> Lat: 454001157 Long: -757070013 Interval: 0.99s
16:05:55.885 -> Lat: 454001153 Long: -757070016 Interval: 5.02s
16:06:00.852 -> Lat: 454001145 Long: -757070017 Interval: 5.00s
16:06:05.858 -> Lat: 454001102 Long: -757070059 Interval: 5.01s
16:06:38.614 -> �SparkFun u-blox Example
16:06:49.000 -> Current measurement interval (ms): 5000
16:06:49.000 -> Current navigation ratio (cycles): 1
16:06:49.034 -> New measurement interval (ms): 5000
16:06:49.034 -> New navigation ratio (cycles): 2
16:06:49.890 -> Lat: 454001038 Long: -757070240 Interval: 0.86s
16:06:50.881 -> Lat: 454001037 Long: -757070243 Interval: 1.00s
16:07:00.873 -> Lat: 454001037 Long: -757070241 Interval: 10.02s
16:07:10.884 -> Lat: 454001040 Long: -757070229 Interval: 10.01s
16:07:20.885 -> Lat: 454001041 Long: -757070222 Interval: 10.01s
16:07:32.001 -> �SparkFun u-blox Example
16:07:37.473 -> Current measurement interval (ms): 5000
16:07:37.473 -> Current navigation ratio (cycles): 2
16:07:37.509 -> New measurement interval (ms): 5000
16:07:37.509 -> New navigation ratio (cycles): 3
16:07:40.860 -> Lat: 454001033 Long: -757070164 Interval: 3.37s <- No data afterwards

I switched to an entirely different MMDLCB and Artemis Processor and also to the same u-blox GPS-RTK2 ZED-F9P board (not SMA) and ended up with the same Send I2C Command failed loop.

16:30:16.465 -> Sending: CLS:NAV ID:PVT Len: 0x0 Payload:
16:30:16.465 -> sendCommand: Waiting for No ACK response
16:30:16.465 -> checkUbloxI2C: OK, zero bytes available
16:30:16.499 -> checkUbloxI2C: OK, zero bytes available
16:30:16.534 -> checkUbloxI2C: OK, zero bytes available
16:30:16.534 -> checkUbloxI2C: OK, zero bytes available
16:30:16.567 -> checkUbloxI2C: OK, zero bytes available
16:30:16.601 -> checkUbloxI2C: OK, zero bytes available
16:30:16.635 -> checkUbloxI2C: OK, zero bytes available
16:30:16.635 -> checkUbloxI2C: OK, zero bytes available
16:30:16.668 -> checkUbloxI2C: I2C error: endTransmission returned 4
...
16:30:17.907 -> checkUbloxI2C: I2C error: endTransmission returned 4
16:30:17.942 -> waitForNoACKResponse: TIMEOUT after 1103 msec. No packet received.
16:30:17.942 -> 
16:30:17.942 -> Sending: CLS:NAV ID:PVT Len: 0x0 Payload:
16:30:17.942 -> Send I2C Command failed
16:30:17.942 -> 
16:30:17.942 -> Sending: CLS:NAV ID:PVT Len: 0x0 Payload:
16:30:17.942 -> Send I2C Command failed
...

Very strange! The only common denominators are the GNSS antenna and my Apollo3 Core and u-blox library files.

Cheers,
Adam

[PaulZC]

Hi Adam,

This is a head-scratcher...

I think most of what you're seeing in terms of waitForNoACKResponse timing out is expected. The module will only respond when it has a new PVT solution ready. But I am wondering if there are some residual I2C bus errors which are complicating things. Please do try adding Wire.setPullups(0); after Wire.begin();. That will almost certainly help. And please check your Qwiic cable. Maybe it is a bit iffy?

I see:

09:16:41.677 -> Sending: CLS:NAV ID:PVT Len: 0x0 Payload:
09:16:41.677 -> sendCommand: Waiting for No ACK response
09:16:41.677 -> checkUbloxI2C: OK, zero bytes available
09:16:41.726 -> checkUbloxI2C: OK, zero bytes available
09:16:41.726 -> checkUbloxI2C: OK, zero bytes available
09:16:41.774 -> checkUbloxI2C: OK, zero bytes available
09:16:41.774 -> checkUbloxI2C: OK, zero bytes available
09:16:41.821 -> checkUbloxI2C: OK, zero bytes available
09:16:41.865 -> checkUbloxI2C: OK, zero bytes available
09:16:41.865 -> checkUbloxI2C: OK, zero bytes available
09:16:41.911 -> checkUbloxI2C: OK, zero bytes available
09:16:41.911 -> checkUbloxI2C: OK, zero bytes available
09:16:41.958 -> checkUbloxI2C: OK, zero bytes available
09:16:41.958 -> checkUbloxI2C: OK, zero bytes available
09:16:42.005 -> checkUbloxI2C: OK, zero bytes available
09:16:42.005 -> checkUbloxI2C: OK, zero bytes available
09:16:42.052 -> checkUbloxI2C: OK, zero bytes available
09:16:42.099 -> checkUbloxI2C: OK, zero bytes available
09:16:42.099 -> checkUbloxI2C: OK, zero bytes available
09:16:42.146 -> checkUbloxI2C: OK, zero bytes available
09:16:42.146 -> checkUbloxI2C: OK, zero bytes available
09:16:42.193 -> checkUbloxI2C: OK, zero bytes available
09:16:42.193 -> checkUbloxI2C: OK, zero bytes available
09:16:42.240 -> checkUbloxI2C: OK, zero bytes available
09:16:42.240 -> checkUbloxI2C: OK, zero bytes available
09:16:42.287 -> checkUbloxI2C: OK, zero bytes available
09:16:42.334 -> checkUbloxI2C: OK, zero bytes available
09:16:42.334 -> checkUbloxI2C: OK, zero bytes available
09:16:42.379 -> checkUbloxI2C: OK, zero bytes available
09:16:42.379 -> checkUbloxI2C: OK, zero bytes available
09:16:42.426 -> checkUbloxI2C: OK, zero bytes available
09:16:42.426 -> checkUbloxI2C: OK, zero bytes available
09:16:42.473 -> checkUbloxI2C: OK, zero bytes available
09:16:42.473 -> checkUbloxI2C: OK, zero bytes available
09:16:42.520 -> checkUbloxI2C: OK, zero bytes available
09:16:42.566 -> checkUbloxI2C: OK, zero bytes available
09:16:42.566 -> checkUbloxI2C: OK, zero bytes available
09:16:42.613 -> checkUbloxI2C: OK, zero bytes available
09:16:42.613 -> checkUbloxI2C: OK, zero bytes available
09:16:42.660 -> checkUbloxI2C: OK, zero bytes available
09:16:42.660 -> checkUbloxI2C: OK, zero bytes available
09:16:42.709 -> checkUbloxI2C: OK, zero bytes available
09:16:42.709 -> checkUbloxI2C: OK, zero bytes available
09:16:42.754 -> checkUbloxI2C: OK, zero bytes available
09:16:42.801 -> checkUbloxI2C: OK, zero bytes available
09:16:42.801 -> waitForNoACKResponse: TIMEOUT after 1100 msec. No packet received.
09:16:42.801 -> 
09:16:42.801 -> Sending: CLS:NAV ID:PVT Len: 0x0 Payload:
09:16:42.801 -> sendCommand: Waiting for No ACK response
09:16:42.801 -> checkUbloxI2C: OK, zero bytes available
09:16:42.847 -> checkUbloxI2C: OK, zero bytes available
09:16:42.847 -> checkUbloxI2C: OK, zero bytes available
09:16:42.894 -> checkUbloxI2C: OK, zero bytes available
09:16:42.894 -> checkUbloxI2C: OK, zero bytes available
09:16:42.941 -> checkUbloxI2C: OK, zero bytes available
09:16:42.941 -> checkUbloxI2C: OK, zero bytes available
09:16:42.988 -> checkUbloxI2C: OK, zero bytes available
09:16:43.034 -> checkUbloxI2C: OK, zero bytes available
09:16:43.034 -> checkUbloxI2C: OK, zero bytes available
09:16:43.081 -> checkUbloxI2C: OK, zero bytes available
09:16:43.081 -> checkUbloxI2C: OK, zero bytes available
09:16:43.129 -> checkUbloxI2C: OK, zero bytes available
09:16:43.129 -> checkUbloxI2C: OK, zero bytes available
09:16:43.175 -> checkUbloxI2C: OK, zero bytes available
09:16:43.175 -> checkUbloxI2C: OK, zero bytes available
09:16:43.222 -> checkUbloxI2C: OK, zero bytes available
09:16:43.269 -> checkUbloxI2C: OK, zero bytes available
09:16:43.269 -> checkUbloxI2C: OK, zero bytes available
09:16:43.316 -> checkUbloxI2C: OK, zero bytes available
09:16:43.316 -> checkUbloxI2C: OK, zero bytes available
09:16:43.363 -> checkUbloxI2C: OK, zero bytes available
09:16:43.363 -> checkUbloxI2C: OK, zero bytes available
09:16:43.410 -> checkUbloxI2C: OK, zero bytes available
09:16:43.410 -> checkUbloxI2C: OK, zero bytes available
09:16:43.456 -> checkUbloxI2C: OK, zero bytes available
09:16:43.456 -> checkUbloxI2C: OK, zero bytes available
09:16:43.503 -> checkUbloxI2C: OK, zero bytes available
09:16:43.550 -> checkUbloxI2C: OK, zero bytes available
09:16:43.550 -> checkUbloxI2C: OK, zero bytes available
09:16:43.597 -> checkUbloxI2C: OK, zero bytes available
09:16:43.597 -> checkUbloxI2C: OK, zero bytes available
09:16:43.643 -> checkUbloxI2C: OK, zero bytes available
09:16:43.643 -> checkUbloxI2C: OK, zero bytes available
09:16:43.690 -> checkUbloxI2C: OK, zero bytes available
09:16:43.690 -> checkUbloxI2C: OK, zero bytes available
09:16:43.735 -> checkUbloxI2C: OK, zero bytes available
09:16:43.782 -> checkUbloxI2C: OK, zero bytes available
09:16:43.782 -> checkUbloxI2C: OK, zero bytes available
09:16:43.829 -> checkUbloxI2C: OK, zero bytes available
09:16:43.829 -> checkUbloxI2C: Reading 100 bytes
09:16:43.875 -> Incoming: Size: 92 Received: CLS:NAV ID:PVT Len: 0x5C Payload: 60 D0 86 1B E5 7 A 1D 8 10 2A 37 19 0 0 0 7A CD 5 0 3 1 EA 1B ** ** ** ** ** ** ** ** 5 59 2 0 E9 9D 1 0 DD 5 0 0 76 9 0 0 4 0 0 0 FD FF FF FF 0 0 0 0 5 0 0 0 0 0 0 0 64 0 0 0 80 A8 12 1 64 0 0 0 6C 18 42 3E 0 0 0 0 0 0 0 0
09:16:43.875 -> packetCfg now valid
09:16:43.875 -> packetCfg classAndIDmatch
09:16:43.875 -> waitForNoACKResponse: valid data with CLS/ID match after 1089 msec
09:16:43.875 -> Lat: 5***66036 Long: -1***4121 Interval: 60.04s

Also, please try running Example21_ModuleInfo. I'm curious to see what firmware version (FWVER) your modules have on them. Mine is:

Thanks!
Paul

[adamgarbo]

Hi Paul,

Looks like my receivers are running firmware versions 1.12 (SparkFun GPS-RTK-SMA) and 1.10 (SparkFun GPS-RTK2). I can certainly try upgrading them.

I tried running Example25_MeasurementAndNavigationRate with a SparkFun Qwiic Micro and observed the same behaviour with a measurement rate of 5000 ms and navigation ratio of 12. For some reasons it falls apart and goes to 1 second.

09:36:08.878 -> SparkFun u-blox Example
09:36:08.955 -> Current measurement interval (ms): 1000
09:36:08.955 -> Current navigation ratio (cycles): 1
09:36:08.989 -> New measurement interval (ms): 5000
09:36:08.989 -> New navigation ratio (cycles): 12
09:36:09.933 -> Lat: 0 Long: 0 Interval: 0.94s
09:36:32.654 -> Lat: 0 Long: 0 Interval: 22.57s
09:36:33.653 -> Lat: 0 Long: 0 Interval: 0.98s
09:36:34.663 -> Lat: 0 Long: 0 Interval: 1.02s
09:36:35.680 -> Lat: 0 Long: 0 Interval: 0.99s
09:36:36.674 -> Lat: 0 Long: 0 Interval: 1.01s
09:36:37.667 -> Lat: 0 Long: 0 Interval: 0.99s

I opened up a brand new SparkFun GPS-RTK-SMA and ran the same test (I2C pull-ups not cut) and had interesting results. It actually worked at the proper interval for two minutes before failing back to 1 s.

09:42:56.807 -> SparkFun u-blox Example
09:42:56.841 -> Current measurement interval (ms): 1000
09:42:56.841 -> Current navigation ratio (cycles): 1
09:42:56.841 -> New measurement interval (ms): 5000
09:42:56.841 -> New navigation ratio (cycles): 12
09:42:56.984 -> Lat: 453984590 Long: -756873124 Interval: 0.14s
09:43:41.981 -> Lat: 453983856 Long: -756861582 Interval: 44.98s
09:44:42.010 -> Lat: 453983046 Long: -756847999 Interval: 60.02s
09:45:41.998 -> Lat: 453984976 Long: -756857149 Interval: 59.99s
09:45:59.143 -> Lat: 0 Long: 0 Interval: 17.15s
09:46:00.185 -> Lat: 0 Long: 0 Interval: 1.03s
09:46:01.170 -> Lat: 0 Long: 0 Interval: 1.02s
09:46:02.189 -> Lat: 0 Long: 0 Interval: 0.99s
...
09:46:39.394 -> Lat: 477480626 Long: 398822871 Interval: 1.20s
09:46:40.424 -> Lat: 477984906 Long: 398857238 Interval: 1.02s
09:46:41.409 -> Lat: 478501575 Long: 398891745 Interval: 1.00s
09:46:42.082 -> Lat: 140358499 Long: 744037061 Interval: 0.67s

This is super bizarre! I've tested 3 difference receivers with 3 different microcontrollers (Artemis & SAMD21) and multiple Qwiic cables. At first I was thinking it may have been hardware related, but I just can't see that being the case now.

Do you think the firmware could be to blame?

Cheers,
Adam

[adamgarbo]

Hi Paul,

I've upgraded all of my receivers to 1.13 but it didn't make a noticeable difference. However, I think I may be on to something. It appears the issue may possibly be power related...

Can I ask how were you powering your MMDLCB and ZED-F9P? I've noticed that when I connect a separate 5V USB battery to the ZED-F9P, the output of Example25_MeasurementAndNavigationRate is as expected:

USB C + 4.2V LiPo + 5V USB Battery

10:46:51.916 -> �SparkFun u-blox Example
10:46:52.307 -> Current measurement interval (ms): 5000
10:46:52.307 -> Current navigation ratio (cycles): 12
10:46:52.307 -> New measurement interval (ms): 5000
10:46:52.307 -> New navigation ratio (cycles): 12
10:47:42.006 -> Lat: 453997700 Long: -757083694 Interval: 49.59s
10:48:41.992 -> Lat: 453996622 Long: -757086970 Interval: 59.88s
10:49:41.986 -> Lat: 454001339 Long: -757072420 Interval: 59.88s
10:50:42.002 -> Lat: 454003209 Long: -757066315 Interval: 59.89s
10:51:41.968 -> Lat: 454003243 Long: -757066084 Interval: 59.89s
10:52:42.013 -> Lat: 454000814 Long: -757072681 Interval: 59.91s
10:53:42.020 -> Lat: 454003349 Long: -757066226 Interval: 59.90s

Removing the USB battery and things go back to being broken, even with a 4.2 V LiPo powering the MMDLCB.

USB C + 4.2V LiPo

10:55:12.811 -> SparkFun u-blox Example
10:55:12.916 -> Current measurement interval (ms): 1000
10:55:12.916 -> Current navigation ratio (cycles): 1
10:55:12.950 -> New measurement interval (ms): 5000
10:55:12.950 -> New navigation ratio (cycles): 12
10:55:41.134 -> Lat: 0 Long: 0 Interval: 28.13s
10:55:42.136 -> Lat: 0 Long: 0 Interval: 1.00s
10:55:43.120 -> Lat: 0 Long: 0 Interval: 0.98s
10:55:44.144 -> Lat: 0 Long: 0 Interval: 1.00s
10:55:45.136 -> Lat: 0 Long: 0 Interval: 1.00s

Removing the 4.2V LiPo and adding back the 5V USB battery and things work as expected!

USB C + 5V USB Battery

10:59:31.268 -> SparkFun u-blox Example
10:59:31.375 -> Current measurement interval (ms): 1000
10:59:31.375 -> Current navigation ratio (cycles): 1
10:59:31.410 -> New measurement interval (ms): 5000
10:59:31.410 -> New navigation ratio (cycles): 12
10:59:41.990 -> Lat: 454019997 Long: -757010463 Interval: 9.98s
11:00:41.983 -> Lat: 454024117 Long: -756991271 Interval: 59.93s
11:01:41.987 -> Lat: 454027900 Long: -756968512 Interval: 59.91s
11:02:41.972 -> Lat: 454029759 Long: -756982831 Interval: 59.92s
11:03:42.011 -> Lat: 454019160 Long: -757026593 Interval: 59.95s
11:04:41.968 -> Lat: 454021864 Long: -757027615 Interval: 59.91s

Cheers,
Adam

[PaulZC]

Hi Adam,

Ah ha! Now that is starting to look like a smoking gun...

I'm powering my boards via USB from my desktop computer. I am plugged in to an SS USB-C port. I don't have a LiPo battery attached.

Peak current draw on the ZED-F9P should only be 130mA or so. Plus a little more for your active antenna. You shouldn't be getting anywhere near a current that would cause a power brown-out. But your tests do seem to indicate that's what's happening.

The 2A resettable fuse on the MMDLCB prevents the board from drawing too much current from USB. If you suspect the fuse, you can solder the BYP jumper to bypass it.

Have a good look at your MEAS and MEAS_BATT jumpers. They're unlikely to be the cause of what you're seeing, but do check them.

The Qwiic port has its own voltage regulator. If you have a 'scope available, try monitoring the QWIIC_PWR and check for any voltage dips when you turn everything on.

If you have an alternate antenna, try that. Just to rule out your TOP106 drawing too much current and causing a brown-out.

Good luck with the detective work!
All the best,
Paul

[adamgarbo]

Hi Paul,

I believe I'm finally ready to close this issue!

After sorting out the power issues (it seems the order in which you provide power to the MMDLCB/ZED-F9P when also connecting to serial via USB-C seems to be really finicky and I haven't 100% figured it out), I started to run some additional tests with various measurement and navigation rates.

I'm happy to report that I did not experience the same issues as the original tests, where the receiver would seem to consistently lose its signal lock. I ran several tests and all were successful. Please see below for two examples, including the original test conditions.

Test 1

gnss.setMeasurementRate(5000);  // Set the measurement rate to 5 seconds (5000 milliseconds)
gnss.setNavigationRate(1); // Set the navigation rate (ratio) to 1 to produce a solution every 5 s

Test 2

gnss.setMeasurementRate(1000);  // Set the measurement rate to 1 second (1000 milliseconds)
gnss.setNavigationRate(15); // Set the navigation rate (ratio) to 15 to produce a solution every 15 s

It's difficult to say what may have caused initial issue, but I'm glad that for now it seems to have been resolved. I'll close this issue for the time being but will certainly open it back up again if I encounter the same issue in future RAWX/SFRBX logging.

I've also been in touch with Clive from the u-blox Support portal and he's advised in terms of best practice, if for example I wanted to log RAWX data at 5 seconds, I should use a measurement rate of 5000 ms and a navigation rate of 1. He also wasn't fond of the idea of a 30 second logging interval for PPP post-processing, so I suspect for the foreseeable future I'll continue to log at 1 Hz.

Relevant question:
https://portal.u-blox.com/s/feed/0D52p0000BbvoEPCQY

Cheers,
Adam

[PaulZC]

Hi Adam,

Thanks for the update. Glad that's working for you.

All the best,
Paul

[adamgarbo]

Hi Paul,

Rereading #70, do you think changes to UBX_RXM_RAWX_MAX_BLOCKS would have made a difference with the gaps in the data originally observed in this issue? With only GPS+GLONASS enabled, I doubt that I was ever pushing the limit, especially with a partially obstructed sky view.

Might have to chalk this one up to a random ephemeral bug!

Cheers,
Adam

[PaulZC]

Hi Adam,

You would only see data loss if the number of blocks in a single RAWX message exceeded UBX_RXM_RAWX_MAX_BLOCKS - originally 64, now 92. A useful question to answer is "with only GPS+GLONASS enabled, do the RAWX messages only contain blocks from GPS+GLONASS"? I'll have a look at that when I get some free time. A simple test would be to run the UBX Integrity Checker on your data. It will report the longest UBX message payload length. If that is close or equal to 2064 bytes (16 + 32 * 64), then data loss might have happened.

Cheers,
Paul