Slow or no fix on mRo GPS u-Blox Neo-M9N with Navigator

Hi all.

Just posting this in the hope that someone else has been through the optimisation exercise…

I have an mRo GPS u-Blox Neo-M9N GNSS attached to a BlueROV2 Navigator board (Serial 3) and with the following settings:

  • SERIAL3_BAUD = 38400
  • EK3_SRC2_POSXY = ExternalNav

My goal is only to get a GPS read while on the surface. My problem is really long Time To First Fix (TTFF) - or just doesn’t fix at all - flakeyness. This outside in the clear BTW.

I’ve checked GPS_RAW_INIT on the Mavlink Inspector and you can see that the GPS comms is happening - status goes from _NO_GPS to _NO_FIX. I’ve tried changing GPS_TYPE to UBLOX (no diff) and to NMEA (doesn’t work).

This is core functionality for Ardupilot/sub and the only difference is Navigator vs. Pixhawk controller… So, I’m interested to know if anyone else has seen reliable behaviour out of this particular GNSS device?

My next step is to start digging in to the Ublox PC utility (u-center) to see how fast I get a fix without the BlueROV2 in the loop. I’ll post my findings… Meanwhile, any advice appreciated!

Hi @PeterM,

Do you have a DVL, or some other kind of external positioning/navigation system? If not, this parameter value doesn’t make sense.

From the available forum discussions I’m yet to see truly robust surface GPS integration in ArduSub (for vehicles that actually submerge), but if you’re going to try:

The only reason I could think of for Navigator having different results to Pixhawk would be if the communications are getting interrupted or reconfigured by some other service (since Pixhawk doesn’t have anything else with access to its ports).

There has been a known Issue with the BlueOS ping service doing that, which is fixed in the 1.3.0 beta releases, so it might be worth updating to beta to see whether that resolves your problem.

1 Like

Hi @EliotBR

Sorry, should’ve mentioned that, yes we have a Waterlinked A50. The plan is to get GPS lat/long on the surface and then estimated position along a transect. We’re creating a GPX file and recording associated MJPG images.

I’ve scoured the forum posts - both BR and Ardupilot/sub. It does feel like there’s something flakey going on with the GPS so going back to basics with UBlox u-center (which is friggin’ horrid!) so I can learn more about how the M9N works. Beyond that, it might be time to look a different solution.

Will look into and try that. Thanks!

1 Like

Just updating this thread for anyone interested… It turns out the issue we were experiencing with no / slow time to first fix (TTFF) appears to be related to RFI/EMI inside the enclosure. We’ve jury-rigged some shielding inside the acrylic top tube, and voila, now fixes within seconds!

The pros/cons on mounting inside the enclosure vs. external I see as:


  • One less penetrator and enclosure - so fewer points of failure.
  • Lower cost (assuming shielding is cheap) than additional enclosures / parts.


  • Tricky to engineer. Might have to lower the electronics boards 10-20mm for this to work effectively.
  • More susceptable to water washing over the top. Externally mounted could be raised higher.

On that last point, was thinking it’s really having a clear (water free) angle of view to the satellites is the issue, not actually raising the device/antenna up, so one option might be a small dome mounted on top of the enclosure which reduces any splashing effects.

Thoughts anyone?

FYI @clyde and @tony-white and @EliotBR

@PeterM We have a Blueboat with the Navigator as well. We have tried 3 different GNSS. All work perfectly when plugged into a Pilot Cube. none start properly when plugged into the navigator board. we have tried getting power from main rail with seperate bec and that is better but there is still a significant difference between running from the navigator board and from a PArdupilot CUBE with respect to the number of sats it gets and how long it takes to get first fix.

we have been working on this for months now in between actual work. Im thinking there is something in BLUEOS that needs to be set so that the UART port works like an actual UART port.

Thanks Jason. Makes me scratch my head a bit on what’s really going on and how you get visibility on the problem… I believe we also added a clean 5vdc supply. @EliotBR : Any thoughts? Are other people experiencing problems with GNSS integration on Navigator?

I read this thread last night

I have messaged @williangalvani to supply a detailed description of what he did to get a simple UART port to work. Hopefully he will reply ASAP as I am loosing work not having this working properly. If I get a reply I will send to you immediately.

Have a look at my lengthy post over in my “GPS issues on vanilla BlueBoat” thread – I got mine working today.

1 Like