testing sync among more cameras - page 8 - General Discussion and Assistance - CHDK Forum supplierdeeply

testing sync among more cameras

  • 121 Replies
  • 29639 Views
*

Offline philmoz

  • *****
  • 3133
    • Photos
Re: testing sync among more cameras
« Reply #70 on: 09 / November / 2012, 16:08:45 »
Advertisements
In your period_synch.patch file how did you find the address 0x00406014
You can find the RAM base address by looking inside the EngDrvOut function (it's exposed as an event procedure).

Thanks. Address on G1X is 0x00606014.

Phil.
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)

*

Offline philmoz

  • *****
  • 3133
    • Photos
Re: testing sync among more cameras
« Reply #71 on: 09 / November / 2012, 16:13:38 »
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.

« Last Edit: 09 / November / 2012, 16:16:14 by philmoz »
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)

Re: testing sync among more cameras
« Reply #72 on: 09 / November / 2012, 16:31:53 »
The clock frequency in the firmware table on the S95/G12 is 38MHz.

I am not sure where the firmware table is, that is why I asked 'vnd'  :-

"On 100H, does the code associated with Fldspec.c contain a reference to RAM address 0xA83C and does that contain a pointer to 0xFFC3BEAC ?"

Strange that the standard period varies with lighting level.

*

Offline philmoz

  • *****
  • 3133
    • Photos
Re: testing sync among more cameras
« Reply #73 on: 09 / November / 2012, 16:50:43 »
The synch period is therefore either less than three standard periods or less than two standard periods.
By delaying 40 msec we ensure we are in the lower half of either synch period.
Yes, correct.

If I understand correctly the camera delays shooting until the end of the current live view frame which at 30fps will be every 1/30th of a second.

Your patch tells the camera to wait 3 frames instead for the next shot.

The line:
          while (*(volatile int*)(0xC0F06000)) {}; // wait until the new value is applied
will wait until the start of the next synch period - potentially up to 33ms in a tight spin loop.

Now since the camera is already at the start of the synch period the msleep(40) seems redundant to me.

Wouldn't it be better to use:
          while (*(volatile int*)(0xC0F06000)) { msleep(10); }; // wait until the new value is applied
to avoid the tight loop and then remove the later msleep(40)?

I've tried this on my G12 and it still seems to work ok; but I don't have a pair of cameras to try so can't test if this affects synch accuracy.

Phil.
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)


*

Offline philmoz

  • *****
  • 3133
    • Photos
Re: testing sync among more cameras
« Reply #74 on: 09 / November / 2012, 17:02:10 »
The clock frequency in the firmware table on the S95/G12 is 38MHz.

I am not sure where the firmware table is, that is why I asked 'vnd'  :-

"On 100H, does the code associated with Fldspec.c contain a reference to RAM address 0xA83C and does that contain a pointer to 0xFFC3BEAC ?"

On S95 1.00e the table is at 0xFFC36CE4.

The memory at address 0xA83C is an array of pointers to the entries in the table at 0xFFC36CE4.

The 0xA83C memory is initialised at startup from another area of the firmware.
At the start of the firmware it copies a block of memory from 0xFFC9A08C to 0x1900. So the initial values for 0xA83C are at 0xFFC9A08C + 0xA83C - 0x1900 = 0xFFCA2FC8.

You should be able to find the equivalent for 1.00h.

Quote
Strange that the standard period varies with lighting level.

Not really - the camera lowers the frame rate of the live view in low light.
Since the clock frequency is fixed this means regA and regB have to change.

Phil.
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)

*

Offline vnd

  • *
  • 36
Re: testing sync among more cameras
« Reply #75 on: 09 / November / 2012, 17:47:06 »

If I understand correctly the camera delays shooting until the end of the current live view frame which at 30fps will be every 1/30th of a second.


It is a bit more complicated. If the shooting starts with counter value between 0 and 0xe0, it starts immediately. With value between 0xe1 and 0x110 it waits for the next period. 0xe0 is the value of register 0xC0F0713C.
I don't know what is the reason for this behavior and if it is the same on other cameras.
This also explains why the synch worked well in more than 50% of cases.

Quote
The line:
          while (*(volatile int*)(0xC0F06000)) {}; // wait until the new value is applied
will wait until the start of the next synch period - potentially up to 33ms in a tight spin loop.

Now since the camera is already at the start of the synch period the msleep(40) seems redundant to me.

msleep(40) waits for the second part of the period when the counter value is higher than 0xe0. At the time when I wrote the patch I didn't know what exactly the value is and msleep(40) worked reliably

You are right that it can be rewritten with msleep(10) to avoid busy waiting.

It would work even better if we could trigger an interrupt on usb bit change (maybe the firmware already does that) and save the counter value in the interrupt handler. This would give us even better precision and eliminated busy waiting completely.


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

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


Thank you for looking this up. I don't have the firmware dump nor IDA.

Re: testing sync among more cameras
« Reply #76 on: 09 / November / 2012, 17:57:34 »
It is a bit more complicated. If the shooting starts with counter value between 0 and 0xe0, it starts immediately.

I do not get this.
Are you saying that even for an extended period 0x110 count represents the full period ?

Quote
msleep(40) waits for the second part of the period when the counter value is higher than 0xe0.

Again, do you mean the the extended period ?

*

Offline philmoz

  • *****
  • 3133
    • Photos
Re: testing sync among more cameras
« Reply #77 on: 09 / November / 2012, 19:33:37 »
On the SX40HS and G1X the value of *(volatile int*)(0xC0F07008) & 0xffff is always 0.

Phil.
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)


Re: testing sync among more cameras
« Reply #78 on: 09 / November / 2012, 19:40:55 »
vnd said :-

"the other one (0xC0F07008) I found. As I understand it, these are Digic IV registers and should be the same at least on all Digic IV cameras."

He did not say how he found it.

*

Offline philmoz

  • *****
  • 3133
    • Photos
Re: testing sync among more cameras
« Reply #79 on: 10 / November / 2012, 23:35:33 »

If I understand correctly the camera delays shooting until the end of the current live view frame which at 30fps will be every 1/30th of a second.


It is a bit more complicated. If the shooting starts with counter value between 0 and 0xe0, it starts immediately. With value between 0xe1 and 0x110 it waits for the next period. 0xe0 is the value of register 0xC0F0713C.
I don't know what is the reason for this behavior and if it is the same on other cameras.
This also explains why the synch worked well in more than 50% of cases.


Ok, if I'm understanding this correctly by inserting a variable length synch period (up to 3x the normal period) you are actually aligning the start of the synch period on each of the cameras.

So the first shot won't be better than the random synch seen with the old code; but every subsequent shot will be accurately aligned (to with 1/4 millisecond by my calculation).

Phil.
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)

 

Related Topics