testing sync among more cameras

reyalp

14118

Re: testing sync among more cameras

« Reply #90 on: 13 / August / 2013, 16:26:24 »

Advertisements

Quote from: srsa_4c on 13 / August / 2013, 15:26:34

EngDrvRead is available on all cameras, and is found by the sigfinder (only for DryOS ATM). It will need a wrapper though.

The EngDrv functions are available as eventprocs, so finding it on vxworks cameras should not difficult. Also meaning you can play with them from lua if you want...

EngDrvReadDump may be interesting with console logging.

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: testing sync among more cameras

« Reply #91 on: 13 / August / 2013, 16:57:28 »

Quote from: reyalp on 13 / August / 2013, 16:26:24

The EngDrv functions are available as eventprocs, so finding it on vxworks cameras should not difficult.

I know, I'm more or less up-to-date with my added sigfinder functions on VxWorks too. It's just not official - converting everything finsig_vxworks can to the finsig_dryos codebase seems too much work.

Logged

waterwingz

12140

Re: testing sync among more cameras

« Reply #92 on: 13 / August / 2013, 16:58:19 »

I've been thinking about how to test this patch more efficiently. Especially when you only have one camera available during the porting process.

I'm thinking that a simple Arduino setup would solve this. Use a digital output from the Arduino to drive the USB+ voltage to the camera under test. Also have the Arduino drive a set of 4 to 8 LED's in a binary counting pattern - incrementing the count every 250 uSecs. Program it so that counting only happens during the expected time window when the shutter will be open.

Once you have this setup built, use it to drive your camera in USB sync mode and take a lot of images of the LED's (maybe 50 - they are free). Then compare the images. If the hack is working correctly, the LED pattern in each image should be close ( +/- 1 binary count).

This is not as good a test as the SDM CRT test - differences in mechanical delays in the shutter mechanism of different cameras won't been seen for example. But for testing this particular patch, I think it should work really well.

Update : my Raspberry Pi & piface extension board should be adequate for this too - using a simliar setup to what I used here : http://chdk.setepontos.com/index.php?topic=7127.msg100447#msg100447 - need to remember to use a Gray code on the LED's .....

« Last Edit: 13 / August / 2013, 18:50:38 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3450

Re: testing sync among more cameras

« Reply #93 on: 24 / August / 2013, 00:46:00 »

Quote from: waterwingz on 12 / August / 2013, 20:08:09

This topic has continued to be interesting to the people with multi-camera bullet time rigs (and those who wish to do stereo photography with CHDK).

In order to get this into the 1.3.0 trunk, the patch needs to be generalized so that it can be activated on cameras that have been tested, and so that it can be easily enabled for testing on cameras where the feature is requested.

To that end, I've attached a patch file that shows how this might be done. It assumes that

Code: [Select]
#define USB_PRECISION_SYNC 1is added to the platform_camera.h of any cameras where the feature is tested (or is to be tested).

There are four "register" values that need to be defined. I stuck them in the usb_remote.c code for this example but they belong in either platform_camera.h or perhaps stubs_min.S or stubs_entry_2.S. Obvious if they get added to the sigfinder they go in stubs_entry.S

Code: [Select]
// s90 values #define USB_SYNC_REGISTER_1 0xC0F06000 #define USB_SYNC_REGISTER_2 0xC0F06014 #define USB_SYNC_REGISTER_3 0xC0F07008 #define USB_SYNC_PERIOD 0x00386014Finding the first three of these seems to depend only on having a digicIV or digicV camera but its not clear that is always true. The last one is apparently found by looking inside the EngDrvOut function.

I suppose I could have posted this in the 1.3.0 planning thread, but it seem to make more sense to put it here.

As far as I can tell the IO addresses are the same on all Digic cameras (from S5IS to SX50HS).
The shadow RAM address changes from camera to camera, so using EngDrvRead would be preferable for USB_SYNC_PERIOD.

I'm not sure about the names though - these IO addresses don't really have anything to do with USB and synching is just a side effect.

Funnel used regB (0xC0F06014) and reg_update (0xC0F06000) in his script; but these aren't really very accurate either.
Perhaps:

Code: [Select]

#define GPIO_VSYNC_UPDATE  0xC0F06000
#define GPIO_VSYNC_MAX     0xC0F06014
#define GPIO_VSYNC_CURRENT 0xC0F07008

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: testing sync among more cameras

« Reply #94 on: 31 / August / 2013, 16:12:42 »

Quote from: philmoz on 24 / August / 2013, 00:46:00

As far as I can tell the IO addresses are the same on all Digic cameras (from S5IS to SX50HS). The shadow RAM address changes from camera to camera, so using EngDrvRead would be preferable for USB_SYNC_PERIOD.

Its not instantly clear to me how to use EngDrvRead. There are only a couple of forum posts. The older EngDrv posts are not too helpful either. I don't track the DSLR forum threads - maybe something more is there or in the ML wiki? Any pointers would be appreciated and definitely a huge time saver for me.

Update : nafraf just told me in IRC that all I need is :

Code: [Select]

int std_period = _EngDrvRead(USB_SYNC_REGISTER_2);

Quote

I'm not sure about the names though - these IO addresses don't really have anything to do with USB and synching is just a side effect. Funnel used regB (0xC0F06014) and reg_update (0xC0F06000) in his script; but these aren't really very accurate either.
Perhaps:
Code: [Select]
#define GPIO_VSYNC_UPDATE 0xC0F06000 #define GPIO_VSYNC_MAX 0xC0F06014 #define GPIO_VSYNC_CURRENT 0xC0F07008

That works for me .. I'll update my patch file. If I can puzzle out the EngDrvRead stuff then I'm ready to start with my Arduino based single camera statistical testing of sync precision.

« Last Edit: 31 / August / 2013, 16:30:00 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

waterwingz

12140

Re: testing sync among more cameras

« Reply #95 on: 02 / September / 2013, 10:43:47 »

Made a little progress. Measuring shot-to-shot variation should give a good estimation of USB remote sync quality, allowing testing of vnd's precision sync modification when you only have one camera to play with. That should tell us if the mod works on more cameras - especially those being used in bullet-time rigs.

Got the Raspberry Pi version that I showed above working but I got worried about interrupts on the Linux O/S preventing sub-millisecond timing accuracy.

So I built this :

The AVR programmer board allows serial communication over USB to a terminal program so I was able to write a quick & dirty UI that lets me adjust the test parameters without reloading the code. The basic test send 5V to the camera's USB port, holds that for five seconds to allow the camera to focus, removes the 5V and then enters an initial precision delay period. At the end of that delay, the LED's start "counting" - using a Gray code so that only one LED changes with each count. ( Note : using the delay lets me set a sync window with more precision than just running the LED's as soon as the USB voltage is removed.)

Initial testing of the A1200 show that with or without sync enabled, the actual shot to shot variation is huge. The G10 on the other hand sync's in under a millisecond routinely. One nice part of using this setup is that you can tell it to do 100 shots, walk away for a few minutes, and then come back and tabulate the results from the images taken.

Tesing the G10 revealed another problem. If you want the LEDs to count every 100 uSec (thereby binning your values with 200 uSec precision) then you really need to be able use a shutter speed of 1/10,000. However at that speed, even with the ISO set to 1600, the LED's that I found in my junk drawer and used are not bright enough to give a good image. But the little red & green surface mount LED's on the uC board come through just fine at that speed. So, using typical brute force engineering, I ordered some super bright 10,000 mcd LEDs and will continue testing when they arrive.

I also discovered that vnd's precision sync patch seems to crash my A1200 about 1/10 of the time. The symptom are similiar to what happens with the old code if you make the sync delay too long - the camera just shuts down after about 10 seconds with the lens still extended. There are two wait loops in the code so figuring out which one is hanging up should not be that hard.

Logged

Ported : A1200 SD940 G10 Powershot N G16

Karmaschinken

198

Re: testing sync among more cameras

« Reply #96 on: 20 / November / 2013, 06:54:06 »

Quote from: waterwingz on 12 / August / 2013, 20:08:09

This topic has continued to be interesting to the people with multi-camera bullet time rigs (and those who wish to do stereo photography with CHDK).

waterwingz, please could you explain to me how i would implement your precision_sync.patch? Since I don't have real experiences I am hesitating a little to put this piece of software into my camera without knowing what I do.

Shall I simply copy the _wait_until_remote_button_is_released function into my usb_remote.c, together with the defines? What about the USB_SYNC_PERIOD that should be found in "EngDrvOut"? Can this be omitted, as stated in a later Mail? And if so, how?

Thanks a lot!

Logged

Microfunguy

4037

Re: testing sync among more cameras

« Reply #97 on: 20 / November / 2013, 07:30:01 »

I thought I had asked previously, what camera are you using ?

Logged

ahull

634

Re: testing sync among more cameras

« Reply #98 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 (potentially up to 8MHz), this would give very precise timing, without any need for the potentially error prone complexity of coding a microcontroller. Still binary though..

... and probably overkill.

You could even trigger the camera from it if you ran it at a suitable voltage.

« Last Edit: 20 / November / 2013, 08:36:35 by ahull »

Logged

waterwingz

12140

Re: testing sync among more cameras

« Reply #99 on: 20 / November / 2013, 08:48:20 »

Quote from: Karmaschinken on 20 / November / 2013, 06:54:06

waterwingz, please could you explain to me how i would implement your precision_sync.patch? Since I don't have real experiences I am hesitating a little to put this piece of software into my camera without knowing what I do.

Shall I simply copy the _wait_until_remote_button_is_released function into my usb_remote.c, together with the defines? What about the USB_SYNC_PERIOD that should be found in "EngDrvOut"? Can this be omitted, as stated in a later Mail? And if so, how?

Thanks a lot!

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

Logged

Ported : A1200 SD940 G10 Powershot N G16