I have another problem though, our new RS+ pictured above has some strange problems:
I guess I lost that day of work and the 220 ha flight completely.
1 Like
Hm, so the base suddenly lost everything? Also in the UBX or ?
No, the base (a good old Reach RTK) has 25-28 sats all the day. Only the new RS+ which was used as rover lost everything. The graph shows the data from the ubx file with two reboots.
I only do PPK, the base and the rover are not connected.
So you changed the number of constellation or? It seems wierd indeed.
Remember to do a Full system report if it happens to you again.
//Christian
No, I did nothing, the RS+ did something. The settings are still the same. And I don’t see how changing settings could influence the raw log like that. As you can see the sats come and go. Something is weird with the device.
Could you please split the topic?
Hi Tobias,
Do I understand correctly that the unit behaves that way from scratch? Can you share raw data and position logs recorded on the device?
What Reachview version on the new unit? I had similar behavior on my rover the other day see below. Seemed to be a software issue to me. My base had full sats as you described too…
1 Like
That is bad, its version 2.20.8-r0. I payed 350 € to my assistant to do the survey… . And the flight (220 ha) cannot be repeated. You can imagine the loss. Its a mess if the things do not work.
Simple system report
app version: 2.20.8-r0
'wifi_status, interface: wlan0':
- wifi_mode: infrastructure
- ip: 192.168.178.143
is_added: true
is_connected: true
is_visible: false
mac_address: 6C:21:A2:8F:9A:C2
security: wpa-psk
ssid: WLAN***
uuid: eb3c05b5-0116-4da9-b09e-3bbe16439eed
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.1'
'1010':
enabled: true
frequency: '1'
'1097':
enabled: false
frequency: '1'
'1107':
enabled: false
frequency: '1'
'1117':
enabled: false
frequency: '1'
'1127':
enabled: false
frequency: '1'
bluetooth:
discoverable: false
enabled: false
pin: '***'
correction input:
input2:
enabled: false
format: rtcm3
path: 192.168.42.1:9000
send position to base: single
type: tcpcli
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: true
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: true
format: llh
path: :9001
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: '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: true
galileo: true
glonass: false
gps: true
qzs: true
qzss: false
sbas: false
snr mask: '35'
update rate: '5'
But I have beautiful pictures now.
I can attest to the lost, it is a sad day.
Was rover for GCPs? You can still process though into model as imagery was taken right?
1 Like
Yes, I have the pictures. I have to go there again an measure “natural” GCPs. I have never reached the necessary accuracy without them. And I need the confidence.
The problem is the water, the area is extremely difficult to access and the water level is high again.
But yes, complete loss is an exaggeration. Its frustrating and costs 1 to 2 days of additional work for two people.
Up to now the original Reach RTK never failed on me. I think EMLID should introduce a very low level raw data recording which is not influenced by the fancy and beautiful ReachView.
1 Like
Same version 2.18.0. Below is my simple system report. I changed RTK settings towards end as was trying to recover mysteriously missing satellites. Seemed a relationship existed when certain combinations were turned on or off. So maybe some RTKLib code faults in this version?
Simple system report
app version: 2.18.0-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: 44:2C:05:FE:9C:21
security: wpa-psk
ssid: reach:87:A2
uuid: 573893a1-453a-4839-8012-e93ab281b844
base mode:
base coordinates:
accumulation: '0.1'
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: '0.5'
'1006':
enabled: true
frequency: '0.1'
'1010':
enabled: true
frequency: '0.5'
'1097':
enabled: true
frequency: '0.5'
'1107':
enabled: true
frequency: '0.5'
'1117':
enabled: false
frequency: '0.5'
'1127':
enabled: false
frequency: '1'
gps:
enabled: false
frequency: '0.5'
qzss:
enabled: false
frequency: '0.5'
bluetooth:
discoverable: false
enabled: false
pin: '***'
correction input:
input2:
enabled: true
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: true
version: null
interval: 24
overwrite: true
raw:
format: UBX
started: false
version: null
solution:
format: LLH
started: false
version: null
lora:
air rate: '9.11'
frequency: 928000
output power: '20'
position output:
output1:
enabled: false
format: nmea
path: bluetooth
type: bluetooth
output2:
enabled: false
format: llh
path: :9001
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: '15'
glonass ar mode: 'on'
gps ar mode: continuous
max horizontal acceleration: '1'
max vertical acceleration: '1'
positioning mode: kinematic
positioning systems:
compass: false
galileo: false
glonass: true
gps: true
qzs: true
qzss: false
sbas: false
snr mask: '35'
update rate: '1'
Maybe Beidou?
1 Like
I like that idea if possible. Two raw logs one uninfluenced by RTK settings and records everything in the sky. The other log as we have now which we can influence in Reachview.
You are using another version. The version you are using is on my Reach RTK devices, I fear (I have updated it to the point where the manual flashing would be the next step).
I have another job on Saturday and need to know which version is save.
I do not recall my original RTK settings when first set up. Typically I do not use Beidou.
Aw yes sorry I misread. This may be issue from versions upwards from there then… Anybody else here have similar issues and if so please share which version so @tobias-dahms can have confidence again.
1 Like
That would be great and would also help Emlid. I would especially be interested in the receiver types too.
I thought qzs must be Beidou?
I thought compass but you may be right. What is QZS vs QZSS?
I think that is the SBAS equivalent for QZS.
Are there no other people using Beidou or having the same issue?
I think it has some relevance and there should be some focus on it since people also flying drones with the system mounted. If there is a problem with all receivers Emlid should publish an information about to warn people.
Or is this problem only connected to the RS+?