Data collected on DJI Phantom 4 carrying Reach in cradle and sychronising image capture with Reach events.
RTK on left using the auto setup of base after 5 mins
PPK on right using RinexHeader station position
Short term fix for me is to establish base, write down the values (good practise anyway) and then use these in post processing rahter than the rinex header position.
Having trouble losing fix! Please help 
I have not been having the same trouble so many have experienced since the last update. On the contrary, by following the settings posted above for LoRa radio I have been surprised how robust the fix has been even when I thought it wouldn’t hold. It has held through quick movements, tilts, and some foliage. Well done and keep it up!
I had a similar offset issue when using the RinexHeader after auto setting up base position and have been writing them down manually ever since to avoid it. A little frustrating but restarting the base log with the established position set may put the right base coordinates in the RinexHeader, but I’ll be sticking to manual for now.
Thanks Sam for confirming this, and the workaround.
@egor.fedorov can you confirm you are looking into this one? It is pretty major!
Simon
What RTKpost/conv version are you guys running?
Is this basically rinex base coordinates beeing offset from manual entered?
Edit: Also, is the coordinates differente or is just the entire log shifted?
Edit:2 ok, final question, how accurate is the coordinates specified?, (number of digits)
I think we could compare the offset seen above to this:
None of us would expect those two position files to line up, unless we recorded the first average coordinate, and then entered it manually for the second run.
In older versions ReachView, we were forced to specify a base coordinate for RTK work.
Now, we have the option of averaging the current base position over time.
By deciding to use the averaging feature, the base coordinate that is produced must be recorded in some fashion for the sake of repeatability. Either you must commit to writing it down, or you could extract it from the rover’s RTCM3 log file (message 1006, ARP station coordinate), or you could get it from the header of your rover’s .pos position file.
I had a quick peek at the RTKLIB source, and when converting to RINEX, it just looks at the first valid position(s) and saves that as the approximate location in the .obs header. RTKLIB documentation also refers to it as ‘approximate’:
the RTKPOST docs:
the RTKPLOT docs:
Maybe you could ask for another base mode option: Mimic RTKLIB approx position.
This will not be as good as averaging over time. But maybe it is better that way because we should be careful not to ask Emlid to mess with the underlying RTKLIB unless it is absolutely necessary.
(I am open to corrections if I have made any mistake here.)
Sorry, I disagree strongly about bug status.
I should be able to ‘expect’ that when I calculate an average position that that is the position that is inserted into the Rinex header. Otherwise why bother having an automated position averaging featur. If I have to manually transfer the coordinates out of reach to use them in any form of post processing. Then I would rather do the whole process manually. There is a mismatch here in the simplified workflow.
If I am exporting RINEX files generated from within the Reach unit having determined an average position for my base within the same unit, prior to the output of corrections. Why would that Rinex file contain a different location? This is remembering that the Rinex file is generated when the raw UBX file is closed, so after the base position has been determined.
@bide “I had a quick peek at the RTKLIB source, and when converting to RINEX, it just looks at the first valid position(s) and saves that as the approximate location in the .obs header” That explains what is happening. Thanks. Again what is the point of averaging the base? might as well use the first valid position, at least it would be consistent with the RINEX data created inside the same device.
From now on I will use Survey to collect the data for the point, then I will have a record that is not obliterated the second I turn my machine on again. So you might as well delete the automated base station creation part UNLESS you are going to do something useful with the data like insert it into the RINEX header.
Is it possible to update Reach to a specified version (e.g. 2.8.0)? Regarding the comments here I am quite unsure if I should update to 2.9.2
@Simon_Allen We are looking into this.
@MichaelEFlip Unfortunately, no way to do this. But I do not see a major problem as well. As long as you don’t use QZSS corrections, you’ll have much better results compared to any previous version we have released. The RINEX head position behavior hasn’t changed for a while now, so you won’t lose anything by upgrading.
I would highly recommend upgrading to v2.9.2. I have noticed a big improvement in performance. This is despite the fact that QZSS is not working.
Hmm. So if you are using RINEX files created by Reach, then I see your point and maybe that is a bug.
But if you are using raw logs (UBX files), and converting them with rtkconv.exe or convbin, then I stand by my opinion.
Then again, I have always done the raw log conversion myself, so maybe it was silly of me to assume that everyone was doing the same thing. Apologies.
@MichaelEFlip I echo @BenLewis now that the problem has been defined as how QZSS is handled and can be mitigated, by not using QZSS I am finding 2.9.2 excellent.
This problem of base position handling is there in 2.8.0 and can be handled procedurally.
It will absolutely catch a lot of casual users out, and as the price of Emlid’s units is encouraging many non survey people to dip their toes into RTK/PPK it needs to be resolved. I accept it is not a bug per se, but it is a systems/ procedures/expectations mismatch that will not be caught in many methods of use and lead to results with poor integrity and no audit trail.
At the very least the raw LLH log generated needs to contain the base coordinates used at the time it is generated.
The position in the RINEX header is not really intended for this purpose. At the moment, it is, in fact, last approximate position of the receiver, just as the header says.
However, I understand the use case you are talking about. And it would make the whole thing a more integrated solution. However, that would imply some inconsistencies. For example, a rover, configured as an automatic single base would have something completely random in the header, as opposed to last known position.
I feel like the workflow you are talking about is inspired by ReachView. That makes happy, of course. But since this takes a different view on the principle of RINEX generation, I don’t feel like this is such an obvious thing to do.
I think, eventually, we will come to something like this, but it will require some time.
I have manually entered the LLH values for the base.
When I process using RTKPOST_emlid_b27, I get a slightly different ref pos. Is this the same issue @Simon_Allen has referred to?
It is related, but different. I have ‘thought’ I had seen this behaviour, but never had the evidence to show it.
Good Job!
@Simon_Allen Thanks for the confirmation. I have had the same issue even when I am using “Average Single” mode. The coordinates on the app and in the .pos (ref pos) does not match. I am assuming this is the issue that you have described above.
I have had it explained to me.
Quite simply you should never use the ‘approximate position’ in the RINEX header, you should always explicitly enter the station coordinates on the ‘positions’ tab of options.
The current internal reach method for the creation of RINEX files is consistent with RTKLIB, but not consistent with the workflow and implied use of data within the reach unit itself. Basically there is no point creating a base using the average position function. You are better off using the survey function to create a point called base, then inputting these coordinates manually both into the base position in the reach and the base position in RTKpost. This is the only way that you can assured that you are working with the same numbers and having them recorded somewhere.
Putting it another way. The base position created using the average function is not used downstream or recorded anywhere (unless you write it down) It is not transferred to the RINEX files which use the last computed position as the approximate base position. So if you collect points in the field using the average base position they will never match anything else unless you manually enter that position into RTKpost and use it as your base station position.
My i add that @Rohit_Ramesh is getting offset even though he manual enter coordinates for base.
So somewhat related but not identical.
This is not completely true. If you download RINEX log file for the base from the rover it will have the actually used base position from RTCM3.
A small, but important fix is out, check out the updated first post.
