Problem Streaming NTRIP Data From Missouri MoDOT Real-Time Network

[angelalalalalas]

My Problem: RTKLIB unable to stream NTRIP client base station data from the Missouri Department of Transportation(MoDOT)'s Realt-Time Network when it has no problem with rtk2go.com or unavco.org. I have to use MoDOT's network because they have the closest base station, and I really do not want to have build my own base station when I should have access to that. The other 2 NTRIP casters I listed puts my GPS in RTK float mode (LED blinking) but failed solve the carrier ambiguities to enter RTK fixed mode (LED off). I have verified that it is not a firewall problem, and MoDOT has confirmed that their data stream is working. Please anyone who has worked with MoDOT or had similar problems help!

My Setup: I'm in Missouri using a Raspberry Pi 4 with a wireless connection (and Windows 10 PC for testing) to stream base station data and log it to my SparkFun GPS-RTK-SMA Breakout - Ublox ZED-F9P board. I'm following this tutorial for the RTKLIB part: https://learn.sparkfun.com/tutorials/gps-rtk-hookup-guide/all#connecting-the-gps-rtk-to-a-correction-source On the RPi, I use both str2str to visualize the NTRIP client's dataflow and rtkrcv with a .conf to do the actual logging.

My Tests:

1. Test with MoDOT NTRIP client:

mount point: VRS_RTCM31; format: RTCM3.1; format details: 1004(1),1005/1007(5),PBS(10); Nav System: GPS+GLO; generator: trimble pivot platform

PI: str2str -in ntrip://[username]:[password]@rtk3.modot.mo.gov:2101/VRS_RTCM31#rtcm3 -out serial://ttyACM0:9600:8:n:1#rtcm3 stream server start 2021/02/23 21:24:21 [WC---] 0 B 0 bps (0) connecting... (1) /dev/ttyACM0 2021/02/23 21:24:26 [CC---] 2 B 0 bps (0) rtk3.modot.mo.gov/VRS_RTCM31 (1) /dev/ttyACM0 2021/02/23 21:24:31 [CC---] 2 B 0 bps (0) rtk3.modot.mo.gov/VRS_RTCM31 (1) /dev/ttyACM0 2021/02/23 21:24:36 [WC---] 2 B 0 bps (0) timeout (1) /dev/ttyACM0 2021/02/23 21:24:41 [WC---] 2 B 0 bps (0) timeout (1) /dev/ttyACM0 2021/02/23 21:24:46 [CC---] 4 B 0 bps (0) rtk3.modot.mo.gov/VRS_RTCM31 (1) /dev/ttyACM0 2021/02/23 21:24:51 [CC---] 4 B 0 bps (0) rtk3.modot.mo.gov/VRS_RTCM31 (1) /dev/ttyACM0 2021/02/23 21:24:56 [WC---] 4 B 0 bps (0) timeout (1) /dev/ttyACM0 2021/02/23 21:25:01 [WC---] 4 B 0 bps (0) timeout (1) /dev/ttyACM0 2021/02/23 21:25:06 [CC---] 6 B 0 bps (0) rtk3.modot.mo.gov/VRS_RTCM31 (1) /dev/ttyACM0 2021/02/23 21:25:11 [CC---] 6 B 0 bps (0) rtk3.modot.mo.gov/VRS_RTCM31 (1) /dev/ttyACM0

MoDOT uses a Trimble network. Instead of selecting a mount point that is a specific base station, I was instructed to pick from one of 6 virtual reference stations (VRS) that output different formats, such as CMR+, CMRx, RTCM2.1, RTCM2.3, RTCM3.1, and RTCM3Net. I chose RTCM3.1, which is what I had set for the other tests. I emailed their support, but they told me the problem is somewhere in my settings and their caster is operating normally.

2. Test with UNAVCO NTRIP client:

mount point: KSU1_RTCM3; format: RTCM3.1; format details: 1004(1),1005(60),1007(60),1012(1),1033(60); Nav System: GPS; generator: TRIMBLE NETRS mount point: KBRC_RTCM3; format: RTCM3.1; format details: 1004(1),1005(60),1007(60),1012(1),1033(60); Nav System: GPS+GLO; generator: TRIMBLE NETR9

PI: str2str -in ntrip://[username]:[password]@rtgpsout.unavco.org:2101/KSU1_RTCM3#rtcm3 -out serial://ttyACM0:9600:8:n:1#rtcm3 stream server start 2021/02/23 21:26:12 [WC---] 0 B 0 bps (0) connecting... (1) /dev/ttyACM0 2021/02/23 21:26:17 [CC---] 832 B 1488 bps (0) rtgpsout.unavco.org/KSU1_RTCM3 (1) /dev/ttyACM0 2021/02/23 21:26:22 [CC---] 1762 B 1481 bps (0) rtgpsout.unavco.org/KSU1_RTCM3 (1) /dev/ttyACM0 2021/02/23 21:26:27 [CC---] 2692 B 1483 bps (0) rtgpsout.unavco.org/KSU1_RTCM3 (1) /dev/ttyACM0

In this test, I have tried using the rtkrcv CUI app with the same information, the only difference is instead of output to my GPS, it logs to it. My GPS enters RTK float mode, the RTK green LED blinks on the board but never fixes. I think it is because the Kansas Base station is too far from me.

3. Test with rtk2go.com NTRIP client:

mount point: Edelstein_IL_F9P; format: RTCM3.2; format details: 1005(1),1074(1),1084(1),1094(1),1230(1); Nav System: GPS+GLO; generator: sNTRIP mount point: PoleBarn9669; format: RTCM3.2; format details: 1005(1),1074(1),1077(1),1084(1),1087(1),1094(1),1097(1),1124(1); Nav System: GPS+GLO; generator: sNTRIP mount point: vanb_rtcm; format: RTCM3.0; format details: 1004(1),1006(10),1008(10),1013(10),1033(10); Nav System: GPS; generator: sNTRIP

I tried rtk2go.com as sort of a last resort just to see if I can get an RTK fix somehow. I had the same exact setup, just streaming data. I tried 3 base stations near me. All of them put my GPS device in RTK float mode as UNAVCO did, but was not able to give me a fix.

[DavidKelleySCSC]

Nowhere do I see that you are sending a NMEA $GGA sentence to the Caster in any of this. That is a big problem for the MoDot Caster as it expects that detail in order to know what to send back. [It is network RTK solution, which Trimble calls VRS] Without it it will disconnect you. For the UNAVCO Caster one, it is a collection of single baseline stations (not $GGA needed) You do not say your gross location or how far the baseline is. Over 50k for L1+L2 is stretching things, over 10k if an L1 only device. I do not recall anything near Mo there. The RTKgo.com SNIP Caster has both single baseline mountPts and its NEAR (network RTK) mountPts, the later resolve to single stations but also require you to send in a $GGA sentence. The three stations you mention are all in central Illinois (plot them with this tool: http://monitor.use-snip.com/?hostUrl=rtk2go.com&port=2101) and frankly that is a long way away from the Eastern edge of Mo. So to sum up; for some of these you need to be sending a NMEA $GGA sentence,m for others you are perhaps too far away.

[angelalalalalas]

Thank you @DavidKelleySCSC for your comment.

I was able to pull the data stream from MoDOT's VRS NTRIP client and enter RTK float mode as I did with the other NTRIP clients, but the GPS is still unable to get a fix. I'm very close to the Lambert Airport in St. Louis, and I have confirmed that there are base stations close to me, the closest being MOBF (10km away). So I really should be getting something.

The Rover GPS hardware I'm using: Sparkfun GPS-RTK-SMA breakout board https://www.sparkfun.com/products/16481 The antenna I'm using: GNSS Multi-Band Magnetic Mount Antenna - 5m (SMA) https://www.sparkfun.com/products/15192

I have been testing on my windows machine using the RTKNAVI GUI: I set my input as NTRIP client, and I'm transmitting NMEA GGA to the base station. I'm using a stationary reading I obtained through U-center, but I'm not sure if that is the right thing to do since it is a moving rover. I have tried to click select single instead of lat/lon as recommended in #536, but it timed out. One thing to note is that the GPST time remains at 2000/01/01 if that changes anything. When I launch RTKSVR just to see if there is some weird problem with the date and time, it displays the current time. My outputs are currently not configured, and my logs page looks like this: My option for output looks like this:

The same configurations are tested on RTKCRV with RPi, same results.

What do you recommend that I do to solve this? Or if you have any other suggestions to obtain centimeter accuracy with the GPS hardware I have and the MoDOT VRS system?

Thank you so much.

[DavidKelleySCSC]

I will take a greater look at your settings in <24 hours (am stuck in my own testing today) but I assure you that the MoDat data is fine (I have been running it in Florissant and Hazelwood for years and still remotely from LA, no problems to report except for my dislike of having VRS block the real station) Quickly though; you seem to have the rover set off (hence no time evolution and no obs data, check that box). Turn on the logs (use level 3) and let's see what RTKLIB has to say, it provides a very good set of debug notes (your last image, under the Options -> Output ->Output solution, 2nd combo, set to Level 3).

[angelalalalalas]

Thank you again @DavidKelleySCSC. I had no doubt that MoDOT's system is working perfectly, and I was really just frustrated with the situation in general. I'm very grateful that you have offered your help, and I wish you good luck with your own testing. I will put together a beginner's guide to using MoDOT's RTK network with RTKLIB from my own experience, once I get everything figured out here, and I will definitely give you credit for helping me along the way. I'm running more tests here, and I will post the lasted updates. So far, I got a fix in U-center. But I have not been able to recreate it with RTKLIB or U-center.

debug trace output:

3 0.000: strsetdir: dir= 3 0.000: strsetproxy: addr= 3 rtkopenstat: file=rtknavi_%Y%m%d%h%M.stat level=2 3 0.001: strsetopt: opt=10000 10000 1000 32768 30 0 0 0 3 0.001: rtksvrstart: cycle=10 buffsize=32768 navsel=0 nmeacycle=5000 nmeareq=1 3 0.001: strinitcom: 3 rtkfree : 3 rtkinit : 3 init_raw: format=4 3 init_rtcm: 3 init_raw: format=1 3 init_rtcm: 3 init_raw: format=0 3 init_rtcm: 3 0.002: stropen: type=0 mode=3 path= 3 0.002: stropen: type=6 mode=3 path=user:pswd@168.166.125.30:2101/VRS_RTCM31:;;;0;;;;;;0;0;;;N;N; 3 0.002: openntrip: path=user:pswd@168.166.125.30:2101/VRS_RTCM31:;;;0;;;;;;0;0;;;N;N; type=1 3 0.002: opentcpcli: path=168.166.125.30:2101 3 0.003: stropen: type=0 mode=3 path= 3 0.003: stropen: type=0 mode=2 path= 3 0.003: stropen: type=0 mode=2 path= 3 0.003: stropen: type=0 mode=2 path= 3 0.003: stropen: type=1 mode=2 path=COM6:9600:8:n:1:off 3 0.003: openserial: path=COM6:9600:8:n:1:off mode=2 3 0.005: openserial: dev=1232 3 0.005: stropen: type=0 mode=2 path= 3 outsolheads: 3 outsolheads: 3 0.005: serialthread: 3 0.006: rtksvrthread: 3 0.006: reqntrip_c: state=0 3 0.006: writetcpcli: sock=0 state=0 n=103 3 0.006: gentcp: type=1 3 0.006: setsock: sock=1008 3 outsols : 3 outsolexs: 3 outnmea_gsa: 3 outnmea_gsv: 3 outsols : 3 outsolexs: 3 outsols : 3 0.018: reqntrip_c: state=0 3 0.018: writetcpcli: sock=1008 state=1 n=103 3 0.034: reqntrip_c: state=0 3 0.034: writetcpcli: sock=1008 state=1 n=103 3 0.048: reqntrip_c: state=0 3 0.048: writetcpcli: sock=1008 state=1 n=103 3 0.048: consock: connected sock=1008 addr=168.166.125.30 3 0.048: reqntrip_c: send request state=0 ns=103 3 0.048: waitntrip: state=1 nb=0 3 0.126: rspntrip_c: state=1 nb=14 3 0.126: rspntrip_c: response ok nb=2 3 0.126: writeserial: dev=1232 n=2 3 outsols : 3 outsolexs: 3 outnmea_gsa: 3 outnmea_gsv: 3 outsols : 3 outsolexs: 3 outsols : 3 outsols : 3 outsolexs: 3 outnmea_gsa: 3 outnmea_gsv: 3 outsols : 3 outsolexs: 3 outsols : 3 outsols : 3 outsolexs: 3 outnmea_gsa: 3 outnmea_gsv: 3 outsols : 3 outsolexs: 3 outsols : 3 4.018: strsendnmea: rr=-21324.748 -4979867.872 3971907.289 3 outnmea_gga: 3 4.018: writentrip: n=90 3 4.018: writetcpcli: sock=1008 state=2 n=90 3 outsols : 3 outsolexs: 3 outnmea_gsa: 3 outnmea_gsv: 3 outsols : 3 outsolexs: 3 outsols : 3 4.949: writeserial: dev=1232 n=31 3 decode_rtcm3: len= 28 type=1007 3 5.042: writeserial: dev=1232 n=531 3 decode_rtcm3: len= 75 type=1033 3 rtcm3 1033: ant=ADVNULLANTENNA NONE: rec=TRIMBLE NETR9:Nav 5.48 / Boot 5.48:5608R50212 3 decode_rtcm3: len= 22 type=1005 3 decode_rtcm3: len= 13 type=4094 3 decode_rtcm3: len= 26 type=4094 3 decode_rtcm3: len= 23 type=1032 2 rtcm3 1032: not supported message 3 decode_rtcm3: len= 14 type=4094 3 decode_rtcm3: len=168 type=1004 3 decode_rtcm3: len= 60 type=1012 3 sortobs: nobs=13 3 decode_rtcm3: len= 72 type=1030 2 rtcm3 1030: not supported message 3 decode_rtcm3: len= 28 type=1031 2 rtcm3 1031: not supported message 3 pntpos : tobs=2021/02/25 22:27:27.000 n=13 3 satposs : teph=2021/02/25 22:27:27.000 n=13 ephopt=0 3 no broadcast ephemeris: 2021/02/25 22:27:27 sat= 1 iode= -1 3 no broadcast clock 2021/02/25 22:27:26.930 sat= 1 3 no broadcast ephemeris: 2021/02/25 22:27:27 sat= 7 iode= -1 3 no broadcast clock 2021/02/25 22:27:26.923 sat= 7 3 no broadcast ephemeris: 2021/02/25 22:27:27 sat=13 iode= -1 3 no broadcast clock 2021/02/25 22:27:26.921 sat=13 3 no broadcast ephemeris: 2021/02/25 22:27:27 sat=14 iode= -1 3 no broadcast clock 2021/02/25 22:27:26.932 sat=14 3 no broadcast ephemeris: 2021/02/25 22:27:27 sat=17 iode= -1 3 no broadcast clock 2021/02/25 22:27:26.930 sat=17 3 no broadcast ephemeris: 2021/02/25 22:27:27 sat=19 iode= -1 3 no broadcast clock 2021/02/25 22:27:26.926 sat=19 3 no broadcast ephemeris: 2021/02/25 22:27:27 sat=21 iode= -1 3 no broadcast clock 2021/02/25 22:27:26.921 sat=21 3 no broadcast ephemeris: 2021/02/25 22:27:27 sat=22 iode= -1 3 no broadcast clock 2021/02/25 22:27:26.917 sat=22 3 no broadcast ephemeris: 2021/02/25 22:27:27 sat=28 iode= -1 3 no broadcast clock 2021/02/25 22:27:26.931 sat=28 3 no broadcast ephemeris: 2021/02/25 22:27:27 sat=30 iode= -1 3 no broadcast clock 2021/02/25 22:27:26.929 sat=30 3 no glonass ephemeris : 2021/02/25 22:27:27 sat=41 iode=-1 3 no broadcast clock 2021/02/25 22:27:26.933 sat=41 3 no glonass ephemeris : 2021/02/25 22:27:27 sat=51 iode=-1 3 no broadcast clock 2021/02/25 22:27:26.927 sat=51 3 no glonass ephemeris : 2021/02/25 22:27:27 sat=53 iode=-1 3 no broadcast clock 2021/02/25 22:27:26.926 sat=53 3 estpos : n=13 3 resprng : n=13 3 outsols : 3 outsolexs: 3 outnmea_gsa: 3 outnmea_gsv: 3 outsols : 3 outsolexs: 3 outsols : 3 5.942: writeserial: dev=1232 n=171 3 decode_rtcm3: len=168 type=1004 3 6.035: writeserial: dev=1232 n=169 3 decode_rtcm3: len= 60 type=1012 3 sortobs: nobs=13 3 decode_rtcm3: len= 72 type=1030 2 rtcm3 1030: not supported message 3 decode_rtcm3: len= 28 type=1031 2 rtcm3 1031: not supported message 3 pntpos : tobs=2021/02/25 22:27:28.000 n=13 3 satposs : teph=2021/02/25 22:27:28.000 n=13 ephopt=0 3 no broadcast ephemeris: 2021/02/25 22:27:28 sat= 1 iode= -1 3 no broadcast clock 2021/02/25 22:27:27.930 sat= 1 3 no broadcast ephemeris: 2021/02/25 22:27:28 sat= 7 iode= -1 3 no broadcast clock 2021/02/25 22:27:27.923 sat= 7 3 no broadcast ephemeris: 2021/02/25 22:27:28 sat=13 iode= -1 3 no broadcast clock 2021/02/25 22:27:27.921 sat=13

And it has more repeats of the "no broadcast" stuff. I suspect that it is not getting a strong enough signal. Although U-center seems to work fine. I'm testing with different ground planes to see if that improves it. Thank you.

[DavidKelleySCSC]

Okay that is easy to fix.
The key insight is that you have no orbital data ("no broadcast ephemeris: 2021/02/25 22:27:28 sat= x etc.") which means the navigation filter does not have current data to locate the moving SVs from.

Use the 3rd input line on RTKLIB to get a copy of the broadcast orbits. There are many places you can download this from and it is most commonly called RTCM3EPH - it provides current orbital data for all SVs for all GNSS systems (and therefore it is a bit big). Your rover device in the field gets this data directly from the SVs it is tracking (this is the 50bps data signal on top of the code and carrier). But that is not sent on when you get the obs messages in RTKLIB or any other separate RTK filter (it could be but it is not customary to do so).

Here are two places you can freely get it off our server machines:
http://ntrip.use-snip.com:2101/ and/or
http://Rtk2Go.com:2101/
Connect to the stream called RTCM3EPH (you do to need a user name or a password, just enter your name if you wish).

[angelalalalalas]

Thank you @DavidKelleySCSC so much. I have tested using your recommendation and my GPS is able to enter the RTK fix mode.

My RTKNAVI configurations: input, base station: NTRIP Client -- Missouri MoDOT input, correction: NTRIP Client -- ntrip.use-snip.com:2101 log, base station: serial -- Sparkfun GPS-RTK-SMA

Other adjustments I have done since first opened the issue:

1. added a big ground plane, steel ~1sqft
2. Moved the antenna from indoor (tilted toward a large glass window with nothing blocking the view), to outdoor in the open and outdoor partially under a roof. When it was indoor, it was able to connect, but not very consistent and took longer. When it was outside, it connected more consistently and faster.

Comment: I tried both rtk2go.com and ntrip.use-snip.com's RTCM3EPH stream. I found that rtk2go's stream disconnects after 30 seconds or so (RTKNAVI led turns orange) and my GPS has not fixed yet. So I would recommend using the snip one directly since I never had any problems connecting to it.

[kpsgf7]

@angelalalalalas @DavidKelleySCSC Sorry to ping you on an old issue, but I wondered if you all would have some insight into getting the correction stream from MoDOT stations. I can get the source table, but I always get an HTTP/1.0 401 Unauthorized error when I try to connect to a mountpoint. I suspect this is an issue related to sending the GGA string as you mentioned above. The MoDOT support says everything is good with my login information on their end since my login info works for the the information page ( https://gpsweb3.modot.mo.gov/ ).

What should the HTTP request look like to establish the connection? I am sending a GGA string but after looking at wireshark it looks like it only gets sent after MoDOT disconnects me.

Thanks for your help.

[angelalalalalas]

@kpsgf7 I have a silly question, is it possible that you input the url or credential wrong in your config file? It's been a while and I dug through my old college files, here are the relevant lines my .conf file:

inpstr2-path       =[username]:[password]@rtk3.modot.mo.gov:2101/VRS_RTCM31 
inpstr3-path       =:@ntrip.use-snip.com:2101/RTCM3EPH

Then for the GGA string, I input my lat lon location in the same .conf file

inpstr2-nmeareq    =latlon     # (0:off,1:latlon,2:single)
inpstr2-nmealat    = [enter your lat]  # (deg)
inpstr2-nmealon    =[enter your lon] # (deg)

If we can rule that out, it may be a firewall issue that there is some sort of IP restriction?

[DavidKelleySCSC]

Offhand if you are getting a 401 reply when using a user account that Caster operator says is good, you are likely sending in a bad NMEA $GGA sentence (so the caster can not connect you to a suitable base). The odd part (IMO) is that a 401 reply implies an NTRIP Rev2/Version2 protocol is in use, but RTKLIB is only able to do Rev1style connections at this time.

Make sure your $GGA is both a valid one and that the location you have entered is close enough to one the MoDOT physical bases that you will be connected to it (not sure what they set as the baseline limit to be, but try <40km). As a debug test, manually set your Lat-Long to be the same (or nearly the same) as what the Base station states. If this fails to result in a connection, call the MoDot staff back and tell them way you have done so they can check.

And as always, capitalization matters for base station names and user accounts, double check that.