M2 shutter count wrong

I did a few missions with my new Reach M2 and when I do a mapping mission with my Arducopter I get different countings of the photo shots. In the last case on the SD card were actually 200 photos. The image referencing tool from Ardupilot (Mission Planner) tells me that there must be 200 photos. When I do PPK with Emlid Studio, it says “Folder must contain 197 JPEG files”.
I connected a hotshoe adapter to my A6000 as camera feedback and I soldered a 10K resistor on top of the hotshoe pin so I can feed the signal into the M2 AND the Pixhawk as feedback in parallel.

What is the reason for wrong counting?
This is the RINEX file of the M2: RINEX file

Today I did another test flight. Now the camera took 182 photos but Emlid Studio is looking for 185 photos. Is there a solution for this?

Hi @k.harbort,

Can you please share the log from your base for your first survey? I’ll take a look at it.

Also, please share logs from both base and rover for today’s flight. They can give more info to understand the reason for the issue.

You can share the files here or via support@emlid.com to keep them private.

fun fact: when I use the raw UBX file, convert it with RTKLib and use it then in Emlid studio for Geotagging, it seems that Emlid Studio wants more photos. How’s that possible?!?

Let’s investigate it.

Please share the UBX file from your rover as well. I’ll check it, compare it with RINEX, and share my thoughts on the issue with you.

If you compare your shutter times in the exif to your triggered events you will be able to eliminate the photos that are not required. This is actually a very common situation. I was able to find another post in the forum that discussed the exact issue.

1 Like

Thank you for the info. Can you share link?

Hi there,

Just wanted to say that I received files from @k.harbort. Once I analyze them, I’ll post my thoughts here.

One of these might have it there are more too…

1 Like

thank you Aaron,
but the solution should be a correct counting. But I will try your suggestion, so thanks for that.
The strange thing is, when I do mapping missions with the A6000 and a (different) hot shoe adapter, the feedback which goes to ArduPilot is always correct. I do long missions with partly >5000 pictures per mission and the counting was always spot on! And it was also correct with the Reach hot shoe adapter (as stated in my first post!). So why is it correct in Pixhawk but not in M2?

Hi @k.harbort,

Sorry that my reply took that long.

I’ve checked the logs from both surveys. The first log contains 197 time marks and the second one — 185 time marks. Thus, Emlid Studio asks for the same number of photos. I also converted the UBX file to RINEX and checked the number of time marks. It was the same as in RINEX for both datasets.

I assume that the difference between the number of time marks in the log and the number of photos is related to the setup. You have a split cable from the hot shoe to the Reach M2. It may lead to losing or doubling some of the signals and, as a result, time marks.

To check if the time mark recording works ok from Reach’s side, let’s conduct one test. Connect the receiver to the camera’s hot shoe and trigger the camera manually. You should see the last time mark recording in the Camera control tab in the app.

Hi @julia.shestakova ,
thank you for the info. I try it at the moment and it works fine (it shows 2023/01/20 16:19:40.4 GPST for example). I did a mission with my mapping plane and M2 today and my camera took 920 photos. So I opened Emlid Studio and used the RINEX file from M2 and it asked for 920 phhotos! So that worked perfect! On the other hand Mission planner was now asking for 923 photos…I don’t get it.
But just for fun I used the ubx file from the Reach M2 again as Rover and then it asks for 924 photos. How can it be different between Raw file and RINEX file from the rover at the same time?

edit: all the raw files mentioned before, I converted them with RTKLib directly. I didn’t know, that Emlid studio could convert them by itself. Now when I let Emlid Studio convert the ubx file the photo numbers match the same as the RINEX file. So that was my fault.

I did another mission today with my mapping plane with 2022 photos and Reach were right again as Emlid Studio asked for 2022 photos. Now Mission planner still wants 2026 photos so I’m not sure, where that comes from as it worked perfect when not using a Reach M2. I will try to have a look at the Signal levels next week.

@julia.shestakova: it would be great if we could use kind of a y-cable to send feedback to FC as well because the I see on my GCS if the drone is taking photos or not! That’s why I want to have a feedback.

I did some test with the scope and I changed the 1K resistor to a 10K resistor on my soldered cable as it seems to be better. But I am not a specialist on this so I am not sure. What do you think? What resistor is used ont the original HSA trigger pin?
I did another mission. Camera took 2662 photos, Mission Planner asks for 2662, Emlid asks for 2661 photos…why?
The mission was seperated in different fields, so I could easily locate in which actual field the missing photo is.
@julia.shestakova if you would like to analyse, I could share you the whole photo dataset plus the RINEX and raw files. Let me know.

Raw voltage before the resistor

behind the 1K resistor

behind the 10K resistor

Hi @k.harbort,

Hmm, I’d say that your new results make me more convinced that the issue is related to the setup. In particular, to the cable from the hot shoe. As far as I know, it’s not a common practice to split it.

In some surveys, the software asks for more photos than you have. In some, less. Sometimes you notice a mismatch in Emlid Studio. In other cases, in Mission Planner. And I see that the cable may cause this inconsistency.

So I’d connect the camera hot shoe to either Reach M2 or Pixhawk with direct cable and do one more test. It’ll help us understand if the split cable indeed causes the issue.

I agree that it might be the problem with my setup. But why is there a mismatch by only 1-3 of >2000 photos? Could you find out what resistor you use on your adapter?
I will do another test mission with the original connection only to M2 and let you know. But still, it would be good to have visual feedback on the GCS.

@k.harbort,

I can hardly share the info about the exact components. All that I can say is that Reach M2 registers a time mark when it gets a 3.3 V pulse from the camera. We tested it with the cable which we supply. And it worked fine. But once you change something in the connection, it’s hard to guarantee that it’ll keep working properly.

I will do a few test missions when I have time and let you know the results. I removed my own resistor because I think it might be unneccesary so I will do a Mission with my cable and one mission without (only with the original cable). It will be interesting what the results are.
But at my last mission, if I would have flown a shorter mission with about 2400 pictures taken, it would have worked perfect since the missing photo must be somewhere around 2400 and 2600 out of 2662 photos. I can not really track down the error. Only one single picture missing…

Yes, the hardest part here is that the issue is not regular. So it’s hard to catch when it reveals itself. But I hope that changing the setup will help. I’ll be waiting for the results of your new tests.

hi Julia,
When I fly only with HSA to M2, it seems to work. BUT I still would like to have a feedback for my fc because I do not see if the camera is taking photos. Is there a way to connect a cable from M2 to FC as a feedback for shutter? It’s very annoying not to get feedback. I just flew 2.5 hrs just to see that the SD card got full during flight. With feedback to FC, I would have seen it.

Hi @k.harbort,

Thanks for the update. Good to know that it works fine with a direct cable from the Reach M2 to the camera’s hot shoe.

That’s the only workflow we can suggest at the moment. But your point makes sense to me. I can’t promise anything now, but I’ve shared your feedback with the team so that we can think about it.