testing sync among more cameras - page 5 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 13   Go Down

testing sync among more cameras

  • 121 Replies
  • 67708 Views
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: testing sync among more cameras
« Reply #40 on: 25 / October / 2012, 05:59:31 »
Advertisements
If that is for the S95, we already have those synch tests.
It would be surprising if that can be improved, the 4msec outliers are presumably due to yielding to another task.

The real test is on a camera that has poor synch.
Logged
*

Offline vnd

  • *
  • 36
Re: testing sync among more cameras
« Reply #41 on: 25 / October / 2012, 08:39:45 »
Quote from: Microfunguy on 25 / October / 2012, 05:59:31
If that is for the S95, we already have those synch tests.

Yes, but now the wait_until_remote_button_is_released() function is called 7-10 context switches later and with high priority.

Quote from: Microfunguy on 25 / October / 2012, 05:59:31
the 4msec outliers are presumably due to yielding to another task.
I will have to match the logs with the out-of-sync shots, but  the task  switching order that I logged so far was rather stable.

Logged
*

Offline vnd

  • *
  • 36
Re: testing sync among more cameras
« Reply #42 on: 29 / October / 2012, 05:48:23 »
An update of my findings:

There is a task SsgPeriodTask which runs all the time, every 20ms or so. It is probably related to frame rate of live view. Then, when the shooting starts, there are basically two possible sequences of task switching. The used sequence depends on the phase of SsgPeriodTask.

The most common sequence:
Code: [Select]
0000 ISComTask                 the log starts at the point in  CaptSeqTask where the sync code used to be
0000 CaptSeqTask
0000 ISComTask                 ISComTask and CaptSeqTask both have low prio
0000 CaptSeqTask
0000 ISComTask
0000 CaptSeqTask
0000 _ImageSensorTask     high prio task starts here, triggered by CaptSeqTask
0000 SsgMainTask
0000 _ImageSensorTask
0000 SsgMainTask
0000 SsgPeriodTask
0000 SsgMainTask
U1                                              I moved the sync code here, attached to TgTask
U0
0000 TgTask
0010 SsgMainTask
0020 _ImageSensorTask      <- When I tried to put sync code before this, I got completely black photos
0020 CaptSeqTask                 back to low prio tasks, the high prio tasks probably waits for something
0020 PhySw
0020 ISMainTask
0020 ISComTask
0020 ISMainTask
0020 ShutterSoundTask
0020 ISComTask
0020 ShutterSoundTask
0020 ISComTask
0020 ShutterSoundTask
0020 ISComTask
0020 ShutterSoundTask
0020 ISComTask
0020 ShutterSoundTask
0020 CtrlSrv
0020 ISComTask
0020 CtrlSrv
0020 ISComTask
0020 CtrlSrv
0020 ISComTask
0020 CtrlSrv
0020 SsgPeriodTask           high prio tasks run again, the capture happens somewhere here
0020 SsgMainTask
0020 SynchTask
0020 MechaShutter              end of capture

The less common sequence, ~10% of shots
Code: [Select]
0000 ISComTask                  the log starts at the point in  CaptSeqTask where the sync code used to be
0000 CaptSeqTask
0000 ISComTask
0000 CaptSeqTask
0000 ISComTask
0000 CaptSeqTask
0000 ISComTask
0000 CaptSeqTask
0000 SsgPeriodTask                 this seems to be an extra switch to SsgPeriodTask, not triggered by CaptSeqTask
0000 CaptSeqTask
0010 _ImageSensorTask         this is high prio task triggered by  CaptSeqTask but the order is different       
0010 SsgMainTask
0010 _ImageSensorTask
0010 CaptSeqTask                   low prio tasks runs earlier
0010 PhySw
0010 SsgPeriodTask
0010 PhySw
0010 ShutterSoundTask
0010 CtrlSrv
0010 SsgPeriodTask
0010 CtrlSrv
0010 SsgMainTask
0010 SsgPeriodTask
0010 SsgMainTask
U1                                              sync on TgTask
U0
0010 TgTask
0020 SsgMainTask
0020 _ImageSensorTask
0020 SsgPeriodTask
0020 _ImageSensorTask     capture happens somewhere here
0020 SsgMainTask
0020 SynchTask
0020 MechaShutter              end of capture

I think that it should be possible to synchronize the start of shooting with SsgPeriodTask to get always the same sequence, but I don't have reliable results yet.
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: testing sync among more cameras
« Reply #43 on: 29 / October / 2012, 07:39:12 »
Quote from: vnd on 29 / October / 2012, 05:48:23


There is a task SsgPeriodTask which runs all the time, every 20ms or so.

How did you determine that interval ?

Quote
The used sequence depends on the phase of SsgPeriodTask.

Again, how did you determine the 'phase' ?

Logged
*

Offline vnd

  • *
  • 36
Re: testing sync among more cameras
« Reply #44 on: 30 / October / 2012, 15:08:58 »
Quote from: Microfunguy on 29 / October / 2012, 07:39:12

How did you determine that interval ?

Again, how did you determine the 'phase' ?


I tried to get more clear results. Now I have logs starting after the emulated button press and I put 500 ms sleep in place of the original sync code in CaptSeqTask. You can see the results in the attached logs. The sleep is marked with letters S at ~60ms and T at ~560ms. During the sleep the camera runs only the low prio tasks and SsgPeriodTask + _ImageSensorTask. The period seems to be longer than I thought originally, around 30ms, but the timestamps are not very precise:

Code: [Select]
.
.
.
0090 SsgPeriodTask
0090 CtrlSrv
0090 SsgPeriodTask
0090 CtrlSrv
0100 ISMainTask
0100 ISComTask
0100 ISMainTask
0100 SsgPeriodTask
0100 _ImageSensorTask
.
.
.
0120 SsgPeriodTask
0120 ClockSave
0120 SsgPeriodTask
0120 ClockSave
0130 PhySw
0130 SpyTask
0130 PhySw
0130 SpyTask
0130 PhySw
0130 SpyTask
0130 PhySw
0130 CtrlSrv
0130 SsgPeriodTask
0130 _ImageSensorTask
.
.
.

My current theory is that if the shooting starts (CaptSeqTask triggers _ImageSensorTask at ~580ms) in the ~20ms interval marked by dots, between _ImageSensorTask and the next period of SsgPeriodTask, then it follows the first sequence I described above and the timing is always the same. You can see it in sw00001.txt.
If the shooting starts in the ~10ms (probably shorter) interval between SsgPeriodTask and _ImageSensorTask, the shooting follows the second sequence - sw00002.txt

Tomorrow I will try to verify this with a CRT monitor.
Logged
*

Offline vnd

  • *
  • 36
Re: testing sync among more cameras
« Reply #45 on: 01 / November / 2012, 06:40:05 »
Syncing the start of shooting with SsgPeriodTask gives slightly better results - 28 good shots out of 30.

Maybe a better way would be to disable or slow-down the period so it does not interfere with synch. With the info from http://chdk.setepontos.com/index.php?topic=7938.0 it might be possible.

Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: testing sync among more cameras
« Reply #46 on: 01 / November / 2012, 11:13:47 »
Quote from: vnd on 01 / November / 2012, 06:40:05
Maybe a better way would be to disable or slow-down the period so it does not interfere with synch.

How does the movie frame period affect still image capture ?

I am obviously misunderstanding this.

Logged
*

Offline vnd

  • *
  • 36
Re: testing sync among more cameras
« Reply #47 on: 01 / November / 2012, 12:08:42 »
I assume that it uses the same timer for both video and live view.

The live view period is running until the very beginning of the still image capture. Then, reconfiguring the sensor for still image takes different times, depending on the phase of the period where it starts.

Part of the live view period is probably guarded by some semaphore, so the reconfiguring has to wait if it starts during this phase.



Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: testing sync among more cameras
« Reply #48 on: 01 / November / 2012, 19:05:53 »
I bet you and srsa_4c could work-out how to synchronise two cameras for movie capture, but that is another topic   :)


David
Logged
*

Offline vnd

  • *
  • 36
Re: testing sync among more cameras
« Reply #49 on: 03 / November / 2012, 04:55:09 »
I played a bit with the FPS registers and found this:

0xC0F06014 -  write period length
0xC0F06000 - write 1 to apply values, the new value is applied at the end of current period, reading 0xC0F06000 back returns 1 until the new value is applied, then returns 0

read 0xC0F07008 (or many others registers in 0xC0F07 range) returns the actual counter value in the lower 16 bits. Higher 16 bits  changes between 0 and 1, I don't know what it means.

For example:
Code: [Select]
0xC0F06014 is set to 0x110 at the beginning by the camera.

write         write          read           read
0xC0F06014    0xC0F06000     0xC0F06000     0xC0F07008
=========================================================
                             0              0x10e
                             0              0x10f
                             0              0x110
                             0              0x0
                             0              0x1

...

                             0              0x50
0x1000
              1
                             1              0x51
                             1              0x52

...

                             1              0x10e
                             1              0x10f
                             1              0x110
                             0              0x0
                             0              0x1

...

                             0              0x0ffe
                             0              0x0fff
                             0              0x1000
                             0              0x0
                             0              0x1

I think that with this info we can fully control the phase with regard to synch pulse. In principle it could work also for video.
Logged
Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 13   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal