[FOSS-GPS] Problem with RTKLIB kinematic, large residual, slip detected, ambiguity validation failed
Dean Ashby
dean at ashby.org.nz
Fri Sep 18 02:17:58 PDT 2015
Thanks for the suggestion Felipe, I performed the following on the two
Raspberry Pis with the receiver antennas stationary and a few cms
apart. For convenience one is labelled base and the other rover.
On rover:
str2str -in serial://ttyAMA0#ubx -out file://rover.rtcm3#rtcm3 -c
ubx_raw_1hz.cmd
convbin -o rover.obs rover.rtcm3
convbin -n rover.nav rover.rtcm3
On base:
str2str -in serial://ttyAMA0#ubx -out file://base.rtcm3#rtcm3 -c
ubx_raw_1hz.cmd
convbin -o base.obs base.rtcm3
convbin -n base.nav base.rtcm3
I then transferred these *.obs and *.nav files to a Windows PC to run
through rtkpost.
RINEX OBS: Rover = rover.obs
RINEX OBS: Base Station = base.obs
Rinex *NA/CLK = rover.nav
I enabled residuals in the ouput solution status and plotted the results
which you can see here:
http://i173.photobucket.com/albums/w62/dgashby/residuals_zpsrpm71wes.jpg
The pseudorange residuals appear to be far greater than the example
shown in Figure 3.7-4 of the RTKLib 2.4.2 manual but given my lack of
knowledge and experience with RTKLib I'm not sure if this is normal or
not, and if not then what might be causing this?
To give you more context, I'm using a pair of ublox 6m receivers (ROM
7.03) and have applied the patch described here:
http://wiki.openstreetmap.org/wiki/UbloxRAW#U-BLOX6 to enable RAW output
and confirmed that the rtcm3 files produced by str2str did contain
RTCM3-1004 and RTCM3-1019 messages using two different tools
(RTCM3-Decode python code and gpsdecode).
Thanks,
Dean
On 18/09/15 10:36, Felipe G. Nievinski wrote:
> try to rule out real-time issues
> by saving the data streams as
> files on disk and post-processing
> using the rtkpost GUI instead of the
> rtkrcv CUI. ask it to save residuals
> and inspect them graphically using
> rtkplot.
> -F.
>
> On Thu, Sep 17, 2015 at 4:00 PM, <foss-gps-request at lists.osgeo.org
> <mailto:foss-gps-request at lists.osgeo.org>> wrote:
>
> Message: 1
> Date: Thu, 17 Sep 2015 12:37:59 +1200
> From: Dean Ashby <dean at ashby.org.nz <mailto:dean at ashby.org.nz>>
> To: foss-gps at lists.osgeo.org <mailto:foss-gps at lists.osgeo.org>
> Subject: [FOSS-GPS] Problem with RTKLIB kinematic, large residual,
> slip detected, ambiguity validation failed
> Message-ID: <55FA0B67.3030503 at ashby.org.nz
> <mailto:55FA0B67.3030503 at ashby.org.nz>>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> I'm relatively new to RTKLIB but have done quite a bit of reading over
> the past few weeks so please bear with me if I've missed something
> obvious.
>
> When running rtkrcv in kinematic mode talking to a base station
> running
> str2str via tcpcli I very rarely get a FIXED solution, usually
> it's just
> a FLOATING solution.
>
> I see a lot of this:
>
> rtkrcv> error
> 00:17:18.00: slip detected (sat=14 rcv=1 LLI1=3)
> 00:17:18.00: slip detected (sat=25 rcv=1 LLI1=3)
> 00:17:18.00: ambiguity validation failed (nb=6 ratio=1.44
> s=25.24/36.30)
> 00:17:19.00: slip detected (sat=14 rcv=1 LLI1=3)
> 00:17:19.00: slip detected (sat=16 rcv=1 LLI1=3)
> 00:17:19.00: slip detected (sat=25 rcv=1 LLI1=3)
> 00:17:19.00: ambiguity validation failed (nb=6 ratio=1.45
> s=29.42/42.56)
> 00:17:20.00: slip detected (sat=25 rcv=1 LLI1=3)
> 00:17:20.00: ambiguity validation failed (nb=6 ratio=1.46
> s=31.24/45.48)
> 00:17:21.00: slip detected (sat=16 rcv=1 LLI1=3)
> 00:17:21.00: slip detected (sat=25 rcv=1 LLI1=3)
> 00:17:21.00: ambiguity validation failed (nb=6 ratio=1.45
> s=34.00/49.20)
> 00:17:22.00: slip detected (sat=14 rcv=1 LLI1=3)
> 00:17:22.00: slip detected (sat=25 rcv=1 LLI1=3)
> 00:17:22.00: ambiguity validation failed (nb=6 ratio=1.31
> s=37.35/49.06)
>
>
> I've seen various other posts where people have had similar
> problems but
> that has ofte been put down to cheap patch antennas and poor SNR.
> Admittedly I'm using cheapish active patch antennas sitting on
> sheets of
> spare 3mm aluminium to act as ground planes, located in reasonably
> clear
> space on three sides, and the satellite SNR looks OK:
>
> rtkrcv> obs
>
> TIME(GPST) SAT R P1(m) P2(m) L1(cyc) L2(cyc)
> D1(Hz) D2(Hz) S1 S2 LLI
> 00:17:55.0 G01 1 23173440.00 0.00 -67934004.25 0.00
> 4321.2 0.0 42 0 2 0
> 00:17:55.0 G03 1 20996503.04 0.00 -80470547.61 0.00
> 8531.9 0.0 43 0 2 0
> 00:17:55.0 G04 1 23901429.65 0.00 -56298544.87 0.00
> 3864.9 0.0 44 0 2 0
> 00:17:55.0 G14 1 23016147.60 0.00 -48310509.64 0.00
> 3804.7 0.0 35 0 2 0
> 00:17:55.0 G16 1 23683356.32 0.00 -27092194.48 0.00
> 10341.1 0.0 32 0 2 0
> 00:17:55.0 G22 1 25079322.86 0.00 -38665003.76 0.00
> 2944.1 0.0 28 0 3 0
> 00:17:55.0 G23 1 22642174.23 0.00 -44392777.77 0.00
> 9568.9 0.0 47 0 2 0
> 00:17:55.0 G25 1 23260380.39 0.00 -70004514.13 0.00
> 4404.1 0.0 30 0 3 0
> 00:17:55.0 G26 1 21612855.57 0.00 -63585920.57 0.00
> 9476.4 0.0 45 0 2 0
> 00:17:55.0 G31 1 19896070.95 0.00 -79557949.56 0.00
> 5677.5 0.0 44 0 2 0
> 00:17:55.0 G32 1 19775470.02 0.00 -84790957.79 0.00
> 6361.9 0.0 49 0 2 0
>
> 00:17:55.0 G01 2 23428649.54 0.00 123118157.28 0.00
> 0.0 0.0 42 0 0 0
> 00:17:55.0 G03 2 21251709.44 0.00 111677473.40 0.00
> 0.0 0.0 48 0 0 0
> 00:17:55.0 G04 2 24156636.48 0.00 126942627.26 0.00
> 0.0 0.0 41 0 0 0
> 00:17:55.0 G14 2 23271350.71 0.00 122291627.81 0.00
> 0.0 0.0 33 0 0 0
> 00:17:55.0 G16 2 23938559.50 0.00 125797319.77 0.00
> 0.0 0.0 43 0 0 0
> 00:17:55.0 G22 2 25334523.53 0.00 133133154.17 0.00
> 0.0 0.0 26 0 1 0
> 00:17:55.0 G23 2 22897381.47 0.00 120326137.93 0.00
> 0.0 0.0 49 0 0 0
> 00:17:55.0 G25 2 23515585.12 0.00 123575137.32 0.00
> 0.0 0.0 29 0 1 0
> 00:17:55.0 G26 2 21868061.88 0.00 114917375.21 0.00
> 0.0 0.0 44 0 0 0
> 00:17:55.0 G31 2 20151273.77 0.00 105894595.55 0.00
> 0.0 0.0 51 0 0 0
> 00:17:55.0 G32 2 20030674.09 0.00 105260781.87 0.00
> 0.0 0.0 47 0 0 0
>
> There are a few things here that seem unusual though. My
> understanding
> is that the first block of satellites are from the local (serial) GPS
> receiver and the second block are from the base station. The P and L
> values seem to significantly different, and the doppler (D) values
> don't
> exist for the base station. This strikes me as very odd as I have
> seem
> some other examples on-line where these values are much closer
> matches.
>
> Rtkrcv appears to be receiving RTCM messages from the base station
> according to the status output:
>
> rtkrcv> sta
>
> Parameter : Value
> rtklib version : 2.4.2
> rtk server thread : -1227946896
> rtk server state : run
> processing cycle (ms) : 100
> positioning mode : kinematic
> frequencies : L1
> accumulated time to run : 00:28:52.7
> cpu time for a cycle (ms) : 45
> missing obs data count : 0
> bytes in input buffer : 0,0
> # of input data rover :
> obs(1732),nav(24),gnav(0),ion(657),sbs(3431),pos(0),dgps(0),ssr(0),err(0)
> # of input data base :
> obs(1733),nav(25),gnav(0),ion(0),sbs(0),pos(114),dgps(0),ssr(0),err(0)
> # of input data corr :
> obs(0),nav(0),gnav(0),ion(0),sbs(0),pos(0),dgps(0),ssr(0),err(0)
> # of rtcm messages rover :
> # of rtcm messages base :
> 1002(1733),1004(1733),1005(57),1006(57),1019(670)
> # of rtcm messages corr :
> solution status : float
> time of receiver clock rover: 2015/09/17 00:25:50.000480056
> time sys offset (glo-gps)(s): 0.000000000
> solution interval (s) : 1.000
> age of differential (s) : 0.001
> ratio for ar validation : 1.160
> # of satellites rover : 11
> # of satellites base : 10
> # of valid satellites : 10
> GDOP/PDOP/HDOP/VDOP : 1.6,1.5,0.8,1.2
> # of real estimated states : 3
> # of all estimated states : 124
> pos xyz single (m) rover : -4603225.267,603993.316,-4358763.701
> pos llh single (deg,m) rover: -43.38549245,172.52487221,56.564
> vel enu (m/s) rover : 0.062,-0.092,-0.162
> pos xyz float (m) rover : -4603225.267,603993.316,-4358763.701
> pos xyz float std (m) rover : 0.233,0.137,0.204
> pos xyz fixed (m) rover : -4603228.149,604003.890,-4358765.385
> pos xyz fixed std (m) rover : 0.038,0.049,0.022
> pos xyz (m) base : -4603224.437,603994.410,-4358758.516
> ant type rover :
> ant delta rover : 0.000 0.000 0.000
> ant type base :
> ant delta base : 0.000 0.000 0.000
> pos llh (deg,m) base : -43.38546274,172.52485749,52.507
> vel enu (m/s) base : 0.000,0.000,0.000
> baseline length float (m) : 5.365
> baseline length fixed (m) : 12.282
> monitor port : 0
>
> I can supply my configs and more information about the hardware and
> software version if necessary but this message was getting large
> enough
> as it was and I thought the information above might be enough to
> diagnose what I am missing.
>
> Any help much appreciated.
>
> Regards,
>
> Dean
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: dean.vcf
> Type: text/x-vcard
> Size: 167 bytes
> Desc: not available
> URL:
> <http://lists.osgeo.org/pipermail/foss-gps/attachments/20150917/fcf857fb/attachment-0001.vcf>
>
> ------------------------------
>
> _______________________________________________
> FOSS-GPS mailing list
> FOSS-GPS at lists.osgeo.org <mailto:FOSS-GPS at lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/foss-gps
>
> End of FOSS-GPS Digest, Vol 80, Issue 9
> ***************************************
>
>
>
>
> _______________________________________________
> This message is sent to you from FOSS-GPS at lists.osgeo.org mailing list.
> Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your subscription
> For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/foss-gps/attachments/20150918/5bb32f82/attachment-0001.html>
More information about the FOSS-GPS
mailing list