ReachView Survey log and Rinex raw log timing mis-alignment

[conehead (Chris)]

@polina.buriak

@polina.buriak

• 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.
• 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

Mostly correct. We do not know the true geographic location of the geophone sensors, but we know their spacing, order and relative position to features observed in the field (trees, roads, buildings ect).

@polina.buriak

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?

Not exactly. The spacing between the geophones is known, as we put down a tape measure to ensure they are evenly distributed. We have field notes and pictures that detail the order of the geophone stations. However the geographic location of the geophones is NOT known, which is why we are surveying them with GNSS.

@polina.buriak

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.

Again mostly correct. When I load either the raw .LLH or the PPK .POS file into QGIS I notice that the cluster of points associated with the Survey CSV point have significant time differences. The Survey CSV start and end times, for any recorded point, always seems to lag behind the associated points in the .LLH or PPK .POS result.

@polina.buriak

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.

Incorrect. The PPK .POS result which contains ALL points from the raw log is in the correct position. It is when I use the Survey CSV points Start and End times (for a certain geophone station label) to extract a geographic location (XYZ point) from the PPK .POS file that I get incorrect results. In this case because the times from the Survey CSV are incorrect, the wrong XYZ point is extracted from the PPK .POS result.

@polina.buriak

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.

Correct.

@polina.buriak

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

Incorrect. The geographic position of the Survey CSV point aligns with the raw LLH log, only the Survey CSV collection start and end times are misaligned.

Hopefully this clears things up a bit.

[conehead (Chris)]

@polina.buriak Here’s the most definitive evidence for the time shift to date. Yesterday I was in the field doing an RTK survey with the RS2 base and rover. I decided to check the UTC start and end time for the points I had just collected and noticed this:

I’m in the Pacific time zone, so PST = UTC - 8. Given that info the reported collection time from the Survey app would put time of collection at 0751. I can say with 100% certainty that I was not collecting field data until 1100, which is 1700 UTC.

[polina.buriak]

Hi Chris,

Thank you for the detailed comments on my message!

Regarding the issue with the start and end time of the point collection, I’ll try to repeat this issue. Have you had a chance to notice how often this happens with the Survey Project points?

Let me ask you a couple of questions regarding your comments as well.

@conehead

I notice that the cluster of points associated with the Survey CSV point have significant time differences.

Would you mind explaining how you associate the cluster of points in the .LLH log with the point of the Survey Project?

You state that they have a significant time difference so you don’t use the time of the start and of the end of the collection. Do I understand correctly that you determine the same points by how close they are to each other?

@conehead

In this case because the times from the Survey CSV are incorrect, the wrong XYZ point is extracted from the PPK .POS result.

May I ask you if you average the coordinates extracted from the .POS file?

You described the PPK workflow you use a few messages above. As I see it, from the PPK result you only extract one line - that refers to the measurement started at “total UTC time + 5 sec”.

You don’t mention if you create a special column for the “total end time” column so that you could find the end of point collection to average the values.

[conehead (Chris)]

@polina.buriak

Would you mind explaining how you associate the cluster of points in the .LLH log with the point of the Survey Project?

I determine this visually. You can see in my post above on Oct 26th I show that the Survey CSV points coincide with clusters of points from the raw LLH log. These clusters of raw points occur when the operator stops to perform an observation at the desired geophone station.

@polina.buriak

May I ask you if you average the coordinates extracted from the .POS file?

I don’t average the points, I simply extract a single point from within the Collection Start to Collection End time frame.

My field crew noticed the problem occurring again this morning. When the operator turned on data logging it was noticed that the time stamp in the file name is incorrect:

The correct UTC time should have been 15:35. We have noticed this happening consistently (> 50% of the time). Whenever we observe the time mis-alignment, the time stamp on the raw file names and the time stamps in the Survey CSV file are incorrect.

Also we have noticed this only happens with one receiver (Rover), and hasn’t been observed occurring on the Base unit. Perhaps the receiver is faulty?

The field operator rebooted the receiver which fixed the problem. We cannot seem to make the issue occur, so it seems to happen randomly. I had him generate a system report that I will send to you.

[polina.buriak]

Hi Chris,

Thanks for the system report!

May I ask you to reflash the unit with time issues? You can use this guide to learn how to perform the reflashing.

Please keep us updated on the results.

[polina.buriak]

Hi Chris,

How is it going?

Have you had the chance to reflash the unit according to this guide and check if the issue persists?

[conehead (Chris)]

I flashed the rover back to v2.20.8 but haven’t had a chance to tested yet. I’ll update when I get a chance to do further tests.