Getting RTK Fix with Reach RS

We have a similar problem with no fix with NTRIP even after an hour. Today we used GLONASS AR, so we’ll try that off next time to see if it work, but I’m uploading the raw log and simple in case there is anything else that could be improved in our settings since we have rarely been able to get a fix solution. Any additional suggestions would be greatly appreciated.
Margaret

Simple system report
app version: 2.11.0-r0
'wifi_status, interface: wlan0':
- Client state
- IP address: 192.168.1.119
  mac address: 90:b6:86:00:0c:c7
  ssid: 
base mode:<a class="attachment" href="/uploads/default/original/2X/0/013840961e59b259c466df64a50de1e1a93f69de.zip">raw_201806251712_UBX.zip</a> (4.2 MB)

  base coordinates:
    accumulation: '30'
    antenna offset:
      east: '0'
      north: '0'
      up: '0'
    coordinates:
    - '0'
    - '0'
    - '0'
    format: llh
    mode: fix-and-hold
  output:
    enabled: false
    format: rtcm3
    path: lora
    type: lora
  rtcm3 messages:
    '1002':
      enabled: true
      frequency: '1'
    '1006':
      enabled: true
      frequency: '0.1'
    '1008':
      enabled: false
      frequency: '1'
    '1010':
      enabled: true
      frequency: '0.5'
    '1019':
      enabled: false
      frequency: '1'
    '1020':
      enabled: false
      frequency: '1'
    '1097':
      enabled: true
      frequency: '0.5'
    '1107':
      enabled: false
      frequency: '1'
    '1117':
      enabled: false
      frequency: '1'
    '1127':
      enabled: false
      frequency: '1'
    gps:
      enabled: false
      frequency: '1'
    qzss:
      enabled: false
      frequency: '1'
bluetooth:
  discoverable: false
  enabled: false
  pin: '***'
correction input:
  input2:
    enabled: true
    format: rtcm3
    path: ***@98.159.149.73:10000/RTCM3_IMAX
    send position to base: single
    type: ntripcli
  input3:
    enabled: false
    format: rtcm3
    path: :9028
    type: tcpsvr
logging:
  base:
    format: RTCM3
    started: false
    version: null
  correction:
    format: RTCM3
    started: false
    version: null
  interval: 24
  overwrite: true
  raw:
    format: UBX
    started: false
    version: null
  solution:
    format: LLH
    started: false
    version: null
lora:
  air rate: '18.23'
  frequency: 1000100
  output power: '20'
position output:
  output1:
    enabled: false
    format: nmea
    path: bluetooth
    type: bluetooth
  output2:
    enabled: false
    format: llh
    path: :2013
    type: tcpsvr
  output3:
    enabled: true
    format: llh
    path: :2014
    type: tcpsvr
  output4:
    enabled: true
    format: llh
    path: :2015
    type: tcpsvr
rtk settings:
  elevation mask angle: '15'
  glonass ar mode: 'on'
  gps ar mode: fix-and-hold
  max horizontal acceleration: '1'
  max vertical acceleration: '1'
  positioning mode: kinematic
  positioning systems:
    compass: false
    galileo: true
    glonass: true
    gps: true
    qzs: true
    qzss: false
    sbas: true
  snr mask: '30'
  update rate: '1'

Hi Margaret,

Could you attach a raw log please?

raw_201806251712_UBX.zip (4.2 MB)
Hi,
Here it is - this is from the field, the system report I generated was once we were back in the office.

Hi Margaret,

As I can see from your raw log, there is a poor satellite visibility in the area where you’ve tested. In what type of environment did you test your Reach? Did you use Reach or Reach RS? What is the distance to the reference station you are using?

Hi,

The area is very open without tree cover or buildings within a couple kilometers distance. These data were collected with Reach RS. The distance to the reference station is 9.602 km.

Hi Margaret,

Have you already tried surveying with Glonass AR mode off? If yes, how was the result?

Please make sure there are no sources of interference around the receiver.

You can also try the latest ReachView v2.13.0 dev version, it allows to use GLONASS AR with non-Reach bases, such as NTRIP casters.

raw_201807051741_UBX.zip (777.5 KB)
Hi,

Here is our log with Glonass AR off. The solution remained “float”. We will try the v2.13.0 dev version and see if that provides a fix solution.

Thank you.

Hello. Do you have another hardware? Like satlab, leica, topcon?
We have and they get fix at once where the emlid doesnt.
Guess the lack of L2-band is the explanation.
Correct?

Hi Margaret,

This log is better than the previous one. Could you also please share base station log so we can see what’s happening during post-processing?

Also, let us know about your tests with v2.13.0.

base_201807051741_RTCM3.zip (200.5 KB)
Hi,

Here is the base correction file. We were using the same NTRIP correction from 9.6km away. We will be going out tomorrow again and will test out v. 2.13 and upload the logs.
Thank you!

Thanks for sharing the log, will look into it.

Please let me know about your tests with the latest dev update.

base_201807111404_RTCM3.zip (953.9 KB)
raw_201807111404_UBX.zip (4.5 MB)
Hi,

It did much better with version 2.13 - for the first time we were able to get a fix solution which held for nearly the entire survey!

1 Like

Hi Margaret,

I’ve post-processed your logs and the solution is getting better.
However, according to the rover raw log, there was a poor satellite visibility again. I’ve attached the screenshot from RTKLIB, so, as you can see, the log contains a lot of cycle slips which’s not good.

Could you share the photo of your Reach RS setup in the field? Do you use survey pole?

Thank you - our pole is 1.67m tall. I’ve sent a photo via PM.

Hi Margaret,

Did you have time to do more tests?

I hear would cost too much for Emlid to create a unit utilizing more than just L1… but just out of curiosity…what is the main cost restrictive factor to do so? Don’t mean to go off the topic here, but just curios is all the main thing simply that holds this back. Is there some sort of fee or something involved to use anything more than L1 on the satellites? Or technology-wise cost restrictive?

1 Like

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