Re: ✘NTRIP and RTCM

[Greg Troxel]

"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 RTCM2.3 you are feeding it is not bad, just L1/GPS only, I
think.

It seems reasonable of a receiver to use differential data that is
presented to it if that differential mode is configured on.

>> 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.  Do you mean "GLONASS is not available"
or "the ORGN RTCM2.3 feed does not have GLONASS data"?

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

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

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

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

>> 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.  And surely some receivers report odd things using
these codepoints.  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.  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.

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

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

>> I am suggesting, more concretely:
>> 
>>   have the analysis program output the computed average in geojson or
>>   something into a file, maybe optionally
>
> gpsprof does that.

ok, great.

>>   have an optional argument to read a "correct answer" from a file in
>>   that same format
>
> 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.

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.

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)
>
>> 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.  If you are trying
to make precise measuremnts of points you really want to know that you
are in FIX before you record.

>>  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,
obtained via different measurement modes.  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.

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

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

I will try mine out sometime and see if I can find anything useful in
terms of comparing it to the calibrated one.

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

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

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.

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

>> I have a particular deck railing nail I place the stand over.
>
> Ditto.  Now if any 2 GPS ever gave me the same position of that nail...

I have measured a few points repeatedly with F9P/RTK, at times separated
by about a month.  I get about a 2cm wander during 30-60s of each
measuremnt (and part of that is my ability to hold a prism pole vertical
watching the bubble level), and the centers of these 2 cm circles are
about 4 cm apart.    That is vastly better than anything pre-RTK.

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

I wonder if you can look at the all the enabled messages and turn down
the ones you do not need.  Including going to 1 Hz from 10 if you are at
10, and reducing frequency of skyview messages, etc.

I am also seeing some trouble, where the positions at Vespucci start to
run slow, but if I close the TCP connection to the ESP32 on my module
(which is just feeding serial over wifi) and restart it things are ok.
So I suspect the issue is on my phone, likely vespucci.

signature.asc
Description: PGP signature