Multiple fix points for a single physical location

sbm · August 7, 2019, 8:05pm

Hi, I have setup my RS2 (v2.20.5) in a stationary location using UNAVCO ntrip source for RTK. I am getting fixes on 2 different coordinates, spaced roughly 1M apart. Receiver fixes on one or the other coordinates after reboot. I have tried with the two nearest UNAVCO sources (13km and 30km), getting a total of 3 fixes. (2 fixes per each ntrip source)

This is disturbing to me, and I am wondering how this is possible? I haven’t tried PPK yet, but I was under the impression that if you get a fix, it should be quite repeatable.

Any ideas what’s going on here?

timd1971 · August 7, 2019, 8:09pm

Post your Simple Report.

https://docs.emlid.com/reachrs/common/tutorials/downloading-files/

sbm · August 7, 2019, 8:20pm

Simple system report

app version: 2.20.5-rs2-rc0-r0
'wifi_status, interface: wlan0':
- wifi_mode: infrastructure
- ip: 10.10.4.114
  is_added: true
  is_connected: true
  is_visible: false
  mac_address: 6C:21:A2:92:96:B2
  security: wpa-psk
  ssid: lan
  uuid: a762ff1d-16dd-4558-965b-89f4b0fe7c98
base mode:
  base coordinates:
    accumulation: '3'
    antenna offset:
      east: '0'
      north: '0'
      up: '0'
    coordinates:
    - '0'
    - '0'
    - '0'
    format: llh
    mode: fix-and-hold
  output:
    enabled: false
    format: rtcm3
    path: tcpsvr://:9000#rtcm3
    type: tcpsvr
  rtcm3 messages:
    '1006':
      enabled: true
      frequency: '0.1'
    '1074':
      enabled: true
      frequency: '1'
    '1084':
      enabled: true
      frequency: '1'
    '1094':
      enabled: true
      frequency: '1'
    '1124':
      enabled: true
      frequency: '1'
bluetooth:
  discoverable: true
  enabled: true
  pin: '***'
correction input:
  input2:
    enabled: true
    format: rtcm3
    path: ***:***@rtgpsout.unavco.org:2101/P426_RTCM3
    send position to base: 'off'
    type: ntripcli
  input3:
    enabled: false
    format: rtcm3
    path: :9028
    type: tcpsvr
logging:
  base:
    format: RTCM3
    started: false
    version: null
  correction:
    format: RTCM3
    started: true
    version: null
  interval: 24
  overwrite: true
  raw:
    format: UBX
    started: false
    version: null
  solution:
    format: LLH
    started: false
    version: null
lora:
  air rate: 2.6000000000000001
  frequency: 868000
  output power: 20
position output:
  output1:
    enabled: true
    format: nmea
    path: bluetooth
    type: bluetooth
  output2:
    enabled: false
    format: nmea
    path: :9002
    type: tcpsvr
  output3:
    enabled: true
    format: llh
    path: :2014
    type: tcpsvr
  output4:
    enabled: true
    format: llh_ext
    path: :2015
    type: tcpsvr
rtk settings:
  elevation mask angle: '3'
  glonass ar mode: 'off'
  gps ar mode: fix-and-hold
  max horizontal acceleration: '1'
  max vertical acceleration: '1'
  positioning mode: kinematic
  positioning systems:
    compass: true
    galileo: true
    glonass: true
    gps: true
    qzss: true
  snr mask: '30'
  update rate: '5'

timd1971 · August 7, 2019, 9:19pm

Anybody see anything why they are having the problem?

What’s up with this?
rtk settings:
elevation mask angle: '3’

RTK_Hunter · August 7, 2019, 10:56pm

What is the other station you are connecting to? Your description of a different fix at reboot is strange. You could start with a slightly higher elevation mask say 15. That low could have introduced some poor data leading to some false fixes when using fix and hold from an RTK perspective.

From an NTRIP perspective check with UNAVCO if any system maintenance was being done on those two stations and confirm the RTCM3 datum of the base coordinate. To me the 1-meter difference suggests bouncing between NAD83 and IGS08 (WGS84).

Try to PPK to the same two base stations and compare coordinates.

P426:
https://www.unavco.org/instrumentation/networks/status/pbo/overview/P426

P4xx?:

sbm · August 7, 2019, 11:26pm

The other station is P437
https://www.unavco.org/instrumentation/networks/status/pbo/overview/P437

I will do PPK on it as suggested, however would think that RTK should not behave this way. It seems to wander over to one point or the other after initialization. I did have a higher elev mask, but lowered to see if it would make a difference.

Point 1 is the shared location
Point 2 is the second fix from the 13km baseline station P426
Point 3 is the second fix from the 30km baseline station P437

agrimgalina · August 7, 2019, 11:31pm

Hi Tim ! although I still do not receive my RS2 I see the configuration wrong!
Glonass Ar off, turn off output correction, mask 15 degrees and SNR 45.
If the coordinates of the base are in NAD 83, it will surely have differences to the WGS84 frame.
I would say that you correctly configure NTRIP and the rest of the RTK parameters

agrimgalina · August 7, 2019, 11:35pm

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: true
galileo: true
glonass: true
gps: true
qzss: true
snr mask: ‘45’
update rate: ‘5’

sbm · August 8, 2019, 12:05am

Interesting, I see apparently there is a discrepancy between coordinate systems with UNAVCO ntrip and Emlid. Seems like that would result in a consistent offset, but I wouldn’t argue that it could result in an unstable fix. That seems like a problem. Maybe Emlid could consider supporting multiple coordinate systems.

sbm · August 8, 2019, 12:12am

Thanks Luis, I tried again with elevation mask 15, snr mask 40 (as high as it goes), there is no option in RS2 for AR mode, and it doesn’t report AR in this firmware yet.
Didn’t change my problem though. Could be a NAD83 vs WGS84 issue.

agrimgalina · August 8, 2019, 12:17am

the parameters of the ellipsoid wgs84 and GRS80 differ in the flattening 1 / f, in the GRS80 the ellipsoid is more flat

agrimgalina · August 8, 2019, 12:20am

but it is not so that there is a difference of one meter between one ellipsoid and another

timd1971 · August 8, 2019, 1:13am

Yes of course. But no timeframe on that. It may also complicate things for “most” users… probably why the stalling… yet it is VERY important for users who NEED it and understand the NEED for it. Therefore, just use third party software in the meantime.

timd1971 · August 8, 2019, 1:18am

https://docs.emlid.com/reachrs2/reachview/rtk-settings/#elevation-mask-angle

Angle mask that low near the horizon bound to cause issues.

timd1971 · August 8, 2019, 1:21am

Don’t use 40, too high, use 35.
And there probably won’t be AR Mode either for the RS2 as apparently doesn’t need it.

tatiana.andreeva · August 8, 2019, 10:44am

Hi @sbm,

Please, share the following information:

RINEX logs from these 2 stations (you can just upload RTCM3 logs from Reach RS2 instead of it)
coordinates of these 2 stations and in which coordinate systems they are specified
raw data files from Reach RS2
position logs from Reach RS2

Thanks!

sbm · August 8, 2019, 4:04pm

Hi @tatiana.andreeva I can send you logs if you really want them, however it seems clear to me after further investigation that the WGS84 vs IGS08 coordinate system problem brought up by several in this thread is the real problem. UNAVCO as an ntrip source is very convenient for me and many others I presume, and it would be of great benefit for Emlid to implement support for other common coordinate systems such as the IGS08 and NAD83 which both use the GRS80 ellipsoid. Many ntrip sources are also on local coordinates, so a whole package would be wonderful!

I am not familiar with the details of RTCM3 but if the ntrip data indicates which coordinate system is used for base location, perhaps in the meantime emlid could consider a warning about incompatible data source.

I am now testing with FieldGenius, using it to interface with the ntrip source for RTK and have had good success with quick fixes and high precision. I will be testing further, but it seems this is my best solution currently.

I was hoping to use the RS2 with RTK via ntrip over cell network, with position output to my ipad or iphone for use with Arcgis collector. This is obviously not possible currently for several reasons. (no Apple MFi for bluetooth)
The RS2 is too good to leave us without these features, so hoping you see the value to us and make it possible!

RTK_Hunter · August 8, 2019, 6:16pm

IGS08 is the latest realization of WGS84. Reach does not know the difference. UNAVCO/PBO should be IGS08. Most stations broadcast GPS only and some GLO. Looks like these stations are GPS only so GLO would have no affect. If base is broadcasting NAD83 your survey will technically be in NAD83 but will tell you its WGS84…

It may or may not be WGS84 vs NAD83 issue. Drop GLO, adjust SNR/Elevation, and change from fix-hold to continuous. Still try PPK to see if can reproduce results.

timd1971 · August 8, 2019, 6:37pm

Prob still send @tatiana.andreeva. may be something else to learn from.

agrimgalina · August 8, 2019, 8:07pm

@sbm send the files @tatiana.andreeva as Tim says