Hi! I’m from Poland. I am currently testing RS2. I have a problem because only Beidou corrections don’t work in RTN measurement (satellites are visible but are not taken for resolution). What could be the reason? I currently have version 2.21.2 installed.
I think it’s a hardware problem.
How do you see that they aren’t used?
What is your NTRIP source?
here in Argentina Galileo corrections work badly, I don’t know if it’s something that happens to all users. The gray bars on some E satellites have not been noticed for months with NTrip corrections
I can see in Quick Gnss or SurvCE software (satellites are visible but not used for calculations).
Used from the “RtkNet” provider. I also checked “Nadowski” and “VRSNet” providers. In any case, there are no corrections with Beidou. I also inserted a sim card and connected to NTRIP. After choosing the RTCM32-MSM mount point, I can see that corrections from all constellations are provided by the supplier (in ReachView format 1124).
So I think the problem is in RS2!
Hi @marcin,
Please, share the following data with us:
- Simple System report
- The screenshot of the Correction input tab while Reach is getting corrections. Please click on “∨” button to show the list of messages Reach accepts from the caster
Are you certain your RTN correction source support Beidou? Here we have a public RTN service but it only supports (the receiver only records) GPS and GLONASS. So for RTN on this network, I never see any Galileo or Beidou satellites considered in the calculation.
This seems to me like your situation would be expected if it is similar to ours.
Corrections are 4 systems. There is no problem on other professional receivers (I will not exchange brands).
Below is the Simple System report and screenshots
Simple system report
app version: 2.20.8-rs2-r0
'wifi_status, interface: wlan0':
- wifi_mode: infrastructure
- ip: 192.168.43.196
is_added: true
is_connected: true
is_visible: false
mac_address: 6C:21:A2:93:27:F6
security: open
ssid: Marcin
uuid: 085bec88-61ba-4685-a2a5-2baf33fcb562
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:
'1006':
enabled: true
frequency: '0.1'
'1074':
enabled: true
frequency: '1'
'1084':
enabled: true
frequency: '1'
'1094':
enabled: true
frequency: '1'
'1124':
enabled: true
frequency: '1'
bluetooth:
discoverable: true
enabled: true
pin: '***'
correction input:
input2:
enabled: true
format: rtcm3
path: geocad:***@[185.172.87.119:2101/RTCM32-MSM](http://185.172.87.119:2101/RTCM32-MSM)
send position to base: single
type: ntripcli
input3:
enabled: false
format: rtcm3
path: :9028
type: tcpsvr
logging:
base:
format: RTCM3
started: true
version: null
correction:
format: RTCM3
started: true
version: null
interval: 24
overwrite: true
raw:
format: UBX
started: true
version: null
solution:
format: LLH
started: true
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: 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: '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: true
gps: true
qzss: true
snr mask: '35'
update rate: '1'
Hi @marcin,
As I can see from the screenshot, Reach is getting corrections for B10 and B14 satellites from the base. May I ask you to clarify why do you think they’re not used in the computation?
1 Like
This is the result of the geodetic program (quick gnss and survce).
I use the receiver only in RTK mode. Base mode is off, so why are the gray bars displayed when base mode is off?
I don’t know if it’s a language issue or if I misunderstand your point, but why would base mode being enabled or disabled affect correction input (grey bars being indicative of this)? They are not really related. Base mode is to transmit a correction, correction input to receive it.
I wrote to the software manufacturer quickgnss to check why beidou is missing. I got the answer: “The file you sent is raw data in the form of NMEA protocol sent by the GNSS receiver via Bluetooth. In the file you sent there is no log beginning with” BD ", which means that the receiver does not send information about Beidou satellites. The ReachView application you use works via WiFi and uses a different protocol, therefore it can display information about Beidou satellites. We suggest that you ask the manufacturer to update the receiver’s firmware so that data on Beidou satellites are also sent via Bluetooth. "
If necessary, I will attach the NMEA file
1 Like
Am I understanding correctly that your issue was in external software through Bluetooth, and not in ReachView?
If this is the case, the reason no one could understand is because there was no explicit mention of the problem being in external software and it seems everybody thought you were having the problem in ReachView.
1 Like
In the second post I wrote that the problem concerns quick gnss and survce software. There is also the same problem in Fieldgenius. I am sorry if I write incomprehensibly (my English is not good).
As I mentioned - the problem probably concerns sending data via bluetooth, in which data from Beidou is missing. I am asking the Emlid team to check this problem.
Hi @marcin,
On the v2.21.2 firmware version, Reach outputs GBGSV and GBGSA strings in the NMEA message. They contain information about BeiDou satellites in the viewing mask. This is the latest NMEA-0183 v4.11 standard.
It seems that the app you use expects GSV and GSA strings with BD talker ID, which corresponds to the NMEA-0183 v4.10.
We are working on adding support for various NMEA versions.
7 Likes
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.