you are right,i do only 2-3 min. to compare each settings
but i dont understand why GPS+BEIDOU give more sat. than GPS+Galileo+BEIDOU
and it was a same pattern while the (fallen) ROVER get correction input via CORS.
Thank you
1 Like
Do not compare your base to your rover. 
!= 
Especially do not compare from one screen only.
Compare them both as rover to do a proper comparison! =
Configure each RS+ as a rover, single mode, all constellations enabled. Wait 5 minutes to make sure all satellites in the sky have been found. Then open ReachView for each RS+ and look at # of satellites and post a screenshot of each RS+.
Also post your raw log files from both units if you can. If you want to do a really good test, then after configuring them both as rover with equal settings and raw log enabled. Then turn them both off and place beside each other. Then turn both on at the same time; wait 10 minutes, then turn both off again. Now you have produced 2 log files with equal settings. We can make the best comparison using that data.
6 Likes
Such a genius that bide is.
; )
1 Like
I just did what suggested
and get a good results
setup
and this is results the fallen reach is RP2, the good reach is PK1
and i will do more combination of GNSS setting
THANK YOU , you all for the help
1 Like
Everything looks good here too. The images below were created by 1) converting your raw (UBX) files to RINEX with RTKCONV, then 2) viewing with RTKPLOT. Left picture is PK1; right picture is RP2.
Green = Number of SATellites (NSAT); other colours are Dilution of Precision (DOP)
Satellite Visibilty
Skyplot
Signal to Noise Ratio (SNR) and Satellite ELevation (EL)
2 Likes
I post-processed the data with PK1 as base and RP2 as rover. For the base coordinate I used an average of the single-mode position.
97.4% fix was achieved with the best static processing settings:
These were the settings used:
- static
- continuous
- combined
- 15degree
- 35SNR
- GPS, SBAS constellations
For a more real comparison to default RTK settings (with Beidou instead of Glonass), I was surprised to see that the solution didn't fix (98.2% float):
The light green dot is the first GPS/SBAS fix and the darker green is the float solution just produced.
After several tries, I found that eliminating either Galileo or Beidou would allow for a rapid fixed solution.
This solution without Galileo was fixed after 24 seconds with 89.7% fix for the log. Here the brown is the kinematic fix, and for comparison, you can see the first GPS-SBAS static fix in green within the kinematic point cloud.
These were the settings used:
- kinematic
- fix-and-hold
- forward
- 15degree
- 35SNR
- all constellations except Galileo (GPS, QZSS, SBAS, BEI)
This solution without Beidou was fixed after 22 seconds with 89.6% fix for the log. Here the brown is the kinematic fix, and for comparison, you can see the first GPS-SBAS static fix in green within the kinematic point cloud.
These were the settings used:
- kinematic
- fix-and-hold
- forward
- 15degree
- 35SNR
- all constellations except Beidou (GPS, GAL, QZSS, SBAS)
I am not sure why Beidou and Galileo are not cooperating here, but @bizzdoh, if you find that you are getting all float solution, then I would recommend turning off either Galileo or Beidou. For these log files, there were many more Beidou satellites visible, so if it were me, I would probably eliminate Galileo. You could just turn off the constellation in the rover RTK settings, but it might be better to disable the base RTCM3 message instead. That way you could keep the constellation enabled and log the raw data for later use if necessary.
That should solve the problem of never getting an RTK fix. Actually it is more of a workaround than a solution, but maybe we can find out more about this apparent issue between Galileo and Beidou.
The other thing not tested here (because there is no data in the log files) is to substitute Glonass for Beidou.
The post-processing software used to produce these results was:
6 Likes
thank you very much for A LOT of information which I didn’t know before. such as
- example settings for static process
- RTK Settings affect the raw file (i think every sat are in the log)
- Galileo/BeiDou issue
so I will do more test
2 Likes
Dear Bide,
I try to process data as suggested
1.Static > I have 97.4% fix but a little different in shape …
2.PPK with GPS+Galileo+BeiDou+QZSS+SBAS > I have 99.2% fix , what i missed ?
- this is my setting
- this is pos file RP2_raw_201905280212_PPK1.pos (492.8 KB)
rtklib
Hello Pat,
I had an opportunity to download your settings and POS file today.
If I post-process with your settings file and the Windows version of RTKLIB, then I get 99.2% fixed exactly like you got.
If I do the same with your settings file and the Linux version of RTKLIB, then I get 60.2% fixed.
If I do the same by reading your settings file and making all my settings the same, then I get 98.2% float.
So there is something wrong. Of course I could have made a mistake, but it seems that the Linux version is maybe not selecting or saving the settings correctly. Further investigation would be helpful I think.
How is your surveying now? Are you able to get a fix quickly? Do you have all constellations enabled, or do you have to disable one to make it work?
3 Likes
Both looks good quick fix via LoRa in RTK but limit distance so best in PPK, and my RTK Settings is GPS/BeiDou/QZSS/SBAS/Galileo at 5hz
for LoRa I choose every constellation (except QZSS consume too much bandwidth) at 0.5hz and GPS 1.0 hz so in RTK i missed only 1-2 sat from QZSS
Thank you
2 Likes
All, is it normal to run Beidou, QZSS and SBAS at the same time. From what I have learned, depending on where you are geographically these constellations interact with each other very little so you are unlikely to get good information from them all at the same time. Unless you are in Japan down to Australia??? Just seems like an unneeded liability to me.
2 Likes
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.