Hi there. I recently flew a mission on our fixed wing drone (fitted with M2 unit) and had our RS2+ set up over a surveyors peg with known coordinates. I entered these coordinates into RS2, flew the mission and then went into E.Studio to post process.
When I pulled the RINEX file across into Studio from the RS2 the coordinates did not correspond to the surveyor’s coordinates so I entered them manually (WGS84 and ellip. height). I also pulled across the navigation file and then the RINEX file from the rover (M2). Processed it all and a heigh majority came back as “single” (more than 80%). The rest was divided up into “float” and “fix”.
What is causing this lack of accuracy?
I have provided the survey company with the tagged images (from the above processing) but they have advised that their photogrammetry software is indicating that the images are not PPK. I assume this is because most of the images were tagged as “single”.
I have looked at the pos. file and the positional errors for the “single” tagged images are way out of place (up to 30m).
Is someone able to help on what I am potentially doing wrong here please?
PS - i am looking where I can upload the pos. file but dont think I have permission to do this.
Can you provide the raw-data over i.e. a WeTransfer link ?
Hi Grant,
Thank you for the data! I’ve checked it and found out the most likely reasons for this issue.
The thing is that your base log has very poor quality. Take a look at the screenshot below:
There are a lot of red bars that mean cycle slips. Cycle slips appear when the satellite signal is interrupted or interference sources nearby affect it. I see that satellite signals were interrupted during the entire session. It may show that the receiver was placed at inappropriate environmental conditions or there was substantial interference. Where was the base placed in your case? Was it provided with the clear sky view?
Regarding the rover’s log, it looks much more better. However, there are also indirect signs of the interference, as shown in the screenshot below:
Since 16:05 (GPS time) signal-to-noise value fluctuates periodically. You can see it as the bar color changes from violet to orange, and from blue to violet. It may be caused by the drone’s electronic affecting Reach. We recommend isolating Reach from all potential interference sources that may cause such issues and decrease log’s quality.
Is it possible to send the hardware setup photos? I can look and check whether Reach is installed properly in the drone.
Hi Kirrill. Many thanks for the above explanation. Please find a photo of where the base station was located. It was in an open area of a park. There were trees around but nothing in close proximity.
I will send a photo of the M2 setup within the drone
What type of two-way radio is on the equipment box? Was it near the base and transmitting during your flight? It could be a source of interference.
Its an aeronautical radio. Was only used to monitor local air traffic. No transmissions were made on the radio at any time during the mission.
Another question on the base setup. I had the base set over a known point and entered these coordinates into the ReachVeiw3 software through “Base Mode”. Is this correct? Or would it be better to just leave the base position as is (its own calculated position) and then enter the absolute coordinates in Emlid Studio prior to processing - change RINEX Header position to a manual position in Emlid Studio?
Hi Grant,
You can try to place Reach in other location without any radios nearby. Please record the raw data log and send it back to me, I’ll examine its quality. Just to check whether this behavior is repeatable.
If you input coordinates in the Base mode in ReachView 3, they are applied for RTK. As for raw data logging, they don’t affect it. So, it’s better to save these coordinates for manual input in Emlid Studio.
thanks Kirill
I cannot go back to same area to set up RS2 (its a 3hr drive to get there) but I did set up the RS a few days ago in order to PPP the raw data to check on accuracy. I cannot upload files to this forum so below is the link to the zipped and raw data for this. Appreciate all the help.
https://1drv.ms/u/s!AuC7tz2Dddtdg714nGCtFuxA89MvHQ?e=CjBO1P
Hi Grant,
Well, the same behavior as in the previous location:
It’s quite strange that there’s strong interference in the beginning of the session, and then it disappears. Just for sure, were there any interference sources like radio transmitters or something else?
Please send me the Full system report from the device. It’s worth showing it to the devs to check out what can be the reason for that.
Thanks Kirill. I will download the FSR and send via email. Do you think it could be an issue with the Reach unit itself? Its only about 2months old and ive had constant issues with trying to PPK the data.
Grant,
I can hardly draw any conclusions before we analyze logs. Once I get any updates from the team, I’ll let you know.
oh and just to confirm, there were no possible sources of radio interference in the area. Its an open area where I do flight training and flight testing
thank you, ive sent the FSR via email now.
Got it!
I’ll keep you posted.
ya lo he estado analizando, pero requiero los archivos ubx
Al el ruido disminuye utilizando las constelaciones glonas y gps.
faltan los ubx del movil (m2)