M2 + RS2 + OPUS Oddity in Time Mark Positions

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

ZIP File with logs and results:
https://drive.google.com/drive/folders/1_SJB5S1uVEh72N-j9Hkga1aHgt3Yxmr3?usp=sharing

Per the standard issue report format:

  1. Both RS2 and M2 were updated upon arrival to ReachView 2.22.1.
  2. System Reports for RS2 and M2 are contained in the linked zip file.
  3. See above summary, and attached images below.
  4. 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
  1. Hardware setup as prescribed in setup guide, powered by external 5.1V BEC. Antenna placement as pictured below.
    Base:

    Rover:
  2. For RTKPLOT of OBS, see images below:
    Rover:

    Base:
  3. See RINEX logs (converted from UBX) in attached ZIP file

Thank you, and please inform me of any technical issues with attachments and/or images.

1 Like

For additional corroborating information, another user is having a very similar issue (almost exact, in fact) in this discussion:

Evan,

Please upload Full Systems Reports from both units to the shared folder.

@polina.buriak,

I have added ZIP files to the shared folder, containing (Full) System Reports for the RS2 and M2

Hi Evan,

Thanks for sharing the reports!

We’re looking into the issue at the moment. I’ll reach out immediately once there’s news.

Hey there,

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.

A post was split to a new topic: Converting UBX to RINEX in RTKCONV

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.
image
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 :
image
If I apply a 18 sec delay in event time (as seen in Rinex) I get a much better figure :
image
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.

Hi Pascal,

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.

Hi guys,

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.

1 Like

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.

SINCERELY
CJ RC flying
Chani Johnsson
Sweden

4 Likes

Hi Chani,

Thank you for sharing the results of your tests! Good to know the update works for you! :slight_smile:

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.

Using the updated version of RTKLib with some older UBX logs, I was able to validate the fix:
(Old version on the left, updated version on the right)

Number of image marks reduced from 1550 to 1520 (30 redundant points, or 1.9%):

Closeup of a redundant image mark removed in the new RTKLib version:

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.

4 Likes

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