dmiralles2009
commented
5 years ago As a follow up I can also confirm that this is also happening in my case, it works with 'b29' but fails with 'b31'. It seems like if the reading of the RINEX observation files errors when dealing with BeiDou satellites. In my case I have a RINEX 3.03 file with mixed observations. At a given epoch the observation file looks like this:
> 2018 9 19 20 49 15.0569599 0 20
G10 39566007.223 -569066.5840 2019.280 45.977
G13 40096681.545 783784.2650 -2898.079 41.952
G15 37710509.258 292687.3210 -1142.761 48.942
G16 41639748.402 568655.3480 -2120.905 38.118
G20 37725205.983 -298700.2560 1026.784 47.174
G21 38041915.430 -129995.8610 426.134 46.379
G24 41432882.912 -679314.2010 2444.149 38.508
G27 40618015.833 -698431.5000 2473.112 37.469
G29 39848587.697 1080556.4370 -3909.816 48.550
R06 38657787.171 -790405.1020 2824.863 34.541
R13 41558176.073 -187803.9061 597.781 25.281
R05 36264984.674 195431.1020 -801.758 48.660
R20 36294870.384 -40571.3620 38.910 42.748
R19 38500402.126 1035136.1320 -3831.783 42.317
R21 38967123.522 -957433.9840 3457.638 44.724
C11 42267974.290 865852.7010 -3646.506 41.044
C14 39132748.662 401848.7090 -1826.686 45.702
C21 42867453.679 666582.4990 -3221.231 37.683
C26 43155717.019 -299182.5950 1516.293 30.559
C28 39041309.264 307334.0500 -1659.236 47.342When using 2.4.3_b31, the pos.trace file with the highest level of debuggin looks like this
3 infunc : revs=0 iobsu=5261 iobsr=18071 isbs=0
3 rtkpos : time=2018/09/19 20:49:15.057 n=14
4 obs=
( 1) 2018/09/19 20:49:15.057 G10 rcv1 -569066.584 0.000 39566007.223 0.000 0 0 1 0 46.0 0.0
( 2) 2018/09/19 20:49:15.057 G13 rcv1 783784.265 0.000 40096681.545 0.000 0 0 1 0 42.0 0.0
( 3) 2018/09/19 20:49:15.057 G15 rcv1 292687.321 0.000 37710509.258 0.000 0 0 1 0 49.0 0.0
( 4) 2018/09/19 20:49:15.057 G16 rcv1 568655.348 0.000 41639748.402 0.000 0 0 1 0 38.0 0.0
( 5) 2018/09/19 20:49:15.057 G20 rcv1 -298700.256 0.000 37725205.983 0.000 0 0 1 0 47.2 0.0
( 6) 2018/09/19 20:49:15.057 G21 rcv1 -129995.861 0.000 38041915.430 0.000 0 0 1 0 46.5 0.0
( 7) 2018/09/19 20:49:15.057 G24 rcv1 -679314.201 0.000 41432882.912 0.000 0 0 1 0 38.5 0.0
( 8) 2018/09/19 20:49:15.057 G27 rcv1 -698431.500 0.000 40618015.833 0.000 0 0 1 0 37.5 0.0
( 9) 2018/09/19 20:49:15.057 G29 rcv1 1080556.437 0.000 39848587.697 0.000 0 0 1 0 48.5 0.0
(10) 2018/09/19 20:49:15.057 C11 rcv1 0.000 865852.701 0.000 42267974.290 0 0 0 40 0.0 41.0
(11) 2018/09/19 20:49:15.057 C14 rcv1 0.000 401848.709 0.000 39132748.662 0 0 0 40 0.0 45.8
(12) 2018/09/19 20:49:15.057 C21 rcv1 0.000 666582.499 0.000 42867453.679 0 0 0 40 0.0 37.8
(13) 2018/09/19 20:49:15.057 C26 rcv1 0.000 -299182.595 0.000 43155717.019 0 0 0 40 0.0 30.5
(14) 2018/09/19 20:49:15.057 C28 rcv1 0.000 307334.050 0.000 39041309.264 0 0 0 40 0.0 47.2However, when doing the processing with 2.4.3_b29 the same pos.trace file with the highest level of debugging looks like this:
3 infunc : revs=0 iobsu=5261 iobsr=18071 isbs=0
3 rtkpos : time=2018/09/19 20:49:15.057 n=14
4 obs=
( 1) 2018/09/19 20:49:15.057 G10 rcv1 -569066.584 0.000 39566007.223 0.000 0 0 1 0 46.0 0.0
( 2) 2018/09/19 20:49:15.057 G13 rcv1 783784.265 0.000 40096681.545 0.000 0 0 1 0 42.0 0.0
( 3) 2018/09/19 20:49:15.057 G15 rcv1 292687.321 0.000 37710509.258 0.000 0 0 1 0 49.0 0.0
( 4) 2018/09/19 20:49:15.057 G16 rcv1 568655.348 0.000 41639748.402 0.000 0 0 1 0 38.0 0.0
( 5) 2018/09/19 20:49:15.057 G20 rcv1 -298700.256 0.000 37725205.983 0.000 0 0 1 0 47.2 0.0
( 6) 2018/09/19 20:49:15.057 G21 rcv1 -129995.861 0.000 38041915.430 0.000 0 0 1 0 46.5 0.0
( 7) 2018/09/19 20:49:15.057 G24 rcv1 -679314.201 0.000 41432882.912 0.000 0 0 1 0 38.5 0.0
( 8) 2018/09/19 20:49:15.057 G27 rcv1 -698431.500 0.000 40618015.833 0.000 0 0 1 0 37.5 0.0
( 9) 2018/09/19 20:49:15.057 G29 rcv1 1080556.437 0.000 39848587.697 0.000 0 0 1 0 48.5 0.0
(10) 2018/09/19 20:49:15.057 C11 rcv1 865852.701 0.000 42267974.290 0.000 0 0 47 0 41.0 0.0
(11) 2018/09/19 20:49:15.057 C14 rcv1 401848.709 0.000 39132748.662 0.000 0 0 47 0 45.8 0.0
(12) 2018/09/19 20:49:15.057 C21 rcv1 666582.499 0.000 42867453.679 0.000 0 0 47 0 37.8 0.0
(13) 2018/09/19 20:49:15.057 C26 rcv1 -299182.595 0.000 43155717.019 0.000 0 0 47 0 30.5 0.0
(14) 2018/09/19 20:49:15.057 C28 rcv1 307334.050 0.000 39041309.264 0.000 0 0 47 0 47.2 0.0It seems like the observation readings for BeiDou has an additional zero column that simply offsets the true measurements. I hope this helps in fixing the issue at hand.
Thansk in advance
Hi, While post processing data collected using 2 uBlox NEO-M8T receivers (GPS and BeiDou enabled), it was noticed that switching on or off the BeiDou constallation doesn't have any effect in RTKPOST. It produced solution using only GPS satellites. I tried the same files & settings with RTKPOST from 2.4.3_b29 and 2.4.2_p13. Both worked fine and included the BeiDou satellites in the solution. Requesting the developers to have a look. I can provide any further info that might be needed. Signed up with GitHub just to post this issue and hence not sure if this is the right place to post the above problem for attention of developers. Thanks!