Trouble getting Fix; limited range

I did not see the Age of Differential increasing. 1.0 or 2.0 seconds throughout. The files at this link are the base raw data log, and then also the files for the rover consisting of (Part A) walking away from the base until losing the correction and then coming back toward the base but the correction does not come back, so I reboot the rover (Part B) in the same location where I was not getting a connection to the base, but after rebooting and starting this new (Part B) log file, I do have a connection with the base. So, a reboot of the rover is required to reconnect with the base.

https://drive.google.com/drive/folders/1o1UXOQWqRZHc4YOg6IUxAjgVfUo7d12m?usp=sharing

1 Like

Just like to add some things.
Using Fix&Hold and the fact that the rover is losing LoRa connection from time to time, this mode will increase time to new fix. You should either swap to continous mode or reinitiat rover by change something in the RTK menu.

For best horizontal distance and coverage, BOTH LoRa antennas should be pointing in a vertical direction. Think of the radio signals as donut rings around the antenna.

Dropping grey bars is often seen with LoRa correction. Some or all may drop but tuning in the radio is important for a stable and long range RTK. You dont need poor RTCM messages hogging up your bandwith. With some planing, you can skip the ones with poor visibility GNSS Radar

High data rate, and many RTCM messages for short baseline. For long distance use low data rate, low frequenc, few RTCM messages at low rate and preferably a rover in static mode if you are really pushing it

5 Likes

While I agree on the data rates due to the length of time the signal is in the air, it has been my experience that lower radio frequencies penetrate better and high frequencies travel further, but I guess it may be different with Reach?

1 Like

I could be wrong of course. Took the numbers from back of my head in the days of FPV.
Low frequence = long range and penetration. Not sure how much it would matter in that small LoRa Hz area RS has.
Could it be you have been using different antenna? I know RS2 LoRa outperform RS LoRa with more or less the same setup. Different antenna though

1 Like

The Reach receiver frequency range is so narrow that it probably doesn’t matter as much, but Topcon’s is a little wider and you can see a difference (mostly on range) between the top and the bottom. Also, we sometimes run UHF (450MHz Band) and get MUCH better penetration is dense areas.

2 Likes


I just find the data has a high fixed rate.

1 Like

My bet is that you have a lose wire somewhere in the LORA system. I was having similar issues to what you are describing and after a few weeks of intermittently working systems, I got a replacement unit. Immediately worked. My guess was a connection was just loose enough to cause issues but made a good enough connection to make the units communicate for a bit at a time making trouble shooting a real PITA. In any case, I would see if it is at all possible to try another unit and see if it resolves your issues.

That’s my bet also. I’ve been tempted to just open the housing and take a look in there but have not done so yet. I expect to find a loose antenna or tenuous soldering of the antenna wire to a circuit board or something like that. Just before I resort to replacing one of the units, I’ll crack mine open. …also, if I have to buy a replacement anyway, is Emlid where I want to go again? I want to believe, but I need a working unit also, so may need to shop around.

Don’t know how long you’ve had the unit, but Emlid replaced mine. We returned ours to the distributor that we originally purchased it from and Emlid sent one straight from Hong Kong. I had a lot of back and forth with them though providing files for them to determine that the unit was screwy.

Here is the topic where it was resolved.

Here is the original topic.

2 Likes

Hi Brian,

Thank you for such a detailed issue description! I’ve checked the data and have a couple of additional questions.

First, it seems that the base file you’ve added is identical to the rover A UBX file. Could you please check once again that you shared the correct UBX file from the base device?

Also, I’ve noticed that both rover logs contain several epochs with GLONASS data at start, but then they are absent (check the screenshot below). Did you disable GLONASS data in RTK Settings on purpose? Could you share the Simple System report from the device with me so that I can check the settings?

I also checked the RTCM3 messages rover got from the base, and there are GPS satellites only. Could you clarify if you enabled only GPS corrections while testing the setup?

Hi Tatiana, thanks for your help.

The files are different sizes so I think that would mean they have to contain different data. Here’s the link again and the UBX files we are loooking for are:
BASE_raw_202005072256_UBX (1).zip
and
ROVER_A_raw_202005072256_UBX.zip
ROVER_B_raw_202005072340_UBX.zip

The link again if you need it:
https://drive.google.com/open?id=1o1UXOQWqRZHc4YOg6IUxAjgVfUo7d12m

Did you disable GLONASS data in RTK Settings on purpose?

Yes, because earlier in this thread it was speculated that the amount of correction data was overloading my LoRa transmission rate and it was suggested that a solution could be to turn off GLONASS. In any case, I was having the same problem before, when GLONASS was on.

Could you share the Simple System report from the device with me so that I can check the settings?

Here they are:
BASE:

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: FC:DB:B3:99:59:71
  security: wpa-psk
  ssid: BrianReachRSBase:59:71
  uuid: 29d5a5e2-d41d-4725-8f05-c2891e535266
base mode:
  base coordinates:
    accumulation: 1
    antenna offset:
      east: '0'
      north: '0'
      up: '0'
    coordinates:
    - 0
    - 0
    - 0
    format: llh
    mode: single-and-hold
  output:
    enabled: true
    format: rtcm3
    path: lora
    type: lora
  rtcm3 messages:
    '1002':
      enabled: true
      frequency: 1
    '1006':
      enabled: true
      frequency: 0.10000000000000001
    '1010':
      enabled: false
      frequency: 1
    '1097':
      enabled: false
      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: false
    format: rtcm3
    path: ttyMFD2:38400:8:n:1:off
    send position to base: 'off'
    type: serial
  input3:
    enabled: false
    format: RTCM3
    io_type: tcpsvr
    path: :9028
device: null
logging:
  base:
    format: RTCM3
    started: true
  correction:
    format: RTCM3
    started: true
  debug: false
  interval: 24
  overwrite: true
  raw:
    format: UBX
    started: true
  solution:
    format: LLH
    started: true
lora:
  air rate: 2.6000000000000001
  frequency: 902000
  mode: read
  output power: 20
position output:
  output1:
    enabled: false
    format: nmea
    path: bluetooth
    type: bluetooth
  output2:
    enabled: true
    format: llh
    path: :9001
    type: tcpsvr
rtk settings:
  elevation mask angle: 15
  glonass ar mode: 'off'
  gps ar mode: fix-and-hold
  max horizontal acceleration: 1
  max vertical acceleration: 1
  positioning mode: kinematic
  positioning systems:
    compass: false
    galileo: true
    glonass: false
    gps: true
    qzss: true
    sbas: true
  snr mask: 35
  update rate: 1

ROVER:

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: FC:DB:B3:9D:FA:05
  security: wpa-psk
  ssid: BrianReachRSRover:fa:05
  uuid: 5d82cac2-92b9-4215-86d2-663af1df3f03
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: tcpsvr://:9000#rtcm3
    type: tcpsvr
  rtcm3 messages:
    '1002':
      enabled: true
      frequency: 1
    '1006':
      enabled: true
      frequency: 0.10000000000000001
    '1010':
      enabled: false
      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: RTCM3
    started: true
  correction:
    format: RTCM3
    started: true
  debug: false
  interval: 24
  overwrite: true
  raw:
    format: UBX
    started: true
  solution:
    format: LLH
    started: true
lora:
  air rate: 18.23
  frequency: 902000
  mode: read
  output power: 20
position output:
  output1:
    enabled: false
    format: nmea
    path: bluetooth
    type: bluetooth
  output2:
    enabled: true
    format: llh
    path: :9001
    type: tcpsvr
rtk settings:
  elevation mask angle: 15
  glonass ar mode: 'off'
  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: 10
  update rate: 1

Could you clarify if you enabled only GPS corrections while testing the setup?

I limited satellites in this last test because a theory earlier in this thread was that data was overloading the LoRa transmission rate. I believe I had set up satellite constellations to be the same on both units for the test, however I see in the Simple System Report that one of the units at the moment has more satellite constellations turned on than the other does. I don’t know what to say about that.

I’ll wait for your suggestions and then run another test. Thanks.

Hi Brian,

I have checked the files once again. The BASE_raw_202005072256_UBX (1).zip and ROVER_A_raw_202005072256_UBX.zip have the same size (1.1 MB). I downloaded them, unzipped and compared using the diff command, and there is no difference between the two.

Could you re-check the files on your base once more so that I can compare the base UBX with RTCM corrections the rover gets from it?

I’ve also sent you another test description in PM. It’d be nice if you have a chance to accomplish it.

Tatiana, ok, today I had time to download the log files again from the Base unit and from the Rover unit. They are at this link. 2020 05 25 Reach logs - Google Drive

You separately sent me a PM to reflash to an older driver but I won’t have time to do this until later. For now, if you can look at the files at the link above, this will be helpful. Thank you.

A post was split to a new topic: Issues with getting fix

Ok, reflashing the units with v2.18.1 allows me to survey RTK. When I break the connection between base and rover (obstructions/powerlines/trees), and then reconnect, it takes about 4 minutes to get back to Fix (back to AR in the hundreds instead of below 3). But, I can survey RTK.

Hi Brian,

We’re looking into this issue in the meantime and conducting our own tests on it. Once we have any news, I get back.

Hi Brian,

We’ve released the v2.22.5 firmware version for Reach RS+/RS devices improving the RTK performance stability. Updating the unit to this version should resolve the issues you experienced.

It’d be nice if you have a chance to try it and share the feedback.

1 Like

On the Reach RS when I go to settings it says only v2.20.8 is available. I enable dev updates and it actually goes backward and says only v2.18.1 is available. So I have unsubcribed from dev updates, and for now I’ll stay with v2.18.1 unless there is some hidden way to get v2.22.5 flashed onto my Reach RS. Thanks.

Hi Brian,

To update the device from the v2.20.8 version to any higher one, you need to reflash it. You can follow this guide to accomplish it.

The v2.22.5 firmware version for Reach RS is available for download here.

1 Like

Ok, this seems to be working now. Thanks much for your patience and help.

1 Like