Multi-camera setup project.

reyalp

14117

Re: Multi-camera setup project.

« Reply #50 on: 13 / July / 2014, 17:17:28 »

Advertisements

Quote from: mphx on 13 / July / 2014, 06:07:02

At syncing process , i noticed that the program went unresponsive for few secs at the middle of the process.
That happened to me before when i was testing 8 cameras , but after some syncing , then it went smoothly.
Today i hit 2-3 syncs just to see the behavior , but on all syncs , the "problem" remained.
No impact to the shooting as i see , since all cameras were mostly synced.
I thought to mention it in case that indicates some problem...

If you are using the chdkptp GUI, I would strongly suggest switching to the CLI for multicam. Start with chdkptp -i

If you were running init_sync in the GUI, long running operations can make windows show "unresponsive" This does not a problem own it's own.

I recommend using the CLI since timing may not be as good using the GUI, and I have noticed some problems with connections being dropped when you are using multiple cameras with the GUI. Also, I do almost all my development in the CLI, so it is more likely to be well behaved.

If you weren't running the GUI, then I'd need clarification of how it became unresponsive.

Logged

Don't forget what the H stands for.

mphx

210

Re: Multi-camera setup project.

« Reply #51 on: 13 / July / 2014, 17:47:08 »

@reyalp

Since there are some commands involved when handling multiple cameras...you know..start multicam , sync , preview mode , rec mode , download images , and all these commands again and again...i am bit bored typing in CLI

So i have made some buttons in the gui for more easy use of the commands.

When program was processing the sync timing of each camera ...it got "stuck"..probably operation took a bit longer at camera no 3.Then after like 5-6 seconds , messages in the console were shown all together..like something were holding them back.
Tried once , twice , three times...same thing at the same camera..
That had happened some days ago too, but after 2-3 syncs , all processing was smooth...

Anyways , there was no practical impact at the shooting.Although one camera at try no 1 , didn't shoot.At tries no 2 and no 3 all were smooth and ok.

« Last Edit: 13 / July / 2014, 18:41:41 by mphx »

Logged

reyalp

14117

Re: Multi-camera setup project.

« Reply #52 on: 13 / July / 2014, 18:50:32 »

Quote from: mphx on 13 / July / 2014, 17:47:08

@reyalp

Since there are some commands involved when handling multiple cameras...you know..start multicam , sync , preview mode , rec mode , download images , and all these commands again and again...i am bit bored typing in CLI
So i have made some buttons in the gui for more easy use of the commands.

That makes sense. FWIW, you could also make Lua functions or CLI commands that do this. I have never used the GUI with more than 3 cameras connected, so I wouldn't be confident that it will behave nicely with 64.

Quote

When program was processing the sync timing of each camera ...it got "stuck"..probably operation took a bit longer at camera no 3.Then after like 5-6 seconds , messages in the console were shown all together..like something were holding them back.

This sounds fairly normal. Long running calls block the GUI in some cases. This may vary depending on whether you are issuing the commands in the input box or using code directly from your buttons.

If for some reason things got hung up in the middle of an individual sync attempt, it could throw the timing off for that camera. In this case a line like

1:Canon PowerShot A540: send 10 diff 863 pred=51743 r=51750 delta=-6

would show a large delta.

Quote

Anyways , there was no practical impact at the shooting.Although one camera at try no 1 , didn't shoot.At tries no 2 and no 3 all were smooth and ok.

Shoot failing (where the camera never gets to the point it thinks it's ready to shoot) is something of a known issue. This may be more likely if you are in full auto mode (AUTO rather than P) or if the flash is enabled.

Another thing to watch out for with the GUI: By default, it polls all the available cameras cameras to update the camera dropdown. I don't think this should cause problems, because it runs in a timer that won't execute while something else is actually running, but if it does you can control with
set gui_dev_check_interval=<value>

0 will turn it off completely.

Logged

Don't forget what the H stands for.

Hardware_Hacker

322

Re: Multi-camera setup project.

« Reply #53 on: 13 / July / 2014, 20:55:19 »

Quote from: mphx on 12 / July / 2014, 12:58:56

I was seeing there some very complicated diagrams about the connections of the hubs etc.

I am guessing it wont work as i imagine right

Another Design Setup Point and another "...very complicated diagram..." A590IS-Current [5x7].png

This shows the current changes, with a little bit of artistic license, and the Multi-Camera Sync testing
concept but using 5x7 DMD's using two A590IS cameras as an example .

* The (Image) Sync Bar Graphs are different lengths because each camera is behaving slightly differently.
* The Cameras Current Spikes occur at different times because each camera is behaving slightly differently.

Note that the Sync Tester has different scan rates. The Image Bars are very short because a very low
scan rate was used for the example.

So, for 80 cameras in the array, and if the camera control is wired/connected as a "Rat's Nest"
these currents will interact, randomly, with the Multi-Camera Sync.

# Some cameras in the Array will see a Advanced Sync Pulse.
# Some cameras in the Array will see the Real Sync Pulse.
# Some cameras in the Array will see a Retarded Sync Pulse.
# Some cameras in the Array might occasionally see NO Sync Pulse. [But Very Unlikely]

This "Rat's Nest" and "Current Spike" effect is made much worse by using Battery Power Adapters.

Again see ( Post #27 by W-W) the link is here
http://chdk.setepontos.com/index.php?topic=11583.msg113516#msg113516

"...I'd spend the money on .... opto-couplers per camera (..., and USB 5V power) and let each camera "float" on its own.

Again see the response ( Post #28 by H-H) the link is here
http://chdk.setepontos.com/index.php?topic=11583.msg113517#msg113517

Also continued from Here
http://chdk.setepontos.com/index.php?topic=11583.msg113619#msg113619

Edit #1 Added Attack_Decay-05.png

Advanced Sync Pulse and Retarded Sync Pulse produced by"Rat's Nest" and "Current Spike"
effect is made much worse by using Battery Power Adapters.

H-H

"....I am guessing it wont work as i imagine right

...."

A590IS-Current [5x7].png (815.91 kB, 1200x600 - viewed 117 times.)

Attack_Decay-05.png (261.22 kB, 1405x388 - viewed 109 times.)

« Last Edit: 15 / July / 2014, 00:59:58 by Hardware_Hacker »

Logged

mphx

210

Re: Multi-camera setup project.

« Reply #54 on: 14 / July / 2014, 05:29:22 »

@Hardware_Hacker

Ok i got the point.It's not that easy as i thought

@reyalp

I created some lua scripts , containing the commands i am using in the buttons at GUI.
And used them through CLI.Everything worked as expected and syncing was pretty good (almost perfect judging from the online meter i used..but ye ye i know it's not an accurate method but variation of few msecs is acceptable for the project).
Ok it's a bit more work writing commands in CLI but i can live with it if that means more reliable conditions.

So for now i will stick to this "method" and see how it goes with more cameras , when we get the rest i mean

Logged

reyalp

14117

Re: Multi-camera setup project.

« Reply #55 on: 14 / July / 2014, 16:27:10 »

Quote from: mphx on 14 / July / 2014, 05:29:22

Ok it's a bit more work writing commands in CLI but i can live with it if that means more reliable conditions.

The GUI might work for you, there's just a lot more room for things to go wrong. In the long run, it would certainly be nice to have multicam controlled from the GUI.

If you want to share you code I can look into incorporating it into multicam.

Quote

So for now i will stick to this "method" and see how it goes with more cameras , when we get the rest i mean

Since it seems like this approach might be usable, I'll try to get serial number mapping / download stuff sorted out.

One thing to be aware of with multicam is that the time it takes to shoot will go up with the number of cameras. It works by sending a message to each cameras that says shoot at time X in the future, and sending the message to each camera takes a certain amount of time (there is no broadcast in PTP). The "minimum sync delay" listed after init_sync() is an estimate of this, although in practice you probably want to leave some head room. On my setup this seems to be about 4 ms/cam with Digic 4 cams, but I don't know if there will be additional overhead if you have a bunch of hubs and cams.

Logged

Don't forget what the H stands for.

Hardware_Hacker

322

Re: Multi-camera setup project.

« Reply #56 on: 14 / July / 2014, 16:34:44 »

Quote from: mphx on 14 / July / 2014, 05:29:22

@Hardware_Hacker
Ok i got the point.It's not that easy as i thought

For anyone that still haven't got the point and don't like "...very complicated diagrams..."

A much simpler explanation, using an array of 100 cameras and 100 cheap power adapters.

Lets say each camera uses 3 watts thats 300 watts supplied from the 100 cheap power adapters.

Starting with the case where array of 100 cameras is powered from the original canon battery's:-

* There is NO External (sneaky) available paths for the current's to flow through.
* The original canon battery has very low internal resistance.
* The Canon Battery management system works even when internal resistance rises.
* There are FCC compliance rules regarding (RF) escaped energy.

In the case of the 300 watts supplied from the 100 cheap power adapters.

* The Canon Battery management system works with cheap power adapters.
* The cheap power adapters probably have much higher internal resistance.
* There are multiple External (sneaky) available paths for the currents to flow through.
* Some Canon P&S cameras have a 1/4-20 Metal tripod mount.
* Via the USB-B cable connectors.
* Via the 100 cheap power adapters power cables.
* Via the Optional Battery third terminal Sync.
* Via other sneaky Common mode current paths, i.e. Restive, Magnetic, Capacitive Coupling.
* The sneak currents or escaped energy Causes very random effects as per prior posts.
* The 100 cheap power adapters are also a SOURCE of sneak currents.

Only a very small percentage of the original 300 watts will, in practice, will directly affect the Sync.
So let's say its 0.1% this is still very significant amount of sneak currents going through your
"Rats Nest" wiring which could have 100 or even 1000 times more "Electrical Length" than
a simple prototype rig with only a couple of cameras .

So the overall project aim is just to try to have some sort of control over the sneak currents.
And have some sort of control (plan) over the Common Sync wiring before construction starts.

Edit #1 attached Multi-Camera_Array_Concept [+Rats].png

This is the case when the Sync is hard wired to each camera in the array.
So the aim is to dissapate the energy in the Parallel Sync Pulse in a resistor at the
far end of the USB-2 +5 Volt Sync Wire. [when using USB-2 Hot-Plug]

* USB-2 Hot-Plug Parallel Sync Pulse will be faster, so there is less USB-Jitter effect.
* Less sneak currents or escaped energy will be picked up via the common mode noise.

Note That this applies also to Opto-Couplers. They have another issue to consider.
"Miller Effect", this is also helped by individual termination resistors, but at the cost of
sensitivity of the Opto-Couplers. see

http://en.wikipedia.org/wiki/Miller_effect

Edit #2

This one in series of post's in regard to Multi-Camera Arrays is also about what physical/scaling
effects that might/may become important a CHDK Multi-Camera Array Constructor.

I regard to USB-2 there is probably over a billion USB-2 devises in use, i.e. a well proven technology.

I regard to USB-2 Hot-Plug CHDK Remote Switching [Non-array] devises in use, may be well over
10,000 i.e. another well proven technology.

I regard to USB-2 Hot-Plug CHDK Remote Switching, for Large Camera Arrays, devises in use, might
be about 20. i.e. an emerging technology.

H-H

Edit #3 see Reply #59 by W-W ... [Fixed some stuff]

"...nobody has ever made it work...."

The Post is about "trying to make it work better" as you increase the number of cameras in the array.

Also "...describing here is a simple exercise in Ohm's law..."

The Post is really about "Reactance" effects as you increase the size and number of cameras in the array.
[ i.e. Restive, Magnetic, Capacitive Coupling.]
http://en.wikipedia.org/wiki/Electrical_reactance

Multi-Camera_Array_Concept [+Rats].png (1225.16 kB, 1250x1250 - viewed 106 times.)

« Last Edit: 15 / July / 2014, 01:07:52 by Hardware_Hacker »

Logged

mphx

210

Re: Multi-camera setup project.

« Reply #57 on: 14 / July / 2014, 17:31:37 »

Quote from: reyalp on 14 / July / 2014, 16:27:10

The GUI might work for you, there's just a lot more room for things to go wrong. In the long run, it would certainly be nice to have multicam controlled from the GUI.

If you want to share you code I can look into incorporating it into multicam.

Since it seems like this approach might be usable, I'll try to get serial number mapping / download stuff sorted out.

One thing to be aware of with multicam is that the time it takes to shoot will go up with the number of cameras. It works by sending a message to each cameras that says shoot at time X in the future, and sending the message to each camera takes a certain amount of time (there is no broadcast in PTP). The "minimum sync delay" listed after init_sync() is an estimate of this, although in practice you probably want to leave some head room. On my setup this seems to be about 4 ms/cam with Digic 4 cams, but I don't know if there will be additional overhead if you have a bunch of hubs and cams.

Till now i haven't done anything fancy. As far as GUI is concerned i have made an additional TAB (i called it "multicam") and i created some buttons there .Buttons that at the bottom line execute multicam.lua commands ( start/connect , sync , rec mode , preview mode , shutdown all , exit , download last).For fast management on multiple cameras.
I had an "argument" with my project-partner about gui vs cli.I told him that cli is a bit more "typing" but more reliable while gui/buttons are more user friendly and less reliable (as far as sync is concerned , all other commands are working great) ..
He definitely wants gui and buttons.He is even trying to "skip" sync process if that means less potential trouble in the whole process.Told him that it will be risky and stupid to skip sync at all.
With your last paragraph you put a new parameter in the play i didn't think/consider/know.We have to consider it too.

Things i'd like to see in multicam.

1.Download stuff- Downloading last images works great.The folder naming could be tweaked a bit.In two ways.
First before creating each cameras' folder (named as i can understand from their increasing number e.g. 1,2,3,4,5...) it could create a parent folder e.g. shoot1 and create cameras' subfolders in it.That implies that it has to check for available increasing numbers for the naming.
Waterwingz has done something like this with his scripts.
Also i don't know if serial number mapping is easy but if these folders had their names from the first x numbers of the serials then photos or the folders themselves can be easily manipulated through batch scripts.
I mean instead of naming these folders like 1,2,3,4,5,6... lets name them e.g. 0ACEC43 (part of the serial number).Then a batch script can easily map them with a database of serials and rename photos like cam1-img001.jpg for instance.And put them in one common folder.
Lastly for the download issue i would like to see download ALL and some deleting command

I don't know what can be done with lua , so i just throw ideas.

2.The thing we were talking about issuing sync timings through a file.You know , hit 10-15 syncs..take the average of the timings and then issue them through some commands or something.Don't know if this is possible , but if sync needs like 10-12 secs for 8 cameras , i believe for 64 will be ~80 secs , that's like 1,5min.
Not looking good

3. Some big font in camera's display to state its number?As a result of some serial mapping if this is possible to be done.

P.S. : Did some testing without syncing on the cameras.They were rather synced all of them.As much as i can tell from my lame online-testing method.But i believe 64 without syncing will be a bit mess at the best.So syncing process must be sorted out to be fast and accurate as much as it can be done.

« Last Edit: 14 / July / 2014, 17:34:42 by mphx »

Logged

Microfunguy

4037

Re: Multi-camera setup project.

« Reply #58 on: 14 / July / 2014, 18:29:18 »

Well, I like an easy life.

For my outdoor rig I will power them with multiple lead-acid batteries and use a simple USB remote switch, no hubs needed.
Back home, I will connect each group of eight via a hub to the PC and switch them to Playback one-by-one.
The images will be automatically downloaded to numbered folders without using PTP.

If I ever need anything more complicated, which is unlikely, I will just use CHDK if I am too lazy to spend more time on my command-line application.

Logged

waterwingz

12140

Re: Multi-camera setup project.

« Reply #59 on: 14 / July / 2014, 20:45:23 »

Quote from: Hardware_Hacker on 14 / July / 2014, 16:34:44

* There is NO External (sneaky) available path for the 300 watts to flow through.

This is nonsense. Watts are a measure of power dissipation - they do not "flow" or "sneak" around. Current flows and is measured in amps.

What you are describing here is a simple exercise in Ohm's law where you have multiple power sources. If the DC side of the power sources all use a common (low resistance) grounding point there is no issue. That simply comes down to a large enough conductor and good bonding to minimize "Electrical Length".

If the power supplies have any significant leakage from the AC side then that's an electrical safety issue regardless of whether you use one or fifty. Grounding the DC side will eliminate "floating" voltage levels the can potentially product very low energy sparks.

Noise pickup on the USB 5V signal line is a potential problem which will depend on sources of high frequence noise in the immediate environment. However, as you point out, it can be mitigated by a suitable termination resistor at the end to each USB cable set.

This is not that hard - reading your description is enough to suggest this project cannot be done and that nobody has ever made it work.

Sorry to be blunt here.

« Last Edit: 14 / July / 2014, 21:23:37 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16