Canon SX260HS accurate geo-tagging

gio_kap

12

Re: Canon SX260HS accurate geo-tagging

« Reply #20 on: 16 / January / 2017, 03:31:56 »

Advertisements

Hi Lanzo; I'm not using the Pixhawk camera feedback feature so I have no direct experience with it (I'm trying to use an external GPS independent of the navigation system for image time-stamping).
I'm sure you've already googled for clues (such as: http://www.tuffwing.com/support/Install_a_canon_precision_geotag_cable.html; http://ardupilot.org/copter/docs/common-camera-shutter-with-servo.html), and your set up seems correct: it appears to be more a Pixhawk hardware/firmware problem.
Sorry for not being able to help.

Logged

waterwingz

12140

Canon SX260HS accurate geo-tagging

« Reply #21 on: 16 / January / 2017, 22:58:28 »

Quote from: gio_kap on 14 / January / 2017, 11:00:30

If weather permits, I'll be soon doing some mapping tests to start checking how this system works and ortho-mosaics accuracy, so I'll be glad and honored to beta test the updated script.

Update : the beta script (after one small upset) allows user defined sync LED "on" time and logs sync LED on & off times to the millisecond. And according to the log for gio_kaps sx260hs , the script is achieving requested 500 mSec LED "on" times within 10 mSec.

However, gio_kap provided a video showing actual erratic operation of the focus assist lamp in his camera, with "on" duration varying from very short to several seconds. Even though the log show each blink to be exactly 500 mSec!

We eliminated obvious stuff with Canon camera settings and disable RAW. Still getting erratic LED performance.

Testing with identical settings on my G10 give rock solid operation so I don't think this is a script issue.

Leaving us with the possibility that the camera_set_led() code in lib.c for the sx260 is calling a Canon firmware routine that does not immediately activate the lamp driver hardware. It looks more like its creating an event request of some type that gets processed later - and not necessarily quickly. if that's true, then using that LED to sync shot time to GPS position via a flight controller is not going to work for this camera model.

« Last Edit: 17 / January / 2017, 00:16:59 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

gio_kap

12

Re: Canon SX260HS accurate geo-tagging

« Reply #22 on: 17 / January / 2017, 03:22:53 »

Hi All.

Just for information purposes: I posted this topic (with a link to this forum) on the DIY Drones forum, as other UAV users might be interested in this, and might also share their experiences.

Logged

gio_kap

12

Re: Canon SX260HS accurate geo-tagging

« Reply #23 on: 17 / January / 2017, 03:23:27 »

And this is the link:

http://diydrones.com/forum/topics/canon-sx260hs-accurate-geo-tagging

Logged

srsa_4c

4451

Re: Canon SX260HS accurate geo-tagging

« Reply #24 on: 17 / January / 2017, 12:58:50 »

Quote from: waterwingz on 16 / January / 2017, 22:58:28

Leaving us with the possibility that the camera_set_led() code in lib.c for the sx260 is calling a Canon firmware routine that does not immediately activate the lamp driver hardware. It looks more like its creating an event request of some type that gets processed later - and not necessarily quickly.

Lots of ports use the LEDDrive firmware function and it doesn't seem to have latency issues (it's good enough for the motion detection test script).
For some reason however, the sx260 port uses a lower level fw function to drive the LEDs, and that affects the AF LED.
To see if that's the cause of the problem, you could make a test build - just remove* the LEDDrive stub from stubs_entry_2.S.

edit:
*Assuming you can rebuild stubs_entry.S

« Last Edit: 17 / January / 2017, 13:03:13 by srsa_4c »

Logged

waterwingz

12140

Re: Canon SX260HS accurate geo-tagging

« Reply #25 on: 17 / January / 2017, 17:50:59 »

Quote from: srsa_4c on 17 / January / 2017, 12:58:50

Quote from: waterwingz on 16 / January / 2017, 22:58:28
Leaving us with the possibility that the camera_set_led() code in lib.c for the sx260 is calling a Canon firmware routine that does not immediately activate the lamp driver hardware. It looks more like its creating an event request of some type that gets processed later - and not necessarily quickly.
Lots of ports use the LEDDrive firmware function and it doesn't seem to have latency issues (it's good enough for the motion detection test script).
For some reason however, the sx260 port uses a lower level fw function to drive the LEDs, and that affects the AF LED.
To see if that's the cause of the problem, you could make a test build - just remove* the LEDDrive stub from stubs_entry_2.S.
edit:
*Assuming you can rebuild stubs_entry.S

Thanks - I'll give that a shot. I looked at lib.c but did not think to see if the address had been patched in stubs_entry_2.S.

I assume I can just un-comment the necessary line in stubs_entry.S (rather than rebuild it completely ..) ?

Code: [Select]

// Stubs below should be checked. Stub not matched 100%, or difference found to current 'stubs_entry_2.S'
//    Name                                     Address      Rule  %  Comp to stubs_entry_2.S
//NHSTUB(DeleteFile_Fut                       ,0xff02163c) //  1 90%        == 0xff02163c
NHSTUB(LEDDrive                               ,0xff1b989c) //120        *** != 0xff04d06c
// ERROR: MakeDirectory_Fut is not found.                  //--- ---    *** != 0xff02214c

Logged

Ported : A1200 SD940 G10 Powershot N G16

srsa_4c

4451

Re: Canon SX260HS accurate geo-tagging

« Reply #26 on: 17 / January / 2017, 18:18:59 »

Quote from: waterwingz on 17 / January / 2017, 17:50:59

I assume I can just un-comment the necessary line in stubs_entry.S (rather than rebuild it completely ..) ?

If you don't (or can't) rebuild stubs_entry.S, just use the address found there to correct the stub in stubs_entry_2.S. Look at the first line of stubs_entry.S for the reason.

Logged

waterwingz

12140

Re: Canon SX260HS accurate geo-tagging

« Reply #27 on: 17 / January / 2017, 20:45:42 »

Quote from: srsa_4c on 17 / January / 2017, 18:18:59

Quote from: waterwingz on 17 / January / 2017, 17:50:59
I assume I can just un-comment the necessary line in stubs_entry.S (rather than rebuild it completely ..) ?
If you don't (or can't) rebuild stubs_entry.S, just use the address found there to correct the stub in stubs_entry_2.S. Look at the first line of stubs_entry.S for the reason.

For the benefit of anyone else reading this later on, srsa_4c is pointing out that stubs_entry.S is a "generated" file. It is created when there is a valid PRIMARY.BIN firmware dump file in the port's sub/firmware directory. So my edit to that file would not be permanent, although it will work as long as the corresponding line in stubs_entry_2.S is commented out and there is no PRIMARY.BIN file in the same directory.

But FWIW, I also downloaded the necessary PRIMARY.BIN file as suggested and checked that the revised stubs_entry.S addresses were the same.

I've sent the new build to gio_kap for testing.

« Last Edit: 17 / January / 2017, 20:48:03 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

gio_kap

12

Re: Canon SX260HS accurate geo-tagging

« Reply #28 on: 19 / January / 2017, 12:34:45 »

Hi; just a quick update on this.
I've tested several iterations of the CHDK build as patiently and generously provided by WaterWingz, however the LED response is not affected by the software, keeping varying the LED pulse width.
In the meantime I tested an Arduino based photo detector (https://www.amazon.it/gp/product/B01M7RRA2M/ref=oh_aui_detailpage_o06_s00?ie=UTF8&psc=1) and it's actually able to nicely detect the rising front of the LED ON pulses, no matter the pulse width; I also checked that the LED turns ON upon shutter activation, so image time-stamping should be accurate.
Thanks to this forum, and great appreciation to waterwingz time and efforts put in.
Regards

Logged

srsa_4c

4451

Re: Canon SX260HS accurate geo-tagging

« Reply #29 on: 19 / January / 2017, 19:31:56 »

Quote from: waterwingz on 16 / January / 2017, 22:58:28

However, gio_kap provided a video showing actual erratic operation of the focus assist lamp in his camera, with "on" duration varying from very short to several seconds. Even though the log show each blink to be exactly 500 mSec!

We eliminated obvious stuff with Canon camera settings and disable RAW. Still getting erratic LED performance.

I realize that OP has found a usable workaround. I'd still like to ask whether there were any experiments using different values for the second argument of set_led. When LED control is implemented with the LEDDrive fw function, the second parameter can be used to set various blinking patterns (when its value is other than 0 or 1). Perhaps it's working differently on this camera.

Logged