In the introduction of the previous article, through five-step analysis, the RTK ambiguity fixation rate and positioning accuracy were gradually improved. If the test is not ok according to the configuration in the previous chapter, then I can definitely say that it is caused by poor data quality. When the newly collected data is used with the configuration in the previous chapter, the effect is not very satisfactory. The following describes the specific situation.
The data I released this time is rover's ubx and base's rtcm, using rtkconv to convert the format, and then using rtkpost for processing, there should be the following problems: (1) Select GPS/BDS, BDS satellite is not used; (2) If If BDS satellites are available, you will find that when BDS satellites are added, the ambiguity fixed rate becomes lower.
Regarding the problems that arise, we must ask ourselves,
1) What is the problem?
2) What is the cause of the problem?
3) How to solve this problem?
In response to the problem (1) , you can open level 3 through trace to find that the bds ephemeris does not exist, debug and view the ephemeris file, and find that the BDS satellite ephemerides are available, updated every 1h, no problem, it seems that the problem is not in the ephemeris . Although there are many BDS satellites, base and rover share the BDS satellites, combined with the ephemeris file, you will find that only three satellites are available, C09 C13 C16, and then continue to check zdres, let me find the problem, BDS satellite The carrier and pseudorange observations of f1 do not exist, and they ran out of the f2 array, and changed 2 to 1 in the header file of the o file, so rtkconv had a bug when converting the data, and there was no time to check , Also simple, go directly to the corresponding app folder to check.
For problem (2) , it needs to be analyzed slowly.
step1 : Assuming that problem 1 is not solved, it is actually running a single GPS to see what the result looks like
. As you can see from the above figure, the observation arc "jumps randomly" after 8:00. Generally, this situation is satellite snr jitter As a result, you can look at rover's G18 satellite.
step2 : Below is the snr of G18. It can be seen that during the ascending process, the altitude angle is gradually increasing. Disable G18 first and see how the result is.
Compare the fixed rate of ambiguity before and after it is disabled. If there is an improvement, the specific value is not written.
step3: Adding the Beidou system at this time, the configuration and results are as follows.
Adding the Beidou satellite, our results have become worse. What is the reason? First consider the data quality problem. I still use the carrier to do the difference plus the Doppler of the current epoch, and use matlab to plot. I found that the data quality of the 3 Beidou satellites is unstable. When it is good, it is good, when it is bad, it is not normal. The difference is like gf when receiving a gift and gf when quarreling. The specific method has been described in the previous chapter, so I won't repeat it. When the data quality is good, I will use it. When the quality is not good, I will discard it. Well, at this time, the cycle slip detection will be available. The specific code is in udbias. I will directly release the screenshots and results of my code changes.
This function was originally disabled. Because of the clock jump problem, you only need to identify the clock jump. The receiver I use I know the magnitude of the clock difference. Yes, the carrier generated on the arm has an ambiguity bug at that time, which is the clock jump. Caused, I changed it, 1ms. This is easy to handle, click, click, the change can be used, and the result is also a big improvement. Of course, the ambiguity of 14% is not fixed. I am still debugging. I first released the o file of the Chihiro base station, and I knew the reason why the fix suddenly changed to float in a certain epoch.
At the same time cycle jump! ! !
So what I want to check is the reason why it is not fixed before 7:00. If it is resolved, add it.
-----------------------Dividing line----------------------
Updated on 202009024
I have directly transferred the data, link: https://pan.baidu.com/s/1PCnWLcl43JmkNAeNicA1Yw
Extraction code: 2r0h
In rtklib, the initial value of Kalman filter is calculated by a single point, then we can also directly pass it The solution obtained in the previous epoch is used as the initial value of the Kalman filter of the current epoch. Just change it in udpos.
Is the result picture improved? Hahaha