sync'ing 3D video - page 6 - Creative Uses of CHDK - CHDK Forum  
« previous next »
Pages: 1 2 3 4 5 [6] 7 8 9 10 11   Go Down

sync'ing 3D video

  • 103 Replies
  • 37622 Views
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: sync'ing 3D video
« Reply #50 on: 27 / June / 2013, 18:13:24 »
Advertisements
"IC2002 CDS A/D TG AD9923BBCZ" just describes the chip as an analogue-to-digital converter that uses correlated double sampling and contains a timing generator for creation of all the CCD control signals.

In video mode, with SDM, while the USB switch is pressed I now flash the AF led in phase with LiveView period counter.

I will look at it on the 'scope.

You would not think the phase or frequency of that signal changes when recording actually starts on switch release.
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: sync'ing 3D video
« Reply #51 on: 27 / June / 2013, 18:39:52 »
At 640x480 I get a 30Hz square wave and at 1280x720 I get a 24Hz square wave.
I need to make a second photo sensor assembly tomorrow.

Now, by half pressing on one camera I could increase the LiveView period slightly at intervals for one cycle and maybe drift the two waveforms into synch.

Surely that must improve shooting synch ?

Logged
*

Offline Hardware_Hacker

  • ****
  • 322
Re: sync'ing 3D video
« Reply #52 on: 28 / June / 2013, 03:33:09 »
Hi All!,

---=== sync'ing 3D video ===---
A summary of my current wip.

---=== Key Concepts ===---
The H-H "Pre-Set"/"Re-Set" sync/initalation concept.
Man in the Middle concept.

---=== Un-Posted ===---
1/ Canon Legacy-Serial discoveries.
2/ Canon HDMI discoveries.
3/ Concept Graphics.
4/ Mode Map CHDK tests/updates.
5/ AF_Led CHDK tests/updates.
6/ Aspect Ratio CHDK tests/updates
7/ HDMI-Hardware "Hacks".
8/ Unique CHDK Multi-Cam Drivers for Xp, Vista, Win-7/8; CHDK-PtP tests/updates.
9/ Non-Rotating 360x180 3D P&S Multi-Camera Array.

---=== IDEA! Sync Mk1 ===---
1/ Legacy Compatible, Simple, Cheap, No/Some extra Hardware.
2/ Problems; Camera system Clock Drift, USB jitter, Camera Lag, A Camera Resource Hog, Slow, Lacks Intra-Camera communications.
3/ Canon's USB-HotPlug detection, hardware, is subject to change "With-Out Notice". [i.e. Camera Model dependant]
4/ Assumes availability of Sd-Tv Vertical Sync. Thus HD-Tv may be un-available.

---=== IDEA! Sync Mk1a ===---
1/ Intra-Camera communications via Legacy "Serial" internal-port.
2/ Intra-Camera communications via USB (or puseo-printer ?).
3/ Attempts to "Reduce" USB jitter via Legacy "Serial" internal-port.

---=== IDEA! Sync Mk1b ===---
1/ Problems; Intra-Camera communications via Legacy "Serial" internal-port, implies/means dissassembly of the cameras.
2/ Why not just "Hardwire" the cameras Power-On/Half/Shoot/buttons to a sutible connector, ???, and solve the Sync/USB jitter problem.
3/ Problems; Camera Drift, Camera Lag, Sd-Card lag, and Buffer-Full loss of Sync,

---=== IDEA! Sync Mk2a ===---
1/ Legacy Compatible, more complex, more expensive, extra Hardware required.
2/ Problems; Slow, Uses the Man in the Middle concept.
3/ Attempts to "Reduce" camera system Clock Drift, USB jitter, Camera Lag.

---=== IDEA! Sync Mk3 ===---
1/ Legacy In-Compatible, much more complex, much more expensive, much more extra Hardware required.
2/ Uses HDMI Cameras, Uses the Man in the Middle concept, much faster, modular, epandable, flexible.
3/ Problems; CHDK-HDMI hacks required, Additional software required.
4/ Attempts to "Reduce" camera system Clock Drift, USB jitter, and Camera Lag, via HDMI "Control".
6/ HDMI is Video Play-Back only, Live View is Un-supported, however, HDMI "Control" supports a "Rich" set of commands.
7/ Utilises Lua and PtP.

---=== HDMI! Mk3 & Good News ===---
1/ HDMI is "Standardised" and subject to change with "Notice".
2/ CHDK-HDMI hack required; There is not a lot of code in the ROM Dumps I have looked at.
3/ CHDK-HDMI hack required; A lot of code in the ROM Dumps appear to be similar.
4/ CHDK-HDMI hack required; Some cameras appear to have "Missing Link" HDMI code. [ i.e. Tx and Rx]
5/ Lots of interest in HDMI-Hacking according to Mr. Google.
6/ Some HDMI-Hardware hacks are simple and cheap.

---=== Comments! or Ideas! ===---

! sync'ing 3D video !

Is there something missing!.
Is there something confusing!.
Is there something wrong!.

Is HDMI worth revisiting!.

"..!.. this project is "dead!" before it starts ..!.."

David!,,,,,,, Anyone!.

---=== .!. ===--- 

Happy-Hacking By  H-H

Every "Sync" method will have, some, advantages and dis-advantages.
« Last Edit: 28 / June / 2013, 03:36:17 by Hardware_Hacker »
Logged
*

Offline Hardware_Hacker

  • ****
  • 322
Re: sync'ing 3D video
« Reply #53 on: 28 / June / 2013, 04:11:45 »
Quote from: Microfunguy on 27 / June / 2013, 16:44:42
Quote from: ahull on 27 / June / 2013, 16:03:04
We need to find the routines that talk to this three wire interface, and configure SSG
  • and SSG [1]
Try searching for I2C, I think I have seen it previously.


---=== Un-Posted ===---

2/ Canon HDMI discoveries. I2C

Would you be interested in me posting it, in a day or so.

There is not a lot of code in the ROM Dumps I have looked at.

Happy-Hacking By  H-H
« Last Edit: 28 / June / 2013, 04:14:09 by Hardware_Hacker »
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: sync'ing 3D video
« Reply #54 on: 28 / June / 2013, 18:08:12 »
Quote from: Microfunguy on 27 / June / 2013, 18:39:52
I need to make a second photo sensor assembly tomorrow.
Now, by half pressing on one camera I could increase the LiveView period slightly at intervals for one cycle and maybe drift the two waveforms into synch.

I have now added the second sensor and by pressing the USB remote switch can indeed drift the two signals into phase.

i now need to add some sort of circuit that will display this.
maybe something as simple as an exclusive-OR gate driving an led ?
The led would turn off when the signals are in phase (or be extremely dim as one signal is a different frequency by a minute amount).
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: sync'ing 3D video
« Reply #55 on: 28 / June / 2013, 18:13:06 »
Quote from: Hardware_Hacker on 28 / June / 2013, 04:11:45

"..!.. this project is "dead!" before it starts ..!.."

David!,,,,,,, Anyone!.
2/ Canon HDMI discoveries. I2C

Would you be interested in me posting it, in a day or so.

There is not a lot of code in the ROM Dumps I have looked at.


I for one would be interested in all the things you are doing.
When you have time, you need to explain each one in more detail.
It is difficult to understand what some of the topics above refer to.


David
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: sync'ing 3D video
« Reply #56 on: 28 / June / 2013, 18:27:31 »
Quote from: Microfunguy on 28 / June / 2013, 18:08:12
I have now added the second sensor and by pressing the USB remote switch can indeed drift the two signals into phase.
I must have not understood something in this thread.  What do you use that tells you the two signals are drifting into phase ? Your oscilloscope?
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: sync'ing 3D video
« Reply #57 on: 28 / June / 2013, 18:54:38 »
Quote from: waterwingz on 28 / June / 2013, 18:27:31
What do you use that tells you the two signals are drifting into phase ? Your oscilloscope?

Yes, the good old Rigol DS1052E.

Imagine the two sets of square waves are applied to the bases of two transistors.
The transistor collectors each have a 2k resistor to +12V.
Two leds in parallel ,but opposite orientation, are connected between the two collectors.
In the final version it will be a bicolour red/green led.
When signals are out of phase, one of the led's will be lit to some degree.
The brightness will fade to almost zero and then increase on the other transistor.
When the signals are in phase, no led will be lit  .. or maybe just very slightly.

That should work, I will do that tomorrow.

« Last Edit: 28 / June / 2013, 19:19:01 by Microfunguy »
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: sync'ing 3D video
« Reply #58 on: 28 / June / 2013, 22:34:58 »
Quote from: Microfunguy on 28 / June / 2013, 18:54:38
Imagine the two sets of square waves are applied to the bases of two transistors. The transistor collectors each have a 2k resistor to +12V. Two leds in parallel ,but opposite orientation, are connected between the two collectors.
In the final version it will be a bicolour red/green led. When signals are out of phase, one of the led's will be lit to some degree. The brightness will fade to almost zero and then increase on the other transistor.
When the signals are in phase, no led will be lit  .. or maybe just very slightly. That should work, I will do that tomorrow.
Hey,  the 1970's are calling and they want their 2N2222's back.   8)

If that works tomorrow,  a $6 aurdino clone board the size of a Canadian Loonie is just around the corner to automate the process.

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Hardware_Hacker

  • ****
  • 322
Re: sync'ing 3D video
« Reply #59 on: 29 / June / 2013, 01:22:51 »
Hi All, Digital-Dreamers & David,

Re:- "....maybe drift..."

The key concepts here  "Trying to Control" these complicated Events and the "Speed of Control".

You are, in effect trying to re-invent the wheel [or a DC Motor Servo System, see below]
Just as well this is not a forum-topic on Rockets, your ["1860's"] rocket would be off course most of the time, plenty of time to crash before you managed to be on course!

Although not involved with rockets I was lucky to be involved with Industrial and Telecom projects using Servo/Phase Detectors.

Back to Some more practical Examples:-:-
Baldour had a trade show demo of twin 100 watt servo motors, that had metal Disk attached to the motor shafts.

The disks had one slot that was slightly wider than the thickness of the disks.

The motors were then mounted at right angles so that the disks were "Egg Crated" i.e. inter-connected. or "LOCKED".

Each Motor would, in turn, gracefully accelerate to full speed and then decelerate, stop so that the disk were again "Egg Created"

When the motors stopped, any attempt to manually rotate the disk on either motor, would be vigorously defended and accompanied by a growing sound.

The Motors also had a incremental encoder attached to the other end of the shaft, the encoder had a extra, absoloute, channel that aligned exactly with the disk's slot.

The Baldour Motor's #1,-#2 used dual-channel incremental phase detection, A#1_B#1 and A#2_B#2.
The dual-channel incremental phase detectors are 90 deqrees apart so speed/direction can be determined.
And also had single-channel Absolute position detection for Motor's #1,-#2, C#1 and C#2.

Quote:-

"....Now, by half pressing on one camera I could increase the LiveView period slightly at intervals for one cycle and .... maybe drift...... the two waveforms into synch...."
"......Surely that must improve shooting synch ?...."

My ["1960's"] rocket, using a modern High speed "Triple" channel control system [see below] has a much better chance of being on target.

But, back to ["2013"] Twined cameras attempting to sync 3D video you could try a similar "Triple", difference, technique:-

The man in the middle-controller, is #0, has Common-Reference inputs A#0=A#1=A#2, the "incremental" Camera inputs are B#1 and B#2.

A 625x improvement in "incremental" comparison speed can be achieved just by using Horizontal sync for [Pal-Sd-Tv] for #1/#2/A/B.

Phase Advance/Retard is achieved by Pal/Ntsc/24/30/120/240 mode-change [mode-change delay is ignored for this example]

The "Incremental" A/B comparison is only used to estimate the Phase Advance/Retard "Rate" of pseudo-control. ["maybe-drift" = Controlled-drift]

Phase Advance/Retard, /120/240 mode-changes, if available, are used for Fast/Slow control. [Mode-change-Video /120/240 to still/mode seems to work, when tested when looking at Tv-News]

Absolute channels is the Vertical-Sync for cameras, #1-#2, are C#1/C#2.

The man in the middle-controller, has Absolute-Common-Reference C#0, the "Absolute" Camera inputs are C#1 and C#2.
The Aim is to have C#1 = C#2 and = C#0.

In practice this is not going to happen. ["maybe-drift" ~ Controlled-drift]
So the aim would be to attempt to continuously minimise C#0 ~ C#1 ~ C2.

By some sort of successive approximation technique could then approach/maintain 3D-video-sync much faster.

You still need to consider Camera-Key-Polling, Mode-Delay, USB-Jitter and Camera-Lag for pseudo-stable 3D Video sync/gen-lock.

Happy-Hacking By  H-H

but please keep up the good work for sync'ing 3D video.

Every "Sync" method will have, some, advantages and dis-advantages. 
Logged
Pages: 1 2 3 4 5 [6] 7 8 9 10 11   Go Up
« previous next »
 

Related Topics
SimplePortal 2.3.6 © 2008-2014, SimplePortal