PPK Missing Events

i have a question:
I got this Positions after Post-Processing
Sapos_Base_Rover_201910220911_events.pos (151.0 KB)
Are they all wrong,because of SNR?

They can be wrong because of many reasons.
But yes, if you have a float solution with a baseline under 60 km, you shouldn’t trust your results in general.

1 Like

After nearly 9 month of missed time mark and no solution on the forum, you can find my thread here I found one today, simply by ignoring this line from the GPS post-processing guide on the Emlid docs :

If your raw logs from base and rover are saved in .ubx format you should convert them to RINEX. If you already have RINEX logs from the receivers you can skip this step.

Using the RINEX directly from today’s flight, 5 missed time mark, but converting the UBX to RINEX and I magically have all my marks.

It’s really a shame, all this time lost modifying my drone , buying stuff to improve it, countless test for nothing, with my boss very mad a me, nearly losing my job. all that because of a software issue…

I’m sorry to here about your troubles. Anyhow I’m not sure whether the software bug is the single source of your problems.

In my case cycle slips are the source of the lost time marks. I work around those problems by machting images and time marks with an Python script. I interpolate the missing time marks from my Arducopter logs. Meanwhile I also do lever arm correction based on the Arducopter logs.

If that helps you I can send you a simple program to match the images and the time marks. But it is only working (the simple version) if youre camera supports subseconds in the exif tags or your capture interval is above 2.5 seconds.

Hi Benjamin,

Sorry for the delayed response.

We conducted several tests with UBX and RINEX logs recorded simultaneously on the Reach M+ device on the latest stable release. However, no matter which format of raw data we used, both *_event.pos files contained the same quantity of time marks in the result.

That’s why I don’t think that the format of raw data could influence the time marks missing somehow.

May I ask you to clarify some things so we can investigate deeper?

  • Which firmware version is installed on your Reach M+ device now?
  • Did you record logs both in RINEX and UBX format simultaneously and then tried to PPK both of them: RINEX recorded on Reach and RINEX converted from UBX?
  • Could you please share both these files (UBX and RINEX) so we can check them and try to process?


Hi Tatiana,

Please find below the RINEX and UBX files for two flights:


With flight 10 the number of pictures was 68 and for flight 12 it was 558, the UBX missed one mark during this flight because the camera was very overloaded due to very high wind on the way back and longer lens focal.

With the RINEX, I am missing about 10-20%

But sadly it’s not over, even with good amount of sat number and best SNR I can achieve, the accuracy is bad. I did a comparaison today with 2 PPK and 1 RTK ground survey using two Reach RS on the same 5 points, here are the results :

PPK2 base on tripod and rover using a 2m survey pole, :

The cuts in the signal is due to walking to the next point with the pole sideway.

RTK base was set as the guide, an accumulation time of 30 minutes, always waited for a fix and AR ration close to 999, the accuracy was off by 3 meters on altitude and more than 1 meter on X Y.

Maybe I am jinxed and I am the only one who can’t even get a meter accuracy.


Edit :

I’m understanding even less, it seems that using the rover obs with Kinematic CSRS-PPP gives me better results, at least when comparing to google satellite map, I don’t have anything else to compare to, or should I leave my base recording for 20 hours and then do a static CSRS-PPP to get an accurate reference point?

How was the base coordinates derived?

1 Like

You mean, how did I get the coordinate of the base ?

If so, I used average single with an accumulation time of 30 minutes

Hi Benjamin,

Thanks for sharing the data! We’ll check them.

Also, I’d like to point out that you won’t get the absolute base position while the base is calculating its coordinates in the Averaged Single mode.

To obtain absolute centimeter-level precision, your base should be averaged while it’s getting corrections from NTRIP and the solution is fixed.

You also can calculate the base position during PPK using RINEX data from a reference station located in the 30-40 km range.

As for PPP, please note that Reach RS+ is an L1 receiver, that’s why the position might be defined with accuracy in 30 cm approximately.

Hi Tatiana,

So if I am understanding correctly to get the best precision, with what I have here in Ivory Coast, I should use a known point or the canadian PPP service to set up a base, which in turn “using PPK” will find the accurate position of the next base if it’s within the range of 30-40km, then repeat until I am close to my mission location. Am I right?

Should I use the option, position mode static in RTKPOST or something else, if I want to correct another base using PPK?

So what if the drone is crossing two base footprint, how is it possible to merge the Rinex or UBX from them?

If I am just using a PPK base setup on an unknown location, start logging 5 min before flight, and then stop just after it, what kind of accuracy should I expect at best and average?

What about the new reach M2, will I be able to use the cinematic canadian PPP services, if I am ok with 50cm accuracy for X,Y and Z?


Edit :

Just received my PPP results

Should I use ITRF14 or A priori ? Also how can I be sure that this is accurate?

Hi Benjamin,

May I ask you to tell me a little more about your use-case? In some applications, you might not need the absolute accuracy, and the relative base position should be enough.

I’ll try to explain this in more detail.

When you place the base, it usually finds out its position by averaging in Single mode. After averaging, Reach knows its position with a few-meter accuracy.

As for the rover, it calculates its centimeter-precise position regarding the base position. So, even if rover coordinates are centimeter-accurate in regards to the base’s, they’ll be shifted on the same offset on which base is shifted from the real position on the Earth. Such accuracy is called relative accuracy.

However, if you know the coordinates of the point where the base is placed, you can enter it in manually. In that case, the base position is centimeter-precise regarding the real coordinates on the Earth. So you get absolute accuracy.

There are several ways how you can find out the absolute base position on RS+:

  • Manual. You can enter the base coordinates in ReachView in case it’s placed over a point with known position
  • Averaged fix. If the base is getting corrections from a reference station located in the range up to 10 km, it can find out the position in RTK
  • PPK. In this case, you need to get 2 RINEX files for post-processing: RINEX recorded on Reach RS+ and RINEX downloaded from the reference station placed in 30-40 km range
  • PPP. Please note that PPP with L1 receiver will not give you better horizontal accuracy than 15-30 cm

According to the PPP results you shared, accuracy estimation from latitude is 31 cm, longitude - 94 cm, and altitude - 92 cm.

ITRF14 position is the position you got as a result of PPP. A priori is the averaged single position from your RINEX file.

Could you please clarify how long have you been recording the RINEX log for PPP?

1 Like

Hi Tatiana,

Thanks for your explanations, it’s very detailed.

So in any case, I will have to use a known point to set my base on, or a correction from a base that is setup on a known point.

Makes me wonder, for example, the Here+ RTK base station claims to be able to reach absolute accuracy of less than 30cm in about one hour using averaged fix without reference station or known point, how can it be possible? I am quite sure now it’s part of the marketing.

The Last PPP test was about 6 hours long, I did another one yesterday about 9 hours long and the results were a bit better, I got 21cm, 76cm and 61cm. Tomorrow I will leave it for at least 24h.

I also found a company here, in Ivory Coast, that can give me a real time correction, their base is about 5km from my office and test ground. I will give it a go, but it’s a bit expensive about 70 USD per day.

I will update this topic, as soon as I have more results.


Edit :

  • Is it possible if I have a flight 200km away, to use my home base which is already corrected to correct a temp base using PPK, let’s call it base2, 30km away and then repeat, base2 correct base3 and so on, until I reach my flight area? Will I lose absolute accuracy on the last base doing that?

Hi Benjamin,

Returning to the initial issue, may I ask you to clarify the GNSS selection and update rate during these flights (flight 10 and flight 12)?

As for PPP tests, please keep us posted.

Yes, you can use such a workaround.

Hi Tatiana,

For all the flight i’ve been using GPS, Glonass and QZSS with an update rate of 5 Hz

Edit : Sorry to ask again but I really need clarification on that.

Makes me wonder, for example, the Here+ RTK base station claims to be able to reach absolute accuracy of less than 30cm in about one hour using averaged fix without reference station or known point, how can it be possible? I am quite sure now it’s part of the marketing.

Because I looked at the P4P RTK manual and video, and it’s the same, just setup, averaging single and you get very precise coordinates. So like the Here+, Is it fake and you only get relative accuracy, or is it using external correction like WAAS or EGNOS?

It’s really bothering me to not understand this.

A post was split to a new topic: PPK accuracy

Hi Benjamin,

I’m afraid I can’t be of much help in questions regarding 3rd-party receivers.

Also, we’ve checked the raw data, and I have a couple of additional questions. Could you please clarify what the ReachhView version was when you faced an issue with missing events? Which ReachView version do you use now?

Hi Tatiana,

I have experienced the issue using the last firmware on march 2019, I think it was 2.16, then the dev version, 2.17dev, not sure, then lastly on the 2.18.

I did not try on the 2.20

Hi Benjamin,

We fixed some issues with losing epochs in the latest dev update (v2.21.2), so I’d recommend checking if you experience the same issue on this firmware version or waiting for the stable release.

1 Like

A post was split to a new topic: GNSS selection for time mark logging for Reach M2

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