Still no GLONASS ambiguity resolution for Reach? Any plans on implementing it? I read Tim Everett (rtklibexplorer) experimented with implementing the inter-chanel biases for GLONASS and he said you are using some of his code too.
Do you mean Glonass AR with Reach and other system or between two Reach?
Sorry I forgot to mention between two different, non-matching receiver types - so for instance between Reach and a CORS base station.
No, I see it for the first time. But the paragraph contradicts itself to me a bit - should I disable it or calibrate? Not clear.
So if I set both GPS and GLONASS to fix-and-hold then the system will fix using GPS and then calibrate GLONASS automatically and if successful use GLONASS for fix too? Or should I set GPS to “continuous”? Is it better to do the calibration in “static” mode? Do you have real experience with this?
Well, Reachview has not Glonass AR fix&hold, only on and off. RTKpost has fix&hold. But someone els might elaborate this part better
We did not incorporate fix&hold for GLO because we are cooking a more generalized solution. Fix&hold only helps after first solution was found. We want to make it work from the very beginning in order to speed up NTRIP fixes. This is especially important as most NTRIP providers are GPS+GLO without other systems and GLO is not usable due to ICBs, so we are left with GPS only to calculate solution. GPS only RTK is a sad story.
1 Like
In RTKlib by RTKlibExplorer as a post processed solution Glonass AutoCal works very well.
1 Like
Nice to hear this! I guess you mean the “demo5” code. I just referenced to a blog post from 2016 about GLONASS ICB solution but did not realize it was working already… However I wonder why Tim still writes that GLONASS AR is not working for non-matching receivers in RTKLIB in his recent posts… that made me think it does not work yet. His docs here do mention this:
(4) Code has been added to calculate and manage inter-channel biases for the GLONASS and SBAS satellites based on an extension of the fix-and-hold method (direct feedback from the ambiguity resolution results to the kalman filter states) .
So I am confused a bit now… Does it work or not. Tim in posts says it does not, in docs it does, you too it does… who knows for sure? 
Maybe Tim in the posts means the standard RTKLIB code (not his demo5 version). The posts I am referencing to are from about last 6 month where he tested Swift and ComNav receivers (I hope I recall correctly).
Anyways the docs read like it is rather a hack than a proper solution, but if you say it works maybe it is good enough.
Nice to hear you are working on a solution! When is it due to? Maybe you could make use of these RTCM messages as they are broadcast by the professional base stations (at least those I know):
1033 - Receiver and Antenna Descriptors
1230 - GLONASS L1 and L2 Code-Phase Biases
Apologies for adding to your confusion I was processing data from a pair of Reach RTK units, both configured to collect GPS, GLONASS, QZSS, Galileo and SBAS. I had a constellation of over 20 sats in view at all times even if the signals were noisy. For the cost of a reach module and antenna I cannot see why you wouldn’t do it this way. YOu can use the CORS to nail your base to the ground with observations from the entire occupancy and benefit from matched recievers, shorter baselines and RTK connectivity (in the low cost config of putting a wifi router on a pole) over the entire site.
1 Like
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.