Rover position creeps all over the place

Hi, we are using a fixed BASE and each morning I place our Reach ROVER into a calibration position. For the past 20 days it has always come up in the same spot. But this morning the ROVER position will not stay put and continues to randomly creep around. This renders the system unusable. Only after waiting for approx 3 hours has the ROVER position stabilized enough that we can use the system again.

Our installation requires that the BASE and ROVER remain powered up and linked (via LoRa) all the time, which has so far been working fine. Both BASE and ROVER are using v2.14.0.

Any idea as to what could cause this instability? And is there a quick way to recover from it (we really cannot afford to be down for 3 hours)?

Any suggestions would be appreciated.

Attached is a status map from the ROVER…

And from the BASE.

As well as the system reports.

ROVER report…

Simple system report
app version: 2.14.0-r0
'wifi_status, interface: wlan0':
- wifi_mode: wpa_supplicant
- ip: 10.1.1.10
  is_connected: true
  mac_address: fc:db:b3:8d:c5:8b
  ssid: TheKnightFamily
base mode:
  base coordinates:
    accumulation: '6.1'
    antenna offset:
      east: '0'
      north: '0'
      up: '1'
    coordinates:
    - '-38.315113'
    - '144.318144'
    - '43.116'
    format: llh
    mode: manual
  output:
    enabled: false
    format: rtcm3
    path: ntrips://:BETATEST@69.75.31.235:2101/AUGSS14#rtcm3
    type: ntrips
  rtcm3 messages:
    '1002':
      enabled: true
      frequency: '1'
    '1006':
      enabled: true
      frequency: '0.1'
    '1008':
      enabled: true
      frequency: '1'
    '1010':
      enabled: true
      frequency: '1'
    '1019':
      enabled: true
      frequency: '1'
    '1020':
      enabled: true
      frequency: '1'
    '1097':
      enabled: true
      frequency: '1'
    '1107':
      enabled: true
      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: true
  pin: '***'
correction input:
  input2:
    enabled: true
    format: rtcm3
    path: lora
    send position to base: 'off'
    type: lora
  input3:
    enabled: false
    format: rtcm3
    path: 10.1.1.248:9028
    type: tcpcli
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: NMEA
    started: false
    version: null
lora:
  air rate: '18.23'
  frequency: 919000
  output power: '20'
position output:
  output1:
    enabled: true
    format: nmea
    path: ttyMFD2:9600:8:n:1:off
    type: serial
  output2:
    enabled: false
    format: nmea
    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: '12'
  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: true
    sbas: true
  snr mask: '34'
  update rate: '5'

BASE report…

Simple system report
app version: 2.14.0-r0
'wifi_status, interface: wlan0':
- wifi_mode: wpa_supplicant
- ip: 10.1.1.11
  is_connected: true
  mac_address: fc:db:b3:9a:d9:95
  ssid: TheKnightFamily
base mode:
  base coordinates:
    accumulation: '30'
    antenna offset:
      east: '0'
      north: '0'
      up: '0'
    coordinates:
    - '-38.3131540332'
    - '144.2932981507'
    - '69.516'
    format: llh
    mode: manual
  output:
    enabled: true
    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: '1'
    '1019':
      enabled: false
      frequency: '1'
    '1020':
      enabled: true
      frequency: '1'
    '1097':
      enabled: true
      frequency: '1'
    '1107':
      enabled: true
      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: false
    format: rtcm3
    path: lora
    send position to base: 'off'
    type: lora
  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: NMEA
    started: false
    version: null
lora:
  air rate: '18.23'
  frequency: 919000
  output power: '20'
position output:
  output1:
    enabled: false
    format: nmea
    path: bluetooth
    type: bluetooth
  output2:
    enabled: false
    format: nmea
    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: '10'
  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: true
    sbas: true
  snr mask: '30'
  update rate: '5'

Hmm I think the real question is, why is it in float, and not fix?
Has it always been in float for you?

I would say the majority of the time we are in float. So we have modelled our operation around that, and it works well enough. Obviously a fix would be better, but we work around a lot of obstructions which often obscure part of the sky. This is the first time I’ve seen the float walking around the place, normally it picks up the correct location each morning. Right now it’s fine, even had a few fix points. But the problem was this morning when it took the ROVER 3 hours to figure out where it was supposed to be… we would like to have a process to avoid this or a reset process to get the correct location back in a minimal amount of time.

Hi @pet.GSS,

Without logs, it’s hard to say about the possible reason for such behavior.
Can you share your UBX raw logs (base and rover) for that period of time?

Thanks.

1 Like

Hi Andrew,
I don’t have the logs from yesterday, but it was out by a bit again this morning, I have attached the log files from both the ROVER and the BASE.

As I mentioned, both antennas are always turned on, but at night the ROVER is parked in a shed so it looses its satellites. Then when we bring it out in the morning, it takes a long time before it finds itself again.

Thanks.

raw_201810162219_UBX_ROVER.zip (1.6 MB)

raw_201810162219_UBX_BASE.zip (1.9 MB)

Hi @pet.GSS,

I’ve processed your log and it has got a really good solution (see the screenshot below).
After 10 seconds of float, you got a tight fix.


You also have an acceptable quality of satellites signals.

I think that the main reason is that it starts to average its position using a lot of “faulty” coordinates after standing in a shed for the night.

Why can’t you turn it on every day? It can help you to get a solution faster.
What way of sending correction do you use?

Hi Andrew, interesting that it reports a fix position, I never saw it on the status screen, it stayed as float. Below is the ROVER status screen for the same time period that I took those log files.

The antennas get mounted on vehicles where the on/off button is not easily accessible. What would be really good is if the antennas had a sleep/wake up feature where we could send a signal through the Reach cable to remotely control them. Or is this a feature that maybe already exists?

Hi @pet.GSS,

It’s quite strange to always have a float solution.
Can you share your full system report for base and rover by following steps from this tutorial?

You can update to the dev version as we’ve automatic boot when power is supplied via the bottom connector from the v2.15.4.

Hi Andrew,
That is really good news about the auto power up through the bottom connector, this will really help improve the way we operate. Looking forward to that version going live.

I’ve tried a few different RTK settings, and when I removed GLONASS and turned on BEIDOU (the others that I have turned on are: GPS, GALILEO, SBAS and QZSS), I find that I’m getting a FIX solution most of the time now.

1 Like

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