testing sync among more cameras

Microfunguy

4037

Re: testing sync among more cameras

« Reply #100 on: 20 / November / 2013, 08:52:58 »

Advertisements

Quote from: ahull on 20 / November / 2013, 08:25:28

FWIW you could also drive your LEDS with a CD4040BE using a CD4011 (page 7) as a crystal oscillator

As a matter of interest what method would you use to divide the frequency by a four-digit number (that is not a multiple of 2 or 10) ?

A microcontroller ?

Logged

Karmaschinken

198

Re: testing sync among more cameras

« Reply #101 on: 20 / November / 2013, 09:41:14 »

Quote from: waterwingz on 20 / November / 2013, 08:48:20

I can test build a patch file and send it to you. Are you still using the SX200is ?

also @ microfunguy: Yes, it is still the SX200IS. Would you mind to send me the patch too? I'd love to see what has been done! Thanksa a lot!

Logged

ahull

634

Re: testing sync among more cameras

« Reply #102 on: 20 / November / 2013, 09:44:23 »

Quote from: Microfunguy on 20 / November / 2013, 08:52:58

Quote from: ahull on 20 / November / 2013, 08:25:28
FWIW you could also drive your LEDS with a CD4040BE using a CD4011 (page 7) as a crystal oscillator

As a matter of interest what method would you use to divide the frequency by a four-digit number (that is not a multiple of 2 or 10) ?

A microcontroller ?

I'm not sure quite why you need to do that, in this case, but assuming you did, I would go for something like this, albeit that you would need something to program it with (that pesky microcontroller perhaps, or a raspi). You would still avoid the possibility of coding latency causing jitter, and interfering with the precision of your frequency.

« Last Edit: 20 / November / 2013, 10:08:14 by ahull »

Logged

waterwingz

12138

Re: testing sync among more cameras

« Reply #103 on: 24 / November / 2013, 19:36:00 »

Updated patch file of vnd's code attached here in case I get distracted again. Seems to run on my cameras but I need to finish sync testing using my arduino setup. Note that the register addresses are my best guess from studying the various posts on this thread.

Any bugs notes / fixes / improvements / updates would be appreciated.

Code: [Select]

#define GPIO_VSYNC_UPDATE  0xC0F06000
#define GPIO_VSYNC_MAX     0xC0F06014
#define GPIO_VSYNC_CURRENT 0xC0F070C8   // 0xC0F07008 ??

void _wait_until_remote_button_is_released(void)
{
    int tick;
    if (    ( conf.remote_enable )              // menu : USB remote enabled - bracket everything in this function
        &&  ( conf.synch_enable  )              // menu : Sync enabled - tells us to wait for USB to disconnect
        &&  ( usb_sync_wait      ) )            // only sync when USB remote is active - don't trap normal shooting
    {
        usb_remote_status_led(1);               // indicate to user we are waiting for remote button to release - this happens every time the camera takes a picture
        tick = get_tick_count();                // timestamp so we don't hang here forever if something goes wrong

    #ifdef USB_REMOTE_PRECISION_SYNC
        int std_period = _EngDrvRead(GPIO_VSYNC_MAX);
        int sync_time = std_period * 3;         // schedule the end of extended period at t = t(synch pulse) + sync_time
        do { }  while( get_usb_bit() &&  ((int)get_tick_count()-tick < DELAY_TIMEOUT));
        int cur_cnt = *(volatile int*)(GPIO_VSYNC_CURRENT) & 0xffff; // get the counter state at the time of sync
        int sync_period = sync_time - (std_period - cur_cnt);
        if (std_period - cur_cnt < 10)
        {
            // too close to overflow, wait for the next period
            sync_period -= std_period;
            while ((*(volatile int*)(GPIO_VSYNC_CURRENT) & 0xffff) >= cur_cnt) {};
        }
        *(volatile int*)(GPIO_VSYNC_MAX) = sync_period; // write the length of the extended period to the register
        *(volatile int*)(GPIO_VSYNC_UPDATE) = 1;
        while (*(volatile int*)(GPIO_VSYNC_UPDATE)) {}; // wait until the new value is applied
        //now we are at the beginning of extended period
        *(volatile int*)(GPIO_VSYNC_MAX) = std_period; // back to standard timing on next period
        *(volatile int*)(GPIO_VSYNC_UPDATE) = 1;
        msleep(40); 
    #else
        // delay until USB state goes to "Off" or timeout
        do { }  while( get_usb_bit() &&  ((int)get_tick_count()-tick < DELAY_TIMEOUT));
        // add a sync calibration delay if requested
        if ( conf.synch_delay_enable && conf.synch_delay_value>0 ) kbd_synch_delay( conf.synch_delay_value );
    #endif
        sync_counter++ ;
        usb_sync_wait = 0 ;
        usb_remote_status_led(0);       // alert the user that we are all done
    }

}

Update : the two values shown for GPIO_VSYNC_CURRENT are from this thread. The value commented out was originally posted by vnd. The value used in the patch was posted by microfunguy. Using vnd's value causes my A1200 to hang after a few shots - presumably in one of the wait loops as it looks at a value that does not change?

precision_sync_v5.patch (8.18 kB - downloaded 45 times.)

« Last Edit: 25 / November / 2013, 08:50:26 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3450

Re: testing sync among more cameras

« Reply #104 on: 29 / November / 2013, 22:16:28 »

Quote from: waterwingz on 24 / November / 2013, 19:36:00

Updated patch file of vnd's code attached here in case I get distracted again. Seems to run on my cameras but I need to finish sync testing using my arduino setup. Note that the register addresses are my best guess from studying the various posts on this thread.

Any bugs notes / fixes / improvements / updates would be appreciated.

Code: [Select]
#define GPIO_VSYNC_UPDATE 0xC0F06000 #define GPIO_VSYNC_MAX 0xC0F06014 #define GPIO_VSYNC_CURRENT 0xC0F070C8 // 0xC0F07008 ?? void _wait_until_remote_button_is_released(void) { int tick; if ( ( conf.remote_enable ) // menu : USB remote enabled - bracket everything in this function && ( conf.synch_enable ) // menu : Sync enabled - tells us to wait for USB to disconnect && ( usb_sync_wait ) ) // only sync when USB remote is active - don't trap normal shooting { usb_remote_status_led(1); // indicate to user we are waiting for remote button to release - this happens every time the camera takes a picture tick = get_tick_count(); // timestamp so we don't hang here forever if something goes wrong #ifdef USB_REMOTE_PRECISION_SYNC int std_period = _EngDrvRead(GPIO_VSYNC_MAX); int sync_time = std_period * 3; // schedule the end of extended period at t = t(synch pulse) + sync_time do { } while( get_usb_bit() && ((int)get_tick_count()-tick < DELAY_TIMEOUT)); int cur_cnt = *(volatile int*)(GPIO_VSYNC_CURRENT) & 0xffff; // get the counter state at the time of sync int sync_period = sync_time - (std_period - cur_cnt); if (std_period - cur_cnt < 10) { // too close to overflow, wait for the next period sync_period -= std_period; while ((*(volatile int*)(GPIO_VSYNC_CURRENT) & 0xffff) >= cur_cnt) {}; } *(volatile int*)(GPIO_VSYNC_MAX) = sync_period; // write the length of the extended period to the register *(volatile int*)(GPIO_VSYNC_UPDATE) = 1; while (*(volatile int*)(GPIO_VSYNC_UPDATE)) {}; // wait until the new value is applied //now we are at the beginning of extended period *(volatile int*)(GPIO_VSYNC_MAX) = std_period; // back to standard timing on next period *(volatile int*)(GPIO_VSYNC_UPDATE) = 1; msleep(40); #else // delay until USB state goes to "Off" or timeout do { } while( get_usb_bit() && ((int)get_tick_count()-tick < DELAY_TIMEOUT)); // add a sync calibration delay if requested if ( conf.synch_delay_enable && conf.synch_delay_value>0 ) kbd_synch_delay( conf.synch_delay_value ); #endif sync_counter++ ; usb_sync_wait = 0 ; usb_remote_status_led(0); // alert the user that we are all done } }
Update : the two values shown for GPIO_VSYNC_CURRENT are from this thread. The value commented out was originally posted by vnd. The value used in the patch was posted by microfunguy. Using vnd's value causes my A1200 to hang after a few shots - presumably in one of the wait loops as it looks at a value that does not change?

Stub and wrapper for EngDrvRead added in revision 3254 (trunk).

Phil.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

waterwingz

12138

Re: testing sync among more cameras - real data

« Reply #105 on: 01 / December / 2013, 12:53:00 »

First set of precision sync test results using uController LED based tester and A1200

Chart shows binned data for three test conditions :
1) No Sync (blue)
2) Normal CHDK sync method enabled (red)
3) vnd's precision sync method enabled. (green)

Timing is in milliseconds from the release of the 5V USB remote signal to image capture - remote=enabled, switch type=one press , control mode = normal. Shutter speed 1/2000, LED count rate = 500 mSec, LED encoding = gray code. Sample count = 25 per sync setting.

Preliminary Conclusions

without any sync enabled, the time between USB remote release and image capture varies randomly by about 40 mSec
with standard CHDK sync enabled, the time between USB remote release and image capture varies by about 20 mSec, with the majority of the captures being within 8 mSec
with precision sync, the time between USB remote release and image capture varies by less that 4 mSec for almost all capture. However, there are occasional captures that are 30 mSec sooner

I think it might be possible to correct the third conclusion above by tweaking the precision sync code a bit. It looks like some shots are happening exactly one timing period early.

"In God we trust; everyone else must bring data".

Logged

Ported : A1200 SD940 G10 Powershot N G16

waterwingz

12138

Re: testing sync among more cameras

« Reply #106 on: 01 / January / 2014, 23:22:22 »

I'm going to post a patch for the autobuild to add precision sync. For now only the A1200 will be enabled. This way, if I get hit by the proverbial bus, at least working code will be in the svn 1.3.0 trunk. And anyone trying to build a "bullet time" multi-camera rig will have a head start in achieving the sync they need.

On the A1200, the time from USB release to shutter activation seems to vary less that 1 mSec for 98 out of 100 shots. The rest are always 30 mSec early so there is still something we don't understand in the timing. Still, it's a much better result than the old sync mechanism almost all of the time so worth adding.

Meanwhile, I'll continue testing and experimenting with the A1200 and my other cameras.

« Last Edit: 01 / January / 2014, 23:29:02 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

Karmaschinken

198

Re: testing sync among more cameras

« Reply #107 on: 02 / January / 2014, 04:31:53 »

Well, I really AM building a rig and I can't say how much I appreciate your and the other great gurus work here! This is really elephantous! Thank you very much!

Logged

Karmaschinken

198

Re: testing sync among more cameras

« Reply #108 on: 04 / January / 2014, 05:47:17 »

I have another question. I am doing bullet-time stuff with 50 cameras and made some long time exposure shots with them using a USB-remote switch signal from an Arduino. I was doing some light painting stuff with it.

Now what I think is that even when the moment the exposure was triggered is nearly the same, the duration of the exposure varied a little. I am not really sure about that issue, but I hat several shots where the "start" of the light painting is the same among the pictures, but not the end. This seems to be a hint that the "real" exposure time varied. Is that possible? Would there be a way to not only trigger the start of such an exposure but also the end, with USB remote?

Thanks!

Logged

waterwingz

12138

Re: testing sync among more cameras

« Reply #109 on: 04 / January / 2014, 09:54:38 »

Quote from: Karmaschinken on 04 / January / 2014, 05:47:17

Now what I think is that even when the moment the exposure was triggered is nearly the same, the duration of the exposure varied a little. I am not really sure about that issue, but I hat several shots where the "start" of the light painting is the same among the pictures, but not the end. This seems to be a hint that the "real" exposure time varied. Is that possible?

It would be helpful to know how long "a little" is. 10 mSec? 1/2 sec? 2 seconds ?

Also, how were you controlling the exposure time? CHDK Tv override menu? Canon M mode ?

Quote

Would there be a way to not only trigger the start of such an exposure but also the end, with USB remote?

I can think of several ways, some easier that others. Especially as you have the ability to build from source.

The simplest way would be to control the shooting from a small script. Set a long exposure time override, monitor the USB remote line in Lua, start the shot when the line goes high, then force the mechanical shutter closed when it goes back to 0V. You'd need to set the exposure for the longest duration you anticipate needing, and you'd get sensor noise building for the entire exposure rather than just the shutter's open time. But it would work.

Code from here: http://chdk.wikia.com/wiki/Meteor_Intervalometer_with_Dark_Frame_Management shows you how to manage the shutter :

Code: [Select]

-- close mechanical shutter
  function closeshutter()
    if (call_event_proc(closeproc) == -1) then
      print("closeshutter failed")
    end
  end
 
  -- open mechanical shutter
  function openshutter()
    if (call_event_proc(openproc) == -1) then
      print("openshutter failed")
    end
  end

You could also play with multiple exposures in the same image this way! Hmmm .. maybe I'll whip up a little script and try that for myself

I would expect response time to be on the order of 100 to 200 mSec - is that adequate for what you are doing?

Logged

Ported : A1200 SD940 G10 Powershot N G16