B10 works correctly. Still have my reserves on the ISO and F-Stop choice, but that is another issue.
I have soldered a 3000mAh RC battery cell to the camera battery so now I can shoot about 200k picture without worrying about the battery getting depleted.
Log is attached.
I had 4 short flights as I was mainly testing the vibration dampers and KAP.log is the main thing that's telling us the script performance anyway. In the first 3 flights I had speeds set between 20-25m/s, camera was set to take pictures every 17 meters
Last Flight at 25m/s (no wind whatsoever) the camera was set to take pictures every 17 meters. That means one picture every 0.68s.
Notice, that the pictures in the last session were taken mostly at .8s intervals. While the .8s interval still offers a 78% overlap that we can work with, it is not perfect.
[glow=red,2,300]Speculation[/glow]:
The CAM_SERVO_ON=3500 is held for CAM_DURATION=0.1s. now the Pixhawk log is not accurate enough to determine if this is the real cause, but it surely provides the explanation for the ~0.1s loss.
Now, reverse engineering the problem:
CAM_DURATION=0.1s(100ms)- this means the the counting for the next shot is not starting from the moment CAM_DURATION began but from the moment CAM_DURATION ended. So 0.68+0.1=0.78 (~0.😎.
If we can work the CAM_DURATION down to 0.02s which is the exact width of one pulse+pause the next speed development would have to be when mapping planes fly at 250m/s . (Probably when we start mapping other planets @80m AGL.)
[glow=red,2,300]Final note[/glow]
All in all I say the timing delays have reached an acceptable level that can be worked with, and if needed it can be compensated for during planning.
[glow=red,2,300]Waterwingz, that was hell of a job! CONGRATS! [/glow]
