Missing Camera Events

  1. ReachView Version: 2.8 for rover and 2.7 for base.

  2. Detailed problem description: Missing camera events during flight. RedEdge camera’s hotshoe pin triggers rover to record geolocation whenever the camera takes a photograph. We are expecting 724 camera events and we recorded 639 geo-locations.

  3. Step by step actions:

    1. Satellite systems used for rover and base station in the RTK settings are
      GPS+GLONASS+GALILEO+SBAS+QZSS at 1Hz.
    2. post processing yields log files that I then process using the following procedure:
      Reach Setup for PPK Processing on a UAV
  4. Picture of the setup and connection scheme.
    image

  5. No Issues with solution.

  6. RINEX log files for rover and base.
    Base: base_raw_201801261556_UBX.zip (4.7 MB)

    Rover: rover_raw_201801261601_UBX.zip (1.0 MB)

1 Like

Hi!

Had the same problem. Disable galieleo part if you can go without it. It will give you all the events. I don’t know if this had been patched since 2.8 version.

Okay, I’ll give it a try and post the results. Thank you very much!

We had a similar problem - I assumed it was a hardware issue with the connection between the hot shoe and the Emlid. Interesting to hear it might be a software issue with a possible fix!

For what it’s worth, if you need to be able to use the data from your previous flights with missing Emlid records, I was able to match our PixHawk’s record of camera trigger output to the Emlid’s record of trigger events recorded (assuming you have a similar record of attempted trigger events by your autopilot). The Emlid event is received about half a second after the PixHawk trigger so it was relatively trivial to write a Python script that matches the GPST of both together, and from there assign the correct Emlid events to the correct photograph. Missing a handful of camera locations hasn’t had a noticeable impact on the final accuracies of our point cloud.

Hello,

We are currently looking into the missing events with 1 Hz frequency as it is something that did not happen before. I have summed up the working regimes in this post.

@sanath Your proposition seems like a sane thing to do. Added to the issue tracker.

Hello Egor and Tom,

Yes I use the configuration # 1 given in Missing Events inVer 2.5 - #45 by egor.fedorov post. and can confirm does not work.

Misses many events (~ 11+ %) . Disabling GALILEO does not makes any difference.

The issue although sounds very trivial is not. A match is needed for less dependence on the GCPs.

Hope a stable fix is found.

Thanks for the response

Cheers
Sanath

I also have (a) missing time mark(s) / event trigger(s) in a simple test I did. Not sure if my issue is the same though. As far as I know I have all of my events (20) in the .obs, but I am missing one of them (the second one) in the _events.pos file. Interestingly I shot some sub-second shots just to see what happened, and I was able to get three events recorded in a second. I am guessing that relates to the 5Hz update rate.

I was using in standalone mode, just trying to make sure I get an accurate timestamp for each image. Processed UBX file with RTKCONV, then extracted events with RTKPOST. Planning to test again tomorrow for about an hour with a camera firing on a PPS-trigger with about 10ms jitter around the PPS. Sorry if this is tangential, but I thought it might be related to issues others are having.

If anyone wants to try my UBX file and see what you get for events in the .obs and _events.pos files, I’ve uploaded it here:

ftp://ftpext.usgs.gov/pub/wr/ca/santa.cruz/Ritchie/Reach/raw_201802100109.UBX

(apparently ftp hyperlinks aren’t clickable in this forum, but I tested cut/paste and it works)

RTKCONV 2.4.3, RTKPOST ver.2.4.3 Emlid b28, Reach version 2.10.0 at 5 Hz using GPS+GLONASS+SBAS+QZSS

incidentally, I would love to see some of the “hidden” event trigger values passed from the chip, especially the accuracy estimate (in nanoseconds) and whether the signal was a rising or falling edge, if it’s not too hard of a tweak. I’m curious how much the accuracy estimate varies, and if the rising/falling edge bit varies at all - seems like almost always it would only be the rising edge that gets recorded from a hot-shoe event trigger.

Ran a second test yesterday. Took 1830 pictures over 30 minutes. Reach reported T=1830 when processing the .UBX file, and .obs file has 1830 events, but the _events.pos file only has 1680 events. Post-processed as single receiver again.

Hi

@aritchie i had this issue (more events in the *.obs but not in event file) but i believe it is corrected as noted in an old but related post
" Could you please check that output if single is set to “on”?"

I still do not have "ALL events in either the *.obs or events file

mean while Team Emlid could you please point us to your prescribed settings for a working configuration ? How about a a single document that list all the correct settings and what not to have set like a quick check list.

Specifically I am looking for a fool proof “for dummies type” configuration where the RTK is expected to work and post processing will give expected results (best solution and a match on the number of events).

Please help … - - - … … - - - … … - - - … … - - - … … - - - … … - - - … … - - - …

Cheers

I struggle with the same issue. Not all camera events are logged. I support the idea that Team Emlid should publish a working configuration for UAV RTK/PPK missions using a base and rover setup. Including a working RTKPOST configuration.

Please help! Best regards!

20 events. Not all is good due to bad solution (not fix) maybe

1 Like

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