[FOSS-GPS] BINR to RTCM

[arwooldridge]

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 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/20150510/9fbf7f83/attachment.html>