Camera Synchronization - Revision history

Polto at 20:48, 22 September 2008

2008-09-22T20:48:42Z

← Older revision		Revision as of 20:48, 22 September 2008
Line 1:		Line 1:
			=Introduction=

	There are several parts of the camera synchronization task.		There are several parts of the camera synchronization task.
	# Camera should receive synchronizing event. It can be done by either special '''hardware inputs''' or just over the '''network'''. It most cases if you want to ~~syncronize~~ 2 or more networked cameras you do not need extra wires, so the network ~~sycnchronizatrion~~ is the most ~~convinient~~. But sometimes you would like to be able to trigger the camera without the network - i.e. from some contact closure.		* Camera should receive synchronizing event. It can be done by either special '''hardware inputs''' or just over the '''network'''. In most cases if you want to synchronize 2 or more networked cameras you do not need extra wires, so the network synchronization is the most convenient. But sometimes you would like to be able to trigger the camera without the network - i.e. from some contact closure.
	# Camera should be able to start image acquisition process when required - generally not possible with most CMOS sensors. ~~''/this used with "external trigger" in FPGA API? - Spectr/''~~		* Camera should be able to start image acquisition process when required - generally not possible with most CMOS sensors.
	# And (in some cases) camera should be able to precisely keep time, so in-sync state of two or more cameras will last longer.		* And (in some cases) camera should be able to precisely keep time, so in-sync state of two or more cameras will last longer.

			=Network synchronization=
			Here is a [https://sourceforge.net/forum/forum.php?thread_id=1068147&forum_id=371579 Thread on sf] about synchronizing two 313 cameras using [http://mhonarc.axis.se/dev-etrax/msg02121.html sntpdate client]: Network synchronizing the cameras ended up being incredibly simple, I didn't have to do anything special at all. I decided to try the easiest solution first, keeping the 2 cameras at the exact same settings. I had the client I wrote request image captures from both cameras at approx. the same time. I haven't benchmarked it to see the exact amount of jitter between matching frames, but I can set FPS to any value and not see any noticeable difference. (Should be 1-2ms jitter with a good network. --[[User:Polto\|Alexandre.Poltorak]] 15:48, 22 September 2008 (CDT))

			=Hardware synchronization=
			We have now hardware synchronization capability allowing 1μs jitter between images as well as external trigger.

	~~Here is a~~ [~~https://sourceforge.net/forum/forum.php?thread_id=1068147&forum_id=371579 Thread on sf~~] ~~about synchronizing two 313 cameras using [http://mhonarc.axis.se/dev-etrax/msg02121.html sntpdate client~~]~~: "Synchronizing~~ the ~~cameras ended up being incredibly simple~~, ~~I didn't have to do anything special at all~~. ~~I decided to try the easiest solution~~ first~~, keeping~~ the ~~2 cameras at~~ the ~~exact same settings~~. ~~I had the client I wrote request image captures from both~~ cameras ~~at approx.~~ the same ~~time. I havn't benchmarked it to see the exact amount of jitter between matching frames, but I can set FPS to any value~~ and ~~not see any noticable difference~~."		The [[353 \| NC353L]] camera have the FPGA code allowing the camera synchronization, but an additional board is needed. The first board allowing the use of hardware synchronization commercialized by Elphel is the [[10369 \| 10369 IO extension board]]. The board have internal synchronization connectors for cameras mounted in the same camera case and wired internally and an external modular RJ11 opto-isolated connector.

	~~How about~~ a ~~digital phase locked loop using~~ the ~~[[RTC]] timer in~~ the ~~FPGA? NTP is basically a digital phase locked loop in software, but it also adds a lot of code for robustness against~~ "~~malicious~~" ~~NTP servers - something we probably don't~~ need ~~for~~ the ~~cameras --[[User:Pfavr\|Pfavr]] 15:15, 27 October 2005 (CDT)~~		You can have several cameras in a so called "slave" mode waiting to receive the trigger and one camera (or any other device) serving as master. To trigger the image from all cameras the "master" device need to send a 5v impulse on the synchronization cable.

Pfavr: summary of the discussion so far

2005-10-27T20:15:21Z

summary of the discussion so far

← Older revision		Revision as of 20:15, 27 October 2005
Line 4:		Line 4:
	# And (in some cases) camera should be able to precisely keep time, so in-sync state of two or more cameras will last longer.		# And (in some cases) camera should be able to precisely keep time, so in-sync state of two or more cameras will last longer.

	~~How~~ about ~~something like ntp - network time protocol? --[~~[~~User~~:~~Pfavr\|Pfavr~~]~~] 16~~:15, ~~26 October 2005 (CDT)~~		Here is a [https://sourceforge.net/forum/forum.php?thread_id=1068147&forum_id=371579 Thread on sf] about synchronizing two 313 cameras using [http://mhonarc.axis.se/dev-etrax/msg02121.html sntpdate client]: "Synchronizing the cameras ended up being incredibly simple, I didn't have to do anything special at all. I decided to try the easiest solution first, keeping the 2 cameras at the exact same settings. I had the client I wrote request image captures from both cameras at approx. the same time. I havn't benchmarked it to see the exact amount of jitter between matching frames, but I can set FPS to any value and not see any noticable difference."

	~~I believe they used something like that here -~~ [~~http://www.kipr.org/papers/cmech-is05.pdf pdf article~~] ~~([https://sourceforge.net/forum/forum.php~~?~~thread_id=1068147&forum_id=371579 sf discussion])~~--[[User:~~Andrey.filippov~~\|~~Andrey.filippov~~]] 17:14, 26 October 2005 (CDT)		How about a digital phase locked loop using the [[RTC]] timer in the FPGA? NTP is basically a digital phase locked loop in software, but it also adds a lot of code for robustness against "malicious" NTP servers - something we probably don't need for the cameras --[[User:Pfavr\|Pfavr]] 15:15, 27 October 2005 (CDT)

Andrey.filippov at 22:14, 26 October 2005

2005-10-26T22:14:20Z

← Older revision		Revision as of 22:14, 26 October 2005
Line 5:		Line 5:

	How about something like ntp - network time protocol? --[[User:Pfavr\|Pfavr]] 16:15, 26 October 2005 (CDT)		How about something like ntp - network time protocol? --[[User:Pfavr\|Pfavr]] 16:15, 26 October 2005 (CDT)

			I believe they used something like that here - [http://www.kipr.org/papers/cmech-is05.pdf pdf article] ([https://sourceforge.net/forum/forum.php?thread_id=1068147&forum_id=371579 sf discussion])--[[User:Andrey.filippov\|Andrey.filippov]] 17:14, 26 October 2005 (CDT)

Pfavr at 21:15, 26 October 2005

2005-10-26T21:15:33Z

← Older revision		Revision as of 21:15, 26 October 2005
Line 3:		Line 3:
	# Camera should be able to start image acquisition process when required - generally not possible with most CMOS sensors. ''/this used with "external trigger" in FPGA API? - Spectr/''		# Camera should be able to start image acquisition process when required - generally not possible with most CMOS sensors. ''/this used with "external trigger" in FPGA API? - Spectr/''
	# And (in some cases) camera should be able to precisely keep time, so in-sync state of two or more cameras will last longer.		# And (in some cases) camera should be able to precisely keep time, so in-sync state of two or more cameras will last longer.

			How about something like ntp - network time protocol? --[[User:Pfavr\|Pfavr]] 16:15, 26 October 2005 (CDT)

85.202.183.226 at 02:11, 21 October 2005

2005-10-21T02:11:02Z

← Older revision		Revision as of 02:11, 21 October 2005
Line 1:		Line 1:
	There are several parts of the camera synchronization task.		There are several parts of the camera synchronization task.
	# Camera should receive synchronizing event. It can be done by either special '''hardware inputs''' or just over the '''network'''. It most cases if you want to syncronize 2 or more networked cameras you do not need extra wires, so the network sycnchronizatrion is the most convinient. But sometimes you would like to be able to trigger the camera without the network - i.e. from some contact closure.		# Camera should receive synchronizing event. It can be done by either special '''hardware inputs''' or just over the '''network'''. It most cases if you want to syncronize 2 or more networked cameras you do not need extra wires, so the network sycnchronizatrion is the most convinient. But sometimes you would like to be able to trigger the camera without the network - i.e. from some contact closure.
	# Camera should be able to start image acquisition process when required - generally not possible with most CMOS sensors.		# Camera should be able to start image acquisition process when required - generally not possible with most CMOS sensors. ''/this used with "external trigger" in FPGA API? - Spectr/''
	# And (in some cases) camera should be able to precisely keep time, so in-sync state of two or more cameras will last longer.		# And (in some cases) camera should be able to precisely keep time, so in-sync state of two or more cameras will last longer.

Andrey.filippov at 20:25, 20 October 2005

2005-10-20T20:25:36Z

New page

There are several parts of the camera synchronization task.
# Camera should receive synchronizing event. It can be done by either special '''hardware inputs''' or just over the '''network'''. It most cases if you want to syncronize 2 or more networked cameras you do not need extra wires, so the network sycnchronizatrion is the most convinient. But sometimes you would like to be able to trigger the camera without the network - i.e. from some contact closure.
# Camera should be able to start image acquisition process when required - generally not possible with most CMOS sensors.
# And (in some cases) camera should be able to precisely keep time, so in-sync state of two or more cameras will last longer.