Maximum measurement rate of Neo M8P over USB

0 votes
I'm trying to maximize the measurement rate of the Neo M8P. I've set up communication with the M8P over USB disabling all protocols on all other I/O ports and setting USB input protocols to UBX and output protocols to UBX + NMEA. I've tried setting output protocols to just UBX, but somehow that breaks communication (GPTXT?). I have disabled all UBX and NMEA messages except for UBX-NAV-PVT to reduce the bandwidth to the bare minimum (Port is set at 921600 baud, so that should not be a limiting factor.) I'm tracking GPS only. Other GNSS services are disabled.  I get a proper ACK when I set UBX-CFG-RATE Measurement Period to 50 milliseconds (20 Hz), Navigation Rate to 1, so I expect the hardware to deliver a PVT solution at 20 Hz. When I check the output I'm getting fresh PVT messages at 10 Hz. Is 10 Hz the absolute maximum the chip can deliver, or am I doing something wrong? Power mode is set to Continuous Mode. Power management setup is Balanced (default).  Thank you for your help.

by dtecta asked Mar 29
0 votes
The NEO-M8P datasheet appears to be quite clear on maximum navigation rates under different modes, none of which are 20 Hz.
You might have assumed the wrong maximum  rate based on a ROM-only part like the M8Q..
You should also refer to the many forum questions on navigation rate with answers from clive1 explaining  that you must first understand the timeline relationships and not blindly drive for maximum nav rate without understanding some basics like ---GNSS tells you where you were, not where you are, regardless of nav rate.
by grampy answered Mar 29
by grampy edited Mar 29
One needs a systemic understanding of time, and an ability to compensate for variable latency in the delivery of a solution.

A system would want to use the TIMEPULSE (1PPS) to establish a common time line on to which the solution can be placed, and then extrapolated to the current instant.
Thanks for pointing me to the data sheet. I can't believe I missed that. And thanks for stressing the latency on the PVT data. Will RTFM. This stuff is all pretty new to me, so please forgive my ignorance.
0 votes
Please review the product summary

Solution rate for GPS only RTK is 8 Hz, for regular solution and raw carrier measurements, 10 Hz

The current iteration of the design is constrained by processing bandwidth and FLASH based firmware, already using a smaller number of channels, but well above the number of GPS satellites you'll see at any one time.


The NEO-M8U supports HNR (High Navigation Rate) of the order 20 Hz, but this is somewhat of a hybrid solution using GNSS and inertial data.
by clive1 answered Mar 29
Thanks for your helpful answers. Actually, I need to fuse the GPS PVT data with my own inertial data, so latency is going to be important. I will dive into the documentation to study the timeline issues regarding variable latency.
A lot of early drone designs didn't use 1PPS, just TX,RX pins, always confused me how they managed time/motion.

You can use TIMEPULSE (1PPS) to understand top-of-second and MPU clock speed, to close the loop you can use TIMEMARK (EVENTIN) to have the GPS time stamp a pulse you generate, ie shutter open on camera, so the receiver can report event time in sub-microsecond realm (will compute in nano-second)

Receivers designed for high-dynamics have much shorter integration times, sensitivity and CNO tends to drop as a result, compared to consumer receivers. For 20G I'd probably be at 4-5ms vs 15-16ms for 4G