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