CHDK PTP multiple instances - page 12 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 7 8 9 10 11 [12] 13 14 15 16 17 ... 19   Go Down

CHDK PTP multiple instances

  • 180 Replies
  • 73459 Views
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: CHDK PTP multiple instances
« Reply #110 on: 20 / November / 2013, 06:36:38 »
Advertisements
Quote from: Karmaschinken on 20 / November / 2013, 05:27:07
And this is due to the phenomenon overcome by vnd?

Yes.

Quote
Would applying vnds ingenious difference-removal-patch eliminate these differences?

It should do.
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: CHDK PTP multiple instances
« Reply #111 on: 20 / November / 2013, 08:30:35 »
Quote from: Karmaschinken on 20 / November / 2013, 05:27:07
Don't understand that. I chose 1/250th because then I can see a pattern which might be better to see while "running", however I will rebuild the testing setup with 50 LEDs.

I am addressing the LEDs with dedicated channels from an Arduino Mega 2560, do I really have to use Gray Code then too? Nevertheless, I'll do that. This is the code I used for the test:
With my setup, I only have a single camera.   I want to time the exact period between when the USB signal goes to 0v and when the shutter opens.  So I want to see an  "exact" pattern on the LED's in the resulting image - not some combination of three to five different LED settings that change while the shutter was open. This means that I need the shutter speed to be faster than the time period that any single LED pattern will display.  The pattern on the LED's then tells me the exact time from when the USB 5V signal goes to ground to when the shutter opens.  Comparing multiple photos tells me how good the sync is by know exactly how long it took for the shutter to open each time.

At 1/2000 of a second,  the image will be a single pattern 50% of the time.  The rest of the time it will be a combination of two patterns,  as the "count' value changes during the exposure.  Using a Gray Code pattern for the LED drive ensures that only one LED changes at each count,  so I can still determine the exact timing ( within 2 mSec in this example).  Here's the code for my Arduino clone :
Code: [Select]
void update_leds(value) 
{
            if( value & 0x01 ) set_digital_output(IO_C0, LOW); 
            else               set_digital_output(IO_C0, HIGH);
            if( value & 0x02 ) set_digital_output(IO_C1, LOW); 
            else               set_digital_output(IO_C1, HIGH);
            if( value & 0x04 ) set_digital_output(IO_C2, LOW); 
            else               set_digital_output(IO_C2, HIGH);
            if( value & 0x08 ) set_digital_output(IO_C3, LOW); 
            else               set_digital_output(IO_C3, HIGH);
            if( value & 0x10 ) set_digital_output(IO_C4, LOW); 
            else               set_digital_output(IO_C4, HIGH);
            if( value & 0x20 ) set_digital_output(IO_C5, LOW); 
            else               set_digital_output(IO_C5, HIGH);
            if( value & 0x40 ) set_digital_output(IO_B0, LOW); 
            else               set_digital_output(IO_B0, HIGH);
}

for ( i = 0 ; i<128 ; i++ )
{
    update_leds((i >> 1 ) ^ i) ;
     delay_us(count_period);
}


If this is too complicated and you have enough LED's, then drive the LED's on sequentially like a bar graph and shoot at 1/2000 of a second.  The distance along the bar graph tells you when each shutter fired.   

Note that in my code,  I use a user defined delay before staring the pattern to allow me to increase precision of the pattern by running it faster.  I experiment with the setup to find the shorted delay needed using trial and error.  I'm also using ultra high brightness LED's so that I can use fast shutter speeds.




Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Karmaschinken

  • ***
  • 198
Re: CHDK PTP multiple instances
« Reply #112 on: 14 / December / 2013, 20:08:54 »
Great work. On my side the things take a little longer but next week I suppose I can manage some tests too. until then I have another question: with regards to the great progress in precision syncing the cameras when shooting with the remote feature I wonder if it was possible to revise the usb sync in a similar way?

I am about to solder 50 mosfets into 200 cables, so I think it is time to ask if there is any hint that a similar precision is at the horizon for a bare usb-connection, maybe?  ::)
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: CHDK PTP multiple instances
« Reply #113 on: 15 / December / 2013, 00:15:03 »
Quote from: Karmaschinken on 14 / December / 2013, 20:08:54
with regards to the great progress in precision syncing the cameras when shooting with the remote feature I wonder if it was possible to revise the usb sync in a similar way?
Assuming you mean precision sync when the shooting is performed via software commands over ptp, then there is pretty much no chance that will work the way you want.

The current USB remote sync works because each camera sits and waits at a special point in the code for the USB 5V signal to change to 0V.  At that point, every camera is released to shoot at exactly the same time.  It seems very unlikely that any software command travelling over a ptp packet could be made to also cause such simultaneous shooting.

Sorry.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Karmaschinken

  • ***
  • 198
Re: CHDK PTP multiple instances
« Reply #114 on: 15 / December / 2013, 05:48:53 »
Yes, that was what I meant! :-) Okay then I have to solder a lot!

Nevertheless: wouldn't it be possible to use sort of "get_tick_count()" in the camera to make them shoot synced? If it was possible to once get a valid "tick" from the camera one could calculate some offsets, then send the command "shoot at tick XXX" to the cameras. I suppose the ticks inside the cameras are not all the same length because when waiting one or two weeks a former synced date/time clock differs some seconds. A year ago I was adjusting my cameras to the same time, now they differ by minutes.

So such a solution had to be calibrated somehow.  Well, probably just talking rubbish here. I will make the remote thing work.

But maybe someone having an  idea for another issue I have: When connecting 50 cameras to one computer via four 13-port-Hubs a download make some time, because of the speed of the computer itself and the hubs too. I have some questions here:

1. Is it possible to download images from multiple cameras at the same time or will I have to step through every camera and wait until download is completed with the one, then step over to the next and so on?

2. If this is not possible I am thinking to use multiple computers, e.g. 4 Asus EeePC or something like that, make them handle the USB download. This way I could divide the download time by four. But this would mean I would have to operate the camera parameters from 4 different computers. But I would love to be able to adjust all the camera parameters from ONE computer. Any idea for that maybe?

Best regards!
Logged
*

Offline ahull

  • *****
  • 634
Re: CHDK PTP multiple instances
« Reply #115 on: 15 / December / 2013, 07:38:16 »
You might be able to use some sort of real time clock synchronization algorithm to bring all of the Real Time Clock chips on the cameras in to line, in a manner similar to NTP. This would however require a bit of work to design and test.

A typical RTC in these devices normally runs on a 32768 Hz clock crystal, so that would be the limit of your time resolution.
Logged
*

Offline Karmaschinken

  • ***
  • 198
Re: CHDK PTP multiple instances
« Reply #116 on: 15 / December / 2013, 14:47:41 »
Hmmm... How should that be done? There is always the USB between me and the camera clock making it virtually impossible to sync the cameras. I suppose the USB-ports are very inconsistent when sending and receiving this and that. However it will be okay for me to build the remote func solution.

But I have another question. With CHDKPTP I use the command "lua" which makes the camera side of chdk start the command while the command line interpreter does not wait for the result. This way I can start some time consuming scripts on the different cameras nearly all at the same time. This is very good, otherwise I would have to wait for every single camera.

Now is there any way to download the JPGs in a similar manner? If that was possible I could start say three or four downloads at the same time, which might result in some speedier download time all in all.

Thanks a lot!
« Last Edit: 15 / December / 2013, 14:49:31 by Karmaschinken »
Logged
*

Offline andrew.stephens.754365

  • ****
  • 461
Re: CHDK PTP multiple instances
« Reply #117 on: 15 / December / 2013, 15:58:08 »
Quote from: Karmaschinken on 14 / December / 2013, 20:08:54
I am about to solder 50 mosfets into 200 cables, so I think it is time to ask if there is any hint that a similar precision is at the horizon for a bare usb-connection, maybe?  ::)

Just before you start that -

any chance [with complete hub network in place and no change to kbd.c] you [via chdkptp]

(i) start [on all cams] something like [but different] to waterwingz['s] script described here http://chdk.setepontos.com/index.php?topic=10837.msg106581#msg106581 

i.e.
set manual overrides (if desired) then
set_config_value( 121, 1 )   -- USB port disable then
loop waiting on 5V drop => capture image to SD then
set_config_value( 121, 0 )   -- USB port enable
end script

(ii) once the script has started on all cams, disconnect connection between pc and usb hub network

then

(iii) turn usb hub network power off [to capture image to sd]

then

(iv) reconnect hub network to PC

then

(v) turn usb hub network power on

then

(vi) via chdkptp script, connect to all cams and download images   

[it's been a lazy Sunday here, so I haven't been thinking about this much - so it may not help, but on the off chance it saves all those FET's / shift registers / arduino code etc, I thought i'd just make this very very lazy post in case it might help  ::)]

[Edit: fmi http://chdk.wikia.com/wiki/UBASIC/TutorialScratchpad get_tick_count => This function returns the time, in milliseconds, since the camera was turned on.]
« Last Edit: 16 / December / 2013, 07:43:04 by andrew.stephens.754365 »
Logged
*

Offline reyalp

  • ******
  • 14126
Re: CHDK PTP multiple instances
« Reply #118 on: 15 / December / 2013, 16:42:11 »
Quote from: Karmaschinken on 15 / December / 2013, 05:48:53
Nevertheless: wouldn't it be possible to use sort of "get_tick_count()" in the camera to make them shoot synced? If it was possible to once get a valid "tick" from the camera one could calculate some offsets, then send the command "shoot at tick XXX" to the cameras.
This is exactly what multicam.lua does, but the sync is quite bad because:
1) get_tick_count only works in 10ms increments
2) sleep only works in 10ms increments
3) when shooting from script (waiting for get_tick_count) the time between detecting the shot time and the shot actually shooting is variable by at least tens of ms.
4) my calibration code probably sucks
Logged
Don't forget what the H stands for.
*

Offline Karmaschinken

  • ***
  • 198
Re: CHDK PTP multiple instances
« Reply #119 on: 15 / December / 2013, 16:50:35 »
@ andrew:

Hello Andrew, actually this is  what I am building right now but I won't use a script waiting for the 5v drop but the remote function. I think it is much more accurate than a loop in a script. I had no problem changing the keyb.c as suggested by waterwingz. I tested that with one camera, at the moment I try to use the multicam.lua to adjust all the cameras from a single PC, works with three cameras now. Next week I will be ready to try with some mosfets (which will actually disconnect the usb-bus, as you suggested).

Thanks a lot for now! Martin

@ reyalp

Hmmm. Okay, although the 10ms might not be a barrier, as long as the "right" 10ms are triggered?

However, nice to meet you here, and thank you very much for your great work, I appreciate it very much.
Logged
Pages: 1 ... 7 8 9 10 11 [12] 13 14 15 16 17 ... 19   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal