While I was preparing for performing some additional tests, I reread this thread and took another look at the data.
What I’ve learned: (apart from using the emlid-RTKLib to avoid cycle slips all over the place…)
There was definitely a problem with the transport of the RTCM-stream (was provided over 4G->iPhoneHotspot->wifi->RS2). There are multiple shorter/longer delays in the correction stream.
I noticed the cycle slips were concentrated on specific periods over different satellites (worst from 16:44-17:00), so I checked where the driver was working at that moment, and it looks like he was close to an embankment with a long row of trees (which still had lot’s of leaves in august), all sats with cycle-slips were either very low on the horizon and/or somewhere between south and east.
Only G04 was very high during this period, but the minute of start/stop of cycle slips perfectly lines up with the machine driving very near the embankment with high trees…
Also it looks like most of the satellites were in a good position to play hide’n’seek.
About the lower Galileo SNR, I can see that E19 wat at its highest elevation when it was ‘under the embarkment-trees’, with a cycle slip every now and then. But when sky was open again, SNR remained just above 40. Any reason why galileo would have a lower SNR that others? Since it’s the same frequency/receiver/environment, I would expect a similar SNR.
Are you able to get this in another way for post-processing maybe ?
I can testament to this, even for a static receiver, you will see cycle-slips, which will cause one of 2 things: loss of lock (=float) or a fixed solution with a large StDev.
It was a VRS-stream, so the exact data won’t be available. While writing the previous post, I also checked on the website of the provider for the nearest base, but it’s too long ago, I couldn’t download them any more. I can try to find some other source of observation data, a quick search gave me data of a base ca50km away, but only provides 30sec samples for this date, I guess that won’t be good enough. (anyone knows publicly available sources of data? location was near Antwerp on the border of Belgium/Netherlands)
From the LLH log, it looks like the RS2 is always returning 0.01 for ‘sdn(m) sde(m) sdu(m)’ as soon as it’s Q=Fix.
It’s still fascinating how the RS2’s real-time positioning is outperforming RTKLib (in suboptimal environments). I guess it’s mainly due to better handling of cycle slips.
Thanks for your patience and for keeping us updated on your findings!
Hopefully, it’ll be possible to run some additional tests with a tweaked setup. Meanwhile, I just wanted to share some comments below.
The delays in receiving the corrections are usually caused by issues with Internet connectivity. Without the missing parts of the log, I’m afraid it’ll be impossible to post-process the data set fully. I’ve checked the available data providers for the region you mentioned and, unfortunately, it looks like the majority of them share the data in real-time only.
A cycle slip indicates the short loss of the signal from the satellite. As Artem has mentioned before, the big amount of cycle clips shows that there are prominent obstacles to the signal around the unit.
Improper placement, complicated hardware setup with RF noise around the unit, vibrations, the position of a satellite close to the horizon so that the signal has to go through more atmospheric interruptions - all of these affect the number of cycle slips appearing in the logs and reducing the quality of the observations.
So it looks logical that the cycle slips appear from the satellites close to the horizon or when the environment conditions increase the obtacles for the signal.
It’s hard to specify a single reason for it. Each satellite constellation transmits the signal with a different power from a differnet position and height in the sky. As these factors vary for each system during the survey, the observational quality of each satellite’s signal is going to be different.
Thanks for the update, since the bulk of the cycle slips could be explained, I postponed the additional tests. The realtime-algorithms seem to handle the slips pretty good…
Logging of raw data/solution/RTCM are on, I meanwhile asked the user to report the times when he gets suspicious positions, so I can investigate more in detail if it happens again. A first report was due to missing correction data, probably the mobile data connection got lost.
About tracking/signal quality I was also advised to take a look at the carrier-to-noise density (C/N).
I still need to perform some research so I can understand how to interprete the data. But is this measurement somewhere availlable for the RS2 (and/or reach modules)? Is it also present in the raw data by default?
Please, share the data with us in case of further issues.
Reach receivers don’t provide such measurements straight away. Signal quality can be assessed by the SNR values. As mentioned in our guide, SNR above 40 is considered good for the surveying.
The solution status shown in the ReachView app will be Fix only if enough satellites with good signal quality are in view on both base and rover simultaneously. When the quality is inappropriate, the receiver will indicate it by a different solution status.
