Event interpolation implementation issue

I was not satisfied with the RINEX converter of emlid since there are differences between ublox’s ucenter and rtklib’s rinex conversion routines.

While looking at this I realized a possible mistake with emlid’s post processing event interpolation routine:

  1. Firmware image and ReachView version:
  2. Detailed problem description. How does observed behavior differ from the expected one?
    I started to look at the RINEX file event times vs. the PPK processed position event times. Even though the RINEX measurements have the corresponding receiver time while the solution should have GPST (which differs by the receiver clock bias) the solution given by rtkpost_emlid_b27.exe has EXACTLY the same timestamps for .obs and .pos files for the events.
  3. Step by step actions.
    I developed my own algorithm in Matlab to calculate the clock bias and interpolate the event measurements based on a consistent time vector. After that I run pix4d with the same setting but using the emlid interpolation vs. my own interpolation routine. It turned out that 3 sigma relative geolocation error (accuracy) in Z went up from 95.58% to 99.71% when using my routine. This indicates to me that my suspicion is correct and the interpolation is not correct in rtkpost_emlid_b27.exe.
    Emlid geolocation report:
    170826F10_emlid_report.pdf (355.4 KB)
    Report using the custom interpolation routine:
    170826F10_interpolate_report.pdf (355.6 KB)
    Matlab results for clock bias calculated at every epoch, not only at events:

Attached are the pix4d report with emlid event calculation, and with the interpolation routine made from scratch. Also the figure about clock bias. It seems rather high, on the order of 0.0135 s, which is 10 higher than what ublox advertises about clock bias https://forum.u-blox.com/index.php?qa=2675&qa_1=bias-clock-and-doppler. If you fly 20 m/s this means 27 cm of error!!!


Very very interesting. While I dont have the data to prove it, I often see on our calibration site that those flights that are down with a fast cruise speed (>19m/s) tend to have a fair bit of wobble when it comes to comparing resultant ortho/DTM with control in the QC part.

1 Like

Nice found ! Mind you share your matlab script ?
@emlid : Do you plan to correct it ?

1 Like

Please send me a p.m. to get the password:


It should be self contained, with all the logfiles and relative path, but not too much comments.
I would appreciate any feedback!


Thanks for the report. We will definitely look into this in the near future.

1 Like

I did a comparison between the RTKlib interpolated positions for my camera events and then interpolated them myself from the raw events output using python pandas linear interpolation. Because of the surprisingly big differences I am now checking my own math/code before making any bold statements. Attached is a (picture of a) list of differences. If the errors are real then there needs to be a fix. in the interim I will inject my coordinates into the EXIFs and see what comes out of Photoscan.

RTKlib interp

1 Like

If we look into reach through ssh, there is python class for cameratrigger but it’s not here (this class is for camera triggering). It’s inside rtklib.

There is these commits related to time mark :

I just looked into this a bit more carefully. I implemented the time mark related part of the .ubx protocol and I can spot some mistakes.

I have a flight with 683 pictures (1 on ground and 682 in air). I got the exif info about time of each picture taken (denoted ‘sony’ on the figure), I have the time values from the Emlid rinex .obs file (‘emlid’) and I have my own implementation (‘ventus’) .

There are 686 events in the Emlid log and 682 in my own version. What I plot on the figure is the difference between time of pictures. Of course sony is integer, but the big delays between flight lines are perfectly matched between sony and my own, while it seems there are some extra entries in the Emlid version and it grows by time.

Seems to be a buffer problem or something like that in taht case !
Did you sync gps time to your a6000 ?

What do you mean by buffer problem? The time of sony is just a random one, no synchronization, but the time difference between pictures does not depend on the clock offset of any device.

Oh ok, you compare difference between picture not between real time.
To write event in ubx file, I think there is a delay that what I mean about buffer

Yes, I have a suspicion also that rising edge and falling edge events are somehow registered in different messages, maybe due to buffer problems, and it could cause difficuties when parsing the file. You have to consider not only the events but also the corresponding Bitfield flags of the events.
Page 342 of UBX-13003221 - R13 protocol description (https://www.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_(UBX-13003221)_Public.pdf)

But I don’t understand one thing, with your previous post : you plot camera exif information. Correct me if I’m wrong but exif time are in seconds, not in milliseconds, how could it be compared ?

I just converted everything into seconds. :wink: What makes it even worse, event timemarks are partially in miliseconds (1e-3) partially in nanoseconds (1e-9) in the raw .ubx file.

1 Like

In ebee process, time of camera is syncing to gps time during preflight connection. So events are in seconds not milli or nano seconds and it’s working !

Hey guys,

We just got back from the fair. We are currently looking into the issues introduced in the last update. As soon as we fix those, we putting our RTKLIB team on this issue.

1 Like

Hi Balint,

I’ve noticed some diferences (significants) when processing with RTKPost (b27) and comparing with Inertial Explorer (Novatel) results.

I put the output from two programs here if you want to check:


There are 5 files:

Inertial Exploerer output.pdf → a default report
output-Inertial-Explorer-8.6.txt → output/exporting from IE
output_Rtklib-rover_raw_201709211753_events.pos → output from processing from rtkpost (b27)
output_Rtklib-rover_raw_201709211753_events.pos-UTM-Zone22.txt → The fields lat/lon from original file, converted to UTM (zone 22).
differences.xlsx → a simple excel file, with a dispersion graphich of differences.

We can notice that E component is more affected by differences… and make sense due the flight was executed in W-E directions… or … the maximum variation of velocity is in directions West and East.

It’s possible to you share your remote and base files, and the base coordinates to check it in IE?

Thanks for the great attention to this point!

Best Regards

Thiago Tiedtke dos Reis

Hi Thiago! I put them together in a zip file: https://drive.google.com/file/d/0BzzUBqpwxqRCSndRU1FXdEhnQ2M/view?usp=sharing . It contains the reach base, the reach rover files and also virtual reference station rinex files, so it is possible to do direct VRS+Rover processing or also VRS+Base → Base+Rover workflow.
I am really curious about the large errors, usually I have similar results when I have low ratio - also I can see that the solution is “jumping” at some points within the processing since forward and backward do not match. I suggest to use continuous AR instead of fix and hold.

1 Like

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