Extra time marks

@ldegraaf I’ve done more digging into the # events > # images behavior.

It appears the camera, the hotshoe electricals, or the M2 is “double tapping” the event/time marks some small percentage of the time.

See image below:

This is a string of three camera trigger events, all of which have been “double tapped”.

See closeup below:

Essentially, when this happens a second event is recorded exactly 0.01 seconds after the (presumably, I hope its causal) real event. So all of my “double taps” are spaced about 15cm from their corresponding real events.

For me in this particual mission, this “double tapping” happened 9 out of 916 times (I have 925 events for 916 images, and have manually verified the number of incidents). That’s only 0.98% of the time, but for a “dumb” event-to-image matching process (e.g. event #1 goes to image #1, etc.) a single offset event can be devastating to the dataset, depending on how dependent on geolocation your processing is.

What bugs me additionally is that a 0.01 second delay, from my understanding, shouldn’t even be possible - it is described that the uBlox F9T/P only records one event per “epoch”, or update for lack of a better term. My M2 is set for 5Hz, which should mean a minimum interval of 200ms, but I’m getting secondary events at a 10ms interval, which is interesting to say the least.

EDIT:
Come to think of it, one possibility that came to mind is the timing of the hotshoe’s electrical pulse may be right on the “edge” of an epoch transition, causing two events to be recorded for the same pulse. My “double taps” seem to happen in groups, which may illustrate some sort of “beat frequency” between capture intervals and epoch timing.
That said, I’m not sure that uBlox documentation (Page 53-54) supports this explanation.

Specifically, I have trouble interpreting this statement:

“Only the last rising and falling edge detected between two epochs is reported since the
output rate of the UBX-TIM-TM2 message corresponds to the measurement rate configured
with CFG-RATE-MEAS”

And accompanying illustration:

I believe it is simply saying that only the last pair of rising and falling edges - which comprise an “event” - is reported. Previous “events” are ignored within the epoch. If my interpretation is correct, there is the possibility that the falling/rising edge is split at the epoch line, forming the end of the previous epoch’s event and the beginning of the next epoch’s event. Their diagram shows that both polarities (falling-rising or rising-falling) are accepted.

1 Like

Hi Evan,

This is interesting observation and report, we’ll look into it shortly! Any chance we could get your raw data with this issue?

Very interesting @evan.williams1010. It is very bad weather here at the moment so I have to do some testing later. But the tests that I have done, the results are a bit strange. One event file shows me 1148 events while there are only 532 pictures taken and if I open that file in RTKPLOT I can not really see any extra events. Maybe they are right on top of each other or something i cant really explain it. In another file I have 247 events for 219 photos. Again I cannot really see what you suggest.

I have the Mid Exposure pulse (same as a hot shoe connector on any camera) of my PhaseOne IXM100 camera connected with the time mark pin on the Emlid M2. The M2 should only register the photo moment but somehow I get a lot of noise within my log file. Im now planning to feed my camera NMEA messages so that the photo`s will have a GPS time and then geotag my images with a GPX track file generated after post processing the raw data.

I could also directly georeference my photos using the RTK feature with LORA radio`s but I cannot assure if I constantly maintain a good fix

Is there a way we can somehow test the time mark pin?

raw_202002140947_events.pos (159.2 KB) raw_202002171237_events.pos (35.5 KB)

@dmitriy.ershov, I have reorganized my shared folder to make things a bit easier to download.

https://drive.google.com/drive/folders/1_SJB5S1uVEh72N-j9Hkga1aHgt3Yxmr3?usp=sharing

The subfolder “2-12-2020_Test” contains the offending events discussed above. It has a base and rover UBX, plus an OPUS solution for the base location.

The subfolder “2-18-2020_Test” contains a newer, much shorter survey (training flight) with 1/3 the number of images, and no sign of “double taps”. This may be explained by simple statistics of a smaller survey. It has a base and rover UBX, plus an OPUS solution for the base location.

Note that the platform in question is capable of flying for 1 hour 30 minutes, taking images at ~1Hz, so a full size mission would probably demonstrate the brunt of the problem.

Hey there,

Thanks a lot for sharing the data!

We’re looking into them now. I’ll write back once there are any updates.

Hi @evan.williams1010, @ldegraaf,

May I ask you to share hardware setup photos of your Reach M2 devices mounted on UAV?

Could you please clarify if you used the Reach M+ device in the same setup? Do I understand correctly that it created extra time marks too?

I am still waiting on a picture of the Reach M2 mounting. I will edit with image when available.

I can say that it is mounted with 3M tape to the inside of an EPO foam fuselage, and is positioned sideways, with antenna port facing forward toward the nose.

It is immediately adjacent to the Sony A7R III, and in close proximity to a 5.1V BEC (DC Regulator). It is relatively close to current paths for motors, but not in direct contact. Separation from these power wires is at least 19mm (0.75"). The power wires carry up to 45A, with a normal in-flight current of 8A.

It is powered by the 5.1V BEC, and connected only to the antenna and the EMLID hotshoe.



I have used the M+ in a similar setup, however I had a different hotshoe, as stock of the EMLID hotshoe was scarce at the time. Placement of the M+ was different, lying flat and upright, and placed in the avionics bay with a Pixhawk 2.1 and several radios.

With this setup of the M+, I did not have the same issue with “double tapped” time marks, though it did occasionally “miss” events - the opposite problem.

Hi Evan,

Thank you for the detailed description! It’d be nice if you’d be able to share the photos too.

Hello Tatiana, sorry for my late response. I was out of office last few days. The setup you see on the photo’s in the beginning of the topic is the same as for the uav. The black plate is actually the DJI d-rtk mounting plate :sweat_smile: and is mounted on top of our DJI M600 drone.

However The receiver on these photos is the new Emlid M2.

Hi Lammert,

Thanks for clarifying it!

We’re now working on the solution to this issue. I’ll keep you posted.

@tatiana.andreeva My apologies for the long wait, but I finally have an image representing the M2’s position.

The black plastic platform at bottom center is the mount for our A7R III. When installed, the A7R III fully obscures the M2 as shown here.
The wiring bundle at the base is normally tucked away to the left - this image was taken during servicing.

Thank you.

Hi Evan,

Thank you for the photo! It’s of great help to us.

We’re still in work on the fix. I’ll keep you posted in any case: whether we need more data or have any news.

Hey everyone,

We’ve released the v2.22.5 firmware version for Reach M2 that should solve the issue with the extra time-marks generation.

It’d be great if you could test it and tell us whether the release solves the issue for you. Please note that fix only works for logs recorded in RINEX currently.

Let me add that we’ve updated the RTKLIB version in our docs. Now it’s possible to convert all the UBX logs using a new version and get the files with the correct time marks quantity.

1 Like

The new firmware seems to have fixed the problem. I did a small survey with ~100 photos and the number of photos matched the number of time marks.

2 Likes

@ldegraaf,Regarding the camera connection, is it necessary to connect the ground of camera with emlid ground.

For the phaseone IXM cameras