arwooldridge arwooldridge at googlemail.com
Tue May 12 16:09:39 PDT 2015

I should really repost under "UBX to RTCM3 conversion problems" or "Raw 
to RTCM3" as I am not sure anyone is watching this!
Further investigation leads me to discount the unhealthy satelite postulate.
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.
However the satelites that exhibited this only did so at very high 
elevations ie >= 75 degrees or so.
I am watching now Sat G04 at 75.2 degrees elevation with zero P1
The satelites are therefore not unhealthy but exhibit this strange 
effect as seen by RTKnavi monitor.
I have since tried MSM messages 1075,1085,1105 plus the 
1006,1019,1020,1033 in the strsvr RTCM3 conversion.
This does transmit D1 or phaserate information as does the raw data.
They give the same outage problem ( jumping out of Fix for 1 or 2 
meters, sometimes more) at seemingly random times.
Using  raw ublox data from the M8N to both base and rover does not 
exhibit this effect,
only when the base is converted to RTCM3 does the problem occur.
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.
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.
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.)
The only common factor then being the generated RTCM3 stream ( the two 
rtknavi's being on seperate computers)

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.
David Kelly has kindly confirmed that the effect is reproduceable.
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?)

The question is not so much why it is happening but why not when raw 
data only is used?

On 10/05/2015 22:05, arwooldridge wrote:
> I have made some progress on this problem.
> As David says its a general problem of raw to RTCM3 conversion in 
> strsvr applying equally to UBX and BINR if not more formats.
> I have recently been testing the ublox M8N and found the same 
> conversion problem ( large outages up to 50 meters in rtknavi)
> I did some post processing using rtkconv and rtkpost.
> The first oddity was that rtkconv did not output any .sbs file, when 
> the input file was RTCM3 converted by strsvr.
> Out of curiousity I tried adding the following MSM messages to the 
> conversion process in strsvr: 1077,1087,1107.
> Bingo! this seemed to almost solve the problem, Outages now reduced 
> down from 50 meters to around 1 meter at most.
> However outages there were still and once out of lock prove difficult 
> to get back into lock.
> 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..
> Further rummaging in the RTKlib bugs about excluding unhealthy 
> satelites in rtknavi options seemed to ring true.
> outages do seem to be random and possibly due to unhealthy satelites 
> disturbing the AR withing rtknavi.
> looking at times of outages seemed to yield two possible unhealthy 
> satelites G08 and R10.
> excluding these seems so far to do the trick.
> This does make sense as standard base reference stations would almost 
> certainly exclude unhealthy satelite data, but strsvr must just pass 
> them through.
> However it does not quite explain why the problem does not occur with 
> raw UBX or BINR data for base and rover.
> 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.
> I believe there is some sanity parsing in nvs.c at least, I have not 
> studied ublox.c.
> Could it be that there is better sanity parsing in the MSM messages 
> than the older 1002-1012 messages?
> If so maybe the older messages can be removed from the conversion?
> This then seems to be the root of the  the problem, in my eyes.
> The solution would be to add or check parsing in rtcm3 input stream, 
> and or the rtcm3 generated stream from strsvr.
> On 11/01/2015 21:06, David Kelley wrote:
>> 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 at theURL:thePORT/theMountPoint:]
>> Back to the original problem of the thread, I defer to arwooldridge 
>> <http://open-source-gps-related-discussion-and-support.1099874.n2.nabble.com/template/NamlServlet.jtp?macro=user_nodes&user=394950> 
>> 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.
>> 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.
>> On 1/11/2015 11:11 AM, cocute wrote:
>>> 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:
>>> 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>   
>>> --
>>> View this message in context:http://open-source-gps-related-discussion-and-support.1099874.n2.nabble.com/BINR-to-RTCM-tp7573086p7573097.html
>>> Sent from the Open Source GPS-related discussion and support mailing list archive at Nabble.com.
>>> _______________________________________________
>>> This message is sent to you fromFOSS-GPS at lists.osgeo.org  mailing list.
>>> Visithttp://lists.osgeo.org/mailman/listinfo/foss-gps  to manage your subscription
>>> For more information, checkhttp://wiki.osgeo.org/wiki/FOSS-GPS
>> -- 
>> Regards,
>> David Kelley
>> ITS Programs Manager, SubCarrier Systems Corp. (SCSC)
>> 626-485-7528 (Cell)   626-513-7715 (Office)  888-950-8747 (Main)
>> _______________________________________________
>> This message is sent to you fromFOSS-GPS at lists.osgeo.org  mailing list.
>> Visithttp://lists.osgeo.org/mailman/listinfo/foss-gps  to manage your subscription
>> For more information, checkhttp://wiki.osgeo.org/wiki/FOSS-GPS

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/foss-gps/attachments/20150513/ea241b7c/attachment.html>

More information about the FOSS-GPS mailing list