Understanding precision sync

andrew.stephens.754365

461

Understanding precision sync

« on: 18 / February / 2018, 04:40:31 »

Advertisements

For normal usbremote sync my understanding is that if, at switch release, the current count is less than a fixed "critical value” then the shot will occur immediately & that if the current count is equal to or greater than this critical value then the shot will occur at the end of the following period.

vnd's attempt to address the challenge is stated in the precision sync code here:

https://chdk.setepontos.com/index.php?topic=8312.msg107419#msg107419

i.e.

For any current count less than 10 from end of period in which switch release occurs:
if at switch release the current count is less than 10 from the end of the period count an attempt to write an extended period count to the count register (GPIO_VSYNC_MAX) is only initiated after the period count has reset to zero i.e. this attempt begins at the beginning of the subsequent normal period count and if successful will be written to GPIO_VSYNC_MAX at the end of that normal period count. The extended count in these circumstances is calculated as:

2xstd period count less (maximum period count less count at switch release)
(i.e. equivalent to 1xstandard period + counts to end of current period)

After 40ms from the beginning of this extended count its current count is examined by Canon. Assuming a non-extended count is less than 40ms then this current count will always be greater than the “critical value” and the shot will occur at the end of the unextended count following the extended count.

For any current count equal or greater than 10 from end of period in which switch release occurs:
if at switch release the current count is 10 or more from the end of the period count an attempt to write an extended period count to GPIO_VSYNC_MAX begins immediately and, if successful, will be written to the register at the end of this normal period count. In this case, the extended count is calculated as:

3xstd period count less (maximum period count less count at switch release)
(i.e. equivalent to 2xstandard period + counts to end of current period)

Again, after 40ms from the beginning of this extended count its current count is examined by Canon. Assuming a non-extended count is less than 40ms then this current count will always be greater than the “critical value” and the shot will occur at the end of the unextended count following the extended count.

In summary, assuming the extended count values are applied to GPIO_VSYNC_MAX in the fashion described then precision sync will occur at practically the same time in both circumstances described at the end of the normal count period which follows the two differently calculated extended periods – this causes all the shots to occur at 4x std periods from switch release (practically always with less than 1ms variance).

My understanding of why vnd only attempts to apply the extended count after the end of the count in which switch release occurs (only when the current count is within a count of 9 from its end) is due to the amount of processing involved with changing the image sensor from free-running to image capture mode i.e. if we are close to the end of the period there is a good chance an attempt to apply the extended count to to GPIO_VSYNC_MAX will not be successful so just wait until next std period before trying to do so.

If that was vnd’s supposition then it seems nearly as likely that, at switch release, a count of 10 (rather than 9 for example) from the end of the count would fail in any attempt to have an extended count written to GPIO_VSYNC_MAX by the end of the period in which the switch release occurred.

So, if occasionally this 10 count (or other close to it but not less than 10) does fail to update GPIO_VSYNC_MAX before the end of the switch release std period then it seems likely that the extended count will, instead, be written to GPIO_VSYNC_MAX at the end of the following unextended period but at a value of:
3xstd count less (maximum period count less count at switch release)

This event would lead to the precision sync outlier occurring a full std period after all other precision sync shots i.e. from switch release the shot would occur at the end of the std period following the extended period – the shot occurs 5xstd periods after switch release.

However, we do not see this by experiment. Instead the precision sync outlier seems to occur a single std period prior all other precision sync shots as the diagram here displays – the shot occurs 3xstd periods after switch release.:
https://chdk.setepontos.com/index.php?topic=8312.msg107601#msg107601

My understanding of what lies beneath the precision sync outlier must therefore be wrong but I can’t currently see where.

If anyone could usefully comment as to what could conceivably be behind theoutlier timing occurrence it could relieve a headache.

« Last Edit: 19 / February / 2018, 05:26:37 by andrew.stephens.754365 »

Logged

andrew.stephens.754365

461

Re: Understanding precision sync

« Reply #1 on: 19 / February / 2018, 12:24:45 »

Quote from: philmoz on 09 / November / 2012, 16:13:38

Quote from: Microfunguy on 05 / November / 2012, 07:02:26
In the example calculation of fps that funnel gave, regA x RegB = 60,000,000.

In our example, 0x110 x 0x1215 = 1,259,088 decimal.

According to funnel:
regA x regB x fps = frequency
or
fps = frequency / (regA x regB)

The clock frequency in the firmware table on the S95/G12 is 38MHz.

So fps = 38000000 / (0x110 x 0x1215) = 30.18

Phil.

Is there a way, by script for example, to determine the clock frequency & regB for SX150IS?

Logged

philmoz

3450

Re: Understanding precision sync

« Reply #2 on: 20 / February / 2018, 19:31:45 »

It's been a while since I looked at this stuff so the memory is a bit vague.

I don't recall exactly where the clock frequency was found in the firmware, I may be able to track it down; but not sure when I will have time.

The main function of the precision synch code is to align the vertical video synch timing across cameras, the video synch timing appears to control other factors including when the camera takes an image. The assumption is that the time from the end of a video frame to the image capture is pretty constant, so if you can sync the video frame timing you should get better image sync timing.

For example, lets say the video frame interval is 30ms and we have two cameras.
The cameras detect the USB pulse at the same time (they are waiting on it).

Lets say that the two cameras are 5ms out of sync on the video frame, camera A is 5ms later than camera B.

Camera A sees the USB pulse, and sees that it is 15ms into a frame, it sets up and extended frame to last 45ms (30ms + time remaining of 15ms).
Camera B sees the USB pulse; but it is only 10ms into the frame, it sets up an extended frame of 50ms (30ms + remaining of 20ms).

After these extended frames have finished the two cameras should now have their video frames occurring at roughly the same time.

That's the theory, in practice the extended frame duration stuff is finicky, the logic that checks how close to the end of the current frame tries to sort out the complications.

I don't know why the outliers are happening, I don't have two of the same camera to test with so never had a chance to investigate in detail.
The fact that the outliers are 30ms off indicates to me that the synch logic is working to align the video frames; but for some reason there is an edge case that results in one standard period difference.

Hope this helps,
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

12140

Re: Understanding precision sync

« Reply #3 on: 20 / February / 2018, 19:40:19 »

Quote from: philmoz on 20 / February / 2018, 19:31:45

I don't know why the outliers are happening, I don't have two of the same camera to test with so never had a chance to investigate in detail.

FWIW, I generated those graphs with one camera. The x axis shows time between USB release and the actual image capture (rather that the differences between cameras) under each of the three test conditions (no sync, regular sync, precision sync). When you think about it, one camera is all you need.

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3450

Re: Understanding precision sync

« Reply #4 on: 20 / February / 2018, 20:24:06 »

Quote from: waterwingz on 20 / February / 2018, 19:40:19

Quote from: philmoz on 20 / February / 2018, 19:31:45
I don't know why the outliers are happening, I don't have two of the same camera to test with so never had a chance to investigate in detail.
FWIW, I generated those graphs with one camera. The x axis shows time between USB release and the actual image capture (rather that the differences between cameras) under each of the three test conditions (no sync, regular sync, precision sync). When you think about it, one camera is all you need.

My understanding is that, if two or more cameras still take the image at the same time, even if the time from the USB release differs from image to image, then the outliers are of no concern and the precision sync is working.

Is that not the purpose of the precision sync?

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

12140

Re: Understanding precision sync

« Reply #5 on: 20 / February / 2018, 20:41:49 »

Quote from: philmoz on 20 / February / 2018, 20:24:06

My understanding is that, if two or more cameras still take the image at the same time, even if the time from the USB release differs from image to image, then the outliers are of no concern and the precision sync is working.

To review, each camera's actions are completely independent - one camera has no idea what the other camera is doing. The only thing they have in common is the reference point at which the USB signal is released (i.e. goes from +5V to 0V).

The quality of precision sync is determined by how closely the actual image capture time matches after that USB signal is released. In other words, every time the USB signal is released, the delay until the image is taken needs to be the same. If the delay is not exactly the same, some images will not be precisely sync'd.

Having said that, assuming the delay time slips occassionally, then both cameras will occasionally randomly slip at the same time and line up. That would produce a sync'd image. Which means that the number of cases of poor sync might be somewhat less than originally suggested because occasionally both cameras shoot early together.

Sorry if this sounds confusing. What this reduces to is that you can use a single camera to experiment until you always get the same delay after USB release. If you get variations then you will not always get sync between seperate cameras, even though the slips will sometimes align.

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3450

Re: Understanding precision sync

« Reply #6 on: 20 / February / 2018, 21:33:54 »

Quote from: waterwingz on 20 / February / 2018, 20:41:49

Quote from: philmoz on 20 / February / 2018, 20:24:06
My understanding is that, if two or more cameras still take the image at the same time, even if the time from the USB release differs from image to image, then the outliers are of no concern and the precision sync is working.
To review, each camera's actions are completely independent - one camera has no idea what the other camera is doing. The only thing they have in common is the reference point at which the USB signal is released (i.e. goes from +5V to 0V).

Not really. They are all waiting for the USB release, in the same CHDK code. If they were truly independent none of this would work.

Quote

The quality of precision sync is determined by how closely the actual image capture time matches after that USB signal is released. In other words, every time the USB signal is released, the delay until the image is taken needs to be the same. If the delay is not exactly the same, some images will not be precisely sync'd.

Having said that, assuming the delay time slips occassionally, then both cameras will occasionally randomly slip at the same time and line up. That would produce a sync'd image. Which means that the number of cases of poor sync might be somewhat less than originally suggested because occasionally both cameras shoot early together.

I see now what you are saying, thanks.

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

12140

Re: Understanding precision sync

« Reply #7 on: 20 / February / 2018, 21:46:58 »

Quote from: philmoz on 20 / February / 2018, 21:33:54

Not really. They are all waiting for the USB release, in the same CHDK code. If they were truly independent none of this would work.

Semantics.

It's true that they are all waiting in the same one line of CHDK USB remote code for the USB power line to go from +5V to GND.

But where they are in various cycles of interrupts and video sync signals is completely independent when the USB line state changes. And that's what drives the differences in time to actual exposure (and thus sync).

Logged

Ported : A1200 SD940 G10 Powershot N G16

andrew.stephens.754365

461

Re: Understanding precision sync

« Reply #8 on: 21 / February / 2018, 06:32:27 »

Quote from: philmoz on 20 / February / 2018, 19:31:45

I don't recall exactly where the clock frequency was found in the firmware, I may be able to track it down; but not sure when I will have time.

Understood Phil. Thanks.

Quote from: waterwingz on 20 / February / 2018, 20:41:49

Having said that, assuming the delay time slips occassionally, then both cameras will occasionally randomly slip at the same time and line up. That would produce a sync'd image. Which means that the number of cases of poor sync might be somewhat less than originally suggested because occasionally both cameras shoot early together.

Sorry if this sounds confusing. What this reduces to is that you can use a single camera to experiment until you always get the same delay after USB release. If you get variations then you will not always get sync between seperate cameras, even though the slips will sometimes align.

Thanks for comment.

I don’t fully understand that. Let me try to pinpoint some meaning by continuing the example with specific numbers that I hope are relevant.

Quote from: waterwingz on 06 / April / 2014, 12:31:25

On my A1200, the value is 0 in playback mode, sits at 103 in shooting mode until a half press changes it to 963 while focussing and 209 when focussed.

Say, at switch release, current count is 200 (i.e. within 10 of end of period count) then vnd’s:

Code: [Select]

while ((*(volatile int*)(GPIO_VSYNC_CURRENT) & 0xffff) >= cur_cnt) {}loops until GPIO_VSYNC_CURRENT is less than 209 which occurs immediately at the beginning of the subsequent normal count.

vnd’s:

Code: [Select]

sync_period -= std_period;calculates the extended period value as 3x209 – (209-200) – 1x209 = 409
vnd now attempts, in this new std period, to apply 409 to GPIO_VSYNC_MAX via:

Code: [Select]

(volatile int*)(GPIO_VSYNC_MAX) = sync_period; // write the length of the extended period to the registerbut says that won’t happen until the end of this new std period, i.e:

Quote from: vnd on 03 / November / 2012, 04:55:09

0xC0F06000 - write 1 to apply values, the new value is applied at the end of current period, reading 0xC0F06000

So, normally at end of count at:
switch release + 9 + 209

then 409 is written to GPIO_VSYNC_MAX

i.e. 409 will be the maximum count of the next count.

vnd’s:

Code: [Select]

msleep(40)
then waits for 40ms into the extended period at which point Canon understands the current count is greater than a critical value. My understanding is that, if a critical fixed value is surpassed (it always is at 40ms) shooting occurs immediately at the end of the period following the extended period.

vnd resets this following period to the normal count of 209 via:

Code: [Select]

*(volatile int*)(GPIO_VSYNC_MAX) = std_period; // back to standard timing on next periodSo, from switch release, the shot occurs at the following count quantity:
9 + 209 + 409 + 209 = 836 (i.e. 4 x std periods approx 132ms)

E.g.2
Say, at switch release, current count is 199 (i.e. 1 count before vnd’s 9 of end of period count) then vnd’s code to wait until the next period is skipped :

Code: [Select]

while ((*(volatile int*)(GPIO_VSYNC_CURRENT) & 0xffff) >= cur_cnt) {} – does not applyNeither does vnd’s code subtract a std_period from the sync_period. Instead an immediate attempt to write an extended period of:
sync_period = 3x209 – (209-199) = 617

to GPIO_VSYNC_MAX occurs, again, via :

Code: [Select]

(volatile int*)(GPIO_VSYNC_MAX) = sync_period; // write the length of the extended period to the register.If that is successful then at:
switch release + 10

the value 617 is written to GPIO_VSYNC_MAX

vnd’s code:

Code: [Select]

msleep(40)
then waits for 40ms into the extended period at which point Canon understand the current count is greater than a critical value. My understanding is that, if a critical fixed value is surpassed (it always is at 40ms) shooting occurs immediately at the end of the period folowing the extended period.

Vnd’s code reset this following period to the normal count of 209 via:

Code: [Select]

*(volatile int*)(GPIO_VSYNC_MAX) = std_period; // back to standard timing on next period
So, from switch release, the shot occurs at the following count quantity:
10 + 617 + 209 = 836 ( 4 x std period = 132ms)

My conundrum relates to vnd’s code:

Code: [Select]

if (std_period - cur_cnt < 10)
If vnd had not included this code to wait (for counts less than 10 from period end) until the beginning of the subsequent std period to attempt to apply an extended count to GPIO_VSYNC_MAX), is a count of 10 from end of period, significantly, any more likely to fail to update GPIO_VSYNC_MAX at the end of the period in which the switch release occurred compared to a count of 9 (or less)?

i.e. if the 10 count from end does not have enough time to have the extended count applied to GPIO_VSYNC_MAX in the count in which the switch release occurs then it seems likely it will be applied at the end of the subsequent std count and that the shot will occur, from switch release, at count:

10 +209 + 617 + 209 = 1045 ( 5 x std period = 165ms)

This does not happen.

If you could describe the circumstances in which a "slip" might happen (just referring to that on one camera) it would be appreciated.

Edit:

Quote from: waterwingz on 20 / February / 2018, 20:41:49

Which means that the number of cases of poor sync might be somewhat less than originally suggested because occasionally both cameras shoot early together.

I do get that - but not how both shots could occur at 99ms rather than at 165ms from switch release.

« Last Edit: 21 / February / 2018, 12:13:20 by andrew.stephens.754365 »

Logged

philmoz

3450

Re: Understanding precision sync

« Reply #9 on: 21 / February / 2018, 16:46:17 »

Quote from: andrew.stephens.754365 on 21 / February / 2018, 06:32:27

I do get that - but not how both shots could occur at 99ms rather than at 165ms from switch release.

My theory would be that the shot occurs at the end of the extended period rather than after the subsequent standard period.
So the shot occurs one standard period earlier - which would explain the ~30ms difference.

I suspect there is some case where the msleep(40) is not always ensuring the behaviour we are after.

Perhaps playing with the msleep value might give some clues.

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)