Re: ✘NTRIP and RTCM

[Greg Troxel]

"Gary E. Miller" <gem@rellim.com> writes:

>> The RTCM2.3 you are feeding it is not bad, just L1/GPS
>> only, I think.
>
> Actually, L1/L2, the M9P can use L2.

Yes, but what is in the RTCM2.3 correctiosn stream you are using?

>> It seems reasonable of a receiver to use differential data that is
>> presented to it if that differential mode is configured on.
>
> Where do you configure a u-blox?  I thought it auto detected the
> incoming RTCM.

You use u-center and it is vast.   I am pretty sure you can tell it not
to listen to some things.

But if you don't want it to use RTCM2.3 it's easy not to send it.

>> Do you mean "GLONASS is not available"
>
> But neither are available from ORGN.
>
> https://en.wikipedia.org/wiki/GPS_signals
>
> "L2C, L5 and L1C are modernized signals, are only broadcast by newer
> satellites (or not yet at all), and as of January 2021, none are yet
> considered to be fully operational for civilian use."
>
> But it is on more than 1/2 the birds:
>
> "As of January 2021, L2C is broadcast on 23 satellites and is expected
> on 24 satellites by 2023."

I hadn't heard of L1C; will have to go read about that.

I thought L2C was basically a C/A code on L2, like the one that's always
been there on L1.  L2 originally only had P/Y code.  But maybe I have
that wrong.

>> or "the ORGN RTCM2.3 feed does not have GLONASS data"?
>
> Some ORGN has GLONASS, but not the ones near me.

Ah, that's a big deal. It could also explain why your receiver is not
going into FIX as much as I would expect.

MaCORS, for RTCM3 at least, I believe has dual-frequency data for all 4
constellations.

>> When using an F9P, it can output NMEA with one level of resolution,
>> or a different way with more.  Or at least it will output NMEA with
>> lots of decimal places, even if it's always lots.  That's all I meant.
>
> I looked in the doc, and can';t find how to change that.  Can you
> point me at the right place?

I'll see if I can find it.  But what are you getting for precision in NMEA?

>> I think I'm getting at least 1 mm resolution.  In my experience that's
>> good enough, as 1 cm quantization changes the feel of the data, and 1
>> mm doesn't really.
>
> I would doubt that. 1mm would be 1e-8.  From here:
>
> https://gpsd.io/gpsd-numbers-matter.html#_latitude_and_longitude
>
> Only the HP variants of u-blox output better than 1e-7.

I'll have a look at some tracks.  I think I am seeing 8 digits of
lat/lon in NMEA.  I am not using the UBX messages, for no good reason.

> I'm trying to   duplicate my MAX plot, but so far I'm getting about
> 0.17m sep.  So the 0.044 was an anomaly.
>
> I'm also trying HP mode, but at 0.17m sep, that does not change much
> but the noise level.

The receiver will only transition from FLOAT to FIX when the residuals
from a FIX choice of the integer ambiguities are significantly lower
than the next best choice of integer ambiguities.  At least that's how
it is supposed to be done, and ublox probably doesn't say.

>> > They are all 3D differential.  Nothing more to say.  u-blox does not
>> > report RTK float of RTK fix.  AFAIK they never really meant
>> > anything.  
>> 
>> It really does mean something, but if the binary UBX protocol doesn't
>> report that, you can't tell.  That strikes me as very strange.
>
> Seems right to me.  Why do we care that 20+ yearss ago that 64 bit
> floating point was not an option for an embedded CPU?

I can't follow that at all.

>> That's crazy.  In NMEA from F9P the field is there.  It just does not
>> make sense that hte binary output would not have this data available
>> somehwere somehow.  But maybe it is true.
>
> It is true.  Just search the u-blox doc for RTK.  It is only mentioned
> in the NMEA section.  Once you have the sep, who cares how it was
> calculated?

Because when you are in the field, getting one position, knowing if it
is FIX or FLOAT gives you a different error estimate.  And you are NOT
calculating SEP.  You are calculating what SEP would be if the average
position is correct.  And you can't boot up and know it in a few
minutes.


> The concept is clear, the implementation is unclear.  Got a pointer to
> how the equations differ?  Nothing is in the u-blox doc.

It's very well known in the literature.

> And once you have 172 channels of data, and RTCM data, and 64 bit
> floating point, why would you calcualte in anything but floating
> point?

Ah that's the issue -- RTK FLOAT and RTK FIX has nothing to do with
using floating point math.  Yes, this is all adequately precise math
(and floating vs scaled fixed point is an implementation detail that we
have zero idea about in the F9P).

RTK is a carrier phase solution, with the basic operation being double
differences (sat1-ref - sat1-you) - (sat2-ref - sat2-you).  Of course
for many pairs of satellites.  This is what you get with hour's of data
submitting to OPUS.

With carrier phase all the cycles look alike, so you have to estimate
some number of cycles offset from you to the other receiver.  You start
off with a real number of cycles,even though physically it must be an
integer.  That is RTK FLOAT mode.  (Yes, the terms FLOAT and FIX evoke
computer number representation, but the point is if it is a real number
or an integer mathematically, not what kind of variable it is stored
in.)

Then, the receiver searches for integer values of cycle offset that lead
to low residuals, and if one choice is better than the rest it adopts
them.

The R part of RTK is that once you have fixed the ambiguities and you
hold cycle-level lock on signals you can continue to deliver cm-level
positions.  And the K part is that you can move while doing this and
keep cm-level positions.

https://gssc.esa.int/navipedia/index.php/RTK_Fundamentals

http://www.rtklib.com/
https://rtklibexplorer.wordpress.com/

and this matches your "u-blox is bad about reporting RTK status" notion

https://portal.u-blox.com/s/question/0D52p00008HKDByCAP/is-there-a-message-that-contains-the-rtk-integer-ambiguity-ratio-and-age-of-differential

An early paper, but I think if you read it, you'll find a good overview
of RTK.

https://www.researchgate.net/publication/2790708_The_LAMBDA_method_for_integer_ambiguity_estimation_implementation_aspects


>> But my F9P (with up-to-date firmware)
>> reports 1, 4 or 5 apparently correctly, in terms of matching the
>> "RTK" blinky light, and having error behaviors that seem to match.
>
> As far as you know, it could just toggle on the sep value.

It does not actually have a way to compute SEP, and it does not know if
it is moving so it cannot compute averages.

I have watched the position and the mode-value/light, and seen that the
position jumps to the correct (matching multiple previous RTK FIX
positions) when it transitions to FIX.


>> I have enhanced Vespucci to show an error circle of 10m, 1m, 0.1m for
>> autonomous/FLOAT/FIX, each times HDOP, and that so far does not seem
>> crazy, although one could argue that 10m is too high.
>
> HDOP is pretty useless.  And error circles are on the way out.

When getting mode and HDOP from NMEA, it's the best you can do, and it's
much more useful than knowing nothing.

> Newer u-blox report the error ellipse.  Much more informative than CEP.

What's the biggest eccentricity you've seen?  If that's 2, then it's
twice as useful, but if it's 1.2, only a little.

>> I believe you that some receivers give bad output.  That doesn't mean
>> the concept is invalid, jsut that some receivers are junky.
>
> Not invalid, just obsolete.

Not sure what you think it obsolete.  the
autonomous/differential/RTK-FLOAT/RTK-FIX is entirely valid today.

>> >> I think the analysis is computing an average over the hour, and
>> >> then the CEP is the distance such that half the points are closer
>> >> to the average.  But that's not really "error" because you don't
>> >> know the right answer.  
>> >
>> > I could go to a geodetic benchmrk, and repeat.  But even they are
>> > not accurate to 0.1mm.  
>> 
>> True, but at least there is something to compare to, likely sensible
>> at the 10 cm level for some.  Of course you'll need to be careful
>> about datum.  I suspect ORGN is in NAD83(2011) epoch 2010.0 just like
>> the datasheets you'll find for NGS marks.  At least that's how MaCORS
>> is.
>
> Red herring.  RTCM cares nothing of datums.  It just sends out the
> ephemeris, and range ertrors.

That's totally wrong.  Basic differential, like the USCG used to send,
involves a reference station with a known location (which is in some
datum), and that station looking at observed pseudoranges based on the
broadcast ephemeris and comparing them to the calculated pseudoranges.
The corrections consist of a pseudorange error and a time for which it
is valid, plus a pseudorange error rate.

>> And even if that file is not correct, it is useful to compare 10
>> future station occupations to a common basis, rather than only being
>> able to look at each one relative to its own mean.
>
> Which I do.  That is why I have a roof mounted fixed antenna.

yes but each plot is relative to its own mean.  I am trying to explain
that being able to center the plot on some known long-term average
instead will let you see bias in the plot.

>> You should care because how this is really working is a good thing to
>> understand in order to reason about error processes.
>
> I woud care, except the firmware is closed to us.  All we really
> know is the data from the device.  Anything not derived from the
> data is based on guesses.

Knowing that RTK FIX is better is not guessing.  It comes from
understanding how this really works.

>> obtained via different measurement modes.
>
> No, exact same mode and configuration.  Measured with different RTCM
> corrections to them.

Putting a different kind of correction/reference stream is a different
mode.  The receiver  behaves fundamentally differently between

  no corrections, SBAS, RTCM2.3

and

  RTCM3


>> I want to see a graph which
>> shows all 4 average locations, with each one having some circle,
>> perhaps 1 sigma, to understand if there are biases in the not-FIX
>> measurements.
>
> So just overlay the 4 pngs.

No, because each has its own origin which are different.

>> If the "mushroom" one you have is the typical $90ish from ebay, it's
>> probably a Beitian, perhaps like
>
> Nope.  TopGNSS.  But they may just buy from Beitan.  Hard to tell
> with cheap CHinese stuff.

That is probably the same.

>> I have one of them, and it seems to work pretty well.  The ardusimple
>> CAL one they must have had an OEM make, bu they sent it through the
>> NGS calibration process.
>
> Which only matters if that antenna cal data is in your PPP service.

Or with OPUS, or loaded into your RTK processing.

While it's technically invalid reasoning, I think it's also pretty
likely that an antenna that survived the cal process is not junky.

>> >> So it would be really interesting to see data from your
>> >> receiver/ant with the antenna fully outside in a repeatable
>> >> postion.  
>> >
>> > Givne the data cluster at 1cm, I would prolly not be able to see any
>> > improvement.  
>> 
>> True, but it would be interesting to see if you end up in FIX with a
>> mount point that is a single station instead of VRS.
>
> Since I use u-blox binary, I'll never know.

If you are in RTK FLOAT you will not see 1cm.

>> Including going to 1 Hz from 10 if you are
>> at 10, and reducing frequency of skyview messages, etc.
>
> I was already at 1Hz and 7 seconds per skyview.

Interesting.  I'll see if I find anything useful.

signature.asc
Description: PGP signature