ReachView Survey log and Rinex raw log timing mis-alignment

I completed a PPK survey the other week with a single RS2 rover. Base station data was pulled from a nearby NRCan station (7km away). I completed the PPK using RTKPost (demo5 b31). In the field we were surveying in support of a seismic survey, so collecting points in ReachView Survey (latest version), using about 20 - 30 seconds time on each point (single, no RTK) and exported everything to CSV. Logged Rinex3.03 directly in the RS2 for PPK. Now when trying to use the CSV of survey points from ReachView to parse out the correct location from the PPK result Iā€™m seeing a mis-alignment.

For parsing Iā€™m using the UTC time, by converting to total seconds in the day, to align the proper station label (from CSV) to the correct geographic location from the PPK results. However Iā€™m noticing a 1 - 3 minute time difference in the time reported in ReachView Survey and the time reported in the PPK log. I made sure that I didnā€™t accidentally post process using GPST. See attached:

Has anyone encountered this problem before? This seems like a very large time mis-alignment.

Hi Chris,

May I ask you to share raw data logs so we can look into them?

Hi Chris,

Not sure I understand your issue correctly. May I ask you to explain how you come to the conclusion that these two points on your screenshots should be the same point? Were you physically at that point at that time period?

Do you observe the same time shift for all points? This mis-alignment is indeed rather big and looks like something is not taken into consideration during conversion or post-processing.

Hi Polina,

This data set was in support of a seismic survey for georeferencing the seismic results. Each station represents the location of a geophone sensor, so the order and spacing of the stations is well defined and known. The time from Survey CSV is consistently behind UTC time from PPK result, however the time shift magnitude doesnā€™t appear to be consistent for the entire day.

Maybe I need to elaborate on my field data collection method:

  • Survey rover (RS2) collects a ~30s stationary observation at a geophone station using ReachView.
  • Observation point name is labeled the same as the geophone station name.
  • Survey rover moves to the next geophone station and repeats the ~30s observation until all stations are surveyed.
  • Field data was Single Point, uncorrected GNSS.
  • Survey rover is also logging raw GNSS (RINEX3.03).
  • geophone spacing was 1m, however GNSS observations were collected every 12th station.

Post processing workflow:

  • PPK of RS2 rover log completed using RTKPost with base station observations provided by a nearby government operated observatory.
  • import rover PPK result (ASCII CSV) from RTKPost into Microsoft Excel
  • For each PPK data row calculate new column of the total UTC time in secords IE: Hour x 3600 + Min x 60 + Seconds = total UTC time (sec)
  • Sort rover PPK results to increase in UTC total time
  • import Survey CSV (from ReachView) into Excel
  • from Survey CSV data set calculate total UTC time (sec) for ā€˜collection startā€™ column using the same formula as above
  • create another column using ā€˜collection startā€™ total UTC + 5 sec
  • this ensures the time point being referenced occurs within the 30s field observation window
  • use Survey rover ā€˜total UTC time + 5 secā€™ as the lookup criteria with the VLOOKUP function to match the associated Station label from Survey CSV with the correct X, Y, Z values from PPK result

When the extracted results are plotted in QGIS against the single point field survey results, the extracted results are not positioned correctly. Some stations appear in the wrong order for example, station 6 is positioned where station 12 should be. Some stations are positioned at nearly the same X, Y position when they should be separated by ~12m. I also noticed that the final station of the day had no result in the extracted data set because of the time shift between PPK and Survey CSV.

Hi Chris,

Thanks for the detailed explanation!

However, may I ask you what you mean by ā€œfield observation windowā€? Why is it necessary to add those 5 seconds? Have you tried matching without adding them?

Iā€™m adding 5 seconds to the Collection Start Time so that the X,Y,Z position being selected is within the point observation time frame. I want this time/position as it is the best chance of capturing a time/position where the receiver is stable.

I havenā€™t attempted to use either the Start or End time only.

Hi Chris,

Iā€™ll try to reproduce your PPK workflow with your data. Iā€™ll write back to you once thereā€™s result :wink:

Sounds good Polina. One thing I should mention is the time shift is observable in the LLH data as well, so this isnā€™t a result of PPK. The pictures below are screen shots showing raw LLH data in purple and Survey CSV result in red star.


This picture shows the time indicated in the Survey CSV file (Start 21:13:35, End 21:13:56).


This picture shows the time stamp for an adjacent point from the LLH file (21:16:16).

The resulting time difference is slightly less than 3 mins. Of note the timing from the Survey CSV file appears to always be behind the raw file timing. I suspect the problem lies in the Survey portion of the ReachView app, specifically when the user switches to another app on the device and then comes back to the ReachView app at a later time. I noticed that the ReachView app will launch immediately back into the Survey project tab (if thatā€™s where the user left initially), so perhaps the UTC time stamp in the Survey project is not updating when the user re-engages the ReachView app resulting is ā€˜lostā€™ time in the Survey CSV file.

1 Like

Hi Chris,

Iā€™m afraid I canā€™t understand how you compare this data.

Both CVS and LLH data sheets in you case, as far as I understand, were obtained in a single mode. It means that the accuracy of these measurements is meter-level. Also, CVS file from the Survey tool is a list of averaged positions during the time period stated in the file, in which you collected the point.

It means that all of the coordinates of these points are going to be different. The way to correlate the points youā€™ve collected in single mode with the post-processed data is through the time of the start and the end of collecting a point.

In RTKPlot, to get the position of the post-processed points, you should do the following:

  1. Choose ā€œEditā€ -> ā€œTime Span/Intervalā€ and set the start and the end time of collecting the point.

  2. Choose ā€œEditā€ -> ā€œOptionsā€ -> ā€œCoordinate originā€ and set ā€œAverage posā€ to get the averaged position of the point you collected.

To see the averaged position, you can look up ORI coordinates on the ā€œGnd trkā€ tab. This is what you can use as the point coordinates.

May I ask you to follow these steps and check if there are any issues with importing them to the QGIS?

Hi Polina,

Perhaps I need to clarify that those images above show a tight cluster of points (purple) within a 1-1.5m radius. Below is another image of the data at a larger scale, again single solution LLH (purple) and averaged point from Survey CSV (red star). The surveyed stations were approximately 5m apart and you can see in this image the clusters of purple LLH points surrounding the resulting averaged survey point (red star). In the field the operator is walking the receiver to the geophone station, performing a 30s observation, then walking to the next geophone station 5m away. Iā€™m comparing the time stamps from the LLH points that cluster around the survey point and noticing a time shift of several minutes. Have you been able to look at the data I submitted to Tatiana?

changed the content because I realized that I might have the same problem.

Can you make a manual protocol to compare it with the observation time span?

This would be a huge problem for my post processing script.

I actually also have a case where I had to move the observation time by 45 seconds to get a fix. I could see the same thing as you have seen.

Its actually a desaster because its a master thesis with several hundered measurements and now I understand why some of the points have a terrible ar ratio. Probably they are all misaligned.

Now Iā€™m back in the time where the survey did not include starting and ending times. I started to write a script which uses the result of kinematic ppk to find the beginning and end of a survey point by the clustering of the points. I guess I have to continue with that approach.

Are you having having cycle slips in youre data?

Hi Tobias,

Here is the RTKPlot window for a subset of my data. A few cycle slips but nothing major (I think).

Iā€™m not sure what you mean by this question:

Can you elaborate?

Its just an idea to prove that the issue is existing. Write down the start and end time of each point on a paper during a new survey. Just to compare and to have a reference which is independent of the device itself.

I have to go to the field tomorrow, so if I find the time I try to do it. This could also include a comparison of points where the app is not left and points where the app is left and reentered. I guess that is the problem, even if I do not understand why since all important stuff is runnning on the Reach device and the app is simply a browserā€¦ .

Hi Chris,
yes, that looks good. I thought cycle slips might cause the error. I think you are right, its connected to leaving the app.

Iā€™ve noticed that the problem is intermittent, but frequent. Out of the 15 data sets I have with the RS2s Iā€™d say Iā€™m seeing the issue on 10-12.

Yes, I agree. I think my student did not leave the app but the smartphone locked the screen and he had to reconnect.

I have 5 obvious cases in 60 survey points.

Unfortunately the number of seconds of the offset seems to be random.

Hi Chris,

Sorry for the delayed response!

As far as I can see, the issue in this analysis of the data lies in the way you identify the points that cluster around the survey point.

Please note that both these data sheets were collected, as you have reported, in a single mode. It means that the accuracy of these measurements is meter-level. So, technically, the points you claim to surround the survey point may be from the measurements of another survey point.

For example, the purple points surrounding the L2stn1 survey point on your picture could be actually recorded several minutes later than the survey point and later were averaged to become the L2stn6 survey point. Thatā€™s why there is a difference in their time - they belong to different measurements.

That could also be the reason why the PPK data and the CVS data from the Survey project have a time shift between them: you compare the meter-level accuracy coordinates with the centimeter-level ones. It means that you could have compared different points that, indeed, have different observation time.

1 Like

Hi @polina.buriak,

thank you for your answer. We are aware of this effect, but we do not think that is the explanation.

Chris also provided enough evidence for that because he is not refering to the clusters alone but to the time of the cluster points too.

This issue might be overlooked because not many people do PPK for the surveys.

Unfortunately I could not make the test I wrote about last Saturday, but I will do it asap.

1 Like

Hi Tobias,

Itā€™d be great to see the results of the tests to understand what happens and what are the reasons for it.

Please keep us posted.

Chris,

Let me sum up the issue. Iā€™m afraid I still canā€™t fully grasp it. Unfortunately, during the month-long discussion, some points might have slipped from my attention.

Below Iā€™ve described the issue as I understand it. Would you mind showing me where Iā€™m missing a point or understand the issue wrongly?

  1. You have a determined set of coordinates of geophone sensors. You attempt to collect these known coordinates with the Reach RS2 base and rover setup.

  2. You start logging once you turn on the devices. Then you collect the points in the Survey project with the Survey tool in standalone operation.

  3. After the survey, you post-processed the logs with the workflow youā€™ve described several messages earlier. After post-processing, you compare the result of post-processing with the set of the known coordinates and the Survey project data. May I ask you to share the set of known coordinates as well?

  4. When importing the data in QGIS, itā€™s possible to observe that the pointsā€™ coordinates averaged after PPK do not have the same time start and time finish as the ones collected in a single-mode. You determine that you compare the same points by how close the points are to each other.

  5. Also, you observe that the post-processed points do not fall into the same places as they have to according to the previously known coordinates. They appear in the wrong order and are generally not positioned correctly.

  6. Moreover, itā€™s possible to see the time shift between the time start of the Survey project and the LLH log. The first point is collected before the LLH log starts even though itā€™s not how it happened on the field. While you compare the Survey project and the LLH log, you also see that the points are not positioned correctly according to the averaged LLH values.

Please, confirm the steps I understand correctly. Iā€™d appreciate your comments on my message to help clear this issue up.