I work a lot with my Reach RM2 on a self-made camera attachment. For this I use everything as described in the documents. Everything works fine so far.
However, I often have the problem that not all events are registered via the hot shoe. The hot shoe fits, works and cannot slip while working. I still use this self-made measuring unit “experimentally” - unfortunately only for this one reason.
My guess: as soon as the signal is too bad due to buildings, trees, etc., no entry is made. (is that correct?)
The big problem here is that it is not possible for me to assign the appropriate entries to the images. (fast sequence of images, no messages, etc.)
Am I generally doing something wrong in post-production?
Is it possible to get all events? (even if the result is nonsense due to buildings etc.)
Is there a possibility to assign pictures to the events afterwards? (I use different cameras, all of them only have a time stamp in the EXIF data)
Many, many thanks in advance!
Thanks for sharing the data! May I ask you to clarify how many images were collected during this flight? It will help me check whether it matches the number of time marks in the raw data log.
If the survey is held in difficult environmental conditions, the observational data might suffer from it. The low quality of observations might cause the loss of the time marks as it usually provokes interruptions in the satellite signal. I’ll look into the raw data log you’ve provided to check the satellite signal quality in your case.
The image center coordinates are not saved in the EXIF data during the flight. To calculate them, you will need to process the raw data logs from the Reach M2 and base station together in RTKLib. After you get the _events.pos file with the coordinates, you can use it to geotag photos in 3rd-party software such as GeoSetter. To learn the detailed workflow, you can explore our Geotagging photos with GeoSetter guide.
Thanks to you for the quick answer!
I took 215 photos.
My problem is that it’s not a classic flight. The EMLID unit is only connected through the hotshoe. So my end result are always pictures “IMG-1234” to “IMG-1345” and the data of the M2. If I have 215 photos, but only 214 survey entries, for example, I have a problem. (the fewer survey entries the worse)
With the large number of photos (all in quick succession, often poor conditions), I cannot reliably assign the measurement data to the images for photogrammetric work. If individual data is missing, this is not a problem at first if I know where / in which order it is missing.
I would need the “missing parts”, so to speak.
Can the GeoSetter program make this assignment correctly?
I will definitely try this out soon. Thank you very much for the tip!
For the example data: if you find 215 entries and you can tell where (or when) the missing measurements took place, my problem would probably have been solved.
Thanks in advance!
As far as I can see, there are indeed only 176 time marks in the raw data log you’ve sent. The satellite signal quality on the rover seems to be good enough for correct time marks collection.
Missed events can result from a bad connection between the camera shutter signal output and the cable from the Reach. I’d suggest checking your hardware setup and make sure that the cable is connected properly. Please provide me with these details so that I can help you to check the setup:
- Photos of the hardware setup
- How is the camera triggered?
GeoSetter can geotag photos with the same number of time marks only, so it can hardly help if their amounts don’t match.
What is your shutter speed typically?
Many thanks for the answers.
The camera is triggered manually via a cable release.
Nothing moves on the installation.
In this case i use 1/500
Can it be due to a connection between the M2 and the cell phone? Can there be interruptions here, which trigger missing TimeStamps?
Meanwhile, I carry the cell phone in my pocket (about 1m away). I use a Huawei with ReachView3. Calls can happen during this time, etc. (but did not occur in this case, as I can remember)
Is there another possible reason here?
But again for me:
All timestamps are recorded, even if the signal is “terribly bad”?
Straighten your wire-coils close to the antenna. The coils make for excellent inductors. Pair-twist Plus/Negative wires.
You could also try shielding your M-unit better.
If you enable logging on the Reach M2 and disconnect it from your cell phone, the receiver will continue saving time marks to the raw data log. So, the lack of connection to the mobile device can’t cause such an issue.
It looks like the camera shutter signal doesn’t reach the receiver in some cases. Please double-check your hardware setup to ensure that the receiver is connected to the camera as shown in the Connecting Reach M2 to a camera using HSA guide. To see whether the issue can be on the Reach side, you can try to walk through these steps:
- Take the unit and GNSS antenna off the camera so that the wire coils can’t affect the unit’s performance
- Connect Reach M2 to the camera with a hot shoe adapter
- Enable the Timelapse feature on your camera (if supported) or press the shutter button manually to collect photos
- Post-process the data and check whether any of the image centers are missing
I made the cables straight. They are no longer intertwined. Otherwise I haven’t changed anything. The M2 unit and the antenna are separated with steel as shown in the picture above.
On my last attempt, 25% of the entries were missing.
I’m not really getting any further.
Should I pack the M2 unit completely in a Faraday cage? (In this case, shouldn’t more people have the problem?)
Can I see when the last event took place in Reach View 3? (I didn’t find anything on the last try - maybe it’s also my hotshoe?).
is there a critical release speed? (image sequence too fast?)
Based on Amazon reviews, I have a strong guess:
The hot shoe dual adapter is just unreliable. There is also no “reputable” manufacturer of these adapters known to me. I will now change my construction so that I can do without this adapter. After that I will write again.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.