Hi I’m a new user and I’m reaching out because for several weeks I’ve really been struggling to obtain any fixed positions using either LoRa or post-kinematic processing. I’m concerned that my settings need to be adjusted. Although the base and rover are not new, I only recently set them up to work together. Two RS2’s with the newest firmware (also tried with v28 firmware).
Moving my base to a pristine open position seems to have fixed LoRa with fixed positions over an hour test period, but I’m still not getting a fix when using post-kinematic with the base and rover in the same positions. For test purposes I placed the base in an open position using Average Single, and logged points using the rover with the LoRa on and again with it off. All of the RTK points were fixed, and every position was float using Stop and Go in Emlid Studio.
Finally, I also tried correcting my rover with a local CORS station getting the same %100 float results.
I’ve attached the raw files for the base and rover, CORS, and the csv files for the RTK and Post-kinematic tests. I’m trying to correct the post-kinematic csv file. If anyone has any suggestions I would appreciate the help.
I’ve attached the zip archive with both pos files here.
The CORS log won’t be of much help here because it doesn’t contain Beidou observations, while Reach RS2 base does.
It’s worth noting that some points didn’t achieve FIX because they were likely located in harsh conditions (dense trees). I converted the CSV file to KML and opened it on Google Earth to check this:
Thanks for your detailed response. It helped to see what you did and then make those changes one at a time seeing how the results changed with each one.
That’s too bad. Eventually I plan to use these in a more remote wooded setting. My hope was that PPK would have an advantage in areas with poor line of sight where LoRa is poorly suited, but it sounds like these factors limit PPK as well.
Can I ask how you converted the CSV to KML? I’m trying to to the opposite conversion right now. Open point and line data from Google Earth in Emlid Flow. I’ve tried shape, dxf, and csv without any success. When using a project system of WGS 84 UTM 17N the points open in the pacific and don’t make sense, and when using the Global CS in Emlid Flow the points are not visible at all.
As far as using any GNSS receiver in a high multi-path areas, if you do, you better have a way to verify your observation position. As I’ve said this numerous times before on this forum, you can have short baselines with adequate time on station with closed polygon loops to verify your position .
The only receivers that can guarantee a precise position in high multi-path areas with single baselines are Javad receivers. These are not cheap, prices for the Triumph LS series receivers starts at about $20k. We have two LS’s along with the Victor LS system and they have paid for themselves at least twice with the guaranteed accuracy we require for boundary surveys and geodetic control nets.
However, you can do what I do when I get to go out in the field and get to use my RS2 and 2 M2’s. When on a large boundary project, I setup a static baseline in open areas about 1 km apart depending on the site . I can then use my RS2 as a rover in wooded areas locating creeks, property corners, fences, etc. by having static observations on each point. Using these three receivers, I’ve got a closed polygon loop (2 M2’s baseline and the RS2 rover) on each point or object located. Sufficient time on station (a minimum of 30 minutes) for short baselines that are <2km is needed for an accurate positioning depending on the surrounding multi-path conditions. With commercial post processing software you can process all closed loops at once and have a confident verified position of your rover points.
You can actually use Emlid Studio (free) for determining loop closures by processing each baseline using the computed position as a base for the next baseline. Comparing your final computed position of the closed polygon against your starting position will indicate the accuracy of the rover point and closed polygon. Once you determine the error of closure (delta error in N, E and Z components), you can use various methods to “balance/adjust” your GNSS traverse baselines for a mathematically perfect loop, i.e. using Compass rule, Crandall’s rule or even least squares adjustment. There is even a free least squares software package called SALSA developed by the University of Texas you could use. It can adjust both closed polygon GNSS baseline loops as well as terrestrial traverse loops.
In conclusion, using GNSS receivers in high multi-path areas without any kind of verification is taking a lot of chances depending on the so called “fixed” position it indicates.
I wish you would put together a step by step for this workflow. It’s not really something I need to do, but it sure does sound confidence inspiring and overall good practice.
Thanks for the feedback. I’m a new user and I don’t especially have a background in this kind of surveying. As a result I don’t have an informed opinion about the different receiver brands and it’s good for me to hear this.
Could you use a CORS station like this in lieu of a third receiver, if I only have two?
It’s good to hear this but to better understand how it relates to my work, can I ask how this relates to accuracy and precision? Are you saying that the the RMS values reported on the receiver are not trustworthy, or perhaps that the confidence is too low, or just that the accuracy will never be good enough in wooded settings? I do environmental work and we have less rigorous requirements than civil. Not having survey grade precision does impact what I can do, but submeter is acceptable for lots of other things.
You could use CORS but your occupation time will increase significantly for longer baselines. Ideally, you want your baselines to be short as possible to the rover locating points in the woods. This will shorten your observation times. However, observation times in the wooded areas will depend on the amount of sky you can see. I’ve made this analogy before: if it’s raining and you’re out in the open and you’re getting soaking wet, (great GNSS coverage), you are being covered in GNSS signals. If you go into the woods to get out of the rain, you’ll not get as wet as in the open field; fewer rain drops (fewer clean GNSS signals). We’ve used our Javad receivers all the time in wooded areas, and never had a bad position. But as I’ve said before these receivers are not cheap. If your locating your points in the woods most of the time, I wood highly recommend buying Javad. There’s nothing wrong with using low-cost receivers in high multi-path areas, but to be convinced of the accuracy of the located point will require verifying the point by either closed GNSS loops or closed terrestrial traverse loops.
If you’re not too concerned with accuracy, you can get meter to sub-meter depending on occupation time and length of observed baselines. If your CORS are not too far away (<20km) you would need to occupy at least an hour per point. This is based on your experience experimenting with observation times and multi-path areas. There’s no set time occupation to determine your accuracy of these points. You’ll just have to experiment like the rest of us do. Using the rms values shown will give you an idea of your located point accuracy but I would not depend on it for any stated accuracy without verification.
Let’s imagine that your using two CORS, assuming the baseline lengths of your point to the CORS are <10 km. You can post process each baseline (CORS1 to point, CORS2 to point). At least in this example you’ll know the accuracy of the point, it’s a simple matter of inversing between the two computed points to determine your accuracy. This would give you a simple idea of the accuracy of the point located. As said above, you’ll have to experiment with your occupation times in the woods.
Sorry, I forgot to attach the archive with the resulting files in the previous comment. Here it is. Mfmaddox.zip (1.9 KB)
That’s not the reason to get rid of the PPK workflow. In this case, it worked out that LoRa gave you better performance. However, in other cases, it can be vice versa. PPK and Stop&Go are good ways of data backup, particularly when there are some issues with the RTK link due to poor internet or LoRa limitations.
