For research, I am mapping trees in a forest using a PPK survey and emlid RS2+ units. We surveyed over 300 tress and post processed them in Emlid Studio with CORS data. We got accuracy within 20cm on most trees, some less some more. While doing this survey we had over 30 satellites in view.
We then went out the next day and re-surveyed 10 of the same trees using the same methods. Again, we got 20cm level accuracy for most trees. However, when the two CSV layers of the 300 trees and 10 trees are overlaid, some trees are 6m off.
Does anyone know why this is? My thoughts are that it is because of the tree canopy causing multipath; is there any way to survey trees without getting interference?
Hi Katelyn,
Welcome to our forum!
GNSS technique doesn’t allow to eliminate the multipath fully. It is what we have to live with. When the signal hits obstacles, it reflects, causing a multipath. And tree canopies are obvious obstacles and sources of such interference. So I’m pretty sure that’s the main reason for the issue you’ve faced.
However, the final result also depends on the post-processing settings. It’s possible to tweak them slightly to make the outcome more robust and solid. I can try to reproduce it in Emlid Studio if you share your dataset. Since it contains sensitive data, you can send it to support@emlid.com.
1 Like
Can you make the raw-data available for a reproduction run ?
Sometime parameters can be tweaked to allow for a better solution.
1 Like
Just to make sure, the base position is a CORS or you manually entered the same coordinates as the day before on your own base receiver?
1 Like
Thanks for the explanation! I cannot email the files because they are too big, but after post processing the data, all of my points are FLOAT and none are FIX. I think this is the issue. My understanding of float and fix is that points are float because during the time the point was taken, satellite connection was interrupted, and fix is when satellite connection is continuous. Is that a correct understanding? Could you explain float vs fix a little more?
Also since we think the issue was with satellite connection in the field is there any way to correct that in post processing? Our thoughts are that we need to redo our survey as RTK (so that we know in the field if we have float or fix) and use a mobile hotspot in the field to have connection with a base station, and the base station we would use is the CORS base station. Hopefully, that would avoid multipath from the tree canopy better because the hotspot would be next to us, below the canopy.
Hi Katelyn,
The FLOAT solution doesn’t provide you with centimeter accuracy. In this case, the accuracy may vary from decimeters to several meters, so this offset you observed is quite expected. The centimeter accuracy can only be achieved with the FIX solution which means that the receiver performed initialization and resolved all the ambiguities.
If satellites are visible, they always send data to the receiver. But the thing is that its quality may be quite poor, so the software can’t use it in post-processing to get the centimeter accuracy.
If you can do the survey in RTK, it’s possible to use the PPK workflow as a backup. If some points weren’t collected in RTK with the FIX solution, you can try to post-process the data to improve their accuracy. This is called Stop & Go mode and is described in our guide.
Just in case, you can use WeTransfer to share this data via email.
3 Likes
Katelyn,
The reason for multipath is tree canopies themselves. It doesn’t matter if the mobile hotspot is close to the receiver: it just needs to connect to the Internet, which in turn allows it to receive NTRIP corrections from the CORS station. But multipath won’t disappear because the trees still block the sky view.
1 Like
Hi,
Thank you so much for this information, I really appreciate it. I just sent over the raw data. I have one more question for you: In the attribute table for the corrected CSV, why do the easting and northing RMS columns have accuracy of 20cm and less if the points were taken on float and are not that accurate?
Katelyn,
Thanks for the data! I’ve tried to post-process it but without any significant success. I could obtain 5.2% of FIX solutions in the pos file and only 1 point processed with the FIX in Stop & Go:
I’ve checked the raw data quality and saw the noisy log full of cycle slips: red bars that occur when the signal interrupts.
This happened due to inappropriate conditions of your survey, all points are located in dense forestries.
Just for comparison, you can take a look at the log from the CORS base:
Overall, I’d not recommend using GNSS receivers in such extremely harsh conditions. At least, if you need to survey trees with centimeter accuracy.
2 Likes
Hello,
I really appreciate your help and knowledge on this! We will evaluate other methods for getting tree coordinates.
Thanks again,
Katelyn
1 Like
Katelyn,
I’m happy to help!
1 Like
What are the ideal settings in ES to get a more robust and solid solution?
Likely the shipping defaults.
While you might be able to get more fixes with tweaks, it doesn’t necessarily means that the resulting coordinates are accurate.
Garbage in, garbage out, as they say.
2 Likes
If you were to buy a commercial post processing processor, you would know what the positional accuracy is.
Emlid Studio is just a single baseline processor. We’ve got two major brands of pp software, Trimble and Javad Justin 3. I prefer Javad’s processor over the Trimble processor. It’s a far better processor and more robust than even NGS OPUS. The cost is $2490 and can do many wonderous things !
http://www.javad.com/jgnss/products/software/justin3.html
With a commercial post processor, you can compute loop closures of your data and know what the positional accuracy is. Loop closures (closed polygon baselines) is the only sure way to know that the supposedly “fix” solution in your controller is valid.
2 Likes
Bryan, I know you have mentioned using a couple of Emlid M2’s in conjunction with your Javad equipment, in order to get shorter baselines in your post processing workflow. Is Javad Justin 3 able to use the converted Emlid UBX files to Rinex in it’s solution? I wasn’t sure if you were using the M2’s with Trimble or the Justin 3 software. I know it says on it’s website, that it is capable of using Rinex files, but another software said the same thing and turns out it can’t handle Emlid’s converted UBX files. If it does, I plan on purchasing it by the end of the year.
Also, isn’t Justin 3 the same type of software used in Javad’s online DPOS solution that I have read good reports about? I’ve been waiting for OPUS to go to their multi-constellation solution for their PAGES software, but I guess they are still working on it.
Are your static Emlid M2’s set up on known points, or do you locate them with a RTN solution or do you post process them first using a CORS station and then process the rest of the data? I do use a RTN service, but was curious on how you do it.
One more question, does the Justin software utilize a USB Key? Not a deal breaker, I have a couple now that I use with different software.
Thanks, Mark
Katelyn, I along with a buddy have done alot of testing recently and come to realize that the RTK accuracy is very very good and the PPK accuracy varies alot (and in some cases is terrible). The ublox receiver provides all satellites for RTK but not all are logged for PPK. So moving forward I am only going to use the RS2+ in RTK for reliable results. If you have no obstructions then your results will likely be ok in PPK. But if you are shooting points near/under tree canopies, close to buildings, etc, then the PPK results will likely be poor where the RTK results will be very good.
How did you do your testing, and what is “very good” in your opinion?
Christian, I want to be very careful not to saying anything that is incorrect. For testing I have used my Trimble S6 with a stacked setup (rover over prism). I wanted to see how accurate the RS2 was to the S6 under trees, next to the house, etc. I was very pleased with RTK!
I consider 0.02’ or less to be excellent. 0.04’ or less to be good. Anything above 0.10’ is not so good and anything above 0.5’ to be bad.
For any test I want to use the same base (local RS2) for the RTK as the PPK using identical base coordinates.
The fact is there will be some shots that are a fix in RTK and a float in PPK. What I should really say is that it is clear to me that doing RTK is more reliable, not more accurate. Because if you do PPK and the solution is a float and it varies by .5’ to 2’ from the known elevation, the solution and residuals should show that.
What is really needed is reliability. I used to be “PPK is king…”. But now I know that RTK is very reliable (provided you have good communication). For small jobs, the LoRa antennas do well. When a good cell signal is present the Emlid caster works like a champ. I will test these eByte E90 units and make sure they are reliable and practical to setup. The guy in Cambodia (I think that is right) has a very slick setup mounting radios on a bracket that is between the pole and the Emlid. So if they prove effective and reliable, I will do the same.
For the lidar mission I just did this past weekend. The CSV seen below is from the RTK survey. I have pasted in the PPK elevation values. Of the 6 that way off, they are all float solutions. The RTK was more reliable and I believe it will always be that way.
Did you test compared to a total station, or was there a reason for the prism setup?
Was the coordinates compared to the other GNSS you owned?
1 Like
Hi Mark
I use Javad Justin 3 for post processing of all our Javad receivers and my Emlid receivers.
As far as Emlid’s receivers, it’s a hit and miss with using the rinex files from them. From experience, the rinex file must be clean , i. e. no multipath. Even then Justin 3 has issues with post processing the Emlid files. During adjustment of a control net, it’s not truly adjusting the file for some reason but looking at the baseline residuals they are mostly <0.05’. The baselines to the Emlid receivers are not shown as “fixed” even though the computed baselines have low residuals as shown in the baseline solutions.
I’ve checked on known passive marks and the computed solutions are good but it worries me using in any important projects. I’ve contacted Javad support but since Javad himself has passed, the support group has all but been dissolved because of the Russia-Ukrain war. The Javad office in Russia has been shut down due to the war and they people in the software unit has mostly disappeared. They last version before I updated the software had no problem using the Emlid rinex files, but the latest version 1.80.21 is having the issues as stated above. Justin 3 does not use the native .ubx files.
It uses a USB key for the software which I like just like my Global Mapper software. I have Justin 3 on 4 work stations just like Global Mapper.
Trimble software also has issues with the Emlid rinex files and I don’t use it much if at all because it has issues with Javad rinex files. The only reason we have TBC is because of our old receivers but we haven’t used them in about 6 years since we purchased Javad. From what I’ve seen on the web, Ezsurv can ingest the native .ubx files but I’m not really sure. It would be nice to also have that, but our bookkeeper is tight with the $$ I can spend. I think Christian Gruner uses Ezsurv. I’ve heard good things about how easy it is to use.
If you want to try Justin 3, I think you can get a 30 day trial. Contact Adam Plumley at 704 477-3603 or by email at a.plumley@javad.com. Javad has a weird way of selling their products, you contact the dealer and he orders your selections then you have to call to make payment. You can’t buy anything on their website.
I think there’s some kind of issue with the translator from .ubx to rinex. The first time I contacted Javad about the rinex issues, they ask how it was translated and I told them by Emlid’s software. I don’t know why Ublox hasn’t provided a true translator, most of not all manufacturers do.
Justin 3 is an excellent post processor but it has problems with low cost receivers rinex files for whatever reason. Javad’s online processor (DPOS) only works with Javad receivers. Justin 3 software gives a DPOS report just like the online processor. The software really weeds out the bad multipath signals and gives excellent results when used in the woods as static, local RTK or when using our states RTN. We also have RTPK on both Triumphs when using a local base. You can verify an RTK position using real time post processing in the field using the base’s files as it’s transmitted real time to the Triumph LS rover and post processed there. It’s pretty cool using it. No one else has anything like it.
I’ve sold one of my M2’S to a friend of mine… he’s not a surveyor but someone who likes to play with new tech toys. I’ve still have my RS2 and M2 but I don’t use them like I used to. We’ve got 3 Javad T2’s and 2 Triumph LS receivers. They are truly scientific receivers as Javad was the king in signal processing. Their operating procedure is like from another planet, there’s a steep learning curve at the beginning but once you get a hang of it everything falls into place and then it amazes you of the operation logic.
I like Emlid’s receivers but they are very sensitive to multipath and I think that’s part of the issue in the rinex conversion but I’m no software engineer. If Emlid is going to stay in GNSS business, they need to have another GNSS chip developed. Javad actually makes GNSS chips for other manufacturers. Using the Ublox chip for entry level receivers is great and has a good price, but users will realize eventually the limitations of their receivers
1 Like