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.
Cheers
Ed
Hi @TB_RTK,
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?
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.
