I’ve been testing the HAS performance of a stationary UM980 receiver under good GNSS receiving conditions and am seeing some quirks. The biggest is a convergence error of about 1/3 a meter in longitude. Given multiple hours the average longitude reported will be about 35cm to the east. I’ve seen this with multiple days of data. Latitude and height values are typically biased less than a decimeter. Has anyone else seen this?
I have done several days of testing with a Septentrio Mosaic board being fed by the same antenna as the Unicore board and recorded the raw HAS corrections to be processed with HASLIB as detailed here:
The latitude, longitude, and height values of the Mosaic data processed with RTKLIB in PPP kinematic mode do not show the large longitude bias.
I’m recording a NMEA GGA sentence every 15 seconds from the Unicore board to look at its position output along with raw data to determine the exact coordinates.
I’m in the center of North America if that matters. Again, has anyone seen something similar?
I’m surprised no has noticed the problems with the UM980 in Galileo HAS mode.
With firmware 11833 two different output coordinates happen.
The sentence PPPNAVA yields coordinates that are a reasonable estimate of (current epoch) ITRF2020 which is what the Galileo system is aligned to. At the same time NMEA sentences like GGA or others like BESTNAVA output different coordinates. At my location these have a fixed offset, once differential status is achieved, of about 7 cm in height, 4 cm in latitude, and 34 cm in longitude.
So, more than a foot difference. That’s a bug.
What’s going on? Is the NMEA output adjusted to the Chinese B2-PPP system datum? It kinda looks like “back in time” ITRF coordinates. I have no experience with current Chinese datums, but if B2-PPP uses a “Pseudo” ITRF1997; epoch 2000.0 system maybe that’s it.
If anyone can provide some clarity or actual testing numbers I’d appreciate it.
Did you performed online PPP calculation with NRCAN for comparison? Both with ITRF@now and NAD83. Also check position without HAS. For instance average 24h position measurement.
NAD83 isn’t really relevant. 24 hour autonomous data is going to have noise levels greater than the offset I see as does a 24 hour SBAS (WAAS) data set I recorded. The UM980’s code psuedoranges aren’t that great compared to say a Mosaic board so the noise levels won’t pick up a ~35 cm offset. That’s getting into noise levels even with a high quality code receiver.
The big picture was to potentially use HAS receivers to navigate with ~ 1 decimeter accuracy given enough convergence time. HAS can potentially do this, but a software app that accepts NMEA data isn’t going to work because of the extra error in the UM980’s NMEA output.
Again, that is at least for me. With more than a dozen days of data and trying various settings with multiple receiver resets. If anyone DOESN’T get different positions from PPPNAVA and NMEA GGA sentences with a UM980 receiver (firmware 11833) I would be very interested.
From what I read - The Galileo HAS system uses the Galileo Terrestrial Reference Frame (GTRF).
I could not find any specific info on which ITRF realization was used to create the latest GTRF, or what the “current” version used by HAS E6 even is.
Looking at a GTRF Velocity Map, it is interesting that you are seeing a bias to the East, since the movement is to the West… almost like the Correction Service Reference Frame (or the hand full of Network Stations in the USA) is way out of date ? That sounds possible, but it’s unlikely.
I’ve been meaning to play around with the Galileo E6 HAS corrections on a Torch (UM980).
I’ll let ya know what I see.
I have some interesting preliminary results for E6 HAS on the SparkFun Torch.
The Torch needed about 12 minutes for PPP Convergence on my test stand control point.
The Solution remained in Float and reported 0.12’ Horizontal Uncertainty.
The Positions were 3’-4’ directly East of the true coordinates.
I watch the positions bounce around for 30 minutes, all biased to the East.
The Neat Part:
I then sent 2 seconds of NTRIP RTCM corrections to the Torch. It immediately landed on the correct control point coordinates with an RTK Fix of 0.03’ reported Horizontal Uncertainty (as expected).
I turned off the NTRIP after 2 seconds and waited for the RTCM corrections to expire.
The East bias never showed back up, even after 30+ more minutes of Galileo E6 HAS corrections only.
I have 2 initial guesses:
The Unicore Library or the FW doesn’t recognize that the Galileo E6 HAS correction source has a different reference frame.
The Galileo E6 HAS is not yet transmitting Atmospheric Corrections.
In reference to #2, I have some local Ionosphere activity this morning (a 6 on the Index).
