Understanding RS2+ M3E GCP & mapping workflow

Reach RS2 / RS2+ Hardware integration
1

Hi Jack, here,
As a newbie, I am trying to understand the technology and nuances of using this GPS equipment. I would like to explain how I have set up my equipment and have you please comment on whether this is a sound system for collecting GCPs and images from a mapping area.
My equipment: 2 Emlid Reach RS2+, 1 DJI Mavic 3 E.
Establishing Base: I have a sim card in both RS2+s. For the base I turn on Mobile data and connect to my local NTRIP provider. For base settings I have: Avg Fix, Avg Time: 6 Min and correct antenna height. For GNSS settings I have: Pos Mode: Static, Elev: 15, SNR: 35, GPS GALILEO QZSS GLONASS BEIDEO selected, Update rate: 1Hz. Logging: Raw Data File: RINEX 3.03, OPUS with LLH, RTCM3 and backup for RINEX selected.
I set my base at an unknown point and turn it on let it run till I get corrections showing with a fix position showing and then I start the log.
Once that is complete, I start to ensure that the Loran is configured for the base settings. I then position my Rover near the base settings so that when the position comes up, I can compare it with the bases’ position.
Establishing the Rover: I do not have the mobile data turned on. For corrections I use the base through Loran. The Rover’s Base settings are: Avg Fix, Avg Time: 2 minutes, correct antenna height. GNSS Settings: Kinematic, Elev: 15, SNR: 35, GPS GALILEO QZSS GLONASS BEIDEO, Update Rate: 5 Hz. Logging: Raw Data File: RINEX 3.03, OPUS with LLH, RTCM3 and backup for RINEX selected.
I let the Rover run till I get corrections showing with a fix position showing and then I start the log.
From here I create a Survey Project and start recording points. I start with the base and continue with the rest of the GCP points. Once I am done, I set the rover next to the Base and record a last point for comparison with the base. Turn off the logging on the rover let the file compile and then switch off the Rover.
I now configure the base and the drone. I activate the Base’s hotspot. Change my network connection on my android device and reestablish my Emlid Flow App. On the Base output menu, I select Local NTRIP.
Power up my M3E controller and aircraft. In the controller’s settings menu I connect to the Reach’s hotspot WiFi. From there I go into the Pilot 2 App and go into the settings menu with RTK. I select Custom RTK Network and fill in all the settings from the Base’s Emlid Flow Local NTRIP page. Save then wait to see the corrections taking place on the Pilot 2 App’s RTK page. Takes a little while for things to settle. I go back through the Base’s status and verify logging is still running.
Then I fly the mission. Shut down the M3E then the controller and pack them up. Then I go into the base’s menu for logging and turn off the logging let it compile the shutdown the Base.
This is where my questions start:

  1. How does the Base establish its position considering the input from the NTRIP network over the sim card does it do continuous calculations or does it do an average of a time period that you set in the Base menu for the aquation?
  2. When the receiver establishes a Fixed resolution is that a fixed number that it can send to a rover as reference? Or is it constantly resolving itself with the NTRIP network and changing the fixed position?
  3. If it is changing are the corrections that it would be sending through LORAN to the mobile Rover or Drone be always changing affecting location of images and GCPs?
  4. Since I am doing RTK, do I need to do PP on my data for accurate results? Is the way I set up the Base with it still connected to the NTRIP network through the Sim Card allowing the Base to have a solid position data so that it can send out corrections over LORAN to the Rover or Drone for good results?
3

Hello, this is a very interesting question. I have kind of the same workflow now ( just received my base this morning )
I’m following up this thread !

In my opinion : ( Newbie as well )
1 - To me, once the point is established with Ntrip RTK FIX it should be the same all long. I think recording is just used to get a better accuracy with PPK once you’ve finished the mission.
2 - I think that after you get your base position with RTK, the point where your base is won’t change. It’s just going to stream position to your rover.
3 - I think the base point is not changing over time. It’s the one that you get in Ntrip RTK at the beginning of the operations.
4 - You do not need to PPK if the data is suitable. But, PPK will ( i think ) create a better accuracy.

To me the workflow is :
1 - Setup the base and aquired it’s position through RTK ( Log PPK for all the survey in case )
2 - Turn on the rover and connect it to that base ( Ntrip / Lora / Local Ntrip )
3 - Collect your GCP and CRLpoints using the rover in RTK corrected by your own base.
4 - Fly the drone ( local Ntrip / Ntrip )
5 - Switch off the base.

If the results are OK then no need to PPK

If not : PPK your base first, and then apply changes to the rover and the drone. ( I don’t know how to do that part still … )

( This is not an accurate answer - I’m a noob as well )

2 Likes
4

Thank you for your input! I appreciate it. My thoughts, as a newbie also, I wish Emlid tech could verify the updating of position on the base. My thoughts are that the base continuously updates to adjust for the constant varying conditions that affect the satellite signal. I also wonder about doing PPK on RTK? Reason being, that I am wondering if you are over correcting for error. RTK is a corrected position for what I understand. So when you process PPK are you putting corrections on something that has already been corrected?

5

Using an RTK connection over NTRIP, your base point would be whatever time frame and conditions (e.g. FIX only) you set. Time matters. The longer, the better. Especially considering the base line to the CORS station supplying the corrections, and the gnss environment, you are operating in.

Once the point above is set, it does not change unless you initiate it. At this point, you can turn off the input of corrections from the NTRIP caster. Even if you left corrections on, but did not initiate a re-average, the recorded point would not change or adjust over time.

Covered above.

PP? PPK or PPP processing can always be done later if you wish. In either case, the raw gnss observation data from the recorded logs are used. Not the point(s) collected via NTRIP, LoRa, or anything else. If enabled, the rinex (and raw ubx) log will run continuously the whole time the receiver is on.

3 Likes
6

Dpitman response is what I thought yes !
Regarding your question about " PPKing points that were collected in RTK " it doesn’t matter.

PPK looks for the TIME ( start and end ) of the average, and then give you a position (cm )
So if you collect points in RTK or FLOAT, or SINGLE, it doesn’t care : It looks the time frame of your average to give you the calculated point

Again : i’m a newbie, someone correct me if Im wrong ?

7

Hi Jack,

As I see, John and Elix have covered this topic well. I can confirm their answers.

8

PPK looks for the TIME ( start and end ) of the average, and then give you a position (cm )
So if you collect points in RTK or FLOAT, or SINGLE, it doesn’t care : It looks at the time frame of your average to give you the calculated point

When you have a proper connection between your base and your rover, and both of them are in the right conditions, you should get a FIX solution. So there’s no need for PPK at all. But you are right. Emlid Studio doesn’t use the solution status or RTK coordinates from the CSV file.

9

Thank you so much for your input! It is amazing how much more you can absorb going over the responses several times. I have a question regarding the setting the acquisition time for the Base’s NTRIP corrections to get a fix. Because establishing a accurate Fix for a Base is critical, what I is a nominal time setting for corrections for a Base receiving NTRIP corrections? I had read somewhere where people were adjusting this acquisition time as a function of how far away the NTRIP station was from the Base. I guess my thoughts were to set it the time right up to when you ready to collect GCPs with your rover? But what is a minimum? What are your thoughts?

10

When I get on site, the first thing I do is select the best spot I can to establish my base point and set up the receiver to start averaging/FIX only. If I have a good gnss environment and the baseline to the station is less than 15km, I average for 15 minutes. If the conditions are less than good, or the baseline is longer, I add as much time as practical.

So, 15 minutes is my starting point, and during that time, I am getting my drone set up and any other preparation for the flight.

After the base point is set, I then set my ground check points. The collection time on them is only 2-15 seconds. And of course the drone, acting as rover, will set a point in milliseconds. Both are dependent on a decent base point.

3 Likes
12

Thanks for all these quality information !!!

I live in Corsica, and the majority of the bases here are > 15km from my surveys area.
But sometime, I find IGN known points ( National Institute of Geography in France ) closer to my area. ( < 10km )

Again, i’m new to it, but If I place my base over one of these points, and input its coordinates to the base I’ll now be able to send correction to another rover on the survey area.

In this configuration, how many time should I average that base in your opinion ?

Also, from that, i’ll place my rover on a good spot on my survey area, and place another “known” point using this setup. I’ll then turn this rover into a base to be able to use it every time I come back in this area.

For this flip from rover to base, how many time do you suggest to average ?

I’m sorry if my question is not very undertandable, my english is not very good !!

Thanks for your help !!

13

If you set up your base on a known coordinate, you do not need to average at all. Input the coordinate in the base settings CONFIGURE > MANUAL and you are ready to transmit to the rover.

Note, that to make the above even easier, you can import the coordinates into a PROJECT beforehand in the office for any points that you know you will be using. And then in the field, you go to BASE SETTINGS > CONFIGURE and you have the option to select a point from a PROJECT. Using this method, you don’t need to manually type in the coordinate in the field.

If you are < 10km from your base set up on the known coordinate, you have a good gnss environment and you are wanting to establish a good base point on site, 15 min. should be good. There are no absolutes with this. For example, less time might result is a placement that is just as good. You can do your own experiments by post processing your base point in addition to your RTK work., and check the result against what you were using in RTK. If it is a small offset, you know you averaged for long enough. If the offset is too large, then more time averaging would have helped.

1 Like
14

For establishing a known point, I’d actually rather observe 4-5 times of 1-2 mins, each spaced 2-3 hours apart, and then average the 4-5 resulting coordinates.
This will, to a much larger extent, take into account multipath conditions, ever-changing satellite geometry etc.

I know this is much more involving from a total time point of view, but it will be a lot more rigid, but without having to leave equipment and manpower on point for hours.

1 Like
15

Ideally, yes. These folks are showing up to fly a drone mission and leave. So the advice is relative to that workflow.

1 Like
16

Thank all you for your insights and input into this topic!
I would like to add to the discussion with my thoughts on this topic. I invite you to comment on my techniques and assumptions and add anything you think is important.

My understanding is this: You need to have an accurate position reference from a Base from which to send corrections to your Rover. As such, this can be a know position where you enter the known coordinates into the Base. The caveat being sure of the accuracy of that position you are entering. The Base will now reference this position to give corrections to the Rover. The second method is to use a CORS station, which is also a known point, only you get corrections over the internet from this known point. The third method is where you don’t have access to a known point or to the internet. You record a data log of raw coordinate data over a period of time. You then Post Process this data with data from a know point, CORS station, which has corrections from its known position at the same time you were data logging your Base’s GNSS data. This is then compiled together into an average to give you a position solution - a known fix. You could then go back and use that data as a known position to be entered into your Base on subsequent jobs using the same point.

It seems that the methodology you use depends on your operating environment. Having a known accurate position, Having an internet connection and a reference station within < 10Km w/Single Band RS/RS+ < 60Km RS2/RS2+ Dual Band according to Emlid Documentation. Or having none of the above abilities you use a static averaging that is Post Processed with outside known point corrective data.

The key point to me seems to be have an accurate base point from which to send corrections to the Rover. It seems to me that in most cases the Emlid Base’s baseline to the rover will be much smaller than a baseline from a CORS station to the Base. As a result the potential relative error will be smaller. This will allow you to use less time acquiring GCPs.

I have read and re-read the Emlid documentation and come across some things that I don’t quite understand. The first one is setting up NTRIP corrections using internet connection.

I JUST noticed that the Emlid documentation says to setup the NTRIP correction in Rover status. This is what is called: “RTFI”. Read the … instructions. When using NTRIP as a correction your status technically is of a
“Rover”. Some of my confusion is that in my mind this will be a used as a base. Also when I read the definitions of Static and Kinematic under GNSS settings it said:

Kinematic positioning is one of two positioning modes. It implies that the rover is moving during the positioning process.

Static positioning is one of the positioning modes. It assumes that the Reach rover is static. Constraining the system helps to resolve ambiguities faster as well as produce measurements with higher precision.

To me it would be “Static”? In addition, the GNSS update rate should be set to 5 Hz which would increase the number of samples? Your thoughts? If this is true that you need to setup your Reach as a Rover first, then once you have your solution you would need to reconfigure the Reach to a Base and Manually entering the solution into the Reach for position.

The documentation also states for a RTK Fix Position you need to set a time of averaging of < 5 mins for which seems incorrect to me. It should be > 15 mins. And add 1 min per km > 10 Km. So a Base line of 15 Km would use 20 mins of Averaging time. What are your thoughts?

Again Thank you All for helping me and others sort this out!

Jack

1 Like
18

@jjckflsh, you understand most of the processes well, but let me add some extra details:

It seems that the methodology you use depends on your operating environment. Having a known accurate position, Having an internet connection and a reference station within < 10Km w/Single Band RS/RS+ < 60Km RS2/RS2+ Dual Band according to Emlid Documentation. Or having none of the above abilities you use a static averaging that is Post Processed with outside known point corrective data.

You’re right. You can post-process your data if you can’t work with RTK. I suggest using our Emlid Studio for this purpose. In this case, you have to record the receiver’s log and get the base’s log too. Whether it’s your own base station or a CORS station. Using PPK your baseline limit is even longer. 100 km for our multi-band receivers (Reach RS2+). But it’s important to note that you also need proper environmental conditions while recording the log.

When using NTRIP as a correction your status technically is of a “Rover”. Some of my confusion is that in my mind this will be a used as a base.

The device that receives corrections is considered a rover. For instance, when your base is connected to NTRIP for Average FIX, the NTRIP base acts as a base, and your base acts as a rover.

Also when I read the definitions of Static and Kinematic under GNSS settings it said:

It’s better to stick to Kinematic all the time. We’re removing Static for multi-band devices in the next stable firmware version (and already removed it in the latest Beta), so I’d not recommend it at all. Static is applied for RTK only and we see from our tests that the results don’t differ much from Kinematic.

In addition, the GNSS update rate should be set to 5 Hz which would increase the number of samples? Your thoughts? If this is true that you need to setup your Reach as a Rover first, then once you have your solution you would need to reconfigure the Reach to a Base and Manually entering the solution into the Reach for position.

We suggest setting up your rover to 5 Hz and your base to 1 Hz. You are right if you want to work with absolute accuracy using your pair of devices. In this way, you have to set up your rover and measure the “future” base position with an NTRIP service. After that, you can use this receiver as a base over the known point and connect a rover to it.

The documentation also states for a RTK Fix Position you need to set a time of averaging of < 5 mins for which seems incorrect to me. It should be > 15 mins. And add 1 min per km > 10 Km. So a Base line of 15 Km would use 20 mins of Averaging time. What are your thoughts?

Fix means there’s already a centimeter-level accurate position calculated. They can increase the collection time, but overall, it’s not required.

1 Like
19

Thank You so Much Zoltan for your input. I helps considerably!

1 Like
21

Phew! Lots of info here. One question. When I’m receiving corrections from an NTRIP Cors, it connects to the closest sensor (36km). However, that station does not create logs to download for PPK. The closest data available is further from me to the south. Will correcting the base station data via PPK from the latter make my base station get a more accurate solution? Thanks!

1 Like
23

How far away is the second source? What is your tolerance for elevations? I can tell you from my experience that by the math alone you are already pushing if not over the boundary of what we would consider Survey-grade (0.10ft) here at 36km. Our network RTK threshold would be more like 20km with maybe up to 30km for PPK. We do have 0.16ft work that can afford further but that’s not the norm. Texas being so big is a horrible place for proximity to base so I rarely run directly off the network any more. I have found that a local NTRIP base keeps me around 1.5-2cm in relativity and I don’t ever have to worry about dropping a fix and I can log my own base corrections. It was an easy decision here since we have to pay for network services.

2 Likes
24

Michael, first off, thanks for the reply. I am a total nube and have no survey background, so I’m trying to understand it all.

The second station in Little Rock (ARLR) is 46km away. I can download the station data for PPK corrections from it. The closer one in Conway (ARCW 36.2km), does not have data available.

If you are not using Cors corrections real time, how do you correct your base station to absolute accuracy after the fact? PPK or OPUS or something else? Is that even possible without doing precise point positioning (PPP) long term (at least 4 hrs)? Also, I thought that the RS2+ would correct the ionosphere deviations for up 100km away? Is that not the case?

My head is spinning! Thanks for any info.
Jason

25

Just by the math. The spec on the receivers is 14mm+1ppm and I typically see 2cm @ 15-20km when on the network so that checks out. 14mm @ 36km is more in the range of 4cm or 0.13-0.15ft so outside of our “Survey” (Construction) tolerance of 0.10ft. I usually set an averaged RTK point from the network and manually set the base to that point so it is now “fixed” and broadcasting corrections via local NTRIP to the RC and my deviations are always 1cm horizontal, and 1.5cm vertical. If I get outside of 30km I will PPK for 30 minutes, run that through Studio and then set my point to that. The only other two scenarios are when absolute geographic positioning is required and I need to do PPP but that has only been a couple of times over the last 5+ years. Usually in that situation there is a Registered Surveyor involved so I am rectifying to their data anyways and may even have control points I can use from them.

1 Like