Need Help using Reach RS as Base for non-Reach Rover

Reach Module / M+ / M2 RTK / PPK configuration
1

Background

We have 2 Reach RS (not plus) units which we have tested under various circumstances. The Reach RSes are updated to the latest version prior to every test, currently v2.11.0.

Scenario 1 - Tested Reach RS as a Rover receiving RTCM 3.1 corrections via WiFi hot spot from a fixed based station with an Arrow Gold and Hemisphere A45 antenna. This worked.

Scenario 2 - Test both Reach RS units, one serving as a base and the other as a rover. Correction data sent via LoRa from unit to unit. This worked with best results achieved when manually registering the base over a known reference point or when using the RTK Fix average function to register the base.

Now we are testing Scenario 3, using the Reach RS unit’s as a base station for other rover units. We cannot get this to work so far. The rover units will not computer an RTK Float or Fix solution but rather remain in Single (GPGGA 1) or Differential (GPGGA 2) solution.

Attempt 1 - Using an Eos Arrow Gold as the rover transmitting RTCM from the Reach Base via TCP. The Reach base and Tablet PC are bother connected to the same hot spot. The Gold is connected to the PC via Bluetooth or USB (same result on both) and the correction is transmitted to the Gold via software provided by Eos which has worked for us with other base stations. The Eos Arrow Gold does not compute a Float or Fix solution.

Attempt 2 - Using a RTKITE GGR2T as a rover. Again the RTCM corrections are transmitted from the Reach Base to the Tablet PC via TCP over WiFi hot spot. Then RTK STRSVR is used to forward the RTCM from the TCP Client to the USB serial connection to the RTKITE. NMEA results are sent from the RTKITE to the PC via Bluetooth. The RTKITE does not computer a Float or Fix solution. An LED on the RTKITE does indicate that unit is receiving the correction.

Question

Has anyone successfully used a Reach RS as a base for a non-reach rover? Any details you can provided on how you did it would be really helpful.

1 Like
3

Thomas,

I can only talk about using tractors (successfully tried John Deere GS4 with a Deere receiver and Fendt Varioguide with Topcon AGI-4 receiver) as rovers and it works like a charm.

This said however, I’m streaming from the base to an NTRIP caster first and the tractors are connecting to the caster.

Have you consider trying to set your base to send correction to a NTRIP caster (SNIP is free and will easily do the job) and connect your rovers to it?

Just my 2 cents…

Pierre

2 Likes
5

Pierre,

Thanks for the reply. I don’t believe that setting up an NTRIP caster is an option for us. We are testing a mobile base scenario where the base unit might be taken from site to site and serve as a base for that job site for some length of time before moving on. One of the reason for to do that might be the absence of wide area network availability. So no available connections to a CORS type fixed RTK base. A great use case for the Reach RS!! We establish a local wireless network via a WiFi hotspot and simply cast from the Reach as RTCM3 as TCP.

Also, in my experience with our own fixed RTK base station (not a Reach), there is no difference in the format or content of RTCM3 messages when sent via NTRIP as opposed to TCP Server protocols. In my understanding NTRIP is a communication protocol packaging HTML Request/Response and Security Authentication technologies, it does not necessarily alter the RTCM3 content.

Do you know is your SNIP set up to translate, convert or alter messages in any way? For example, maybe it repackages an RTCM3 1002 (L1 band only GPS) into a 1004 (Multi-band GPS) message which might be more compatible with the rovers RTK solution engine?

6

More data, we repeated the testing with a Navcom SF-3040. It did not work. The RTK Led blinked Green indicating it is receiving RTK correction messages but LED never became solid indicating a Fix solution.

Also, in examining the NMEA output the GNGGA message fix solution was 1. If it were unconnected from RTK solution it would use SBAS correction and provide a DGPS solution of 2. So the NMEA 1 fix is further confirmation that the rover unit did receive RTK input. However, the NMEA messages never showed an RTK Float 5 or Fix 4. My assumption is that it’s internal RTK engine was attempting, but not able to use the incomming RTCM3 messages.

7

Pierre,

Another question; Can you share with me the software version of your Reach base and the setting you are using on the Reach Base Mode screen?

Thanks!

8

Hi Thomas,

You start getting me worried… I did an attempt yesterday on my 2.11.0 base (through SNIP as a Caster) and I end up with the same problem as yours; while I’m 100% sure I had it working fine last year during an test.
The rover (Topcon AGI-4) is acquiring the data, showing the right distance to the base but never gets a cm accuracy.

Since I also used to proxy data from a L1+L2 with my Caster, I’m wondering if I was not on that mountpoint. To make things more confusing, SNIP can proxy under the same mountpoint as one coming from a NTRIP Server (in this case, my reach base); what it does is incrementing the mountpoint name of the Server.
Let me make some further tests and get back to you.

Regarding your point about NTRIP and TCP, I don’t have much details.
Looking at a sniffer trace when my base (Reach, NTRIP Server) connects to my Caster, I can definitely see the mountpoint’s password into the headers but the rest is pure hexa.
I don’t believe you will manage to translate 1002 messages into 1004; this said if the rover purely expects 1004, it might be what’s causing what we see.

Would have to dig the NTRIP protocol a bit more and eventually see if we can find a packet analyzer to read them.

Pierre

9

Btw - http://www.wsrn3.org/CONTENT/Reference/Reference_NTRIP-V1-Tech-paper.pdf is exactly describing what I see in my sniffer traces.

10

Hi Pierre

I’ve just tried here with a Reach RS setup, running 2.11.0 as a base sending RTCM3 corrections out via serial port and UHF radio and with a Fendt/Topcon AGI-4 receiver as the rover. Although radio connection status is good and showing 0/1 second delay, there is no RTK fix. The best accuracy the VarioGuide receiver shows is 1.34m

With the same Reach RS and radio acting as a rover and receiving inbound RTCM3 corrections from my fixed base works fine and I can get a fix. NTRIP from the same base also works well with the Reach RS as rover.

11

That’s exactly what I ran into Yesterday, 1.xx meters accuracy. I believe when I tested this before, my proxy had taken over and SNIP was casting these data :frowning:

On a side topic with the AGI-4 and Varioguide (using a working RTK base), do you also have the following issues?

  1. Offsets on tracks are not recorded so if you switch wayline, you have to re-apply the offset.
  2. Doing an offset on a curve is not working fine. Depending on when you are on the curve, you’ll get a different offset. So if for instance you have a curve that goes straight then turns like a circle; if you apply the offset during the straight section, everything shifts as expected. If you apply the offset on the circle side of the curve, the offset is only apply right at the point where you apply it. Other sections of the curve will get a different and wrong offset.
12

I’ve not noticed the offset errors, but I’ve also not specifically tried what you are attempting also.

What software version are you running on VarioGuide? There was a new EOL release in March for compound 783. I’ve not been upgraded yet, but an acquaintance has sent me the release notes. I can share that with you over on TFF.

13

I would love to have these release notes… I’m on 782 (the one that introduced the shortcuts on the navigation page - 781 had it but had issues acquiring tracks)

The offset errors are very obvious if you encode a curved field with for instance a 3m implement. Then if you go with a 7.5m implement and performs the offset, you will start losing the field edge when the cap changes…

I’ve re-tested proxying a 1004 message through SNIP and also serving a 1002 coming from my Reach using the same mountpoint name. The proxy wins it and my reach gets a _01 following the mountpoint. I can only think of that which faked my results before where it was working fine… (I was also testing with GS4!).

14

Pierre,

I’ve had the “it worked before and now it doesn’t” experience also on other issues. Not sure if this applies to you but here are some examples.

Case A: Some RTK receivers like the EOS Arrow line, Hemisphere chipsets, Geneq line and others have a “Tree Canopy” mode or “Forrest Mode” which allows the rover to cache RTK corrections from either a ground based CORS or a SBAS RTK service like StarFire for 10, 20 or more minutes. This is so you can pull the data heavy RTK corrections and ephemerides outside of the canopy in good signal area and then enter the tree canopy with cached data and all you need from the Satellites at that point are the ranging data which is easier to acquire. Of course as the cached data ages it does impact the quality of the position estimate.

So what can happen is if you boot the system under a certain correction source, then you switch correction sources to another RTK base station or something. The other RTK base station can be bad, but the data output from the Rover looks good. This is because the rover is feeding the cached data into the RTK engine in the absence of useable data from the other base station.

Case B: This is an issue I’ve reported on this forum. In the desktop version of RTKLib (both 2.4.2x and 2.43x) the rtknavi.ini file with cache satellite ephemerous data at the bottom. Here is an example,

[navi]
eph_00=G01,96,96,1,0,1533218400,1533218400,1533211991,2.65602364404307E+07,8.04775475990027E-03,9.72076025131128E-01,2.40643041238872E+00,6.72455937163245E-01,-4.44332927449940E-02,4.68305221077906E-09,-8.41249327125458E-09,-4.53590322429027E-11,3.02843750000000E+02,-5.46875000000000E+00,-2.30967998504639E-07,4.08478081226349E-06,4.84287738800049E-08,7.26431608200073E-08,3.96000000000000E+05,4.00000000000000E+00,-7.21234828233719E-05,-3.97903932025656E-12,0.00000000000000E+00,5.58793544769287E-09,1,0,

If you connect to a source out file in RTKNAVI which lacks good ephemerous data the RTK engine will re-use the rtknavi.ini data. Which could be really old and cause precise looking results that are really inaccurate.

We’ve added some rigor to our testing process to ensure our testing is done under the correction operating modes and that the RTK engine data is not coming from an inappropriate cache.

1 Like
15

Regarding RTCM 1002 vs 1004, I had a very small suspicion that the newer rovers I tested maybe do not play well with 1002. So that is why I pulled the SF-3040 out of the storage closet, it’s probably 6-8 years old. And the documentation does confirm compatibility with messages 1001-1012. But as I posted it had identical result to the newer units.

As another piece of data, the Reach RS works as a rover with our Hemisphere chipset driven RTK base station. However, it works MUCH MUCH better with a second Reach RS as a base. The Fix times are shorter and once we get a Fix it is more stable, even with GLONAS AR turned off.

I wonder if the Reach RS is not reading and transmitting 100% RTCM compatible messages. There could be a small bug in the translator. I assume Reach RS is using RTKLIB to convert the UBX message from the uBlox chip into RTCM. This could be an RTKLIB bug in fact because I have confirmed that I can record RTCM base correction data from the Reach RS and replay it in my Windows Desktop RTKLIB install.

Maybe someone from Emlid can look into this?

16

Thank you for sharing this too.

On my side I’m using my Reach RS either against my Reach base or against 3 different RTK providers that are L1/L2.
Beside having a possible software glitch, it really looks like our L1/L2 AG rovers don’t like talking to an L1-only base station. I’ll go back to a GS4 tomorrow to try as I could only play with an AGI-4 Yesterday.

To your point with the 20mins cache, you might have a point. However with the AGI-4 once a config change is done you re-initialize the RTK calculation so I believe I would have seen it working fine. Here I waited for around 15mins (I was hooking an implement) and it was still a no-go.

17

I’d agree with Thomas that the fix using Reach-to-Reach as a base-rover pairing is far more stable and faster to get to a fixed solution than 3rd Party Base-to-Reach pairing.

Again is this a limitation when using an L1/L2 rover with an L1-only Reach RS as base, perhaps?

I’ve just been playing around with our Leica GR receiver. It certainly doesn’t like an inbound RTCM stream from the Reach. It loses its entire navigated position. On inspection of the stream the number of GPS and GLONASS satellites in the inbound stream appear to be visible on L1.

18

Just for more information we have successfully used the Reach RS as a rover with an L1/L2 base station. And then we upgraded the base earlier this year to an L1/L2/L5 with Galileo support base station. The Reach RS continued to work as a rover.

But again, as DirtyHarry confirmed, the Reach RS works best as a rover when another Reach is used as the base.

I also agree with DirtyHarry that the performance difference must have something to do with the multi frequency message verses the single frequency messages; 1002 vs 1004 for GPS and 1010 vs 1012 for GLONASS. It could be as simple as the 1004/1012 message contain more data and take longer to parse. Or there could be a parsing error in RTKLIB for 1004/1012 messages that slows down or makes less reliable (but not completely destroys) the data read. It could be that this theoretical parsing error does not affect 1002 and 1010 messages.

I would love to test this theory by using a third party L1 only RTK receiver as a base to a Reach RS rover. Unfortunately, the Reach RS is the only L1 only RTK receiver we have capable of serving as an RTK base.

19

I usually find that if the base is highest spec then anything running off it work fine.

20

Thomas and team,

Just to keep you updated… in my journey of connecting AG AutoSteer to a private base station I succeeded yesterday connecting the Varioguide to it. However my base is an L1+L2 (a cheap one though) which distributes 1004/1012 messages. I’m forwarding them to my caster using a raspberry pi3 through str2str (rtklib) just to forward from serial to ntrip as the base does not have that ability yet. I’ve actually worked on 3 fields and did not see any difference than when using our (expensive) official NTRIP Provider.

I’m still in love with my Reach and Reach RS; I’m actually testing my L1/L2 testing base with them and still survey fields with them too.

I’ll give a shot to JD GS4 but now that the Topcon AGI-4 works fine as rover I don’t see any reason on why this would fail.

Pierre

3 Likes
21

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