Large height difference in one system compared to others

Reach RS / RS+ Getting started
1

Hello all!

This is another attempt at a post in a different section about the issues I’ve been having with one of 4 Reach RS+ that I’m using.

Having conducted a position verification over a known point (verified with a Leica system as well as 3 other Reach RS+), the height value for the final system wanders greatly over the space of 45 minutes, ranging from +30cm to -20cm between the observed point and the control point, but is always decreasing (there’s a large random step of 5cm after 20 minutes). This results in a large standard deviation of around 14cm, however the Lat and Long standard deviations are negligible. As I’m logging data for roughly 30 minutes to obtain a good dataset to work with, the height finally levels out aftter roughly 25 minutes. Strangely, when I do some processing in Excel with the .LLH file, the height actually averages out to within 3cm of the verified CP.

When starting up the systems, the 3 ‘good’ ones obtain in the region of 12-15 satellites immediately and most of them have a good signal to noise ratio in the status window - plenty to safely work with, whereas the system in question takes about 5 minutes to recognise more than 4. This figure does increase in time, however, the solution status never becomes fixed, which is the results that is needed and all them ‘seem’ to either be in either ‘float’ or ‘single’ when observing in status. Corrections are provided via NTRIP over 4G (through an iPhone) in all cases. Pole height is set to 2.0m plus the adaptor (2.0865m) and the mask is set to 15 degrees.

The way I’ve been connecting everything up is as follows:
Power up Reach
Connect laptop to Reach via wifi (then typing 192.168.42.1 to connect to ReachView)
Connect Reach to phone hotspot
Connect laptop to phone via hotspot
Connecting to Reach via browser (typing Reach IP address into browser)
Compared to booting up an ageing GX130+ (the menu is still in monochrome!), these systems are really good in the sense that you can almost “plug and play” with fairly little background experience or knowledge, however troubleshooting is a little harder due to the simplified interface.

My initial thoughts were the mask angle (as the CP is located behind 2 storey tin sheds), which I changed from 15 degrees to 35 degrees and had a bit of a test - no change. Also, as there are several SmartNet licenses to choose from, I’ve made sure that I’m using one which isn’t already in use. Corrections are definitely coming in and, as previously described, I have successfully verified the CP with 3 other RS+ and a Leica GX1230+. I’ve finally tried reflashing the Reach and performing a ‘factory reset’ which obviously doesn’t change the wireless settings, but I don’t think that’s the problem here. Obviously there was no change after this.

On closer analysis of the data that was collected in RTKLIB, the satellites are there and being recognised and there are 5 that are in ‘fix’ with a good SNR and no cycle slips however the height value just doesn’t match up unlike the other systems which give me SDs of less than 1cm and differences between the CP and the observed position of less than 4cm.

Log files to come!

2

Hi, do you have raw or log from this session you could share? And the corresponding correction data

3

Thanks for the reply, I’m currently working on downloading the system log, however I’m not sure where the session log will be stored as I logged raw base, solution and position data and didn’t create a survey job.

4

System Log can be found here

5

Just to make things clear before i run processing.
You have 4 RS+ units, but one of them is acting up with to much error?
All units run the same Reachview version?
You use the same NTRIP on all units?
Have you tested with a local base nearby?

oh, and system report doesnt contain recorded logs or raw files. Those are found here
https://docs.emlid.com/reachrs/common/reachview/logging/#logging

6

That’s correct we have 4 RS+ units, just one is acting up, everything is running the exact same firmware and software, same NTRIP account details however, I haven’t tried it on a local base as of yet.

I’m currently getting some more up-to-date data to prove that the problem still exists which will be finished in around 20 minutes, so once I have that, I’ll upload everything along with the recorded and raw log files for you.

Many Thanks!

Edit: I’ve just been monitoring the system whilst collecting data and I’ve noticed that regardless of the fact that it has 26-27 satellites and 5-6 of them are in ‘fix’, the solution status is still saying ‘single’. All satellites that aren’t in ‘fix’ have a really high SNR. The position is however not wandering like initially experienced, however the ellipsoidal height is still all over the place.

1 Like
7

As requested, here are the raw and solution logs:

8

Did you record ntrip data too?
Its needed to produce a solution from post processing.

9
10

As far as I can see, there may be an issue with the NTRIP corrections as on previous logging attempts, there has been a large amount of data whereas on this attempt, there is hardly any. I’m currently investigating as to why this is. Could there be any reason why the NTRIP server connection would timeout RS+ side? This may be the reason why the solution is stuck in single, not switching to fix?

Here’s a short clip of what I’m experiencing - it keeps dropping out for a second or two then coming back in for about 10 seconds or so.

11

Yes,there is no ntrip data recorded thus not able to process a solution.
You where able to use ntrip with the other RS+ units?
Is this a VRS service? if so, you need to tick Send NMEA GGA just above

Also, some non VRS service need to know your location as they would not allow service outside certain areas

13

I think this is where the problem lies :slight_smile:

This must have been unchecked when the reset occurred! What I can do in the meantime while I’m conducting this again is to send some data (with accompanying NTRIP data) from when I first encountered the original problem.

14

The position of the output solution looks good.

image
image.png1003×741 25.7 KB

Though the ntrip doesnt seems to process 100% smoothly.
This is where a base comes at hand. Set base to static and make a fixed known point and swap ntrip with your own local base that will provide you with more stable and rugged solution. IMHO

But if you rely on ntrip with a different base then your own, you might want to try a differente service or base. This one seemed not to be read 100% flawlessly in RTKlib for RTK missions.
At first glance its not processing all satellites but the good part with post processing, you can almost get everything to work with some tweeks.

Decent data from this log. Nothing wrong as i can see, but it might be bit picky ntrip service

image
image.png1140×752 17.2 KB

15

TB, many thanks for your reply and the results!

The intended use for our systems is so that they can be used to verify vessel headings with what other onboard systems are saying, so they need to be standalone as well as be independently verified on a known control point annually (which is currently what I’m attempting to do), however, we have always used Leica systems up until now and our 4 systems are a recent acquisition.

The reason for me using the LLH file is so that I can obtain the raw data (which needs to be good enough to use without post processing to within our own spec of <5cm difference), do averages of LLHs and standard deviations of the differences between average and raw points. As we set up one on the bow and one on the stern on known points, a baseline can be calculated between the two and thus the heading can be verified!

Back to the original problem, it seems weird that the NTRIP service would just be patchy on this one unit when it has been absolutely fine on the others?

16

Have you had repeatedly episodes with this reciver?
A complete set of raw/rinex logs from all four units during the same session with ntrip when the one fails would be a nice log to analyze.

18

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