Re: ntrip and sending position

[Greg Troxel]

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

>> and I wonder what happens if one's username foo is an email address.
>
> 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.)

Basically;

  ntrip://address@hidden:address@hidden:1234/

needs to be parsed by picking the right-hand @, and then of the
user:pass it seems that they just have to not have :.

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.

>> The man page doesn't address sending position.  The Emlid Reach RTK
>> has options to 1) not send 2) send a static lat/lon and 3) send the
>> current position solution.
>
> For ORGN, that just goes in the URL.  So ask MaCORS what to use as your URL.

They have mountpoints for specific stations.  But there is a way to send
either GGA sentences or their logical content to get synthetic
corrections specifically for that place, as you move, on different
mountpoints.  That can't be in the URL. (Obviously someone needs to
figure out the scheme and write code; RTKLIB seems to do this.)

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.

https://www.agleader.com/blog/ntrip-cors-how-it-works-and-what-is-involved/

I am unclear on whether positions for Near are sent in the URL or via
the mechanism used for iMax.

>> 3) I wonder how to monitor the ntrip stream.
>
> gpspipe.  The NTRIP will show up as another "DEVICE".

Thanks.   I have managed to get it to show up, after capturing the
traffic and getting the sourcetable (list of mountpoints).

For a stream identified as "RTCM 2.x (extended)" and apparently 2.3, I get:

  gpsd:PROG: RTCM3: unknown type 1230, length 12
    and also
  gpsd:PROG: Changed mask: {ONLINE|RTCM2|PACKET} with reliable cycle detection

For a stream idenitfied as "RTM 3.x (extended)" and apparently 3.1, I get:

  gpsd:PROG: RTCM3: unknown type 1230, length 12
    and also
  gpsd:PROG: Changed mask: {ONLINE|RTCM3|PACKET} with reliable cycle detection

For a stream identified as "RTCM 3.x (MSM4)" and apparently, I get.

gpsd:PROG: RTCM3: unknown type 1074, length 226
gpsd:PROG: RTCM3: unknown type 1084, length 133
gpsd:PROG: RTCM3: unknown type 1094, length 155
gpsd:PROG: RTCM3: unknown type 1124, length 62


It may be that MaCORS is only sending RTK info and not pseudorange
corrections, and there is no overlap in what gpsd can parse and what
MaCORS is emitting.

> Here is what mine looks like, note the 2nd device:
>
> # gpspipe -w pi8
> {"class":"VERSION","release":"3.19.1~dev","rev":"release-3.19-945-gbf503e48e","proto_major":3,"proto_minor":14}
> {"class":"DEVICES","devices":[{"class":"DEVICE","path":"/dev/ttyAMA0","driver":"u-blox","subtype":"SW
> EXT CORE 3.01 (111141),HW 00080000","subtype1":",ROM BASE 2.01
> (75331),FWVER=TIM 1.10,PROTVER=22.00,MOD=NEO-M8T-0,FIS=0xEF4015
> (100111),GPS;GLO;GAL;BDS,SBAS;IMES;QZSS","activated":"2019-12-16T21:24:56.598Z","flags":1,"native":1,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00,"mincycle":0.25},{"class":"DEVICE","path":"ntrip://rellim:rellim","driver":"RTCM104V2","activated":"2019-12-16T21:24:56.447Z","flags":3}]}

Thanks, I am seeing similar now.  Is that from the state of Oregon service?

>> I am sure it has carrier
>> phase, as people talk about RTK with it.  I think it also has
>> pseudorange corrections.
>
> # gpspipe -w pi8
> [...]
> {"class":"RTCM2","device":"ntrip://rellim:rellim","type":1,"station_id":205,"zcount":1515.0,"seqnum":7,"length":14,"station_health":0,"satellites":[{"ident":26,"udre":0,"iod":71,"prc":-4.160,"rrc":0.000},{"ident":3,"udre":0,"iod":16,"prc":-2.000,"rrc":0.000},{"ident":9,"udre":0,"iod":47,"prc":-2.400,"rrc":0.000},{"ident":16,"udre":0,"iod":58,"prc":-4.860,"rrc":0.002},{"ident":23,"udre":0,"iod":75,"prc":-0.900,"rrc":0.000},{"ident":6,"udre":0,"iod":19,"prc":-5.080,"rrc":-0.002},{"ident":22,"udre":0,"iod":4,"prc":-3.620,"rrc":0.002},{"ident":31,"udre":0,"iod":59,"prc":-6.180,"rrc":-0.002}]}
> {"class":"RTCM2","device":"ntrip://rellim:rellim","type":18,"station_id":205,"zcount":1515.0,"seqnum":0,"length":17,"station_health":0,"data":["0x40000016","0xa6930c6c","0x0ab7b2a9","0x60d244b2","0xa87b5c8f","0xe25180c3","0xf9335b61","0x64178935","0x5fbb9443","0xe5d119e2","0x8441b94c","0x219240e1","0x790a9b72","0xa5938b5a","0x864e4cee","0xa7d20471","0x633e3236"]}
> [...]
>
> The type 1 is the corrections.  The type 18 is not decoded.

Thanks - that's really helpful to know what to expect.   

>> While I realize the primary path should be
>> the MaCORS docs, it seems the gpsd way would have some sort of
>> monitor.
>
> For now, just gpspipe, which can give you the raw and/or JSON of the data.
>
> Patches welcome!  If you figure it out, a howto would be nice.

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