[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ntrip and sending position

From: Greg Troxel
Subject: Re: ntrip and sending position
Date: Tue, 17 Dec 2019 16:21:30 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (berkeley-unix)

"Gary E. Miller" <address@hidden> writes:

> Yo Greg!
> On Tue, 17 Dec 2019 13:11:48 -0500
> Greg Troxel <address@hidden> wrote:
>> > That URL is just used verbatim.  So whatever your NTRIP server
>> > wants is what you put there.  
>> The parsing code uses strchr to look for '@', so I would expect a
>> username that's an email address to fail.  Probably that should be
>> strrchr.  (I have an account without an @, so I'm avoiding this.)
> No point "fixing" it until it is a problem.

It is a problem.  Anyone who has a username with an @ -- which is normal
these days to use an email address as a username -- will lose, and the
docs don't explain this.

>> This is extra confusing because the string is written during parsing
>> and then referred to in logs as "ntrip://user:pw" implying that
>> parsing failed, when really that' just what's left after the @ is set
>> to NUL. Maybe that's easy to fix and I'm looking at the code.
> Yeah, not showing the u/p needs to get fixed.  Not a release blocker.

Agreed not a release blocker - this is not new.

>> This is somebody trying to sell their stuff, but it seems to define
>> the terms that I am seeing on the MaCORS documentation, such as Max
>> and iMax.
> But not well enough to code from.  I see ORGN also does MAX, iMAX and
> CMR+, whatever they are...

MAX apparently sends multiple station info to the rover which is
supposed to interpolate, and iMax the server interpolates.  It may be
that iMax and "virtual reference station" are two words for the same

CMR is a proprietary version of RTK info, and apparently not used so
much these days.

>>   gpsd:PROG: RTCM3: unknown type 1230, length 12
> RTCM 1230: GLONASS L1 and L2 code-phase biases.
> u-blox does it.  Not sure how to decode it.  I'm not spending $275 for
> the doc...

Thanks; that's helpful.  I'm trying to do regular differential, not RTK.

>> For a stream identified as "RTCM 3.x (MSM4)" and apparently, I get.
>> gpsd:PROG: RTCM3: unknown type 1074, length 226
>  GPS Multi Signal Message 4
>> gpsd:PROG: RTCM3: unknown type 1084, length 133
>  GLONASS Multi Signal Message 4
>> gpsd:PROG: RTCM3: unknown type 1094, length 155
>  Galileo Multi Signal Message 4
>> gpsd:PROG: RTCM3: unknown type 1124, length 62
>  BeiDou Multi Signal Message 4
>> It may be that MaCORS is only sending RTK info and not pseudorange
>> corrections,
> Those are one and the same thing.

I don't think they are.  RTK is concerned with carrier phase and
pseudoranges are not carrier phase.  I am not sure that RTK users look
at pseudorange corrections at all.  But maybe that's part of
bootstrapping to fix the integer ambiguities.

>> I think the first thing (for me) to do is improve the error reporting
>> in this code.   I think I'm running into problems not encountered by
>> the authors :-)
> A good place to start.  I have been adding in the missing codes to 
> driver_rtcm3.c, as comments.

Thanks for the sanity check.

I am still unclear on if my corrections are being applied and helping
(vs SBAS corrections).   Definitely when I walk in the woods the
accuracy is not good enough with just SBAS for pleasing trail mapping.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]