Absolute newbie- need help getting started

I recently purchased two RS2+ receivers. Yesterday I tried using them for the first time by logging four hours worth of data. I think I might have left the update rate at 5Hz, when it should have been set to 1Hz since I was trying to simulate setting up a base, not rover. Afterwards I downloaded the files to my computer. I was expecting the files to be in .csv format, but they weren’t. How do I convert the files to .csv format? Do I even need to do this?

If I were setting one of my receivers up as a base and logging data for an extended period of time to create a new Known Point, could I use my other receiver to record the locations of my GCPs at the same time? I guess / think my rover needs to be receiving corrections from the base while I record my GCP locations so it’s probably not possible to do these two things simultaneously?

I also downloaded some CORS data from the nearest station, but I don’t know how to use it? Is it possible to use my local CORS as a source for corrections while I record my GCP locations with my rover? How do I go about doing this? I am trying to avoid paying $600 for access to my local NTRIP network.

The Emlid support documents say I need to get a RINEX observation file from a CORS, a RINEX observation file from a local base, and a RINEX navigation file from a CORS or local base to use static processing to create a new Known Point. How do I get a RINEX navigation file from my local base? Is it one of the standard files that gets downloaded after I log data from my RS2+ base? The support document also says I need to use Emlid Studio on my computer to process these three files into a new Known Point. So apparently I can’t do this in Emlid Flow? I know I have to log data for at least two hours, but I am curious how long I can expect the processing to take in Emlid Studio after I have imported the data into it?

If I am understanding the process correctly, I can record my GCP locations with my rover getting corrections from my base over LoRa radio after I have created a new Known Point and placed my base over it?

Since I don’t think it’s possible to get corrections from my local CORS while recording my GCP locations, I think my workflow when I get to a new work site will be to log data for at least two hours, preferably four, then create a new Known Point over the base, connect the base to the rover over LoRa radio and record the locations of my GCPs, getting corrections from the base. Does this sound right?

As you can tell, I am a complete newbie so any help or advice is greatly appreciated! Thank You!

1 Like

Hi Eric,

GNSS receivers record raw data in proprietary or industry-standard RINEX format. Raw data in any format don’t contain coordinates. It contains satellites observations: code, pseudo-range, phase-carrier, ephemeris, and so on. This data is post-processed in software in order to calculate the precise point’s coordinates. Hence, you don’t need to convert it into the CSV format. You need to post-process it to obtain precise coordinates.

Reach RS2+ can record raw data log and output base corrections simultaneously. You need to configure logging in the Logging tab and enable the Base mode via LoRa, for example. While logging the data, you can collect GCPs in RTK.

Here, you can use the Static processing workflow of Emlid Studio. The RINEX log from CORS goes into the Base tab, the observation log with .23O extension from Reach RS2+ goes into the Static receiver tab, navigation file with .23P extension from Reach RS2+ goes into the Navigation tab. You can download log from Reach RS2+ in the Logging tab, this guide may be of help.

If your local NTRIP provider broadcast corrections in RTCM3 format, you can avoid using your own base. You need to configure Reach RS2+ as rover receiving NTRIP corrections and collect GCPs. It’s not necessary to think of calculating precise base coordinates, since CORS stations are commonly adjusted and have an absolute accuracy.

Yes, this file has .23O extension. Even if you record the log in UBX format, Emlid Studio will convert it into the RINEX format.

Yes, it’s post-processing workflow. Emlid Flow can come in handy when you collect points in RTK, for instance, when you collect GCPs.

The processing of a single static point usually takes a couple of minutes. It’s a pretty fast procedure.

I’d also add that a couple of hours is likely excessive time for recording a static log. I believe that a half an hour for rapid static log should be enough.

You can avoid waiting for the end of recording raw data. As I said, you can collect GCPs with the rover while the base recording log. The main task here is calculating the base offset afterward and applying it to GCPs’ coordinates.

After post-processing in Emlid Studio with local CORS log, you have resulting precise base coordinates. Meanwhile, the CSV file contains unadjusted base coordinates averaged in SINGLE. Coordinates measured by the rover are precise towards these unadjusted coordinates, so they have a relative accuracy. To adjust them, you need to calculate the base offset—the difference between precise and unadjusted base coordinates. Then, you need to apply this offset to rover coordinates. After that, they will have absolute accuracy. You can do that in a spreadsheet editor like Excel.

This is also the correct way, but there are some drawbacks you have to know about.

First, you need to perform post-processing right in the field, so you have to bring your laptop with Emlid Studio to the site. Second, the CORS log may be available not at the moment when you’re in the field. Some NTRIP providers send them via request, so it can take a while.

The advantage is that you know precise base coordinates before you start collecting GCPs. So, you don’t need to perform calculations described in the previous paragraph.

1 Like

Is there a way to check to see what update rate I had set, perhaps in the metadata of the log file, after the fact? If I’m logging a static position with my base, the update should be set to 1Hz, right? And for the rover it should be set to 5Hz, right?

Hi Eric,

You can check it by looking at RINEX file in text editor. There are RINEX epochs marked with > symbol with the time stamp as shown in the screenshot below:


Here you can see the epoch difference is 0.1 second (28.1 minus 28.0). It means that update rate for this log is 10 Hz.

We recommend these settings for RTK, but you can use them for static observations as well. You can set Full rate, it will apply the same update rate from GNSS settings.

This is the RINEX file from my test logging session. The difference between the epoch time stamps is .2 so I guess this means I had the update rate set to 20 Hz?

I am going to log four more hours of data in a second test tomorrow. I will set the update rate to 1Hz since I am trying to figure out how to create a new Known Point and the location will be my base.

Afterwards, I will download data from my local CORS that matches the same time frame. Then I will upload the log file from my Reach RS2+ to OPUS and process all of the files in Emlid Studio. I believe this should complete the process to create a new Known Point? And I will get an email from OPUS confirming the coordinates of my new Known Point?

After my new Known Point is created I can use my second RS2+ as a rover to record my GCP locations using LoRa to connect my two receivers. How far away from the base / Known Point can I go? In other words, what is the range of the rover to accurately record GCP locations away from the base? Thank You!

5 Hz: 0.2 sec means 5 per second

@studioBroggi Thank You!

I totally understand your explanation on needing to adjust the recorded GCP locations with the base offset to make them absolutely accurate, rather than relative. Is there a tutorial on how to do this in Emlid’s support documents? I know I would do this in Excel or other spreadsheet software. Thank You!

Ok, so I logged data for a little over four hours today. I selected OPUS in the logging settings, which defaulted to 30 sec intervals. Afterwards, I uploaded the .23O file to OPUS and got an email back in a matter of minutes. For some reason only 87% of the observations were used. The tutorial says the most accurate solutions require 90% of observations being used. Any idea why only 87% of the observations were used? The tutorial also says the orbits used in the computation should be either rapid or precise. The email I got says an “ultra-rapid orbit” was used. Any idea why an “ultra-rapid” orbit was used and precise or rapid orbits were not?

The next step in the tutorial is to enter the obtained coordinates in the base settings menu. I can do this when the RS2+ unit is not over the base location? I am only entering the obtained coordinates for future use? So for example, if I enter the obtained coordinates in Emlid Flow while the RS2+ receiver and I are in my office I am not telling the RS2+ that it is currently over the spot where I logged the data?

It does not look like I can enter and save multiple base locations at the same time, so if I had multiple projects going on at the same time I would have to enter or re-enter the appropriate base location each time I wanted to use them?

After uploading the observation file from my logging session, I also processed the file in Emlid Studio along with an observation file from one of my local CORS stations. However, I don’t think the result I got in Emlid Studio is accurate because the logging session was set to OPUS at 30 sec intervals and not Default with a 1Hz update rate? If this is the case, I think it means I cannot use the same log file for both uploading to OPUS and Static Processing in Emlid Studio for the purpose of creating a new Known Point? Therefore I should choose which process I am going to use before starting logging?

Also, when I set up my logging session I forgot to change the position mode to Static, so it was left on Kinematic. Does this mean my log file is inaccurate?

Depending on the answers I get to the questions above, I am going to use the base location I recorded today as a Known Point to get corrections while I place some GCPs for a photogrammetry flight. If I have to I will re-log the same spot with the correct settings to get more accurate results. My goal is to learn how to create a new Known Point using both OPUS and Static Processing in Emlid Studio.

Lastly, when I went to download CORS data from my nearest station (RNO1) no data was available from the last two weeks. Is this a normal thing to happen? I had to get CORS data from the second nearest station (STEA), which I did with no problem. When I request data from CORS I’m sure I need to ask for the same time frame as my logging session and the two files are automatically synchronized in Emlid Studio? And therefore the update rate / sampling rate have to match as well?

Thanks in advance for answering my questions! Hopefully it won’t be long before I have this process down and committed to memory. I’m sure repetition is the key.

Hi Eric,

We don’t have a specific guide, but you can read our Support tip explaining this process.

I need to look at your file and check its raw data quality before drawing any conclusions. You can send it via PM or contact us to support@emlid.com.

I assume that ultra-rapid orbit was used due to the fact that you uploaded the file right after the logging session. Rapid satellite ephemeris and clocks usually appear in such services at least in 24 hours, precise ephemeris may appear in a few days.

If you want to proceed working in RTK, you need to input obtained coordinates once you place the base in the field. If you work in PPK, it’s enough to keep these coordinates and input them lately in Emlid Studio or another post-processing software.

If you have several fixed points with known coordinates at your survey area, you can add them manually in the project. When you place the base over one of these known points to collect your GCPs in RTK, you select a particular point from the project. In this case, you won’t need to input their coordinates each time: they are stored in the project.

To bypass it, you can record UBX log as backup. Reach will simultaneously log one RINEX file for OPUS with preset, and the UBX file, which you can convert into the RINEX in Studio. UBX file contains all the raw data, so you can adjust it to the software requirements. Emlid Studio will process converted RINEX file smoothly.

No, it doesn’t. This setting affects RTK mode, not logging.

It depends on your NTRIP provider. As far as I know, some of them provide access to logs only via email requests.

Yes, you’re right. If time intervals don’t match, Emlid Studio outputs SINGLE solutions. The same as if you process without the base log at all.

It’s unnecessary, but you may struggle to get a FIX when the base has a large update rate, like 30 seconds. We receive such reports occasionally, so it’s better to keep the base and the rover on close update rates. For example, if the base has 1 Hz and the rover has 5 Hz, there should be no issues.

It is good news to hear I can log data for both OPUS and Static Positioning to create a new Known Point at the same time. There is just an added step of converting the UBX file to RINEX. I am confused a little bit though, because if I select OPUS in the raw data format it defaults to 30 sec intervals. So if I select OPUS and UBX, the update rate for at least the UBX file can still be set to 1Hz?

When I uploaded my OPUS observation file into Emlid Studio it had an interval of 30 seconds, but the RINEX observation file I got from CORS had a sampling rate of 1 (second). This makes me think the result I got is Single and not Fixed? However, if I had converted the UBX file to RINEX and uploaded that file to Emlid Studio, both observation files would have update rates of 1 second / 1 Hz?

Perhaps it might be better to leave the raw data format to Default and then upload that file to OPUS? Or will that create a problem or error since it wasn’t specifically set to OPUS?

I am currently only trying to learn how to create a new Known Point and record GCP locations for PPK, however at some point soon, I would like to learn how to set everything up for RTK as well. If I understand your previous response, I can or should only enter the base coordinates in the base settings menu when the RS2+ receiver is over / on the actual spot? If I want to enter the position’s coordinates when the receiver is not over / at the actual spot I should create a project by tapping the Survey tab and enter the coordinates as a saved point in the project?

What would happen if I enter the base coordinates in the base settings menu when the RS2+ is not over the actual spot? Are there any negative consequences to doing this?

It seems like you implied some CORS stations can be used as NTRIP for RTK corrections, but not all? So far I’ve only used my nearest CORS station (RNO1) and the second nearest CORS station (STEA) for PPK through User Friendly CORS. There is another NTRIP network available locally, but it costs $600 per year. I am now hoping RNO1 can be accessed for RTK corrections for free. I will try to find out if this is possible. (It’s not, I just found out it’s the same network that costs $600 per year, bummer.)

I am currently logging data for another four hours over the same spot as my earlier test. I will upload the OPUS file to OPUS and convert the UBX file to RINEX format and then input it into Emlid Studio. I wish / Is there a way to verify all the settings after the fact? Especially in regards to interval or update / sampling rate?

It is disappointing to learn I might have to wait 24 hours after logging to process the files to get a rapid orbit being used on OPUS. Last Sunday, I uploaded to OPUS within about 6 hours after I stopped logging data so that is probably why it used an “ultra-rapid” orbit.

I have copy & pasted the email I got from OPUS below with the parameters that were used in the calculation of my new Known Point. Any feedback would be appreciated. Thank You!

FILE: GAP_Reach1_raw_20230212185023.23O OP1676269046759

2005 NOTE: The IGS precise and IGS rapid orbits were not available
2005 at processing time. The IGS ultra-rapid orbit was/will be used to
2005 process the data.
2005
NGS OPUS SOLUTION REPORT
========================

All computed coordinate accuracies are listed as peak-to-peak values.
For additional information: https://www.ngs.noaa.gov/OPUS/about.jsp#accuracy

 USER: eturn23@me.com                           DATE: February 13, 2023

RINEX FILE: gap_043s.23o TIME: 06:20:05 UTC

SOFTWARE: page5 2008.25 master292.pl 160321 START: 2023/02/12 18:51:00
EPHEMERIS: igu22490.eph [ultra-rapid] STOP: 2023/02/12 23:10:00
NAV FILE: brdc0430.23n OBS USED: 7181 / 8286 : 87%
ANT NAME: EML_REACH_RS2+ NONE # FIXED AMB: 74 / 81 : 91%
ARP HEIGHT: 2.0 OVERALL RMS: 0.020(m)

REF FRAME: NAD_83(2011)(EPOCH:2010.0000) ITRF2014 (EPOCH:2023.1175)

    X:     -2447561.108(m)   0.014(m)          -2447562.141(m)   0.014(m)
    Y:     -4287301.920(m)   0.015(m)          -4287300.569(m)   0.015(m)
    Z:      4027118.985(m)   0.011(m)           4027118.910(m)   0.011(m)

  LAT:   39 23 39.05516      0.001(m)        39 23 39.06690      0.001(m)
E LON:  240 16 42.79570      0.016(m)       240 16 42.73021      0.016(m)
W LON:  119 43 17.20430      0.016(m)       119 43 17.26979      0.016(m)

EL HGT: 1398.672(m) 0.016(m) 1398.114(m) 0.016(m)
ORTHO HGT: 1422.745(m) 0.072(m) [NAVD88 (Computed using GEOID18)]

                   UTM COORDINATES    STATE PLANE COORDINATES
                    UTM (Zone 11)         SPC (2703 NV W)

Northing (Y) [meters] 4364054.689 4515973.876
Easting (X) [meters] 265641.060 701967.332
Convergence [degrees] -1.72795556 -0.72236389
Point Scale 1.00027630 1.00001829
Combined Factor 1.00005685 0.99979890

US NATIONAL GRID DESIGNATOR: 11SKD6564164055(NAD 83)

                         BASE STATIONS USED

PID DESIGNATION LATITUDE LONGITUDE DISTANCE(m)
DN4181 P143 INDIANCRK_CN2007 CORS GRP N384536.586 W1194553.357 70504.7
DG6525 COF1 FERNLEY COOP CORS ARP N393618.051 W1191426.228 47532.3
DN5644 P149 BABBITTPK_CN2008 CORS GRP N393607.653 W1200617.856 40296.1

            NEAREST NGS PUBLISHED CONTROL POINT

KR0928 46 N392330.000 W1194431.000 1787.8

This position and the above vector components were computed without any
knowledge by the National Geodetic Survey regarding the equipment or
field operating procedures used.

If you review this, it will answer 99% of your questions:

https://geodesy.noaa.gov/OPUS/about.jsp

2 Likes

ok, thanks, I’ll give it a read.

2 Likes

Hi Eric,

UBX log is recorded as it is, you can cut it into intervals shown in the screenshot below. 1 Hz is also among them.

Probably I don’t get your idea, but why you want to input base coordinates when it’s not on the actual spot? You won’t benefit from it anyhow. The only thing you’ll get is that the rover won’t calculate FIX if inputted base coordinates significantly differ from real base position.

If NTRIP service transmits corrections in RTCM3 format, it should work with Reach receiver just fine.

You can leave OPUS preset and record UBX log as backup. OPUS preset is tailored to be used with OPUS service. Just in case, you’ll be able to convert and adjust your UBX log for OPUS or Emlid Studio, for example. We’ve even recently published a Support tip that can help you.

1 Like

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.