ElphelWiki - User contributions [en]

User:Polto

2009-04-14T00:33:12Z

Oscar: /* Mobile camera with a 12v Traco DC/DC and a LiPo battery */

= testing =
This section list different tests I am doing. The goal of this section is to describe my tests, list the results and get others to participate.

Please feel free to comment this pages, then needed in the discussion tub.

== [[10359_in_dual_sensor_setup]] ==

== Mobile camera with a 12v Traco DC/DC and a LiPo battery ==

Example of a LiPo battery with improvised enclosure and LiPo saver LED (will light up when the battery reaches 9v (3v per cell). This is because LiPo must not be discharged under 2.5v per cell.)

[[Image:DSC_0001.jpg|200px|abc]]
[[Image:LiPo-LED.jpg|200px|abc]]

Test results will follow... [oscar]

User:Polto

2009-04-14T00:09:15Z

Oscar: /* Mobile camera with a 12v Traco DC/DC and a LiPo battery */

File:LiPo-LED.jpg

2009-04-14T00:05:31Z

Oscar: LiPo battery with safety LED

LiPo battery with safety LED

File:DSC 0001.jpg

2009-04-14T00:01:03Z

Oscar: LiPo with enclosure.

LiPo with enclosure.

File:BasePlate-rods(compact.jpg

2009-04-10T15:41:03Z

Oscar:

2009-03-20T00:59:26Z

Oscar: /* Designs for rod support */

== About this site ==

This page is created to develop elphel digital cinema cameras.

<code>Are we talking about a revolution? Maybe, or maybe we are only dreamers, but it's cool to be a dreamer with a revolution in mind! :-)</code>

== History ==

The cinema camera idea started in the first part of 2006 in the mind of a member of the [http://dvinfo.net/conf/index.php dvinfo] forum, and in March 26th 2006 01:46 AM, FS (I don't use the real name for privacy... FS if you want you can edit the page) started a new thread called [http://dvinfo.net/conf/showthread.php?t=63677 High Definition with Elphel model 333 camera].
Around one year later that thread had more than 400 responses, at the moment we are close to breaking the 1.000th reply barrier, so searching through them to find good information can be difficult.

This page was born to try to solve that problem. Andrey said to us: "We need to organize data more like a FAQ - the thread is so big." So here we go.

== Model 333 cameras==

=== info about elphel 333 ===

Here are some important links to understand what we have already.

- [http://www3.elphel.com/en/products model 333 general specification]

- how the camera works article [http://linuxdevices.com/articles/AT5951285077.html AJAX, LAMP, and liveDVD for a Linux-based camera] on [http://linuxdevices.com linuxdevices.com]

- all the software that you need to use the camera [https://sourceforge.net/projects/elphel sourceforge.net]

- the [http://developer.axis.com/ link] to Axis developer's site

- some video and images from the camera [http://community.elphel.com/videos/ on elphel's community videos], [http://www.elphel.com/3fhlo/ on elphel.com], on [http://www.tacx-video.com/images/HD2006/ tacx-video.com] and a [http://www.tacx-video.com/raw-demo/RothTri-333Raw-mjpeg.avi video] by PS, the [http://i11.photobucket.com/albums/a162/vericetti/beard1.jpg first image] taken from FS with not the best conditions, a low ligth 35mm adapter [http://s09.picshome.com/d35/comp_1__0-00-30-00_.jpg test] and one significant test example of dof from OS

<center>[[Image:35mmroof5.jpg|400px|abc]]</center>

- Example of a cinema camera setup by (D.L) ...and some result with it [http://wiki.elphel.com/index.php?title=Image:Txt.jpg text test], [http://wiki.elphel.com/index.php?title=Image:V8_Dof_test.jpg Bottle D.o.f. test]

<center>[[Image:333 hd setup.jpg|400px|abc]]</center>

and good example of what this setup could do:

<gallery>
Image:DLmoviegrab1.jpg
Image:DLmoviegrabpaint.jpg
Image:DLmoviegrab2.jpg
</gallery>

==MOVIES==

- May 18th, 2007, 09:28 PM - first short made with the elphel 333 hd camera + 35mm wax adapter by O.S. using that setup:

[[Image:Elphel35mmTripod.jpg|200px|abc]]

The autor said:

"Here is a small version of the 'documentary' I made in France. While my girlfriend was working all day in the garden making a path.... I was testing all aspects of the Elphel. Yes, between some shots I helped her a bit, but filmmaking comes first, right?

This short film also proves you can synch a separate audio recording, using the old method with a clap board (in this case I just clapped my hands and said the take number, the same as the Elphel output filename)
I used a portable minidisc recorder and it really worked fine.
I also used the wax adapter (which really needs to be rebuild to get rid of soft edges), and a 'big' Panasonic TV lens (notice some telephoto close ups of the flowers).

The clip is reduced by half in resolution to upload, and is just a rough cut without color adjustments and some faults in the editing. I'll probably upload the final version at normal resolution of 1600x900 pixels and less compression.
I'll post some stills at full size soon.

You can download the (54MB) file here: http://community.elphel.com/videos/RomainSurMeuse2.avi (it's in Xvid compression)"

or the full resolution version Xvid (200MB): http://community.elphel.com/videos/RomainFULL.avi

== The new cameras==

The new 353 cameras have better specs than 333 and are already available.
Here is a fast FAQ:

To better understand how the new hardware works, look at this article on [http://linuxdevices.com/ linuxdevices.com]: [http://linuxdevices.com/articles/AT4415936647.html High Resolution Cameras for Web Developers]

'''1. What sensors are available for the 353?'''

Quoted from [[353]]:
* Aptina 5MP 1/2.5" Sensor
* Kodak 11MP Full Frame Sensor
* Kodak 16MP Full Frame Sensor

'''2. Is it be possible to record video to a hard drive ?'''

With interface board [[10369]] it is possible to write video to SATA HDD or Compact Flash Cards (2 slots). From the software side a tool called camogm takes care of the recording.

'''3. What format will the recorded data have?'''

[[Camogm]] can record video as quicktime *.mov (MJPEG compression), Ogg Theora *.ogm or as JPEG sequence (even with exif data like geotags).

'''4. What frame rates / image sizes can be selected?'''

In general the chips window (only an area of the chip is be used for recording) can be freely modified. The lower the resolution the higher the possible framerate.

HD Standards:
* 1920x1080p (1920x1088 windowed chip) max. 25.24fps
* 1280x720p (1/2 binning 1280x720 full frame chip) max. 46.18fps
* 1280x720p (1280x720 windowed chip) max. 57.91fps

DV Standards (caution: square pixels):

* 640x480p (4:3 windowed chip) max. 126.11fps
* 854x480p (16:9 864x480 windowed chip) max. 110.13fps
* 640x480p(1/3 binning full frame chip) max. 81.95fps

* 720x576p (4:3 windowed chip) max. 100.36fps
* 720x576p (1/3 binning full frame chip) max. 66.36fps
* 1024x576p (16:9 windowed chip) max. 84.53fps

'''5. If it needs custom programming, where do I find info about tools / language etc? Just need a pointer. Any free compilers?'''

To be able to do development for these cameras you do not need any expensive (or even non-free-as-in-beer) tools. There are 3 levels (not to count client/PC software)
1 - "Web design" - developing of custom user interface - just any web design tools - you can FTP results to the camera
2 - Software applications to run in the camera - you need a PC running GNU/Linux (any flavor) and software from our Sourceforge project page plus additional - from http://developer.axis.com - our software will tell you what to download.
3 - FPGa code development - free (for download) tools from Xilinx - http://www.xilinx.com/ise/logic_design_prod/webpack.htm

'''6. Does the camera casing have space to accommodate a small hard drive?'''

Yes, or CF card.

'''7. Any idea of power requirements?'''

Model 333 needs a little under 3W. 353 should need about the same - not to count additional modules - hard drive or flash.

'''8. Does the camera have a C mount?'''

CS-mount as it is more universal for cameras - you can install both C and CS lenses

'''9. If I use a simple SLR mount (Nikon or Canon) to C mount adapter (instead of a ground glass solution), what lens multiplier would be in effect?'''

That depends on particular sensor that will be used - each sensor usually has info on the Internet.

'''
11. What does the 353 camera and sensor cost?'''

The same as our previous model had cost: [http://www3.elphel.com/price_list Pricelist]

'''12. Some more details about the 5MP Sensor?'''

The Aptina 5MP Sensor has a physical size of 5.70mm(H) x 4.28mm(V). Optical format is 1/2.5". But considering that the window of a full HD output only uses around 75% of the chips width the depth of field should be pretty much the same as using a 1/3" prosumer camcorder like the Panasonic HVX200, Sony FX-1 or Canons XL-H1. Aptina claims that the chip has 70db of dynamic range at full resolution and 76db when using 1/2 binning. It outputs 12-bit color data (elphel boards reduces these to 8bit in FPGA? please confirm). It might be possible to overclock the chips (96 MHz) pixel clock to achieve higher fps.

== Work In Progress ==

=== FPGA ===

Reading the [http://www.dvinfo.net/conf/showthread.php?t=63677&page=28 dvinfo thread] you can find someone (Z.H.) that is making some mod. to the current Fpga;

25 may 2007 - this project by Z.H. is in stand-by and he offer up his project for somebody else to take it over.

"If somebody's interested, here's the BloodSimple(TM) codec I wrote and experimented with. It creates a bitstream directly from the bayer input, always taking the difference of pixels as input. It works best if we use the algorithm in interframe mode, which means that we calculate the difference of pixels from the same coordinate of the previous frame. This of course needs that whole frame in memory.

An output sample always begins with a one bit flag (F) which tells the decoder if the following sample has the same bit length (F=0) as the previous one (a length of P) or it is greater with G bits (F=1). This G constant can be set according to the input stream and it will tell the contrast ratio of the generated images: with a T bit input, following pixels usually don't have more difference than T/2 bits. Visually lossless is around T/3 but it can be calculated explicitly in a pre-encoding step if needed. (By having the motion blur of the 1/24sec exposure, the blur caused by fast pans won't cause quality loss in the encoder as it would do with shorter exposure times.) If F=0, the decoder uses the previous P bit length but if the sample's most significant L bits are zero then the next sample will be taken with P-L bits (if that sample's F=0). The encoder knows this and if the next sample's length is greater than P-L then it sets F=1. L is usually set to T/4.

With sample videos (no real bayer input, only some grayscale mjpeg stuff with some artifical noise added) it has produced a 2:1 average ratio which means 2.5:1 with low freq content and 1.5:1 with high freq content (ie. trees with leaves with the sky as background). Because the code is so simple one can use several module instances in an fpga, for example, one for each pixel in a 20x20 block (or whatever the Elphel uses), working in paralell with only the memory bandwith setting the performance limits. However, with a smaller no. of instances it may fit beside the theora module; altough two output streams aren't supported yet. And it's really easy to implement it in verilog which can be a concern if somebody's not an expert"

"I'm afraid there are no verilog programmers here but somebody might pick it up. As for other bayer cameras, I'm not aware of any other which could be freely programmed like the Elphel. And the compression rate is pretty low (just enough for the Elphel, hopefully), perhaps it might be combined with some other algorithm to get better results."

=== Graphic User Interface (GUI) ===

For now we have a very good interface with the possibility of modify every single parameter that you can imagine, it is the ccam.cgi that may be get confusion (being incrementally patched from the first model 303 camera), but it is current.

<center>[[Image:elphel_camvc.jpg|400px|abc]]</center>

But for converting the elphel in a cinema camera that freedom is more than enough. Also there are some problems; the software and LiveCD give some difficulty, in fact you can't save the setting in an easy way so to prepare the laptop end the camera you have to spend between 10 to 20 minutes to setup all the command lines that had to be entered to optimize Linux for recording, and more command lines to record etc.

If you want to help us please see this page [http://dvinfo.net/conf/showthread.php?t=83044 link]</gallery>

=== Designs for rod support ===

The idea is to make a universal rod support that could mount:

-The Elphel 353 camera

-Any type of small PC (camera controller)

-power source

-Audio interface + microphone

-Most types of 35mm adapters

-Matte box

It is also important that the system is prepared for future hardware changes (like a bigger camera front-end for bigger sensors.)

The following examples are designs by Elphel users/developers:

[[Image:Elphel_VIsion_Concept_01.jpg|200px|abc]]

Design by Sebastian Pichelhofer

[[Image:Expl.jpg|100px|abc]][[Image:Perspective2RodSupport.jpg|200px|abc]][[Image:Perspective2.jpg|200px|abc]]

This design by Oscar Spierenburg puts the camera body in a 45° to safe space for the PC.
The tablet PC (touchscreen) is placed in 90° (Portrait) position.
(Note: this is not a shoulder mount setup, the middle part is the tripod/steadycam mount.)

[[Image:Cam-TabletPC-front.jpg|200px|abc]][[Image:Cam-TabletPC-back.jpg|200px|abc]]

This is a previous prototype by Oscar Spierenburg with the Tablet PC placed on top of the camera.

=== Shell-Design ===

Final part list:

- Sensor-Shell

- Controller-Shell with buttons

- Recording-Shell

- Battery-Shell

[[Image:batterypack.jpg|200px|abc]]
[[Image:batterypack2.jpg|200px|abc]]
[[Image:batterypack3.jpg|200px|abc]]

- Screen-Shell (TFT Monitor)

[[Image:screenmodule.jpg|200px|abc]]
[[Image:screenmodule2.jpg|200px|abc]]
[[Image:screenmodule3.jpg|200px|abc]]

- Audio-Shell

- Intelligent-Handle (USB connected)

The parts should be produced in aluminium or/and abs-plastic. All designs need to be open source. It would be good to find a university or shopowner who would participate on this project without personal benifits.

Apertus.Home

2009-03-19T21:39:53Z

Apertus.Home

2009-03-19T20:47:10Z

Oscar: /* Shell-Design */

== About this site ==

This page is created to develop elphel digital cinema cameras.

<code>Are we talking about a revolution? Maybe, or maybe we are only dreamers, but it's cool to be a dreamer with a revolution in mind! :-)</code>

== History ==

The cinema camera idea started in the first part of 2006 in the mind of a member of the [http://dvinfo.net/conf/index.php dvinfo] forum, and in March 26th 2006 01:46 AM, FS (I don't use the real name for privacy... FS if you want you can edit the page) started a new thread called [http://dvinfo.net/conf/showthread.php?t=63677 High Definition with Elphel model 333 camera].
Around one year later that thread had more than 400 responses, at the moment we are close to breaking the 1.000th reply barrier, so searching through them to find good information can be difficult.

This page was born to try to solve that problem. Andrey said to us: "We need to organize data more like a FAQ - the thread is so big." So here we go.

== Model 333 cameras==

=== info about elphel 333 ===

Here are some important links to understand what we have already.

- [http://www3.elphel.com/en/products model 333 general specification]

- how the camera works article [http://linuxdevices.com/articles/AT5951285077.html AJAX, LAMP, and liveDVD for a Linux-based camera] on [http://linuxdevices.com linuxdevices.com]

- all the software that you need to use the camera [https://sourceforge.net/projects/elphel sourceforge.net]

- the [http://developer.axis.com/ link] to Axis developer's site

- some video and images from the camera [http://community.elphel.com/videos/ on elphel's community videos], [http://www.elphel.com/3fhlo/ on elphel.com], on [http://www.tacx-video.com/images/HD2006/ tacx-video.com] and a [http://www.tacx-video.com/raw-demo/RothTri-333Raw-mjpeg.avi video] by PS, the [http://i11.photobucket.com/albums/a162/vericetti/beard1.jpg first image] taken from FS with not the best conditions, a low ligth 35mm adapter [http://s09.picshome.com/d35/comp_1__0-00-30-00_.jpg test] and one significant test example of dof from OS

<center>[[Image:35mmroof5.jpg|400px|abc]]</center>

- Example of a cinema camera setup by (D.L) ...and some result with it [http://wiki.elphel.com/index.php?title=Image:Txt.jpg text test], [http://wiki.elphel.com/index.php?title=Image:V8_Dof_test.jpg Bottle D.o.f. test]

<center>[[Image:333 hd setup.jpg|400px|abc]]</center>

and good example of what this setup could do:

<gallery>
Image:DLmoviegrab1.jpg
Image:DLmoviegrabpaint.jpg
Image:DLmoviegrab2.jpg
</gallery>

==MOVIES==

- May 18th, 2007, 09:28 PM - first short made with the elphel 333 hd camera + 35mm wax adapter by O.S. using that setup:

[[Image:Elphel35mmTripod.jpg|200px|abc]]

The autor said:

"Here is a small version of the 'documentary' I made in France. While my girlfriend was working all day in the garden making a path.... I was testing all aspects of the Elphel. Yes, between some shots I helped her a bit, but filmmaking comes first, right?

This short film also proves you can synch a separate audio recording, using the old method with a clap board (in this case I just clapped my hands and said the take number, the same as the Elphel output filename)
I used a portable minidisc recorder and it really worked fine.
I also used the wax adapter (which really needs to be rebuild to get rid of soft edges), and a 'big' Panasonic TV lens (notice some telephoto close ups of the flowers).

The clip is reduced by half in resolution to upload, and is just a rough cut without color adjustments and some faults in the editing. I'll probably upload the final version at normal resolution of 1600x900 pixels and less compression.
I'll post some stills at full size soon.

You can download the (54MB) file here: http://community.elphel.com/videos/RomainSurMeuse2.avi (it's in Xvid compression)"

or the full resolution version Xvid (200MB): http://community.elphel.com/videos/RomainFULL.avi

== The new cameras==

The new 353 cameras have better specs than 333 and are already available.
Here is a fast FAQ:

To better understand how the new hardware works, look at this article on [http://linuxdevices.com/ linuxdevices.com]: [http://linuxdevices.com/articles/AT4415936647.html High Resolution Cameras for Web Developers]

'''1. What sensors are available for the 353?'''

Quoted from [[353]]:
* Aptina 5MP 1/2.5" Sensor
* Kodak 11MP Full Frame Sensor
* Kodak 16MP Full Frame Sensor

'''2. Is it be possible to record video to a hard drive ?'''

With interface board [[10369]] it is possible to write video to SATA HDD or Compact Flash Cards (2 slots). From the software side a tool called camogm takes care of the recording.

'''3. What format will the recorded data have?'''

[[Camogm]] can record video as quicktime *.mov (MJPEG compression), Ogg Theora *.ogm or as JPEG sequence (even with exif data like geotags).

'''4. What frame rates / image sizes can be selected?'''

In general the chips window (only an area of the chip is be used for recording) can be freely modified. The lower the resolution the higher the possible framerate.

HD Standards:
* 1920x1080p (1920x1088 windowed chip) max. 25.24fps
* 1280x720p (1/2 binning 1280x720 full frame chip) max. 46.18fps
* 1280x720p (1280x720 windowed chip) max. 57.91fps

DV Standards (caution: square pixels):

* 640x480p (4:3 windowed chip) max. 126.11fps
* 854x480p (16:9 864x480 windowed chip) max. 110.13fps
* 640x480p(1/3 binning full frame chip) max. 81.95fps

* 720x576p (4:3 windowed chip) max. 100.36fps
* 720x576p (1/3 binning full frame chip) max. 66.36fps
* 1024x576p (16:9 windowed chip) max. 84.53fps

'''5. If it needs custom programming, where do I find info about tools / language etc? Just need a pointer. Any free compilers?'''

To be able to do development for these cameras you do not need any expensive (or even non-free-as-in-beer) tools. There are 3 levels (not to count client/PC software)
1 - "Web design" - developing of custom user interface - just any web design tools - you can FTP results to the camera
2 - Software applications to run in the camera - you need a PC running GNU/Linux (any flavor) and software from our Sourceforge project page plus additional - from http://developer.axis.com - our software will tell you what to download.
3 - FPGa code development - free (for download) tools from Xilinx - http://www.xilinx.com/ise/logic_design_prod/webpack.htm

'''6. Does the camera casing have space to accommodate a small hard drive?'''

Yes, or CF card.

'''7. Any idea of power requirements?'''

Model 333 needs a little under 3W. 353 should need about the same - not to count additional modules - hard drive or flash.

'''8. Does the camera have a C mount?'''

CS-mount as it is more universal for cameras - you can install both C and CS lenses

'''9. If I use a simple SLR mount (Nikon or Canon) to C mount adapter (instead of a ground glass solution), what lens multiplier would be in effect?'''

That depends on particular sensor that will be used - each sensor usually has info on the Internet.

'''
11. What does the 353 camera and sensor cost?'''

The same as our previous model had cost: [http://www3.elphel.com/price_list Pricelist]

'''12. Some more details about the 5MP Sensor?'''

The Aptina 5MP Sensor has a physical size of 5.70mm(H) x 4.28mm(V). Optical format is 1/2.5". But considering that the window of a full HD output only uses around 75% of the chips width the depth of field should be pretty much the same as using a 1/3" prosumer camcorder like the Panasonic HVX200, Sony FX-1 or Canons XL-H1. Aptina claims that the chip has 70db of dynamic range at full resolution and 76db when using 1/2 binning. It outputs 12-bit color data (elphel boards reduces these to 8bit in FPGA? please confirm). It might be possible to overclock the chips (96 MHz) pixel clock to achieve higher fps.

== Work In Progress ==

=== FPGA ===

Reading the [http://www.dvinfo.net/conf/showthread.php?t=63677&page=28 dvinfo thread] you can find someone (Z.H.) that is making some mod. to the current Fpga;

25 may 2007 - this project by Z.H. is in stand-by and he offer up his project for somebody else to take it over.

"If somebody's interested, here's the BloodSimple(TM) codec I wrote and experimented with. It creates a bitstream directly from the bayer input, always taking the difference of pixels as input. It works best if we use the algorithm in interframe mode, which means that we calculate the difference of pixels from the same coordinate of the previous frame. This of course needs that whole frame in memory.

An output sample always begins with a one bit flag (F) which tells the decoder if the following sample has the same bit length (F=0) as the previous one (a length of P) or it is greater with G bits (F=1). This G constant can be set according to the input stream and it will tell the contrast ratio of the generated images: with a T bit input, following pixels usually don't have more difference than T/2 bits. Visually lossless is around T/3 but it can be calculated explicitly in a pre-encoding step if needed. (By having the motion blur of the 1/24sec exposure, the blur caused by fast pans won't cause quality loss in the encoder as it would do with shorter exposure times.) If F=0, the decoder uses the previous P bit length but if the sample's most significant L bits are zero then the next sample will be taken with P-L bits (if that sample's F=0). The encoder knows this and if the next sample's length is greater than P-L then it sets F=1. L is usually set to T/4.

With sample videos (no real bayer input, only some grayscale mjpeg stuff with some artifical noise added) it has produced a 2:1 average ratio which means 2.5:1 with low freq content and 1.5:1 with high freq content (ie. trees with leaves with the sky as background). Because the code is so simple one can use several module instances in an fpga, for example, one for each pixel in a 20x20 block (or whatever the Elphel uses), working in paralell with only the memory bandwith setting the performance limits. However, with a smaller no. of instances it may fit beside the theora module; altough two output streams aren't supported yet. And it's really easy to implement it in verilog which can be a concern if somebody's not an expert"

"I'm afraid there are no verilog programmers here but somebody might pick it up. As for other bayer cameras, I'm not aware of any other which could be freely programmed like the Elphel. And the compression rate is pretty low (just enough for the Elphel, hopefully), perhaps it might be combined with some other algorithm to get better results."

=== Graphic User Interface (GUI) ===

For now we have a very good interface with the possibility of modify every single parameter that you can imagine, it is the ccam.cgi that may be get confusion (being incrementally patched from the first model 303 camera), but it is current.

<center>[[Image:elphel_camvc.jpg|400px|abc]]</center>

But for converting the elphel in a cinema camera that freedom is more than enough. Also there are some problems; the software and LiveCD give some difficulty, in fact you can't save the setting in an easy way so to prepare the laptop end the camera you have to spend between 10 to 20 minutes to setup all the command lines that had to be entered to optimize Linux for recording, and more command lines to record etc.

If you want to help us please see this page [http://dvinfo.net/conf/showthread.php?t=83044 link]</gallery>

=== Shell-Design ===

Final part list:

- Sensor-Shell

- Controller-Shell with buttons

- Recording-Shell

- Battery-Shell

[[Image:batterypack.jpg|200px|abc]]
[[Image:batterypack2.jpg|200px|abc]]
[[Image:batterypack3.jpg|200px|abc]]

- Screen-Shell (TFT Monitor)

[[Image:screenmodule.jpg|200px|abc]]
[[Image:screenmodule2.jpg|200px|abc]]
[[Image:screenmodule3.jpg|200px|abc]]

- Audio-Shell

- Intelligent-Handle (USB connected)

The parts should be produced in aluminium or/and abs-plastic. All designs need to be open source. It would be good to find a university or shopowner who would participate on this project without personal benifits.

Talk:Questions and Answers

2009-01-28T13:53:14Z

Oscar:

Hello...
I am interested in using the 363 camera board(s) for a project that would
allow people to convert their old still film-based cameras to digital use (digital still camera, NOT motion).
And before anyone points out the obvious, yes, I know that you can buy a full frame digital
camera for probably less than this project would allow someone to convert an old Nikon F
or a Canon AE or Leica M series to digital usage. But, it needs to be done and since no one else
has picked up the baton, I guess I must be the one. There is a treasure trove of old lenses and cameras out there
that are going to waste and a large portion of photographers who don't care about auto-focus, LCD review and
other bells and whistles that are available whether you want them or not.

What I am initially looking for is someone who is very familiar with the circuitry of the 363 camera.
It would help me a lot to be able to ask a number of questions on how to simplify the circuit easily. Much of the
features of the 363 will not be needed and I want to find out what needs to be "tied to ground" or can be left
dangling or open on the circuit and not be used.

Anyone?
thanks
George
Chicago

----
George,
I don't think there is anything you can really save on by not using some features. To build 363 camera you need 10353+10342+10347+10365 if mechanical shutter is not needed, otherwise - add 10368. Mechanical shutter may be needed if you have exposure times less that about 1/1000, that is needed because of the limited shutter ratio of the electronic shutter (some light still leaks while sensor is being read out).

If you have any specific questions about the boards - please go ahead, post them here.

--[[User:Andrey.filippov|Andrey.filippov]] 23:53, 22 January 2009 (CST)

Hello Andrey,
thanks for the response...I'm currently reading the entire DVinfo thread and trying to get up to speed. The reason I'd like to "edit" features is to reduce the size of the boards needed. I'd like to fit the electronics into existing still-film camera bodies and as you know, they're pretty small. Your current pc board size for the 353,347 and 342 I think will work just like they are, but there's no room for the 365 and 368...although I have yet to try to mock up the pc boards for a physical fit trial...as a secondary comment may I congratulate you and your associates on your great work and I wish you continued success...
George

By the way...I can't seem to find anything on the 10365 board...can you direct me to where info is? thanks...George

It is a power supply board for the 10342+10347 - CCD needs a lot of power for readout, vertical phase currents are in amp range. It seems this board was never documented on the wiki, as well as the other one - 10368, mechanical shutter driver. I'll work on it --[[User:Andrey.filippov|Andrey.filippov]] 15:06, 26 January 2009 (CST)

No description pages yet, just the files:
* [[Image:10365a.pdf|10365 - Circuit diagram, parts list, PCB layout]]
* [[Image:10365a_gerber.tar.gz|10365 - Gerber files]]
* [[Image:10368a.pdf|10368 - Circuit diagram, parts list, PCB layout]]
* [[Image:10368a_gerber.tar.gz|10368 - Gerber files]]
--[[User:Andrey.filippov|Andrey.filippov]] 15:44, 26 January 2009 (CST)

Thank you Andrey...
here's some summary questions that I've been working with Alexandre to formulate for the wiki...

Let me see if I am correct in my understanding...

1. The 10353, 10342 and 10347 are the core boards I need for a 10363 camera to use as a base for my digital still image camera (no motion needed).

2. They will all work on 3.2v battery power (well regulated...no over power...no under power or does under-power matter?)

''Yes, it does matter. Processor will be reset and reboot if voltage goes too low (hope no writing to flash at that time). But 3.2v battery will most likely fail during frame readout - the power is about 12W during this process. If voltage will drop, system will be reset. And generating CCD voltages from 3.2 will be very inefficient - I would rather start from higher, like 12V (or 18V-19V like in notebooks)--[[User:Andrey.filippov|Andrey.filippov]] 19:41, 27 January 2009 (CST)''

3. If I don’t want to expose a frame faster than 1/1000 sec then I don’t need mechanical shutter board (10368)...everything slower than 1/1000 sec can be handled by electronic shutter in the KAI11002 sensor, yes?

''Yes, especially if the exposure is even higher >1/100. Around 1/1000 they could be some visible vertical artifacts that in some cases could be software corrected--[[User:Andrey.filippov|Andrey.filippov]] 19:41, 27 January 2009 (CST)''

4. The 10353 (or 10363 as it is known when using the 11002 sensor) has onboard memory that could keep, let’s say, 20 full frame still camera raw images until downloaded to pc? Or does it need an additional memory board to be able to do this?

''Total system memory - 64MB, currently we use 19MB as image buffer (for compressed images). It is probably possible to increase it, but you'll need to be careful and remove all the unneeded applications that use memory. That may be not so easy as you'll loose software compatibility with the default software and upgrades. And that is for compressed, not raw images. 1 raw image for 11 MPix camera will need around 22MB, you can fit maximum 3 of them in the video memory (64MB)--[[User:Andrey.filippov|Andrey.filippov]] 19:41, 27 January 2009 (CST) ''

5. when I have this all hooked together, will the camera be able to boot from internal memory to work as a true portable for 20 raw still images, or will it always need to boot from a pc?

''Camera does not need any PC to boot, it boots from internal flash memory--[[User:Andrey.filippov|Andrey.filippov]] 19:41, 27 January 2009 (CST)''

6. Do I absolutely need the 10365 power supply board and what is it's physical dimension? if it is the wrong dimensions for my needs, can I redesign to other physical dimension and will it also run off the 3.2v battery power or does it require more battery power?

''10365 generates +1.2V, +5V, +6V, +15V, -15V, +27V, and as I wrote - starting from 3.2v would be less efficient, than from higher voltage. 2-d dimensions are in the PDF file (and also in Gerber ones) --[[User:Andrey.filippov|Andrey.filippov]] 19:41, 27 January 2009 (CST)''

thanks
George

George,

Did you consider using a medium format twin lens camera like the Rolleiflex? Cameras like these are inexpensive, but high quality: http://en.wikipedia.org/wiki/Rolleiflex You'd need a 60mm x 60mm sensor of course, but you'd have something really special. Maybe you can fit the boards under the mirror, i think that's an empty space.

Oscar

Audio

2009-01-28T01:38:07Z

Oscar: /* Microphones */

=Parts to try=
==Audio USB interface (with XLR-mic pre amp)==
* [http://www.tascam.de/art/en/artcess/preamp/usbdualpre.html ART dual pre]
==Microphones==
* [http://www.audio-technica.com/cms/wired_mics/c75c5918ed57a8d0/index.html AT2020USB] [http://www.google.com/products?checkout=1&lmode=online&q=AT2020USB $100-250]
* [http://www.logitech.com/index.cfm/webcam_communications/microphones/devices/221&cl=us,en Logitech USB microphone]
* [http://www.infra-sonic.com/site/p_jam_ufo.php Jam Mate UFO ~$200]

=Approved parts=