We have been using RTK equipment for different applications and I think we kind of know what we are doing. However, when it comes to REACH things are really weird. I am not talking about RTK(which we have given up already), but about post-processing kinematic solutions. We get some fixes (<20%) when the rover is static but as soon as it takes off with the UAV (flying not faster than 2m/s) we get float solutions (in the best case) and SPPs. We have good ground plates, but even with those C/N0 is not that great. The really weird thing is that when we replace the REACH base with a commercial Leica receiver (+antenna) we get even less fixes. There is something really weird, and after spending weeks on debugging we start loosing motivation to try to make that product work (or at least bring it closer to a state that one could call working). So here’s my question: How are your fix ratios in post-processing and was your rover moving during that time?
Hello Thomas,
Please post Rinex files, picture of your setup and how you are processing the files. Bad C/N0 could be caused by interference from other equipment on the aircraft, it is not only ground plane dependant.
An example of good results can be found in the docs.
Dear Ivan,
Thanks for the reply.
Please let me know your email address and I can mail you a link from where to get the file. I am not going to share them in this forum as the data will be used by one of our students in a master thesis project.
Thanks for your understanding.
/Thomas
Dear Thomas,
You can send them to support@emlid.com with a link to this thread. Please archive them and make sure that they are <15MB. A link to download is perfect.
So, plotting the observations with RTKPLOT reveals the source of the issue.
Base observations are plotted on the left and rovers are plotted on the right. Red marks show cycle slips. While base has almost perfect data, rover experiences heavy interference from some source. This also explains why replacing the base with Leica did not help, because base was not the issue!
This kind of analysis has been shown in the post-processing tutorial. Getting fixed solution requires finding the reason of why the collected data is so bad.
My suggestion is to remove Reach and antenna from your UAV and test it separately. You should get equally good observations on rover and base and solution with good percentage of fixes. After that you need to find which component on your drone is causing interference and move antenna as far from it as possible.
Real-time SNR view in ReachView is great help when integrating Reach in a drone. Just remove power from other equipment on board and bring it back one by one and observe SNR, if it drops by 5-10 points on power up of a certain device you have found your cause!
Best regards,
Igor
Thanks. Yes we found that as well. However, we get very similar results even if we don’t mount it on the UAV, but just walk around…
There must be something different between how base and rover are setup that will explain it.
Yes, but since we perform all analysis with the raw observation filesit can only be the antenna or the UBLOX chip. Or do I miss something?
Try to swap receivers / antennas / place and isolate the reason.
Maybe you can also post some pictures?
I try to setup an experiment tomorrow and come back to you…
We were running some simple tests (walking around with a reach unit) after installing the latest firmware and software updates. Things look slightly better. More tests next week …
We finally got fixes (>90% in post processing). We had to separate the antenna from the reach further away and also had to put each of the components quite far away from the drone body (roughly 20 cm above the hood). Beside this mechanical fix we confirm that only the very latest REACH software/firmware version gives us satisfying results. In the end a workaround that serves our purpose …