In a previous post I explained that integer ambiguity resolution doesn’t generally work on the GLONASS satellites in RTKLIB because we have not accounted for the inter-channel biases caused by the multiple frequencies used with the different GLONASS satellites. That is why I have been setting gloarmode=0 in the configuration file even though I am using the GLONASS satellites for the float solution.
In theory, there is an exception to this rule, and that is when both receivers are using identical hardware. In this case, the biases should cancel and can be ignored. Whether this is true for some of the low cost receivers seems to be in question. Carcanague, in his thesis, describes finding that in some cases, biases can change with power on/off cycles, which if true, means they must be accounted for to make the GLONASS integer ambiguity resolution work reliably.
In my demo1 data set, both receivers use Ublox M8N receivers, although on non-identical boards. I get virtually no fixes if I enable GLONASS integer ambiguity resolution (AR), and this led me to believe that GLONASS AR was not an option unless I accounted for the inter-channel biases.
So I was quite surprised when I enabled GLONASS AR (gloarmode=1) on this new data set and got great results! Here’s a comparison of my metrics for three solutions. The first is with fix-and-hold disabled, the second is fix-and-hold enabled with the position variance criteria described in the previous post, and the third is the same with GLONASS AR enabled.
As you can see, the mean number of satellites used for the fixed solution has nearly doubled when GLONASS AR was enabled. This is a very significant improvement! I ran this configuration on three other data sets from the same receivers taken on different days and got similar improvements on all three, suggesting that there is most likely not an issue with power cycles with these (M8T) receivers.
I was very excited to discover GLONASS AR worked on this data but now I need to understand why I don’t see the same behavior with my receivers. I can think of several possible reasons:
- The Reach receivers use the Ublox M8T, while my receivers are both using the Ublox M8N. I was under the impression these two receivers are very similar (they share the same documentation) but maybe there is some subtle difference between them?
- Although my two receivers both use the M8N chip, the boards they are on are from different companies. I wouldn’t expect this to make a difference, but maybe it does?
- The two antennas I used to collect my data are different, although they are both basic patch antennas.
- This data was taken at at 5 samples/sec. My data was taken at 1 sample/sec.
I hope to run some experiments to answer this question in the near future. In the meantime though, can anybody else explain what I’m seeing, or confirm they’ve seen similar behavior?
Update 5/2/16: I just came across this comment from Tomoji Takasu, the author of RTKLIB, regarding differences between the M8N and M8T on the Emlid forum
“NEO-M8N does not support raw-data officially. However, it is known that some F/W version can be configured to output raw-data as TRK-MEAS and TRK-SFRBX messages. I confirmed it by F/W version 2.01. The latest RTKLIB (2.4.2 p11) can also handle such messages. For details, refer the following material.
http://gpspp.sakura.ne.jp/paper2005/gpssymp_2014_ttaka.pdf62
I found some limitation by M8N compared to M8T.
(1) Raw message can be used only with 1 Hz (NG with 5 Hz).
(2) Only GPS ambiguities can be resolved (NG for GLONASS or BeiDou)
Again, these are not supported by u-blox formally. Other F/W versions may not support them.”
It looks like he has had the same experience I am seeing, where the M8N can resolve GLONASS integer ambiguities and M8T can not.
rtklibexplorer 
There are correction tables lists at http://wiki.openstreetmap.org/wiki/UbloxRAW#U-BLOX-M8 for the M8N and could I ask if these make any sense and if you have considered applying these? Would these affect RTK gps or would they be common factors that cancel if the rover and base were the same type of receiver?
LikeLike
Hi Oaq. Interesting … I have not seen these tables before. I don’t understand what they are supposed to be correcting for and find it curious they are in integer meters and not integer cycles. They appear to be corrections for the pseudorange measurements, not the carrier phase measurements. If that is the case, they would not help with the carrier phase ambiguities.
LikeLike
Hi, Thanks for sharing
I have some problem about building RTK with Low-cost GPS Receivers( u-blox lea-5s and 6s receivers)
In Windows PC,rtknavi cannot work which two input stream rover and basestation are light-green,it means data active ,but positioning process is still deep-green(waitting).
RTKnavi didn’t display any information but show rover and basestation GPS messages
Is my u-blox format wrong? rtklib Maual2.4.2 :u-blox lea-4T,5T and 6T binary format
Dose RTKlib not suport ublox S-series?
I am not sure where I do wrong.
Thanks.
LikeLike
Very impressive work. Thanks for sharing.
I know you are focusing on the cheapest possible equipment (~$30 for receiver and antenna), but if that can be increased to $100 or $150 the capability improves quite a bit and we are still well below the cost of the least expensive dual frequency receivers. If this is too high a price for your project perhaps it may not be for others.
Improving the antenna is often mentioned and those on your typical $30 combo are pretty bad. Even a $10-$15 one like those supplied with the Ublox evaluation kit will help a lot. A $40 or $80 Tallysman will help a bit more. A $1000 NovAtel Pinwheel will be even better, but we’ve completely left the low cost realm. I would really suggest upgrading the couple dollar patch antenna typical of the cheapest equipment.
The other thing to improve of course is the receiver. Starting at several hundred dollars you can get a better performing one than the Ublox, but this is getting expensive. For ~$80 a Ublox M8T receiver can be obtained. This has a major advantage over the M8N as signals from GPS, Glonass, Galileo, and SBAS can all be used for fixed integer work with RTKLIB. With the M8N only GPS can be used.
As a simple example to show the benefits of lots of satellites for fixing the integers I recorded 90 minutes
of static data with two M8Ts attached to Tallysman antennas on a roof of a vehicle under ideal receiving conditions. They were set to record GPS, Glonass, Galileo, and SBAS data at a 1 Hz rate. I then ran the data through RTKPOST chopping it up into 30 three minute segments and attempted to fix the integers in Kinematic mode with a ratio of 3.
First, using only GPS sats (6-8) a fixed integer solution was obtained (within 3 minutes) in 20 of the 30 trials. One of these was incorrect. The average time to a fix for those that did was 59 seconds.
Then the Glonass sats were added (13-15 total sats) and a correct fixed integer solution was obtained every time. On average it took 10 seconds.
Then Galileo and SBAS sats were added (20-22 total) and a correct fix was obtained every time with an average of 1 second to get there.
Of course this data is correlated and real world kinematic performance won’t be as good, but the idea is to show the relative improvement that large numbers of satellites can make.
LikeLike
Hi JB. Thank you for the feedback. You make some very good points and I wouldn’t disagree with any of them. In fact if I were trying to do something useful with RTKLIB today I would probably use the M8T with an improved antenna, and I would recommend other people do the same. My goal, however, at least for the short-term, is more about understanding and improving RTKLIB, than it is about maximizing my results. The ultra low-cost solutions I am experimenting with stress RTKLIB in a way more expensive solutions do not, and so are quite ideal for my purpose. Longer term, I do have hope that the ultra-low cost solutions will have enough capability to be usable at least in relatively friendly environments, which will open up new more cost-sensitive applications for precision GPS. I also hope that most of the changes I make to RTKLIB should apply to all low-cost solutions, not just the ultra-low cost.
I agree completely with your point about the benefits of having more satellites in the solution. I am not convinced however that the M8N can not be used for GLONASS ambiguity resolution. I am getting quite consistent GLONASS ambiguity resolution now in my solutions using a modified version of what I described in an earlier post. I am not able to use it for initial acquisition yet but suspect it should be possible.
I also do own a $10 UBlox antenna and a nice Tallysman antenna and plan to get a couple of M8T receivers soon, so am not a complete purist when it comes to ultra low cost. I may be convinced at some point to move up at least a notch, although I really would like to stay under $100.
You make a good point about the correlation of the data when both antennas are mounted on the rover. I am concerned that the limitations of the cheap antennas will be more apparent when their orientation is uncorrelated, but haven’t had a chance to look closely at that yet. In my demo1 data, taken like yours with two antennas mounted on top of a moving car, I was using the $10 UBlox antenna with one of the receivers and the very cheap antenna on the other receiver. I was actually not able to see a noticeable difference in the quality of the data between these two setups, but I wouldn’t conclude anything based on this one example.
I am impressed by your factor of 10 reduction in acquisition time when you added the Galileo and SBAS satellites. With the SBAS satellites, were you adding the correction data too, or just the raw pseudorange and carrier phase?
LikeLike
My comments were really more for those who want to try low cost RTK with RTKLIB the way it is now. There are people relatively new to this watching your site and we agree that if they can afford it the M8T route would be the way to go.
I do think you can get more out of an M8N with some software mods (which you are doing), but since Ublox doesn’t support raw data from it – and they’ve already changed things as to enabling raw data with their latest firmware – the M8N seems to be at a dead end for high accuracy work. As you mentioned though, for your purposes it has value.
Of course I haven’t tried every cheap patch antenna out there, but in general you get what you pay for. Under really good conditions I’ve done kinematic work with a $5 antenna, but a $40 one will be a bit more robust. For one of my M8N’s I got a good deal on a Tallysman 1421 antenna ($29) to replace the stock patch and some before and after tests near a pond and metal sided building (multipath) showed substantial improvement. When doing kinematic work, especially RTK, every little advantage helps.
When I added SBAS sats in the test I mentioned that was just the pseudorange and carrier data. I don’t think RTKLIB will use any other SBAS info when differencing. Again, just showing that more sats are better.
LikeLike
Hi JB. Good points again! I’ve added an update to the “Selecting a GPS receiver” post with both your comments included.
LikeLike