Hello Emlid Forum people,

This is a request for some help. I completed a survey the other week in a fairly narrow river valley with a lot of over hanging trees etc.
I have tried processing this data uncountable times with RTKPOST (up to date - downloaded Apr 18) using both another reach unit set up over a known location, and using a CORS station, both with incremental changes to all settings I am happy to play with:
Filter Type
Elev Mask (0 to 45)
Elev Mask SNR
Int Amb Res (Fix/Hold, Cont, Inst))
I even had a play with Min Fix Sats / Min Hold Sats (not so confident).

While fixes have been achieved in patches, I don’t believe a scrap of the data as the elevations are not consistent enough (i.e. rover on almost fixed height platform on a relatively fixed plane (water)).
I believe that because of the poor sky view at times (I ended up under a tree or two), and the crappy data associated with these times, the rest of the data is getting thrown out…way out.
Tried doing small sections in the open where I previously failed to get a fix - no luck

ReachRS units should be up to date

Please find a zipfile with relevant files here:

The .ubx files in “rover” and “base” folders, the CORS station data is in “hamt”; in this folder there are the obs/nav files from the cors, but also some converted to rinex 3 with just L1 data:

Would be stoked if anyone could shed some light on the situation; or at least tell me I have no chance.

Not sure what you`re doing, but looks fun.

Are you looking for mulitple points or could you point to where you need fixed area?


It is fun, when the data behaves.
I need the whole lot - except for the transit before and after the survey (but those points fix quite well anyway).
Any ideas?

I dont think its possible to get the entire run fixed from one process, but process them seperatly before merging them together. It would be alot of work though

Mmmmmmm. Yes, I tried a few bits here and there, no luck. Essentially, I think this is at the far end of a low cost receiver’s capability. Thanks for your input though @TB_RTK.
On a side note, I saw a post you commented on about how RTKPOST fails to recognize a manually entered ref pos (in the .pos out file). Do you know if this ever got sorted?

This issue?

Partially related. Lots going on in that thread.
I just cheked for an update here:

Ah, they released a new lib version not so long ago. Not sure this bug was fixed though

and here

That’s not it, running the latest (2.4.3 b28).
It really is a weird one how regardless of entering a manual base location in RTKPOST the .pos file spat out has a different %ref pos (assumed from averaging or else). Yet if I take this %ref pos and subtract what I know is the real base location, then apply that to a processed set of data over another known location I get a great xyz comparison…
Ultimately, RTKPOST does not recognize a manually inputted base location.
I also had a play at editing the ECEF pos in the bases .obs file to see if I could convince it using the header information. That did not go so well.

And this?

Yup, exactly.

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