Unicore Galileo HAS bug?

GPS/GNSS
1

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?

2

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.

3

Hard to say what’s wrong.

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.

1 Like
4

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.

5

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.
image

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.

6

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:

  1. The Unicore Library or the FW doesn’t recognize that the Galileo E6 HAS correction source has a different reference frame.
  2. 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).

image
image659×560 88.6 KB

But Atmospheric Conditions wouldn’t explain the EAST bias everyday, I wouldn’t think.

I’ll continue to let the Torch cook this morning and see how the positions drift over time w/ Galileo E6 HAS corrections only.

[edit] After several hours, the RTK solutions using only Galileo E6 HAS corrections are 35cm to the East of my known position.

7

Thanks for looking. At least I know I wasn’t doing something dumb over and over again.

Here’s the details for the Galileo HAS reference frame - see Section 1.6.6.1

It’s essentially ITRF2020.

1 Like
8

Any update on Torch with only E6 corrections using latest firmware for all modules?
Are you now getting better accuracy (less drift)

Very interesting information and thank you for sharing TORCH details.

9

@ChrisO , I performed more tests and it seems like there was a “reasonable” guess as to what might be happening to cause the apparent East Bias. I need to find my notes.

1 Like
10

Below are some of my notes.
Please don’t take this to be factual information. These are guesses and assumptions. I did not thoroughly test to form any real conclusions.

Basically, the Torch is using some weird Reference Frame with HAS E6 (GTRF - but the East Shift changes over time). However, the Torch doesn’t seem to go back to GTRF once it has seen a different correction source, even though that correction has supposedly timed out. This still works when dumping the antenna (cover it and point to the ground) to force a new fix & solution (also weird).

With @sparky’s help, I fiddled with the UM980 Configuration.
My only change of consequence was :
CONFIG PPP DATUM WGS84 [ From SFE ]
changed to
CONFIG PPP DATUM PPPORIGINAL [ My Change ]

This change appears to have eliminated the HAS E6 Bias to the East.
It did not seem to negatively impact results from various OSR correction sources either.
I did Not check SSR correction sources.

I still had questions about this default setting:
CONFIG,RTK,CONFIG RTK RELIABILITY 3 1

image
image598×341 34 KB

Accumulated Delta Range (ADR) is dealing with the Carrier Phase and it seems a higher threshold might help the Ambiguity Resolution?

I didn’t take this any further, as I personally won’t need HAS E6 as a primary correction source.
It could be useful as a fallback in certain situations…for my scope of work.

1 Like
11

Thank you for sharing your results. I’m hoping some others with TORCH can comment about using E6 with no other correction source to see what they achieved in the real world.

12

@ChrisO , I put the Torch on my test stand a little bit ago for HAS E6 only. It got to RTK Float then started raining. I’ll try again later.

1 Like
13

Real world results for HAS with the Unicore UM980 receiver are basically as expected. About 20 cm horizontal and 40 cm vertical accuracy 95% of the time after convergence. Convergence often takes 20 to 30 minutes, sometimes longer. Note that receiver reported convergence is going to be optimistic.

This fits quite well with published specs. See section 1.5

HAS is still in its early stages.

My tests have all been static and in good GNSS receiving environments. I have roughly 40 days of data. Mostly 24 hour sessions recording raw data and looking at antenna performance, but might as well turn on HAS and look at it also.

I did one day under heavier tree cover where a GEO sat correction source would likely be blocked. There were no HAS correction dropouts since all Galileo sats send corrections. Accuracy did suffer by about a factor of two though because of the poor GNSS environment.

Is HAS going to compete with the accuracy of RTK services? No, but today it’s three to four times better than SBAS as far as accuracy goes. For integrity you do want SBAS - which is really what SBAS was designed for.

As mentioned earlier in the thread in HAS mode the UM980 only outputs a ITRF solution in the PPPNAVA sentence. The NMEA sentences are referenced to some different datum. It’s a fixed offset that depends on your location. I haven’t seen this mentioned in any Unicore documentation. Someone at Unicore knows. Anyway if a product like the Torch uses NMEA data this bias will be there. It’s only a few decimeters in my area in the center of North America, but is definitely significant when we are talking about a service capable of two decimeter accuracy.

Lastly I’ll add that the Unicore HAS processor occasionally stops working. Not often, but maybe every two or three days of data there is a few minute dropout or two. Is it the HAS system or the receiver? I’m leaning towards the receiver because one day it just quit for 95 minutes. During that time an autonomous position was output and the raw data was fine. When HAS came back it immediately jumped from autonomous to converged PPP.

Not too surprising that there are some quirks with the implementation of a new service.

3 Likes
14

20cm even waiting 30 minutes would be great/perfect for what I am doing. I need to be 2-3ft away from the property line with the firebreak I am putting in so even being 20 inches (~50cm) wrong would be acceptable. My property has some places where the DEED/SURVEY calls are as long as 1,500ft and 2,700ft. And others that are 7.23ft, 28.45ft, etc. Along the very long stretches I will put in T-bar posts every 100-200ft (3 within line of sight of each other) . I think the Torch is going to be my solution, just watching this forum for some more insights before making the final purchase decision. Hopefully then I can contribute insights about using it in farming/forestry work. (East Tennessee USA near Sweetwater)

15

@ChrisO , I’m afraid you wont be happy with a Torch and only using HAS E6.
The Torch is way too nice of a device to handicap it in that manner.

That’s like filling-up your Ferrari with kerosene :slight_smile:

I believe the Torch still ships with 1month of PointPerfect MQTT corrections included.
I think you will be spoiled after that and wont think about HAS E6 ever again.
I promise the $8/month is worth it, after a couple minutes of using PP verses HAS E6.
That’s especially true if you have a multi-path environment.

That’s just my $0.02, but it might not be worth that much :slight_smile:

1 Like
16

@jpb , I found a fix (1 config change to the RTK FW) that worked for me, see my long post above about “CONFIG PPP DATUM PPPORIGINAL”.

17

Well I am on a Yugo budget (do they still exist?)

I thought I had read a subscription was $60 a month or if you prepaid $600 a year. I just found this on the Torch registration for service confirming $8.00 a month (see below)

Do you mind sharing your full configuration? Which tablet or phone you use, which software apps you use (liked and disliked) I am about 95% sure I’m going to order the torch, just running down a few questions like Monthly fees, will I be satisfied with iPhone 11 or do I need an Android Tablet, etc.

Really appreciate all your insight.
Thank and regard, Chris

MPORTANT: By checking the box above you are agreeing to sign up for a subscription service to ublox’s PointPerfect network in order to utilize correction services with your SparkFun RTK Torch. SparkFun will automatically renew the applicable subscription services on a monthly basis and will take a payment of $8 from the payment method used for the device on file with SparkFun Electronics. You may cancel your subscription at any time by filling out this form and choosing to Cancel/deactivate my correction service in the proper form field above.

See SparkFun’s standard terms and conditions of sale, available here.

18

I tried every setting I could think of and still got the different datum issue. Just dumped my CONFIG file and it currently has the PPPORIGINAL setting. Maybe sending corrections to the receiver changes something or who knows? I’ve never tried RTK with it.

$CONFIG,ANTENNA,CONFIG ANTENNA POWERON7A
$CONFIG,NMEAVERSION,CONFIG NMEAVERSION V41047
$CONFIG,RTK,CONFIG RTK TIMEOUT 1206C
$CONFIG,RTK,CONFIG RTK RELIABILITY 3 176
$CONFIG,PPP,CONFIG PPP TIMEOUT 1206C
$CONFIG,PPP,CONFIG PPP ENABLE E6-HAS01
$CONFIG,PPP,CONFIG PPP DATUM PPPORIGINAL04
$CONFIG,DGPS,CONFIG DGPS TIMEOUT 3006C
$CONFIG,RTCMB1CB2A,CONFIG RTCMB1CB2A ENABLE25
$CONFIG,ANTENNADELTAHEN,CONFIG ANTENNADELTAHEN 0.0000 0.0000 0.00003A
$CONFIG,PPS,CONFIG PPS ENABLE GPS POSITIVE 500000 1000 0 06E
$CONFIG,MMP,CONFIG MMP ENABLE25
$CONFIG,SIGNALGROUP,CONFIG SIGNALGROUP 216
$CONFIG,ANTIJAM,CONFIG ANTIJAM AUTO2B
$CONFIG,AGNSS,CONFIG AGNSS DISABLE70
$CONFIG,BASEOBSFILTER,CONFIG BASEOBSFILTER DISABLE70
$CONFIG,COM1,CONFIG COM1 11520023
$CONFIG,COM2,CONFIG COM2 5760010
$CONFIG,COM3,CONFIG COM3 115200*23

For those interested here’s a chart showing typical HAS performance. This starts after the receiver says it’s converged (with default settings) which was about 8 minutes. It almost always needs at least a few more. Position error is mostly below a decimeter, but can kick up to 2 or even 3 decimeters on occasion. Very typical to what I see in my area.

has
has1029×651 43 KB

1 Like
19

The Torch has a duel Bluetooth mode, where it broadcasts in SPP and BLE at the same time.
Basically that means an iOS or Android device can connect without needing to change anything in the Torch Settings. I personally use an iPhone 13 with Diamond Maps or SW Maps, depending on what I’m doing.

I have field techs using all sorts of Smartphones and Tablets successfully everyday (with Facets and Facet-LB’s), but the same would apply for the Torch.

The main thing I change in RTK FW is the NMEA message rates. I like the following:
Message GPGGA: 1
Message GPGST: 4
Message GPGSV: 9-10
Message GPRMC: 1

The most budget-friendly solution will be the Sparkfun PostCard, by Far.
It’s brand new and operates on the same RTK Everywhere FW as the Torch.
It will take a little time to get a few quirks sorted out from it’s LG290P GNSS chip, but the PostCard is in a great position this early in it’s life.

1 Like
20

@jpb, that’s pretty darn good results for HAS E6.

I’m seeing sporadic “bogus” positions using HAS E6 only, in a multipath environment operating in RTK.
They sneak-in and the only way I notice is because I know the true coordinates.
In the nature of ~2’ Horizonal and ~4’ Vertical.