ReachView v2.9.3 - RTK performance boost

Sure thing. I’ll get back to you with more info.

Egor:

I am in the US and after some playing around with different configurations I have been using GPS satellites only since Reachview 2.5 came out. It seemed to be the most stable configuration and avoided choking the radio link.

Based on your testing results I have upgraded to 2.9.1 and am now going to add Glonass and SBAS satellites and possibly Galileo if they have any visible satellites in the western US.

What are the other settings that you recommend for the LORA radios etc?

Please could you give a complete list of settings so that I can start off with the same configuration as you tested on my Base and Rover.

I set up on a point 5km from one reference station and 26 km from another. I had the short baseline solution going in the Reach and the longer baseline solution going in RTKnavi (using raw UBX on port 2000) on my laptop. The solutions were within one cm of each other. The longer baseline took a little longer to reach FIX.

2 Likes

Ok, so I have a small update on the issue. Turns out, the solution will only work as intended as long as the QZSS RTCM3 message has the same frequency as the GPS observations(1002). Could you please verify this in one of your tests, @BenLewis?

We are working on a fix for this.

Hi @egor.fedorov,

I have tried setting GPS L1 observations (1002) and QZSS (1117) to the same rate (1 Hz). Unfortunately I still cannot get a fix.

Here is a screenshot of my RTCM3 messages.

Here is a screenshot of my status page.

Here is a link to my log files.

@egor.fedorov,

Here are my results with ONLY 1002 and 1117 messages at 1 Hz.

@BenLewis

Thank you so much for your testing! Seems like things are still not handled properly with QZSS, we will figure that out. Please disable QZSS message for now, it does not bring any significant performance improvement anyway.

Start with:
1 Hz 1002(GPS), 0.5 Hz 1010(GLONASS), 0.5 Hz 1097(Galileo), 0.1 Hz 1006(base position)
and radio at 18k. This setting should work great in any part of the world.

1 Like

OK - Thanks. I will let you know how it works in California.

Initial testing was great. I set up my two reach units at a local park near my house and the Rover got a fix solution right away with the base and held it 100% while walking around. There were about 6 GPS satellites visible , 4 Glonass and 1 Galileo. Before it would have taken 5 minutes to get a fix. Also I previously just used GPS satellites. There was some tree canopy nearby so I walked under there and the fix was maintained. So I am going to take the units to the jobsite - about 3 hours away and give them a test under those conditions.

4 Likes

@hydrokiwi Thank you for posting your positive results!

@Simon_Allen Could you please confirm that things are working for you now with GPS+GLO+GAL?

1 Like

It’s working.
Thanks,

Here are some logs from some work out at the jobsite. I was using the survey tool but thought the raw logs may be useful information regarding using v2.9.1 in the field.

I initially tried GPS, GLONASS, SBAS and Galileo. After having some trouble reestablishing a fix and having to reboot the rover I ended up changing to just GPS and GLONASS. That seemed to be pretty stable.

It is pretty solid for ground ops, but is truly appalling for aerial applications.

I can get a solid lock on the ground with rotors turning, but as soon as I lift 2m in the air I have lost lock. At first I thought this was RF interference, but there is no reduction in SNR. My baseplate is now 10cm so, not a problem with multipath.

Is there anyway to rollback to 2.8.0 that seeemed to work for me before.

Edit to post a day later.
Although there was no visible change in the SNR It appears that the motors on the Phantom are extremely RF noisy.
I moved the reach unit to the bottom of the leg and shielded it and was able to maintain fix through a flight. Still feels a bit ‘tender’ but getting better. I think the difference between what I experienced with 2.8.0 and later versions was actually due to the change from an aluminium chassis to a 3d printed chassis, not a software change. Apologies for the negativity.

1 Like

Hey everyone,

The original post has been updated with details for v2.9.2!

Out of curiosity, has anyone else observed a change in unit behavior following some of the more recent updates with respect to the time it takes for AR to exceed three?

When I first started using the Reach units (around June-July of this year), I was able to obtain a fix using RTK in the field relatively quickly, and it would jump to AR = 9999 and stay there pretty consistently! Following some of the more recent updates, the units are sluggish to obtain a fix at all, and they struggle to maintain it. Rather than jumping to a high AR value, the units creep to it. I’ll wait in the field and watch the AR value creep up from 2.1 to 2.2 to 2.3 to 2.4… and I haven’t been able to get a fix above 11 or so for a while. Did something change in the way that the units compute AR ratios or receive corrections across previous updates?

I didn’t get great results with a casual test of the Reach units using RTK today using v2.9.2. I wasn’t very rigorous about the setup - I put the Base on a tripod and walked around slowly with the Rover, trying to take a survey point on “fix” status every ten steps or so. I was able to get a fix at an AR ratio between 3.1 and 10 at least intermittently. After postprocessing the points against a local CORS station (located less than a kilometer from where I was testing the units), less than 5% of my data from the base or rover ended up with “fix” status. I’m not sure if the issue lies with me or the units at this point, but it’s probably a combination of both factors.

I’ve attached a Google Drive link for the files from my test today, including CORS station data. If anyone has suggestions of how I might be able to get my units to work better together, I would be incredibly thankful. I had GPS, GLONASS, Galileo, and SBAS satellites enabled, though in hindsight I probably could have swapped out SBAS for QZSS to test the QZSS fix in the 2.9.2 update. I’m located in the US near the Northwestern border with Canada, if that helps.

https://drive.google.com/file/d/0B_iK3z1Blou9WFcwVS1iSDZ0Nlk/view?usp=sharing

:pray: Thank you! Please let me know if you need additional information that I can provide!

Are you using fix-and-hold or continuous ar mode? Make sure it is fix-and-hold. One more thing.

Also, check your base mode configuration. Sending too much messages will still make LoRa choke on data and the main observations will be delayed or discarded. Try minimal RTCM3 settings with 1002 and 1010 at 1 or even 0.5 Hz.

@egor.fedorov.
I have found that fix and hold works well for ground based not very dynamic situations, but on my drone that continuous works better. In fix and hold I can get a good lock and then boof! as soon as I take off lock is lost and F+H will not reacquire, but continuous gets FIX with a lower ratio, but then keeps fix through take off. Any thoughts on this?

@egor.fedorov,

I have updated to ReachView 2.9.2. Unfortunately QZSS is still not working for me. Here’s a link my log files.

Sorry for the delay in responding, but thanks for getting back to me. I did another causal test yesterday using a couple of different configurations and was actually able to maintain a fix! I had changed from using “Fix and Hold” to “Continuous” at TB_RTK’s suggestion a while back, but perhaps I misunderstood, and TB_RTK really meant that I should use Fix and Hold in the field, and Continuous while applying corrections in RTKLIB. Is it okay to mix settings like that?

After correcting yesterday’s results with CORS, I’m a little disheartened. I was, indeed, able to maintain a fix for most of the time I was in the field (the exception was when I walked around the side of a gymnasium and my AR ratio dropped to nothing). However, after correcting my base logs with CORS, I only got a fix on 26.7% of points, and my CORS-corrected rover logs obtained a fix for only 37.7% of points. I’m not sure where I’m going wrong - in the past I’ve been able to get up to 97% fix for both.

I did update my base configuration to the following settings:

  • 1002 @ 1 Hz
  • 1006 @ 0.1 Hz
  • 1010 @ 0.5 Hz
  • 1097 @ 0.5 Hz
  • 1107 @ 1 Hz

I have been avoiding using QZSS since the new update was released, but I probably shouldn’t be applying it in North America regardless. I left my update rate on the default 5 Hz setting and had the units communicating at a frequency of 1002.0 MHz using an output power of 20 dBm and an 18.23 kb/s air data rate.

My logs from yesterday’s field run: https://drive.google.com/file/d/0B_iK3z1Blou9TGVaTTAwb2VwS00/view?usp=sharing

I’ll be taking the units out again today or tomorrow to do a more rigorous accuracy test against known survey markers with good vertical control, but if anyone has suggestions for how to improve accuracy, I’m happy to give them a try!

After a run of poor post processing results I followed a piece of advice given to me by @TB_RTK, which I should have followed way earlier.
Delete your RTK post.ini file and build up your processing options again. This took me from 42% fix to over 90% fix. It took about 10 iterations as, once I had set the basics, I only changed one variable at a time. I recorded the percent fix/float/single for each solution. A painful process, but now my processing just uses the final configuration and I am getting good results.

Update to this dataset.
I just re-ran it using combined (forwarda and backwards) and continuous, rather than fix-and-hold. I think because my noise levels were good the combined method managed to fix the data at the start of the file. So now I get 98.7 % fix!

HOWEVER. I have been seeing an offset in my orthomosaics produced by PPK. I attributed it ti the SFM processing, but look at this…

One solution is the raw LLH file and the other the PPK .pos file. The base position in the RINEX header is different to the postion displayed on the screen after a base is established and yes the offset appears to be the same direction and magnitude as my orthomosaic offset. My reference points were collected in realtime (not post processed) and were all 1.1m west and 27cm South. Please Emlid, as a matter of urgency can you have a look at the code and see if an offset is sneaking in?

3 Likes