Has there been any further outcome regarding event mark accuracy initiated in this thread (now closed);
I was having some difficulty in obtaining a satisfactory alignment solution in photoscan for a survey of approximately 4000 frames, performed with a fixed wing platform with a Sony a6000 playload newly interfaced to a Reach via hotshoe. The nominal ground speed was 18 m/sec. The solution in rtkpost was satisfactory, with a fixed solution obtained for the entire survey flight.
I reprocessed the solution in Waypoints Grafnav application, and compared the full resolution 5 Hz solution with the rtkpost solution. The differences between the rtkpost and grafnav solutions was only a few cm.
However I am observing large, metre+ level differences between the rtkpost event mark solution file and the event marks computed by Grafnav. A plot of the differences illustrates the magnitude and variability of the differences, as well as a strong correlation with flight direction. Flight lines were nominally SE/NW.
The grafnav computed event marks fit the photoscan solution very well, with an RMSE on surveyed ground control points of a few cms. The rtkpost computed event marks yield an RMSE of nominally 1 metre in position.
Given the high accuracy of the grafnav computed solution, there issue is not the timing accuracy of the recorded event marks within the rinex file (using rtkconv_emlid_b27 to convert from UBX). Based on my results it would appear that the issue lies with the event mark interpolation in rtkpost.
Hi Stu!
I think there have not been any updates on Emlid side, even though we talked with them on Intergeo, and they are aware of the problem.
Would you be willing to share the dataset with me, so I would be able to see how much I am able to compensate (1 meter means 1/18 = 0.0555 sec clock bias which is fairly high, 0.02-0.03 s is the highest I have observed) with my custom developed script.
I worked out this morning that my inital comparison between the even marks was incorrect. I had processed the solution initially using Fix & Hold AR mode and then performed the comparison between the event marks from rtklib & grafnav and got poor results. I had then reprocessed the data taking Balint’s advice using Continous AR mode, and computed the difference between the 5Hz solutions, which was acceptable.
I have reprocessed that data today, and now the comparison differences between rtkpost and grafnav computed event marks are much better, going from metres I had initially to decimetres, as illustrated below.
Now to add something worthwhile to the discussion, I computed a simple linear interpolation between two epochs either size of an event mark, and compared this to both the rtkpost and grafnav computed event mark positions. The manually calculated event mark and grafnav event mark agree at a sub-centimetre level.
The RTKpost event mark is incorrect by nominally 16cm in latitude.
So whilst the rtkpost event mark interpolation isn’t anywhere near as incorrect as I had initially feared, there is still significant decimetre level errors being observed.
Balint, I need to trim the base station rinex file down tomorrow, then will post a link to the dataset.
