Time marks not present in post-processed coordinates

I recently acquired an Emlid Reach UAV Mapping kit, including RS+ and M+ units, as well as an Emlid LoRa radio. I have set up the M+ unit on a DJI S900 hexacopter (as shown below) and am using it to log points that I mark via another means as I take pictures with a Canon S100 camera.

However, while I know that the time marks are being recognized by the M+ and pictures are being taken (using a wifi connection to the unit), none of the time marks are coming out of the post-processing procedure for RTKLIB published in your documentation.

I have tested that the M+ does recognize the time marks and is logging GPS data using RTK updates. My RTK settings are as follows:

– Positioning mode: Kinematic
– GPS AR mode: Fix-and-hold
– Elevation mask angle: 15 degrees
– SNR mask: 35
– GNSS selection: GPS, 10 Hz updates
– Firmware version: 2.16.2

I am using the copy of RTKLIB available from the Reach documentation (https://docs.emlid.com/reach/common/tutorials/gps-post-processing/). I should have at least 100 time marks, but I only receive a .pos file with position data (not correlated to time marks) after following the procedure described there. I would attach the log files, but, as a new user, the system will not allow me.

Any help is appreciated, as, after perusing the forum and documentation, I’m at a loss for how to procure a file with time marks and coordinates.

In the docs it says:

“The .pos file with “__event” will contain timestamps if you had them during your job.”

Is it correctly understood that this file is missing ?

Are you able to post your ubx files via a wetransfer link or something?

Yes – you understand correctly. There is a .pos file output from RTKLIB, but not with an “__event” tag in the filename.

Let’s try this: http://bit.ly/2MrQA0Y. That link should have the raw and post-processed files. There is a RINEX file in the Rover folder (which came from the M+), but I posted with RTKLIB from the UBX file in case there was something I was missing.

hi Marius,

I don’t see time marks in your supplied .OBS file but i can when i convert the UBX file to RINEX myself - 135 of them. Perhaps convert the UBX again with the latest version of rtkconv.exe.

i know you didn’t ask, but i’d log more satellite constellations at a slower rate rather than GPS only. i can’t see the benefit of high Hz logging for UAVs at the expense of more satellites. At 5hz you could log GPS+GAL+GLO. I’m logging GPS+BDS+GAL and all time marks are present. With this I am able to fix some UAV flights with ref station data from >20km away.


According to the docs either GAL or GLO is recommended for time marks logging:


Is this information outdated?

I get the feeling that my GLO data has lower quality compared to the GPS data (SNR, cycle slips). I also have data sets where I only can get a solution when skipping the GLO data. I thought that a higher data rate might provide more information and thus help to get a fix quicker/more reliable?

@mstrom you can check for valid and non-valid time marks in the OBS file with this tool: Timemark time machine: a script to manipulate events within RINEX 3.xx files

Hi Marius,

I’ve processed your data and got the *_event.pos file with 135 time marks as well.

Are you sure you download the RTKLib version for Reach M+ from our docs? May I ask you to share your step-by-step actions with us?

perhaps that isn’t an exhaustive list of stable configurations. I’m going ok with GPS+BDS+GAL. I checked the satellite availability in your area and it looks like that could also be your optimum combination. BDS have more satellites than GAL or GLO and GAL is about the same as GLO for numbers and might be a cleaner signal. That’s just based on my GAL processing residuals usually being pretty clean compared to the other constellations. That is, when GAL is actually online!

I like to imagine stronger geometry, higher number of satellites with differing frequencies would lead to more reliable and faster fixes, but i’ve not tested it too hard. I haven’t had a flight fail to fix with the extended constellation tracking but GPS only has been unreliable in the past. Also having my flights fix over very long baselines suggests to me that multiple constellations @ 5Hz is the way to go for me.

1 Like

Ah cripe – thank you all for the help. Turns out that, while I had downloaded the Emlid RTKLIB, I was still using the executable for the original RTKLIB. I now have an *__events.pos file with 135 events logged in it.

Thanks, and God bless!


Great, thank you, I will switch for GPS BDS GAL 5Hz! If I ever miss a timemark I can fix that with my script and the Arducopter log data anyhow.

Yeah give it a try and perhaps let me know how it goes after a few flights.