PPK : Stop-and-Go Methodology Needed

Hello, I’ve been testing a couple Reach RS units, in PPK mode, that we plan to use for collecting GCPs for drone work. We are doing simple static point collects and then post processing back in the office.

What I have found is that 7-10 minutes is required to resolve integer ambiguities and get a fixed solution. This is fine and is typical of many L1 Survey GPS units. However, what is brutal, for example, is that after the first point is collected (raw logging is started and then stopped) the next point must also be collected for 7-10 minutes to achieve a fixed solution. ARG. What I had hoped for was that the “lock” from the first point would be maintained and then that a simple 15 sec collect would / should result in a fixed solution, assuming lock is not lost. But this is not the case, as the solution is float.

So from what I am seeing if one wants a fixed solution then 10 minute occupations, at a minimum, are required. Well, if I am going to collect 20+ gcps then this is not a viable solution. 20 gcps would be over 3 hours of collection time, not to mention the time walking to each point. If lock could be maintained then 15 second collects for 20 gcps would be a total of 5 minutes spent collecting gcps!!

So… This is what I think, IMHO, needs to be added to the software app:

  1. A “PPK Survey” page to remove confusion with all the RTK related pages. All PPK surveys would be started and stopped from this page.
  2. On this tab you you select from 3 types of surveys: static, kinematic and stop-and-go.
  3. The ability to enter a filename would be nice.
  4. For Stop-and-go a automatic file naming process is implemented that auto increments the file name for each point that is collected.
  5. For Stop-and-go a basic count down timer (user entered) for initial lock (initialization) and for point collection would be required. Also, having a warning box pop up if lock is lost. If lock is lost the user would then be told to re-initialize before collecting the next point.
  6. Having the ability to add a description to each file would be nice.

If the above is not possible it would be really useful if “lock” or whatever happens internally, is maintained while in static collect mode white the receiver is on. This would provide a viable work around for doing a stop-and-go survey with short collects. So when a user turns off raw logging lock would be maintained – until the unit is turned off.

I would love to know how those that are using a pair of Reach or Reach RS units (one for base and one for rover in PPK mode) are collecting multiple points. Are people sitting on each point for 10+ minutes? Am I missing something?

Oh, here’s an idea: I suppose I could use my TuffWing trigger cable connected to a Reach GPS and a camera and collect points by taking pictures! One could use an intervalometer, for example, to take one photo every second for 15 seconds while remaining stationary over a point. In post processing, in RTKPost using the TuffWing workflow, these camera event position are logged to a file: "name…events.pos. This file could then be imported in a spreadsheet and positions averaged. This would work – I think. Makes me wonder if a cheap intervalometer could be wired directly to a Reach GPS to avoid the need for a TuffWing cable and camera? However, I don’t know how one would do this with a Reach RS.

Anyways, sort of rambling here. In the end a simple Stop-and-go PPK addition to the software app would be extremely valuable. This would be very helpful for the UAV mapping community (those not doing RTK) that want to use Reach units for surveying ground targets. With this addition you then have a survey tool that is a nice alternative (in good conditions) to a $10,000 Trimble.

Just my 2 cents.

1 Like

This is not a response to your request, but just a comment to make sure you know about this workaround for PPK stop-and-go:

Turn on the rover raw log. In ReachView, start a survey project; single-mode; 1 minute average(or whatever occupation time you decide on). Go collect points at each GCP. On the first GCP, make sure you have had the rover turned on long enough to allow time for first initialization. Then when moving, try to keep the rover head upright, in clear sky, and don’t spin it (to make sure to retain the initialization). Back at the office, download the survey project in .csv format. Open as a spreadsheet and extract point name, start time, stop time. Post process your log file (in one of several possible ways). Get all the coordinates from the position solution file which are between each point’s start and stop times and average them (also can be done in several ways).

For speed, I would suggest post-processing your whole log in Kinematic mode. And for simplicity, I would suggest using RTKPLOT to view the position file. Turn on statistics to get automatic averaging, and use the start and end time settings to limit the view (and averaging) to correspond to each point’s start and stop time from your .csv file.

I hope that helps out in the meantime. :slight_smile:

2 Likes

Your solution would work, although it is a little to complex and round-about to offer as a general workflow for field techs that we would like to send into the field with Reach units. What I need is Emlid to add a Stop-and-Go feature to their software. Emlids RTK features are great, but we work in really mixed and rugged terrain where using RTK is not always viable. I desperately need a elegant solution!

So for the time being I am going to see if I can put an intervalometer on a Reach GPS as a stop-gap solution. This method I believe will work, but it would be missing the critical element of a warning message if lock is lost. If one uses kinematic mode for ground collection, then the potential for loss of lock also looms, but would only be discovered back in the office when one sees that post processing results are float instead of fixed. But then you are out of the field and out of luck!

Anywys, I hope Emlid addresses this.

I can’t believe others have not complained about this? Is everyone just dong RTK surveys now?

Again, not to take away from your request, but to speak about the workaround:
If you are trying for RTK, but might have to PPK some tougher points, with the assumption that you might loose initialization, then you could for example, set these survey project settings:

Fix, avg. 15 seconds.
Float, avg. 10 minutes.
Single, avg. 10 minutes.

(The times above are copied from your first post) And that way if your tech has an RTK fix, they move quickly, and if they don’t have an RTK fix, then the software makes them wait longer on the point so that you have a good chance of getting an initialization when you do your PPK afterward.

This has the added side effect of training your tech that if they can work smarter with the rover and hold the RTK initialization, then they get to move on sooner without waiting around on a point. :wink:

2 Likes

Very interesting. I wasn’t aware that when in RTK mode that the unit also collects raw data (I’m still getting up to speed on these units). So to be clear, it is possible to set up an RTK survey that collects and create raw files (ubx or RINEX) for each point in a static survey while storing RTK results? If this is true then I feel all tingly! :heart_eyes:

Well, don’t get too tingly. It’s not quite that simple.

The tech is in control of the log files and which are on or off. If it were me, I would make them check that they are all on, just to be on the safe side.

You should enable the raw data log the whole time as one long log (so that you can take advantage of satellite data before and after each point to assist your PPK). This is not a complication for the tech, but it is for you afterward. But like I mentioned above, you can get the start and stop times of each point from the survey project .csv file. Then you can constrain the processed solution file to each particular point for which you need a PPK result.

Alternatively, you could get the tech to start and stop the raw data log before and after each point collection, and even though that would be easier for you to sort out afterward, I would recommend against it. You would loose the benefit of the extra data available in a log file that is longer than your point collection time.

You might be interested in the following related thread:

Regards,
-FGN.

Hi Peter

You are right, if you stay 10 minutes on the first point, you can get a fix (from static measurement), then if you maintain the lock, you can go to the next GCP point and only take 1-3 sec (stop&go), and so on for all your GCPs. Even better, if you know your job will last over 30 minutes without obstruction, even the first GCP can be few seconds!

If you record your data with ReachView, you can store the start/end time of your GCPs. You can export your GCP sites to a CSV file.

Then, use EZSurv post-processing software. EZSurv post-processing software allows to retrieve the sites from the ReachView CSV file. Therefore after post-processing of the log file, EZSurv will compute (weighted average) and output your stop&go GCP sites.

To try EZSurv post-processing software: http://www.effigis.com/en/freetrial/

This method of continuous log and retrieve GCP times segments is what I do. Unfortunately it is working in very open areas only. In urban areas there are too much masks to maintain the lock. Dual frequency there has a big advantage of faster fix.

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

Hi Everyone!

I’m glad to update this topic with news about the Emlid Studio release.

Besides such helpful features as raw data conversion and analysis, PPK, and geotagging, the Stop & Go with ReachView 3 simplifies the workflow described in this thread.

Feel free to check it yourself and share feedback with us!

1 Like