We have just started using a Reach M+ with a Reach RS+ base station PPK set-up. We are flying our commercially-purchased drone over a tropical forest with tall trees and variable topography (<= 150m elevation). We have four flight paths, with each one being successively farther away from our take-off point. Today we did the first 3 and discovered that we lost connection with the controller (and data link loss) for roughly 6 periods ranging from 10 seconds to 4 minutes, 54 seconds. During this time, the drone continued with the flight plan and continued taking pictures.
I was processing the information in Emlid Studio this evening and found a mismatch between the events in the .pos file (277) and the images (288). I read through some previous discussions here such as this one and this one.
My thoughts
I believe the connection loss is leading to the missed events in the Reach M+. Here is a Google drive link that contains our logs.
Question
I have a few questions:
Is the solution for the connection loss to simply move to a better location with the base station and controller? Would wrapping the Reach M+ in foil help with this?
Iāve seen on previous discussions that a workaround is to manually alter the .pos file. However, it is possible we will have many flights in the future that will involve connection loss. In that case, is there a reliable post-processing step we can take?
I believe this is related to our situation, but would changing the settings in Emlid Studio help with this, such as in this topic? I did already try changing the Elevation mask to 5 degrees, Filter type = combined, and Integer Ambiguity Resolution to āFix and holdā. It did increase the number of FIX points we had, but only by a small percentage.
Is the solution for the connection loss to simply move to a better location with the base station and controller? Would wrapping the Reach M+ in foil help with this?
A tropical forest could be a challenging environment for single-band receivers. For similar projects, we mostly suggest our multi-band receivers that can handle these types of conditions more easily. I checked your log and saw many gaps and cycle clips too. Most likely, these are the reasons for the connection loss and the difference between the events in your .pos file and your images. But I agree with your ideas. A better base location and the foil around the Reach M+ could improve the quality of the log.
I believe this is related to our situation, but would changing the settings in Emlid Studio help with this, such as in this topic 2? I did already try changing the Elevation mask to 5 degrees, Filter type = combined, and Integer Ambiguity Resolution to āFix and holdā. It did increase the number of FIX points we had, but only by a small percentage.
It could indeed be a good solution to get more FIX. You tried the same settings that we usually recommend, but overall, if the quality of the log isnāt good enough, these changes wonāt have much of an impact on the result.
Thanks for your response. We have now tried another series of flights, and on one of them we had 98.9% FIX but we still had a mismatch of the photos compared to the events (here, 288 photos for 283 events).
Is there an easy way to tell which events are attributed to specific photos? That would help a lot with knowing which ones to include for building an orthomosaic. I included the most recent log files in the same google drive link from my original post.
Iāve discussed your case with the team. Iāve modified my previous message because it was misleading. Sorry for that. We donāt recommend modifying .pos files after the survey. Itās usually more effective to deal with causes than effects. In most cases Weāve seen, time marks were missing because of issues with the hardware setup, like RF interference or loose connection between the Reach and the camera. If itās fixed, post-processing doesnāt require any additional steps and becomes much easier.
Most likely, connection loss between the drone and the controller should affect the results this way. Reach M+ continues writing raw data all this time and continues recording time marks if it receives a shutter signal. If you trigger the receiver via autopilot, and the signal doesnāt get to the device, maybe it can cause such issues. Could you please try to use the Timelapse feature instead of Autopilot?
Thanks for your response! We have a couple follow-up questions, but weād also be happy to set up a meeting with Emlid to chat if that would be easier.
Is the timelapse feature the interval shooting mode on the camera itself or QGround Control?
Are there any potential issues we need to be aware of if we use the Timelapse feature?
Our understanding is that the flight plan created in QGroundControl sets and controls the cadence at which photos are taken via usb connection from the drone to the camera, then the M+ is ātriggeredā via the hotshoe adapter connection with the camera. Both of those are cables, and while cables can be susceptible to interference itās not clear to us that this is the interference you mentioned rather than the drone āradioā just sort of overwhelming the GPS signal. Otherwise, we donāt see how the drone-to-controller connection would affect the M+ unless there is some feature in the droneās flight software causing an unexpected behavior when it loses connection.
I believe itās better to continue the communication here, since it may be helpful for others. Let me answer your questions.
Is the timelapse feature the interval shooting mode on the camera itself or QGround Control?
Thatās the interval shooting mode on the camera.
Are there any potential issues we need to be aware of if we use the Timelapse feature?
We donāt have any known issues regarding the Timelapse feature, but as always, itās better to do a test survey before the actual work to see how it works.
Our understanding is that the flight plan created in QGroundControl sets and controls the cadence at which photos are taken via usb connection from the drone to the camera, then the M+ is ātriggeredā via the hotshoe adapter connection with the camera. Both of those are cables, and while cables can be susceptible to interference itās not clear to us that this is the interference you mentioned rather than the drone āradioā just sort of overwhelming the GPS signal. Otherwise, we donāt see how the drone-to-controller connection would affect the M+ unless there is some feature in the droneās flight software causing an unexpected behavior when it loses connection.
Actually, you are right. The cables can be susceptible to interference too. So itās better to protect them as much as possible. We canāt provide a complete solution for this, but you can find some possible solutions in other forum threads.
Thank you for your response. Have you seen this problem occur before? In our case, cable interference is unlikely given all other cables appear to be functioning properly, so is there a reason that the hotshoe cable would be more susceptible?
If the cable interference issue is not influencing any other cables in the drone, it appears likely to us that one or more of the cables, connectors, or device components are faulty. How do you suggest we test for faulty connections or components of the Emlid system?
Sorry for the late reply, Ian!
Itās not easy to tell whatās going on at this point, but Iād like to request that you send some photos of your setup. Perhaps I can spot something that can help.
Iāve never done this myself so Iām just speculating, but couldnāt you display the points for the photos on a map and also display the photos on a map using the EXIF coordinates, and align them that way?
Currently the main photo we have is this one, where the Emlid is just to the right of the camera left of the camera - you can see it here covered in foil.
@daygeckoart yep we tried that, but the problem was that we had several instances where we had ~5 points for different photos all given the same coordinates.
Unfortunately, itās not easy to spot the reason for the issue from this photo, but I can see that the hotshoe cable is a bit twisted. Also, it would be great if you could test the time marks triggering out of the drone. It will show whether the issue is related to the droneās electronics or the receiver itself. For this, you just need to connect the camera with Reach and run triggering. Then Iāll check the logs, the number of photos, and the number of time marks.
