I have a Sparkfun RTK facet configured with SW Maps and using a trial NTRIP client from PointOneNav.
I left my facet outside and monitored the readings on SW Maps. I noticed latitude and longitude are very on point without changing for up to 7 sigfigs. However, the altitude has been changing slightly throughout. In the past two hours. I’ve seen it go as low as -16.822m and as high as -16.957m. The whole time it has been on RTK Fix.
Is this normal? I understand height is less accurate than lat/lon, but I wonder why it varies as the hours go by. 15 cm isn’t a huge margin, but is there a way improve on this?
Elevation is very sensitive to humidity. In opposite to ionosphere that is both above the reference station and the rover, you are inside the “humidity”. First recommendation is to have base and rover at similar elevation. I saw somewhere a recommendation for a difference of less 300 m. Is it your case? Also, what is the horizontal distance between base and rover?
X, Y, and Z accuracies are in that order typically. Your X component is generally the best, Z is the worst. There are many reasons for this, but most stem from the fact that Positioning relies on the principle of trilateration.
When you think about the orientation of satellites (birds) flying around overhead, the Z component is the most sensitive to errors in the trilateration calculations. The best birds for calculating a single distance are directly overhead, and the worst are low on the horizon. Geometry would point us to adding the birds low on the horizon to better “fix” a point in 3D space - but those signals must travel through more atmosphere than the rest. Low angles are also much more susceptible to Multi-Path interference at the receiver.
Now consider that the bird has traveled a couple hundred miles [Correction: meters] through space during the time it takes the RF signal to reach Earth. Plus the Earth is spinning and the Y coordinate has moved ~100’ during that time.
Thankfully, we have many birds to produce an overdetermined calculation. Sorry to geek-out. After 30 years in the industry I’m still amazed we can get cm solutions.
I’d look for Multi-Path at your receiver first. This is a problem for everyone and the easiest thing to mitigate.
Next, I’d suspect your Correction Source. No person or receiver can outperform their correction source. PointOneNav has OSR and SSR service plans. SSR is a computer model, and is “generally” less accurate than OSR. However, your baseline length gets critical in OSR.
Cheers to you for actually testing ! That’s the only way to truly know what you’re getting.
Note: The Facet is capable of reproducing points inside of 2cm over weeks of time with the proper correction source and field procedure.
P.S. @Eric_S has mentioned an interesting aspect that I’ve never really considered…because I live in flat country. I’d have to drive 12+ hours away to see a 300m “Mountain”
That was a generally good and helpful explanation from @rftop, but there are a couple of points that can use clarification, to avoid misconceptions for people new to GNSS surveying and navigation.
First, there’s the statement “the bird has traveled a couple hundred miles through space during the time it takes the RF signal to reach Earth.” For a GPS satellite (GLONASS, Galileo, and BeiDou should be roughly similar) on your horizon, the slant distance is about 27,300 km, so the maximum time-in-flight of the signal is about 0.091 s. The orbital velocity of a GPS satellite is about 3.9 km/s. The satellite will move about 350 meters along its orbit, rather than hundreds of miles.
Second, I assume that the references of “X, Y, and Z” are really intended to mean local “north, east, and up”, or “NEU”. Use of the X, Y, and Z symbols strongly implies that we’re talking about ECEF (Earth-Centered, Earth-Fixed) coordinates, which do not bear a simple relationship to a user’s local coordinates (e.g. to “up” or elevation). For example, the X, Y, and Z ECEF axes of the International Terrestrial Reference System are such that the Z axis points from Earth’s center of mass to the International Reference Pole, the X axis lies in the equatorial plane (the plane perpendicular to the Z axis and containing Earth’s center of mass) and points to the intersection of the International Reference Meridian with the equatorial plane, and the Y axis completes a right-handed, three-dimensional, Cartesian coordinate system (i.e. lies in the equatorial plane and points to the intersection of that plane and the 90º east meridian). Examples of X, Y, and Z ECEF coordinates can be seen in the outputs of the NGS OPUS and CRSR-PPP online processing services and in certain NGS survey mark data sheets. Unfortunately, there is traditional usage in land surveying (e.g. in data collector UIs), at least in the United States, of referring to local coordinates as NEZ (“north”, “east”, and “up”), thus blurring “up” and ECEF Z.
Not at all. If you ask an engineer or surveyor for X,Y,Z for a point- you’ll be getting State Plane the majority of the time.
X and Y are defined in SPCS, UTM,etc. It’s literally the definition of a Cartesian system.
“Z” instead of “Up” doesn’t make most people in my industry jump to assuming ECEF, in my personal experience.
Agreed, I blame that on so many people using AutoCAD PNEZD point files for several decades (Point# Northing Easting Elevation Description)…including myself.
It’s a valuable discussion as it shows just how easily things can get crossed up…quickly
