Re: ✘NTRIP and RTCM

[Gary E. Miller]

Yo Greg!

On Mon, 06 Dec 2021 19:52:07 -0500
Greg Troxel <gdt@lexort.com> wrote:

> "Gary E. Miller" <gem@rellim.com> writes:
> 
> >> >> I am fuzzy but I gather that RTCM2.3 typically is pseudorange
> >> >> corrections, and GPS only.  It may be L1 only.    
> >> >
> >> > Yes, in this case, GPS and L1 only.    
> >> 
> >> So you lose 3 of 4 constellations, and you lose the abiltiy to
> >> estimate iono delay from L1/L2.   Interesting that it makes things
> >> worse, but I am not super surprised.  
> >
> > ONe would hope the firmware would recognize the degradation and
> > stop using the RTCM2.3.  Just like it stops using any satellite
> > that provides bad data.  
> 
> Well, it's an interesting question to decline to use differential
> because of some estimate that it might be worse.  It might be, it
> might not.

The receiver has no trouble computing many solutions, thenm deciding
to throw some satellites out of the fix to improve the results.

Same could apply to RTCM.  Compute once with, once without, and then
use the one with the smallest spherical error probablity (sep).


> The RTCM2.3 you are feeding it is not bad, just L1/GPS
> only, I think.

Actually, L1/L2, the M9P can use L2.

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

> >> So no L2C, no GLONASS even?  I suppose someone(tm) should get the
> >> SBAS stream and decode it.  
> >
> > Thera are so few L2C GPS satellites, not much use.  RTCM 2.3 does
> > support GLONASS, but not available to me nearby.  
> 
> I thought about half were L2C.

Sorry, you  said L2C, and I read L1C.

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

> or "the ORGN RTCM2.3 feed does not have GLONASS data"?

Some ORGN has GLONASS, but not the ones near me.

> >> I've been using high-precision NMEA, because my real goal is to log
> >> data in Vespucci for mapping/surveying, and I think I'm seeing well
> >> sub cm quantization.  
> >
> > What is "high-precision NMEA"?  NMEA does not specify any
> > resolutions.  
> 
> 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 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.

> > u-blox HP mode gets to 0.1 mm.  UBX-NAV-PVT (default) is 1 mm.
> >
> > I'll recheck gpsd JSON path to confirm it can hadle 0.1mm.  
> 
> Thanks.  The plot I saw sort of looked like the resolution was maybe
> 8mm.

Which would be 1e-7 longitude at about 44 latitude.  So that
would fit.

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.

> >> Great, so you should be able to associate with each position what
> >> kind of fix it is.  
> >
> > 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?

> >> Do you mean there are no messages that say if the solution is from
> >> RTK FLOAT, RTK FIX, just nav satellites, differential etc  
> >
> > Correct.  
> 
> 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?

> >> like you get in
> >> the mode field of the main NMEA message?  
> >
> > Uh, no.  The NMEA mode field can also report RTK fix, RTK Float, and
> > other variants.  Badly defined and inconsistently implemented.  
> 
> I don't find the concept for autonomous, differential, RTK FIX, RTK
> FLOAT to be unclear.

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

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?

> And surely some receivers report odd things
> using these codepoints.

Every receiver reports odd things.

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

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

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

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

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

> > If I could get a "correct answer", but I have none.  So not useful.
> >  And the math to add a constant error is trivial, if I knew what
> > that was.  
> 
> It is useful.  If you have an average from an RTK FIX session, then
> that is very likely far closer to right than anything else.

I'd rather depend on sep.

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

> FWIW, I have measured a white 15x15cm fencepost top with RTK and
> compared to a position obtained from MassGIS 15cm orthohhotos, claimed
> to have 0.1m RMS error (all in NAD83(2011) epoch 2010.0) and the two
> positions agree at the 15 cm level (one pixel)

Seema about right. 

> >> What you would do is use the output from the MAX which appears to
> >> be RTK FIX, to process the rest.  
> >
> > It is the only output I have, so I dont care what it appears to be.
> >  
> 
> 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.

> If you are
> trying to make precise measuremnts of points you really want to know
> that you are in FIX before you record.

All I care about is stable sep.  That has high granulaarity.  Fix/Float
is just binary.  And undocumented.

> >>  That would show you biases among them,
> >> even if you aren't still really sure whihc is right.  
> >
> > Lost me again.  What "them".  
> 
> You posted 4 plots, all presuambly of the same physical location,

Yes.

> obtained via different measurement modes.

No, exact same mode and configuration.  Measured with different RTCM
corrections to them.

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

> By using the RTK average as the reference position for processing the
> other 3, you would sort of accomplish this goal.

I did that, but since the plots are only 1 hour long, and the wander
is on the order of hours, the data was not interesting.  I need to
take some 12 hour plots.

> >> Do you mean the slightly larger mouse-style magmount one that is
> >> about $60?  I have one and need to try it.  
> >
> > They onlye sell one:
> >
> > https://www.u-blox.com/en/product/ann-mb1-antenna
> >
> > I find it works well.  
> 
> except you are not in FIX with a 1-mile reference.  But you are also
> indoors.

Don't care.  All I care is jhow well I can measure what is right in
front of me.  And the relative goodness, and that is very clear from my
data.

It does not matter I can get a real precise measurement, when I'm   not
measureing something I want to measure.

> >> I would love to see data with something like the survey or
> >> calibrated from this line.  I am guessing you have the MB.
> >>   https://www.ardusimple.com/simpleant2b/  
> >
> > Unclear what models they are selling.  I have one of the mushrooms.
> >  It has a 40db LNA, so good for feeding a power splitter.  I have
> > not tried it with the F9P.  
> 
> 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.

> https://sq.cicig.co/product/1005003506926839/beitian-high-precision-rtk-gnss-antenna-zed-f9p-gps-antenna-high-gain-cors-antenna-tnc-gps-glo-gal-bds-gnss-l1-l2-bt-800d

That one does not do L5.  Mine does.

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

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

> > I am running into one big problem.  When I use the iMAX data, the
> > F9P CPU gets overloaded.  It stopps sending all but the most basic
> > messages, the txbuf is at 99 to 100% full:
> >
> > UBX-MON-TXBUF:
> >  pending   0 12031 0 0 0 0
> >  usage     0 99 0 0 0 0
> >  peakUsage 0 99 0 11 0 0
> >  tUsage 99 tPeakUsage 100 errors xc0 reserved1 0
> >   errors (mem alloc) limit (0)
> >
> > and constantly sending error messages:
> >
> > $GNTXT,01,01,00,txbuf alloc*61
> >
> > So the extra precision comes at great cost to other available data.
> >  
> 
> You say CPU, but wouldn't that lead to just getting slow and not
> filling up the tx buffer?

The tx rate is not enough to fill the channel, and the tx data reduced
by a lot, what else could it be?

> I wonder if you can look at the all the enabled messages and turn down
> the ones you do not need. 

No need, they all turned off on their own when the tx buffer filled.

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

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpUvDMSFjffW.pgp
Description: OpenPGP digital signature