After completing my first test PPK mission with an RS2 + M2 setup, I have observed some strange behavior with the time/event mark locations. I have prior experience using the M+ and RS+. I seek input on my configuration and/or workflow to amend the event mark positions.
In summary: The time/event mark locations are not associated with the post-processed rover position log/paths, they are scattered about with only light correlation to the rover position file path. The rover position file maintains 99.9% Fix during flight, and the time mark file maintains 100% Fix. Event marks run well off the ends of the survey grid, and wobble greatly along the rover path. Event mark altitudes vary by +/- 40m. Neither of these issues are present in the rover position file, so I do not understand where or how these event mark positions are derived - they are almost certainly not interpolated from the rover position file as I would anticipate, since they are not “between” rover positions along the path. There is a large void in time marks present in the middle of the survey, which does not reflect image capture absences. From my work with the M+ and RS+, missing time marks are nothing new, but this issue seems very new to this combination of equipment and software.
For this mission I used OPUS to process the base station coordinates, tested prior to provide decent accuracy (~1.5cm with 30 minute observation).
Steps followed are as detailed in post-processing docs, with the following exceptions:
Elevation Mask 15
GPS Only
Manually inserted OPUS coordinates in Lat/Lon/Height (dms/m) format, as follows:
LAT: 29 6 33.03234 0.008(m)
W LON: (-)81 5 13.87802 0.006(m)
EL HGT: -22.100(m) 0.023(m)
For more details see OPUS report in ZIP file
Used RINEX version 2.11 for consistency with OPUS requirements (Also tried 3.03)
All other steps as prescribed to the best of my understanding
Hardware setup as prescribed in setup guide, powered by external 5.1V BEC. Antenna placement as pictured below.
Base:
Just wanted to announce that the issue with overspread time marks was due to the RTKLib time conversion issue. This is fixed in the new RTKLib QT apps. You can download them from this guide.
I have a similar issue, and when looking for causes I found a nasty time record inside a rover obs Rinex file. So it is not only a post processing issue with RTKLib.
I hope the pink line indicates well an event, as it fit in time with the event.pos file.
If I process as it is, I have a figure very close to @evan.williams1010 is showing :
If I apply a 18 sec delay in event time (as seen in Rinex) I get a much better figure :
We could correct that position much better, but delay can only be estimated between 2 GPS fixes, here at 0.2 sec frequency. So 4m for a plane flying at 20 m/s.
Thank you for digging into this issue and pointing this out!
This is indeed so. We know about the issue and are working on the solution for it. We hope to release the fix in one of the following updates.
We felt that it was important to provide the RTKLIB conversion solution until we release the fix so that the issue doesn’t affect the PPK mapping workflow badly.
Let me give you an update on this. We’ve released the v2.22.5 firmware version for Reach M2 and Reach RS2 that should solve some issues with extra time marks.
It’d be great if you could update your units and tell us how the release works for you. I’d like to note that currently, fix only works for logs recorded in RINEX.
Hello
Now I have flown 2 tests with your latest update of RS and M2.
Flight 1: 88 photo 6.6 ha Height 70 m speed 4m / sec camera shutter 1/500 sec.
Flight 2: 73 photo the same height and settings.
All markings in events were equal to the number of photos.
When running in RTKLIB 33b RS2 as base log rinex 3.03
M2 like Rover log rinex 3.03. The result was outstanding
in both tests, fix everything and a diff in Z of just 2/3 cm.
It looks very promising as it works now.
You have done a very good job.
Thank you for sharing the results of your tests! Good to know the update works for you!
Let me add that now you can post-process the UBX logs without having issues with the time-marks quantity. The new version of RTKLib is already in our docs.
The fix on the post-processing side appears to be working well.
I will not be able to do a flight test for quite some time, but I trust @SS6106jj4605 's conclusion.