RS+ won't enter "Fix Mode"

For the issue regarding an EMLID RS+, the settings of the device are properly set, and it’s in the recommended environment for a secure connection but currently it seems incapable of having a fixed connection. For the variety of tests that the device has been used for, there has been a fluctuation in how the RS+ obtains a fix. This variation is to say that the device went from working as intended, to taking a longer time than normal to reach the “fix” mode, to not being able to reach this mode entirely. Asides from having the necessary settings and an optimal environment for satellite connections, why can’t the device secure a “fix” solution status at this point in time?

Since many variables could affect your FIX, it might be best to save your Simple System Report and post here for detailed help.

https://docs.emlid.com/reachrs/reach-panel/settings#system-report

Hi @avazquez,

Welcome to the Emlid community forum!

Several reasons can cause such an issue:

  • environmental conditions. Reach RS+ needs a clear sky view without any obstacles to achieve a fixed solution.

  • long baseline. If the baseline is more than 10 km, Reach RS+ can have difficulties with calculating a fixed solution.

  • inappropriate configurations. We recommend using the default settings from our docs since we thoroughly tested them and can confirm they work fine.

To investigate this case, we will need more information about the configuration of your devices and your current workflow.

Can you please post the logging data from the base and the rover?
We need raw data log, position log, base correction log from the rover, and raw data log from the base.

Can you also post the photos of the environmental conditions you’re surveying in?

Hello, my apologies for the late message! I am no longer at the site but I do have a photo and saved log information (Raw Data, Base Corrections, Position) for the scenario where only a float signal was seen currently saved today on my device. I’m trying to upload them all as a zip file, but I end up getting a message saying “New users cannot upload attachments”?

Actually I believe this should be it

rate.zip (4.9 MB)

The photo should show the base unit in the far back up on a pole with the rover sitting on top of the ground. (I don’t have a simple system report)

Setting the receiver on the ground is a cardinal sin the GNSS world. If you can afford a receiver, you can afford a bipod and range pole or a tripod and tribrachs. The unit needs to be off the ground in order to receive clean unobstructed signals from the sats. It may look like this would work, but this is your main problem in not getting a fixed solution.

3 Likes

Well essentially the device was attached to a moving piece of equipment (elevated off the ground) but was disassembled that day which left me to test the device by holding it up and walking up and down the crop paths. The device remained on a float signal for the entire duration of the test.

I question if there is a cycle slip either because of a connection to GLONASS satellites or if it’s because of a firmware update that reachview 3 stated was needed for the RS+ (Not sure if that causes a fix connection failure). But I’m unsure of what other reasons it could be.

Is the height for the base correct? I.e. from point on ground, to bottom of receiver PLUS 65mm to ARP? did you average single, then save the coordinates as manual? (or average fix via NTRIP CORS RTN?)

https://docs.emlid.com/reachrs/tutorials/basics/placing-the-base#placing-reach-rsrs

You really need to send a simple system report to see what settings are possibly incorrect.

I’m not sure I this needed to be at the site in particular for any change in the system report, but I did find where to generate it so its listed below (No antenna is connected, merely obtained the report with both devices resting on a table). I unfortunately can’t test these devices in the setting shown in the photo but if needed I can test any theories at the residency I’m located at now. But any leads for why its suddenly refusing to hold a fix signal would be much appreciated.

The height for the base should be correct. (If I’m making this difficult, my apologies I’m still new to using emlid reach devices)

Simple system report

app version: 2.22.4-r0

'wifi_status, interface: wlan0':

- wifi_mode: ap

- access_point:

    band: bg

    channel: 1

    password: null

  ip: 192.168.42.1

  is_added: true

  is_connected: true

  mac_address: C0:84:7D:1F:20:6A

  security: wpa-psk

  ssid: Fumi_head:3F:C7

  uuid: 916f4cd4-67f8-43d0-941b-cd125280d368

base mode:

  base coordinates:

    accumulation: '2'

    antenna offset:

      east: '0'

      north: '0'

      up: '0'

    coordinates:

    - 0

    - 0

    - 0

    format: llh

    mode: single-and-hold

  output:

    enabled: false

    format: rtcm3

    path: lora

    type: lora

  rtcm3 messages:

    '1002':

      enabled: true

      frequency: 1

    '1006':

      enabled: true

      frequency: 0.10000000000000001

    '1010':

      enabled: true

      frequency: 1

    '1097':

      enabled: true

      frequency: 1

    '1107':

      enabled: true

      frequency: 1

    '1117':

      enabled: true

      frequency: 1

    '1127':

      enabled: false

      frequency: 1

bluetooth:

  discoverable: false

  enabled: false

  pin: '***'

constraints:

  lora:

    frequency:

    - - 902000

      - 928000

correction input:

  input2:

    enabled: true

    format: rtcm3

    path: lora

    send position to base: 'off'

    type: lora

  input3:

    enabled: false

    format: RTCM3

    io_type: tcpsvr

    path: :9028

device: null

logging:

  base:

    format: RINEX

    started: true

    version: '3.00'

  correction:

    format: RTCM3

    started: true

  debug: false

  interval: 24

  overwrite: true

  raw:

    format: RINEX

    started: true

    version: '3.00'

  solution:

    format: NMEA

    started: true

lora:

  air rate: 9.1099999999999994

  frequency: 902000

  mode: read

  output power: 20

position output:

  output1:

    enabled: true

    format: nmea

    path: ttyGS0:9600:8:n:1:off

    type: serial

  output2:

    enabled: false

    format: llh

    path: :9001

    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

    qzss: true

    sbas: true

  snr mask: 25

  update rate: 5

try bumping that back up to the default 35.

That was not the case, I may place a base in a different location for a better signal but I’m currently testing it in a yard (elevated sidewalk and front yard)(done it with a RS2 and worked just fine) I changed the base coordinates input to average single to adjust the coordinates and ran a test and the AR validation just kept fluctuating (between float and fix) and eventually stayed around 1.2 - 2.1

details=“Simple system report”]

app version: 2.22.4-r0
'wifi_status, interface: wlan0':
- wifi_mode: ap
- access_point:
    band: bg
    channel: 1
    password: null
  ip: 192.168.42.1
  is_added: true
  is_connected: true
  mac_address: C0:84:7D:1F:20:6A
  security: wpa-psk
  ssid: Fumi_head:3F:C7
  uuid: 916f4cd4-67f8-43d0-941b-cd125280d368
base mode:
  base coordinates:
    accumulation: '2'
    antenna offset:
      east: '0'
      north: '0'
      up: '0'
    coordinates:
    - 0
    - 0
    - 0
    format: llh
    mode: single-and-hold
  output:
    enabled: false
    format: rtcm3
    path: lora
    type: lora
  rtcm3 messages:
    '1002':
      enabled: true
      frequency: 1
    '1006':
      enabled: true
      frequency: 0.10000000000000001
    '1010':
      enabled: true
      frequency: 1
    '1097':
      enabled: true
      frequency: 1
    '1107':
      enabled: true
      frequency: 1
    '1117':
      enabled: true
      frequency: 1
    '1127':
      enabled: false
      frequency: 1
bluetooth:
  discoverable: false
  enabled: false
  pin: '***'
constraints:
  lora:
    frequency:
    - - 902000
      - 928000
correction input:
  input2:
    enabled: true
    format: rtcm3
    path: lora
    send position to base: 'off'
    type: lora
  input3:
    enabled: false
    format: RTCM3
    io_type: tcpsvr
    path: :9028
device: null
logging:
  base:
    format: RINEX
    started: true
    version: '3.00'
  correction:
    format: RTCM3
    started: true
  debug: false
  interval: 24
  overwrite: true
  raw:
    format: RINEX
    started: true
    version: '3.00'
  solution:
    format: NMEA
    started: true
lora:
  air rate: 9.1099999999999994
  frequency: 902000
  mode: read
  output power: 20
position output:
  output1:
    enabled: true
    format: nmea
    path: ttyGS0:9600:8:n:1:off
    type: serial
  output2:
    enabled: false
    format: llh
    path: :9001
    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
    qzss: true
    sbas: true
  snr mask: 35
  update rate: 5

[/details]

Damn… You need a tripod ! You could get one of these and mount on top of your truck or car. At least this would be better than on the ground !!

4 Likes

A post was split to a new topic: Acceptable time for RS+ to get a fixed status

First, before we talk about fixes, you need to get those units elevated. That is the biggest issue right now that prevents you getting a fix.

Get a Rover Pole and a bipod, and you are you good to go.
Then, with the rover elevates to at least over head height, you should see fix times of around 5 minutes for the single frequency RS+.

2 Likes

I understand, I did spend time repositioning the devices to have a higher elevation from the ground and the devices did have a fix signal after some time. However, based upon the original rate.zip file and photo shown in a field in West Virginia (At the beginning of this topic post), both devices had enough height from the ground to acquire a fix signal but never was able to connect to it. So the newer data and photo was just of me trying to test whether the base/receiver were working as intended (at a residential location). Good news is that they held a fix signal but my original problem was trying to understand why it wasn’t working at the field (All the settings and conditions were attained).

@avazquez,

As other users told above, you should level up the base. As I see from your logs, you have periodical gaps in correction messages, which indicates that the LoRa signal is interrupted. The LoRa antenna shouldn’t lie on the ground also. It may also be the cause why you can’t achieve a stable fixed solution.

Your raw data from the rover looks good. However, you’ve not placed a log from the base, only a corrections log. Do you have a raw data log from the base in UBX?

I do, I appreciate you looking into this for me! I’m not sure how to check out the data in the sense for identifying any issues. I have posted all the logs for one of the tests along with the picture of the environment. (Both the base and receiver were elevated off the ground but I question if something in the environment is the reason.

Please keep in mind, what I posted is the main issue. Its regarding an area in West Virginia. The settings for the device should be fine yet no fix signal could be attained. All other tests performed outside this area proved successful so far, so I’m unsure of what could cause this issue in this field. (During the test in the photo - BOTH - units were properly elevated off the ground, the receiver was only on the ground after I finished testing)

solution_202107061715_NMEA.zip (119.3 KB)
raw_202107061715_RINEX-3_00.zip (930.0 KB)
base_202107061715_RINEX-3_00.zip (132.0 KB)
raw_202107061715_ubx.zip (1.0 MB)
base_202107061715_rtcm3.zip (81.4 KB)

Not sure if you missed my post I sent three days ago, but I did send the file you needed. If you could assist me with what the problem could be I’d appreciate it.

Hi @avazquez,

I’ve checked all your data once again.

I’ve noted that the firmware version in the Simple system report is stated as 2.22.4.
Can you check all your receivers and update them to the latest firmware version? We have substantially improved fix stability in RTK in the latest versions.

The next thing is that I can recognize a powerline above the receiver on the pole. These power lines can affect the LoRa signal stability.

I also suggest you try another LoRa bandwidth as there can be radio-electronic signals that interfere with your current LoRa bandwidth.

It would be great if you repeat the test after all modifications and share your results.

Do you have a base receiver left on the pole in the field, or is it with you?

3 Likes

Unfortunately the base receiver is currently with me. Now I spoke with someone who originally tested these devices in the field and the options you stated were already tested long ago. The base was moved so that the powerline would be out of the way and the bandwidth was changed and no changes were seen. The device says its up to date but I question if it’s true since the device produces its own connection but it has no internet so I’m not sure if it’s truly up to date. But other than that, I only had to update a different rover receiver (wasn’t used during the test). Are there any other reasons for a faulty connection. My apologies for not being able to test this. The test sight is far, and there hasn’t been any time to go back and use the testing field again.

Connect the receiver to the internet and then check for updates.

2 Likes