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?)
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
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).
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