That is not my experience and the root of my gripe.
It was using the base position from the downloaded RINEX file that created the offset I demonstrated earlier in this thread.
1 Like
@Simon_Allen Maybe I am missing the point here. Just for example, are you suggesting that if you connect Reach to an NTRIP service the resulting base position in base RINEX log file will not be the same as broadcasted by the NTRIP caster?
1 Like
There are a couple of use cases that are causing problems:
Usecase 1.
Set up base to start broadcasting after it has spent X minutes averaging a position
Once base is transmitting the new averaged position go out with a rover and collect point data and flyer to collect drone data. I use flyer to differentiate The rover is collecting RTK via LORA the flyer is PPK (but with corrections received over wifi to confirm everything prior to launch)
In this case the rover has a good fix and the realtime positions are good enough for control if I occupy each site for a short period.
I download the RINEX file directly from the Reach RS (software2.9.2) and if I use the RINEX Header position (because I am lazy and don’t want to type the position in) then I will get an offset.
Note: The rinex file is converted on the reach after the UBX file is closed and therefore the reach unit has available to it the averaged base position, but this does not appear to be the base position used. This leads to my error. Now identified this is a procedural thing that involves writing numbers (the base location from averaging) on a piece of paper and using these numbers explicitly in post processing. Not a problem, but not a joined up process.
Usecase 2
@Rohit_Ramesh
Explicitly entered a base position into the reach and (I assume) expected these values to be stored in the onboard RINEX file so that they would be used in post processing but it appears (again) that the RINEX file generated when the UBX file is closed does not use this information but generates a different position for the base.
So his problem is the same, but slightly different.
My suggestion is that there be a priority cascade for the base position in the RINEX header for rinex files created onboard the reach. 1) Has the base position been entered manually? Yes . Use this. 2) Has an average base position been calculated? Yes. Use this. 3) No information on base position. Yes. Use last good fix.
1 Like
I understand this part, I was just suggesting that averaged base position is actually getting recorded on the rover side.
2 Likes
With the 2.9.3 update I accidently selected ntrip when I had meant to do a tcpip connection for correction input. Now the device UI for correction input spins endlessly and I can’t change the correction input. Any ETA on a fix for this?
1 Like
That is an old bug, I am also very interested in a solution, fix or workaround 
1 Like
Yes, I also have experienced this behaviour. For me a reset of refreshing the browser or turning corrections on or off has usually been by workaround, but, in general, I have seen some inconsistent behaviour on this page, specifically under NTRIP settings.
1 Like
Thank you for reporting the issue!
Could you please let us know the steps to reproduce it?
Was your unit connected to internet at that moment or was it in hotspot mode?
1 Like
For me, was having an @ symbol in the NTRIP username.
1 Like
Hi!
Unfortunately, this error happens with only certain casters. If you could PM me the details on the one you use, we could investigate. Meanwhile, to get out of this, you can reset the settings to default in the gear tab.
@Amilcar_Lucas we are currently revisiting our settings as a whole, so a fix for this will be included. For now, the @:/ symbols are forbidded in both usernames and passwords.
1 Like
My unit was in hotspot mode and also the address was rtk2go. I have noticed also that sometimes I get dropdown menu for choosing mount point but usually not. I haven’t tried it yet on 2.9.3.
1 Like
The base offset from input in reachview to view position in rtkplot, i tried to reproduce the offset but failed.
I used rinex 3.03 logging for rover and base and output in rtkplot shows base coordinates spot on.
1 Like
I am still not able to get these offset you guys are talking about. I am probably doing something wrong or right.
This time i used average base position. Rinex log 3.03 for base and rover ( i saved both on rover) or should i use rinex saved on base?
First pictures of base with coordinates used.
And final, RTKpost and plot view with dead on coordinates.
2 Likes
Use the Rinex saved on base.
Had it explained to me. The Rinex saved on the rover ( of base observations) will have the averaged position in it. But I use the Rinex saved directly on the base as my comms between base and rover are spotty, hence PPK. The base RINEX does not have the averaged position in the header.
3 Likes