<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I have made some progress on this problem.<br>
As David says its a general problem of raw to RTCM3 conversion in
strsvr applying equally to UBX and BINR if not more formats.<br>
I have recently been testing the ublox M8N and found the same
conversion problem ( large outages up to 50 meters in rtknavi)<br>
<br>
I did some post processing using rtkconv and rtkpost.<br>
The first oddity was that rtkconv did not output any .sbs file, when
the input file was RTCM3 converted by strsvr.<br>
<br>
Out of curiousity I tried adding the following MSM messages to the
conversion process in strsvr: 1077,1087,1107.<br>
Bingo! this seemed to almost solve the problem, Outages now reduced
down from 50 meters to around 1 meter at most. <br>
However outages there were still and once out of lock prove
difficult to get back into lock.<br>
<br>
The reason is not obvious to me why the extra MSM messages are
necesary as standard RTCM3 messages from NTRIP reference base
stations that I have used do not include them yet seem immune to
this gross outage problem..<br>
<br>
Further rummaging in the RTKlib bugs about excluding unhealthy
satelites in rtknavi options seemed to ring true.<br>
outages do seem to be random and possibly due to unhealthy satelites
disturbing the AR withing rtknavi.<br>
looking at times of outages seemed to yield two possible unhealthy
satelites G08 and R10.<br>
excluding these seems so far to do the trick.<br>
<br>
This does make sense as standard base reference stations would
almost certainly exclude unhealthy satelite data, but strsvr must
just pass them through.<br>
However it does not quite explain why the problem does not occur
with raw UBX or BINR data for base and rover.<br>
Unless of course there is parsing within the raw processing ublox.c
nvs.c to exclude raw unhealthy data within rtknavi but not via RTCM3
input.<br>
I believe there is some sanity parsing in nvs.c at least, I have not
studied ublox.c.<br>
<br>
Could it be that there is better sanity parsing in the MSM messages
than the older 1002-1012 messages? <br>
If so maybe the older messages can be removed from the conversion?<br>
<br>
This then seems to be the root of the the problem, in my eyes.<br>
<br>
The solution would be to add or check parsing in rtcm3 input stream,
and or the rtcm3 generated stream from strsvr.<br>
<br>
<br>
<div class="moz-cite-prefix">On 11/01/2015 21:06, David Kelley
wrote:<br>
</div>
<blockquote cite="mid:54B2E5D2.9030409@ITSware.net" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<br>
Frankly I can not see the issue from what you have posted, or why
you are getting these two SVs rejected. It would help if you
could post your settings (the *.ini file) as we can see what is
odd, but before you do so be sure and remove the private
passwords for your casters etc from it. [The RTKLIB tool store
the user and the password together, so seek for lines in the
format =user:password@theURL:thePORT/theMountPoint:]<br>
<br>
Back to the original problem of the thread, I defer to <a
moz-do-not-send="true"
href="http://open-source-gps-related-discussion-and-support.1099874.n2.nabble.com/template/NamlServlet.jtp?macro=user_nodes&user=394950">arwooldridge</a>
to describe it in more dept but: We have conclusively seen over
the last month that that same stream of data from from a uBlox
device performed noticeably poorly when passed from the Stream
Convert (converting the native format to RTCM) and into RTKNavi,
then the same set of data passed into the RTKNavi tool directly.
We believe the same thing occurs with the BINR stream but at my
office we can not make the NVS chips work with RTKLIB yet. These
two processing paths should be identical for all practical
purposes, with the same net result. <br>
<br>
The core issue seems to be minor differences in the way the
proprietary encoding is treated (vs the RTCM 1004 messages)
between the two tools. I find no actual errors anywhere in RTKLIB
about this, but I suspect that there are difference in the how the
cycle clips are detected and reported in this. I remain annoyed
that I can not yet pin this down and will keep at it. One can
reproduce the problem by running multiple copies RTKLIB with the
two different settings, or by an L-band replay with a tool like
the LabSat3. In either event, the percentage of time spent in a
fixed mode is sharply reduced when the stream convert tool is used
regardless of the baseline distance. <br>
<br>
<br>
<div class="moz-cite-prefix">On 1/11/2015 11:11 AM, cocute wrote:<br>
</div>
<blockquote cite="mid:1421003481680-7573097.post@n2.nabble.com"
type="cite">
<pre wrap="">Hello,
i'm testing same process,
but i dont now if works or not,
i only test in window of my house, and not FIX possible, low sat vision,
when i test in open sky i comment.
You see all settings correct:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.dropbox.com/s/xif0yf733gldw24/Captura%20de%20pantalla%202015-01-11%2020.00.23.png?dl=0">https://www.dropbox.com/s/xif0yf733gldw24/Captura%20de%20pantalla%202015-01-11%2020.00.23.png?dl=0</a>
<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="https://www.dropbox.com/s/xif0yf733gldw24/Captura%20de%20pantalla%202015-01-11%2020.00.23.png?dl=0"><https://www.dropbox.com/s/xif0yf733gldw24/Captura%20de%20pantalla%202015-01-11%2020.00.23.png?dl=0></a>
--
View this message in context: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://open-source-gps-related-discussion-and-support.1099874.n2.nabble.com/BINR-to-RTCM-tp7573086p7573097.html">http://open-source-gps-related-discussion-and-support.1099874.n2.nabble.com/BINR-to-RTCM-tp7573086p7573097.html</a>
Sent from the Open Source GPS-related discussion and support mailing list archive at Nabble.com.
_______________________________________________
This message is sent to you from <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:FOSS-GPS@lists.osgeo.org">FOSS-GPS@lists.osgeo.org</a> mailing list.
Visit <a moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-freetext" href="http://wiki.osgeo.org/wiki/FOSS-GPS">http://wiki.osgeo.org/wiki/FOSS-GPS</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Regards,
David Kelley
ITS Programs Manager, SubCarrier Systems Corp. (SCSC)
626-485-7528 (Cell) 626-513-7715 (Office) 888-950-8747 (Main)</pre>
<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>