Time mark delay feature request

I have a feature request to enhance the the location accuracy of the time marks of aerial images.

The problem: there is some delay between when the camera has taken a photo and when the time mark is captured. When the UAV is moving this leads to a constant offset, where the time mark is either ahead or behind the UAV depending on flight direction and speed.

This delay is measureable in post processing and could/should be adjusted by the onboard emlid unit. There should be an extra field in ReachView in the Camera control tab, where the user can input this delay.

How much improvement can we achieve? In my case I use a Sony A6600 and an Emlid M2 with the hotshoe adapter and my delay is approx. 17 ms. This means an error of 8,5 cm at 5 m/s flight speed, 17cm at 10 m/s, 25,5cm at 15 m/s and so on.

1 Like

Personally, I would much rather have this be an input parameter when post-processing the data?

I am not sure how Emlid processes time marks. If only the exact time is saved, when the camera is triggered, than this would be possible.
However if the onboard unit already interpolates between two coordinates and then saves coordinates, than this could be more difficult in post processing, since a new re-interpolation would be necessary.

edit. Ok, I inspected the RINEX file from one of my surveys and it appears, that only the exact time is saved as a camera event. In this case the compensation could also be done with a simple script before post-processing, that simply subtracts the delay from the camera events.

Hi David,

The time mark pin on our devices is connected to the GNSS chip directly. This allows you to collect the time marks with nanosecond accuracy.

That’s why a constant 17ms delay seems rather unusual. Would it be possible to share the photos of your hardware setup?

1 Like

I thought ground control points in the images solved this problem with time or helped resolve it ? Am I missing something ?

1 Like

That’s why a constant 17ms delay seems rather unusual. Would it be possible to share the photos of your hardware setup?

Everything is connected exactly like the manual.

I cannot quote it, but somewhere I read that other people also have this issue. The delay might not be caused by the emlid unit, but could also be the cameras fault.

I thought ground control points in the images solved this problem with time or helped resolve it ? Am I missing something ?

We don´t always have the luxury to place and measure GCPs. Sometime we can only access the area from the air.

1 Like

Hi David,

Could you please specify how you measure the offset? Do you use the time mark pin from another port (C2) for it?

I estimated the delay using Agisoft Metashape.

To do that I had to do a flight with lots of GCPs and let Metashape calculate the offset between the antenna and the camera. I always fly forwards and got an error in flight direction, that is dependent on the flying speed. If I know the physical offset and the one that is estimated I can calculate the time delay based on flight speed (which I also know).

I do believe, that this error is coming from the camera. I have read on various camera forums, that people have problems with the flash being delayed on the Sony a6300. Maybe this problem persists on the a6600, which I have.

However it would still be nice to be able to compenate for this, since the delay seems to be constant (as far as I can tell).

Have you set the camera to use Front Curtain sync?

Front curtain flash is the default setting, which I haven´t changed. Do you recommend something different?

Theoretically the difference at my shutter speeds (1/600 or 1/800) should only be about 1.5 ms and not 17.

Front Sync would be the best option on a typical camera, that isn’t designed for photgrammetry.

However, 17 ms seems way too long. considering that normal sync-shutterspeed for a camera is max 1/250s or 4 ms, this would means that the camera would miss the flash-pulse entirely, which never happens.

You could try rear-sync, just to see if there is any shifts in the delay.

Hi everyone,

It seems like the offset is indeed related to the camera specifics.

We’ve created a setup with Reach that would minimize such issues: as I’ve mentioned already, Time Mark Pin is connected to the GNSS chip directly so that there’s no delay on the periphery connections. This allows the time mark to be recorded with very high accuracy.

However, the shutter trigger time is dependent on the exact signal shape on the camera’s hot shoe. So the delay depends on the specific camera and shutter shape. This means the delay will be different for each setup which makes it difficult for us to address it.

Currently, the easiest way to eliminate this delay is through working with GCPs. We have detailed guides on it here.

This is correct. I have even gone to the point of collecting the entire GPS track without events, shooting two checkpoints and synchronizing with the photos. This gets the relativity to centimeter level and the time marks very close, but the ground control points override and place the map correctly. If this is for PPK then you can put an offset in RTKLIB.

1 Like

I have a couple thoughs on this:

  1. Could it possible be rolling shutter related? Do you use rolling shutter option in Agisoft? Rolling shutter effects can destroy the type of accuracy you are trying to achieve. When I want cm accuracy I throw up a quad and map at 5 m/s.
  2. Did you ever lay out a bunch of ground targets - in a flat field - and set them as Independent check points to test if this offset exists in actuality? If it exists it would show up as a constant offset. Just wondering.

I’ve never dialed in using time marks (although I want to) and still use traditional ground control point targets (and check points) for crucial surveys if I want to be more confident in cm accuracy.

1 Like

Thanks for your inputs.

  1. I don´t think so. I manually set the shutter speed to 1/800, which is much less, than the 17 ms delay I get.
  2. That is exactly how I found this problem.

It is most definiatelly the cameras fault, I was just looking for a feature, how I can compensate for this. In the meantime I have a Python script, that modifies the RINEX data with the time delay and am getting much better results with the compensated time marks.

1 Like

I found exactly the same problem with my setup.
Look at this post.

I’m sure it’s a camera-related problem.
What I cannot understand are some user cases I read in emlid site where people seem to have perfect results with the same setup as mine.

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