I am attempting to use CORS Rinex data in conjuction with our UAV log file, using Emlid Studio 1.1.
The UAV is a M300 running their latest firmware.
While in-flight, we received a notification on our controller when the RTK symbol on our DJI smart controller changed from a green color to an orange color and with a “-” symbol. As a result, I wanted to process using PPK to compare the camera locations to verify the RTK data.
When I process within Emlid Studio, all the results are in float. In addition, I have been receiving a “Something Went Wrong” error also. I have forwarded a technical report to Emlid for their review.
I have attempted two different CORS locations. Each is approximately 30km from the site location. A screenshot of the satellite signals
Try reprocessing the solution with GLONASS turned off. Sometimes this is helpful if one of the GLONASS satellites is throwing off the solution. For your obs and NAV files, you can upload them to google drive or weTransfer and post the link here.
I believe we’ll figure it out, but I’d check your files to reproduce this issue. If you’re not permitted to upload files here, please write us to support@emild.com. I need the following ones:
I did attempt a similar kind of data processing activity today when I was test flying in RTK mode and lost wifi connection to my RS2+ base station caster, loading into Emlid studio showed ALL as float not fix. Whereas in PPK mode with drone NOT in RTK mode showed as as Fix which is expected behavour and workflow for PPK as far as I’m aware. Attempting with RedToolBox utility (processing as though were PPK) with the RTK data showed the majority of photos as Fix and smaller number as float (which I would kind of expect) but when processed it showed all points as fix in the report - so this might have actually corrected those which may not have had an RTK “fix”. I’ll drop their support team a message to clarify the behaviour I saw as this might help you if so REDtoolbox – REDcatch GmbH.
the RINEX *.bin/*obs and MRK files on the drone, recorded during flight, are independent from any existing RTK correction.
If you receive FLOATs there is always a reason for it
at base station: poor satellite constellation, number of satellites, sun eruption, base station distance >30km, …
at drone: harsh conditions with lots of wind gusts, flight speed too fast, abrupt elevation changes (terrain follow mode in combination with flight speed), sun eruption, …
BUT: (from our perspective) It’s in-depended whether if you flown in RTK mode or not.
One mor info about processing in REDtoolbox software: We do not “correct” the selected non-RTK coordinates of photos. PPK is always a full new processing of the whole flight path and assigning the new image centre coordinates to ALL the photos. (so eventually existing RTK coordinates in *.jpg were dropped)
As I know, RTK drones always record their logs in case there’s no way to get FIX during the flight. So you can post-process and geotag images using the logs from the drone and the base. And there should be no separate PPK mode - PPK is always a backup plan.
Would you mind sharing the logs with me, so I can check why you received FLOAT solutions? You can send them privately to support@emlid.com.