Reach RS2 FLOAT solution

try stable version 2.22.2 or version 2.23.4dev

2 Likes

Could you provide me the zip file for that versions?

I installed an old version 2.20.5. But I was unable to pass to reboot, because when I re-enter to reach view after the reflashing procedures ends, the system requires me to update, as shown on the screenshoot below.
After this, I was forced to reinstall the latest version 2.22.3 (the same that gave me problems to obtain fixed solution) and by the end return to the same problem.

Below are the screen shoots that shows the settings I have been using. The provider (CRTN) only transmits GPS and GLONASS corrections.

after reflash connect to wifi but disable internet access (then you do not need to update to the latest version) ex. disconnect internet cable from router

Hi @JoseDuran,

We recently released the new dev v2.23.4 of the ReachView app. This version is mostly used for testing purposes. However, there should be significant improvements in RTK performance. So it’d be nice if you could try it and let us know if this version helps you out.

After spent 2 hours doing the upgrade to v2.23.4 and some tests outside, I obtained the same results.

Any other clue to solve this?

Hi Jose,

Do you have another mount point of CRTN within 60 km to try? As far as I know, RS2 should work fine with this service. Would be great to make sure it’s not mount point related issue

Also, please post a screenshot from RTK Settings tab where the messages from NSSS mount point are shown

I tested using several mount points, with the same result.

Jose,

At this point we’ll need raw logs from your caster and rover unit from the session where you couldn’t obtain fix.

Another idea, does anything change if you use GPS only?

Dmitriy,

Here are the logs for a 10 minutes session, with no fix.

The image below shows a session using GPS only, same results. At the lane position it looks like the same precision when I used the GPS+GLONASS. It seems GLONASS is not participating helping me to obtain a fixed solution.

Thank you!

Below is the image of the RTK session for the session when I logged these files:

Here is the correction input settings:

raw_202004021549_UBX.zip (2.6 MB) base_202004021549_RTCM3.zip (205.5 KB) solution_202004021549_LLH.zip (87.1 KB)

Awesome, thank you for the details, we’ll look into this in the nearest time!

2 Likes

Why don’t you have “send NMEA GGA messages to correction providers” selected? In my opinion, this option is necessary for proper operation with the NTRIP server

Solved!

I tried with two caster providers. 3 cors stations are unable to provide me fixed solution. Other are working good. I connected to internet using home internet and my cellphone as a hotspot.

Thank you!

Hi @JoseDuran,

Glad to hear you obtained a fixed solution!

However, I’d like to investigate what’s wrong with the other 3 CORS stations. Could you also share the logs from these tests?

Svetlana,

Here are you requested me:
1740 is for the NSSS mount point (not getting fixed solution, 9 kms)
1744 is for the P473 mount point (not getting fixed solution 26 kms)
1749 is for the P066 mount point (not getting fixed solution but maybe because is located at 73kms)
1753 is for the P475 mount point (working good 23 kms)

Let me know if you need something else.

Thank you.

base_202004081740_RTCM3.zip (42.2 KB) base_202004081744_RTCM3.zip (212 Bytes) base_202004081749_RTCM3.zip (57.0 KB) base_202004081753_RTCM3.zip (37.4 KB) raw_202004081740_UBX.zip (545.5 KB) raw_202004081744_UBX.zip (763.9 KB) raw_202004081749_UBX.zip (729.9 KB) raw_202004081753_UBX.zip (531.7 KB) solution_202004081740_LLH.zip (14.9 KB) solution_202004081744_LLH.zip (14.6 KB) solution_202004081749_LLH.zip (14.7 KB) solution_202004081753_LLH.zip (9.7 KB)

Here you can download an excel table with all the cors stations for the California Real Time Network (in yellow the ones I used):

http://sopac-csrc.ucsd.edu/index.php/crtn-stationlist/

Hi Jose,

Thanks for the logs. I’ve analyzed them, and there are no obvious reasons for such differences in the results. Please take a look at the screenshots. The rover raw data log is at the top, and the NTRIP log is at the bottom:

  • NSSS mount point

  • P475 mount point

In both cases, we have 8 common satellites with stable SNR values of about 45. However, a fixed solution was obtained with the P475 mount point only.

According to the CRTN station list, NSSS, P473, and P066 mount points are owned by SDCRTN sub-network. And the last one is owned by NOTA.

To investigate if there are any differences between these sub-networks, may I ask you to share with me screenshots of the Correction input tab with the RTCM3 messages list? To display this list, please press on the arrow in the lower right corner of the window.

2 Likes

Hello Svetlana,

Here are some screeshoots.

Thank you.

2 Likes

Hi Jose,

Thank you for the screenshots. Looks like the issue isn’t related to RTCM messages. So I’ll continue to investigate this and write you back once there is any news.

1 Like