He needs the patern of cable to connecting a camera and Reach M2 with a hot shoe adapter. The hot shoe cable sends a signal from your camera’s hot shoe to both the Reach Module and Pixhawk. The signal adds time marks used for geotags to the Reach RINEX log file and the Pixhawk DataFlash log.
Given needs to the modification Reach M2/M+ camera hot shoe adapter
Similar solution is here
http://tuffwing.com/support/reach_geotag_event_hot_shoe_cable.html
Hi @El_Geodetos,
Just to confirm, are you referring to this thread?
Hi, inkar.madikyzy
inkar.madikyzyEmlid
Just to confirm, are you referring to [this thread (Help with the best wiring M2 Pixcube and Camera)?
I think about this solution
[Tuffwing: Reach hot shoe time mark cable 4]
He indispensable is system diagram & pinout of the cable
Hi @El_Geodetos,
My apologies for the radio silence.
Although we haven’t tested this exact setup, it should work based on my understanding. However, splitting the signal cable seems quite complicated. We also don’t suggest modifying a hot shoe, as it may prevent the signal from being properly recorded by our receiver.
So, I’d suggest the following connection: Camera — Reach M2 — Pixhawk.
Does your camera support a hot shoe connection? If so, please use the Reach M2/M+ hot shoe adapter. Plug the hot shoe connector in a camera hot shoe and the JST-GH connector in the С1 port on Reach M2. It’ll record a time mark every time the camera is triggered. This data is stored in the Reach M2 logs.
Then, connect Reach M2 to Pixhawk using the appropriate telemetry port (usually TELEM2 or GPS2). I’m not familiar with the DataFlash logs, but from what I’ve seen on the ArduPilot forum, they include GPS time information. This includes data for all GPS instances, such as GPS week and milliseconds since the start of the week.
Depending on your setup, the camera can be triggered manually or via Pixhawk’s mission planner commands. Please refer to our guide on configuring the Reach UAV kit for PPK mapping .
UPD. I’ve updated my previous comment so as not to mislead anyone.
Hi, inkar.madikyzy
I know this solution and he works at me correctly.
From this what You wrote it would result, that in Reach M2 - NMEA/ERB log file the gauges of the time are also recorded . You can confirm this, because the doubt has that it is so.
Hi @El_Geodetos,
Sorry for any confusion earlier. From what I’ve seen on the ArduPilot forum, Dataflash logs include GPS time information. This includes data for all GPS instances, such as GPS week and milliseconds since the start of the week. Even though the Reach M2 sends position data to ArduPilot in real-time, I can’t say for sure whether the Dataflash logs reflect the time from it as a second GPS unit. I’ve updated my previous comment so as not to mislead anyone.
Could you please share why you want to send the signals to both the Data logs and the Reach M2? The Reach M2 logs should already have all the necessary information for geotagging your photos.
To my knowledge, when the autopilot triggers the camera, CAM messages are recorded in the Data logs. These messages can be used later to geotag your photos directly in Mission Planner. To trigger the camera, please refer to our guide.
Hi, inkar.madikyzy
In the case, when the method PPK not gives the good solution I wanted to use RTK/RTN.
You will understand the problem reading:
[Geotag RTK/RTN images – Emlid Studio - #7 by kornel.nemeti]
Until the use of my request - solution this in Emlid Studio [Geotag RTK/RTN images – Emlid Studio - #7 by kornel.nemeti] he needs: the hot shoe cable sends a signal from your camera’s hot shoe to both the Reach Module and Pixhawk. The signal adds time marks used for geotags to the Reach RINEX log file and the Pixhawk DataFlash log
Read: CAM versus TRIG messages in wiki - reversed? - Copter 4.3 - ArduPilot Discourse
a) When using a hot-shoe, a “TRIG” message will be stored every time the flight controller commands a photo to be taken. A “CAM” message will be stored every time the flight controller receives a hot-shoe signal - indicating that the shutter was released. If the camera fails to take the picture, the “TRIG” message is recorded, but no “CAM” message is recorded.
b) When not using a hot-shoe, only “CAM” messages are stored. There are no “TRIG” messages. Without the hot-shoe input, a “CAM” message is stored every time the flight controller commands a photo to be taken. If the camera fails to take the picture, the “CAM” message is still stored
Without the gauge of the time in Pixhawk DataFlash the log I will not receive good, the quality of the data.
Thank you for sharing this information from ArduPilot. I’ve discussed it with the team. For optimal performance, we strongly recommend using the hot shoe connection without any modifications or signal splitting.
The hot shoe cable connects directly to the GNSS chip, triggering the signal with minimal delay and ensuring precise timing. Even a small delay, such as 1 millisecond, can lead to noticeable inaccuracies in position estimates. To avoid such issues and achieve the best results, I suggest following our tested setups.
I’ve reviewed your previous inquiry about PPK. The quality of the logs and, thus, the environmental conditions should be improved. So, my main recommendation is to remove obstacles and improve the sky view for your unit in further surveys.
Having on the attention this you wrote, I ask the team Emlid for the quick introduction of the solution which suggests
https://community.emlid.com/t/geotag-rtk-rtn-images-emlid-studio/39150/11
Measurements photogrammetric he does not execute in the ranges of his hobby. He executes measurements on his customers order. I do not have the possibility of the choice the place of without obstacles to oneself. He executes measurements photogrammetric from the ground (not from drone). Often near obstacles such as the building. That is why my satellite observations, there will often the weak quality.
Simultaneous measurement PPK and RTK / RTN will improve my efficiency considerably, when PPK not gives the good solution.
here are the information which I needed here
Thank you for the details. I understand the challenges you face with PPK under your survey conditions. We’ve added your feature request to our internal list, but at the moment, we don’t have any plans to implement this feature, so I can’t provide an ETA.
This modification of the hot shoe might seem technically feasible, but the delay will vary for each setup, making it difficult for us to address it.
To help minimize these issues, we’ve designed a setup with Reach where the Time Mark Pin is connected directly to the GNSS chip. This eliminates peripheral delays, allowing the time mark to be recorded with nanosecond accuracy.
He thanks for the answer. I wait for more far information in this matter.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.
