<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I should really repost under "UBX to RTCM3 conversion problems" or
"Raw to RTCM3" as I am not sure anyone is watching this! <br>
Further investigation leads me to discount the unhealthy satelite
postulate.<br>
The reason this was suspected is that when observing the satellites
whose status was OK and where included in the fix /float solution,
some had zero values for P1 residuals.<br>
However the satelites that exhibited this only did so at very high
elevations ie >= 75 degrees or so.<br>
I am watching now Sat G04 at 75.2 degrees elevation with zero P1<br>
The satelites are therefore not unhealthy but exhibit this strange
effect as seen by RTKnavi monitor.<br>
I have since tried MSM messages 1075,1085,1105 plus the
1006,1019,1020,1033 in the strsvr RTCM3 conversion.<br>
This does transmit D1 or phaserate information as does the raw data.<br>
They give the same outage problem ( jumping out of Fix for 1 or 2
meters, sometimes more) at seemingly random times.<br>
Using raw ublox data from the M8N to both base and rover does not
exhibit this effect, <br>
only when the base is converted to RTCM3 does the problem occur.<br>
Using raw data for both rover and base gives the same curious effect
of zero P1's at high elevations. so strange though it is it does not
seem to be part of the problem.<br>
Using a setup of three receivers one as base, one as rover1 and one
as rover2 and two strsvr's outputting simultaneously to three
rtknavi threads running concurrently, with one rtknavi useing only
raw data inputs and the other two using RTCM3 convertions via
strsvr.<br>
I was able to prove not only that the outages occurred on both
rtknavis that had RTCM3 converted inputs, but that they occurred
exactly simultaneously. (this was on rovers separated by 100 meters
or so, but using the same base station.)<br>
The only common factor then being the generated RTCM3 stream ( the
two rtknavi's being on seperate computers)<br>
<br>
I am puzzled that no one has come up with this as a problem as there
are many people doing this on various platforms , linux, rasberry
pi, beagle board, Emlid reach, android etc etc. <br>
David Kelly has kindly confirmed that the effect is reproduceable. <br>
I can reproduce it with 100% certainty ( except for the timing of
the outage, which I cannot explain, possibly due to a satelite
coming in to the solution or one dropping out?)<br>
<br>
The question is not so much why it is happening but why not when raw
data only is used? <br>
<br>
<br>
<div class="moz-cite-prefix">On 10/05/2015 22:05, arwooldridge
wrote:<br>
</div>
<blockquote cite="mid:554FC834.50309@googlemail.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
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 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>
</blockquote>
<br>
</body>
</html>