Reach m+ triggering

how do you trigger the reach m+ with a camera without a flash shoe. for instance, the agricam or mapir camera for ndvi mapping has a trigger input from the flight controller but no flash output.

You can use an Arduino to create a multi type trigger, i.e a pwm trigger for a mapir and a reach detectable trigger.
Tou can generate the trigger either from an external event (DJI Phantom LED blink for example) or a fixed time period.

Do you then send the signal to the Time Mark or GPIO on an M+

Hi Adam,

May I ask you to clarify your question? The time mark pin is used for saving time stamps, it should be connected to camera hot-shoe.

I’m trying to trigger from an Arduino, not a hot shoe. Using the GPIO is the best way, however, I can send a 3.3v signal to Time Mark if necessary.
What input current goes to the Time Mark input, 100mA?

Hi Adam,

It’s better to send a signal to Time Mark pin directly, cause it allows you to make more precise time measurement.

Time Mark pin is open drain. You just need to switch it to the ground to record a time mark.

Hello Tatiana,

Have you at emlid done testing to confirm the that the actual accuracy of the time mark recording lives up to the expectation? I’ve posted another topic about it and my time marks look suspiciously ordinary. Like there’s some kind of pattern to the rounding, and not nearly the randomness I’d expect to see.

From my other post:

1 Like

I posted a clarification in the other thread for my same post as directly above. I’ll do that here too, so no one sees this as unresolved.

I think the emlid/u-blox timing is very accurate/precise. What I think I’m seeing is that the flashing of the LED lights on the P4, which I’m recording as events, is driven by pretty stable timing. They are also only coming on at intervals which seem to be spaced at multiples of 0.04 seconds. This seems to occur whether triggered manually or automatically. I see this timing behaviour now with a P4P, P4A and P4.

So it seems like I have to live with 0.12m uncertainty at 3m/s flight speed, 0.24m uncertainty at 6m/s, and so on and so forth.

My logging also seems to suggest very consistent response times of photoresistors. Photodiodes are supposed to be quicker to respond, but in this application where you’ll be applying an offset backwards in time anyways, It’s irrelevant how quickly you capture the secondary event. A secondary event which is delayed anyway after the real event you are interested in.

This won’t matter soon anyways as the boss has green-lighted a P4 RTK. Side-by-side testing will confirm or sink my 0.04s interval hypothesis. Which will show up as reductions in the along-track residuals after processing. Exciting times.

The LED goes off prior to shutter operations, so I estimated about a 30ms uncertainty. Glad to see it is probably tighter than that.

sorry, I edited my post. I meant to say that the LEDs are coming back on at 0.04 second intervals. I’m recording them coming back on as my event, so I have to offset this time event record backwards.

1 Like

Simon, are you detecting the going off of the LEDs? and if you are, can you tell me what your estimated delay to middle of exposure is? Just interested to see if it’s same as delay to LED coming back on.

Depends on the model and the shutter speed.
With the P4 with rolling shutter, of which I have experience, the ‘roll’ take 33ms, seemingly independent of actual shutter speed. I haven’t investigated much further. My module has been superceded by more sophisticated methods. Also I kinda came around to the idea that a good camera calibration and GCP’s was a far more robust solution.

1 Like

I believe the 33ms has, at least, been documented on pix4d website.

Did you determine that the rolling shutter starts the instant the LED goes off? I was wondering if the image capture was in the middle of the LED shutdown. I estimated the LED comes back on about 0.194 seconds after the middle of the image capture. At least, this value gave me the smallest residuals during photogrammetric processing.

Hi @wsurvey,

Sorry for the delayed response! As I see you’ve already figured it out. Anyway, let me confirm your thoughts.

Time marks are recorded with nanosecond accuracy. Time mark pin is connected to u-blox chip directly what allows to get such precise measurements.

With LED connection there will be a delay after the shutter triggers as there is no direct connection.

1 Like

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.