I subscribed to my local service Can-Net through Cansel. I am able to access their network, and select the correct mount point, etc. I also the grey bars showing the satellites picked up by the virtual base. On this end, it seems like I am connected to the network, and sending the corrections to the Reach RS though my phone.
Initially, I wanted to use Kinematic settings and log some points with a rover pole for the simple purpose of testing the reliability of establishing and maintaining a fix. After walking in circles, in a relatively open area for 10 minutes, I could not maintain a fix. I thus decided to set up a tripod and establish a Static position via NTRIP. The pictures below are the settings I used for this configuration. I should also mention I was able to achieve a fix, but could not replicate it. I will get into the settings I used shortly.
First I did not use any auto log settings.
RTK Settings generally looked like this on the instance I was able to get a reliable fix.
After logging a point in Fix-and-Hold, I switched to continuous to see if I could get a fix with the setting. I could not. I then switched back to fix and hold, but had no success maintaining a fix. I tried numerous settings, including using GPS only (which seemed to stop the NTRIP virtual base satellites from showing in my graph), and turning GLONASS AR on or off.
My AR ration struggled to stay above 3, where a fix seems to be established. If it made it over 5 or 6, it seemed to shoot up to the hundred very quickly. This occured in the instance I did maintain a fix.
So, I am at a loss as to why I was able to get a fix with the settings configured one way, and not able to replicate it with the same settings. I waited several minutes in an attempt to get the fix back with no luck.
I was able to log 3 points, 1 a fix, and 2 as float, the result being points that are separated by up to 1.5 m.
I’d like to know if my settings are wrong, or if there is some likely cause for inconsistency in finding a fix solution.
Also, I did not log raw files (forgot to switch it on, arg) so I cannot provide those of assessment.
First things first, I’d ask you to provide a system report, so I can see the full picture with the settings.
Second, how was the signal reception?
Third, I can see you have all GNSS disabled. The number of satellites you can see is the key to achieving a good solution. Try enabling all other allowed systems - Galileo and the rest.
Also, when working with a non-Reach base, you need to turn off the GLONASS AR.
The settings I posted were the recreation I made in ReachView when I returned to my office.
I will be provide a system report shortly, as for the other questions.
The signal reception was initially poor. I boosted the elevation mask to 25 and I had 15 or so satellites on the Reach and about the same on the NTRIP base. I don’t think reception was the issue.
GNSS settings shown were simply one configuration. I tried with GLONASS and Galelleio, with and without GLONASS AR turned on, but I will disable that and try again. If I disable the GLONASS AR, can I still use GLONASS, or should that constellation be switched off?
I had better luck today, but I am now facing some new questions and difficulties
I wanted to test the reliability of establishing a FIX using an NTRIP network for base correction., and compare difference in coordinates that I log. I hoped the separation would be minimal. My NTRI[P service provider is Cansel, which operates the Can-Net network. The intention was to test the reliability of establishing a FIX with the REACH RS mounted on a static tripod, and then using the same REACH RS on a rover pole. Throughout all my tests, I maintained connection with around 15 satellites.
Test 1: Static Tripod configuration was used first. I logged the position using Fix-and-Hold GPS AR mode, and then with Continuous GPS AR Mode. GLONASS AR mode was off in both configurations. The GNSS constellations utilized were GPS, GLONASS and SBAS. Update rate was 5hz in both configurations.
The image below demonstrated the settings used (with GPS AR mod later changed to Continuous):
Using Fix-and-Hold mode, I was able to establish a fix relatively quickly, and the AR Validation ratio quickly climbed to 999.9 I logged the static position 3 times when the AR validation ratio reached 999.9. The logging time as between 1 and 2 minutes for each sample.
Test 2: I switched to Continuous GPS AR Mode, while leaving the reach in the same position. With the exception of this setting, everything else was the same as the configuration in Test 1:
It took considerably longer to establish a fix while in Continuous mode, and the AR Validation ratio did not climb very much past 3. I was able to get a fix, but it did fall out a few times. I logged the position of the REACH RS twice. Each collection lasted between 1 and 2 minutes.
Test 3: Switched back to Fix-and-Hold, without moving the REACH RS. I again surveyed my Static tripod position for between 1 and two minutes. I performed this test in order to compare the first run of Fix-and-Hold points performed in Test 1 to those in Test 3, in order to understand the accuracy of a Fix-and-Hold solution. I hoped to see minimal difference in the recorded positions, given that they were taken at the same location.
Analysis: The difference between the two sets of Fix-and-Hold solutions is unacceptable. Pictured below are two clusters of points. The lower grouping includes the first series of Fix-and-Hold solutions, as well as the Continuous solutions. The upper pair are the second series of Fix-and-Hold (Test 3).
As shown, the difference between the clusters is about .5 m. This difference undermines my trust to perform NTRIP based RTK with the REACH RS in FIX and Hold mode, as I understand it at this point. Given that the location was static, I would expect the results to be much closer. While performing a Kinematic survey with a rover, would the accuracy not be further reduced especially if I am in more rugged terrain or an urban environment?
Next, I looked at the differences in the tighter cluster. The yellow points shown below are the Continuous fix solutions, which are at least close together, separated by only a few millimeters. The grouping of the Fix and hold is also only a few millimeters apart as well.
If these coordinates are reliable, than the spacing in encouraging to using Reach RS with NTRIP to establish a known location, or to survey points. To verify the accuracy, I will next perform this test over a monument with a known position.
Test 4: Kinematic Mode
I next attempted to test the Kinematic Positioning mode. I turned off the REACH RS, attached it to a survey pole, and rebooted and created a new job. I set Positioning to Kinematic and used Fix-and-hold GPS AR mode.
The terrain was quite open, but it is my understanding that Fix and Hold should be used in rugged terrain, or where multipath interference is likely. I hope to use this gear for agriculture purposes, where multipath interference will be present, so I sought to use the setting that seem to be recommended for my actual work conditions.
Now set up with a Rover, and having established a FIX, I surveyed the same spot where my Tripod had previously been set up. The results are seen below, wit the GREEN POINTS showing the supposed location I surveyed with the ROVER pole.
This is a full Metre from the position given it Continuous and Static mode, and near the same difference from the Second sample (Test 3) using Fix and Hold. Given that I want to use this system with Real Time corrections applied, these differences are discouraging. In my experience with other stand alone systems using a rover and NTRIP network to supply the base, I needed to calibrate myself on site. Granted, in this case I was using a local coordinate system and associated datum, rather than simply using the WGS84 information from the GNSS network that Reach RS, so I am not sure if calibration is something that can be forgone. Can-Sel provides an adequate summary of the process involved in calibration, which is basically what I followed by tying into local monuments. The system I used in that case gave me a real time position the local coordinate system, which I could see was off from the monument position until I performed an inverse solution based (I hope my explanation makes sense here, as I was shown how to do this in a n ad hoc manner)
Anyway, I would like to know if I am out to lunch on this stuff.
How do I improve consistency in my surveyed points?
What sort of tests can I perform to ensure the coordinates I log can be used as a base position in the future?
Is there perhaps a compatibility problem with the NTRIP provider and REACH RS?
How can I determine whether I can trust the results from Fix and Hold or Continuous (setting up over a monument is my next step).
Another day of tests (well, configuration attempts is more accurate) with my pair of Reach RS units, and another day of frustration. If anyone thinks they can offer some help and would like to see screen shots of the settings I used, please ask an I will post. I ran through a bunch of configurations so I don’t want to post everything up front.
I had several objectives today:
Use a Reach RS as a standalone rover with NTRIP (using paid subscription) to test NTRIP accuracy over previously surveyed point (PPP)
Test the reliability and accuracy using a Continuous Fix
Test the range of the radios with a Base Rover configuration
I wish I could report success, but each of these basic tests resulted in failure. There were a few components to each, so I will go through each step by step
1. Using Reach with NTRIP.
This should have been the simplest of things. I signed into my NTRIP account and was able to see the correction information coming through my Android device, but the Reach was unable to establish a Fix. The AR ratio did not want to crack. It remained in float expect for a few second jumps to fix. These units were unobstructed and damn close to each other. At this point, I’ve basically given up on using Reach with an NTRIP subscription. It is simply cost prohibitive if it does not offer a “grab and go’ option for me. Whether the problem lies with the Reach RS, compatibility issues with the NTRIP provider, or user error (the configuration options are pretty limited, so I am not banking on this being the case), I cannot say for sure. Bottom line is that it needs to be reliable, and it’s been anything but.
My intention was to connect to the NTRIP, establish a fix, and then survey a point I had collected raw log files over 4 hours the weekend prior and sent through NRCAN for PPP. This would have let me measure the accuracy of the PPP results and the accuracy of the NTRIP solution once I also tagged a known monument nearby. However, I could not perform the actual test part of my little experiment because of the calibration/NTRIP problems. This was very disheartening.
2. Testing reliability and repeatability of Continuous fix.
Like it was in previous days, an utter failure. I intended to at least gauge the accuracy of my PPP established position before moving onto this test but moved on anyway. I plugged the NRCAN PPP coordinate into the base with the intention of using the LoRa connection to send corrections to the rover. I would set out to the known monument, and record a point to gauge my accuracy real time. Seemed easy enough, but it was not to be. I was able to get the radios talking to each other, but I was not able to get a good AR ratio. I waited and waited and waited to establish a fix. I had a few blips and got excited for a second, but then the AR Ratio dropped back to 0. After realizing that things were not going to improve, I decided to set out to test the radio range, fix of not.
3. Testing the Radio Range. In real world conditions, ie some trees between the base and rover, I was limited to around 1km before I stopped getting a feed from the base. That is not the end of the world, and could surely be boosted by getting a taller tripod or pole, but I was hoping for more.
4. Finally, I decided to try getting a fix with Fix and Hold mode. It took a while, but I finally have it. Problem is that my tests so far with fix and hold mode have given me poor results, in the order of +1m difference in a static point. This was done using an NTRIP VBS. Thus, I do not trust this feature for RTK point recording at this point. Has anyone measured the accuracy of points record in fix and hold mode before any sort of post processing?
It seems that some people have been having success using the REACH RS as a reliable RTK tool. I simply can’t figure out why it’s been so unforgiving to me. I want to ask for help, but at this point I don’t know what question I should ask. I’ve tried different satellite constellations, different update rates, different combinations in the RTCM3 messages with different Air Data Rates, and NTRIP networks, and I don’t feel like I am getting anywhere. Every test I come up with is leading me further down the rabbit hole.
Having trouble getting the files to upload. I have the raw files in a ziz folder. It allows me to upload them in my message, but they do not appear when I hit submit.
Let’s start with Reach RS base and rover configuration. It should give you great results out of the box, once it works we can look into the NTRIP base setup.
Please make sure that GPS, Glonass and Galileo are enabled on both base and the rover. The appropriate RTCM3 messages need to be selected as well. From your log files in looks like you only had around 10 valid satellites, it should be more with all systems enabled. Do not set the masks to high values, 15 degrees is adequate.
I’ve played around with the RTCM3 messages, and deactivated many of them due to possible radio problems I was having a few months ago. I’ll keep in mind the elevation angle, but in this instance, I was getting intermittent satellite signals until I raised it to 25-30. There was not a whole bunch of possible interfering objects, but raising it seemed to provide better connection to the GNSS network.
I’ll try activating Galileo, as I usually switch that off.
Are there any other likely fixes or settings to apply?
I’ll have to post those tomorrow, as I do not have access to the equipment at the moment. I should also mention that I tried multiple configurations, so the settings may not be exactly as there were during my tests.
