What is the trigger for the "$GNTXT,01,01,01,Reference station position seems incorrect" message?

[tonycanike]

Subject of the issue

What situations cause the "$GNTXT,01,01,01,Reference station position seems incorrect" message to be written to the log file?

Is the firmware comparing the $GNGGA message coordinates to the fixed coordinates that the firmware last set the base to?

Is there some distance criteria?

If I turn the base on and it's still configured with fixed coordinates from somewhere else yesterday, that is the firmware (profile) base coordinates were from yesterday and the base is now somewhere else, will it emit those messages and then stop when I WiFi config in today's coordinates?

But if it's started with yesterday's configuration, wouldn't the $GNGGA coordinates be identical to the coordinates the firmware set yesterday and saved in the profile, as wrong and as far away as they may be, so the firmware would think the coordinates are fine. Then why are there any "Reference station position seems incorrect" messages?

Or is there something more complex going on, like the ZED knows the base coordinates are off by some distance, issues a message indicating that, and the RTK Firmware reports that.

Carlson SurvPC supports configuring the ZED directly. It's really helpful to, with the push of a button, set the base coordinates to any point in my survey project file on my data collector. We generally work in state plane coordinates, and the boss will sometimes text me state plane coordinates for a new base setup. It's much easier to put the NAD83 state ploane northings and eastings in US Survey Feet (not even international feet) into my DC and set the Facet ZED base coordinate with SurvPC. So I often power up the base, configure it using WiFi config with wrong but close coordinates, let it start and beging transmitting RTCM, and then set the base coordinates with SurvPC. Will the RTK Firmware then continuously emit "Reference station position seems incorrect" messages to the log all day long? That's not unreasonable, the firmware remembers those wrong-but-close coordinates and the $GNGGA coordinates don't match.

I'm asking so I know as I'm hand-editing the million-record big "SFE" file from yesterday.

Facet running 3.3-DEV March 13 and 3.2-release

PS crazy note: Philadelphia, Pennsylvania, USA has their own definition of a foot. Surveyors around here have three different "feet" they need to work in.

[tonycanike]

[nseidle]

Reference station position seems incorrect

You threw me for a loop. This text does not appear in our codebase. We don't generate it. Instead, the ZED-F9P is reporting this error on its own.

Source is for M8 module but u-blox shares a lot between modules. Above, it seems the coordinates assigned to your base station are off enough for it to throw a warning. I've seen similar messages when the baseline is too big (see section with WARNING: DGNSS baseline big: 10km).

Are you entering coordinates in the new DD MM SS format? I wonder if you're entering coordinates in the Config page and they are getting corrupt. I will check but please let me know.

PS crazy note: Philadelphia, Pennsylvania, USA has their own definition of a foot. Surveyors around here have three different "feet" they need to work in.

You have to tell me more! This is fascinating! I mean, US units (foot, oz, bushel) are bonkers. But you'd think they'd learn from the Vasa.

[nseidle]

I'm guessing you're not setting up your base outside of Hotan, China 38.1926082, 079.6139934 (what your output shows). So we've dropped a negative sign somewhere as I believe you are in Williamsville, VA 38.1926082,-79.6139934.

Edit: Never mind. GGA sentence is correctly showing N/W. Can you send me the coordinates in the exact format you entered into the config page?

[tonycanike]

I don't believe this is/was a problem with the RTK firmware. Just a result of turning on a base fixed with coordinates from another location. Once I configured it for the day's coordinates the message no longer appeared in the log file.

That explains it, thanks! I updated my branch on my desktop and searched all the code, and the code for the SFE GNSS library too. And the old version of the GNSS library as it looked like it's recently updated. I didn't find the message!

Those coordinates were from my previous day's work, about 1.15 miles away from where the base was on the current day. It was still configured with the fixed base coordinates from the previous day when I turned it on. It was a few minutes before I configured it with the base coordinates for the day.

Though I did make the missing minus sign error once last year and my Rover would not fix. Took my a while to figure out what I did wrong.

[tonycanike]

https://www.sizes.com/units/yard_international.htm To eliminate such problems, Australia, Canada, New Zealand, South Africa, the United Kingdom, and the United States agreed that effective July 1, 1959, 1 international yard = 0.9144 meter exactly. So a "International Foot" is exactly 0.3048m. That's exactly 2.54cm to an inch.

Before 1959, the US used a foot that was 1200/3937 meters. That's 39.37" to a meter exactly. So the US Foot is about 0.304800610... m.

Currently, various US states by law have surveyors use US Feet, International Feet, or Meters. However surveyors, despite state laws, routinely need to work in the units that were uses in the original land title or subsequent surveys. Chains, rods, varas, etc.

Philly just adds 3" to every 100 US feet to make 100 Philadelphia "District Standard" feet.

https://www.phila.gov/media/20220127093407/PZ_016_FAQ_Survey-Standards-on-Zoning-Plans-1.27.2022.pdf

[nseidle]

My mind is blown. I feel so bad for surveyors!