The green/yellow points are from the *.stat file. The blue/brown is from the output file, which contain final coordinates. I set solstatic=all for this example. As it is fast-static and the KF was very long to converge, I used the combined-no-reset option and I finally got the ambiguity fixed.
Instinctively I though the positions calculated everywhere the points are green are the good one and the float solution shouldn’t be taken into account. But actually, rtklib seems to make a mean between float and fixed solution, what I don’t really understand.
More surprising again, the final position is closer to the backward solution when this solution is floating (07:53:00, and after 07:55:30) than when it is fixed.
Is this behaviour is intentional I don’t understand it at all, and I really need further explanation. If not, how it is possible to get rid of it ?
Thank you very much.
pos1-posmode =static # mode (0:single - SPP (rover only) or SBAS DGPS;
# 1:dgps - Code-based differential GNSS;
# 2:kinematic - PPK (phase based, moving rover, static base);
# 3:static - phase based, static rover and base;
# 4:static-start - static til first fix, then kinematic
# 5:moving-base - phase based, moving rover and base;
# 6:fixed - phase based, static rover and base with known position);
# 7:ppp-kinematic - phase based, moving rover, no base;
# 8:ppp-static - phase based, static rover, no base.
pos1-frequency =l1+l2 # (1:l1,2:l1+l2,3:l1+l2+l5,4:l1+l2+l5+l6)
pos1-soltype =combined-nophasereset # (0:forward,1:backward,2:combined,3:combined-nophasereset)
pos1-elmask =15 # (deg)
pos1-snrmask_r =off # Use rover SNR filter (0:off,1:on)
pos1-snrmask_b =off # Use base SNR filter (0:off,1:on)
pos1-snrmask_L1 =35,35,35,35,35,35,35,35,35
pos1-snrmask_L2 =35,35,35,35,35,35,35,35,35
pos1-snrmask_L5 =35,35,35,35,35,35,35,35,35
pos1-dynamics =on # Wether velocity and accelaration are estimated (0:off,1:on)
pos1-tidecorr =off # Use tide correction (0:off,1:on,2:otl)
pos1-ionoopt =sbas # (0:off,1:brdc,2:sbas,3:dual-freq,4:est-stec,5:ionex-tec,6:qzs-brdc)
pos1-tropopt =sbas # (0:off,1:saas,2:sbas,3:est-ztd,4:est-ztdgrad)
pos1-sateph =precise # (0:brdc,1:precise,2:brdc+sbas,3:brdc+ssrapc,4:brdc+ssrcom)
pos1-posopt1 =off # Use satellite antenna PCV model (0:off,1:on)
pos1-posopt2 =off # Use receiver antenna PCV model (0:off,1:on)
pos1-posopt3 =off # Use phase windup correction (0:off,1:on,2:precise)
pos1-posopt4 =off # Exclude GPS Block IIA in eclipse (0:off,1:on)
pos1-posopt5 =off # Exclude satellite if SSE is over a threshold (0:off,1:on)
pos1-posopt6 =off # Use day boundary clock jump correction (0:off,1:on)
pos1-exclsats =G11 G12 # Satellite to exclude/include, separate by space.
pos1-navsys =15 # (1:gps+2:sbas+4:glo+8:gal+16:qzs+32:bds+64:navic)
pos2-armode =fix-and-hold # (0:off,1:continuous,2:instantaneous,3:fix-and-hold)
pos2-gloarmode =autocal # (0:off,1:on,2:autocal,3:fix-and-hold)
pos2-bdsarmode =on # (0:off,1:on)
pos2-arfilter =on # Require AR qualification of new or retunring satellites after cycle slip (0:off,1:on)
pos2-arthres =3.80
pos2-arthresmin =3.80
pos2-arthresmax =3.80
pos2-arthres1 =0.1
pos2-arthres2 =0
pos2-arthres3 =1e-09
pos2-arthres4 =1e-05
pos2-arlockcnt =240 # Minimum lock count for integer ambiguity
pos2-arelmask =30 # Minimum elevatino for integer ambiguity(deg)
pos2-arminfix =240 # In fix-and-hold, minimum fix count for integer ambiguity
pos2-elmaskhold =15 # In fix-and-hold, minimum elevation for integer ambiguity(deg)
pos2-dopthres =0 # (m)
pos2-slipthres =0.05 # (m)
pos2-maxage =30 # (s)
pos2-aroutcnt =5
pos2-rejcode =10 # (m)
pos2-rejionno =2 # (m)
pos2-niter =1
pos2-syncsol =off # (0:off,1:on)
pos2-baselen =0 # (m)
pos2-basesig =0 # (m)
pos2-minfixsats =4
pos2-minholdsats =5
pos2-mindropsats =10
pos2-varholdamb =0.1 # (cyc^2)
pos2-gainholdamb =0.01
pos2-armaxiter =1
out-solformat =llh # (0:llh,1:xyz,2:enu,3:nmea)
out-outhead =on # (0:off,1:on)
out-outopt =on # (0:off,1:on)
out-outvel =off # (0:off,1:on)
out-timesys =utc # (0:gpst,1:utc,2:jst)
out-timeform =hms # (0:tow,1:hms)
out-timendec =6
out-degform =deg # (0:deg,1:dms)
out-fieldsep =,
out-height =geodetic # (0:ellipsoidal,1:geodetic)
out-geoid =egm08_1 # (0:internal,1:egm96,2:egm08_2.5,3:egm08_1,4:gsi2000)
out-solstatic =all # (0:all,1:single)
out-nmeaintv1 =0 # (s)
out-nmeaintv2 =0 # (s)
out-outstat =residual # (0:off,1:state,2:residual)
out-outsingle =off # (0:off,1:on)
out-maxsolstd =0 # (m)
stats-eratio1 =300
stats-eratio2 =300
stats-eratio5 =300
stats-errphase =0.005 # (m)
stats-errphaseel =0.005 # (m)
stats-errphasebl =0 # (m/10km)
stats-errsnr =0 # (m)
stats-snrmax =52 # (dB.Hz)
stats-errrcv =0 # ( )
stats-errdoppler =1 # (Hz)
stats-prnaccelh =3 # (m/s^2)
stats-prnaccelv =1 # (m/s^2)
stats-prnbias =0.0001 # (m)
stats-prniono =0.001 # (m)
stats-prntrop =0.0001 # (m)
stats-clkstab =5e-12 # (s/s)
stats-stdbias =30 # (m)
stats-stdiono =0.03 # (m)
stats-stdtrop =0.3 # (m)
stats-prnpos =0 # (m)
#ant1-postype =llh # (0:llh,1:xyz,2:single,3:posfile,4:rinexhead,5:rtcm)
#ant1-pos1 =90 # (deg|m)
#ant1-pos2 =0 # (deg|m)
#ant1-pos3 =-6335367.6285 # (m|m)
ant1-anttype =
ant1-antdele =0 # (m)
ant1-antdeln =0 # (m)
ant1-antdelu =2.056 # (m)
ant2-postype =rinexhead # (0:llh,1:xyz,2:single,3:posfile,4:rinexhead,5:rtcm)
#ant2-pos1 =0 # (deg|m)
#ant2-pos2 =0 # (deg|m)
#ant2-pos3 =0 # (m|m)
ant2-anttype =
ant2-antdele =0 # (m)
ant2-antdeln =0 # (m)
ant2-antdelu =0 # (m)
ant2-maxaveep =1
ant2-initrst =on # (0:off,1:on)
misc-timeinterp =on # (0:off,1:on)
misc-sbasatsel =0 # (0:all)
misc-rnxopt1 =
misc-rnxopt2 =
misc-pppopt =
file-staposfile =
file-satantfile =
file-rcvantfile =
file-geoidfile =RAF20.dac # Grille de conversion alti
file-ionofile =
file-dcbfile =
file-eopfile =
file-blqfile =
file-tempdir =
file-geexefile =
file-solstatfile =
file-tracefile =
Hello,
I am not sure if it is a bug or if I don’t understand the behaviour of
rnx2rtkpbut:The green/yellow points are from the *.stat file. The blue/brown is from the output file, which contain final coordinates. I set
solstatic=allfor this example. As it is fast-static and the KF was very long to converge, I used thecombined-no-resetoption and I finally got the ambiguity fixed.Instinctively I though the positions calculated everywhere the points are green are the good one and the float solution shouldn’t be taken into account. But actually, rtklib seems to make a mean between float and fixed solution, what I don’t really understand.
More surprising again, the final position is closer to the backward solution when this solution is floating (07:53:00, and after 07:55:30) than when it is fixed.
Is this behaviour is intentional I don’t understand it at all, and I really need further explanation. If not, how it is possible to get rid of it ?
Thank you very much.
PS: here is the config file if needed: