What to check when choosing an NTRIP service for Reach RX?

Support tips
1

We call Reach RX a network RTK rover, which means it receives corrections from a base via NTRIP. It can be either your own base connected to Emlid NTRIP Caster or an NTRIP service.

In the previous post, we described the workflow with your own base. This time, we’ll discuss how to choose an NTRIP service which suits you best. Below, we’ve listed some things you need to pay attention to when considering using NTRIP. Often, this info can be found on NTRIP service website, but sometimes you need to reach out to a service support directly.

Data format

Reach devices, including Reach RX, work with corrections in RTCM3 format only. This is the standard format in the industry, and most providers support it. But still, it’s better to check it additionally.

Required data

To calculate a solution, Reach RX requires at least:

  • The base’s antenna reference point coordinates with antenna height. It’s provided in 1006 RTCM3 message.
  • GPS observables. There are several RTCM3 messages containing this info. One of the most popular is 1074 GPS MSM4.

Of course, Reach RX also reads GLONASS, Galileo, and Beidou data. But the ones listed above are a minimal subset.

Baseline

Reach RX is a multi-band device. So, the maximum distance between base and rover in RTK is 60 km (37.2823 miles). Check the map of reference stations and make sure there is one within this range.

Coordinate system and vertical datum

Emlid Flow (formerly known as ReachView 3) supports plenty of coordinate systems and vertical datums. Each of them requires a base to be in a specific datum as well.

When completing coordinate system and vertical datum setup, check a small tip: “Make sure your base or NTRIP is in …”. For example:

Project
Project825×1688 106 KB

So, just follow this tip!

That’s all! By the way, you can use the same suggestions if you work with Reach RS2+.

As always, don’t hesitate to ask additional questions in the comments!

14 Likes
2

Hi. Firstly; apologies in advance for being uneducated in this field of expertise. We’re new to the GNSS world here I’m afraid and struggling to understand what workflow to follow in order to obtain correct UK co-ordinates. We currently conduct small scale topographical surveys to local grid and wish to observe control points to UK OS grid, and then re-run topo data to shift survey to OS grid.

We’ve recently purchased an RS2+ and would like to use it as a rover with NTRIP corrections to achieve cm accuracy if possible. We’ve setup a project in Emlid Flow with coordinate system set to OSGM 1936 / British National Grid + ODN height (uk_os_OSGM15_GB).

as a test; we’ve obtained survey data from 2 other local surveyors in Shrewsbury for control points they have near us, and setup the RS2+ to observe for approx. 20minutes at each point with NTRIP corrections received from RTK2GO.com via a mount point in Bicton which is approx 8km away…and we’re getting errors in the region of +/- 500-700mm E&N and about +/- 40mm Z.

I get the locations of control points may reduce the accuracy achievable but wouldn’t expect errors to be that extreme. The fact we’re getting the same sort of differences to both sets of data tells me we’re doing something not quite right our end.

Any help or guidance would be greatly appreciated.

Cheers

3

You could try using a different mount point (aka a different NTRIP Caster) - the limited experience I’ve had with RTK2Go in the UK is that the sources vary greatly in accuracy. The one nearest to me (which is at a University) gives reasonably decent XY positions, but it’s Z throws my readings out by several metres. Another RTK2Go source much further away gives better Z readings, but sometimes readings drops into FLOAT instead of FIX when using that one. Yet another mount point only seems to give FLOAT.

From the sudden recent surge in new UK sources on RTK2Go, I’d say a lot of the NTRIP casters are famers bypassing the expensive RTK providers and putting up their own bases, from what I understand they only require local relative accuracy, not absolute accuracy, for the autosteer systems in their machinery. I’d guess they’re not always as careful at obtaining accurate fixes or setting antenna heights and offsets.

Unfortunately the state of the RTK NTRIP source market in the UK doesn’t appear to be very innovative or competitive for smaller users.

As to your original data and benchmarking it, you might get better results by just using the RS2+ standalone, (without any external corrections), taking Average Single readings for each point and using the nearest OSGB Base Station RINEX files to correct them in Emlid Studio.

5

Hi Nick and thanks for your help, very much appreciated!

I hadn’t thought that the base maybe inaccurate and therefore the corrections not entirely true. And I think the next nearest mount point is too far away.

Will try the rinex option but will need guidance on how that workflow operates…is this something you could assist with to get us started?

Thanks

Daz

6

Hi Daz,

It’s something I’m still trying to work out how to use, but I’ll do my best and I’m sure others will correct me if I get something wrong!

If you want to start afresh and take new readings:

  1. Set up the RS2+ on the location over the point to be measured.
  2. Start up the RS2+. Make a note of the time you start up (in GMT not BST :slight_smile: )
  3. Set the RS2+ to record it’s own log files, and make sure it’s recording. RS2+ Record & Download Logs
  4. Set the RS2+ for Average Single recording. Average Single Base Position
  5. Use Emlid Flow to record the position of the RS2+. Record the point as an Average Single and average for a minute or so.
  6. Move to your next location and take another reading as per #5.
  7. Once you’ve finished recording the positions, then leave the RS2+ set up over the last point for a minute or two, then stop the log recording & shutdown the RS2+. (I’m not sure if you can just turn off the RS2+ to stop the logging?)
  8. Once you’re back home you need to download the appropriate OSGB CORS RINEX file for the period(s) you where making observations. You can find the files by visiting OS GB Rinex Stations Finder and finding your nearest station. Click on its pin and make a note of the 4 letter name (you’ll need that next). I’m guessing for you it’ll be SHRE for Shrewsbury (yep, there’s one right next to you you lucky person!)
  9. Now visit OS GB RINEX Direct Access and click on the appropriate year in the list (in our case 2024). Now you’ll see a series of subdirectories - these contain the RINEX files for teach station by day. They usually appear an hour or two after the time period they’re recording. Find the day you want and click on the folder.
  10. Now you need the station name you noted in 8. - search for the files beginning with the 4-letter code SHRE and download the files for the time period you want. I’d recommend grabbing the ones either side too just for safety in case you took readings earlier or later. Remember they’re in GMT/UTC+00:00. So, the files for 1pm today would be SHRE00GBR_S_20241011300_01H_30S_MO.rnx.zip - unzip the files and save them.
  11. Download the Log files from your RS2+, unzip and save them, and download your Flow project too.
  12. Now you need to work through Emlid Studio to correct the raw readings.
  13. Choose Stop & Go With Emlid Flow in Emlid Studio.
  14. For the ROVER file, use the file ending in .23O or .24O. ( O = Observation) from your RS2+ log files.
  15. For the BASE file, use the .rnx log files from the OSGB RINEX files you downloaded.
  16. Emlid seem to like using the ECEF position coordinates rather than the ones from the RINEX header, you can find the latest ones in the OSNet Coords File (They’re the first 3 numbers).
  17. For the NAVIGATION file, use the file ending in .23P or .24P ( P= path = navigation) from your RS2+ log files.
  18. If everything’s good, you should now be able to press “Process” and everything should work and give you a solution. If it does, then you can go to the next step, which is to correct your Stop & Go points.
  19. Drag and drop your Emlid Flow Project into the “Project from Emlid Flow” box and press the “Start” button. That should then output a file with the corrected locations in it. I thiink if your project is in OSGB36 & ODN that the outputs should also be in the same CRS. You should also see the corrected WGS84 and ellipsoid heights in the file too.

If you want to try and correct your existing readings, then start from #8. - hopefully your RS2+ recorded a log file for you, and you’ll need to work out the day you need for the OSNet RINEX files - beware they only leave something like the last 40 days of files online… after that you’re going to be trying to track them down from an archive somewhere or other!

I think that’s it - hopefully someone will chip in if something’s not quite right!

Nick

(ps - be prepared for some headaches until things begin to drop into place… a dark room, strong coffee and chocolate needed :smiley: )

2 Likes
7

It’s a shame the RX doesn’t log raw data… maybe one day it will.

2 Likes
8

… plus TILT… plus radio… plus L5… :stuck_out_tongue_winking_eye:

2 Likes
9

Sheesh, thats a lot of steps!! I guess the alternative is to purchase a VRS correction service?!?

We’ll give it a whirl and compare to the same data I mentioned we had from fellow local surveyors and see what gives.

First step…getting IT to allow us to download Emlid Studio :see_no_evil:

10

It sounds a lot, but it’s not as bad as it looks when you go through it.

Even if you buy a vrs/ntrip service it’ll be good to know what to do when it’s not available (or gives you bad results).

2 Likes
11

Actually I enjoy all the extra steps such as PP. I’m an old surveyor that has used GNSS equipment since the early days.

It’s fun every day verifying RTN data by PP with Javad Justin 3 software. I’ve been using it about 6 years now and I’m always learning something new that it can do. I know that I should be doing other things (such as CAD work) but it’s always fascinating looking at the raw data. When I have free time, I’ll PP CORS baselines just to verify NGS positions ! :smile:

The software is about the cost of an RS3. Everybody in the GNSS profession should consider buying commercial PP software. Try it, you’ll like it !

Maybe Emlid will develop a multi baseline processor, that would be cool…

1 Like
12

Hi @PSGSurvey,

Working with mount points from RTK2GO may provide various accuracy. As Nick mentioned, it depends on how the mount point was set up. So, it’s worth checking different mount points to see how the accuracy or the solution changes.

Also, let’s double-check that the mount point provides corrections in the proper datum. When you’re creating a project in Emlid Flow, there’s always a note about how your base should behave. In your case, it looks like the following:

new_project
new_project1061×2173 160 KB

If you can access raw data files from a CORS, it’s indeed a possible alternative to perform Stop&Go with Emlid Studio. In this case, there’s no need for a real-time connection with any base station. Here’s our guide about the necessary steps. You’ll need the raw data files from your Reach RS2+ and the CORS, along with the CSV file of your project in Emlid Flow - with the collected points.

I also recommend our guide about how to record the required logs for Stop&Go.

Feel free to share any additional questions or experiences!

2 Likes