I am attempting to use the Reach to mark ground control points for drone surveying. However I am having trouble getting a fix - seems like I can only get float.
I’m running the Reach units in single mode and am using the supplied GPS antennas with 100mm ground planes (aluminum). Then I’m using RTKPOST to post process since the radios I have are no good for any distance worth speaking of and the cellular network is pretty sketchy here in AK.
The base is set up over a known survey point, it can see a solid 6 GPS satellites in the green, sometimes more. I start this logging and then go and move the rover unit (set up the same way) around between the GCPs I’ve marked on the ground. I’m using a 2m survey pole strapped to a tripod so I can leave the rover over a point for around 10 minutes.
After the survey is done I download the logs as RINEX and use RTKPOST to process them. I’ve experimented with a few different settings and actually got a fix on some data where I had the base right next to the rover - but never when I was actually at my GCPs, which are about 4km away from the base.
I’m attaching some images from RTKPLOT showing the fix I did get right by my base station as well as typical plots for the GCPs.
I should mention that for the GCPs I set up the tripod and levelled the pole over the target point, then hit “START” in Reach View to begin logging.
Perhaps someone knows whether I would get RTK fix if I occupied each GCP for longer? How long should I expect to need in each place?
Anyway if anyone has any help I’d love to hear it!
Another question I have is regarding ground planes - should they be ferrous, or is aluminum ok?
Lastly how much better results will I get from using an upgraded antenna for instance Tallysman TW2410?
I think it may be a post processing errors rather than field errors.
Try setting the ionosphere corrections to broadcast and troposphere to SBAS or Saas… ( I found estimate ZTD + grad to be more accurate but I get less fixes)
Load the sbas file from the rover or base if using sbas troposphere corrections (i do not)
finally download the ephemeris or sp3 file from this link and add that or for slight better accuracy add the .clk file. If you add the .sp3 or .clk file set the clock to precise.
I am not sure of why the fix ambiguity is set to 310. That is set to 3 by default and I haven’t touched it. To be honest - not sure what this does but you will not get any fixes with it set that high.
Set the antenna position for the base station. I am using a CORS station in the example below as the base and the position is contained in the Header of the RINEX file. It can be set manually.
IMO occupancy time needs to be longer. At 5 minutes, you still might not get a fix. I wait at least 10 minutes with good satellites, sometimes 20 minutes if I want to be really sure of getting the fix. Of course, if the radios were working, then you know when you get the fix and could move on.
I definitely agree with @mdgps on the “Min ratio to fix ambiguity”; the default setting is 3 and 310 is not going to work.
Also a BIG one for post processing (and thanks to whoever gave me the hint), on the Frequencies / Filter type: change “Forward” to “Combined” to double your chance of getting fixes.
Thanks for all these tips, I will try them out tomorrow.
Re the 20+ minutes to fix - if it takes this long to get a fix then presumably it is better to never hit “stop” between GCPs - instead I should leave it running while I move to a new GCP and just note the time at which I get the tripod properly leveled etc? So I can match that time to position later on? In other words I’m assuming the Reach can keep the fix while moving and doesn’t need another 20+ min at the next GCP…?
Yes, the ambiguity was default at 310 but I will try 3 tomorrow. Strange.
That’s right. If you can keep the rover moving with good satellite view between your points then you can do the job quicker, but it’s a gamble. I don’t have any experience operating that way myself, but in RTKPOST, use Kinematic instead of Static mode if you are moving.
I wouldn’t sit on every point for 20min, but if your day’s work depends on that point or if you have to crash through the bush for half an hour to get there then maybe.
I’ve been sitting at a place with good sky view and the fix doesn’t come along for 7 minutes (bad satellite geometry?). Most times it comes a lot quicker, but that is why I wait for 10.
I guess you’ll get the feel for it as you watch the time scroll by in RTKPOST and you see when your Q=2 (float) switches to Q=1 (fix).
That’s what I do. Record the time for the start/stop of each observation window and move to the next point and do the same without the stop start on the module.
I would not however change the solution from static to kinematic in RTKPOST. Instead leave in static and simply adjust the GPST time start and end in RTKPOST. Remember GPST time does NOT equal UTC time. Currently GPST is about 17 seconds in front. So you will need to account for that.
Changing the ambiguity will probably fix the problem.
Additionally - Is there any reason in choosing QZSS broadcast for the ionosphere model? As this will make a difference too. These satellites orbit over Japan and down to Australia and back. Also I think they would need to be selected in the used positioning systems for the broadcast to be written to the logs… I could be wrong here though.
Static mode! I agree and retract my previous remark about Kinematic because the period of time where @Jonathan_Bailey is moving does not matter to the mission of capturing the GCP points.
I tried the suggestions on the data I had already gathered to see if I could get any better results without having to go back out and re-survey.
Took me a little while to decipher how to get the correct data from the http://cddis.nasa.gov/ site, I ended up using a date calculator found here http://csrc.ucsd.edu/convertDate.shtml to help me get there. I found that there were only sp3 files available for my date, no clk or clk_30 files. Is this because I need to wait longer until they become available, or am I missing something? I’m here ftp://cddis.gsfc.nasa.gov/gnss/products/1892/ and looking at files called igu18924 - there don’t appear to be any igs files (yet?) for my day of week (4).
I do get better results overall but I am left with some questions. See attached images for my settings.
One setting that helps is Troposphere to Estimate ZTD + Grad.
Fix ambiguity does not seem to matter at either 310 or 3 I get the same results…
Forward vs Combination does not seem to affect my results, but I’m leaving it on combination in case it does help in the future:)
Setting clock to precise and including the igu18924_12.sp3 file enables me to see the four fixes in the attached image. If I leave clock to broadcast I end up with just the fairly tight grouping of floats (~25cm).
Q: if I get a fix for 4 points out of multiple should I believe the four points rather than the many others that have a good grouping, given that the fixes are around 5m away from the group? My gut feeling is that to trust a fix it should be somewhat central to a larger area of float points - not in an entirely different location.
Witness the other attached images - position of my base station based on two fairly close CORS stations. The closest one gives believable data, with floats surrounding the fixes; the distant one does not - which is borne out by the fact that the center of the float group is approximately the same location as given by the fixes from the close CORS results. This is kind of answering my own question for me - but I’d appreciate input from people who have a bit more experience than myself - I’m feeling around in the dark here…
I’m going to go back out and occupy the points for longer and see what I get from that.
s = Final
The final combinations are available at 12 days latency.
r = Rapid
The Rapid product is available with approximately 17 hours latency. The .clk files will accompany this.
u = UltraRapid
The UltraRapid combinations are released four times each day (at 0300, 0900, 1500, and 2100 UT) and contain 48 hours worth of orbits; the first half computed from observations and the second half predicted orbit. The files are named according to the midpoint time in the file: 00, 06, 12, and 18 UT.
The difference in accuracy of u and r is mildly significant but not between r and s. Using the r or rapid results are almost the same as using the s or final results ie use the r results don’t wait for the s.
I wouldn’t trust 4 points although they look ok… Try setting the fix ambiguity to 1.5 or 2 and those floats may turn into fixes. They will be less accurate fixes but in general - fixes are always better.
With the longer baselines (47.3km) try Estimate STEC for the ionosphere it may help as well as setting the ambiguity lower.
L1 signal is subject to multipath ie there will be fixes that will be reflections of surrounding objects and that is what those outlying fixes look like. Play around with the terrain mask, this may help. 15 degrees usually works pretty well but I find sometimes the results are better with a lower value and sometime better with a higher value.
I find I get tighter fixes with ZTD but less of them.
Finally, I use TW3710 antenna with a 200mm aluminium ground plate (small pizza tray!) which I found makes a difference about 4-5db on the SNR over the stock antenna and less multipath. No experiments here though just eye balling the SNR with the antennas side by side.
I got much better results after occupying for longer. The minimum I used was 15 minutes. I got a believable fix on all points by:
processing a solution using kinematic (ended up with mainly floats) and noting the stationary times (static solution for the whole log was unbelievable…)
processing using static for just those stationary times. I did have to mess around with times a bit to get believable results in some cases (ie when to start when to stop processing). Also used Google Earth view to check the believability of some fixes.
I didn’t use any clock or check against CORS since those weren’t available right off.
I attach screenshots showing the difference between using kinematic vs static for just the time the Reach was stationary at one point. All other settings are the same.
All this leads me to be quite confident that I can use the Reach to locate GCPs accurately. However, it does make me question how people got those nice tracks of green points using kinematic mode - the circles etc that one see when reading about Reach and RTKLIB. In my experience so far I can only rely on getting float and the occasional fix when moving. Thats not a show stopper for me, though - just a point of interest.
Thanks for all the input, I will try all these additional things out in the future.
Jon
Hi Jon,
I am getting much better results than you in post processing, but I don’t know why. Can you show your number of satellites plot? Is there any reason that you aren’t also logging Glonass data? I have found that my best results come from logging GPS+Glonass 5Hz, but - importantly - I have also found that RTKPost cannot use Glonass from the Reach-converted RINEX files, so I have to convert them myself using convbin.
Typically I am getting mid 90’s fix kinematic, and even better than that static (although my use-case is moving logs). Almost all of my floats come during initial convergence (perhaps 5-10 minutes), so I have more or less perfect results during my logging.
I didn’t save any screenshots of satellites from this last job, however I was getting between 6-10 green, most often 8.
I was using GPS+GLONASS 1Hz (- does 5Hz help?) but I found that RTKPOST actually got less fixes when GLONASS was checked so I’ve been leaving it unchecked.
What you say about using convbin to convert then makes sense - but can you add details of how you do this, I’ve never used convbin before. Do you need to download the logs in raw and then convert to RINEX using convbin?
Hi Jon,
I don’t know if the 5Hz helps - although I doubt it hurts (apart from processing time).
To see the number of satellites used in the solution, select the NSat screen in RTKPlot. I found that when I used the rinex files produced by Reach, Glonass was never used. To convert yourself, you need the latest (2.4.3) version of RTKLib, and running convbin.exe is very simple - just convbin filename is sufficient, although I also use the -od option to include doppler info, on the advice of the author of the http://rtklibexplorer.wordpress.com/ blog. If you don’t specify, then convbin will put all generated files into the same directory as your raw file.
If you do try to convert yourself and process again, I would be very interested to know if you also experience an increase in the number of satellites used.
I am mostly processing against CORS data that is about 20km away, and getting pretty good results (I am only after decimeter precision, however).
Matt
