Well, although definitely possible, it’s a little tricky, due to the fact the time tag position must be interpolated with the next solution and the solution code it not written to work across multiple epochs. I’d say post-processing is a more sane way to handle this.
I’m Geomatic Engineer with some expertise in Geodesy and development. If I can help in something, (research, tests, etc), stay in contact
I have some GNSS receivers from Novatel where it’s possible to compare the timemarks in real time (or even rtk), in a future algoritmn for this purpose.
Just for clarifications, do you consider clock drift when calculating the final event position in the _events.pos file? It seems to me that the raw .obs RINEX file and the final _event.pos file have the same time instances for the events, while the clock drift should have been taken care in the solution.pos file. It is not a major factor, since the M8T resets the clock drift after exceeding 1ms, but still a UAV flying 20m/s this is 2cm.
I looked at it last night and the raw .obs timestamps and the .pos solution timestamps differ more than 0.01 sec, which is substantial. I am sure you handle it somewhere but I just want to understand what I see. Could you clarify how you do the event interpolation?
