Reach RS - No Fixed Solution, Strange Float Solution

Reach RS / RS+ RTK / PPK configuration
1

Hello,

I recently received two Reach RS units, and have been testing them out. I have found it impossible to get a fixed solution in RTK mode, only float. Furthermore, the float solution is very bad. For instance, standing outside with a clear view of the sky, I had the base and rover units within a few meters of each other, yet monitoring the rover, my indicated position moved steadily further away from the base, until it indicated I had moved over 100 meters away! By comparison, the single solution using just the rover seemed to be much more accurate.

I was able to post-process the data, and the results looked very good. I have attached a screenshot from RTKPLOT showing the post-processed fixed solution, as well as the float solution generated in the field.

FixedVsFloat_edit.jpg1920×958 755 KB

As you can see, the float solution is more or less garbage, completely offset and misshapen compared to the post-processed fixed solution. Also note the significant deviation to the south of the base position. None of this happened in reality.

I am attempting to use the LoRa radios to communicate between the units. Left the frequency at default 868 Mhz. Output power at 20 dBm, and air data rate was 9.11 kB/s.

I have mostly kept the default settings on the devices, and I am running ReachView v2.2.7. Not sure how to determine firmware, I am a total noob to these devices, and RTK in general unfortunately. If it helps I can provide other settings as well, I’m not sure if there is a way to post all settings easily or not.

Here is a dropbox link with my raw log files from base and rover: Dropbox - Error - Simplify your life

Not sure if I can provide anything else that would help. If I can, please let me know. Sorry about my lack of knowledge on these matters. I really have been trying to do my due dilligence by searching the forum for similar issues, and searching the documentation, but I haven’t solved the issue and was hoping someone could lend me a hand.

Thank you,

Gordon

2

Hi Gordon,

Could you please also upload the original solution file that you have collected in RTK?

3

Sure, I have placed it in that same dropbox link.

4

Not clear yet :slight_smile: Could you please also upload a log of incoming corrections from the rover unit? Also screenshots of base mode tab from the base would be helpful. How did you set coordinate for the base?

5

Hi sorry I am not at my desk currently. I will for sure post those files later on and will let you know how I set the coordinates. Thanks for your prompt responses on this.

Gordon

6

I can say that the base coordinate was set to average single with 2 minutes for averaging, as it was for default.

7

Gordon,

The real-time solution is really strange and considering that post-processed one is really good I am confident that we will get to the bottom of this issue.

Which RTCM3 messages did you select on the base? If you do not recall, I can just find it out from the corrections logs once you upload them.

8

Hi,
I know I may be imagining this, but for what it is worth, it seems to me that about every second change in version, I can’t seem to get ReachView fix in realtime. I can watch the float and the old problems are all gone, but it does not seem to want to converge to FIX. RTKPOST seems to work with each new version. Is it possible to have a good and bad module somewhere? For now, I do most work in RTKPOST, so I just wait for the next version.

9

Sorry I didn’t get a chance to upload the correction logs, I will do so first thing tomorrow morning, as well as a screenshot of the base configuration.

10

Hmmm. That seems very odd. That would be disappointing if one is forced to just wait for updates for the devices to work properly. I am hopeful that my issues can be resolved. For the most part being able to post-process is enough, but if for instance I need to return to a previously measured location, then having a fixed RTK solution would be very helpful.

11

Nevermind I managed to get my remote desktop connection to my work PC to function finally, and put the correction logs in that same Dropbox folder! Will post configuration screenshot tomorrow.

12

Screenshots of base configuration:

Screenshot_20170407-120256.png1440×2560 162 KB

Screenshot_20170407-120318.png1440×2560 194 KB

Screenshot_20170407-120324.png1440×2560 168 KB

13

Hi Gordon,

After looking at your logs I can see that the base is getting heavy Glonass interference, which is not the case with the rover. Could you please try again, but relocate the base or disable Glonass just for the debugging purpose. We will look into improving how this situation is handled. Thank you!

14

Hi Igor,

Sorry it has taken me so long to get to this. I went out and tested things using just GPS. I set base and rover nearby eachother and didn’t move either of them. I ran two tests using different antenna air rates (9.11 kB/s which I had been using before, and 2.6 kB/s). Still using 868 MHz for the frequency.

I have uploaded my results to Dropbox. First test is found here: Dropbox - Error

Second test is found here: Dropbox - Error - Simplify your life

I was still unable to get a fixed solution. With that said, the float solution was more reasonable this time, though still showed the rover wandering around for a while, even though it was stationary.

Any help you can offer on this is appreciated. I am hoping we can get this working, as the utility of the units for us is currently compromised with it only functioning for post-processed logs.

Thank you,

Gordon

15

Just tried again. This time I copied the settings used in this video linked in another post: RTK Survey with Reach RS, Lefebure and Mobile Topographer Pro - YouTube

The main settings I changed involved reducing the antenna output power to 6 dBs, and changing the frequency to 868.1 MHz. Of the two, I think the output power made the difference, though I can’t be sure. I also re-enabled Glonass.

Either way, I managed to get a fixed solution! I then walked around my building at work, and the fix maintained until the building was between me and the base, as might be expected. I still had a float solution, however. I returned to the base station, but the float solution maintained, without returning to fix. I went into the rover correction input menu, disabled base corrections, then re enabled. After a little bit, it returned to a fixed solution.

So this is definitely an improvement. I am not sure why changing the antenna power made a difference. My concerns are the following: with such a low output power, should I be concerned about not having RTK over even fairly short base lines? Secondly, the fact I seemingly had to disable and re-enable base corrections to get back to a fixed solution…is this typical and to be expected?

Thanks for your help on this. We seem to be making progress.

Gordon

16

if the radio is interfering with your satellite signal, then you should look at your ground plane and where your antennas are in relation to one another. do you have a picture of your setup?

if you can’t regain fix, then is your RTK mode set to Static? It should be set to Kinematic if you are walking around with it.

17

Did somebody manage to open rover_solution.ERB file? I did not

18

I don’t have any pictures, no. I will take a pic the next time I test it out. But I am using a survey tripod for the base and a survey pole for the rover. Pretty standard stuff. RTK was set to kinematic on the rover. I set the base to static.

19

No apparently that format is for interfacing with Ardupilot and can’t be opened properly in RTK Plot or anything. Didn’t realize that at the time, and unfortunately that is the default format. I have since changed the solution file format.

20

OK, I was thinking Reach module and external radio, but you have the RS, my mistake. And you’re set to Kinematic. That’s all I can think of at the moment. Good luck with the next trial.