ElphelWiki - User contributions [en]

SCINI: Submersible Capable of under Ice Navigation and Imaging

2008-10-14T20:14:35Z

Aegdss: On ICE

A group at the [http://www.mlml.calstate.edu Moss Landing Marine Labs] in Moss Landing, CA (USA) is working on a new submersible ROV (remotely operated vehicle) which will be first deployed in Antarctica in the fall of 2007; it is a three year development program ending in 2009.

They are planning on using an Elphel 353 video camera for the main navigation camera, and possibly adding on a second high resolution still camera sensor board for image collection. The ability to run video over ethernet with the rest of the communications means the 1000 foot (330 meter) tether does not need dedicated conductors for video transmission, which saves a lot of hassle! The configurability of exposure, color balance, frame rate, etc, through open standards and software means less reverse engineering and easier integration with existing robotics control software.

<center>[[Image:Camera_module_sm.jpg]]

Prototype Waterproof Camera Bottle</center>

Here's a first fisheye [http://mit.edu/bnewbold/scini/from_crary310.jpg image] from McMurdo station in Antarctica... not well focused, window reflections, bad exposure, blah blah. The black shapes around the edge are LED casings. We will try to post more stills and video clips when we start flying the ROV in the next week or two, bandwidth permitting.

It's beautiful here. --[[User:Bnewbold|Bnewbold]] 04:41, 10 October 2007 (CDT)

For more information about the project including a blog see http://scini.mlml.calstate.edu/

[[User:Bnewbold]] was the main contact on this wiki for the SCINI Project; see his talk page for Elphel-specific questions and software related to the SCINI Project.

[http://scini.blogspot.com/2007/12/pretty-pictures.html more images and video clips from Antarctica]

SCINI and Elphel are back on the ice for the 2008 season. The team is currently going through training, but hope to start performing engineering tests later this week. First science dives should start shortly.

There are currently 4 systems assembled. Two are configured as standard monohead 353 cameras. Two are configured as dual headed 353 + 10359 cameras. Hopefully we will have annotated images and seafloor mosaics soon! --[[User:Aegdss|aegdss]] 15:10:16, 2008-10-14 (CDT)

SCINI: Submersible Capable of under Ice Navigation and Imaging

2008-10-14T20:10:16Z

Aegdss: On ICE

A group at the [http://www.mlml.calstate.edu Moss Landing Marine Labs] in Moss Landing, CA (USA) is working on a new submersible ROV (remotely operated vehicle) which will be first deployed in Antarctica in the fall of 2007; it is a three year development program ending in 2009.

They are planning on using an Elphel 353 video camera for the main navigation camera, and possibly adding on a second high resolution still camera sensor board for image collection. The ability to run video over ethernet with the rest of the communications means the 1000 foot (330 meter) tether does not need dedicated conductors for video transmission, which saves a lot of hassle! The configurability of exposure, color balance, frame rate, etc, through open standards and software means less reverse engineering and easier integration with existing robotics control software.

<center>[[Image:Camera_module_sm.jpg]]

Prototype Waterproof Camera Bottle</center>

Here's a first fisheye [http://mit.edu/bnewbold/scini/from_crary310.jpg image] from McMurdo station in Antarctica... not well focused, window reflections, bad exposure, blah blah. The black shapes around the edge are LED casings. We will try to post more stills and video clips when we start flying the ROV in the next week or two, bandwidth permitting.

It's beautiful here. --[[User:Bnewbold|Bnewbold]] 04:41, 10 October 2007 (CDT)

For more information about the project including a blog see http://scini.mlml.calstate.edu/

[[User:Bnewbold]] was the main contact on this wiki for the SCINI Project; see his talk page for Elphel-specific questions and software related to the SCINI Project.

[http://scini.blogspot.com/2007/12/pretty-pictures.html more images and video clips from Antarctica]

SCINI and the elphel are back on the ice. The team is currently going through training, but hope to start performing engineering tests later this week. First science dives should start shortly.

There are currently 4 systems assembled. Two are configured as standard monohead 353 cameras. Two are configured as dual headed 353 + 10359 cameras. Hopefully we will have annotated images and seafloor mosaics soon! --[[User:Aegdss|aegdss]] 15:10:16, 2008-10-14 (CDT)

Talk:Camera Wishlist

2008-10-08T23:56:32Z

Aegdss: other wishlist...

There is already a [[Wishlist]] page: I didnt want to hijack your page, but maybe they should be merged. --[[User:Aegdss|aegdss]] 18:56:32, 2008-10-08 (CDT)

Fast Boot

2008-10-03T12:25:47Z

Aegdss: added two links

It would be nice if it was possible to speed up the system boot time, from power on to images on the wire.

I have not looked into this at all, but some ideas:

1) Benchmark current boot process

2) Strip out as much as possible

3) custom kernel

4) custom bootloader

Should be a fairly easy project, at least for the beginning steps.

Somewhere around 1-2 sec would be ideal.
--[[User:Aegdss|aegdss]] 17:09:32, 2008-09-05 (CDT)

Some links:
[http://lwn.net/Articles/299483/ LWN article on fast booting]
[http://broadcast.oreilly.com/2008/09/how-powertop-latencytop-and-fi.html oreilly article]

Talk:Main Page Temp

2008-10-02T20:04:46Z

Aegdss:

I like it--[[User:Andrey.filippov|Andrey.filippov]] 14:26, 2 October 2008 (CDT)

FWIW, Gets my vote too! One thing, As a relatively new user, one of the biggest challenges was/is conflicting documentation. For example it's not 100% clear what the difference between the user documentation and roadmap is. Also a direct link to sw would be nice or at least a note as to what the current stable version is.
--[[User:Aegdss|aegdss]] 15:04:46, 2008-10-02 (CDT)

File:Bad phase.jpg

2008-10-01T17:21:30Z

Aegdss: Incorrect phase on sensor 2 of dual head camera

Incorrect phase on sensor 2 of dual head camera

File:Good phase.jpg

2008-10-01T17:20:03Z

Aegdss: Good phase adjustment on Dual Head camera

Good phase adjustment on Dual Head camera

User:Aegdss\Learning Curve

2008-10-01T17:18:52Z

Aegdss: /* good colors on dual head camera */

== Diary of getting up to speed ==

== Unboxing ==
--[[User:Aegdss|aegdss]] 09:24:28, 2008-08-08 (CDT)

Got the camera including a few cat-5 and rs-232 Dsub shell etc which was very nice.

Dont have a POE switch and didnt want to cannibalize a cable or open the
housing yet, so I bought a POE injector (POI-2000 from CP Technology via amazon).

Camera came right up, could connect via telnet and browser, could acquire images and
modify settings. UI seemed a bit flakey at times (using Firefox) but that could certainly
have been op error.

Changed IP to 192.168.1.9, so it would work on my lan.

Attempted to get VLC and mplayer to work, but didnt have too much luck. Streamer seemed to start
as evidenced by ps and indicator on web ui. But I couldn't get client apps to receive a stream. I did manage to get mplayer to start crashing so It must have been doing something :)

Gonna try streaming with linux client and then once that is all working go back to vista.

----
VLC should work at least up to HD resolution on any OS. (take the last stable version of VLC. VLC need to be compiled with a liblivemedia >= 2007.02.20) We officially support only patched MPlayer. (Here also, last stable MPlayer, liblivemedia >= 2007.02.20) The patch to apply is just in mplayer-1.0~rc2/libmpdemux/demux_rtp.cpp replace #define MAX_RTP_FRAME_SIZE 50000 by #define MAX_RTP_FRAME_SIZE 5000000.

--[[User:Polto|Alexandre.Poltorak]] 02:51, 9 August 2008 (CDT)

== Streaming ==

Yes, VLC seems to work when using HD or less resolution. VLC is a touch on the flaky side, It would crash when using a built in image capture device (not elphel camera). Also, I could only get vlc to work using unicast streaming (rtsp://192.168.0.9:554). But that could easily have been operator error. I'll look into that further later, but first want to test out a patched mplayer under windows. But once I set the frame rate correctly and used unicast I didn't have any problems.

VLC had bad latency, on the order of 2-3 seconds, which seemed independent of resolution. The web interface, used at the same time as the streamer, did NOT exhibit the same latency. PC CPU load was only 25% or so. The other SCINI team members reported "very low" latency using VLC under linux, so evidence points to an issue with vlc on windows.

Aside:
The AJAX interface works well and is nice if a bit intimidating for the neophyte user,
the tooltips help a lot. I'm curious what is the frame rate limiting factor here, I need to
take a peek at the code when I get a sec.

--[[User:Aegdss|aegdss]] 14:01:39, 2008-08-11 (UTC)

== Use the src... ==

Seems like the ajax ui eventually turns off the compressor if streaming is not on,
I didnt look at the code yet though.
----
Please use camvc2.html and not camvc (index.html), camvc2 treat the compressor and the streamer independently.
You can also do all the setup using only PHP: [[PHP Examples]], see camera_demo.php
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----

Managed to get pretty good performance using the fast server (port 8081). Just start the compressor with fpcf -jpeg and then read from 8081/img as fast as I could. Gonna write a small little app to do it and see how fast I can get it on windows.

Loaded src onto a ubuntu machine today using install_from_cvs script. Went pretty smooth with only a few glitches...

1) the tcpdump.org was down and ./install_elphel wants to grab libpcap from there. Just download it from somewhere else and put it in the ~/distfiles dir.
----
we will check it, normally it should take from the mirror automatically in this case.
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----

2) apt-get install lex yacc doesn't work. Those are in flex and bison though, so apt-get install flex bison gets them.
(This was corrected in the wiki docs...--[[User:Aegdss|aegdss]] 09:26:52, 2008-08-25 (CDT))

3) the manual install of the cris compiler had problems, but the binary distribution worked just fine.
----
Please have a look on: [[Elphel_Software_Kit_for_Ubuntu#For_developers:]]
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----
[[Elphel_Software_Kit_for_Ubuntu#For_developers:]]
were the docs I was following, (which are pretty good btw.) The line
"sudo apt-get install cvs build-essential lex byacc bison libglib2.0-dev tcl gettext libncurses5-dev patch zlib1g-dev" was a problem cause apt-get couldnt install lex. I think maybe if lex is replaced by flex it would be fine. I didnt really investigate further.

I also first tried to install the cris compiler using the docs on the same page. This failed in the final step (sudo ./install-cris-tools.) I did not note the error and just went straight to the binary package (which worked fine.). Of course this is more an issue with the axis script (install-cris-tools) rather than the wiki doc which seems correct in this case. I just noted it in case anyone else has the same issue and doesnt have the time to debug the install script. I think the problem with the install-cris script is probably machine (or distribution) dependent and may work just fine for most everyone else. FWIW I'm installing on a fairly stock ubuntu 8.04.

Overall the user experience for setting up the dev environment using the binary package install for the cris tools and then [http://downloads.sourceforge.net/elphel/elphel353_install_from_cvs.sh.tar.gz?modtime=1195003055&big_mirror=0 elphel353_install_from_cvs.sh] was really very nice and easy.

--[[User:Aegdss|aegdss]] 08:28:11, 2008-08-22 (CDT)

== SCINI stuff ==

We are going to try to use a dual headed setup with one sensor fwd and one looking down. So looking into using the 10359 and what exactly is the best operational method of doing that.

--[[User:Aegdss|aegdss]] 14:28:38, 2008-08-21 (CDT)

== Plunging into dual head ==

After getting a great amount of support from the elphel team,
I managed to successfully test the 10359 board. Although only
with one sensor module (the other I got from SCINI team didnt work, but they had mention that they thought that they had killed it (static, bad voltage, penguin attack?, who knows...).

I'm trying to procure another sensor board today.

But FWIW I got images easily through the 10359 using the following sequence of steps (provide by Alexandre Poltorak):

http://192.168.0.13/camera_demo.php

http://192.168.0.13/359/sensors_init.php

http://192.168.0.13/ccam.php?trig=async&mode=set

http://192.168.0.13/359/tests_for_96mhz.php

http://192.168.0.13/compressor.php?cmd=run

http://192.168.0.13/sync.php?role=self&fps=single

http://192.168.0.13:8081/img

Gonna dig through those scripts now, while awaiting another sensor board.

--[[User:Aegdss|aegdss]] 09:21:27, 2008-08-25 (CDT)

Also anyone interested in Dual Head should take a look at [[10359_in_dual_sensor_setup]]

== Feet to the fire ==

Nothing like dangerously close deadlines to speed up the learning process...

Current plan is to have a c#/wpf dual head camera control app that also allows for science annotation...All using http, no rtp.

Actually making good progress. Playing/reading all the php scripts.
Got multi-threaded http image reader/display going on windows (C#, WPF). It seems
plenty fast, and no noticeably latency: This is using a single sensor running through the 10359 in
"Transparent" mode.

(image request, image read, display set source, display invalidate: )
8-9 ms (320x240) 
12-14 ms (640x480) 
19 - 20 ms (1296x960) but starts to clobber the UI of the app . 
45 - 50 ms (2592x1936) bit of stuttering and UI getting very unresponsive. 

So very very promising...need to clean up the app, better thread handling, add dual head, add camera control, etc. etc....

--[[User:Aegdss|aegdss]] 14:55:08, 2008-09-02 (CDT)

== Two heads are better... ==

Got some results attempting dual head. Managed to switch between sensors and get imagery from both, although there seems to be some issue with color and or syncs in the images. Looking into that now. But not bad for first time. Maybe I'm not stopping the compressor correctly, or not waiting long enough between stopping and starting. It currently takes about 3 seconds to do a switch (with messed up colors, but other than that working). This is kinda slow, so I may need to find a way to speed that up.

Using the php is pretty easy. Much nicer to have a bunch of custom scripts than to have to do everything by passing params to ccam.php. While I'd prefer a straight C interface with maybe a simple socket wrapper, I must admit that the php stuff makes it pretty easy.

--[[User:Aegdss|aegdss]] 15:37:58, 2008-09-03 (CDT)

Managed to get the "snapshot" mode working ok. Colors are messed up, but can acquire frames from both sensors. Here is the scripts used:

http://192.168.1.9/camera_demo.php

http://192.168.1.9/359/sensors_init.php

http://192.168.1.9/ccam.php?trig=async&mode=set

http://192.168.1.9/359/tests_for_96mhz.php

http://192.168.1.9/compressor.php?cmd=run

Then Repeat:

http://192.168.1.9/sync.php?role=self&fps=single

http://192.168.1.9:8081/torp/img/next/save

--[[User:Aegdss|aegdss]] 15:54:43, 2008-09-03 (CDT)

== Doh!!! ==

Important tip! When comparing images from a dual headed camera, make sure the iris's on both
lenses are open!!!!

Still don't fully understand phase setting, what is hitting sensor registers, etc.
I do fully understand the php interface and other various ajaxy scripts etc.

Weekend reading assignment is all src code. Hope to have SW done by end of next week, at least in some usable state, which I think is doable now.

SCINI is using 3" or 4" ribbon cables, will be getting some next week.

--[[User:Aegdss|aegdss]] 16:51:49, 2008-09-05 (CDT)

== All The Pretty Colors ==

Ok, the color issue has been resolved. Oleg and Alexandre had said multiple times to adjust phase to
fix the colors, but I had thought that relative small values of phase adjustment should be used. I wrote an
application (C#/WPF) that talks to some custom php scripts which allows one to quickly adjust the dcm phase of each sensor. (See below) Once this was done it took about 2 seconds to get good images on both sensors. Oleg also sent new x359 bits which fixes some slight problems causing 1 bad frame upon a sensor mux. I will release all the software at some point, but if anyone wants it sooner please email.

[[Image:bad_phase.jpg]]

[[Image:good_phase.jpg]]

--[[User:Aegdss|aegdss]] 12:18:52, 2008-10-01 (CDT)

10359 in dual sensor setup

2008-09-12T20:36:28Z

Aegdss: /* fixed php script */

{{Polto's test page}}

=Hardware configuration=
[[Image:10359_polto.jpeg|thumb]]
In my tests I use 2 sensors connected to a 10359 board and a 10353.

To be able to simply visualize the difference I connected 1 color and one monochrome sensor.

For simplicity and better hardware protection I just hacked 2 standard camera cases. It's not perfect at all, but allow a clean setup without many work.

=Considerations=

The monochrome sensor is connected with a 12" flat cable. This sensor will need individual phase adjustment.

=Tests=
==Transparent mode==
===Configure the sensor & 10359 and request a single frame===
1) I telnet to the camera and do:
cp /usr/html/camera_demo.php /var/html/

2) I modify in /var/html/camera_demo.php:
//!start compressor:
elphel_compressor_run();
//! or just acquire a single frame
//elphel_compressor_frame();
by
//!start compressor:
//elphel_compressor_run();
//! or just acquire a single frame
elphel_compressor_frame();

3) I call http://192.168.0.9/var/camera_demo.php from a browser. The page will be loaded, but the image do not appear. At this moment I open http://192.168.0.9/359/sensors_init.php and in another tab, the image appear in http://192.168.0.9:8081/last/save/wait/img

===Request a single frame===
I can request more images by executing a custom script get1frame.php:
<?php
//! just acquire a single frame
elphel_compressor_frame();
echo "<img src=\"http://" . $_SERVER["SERVER_ADDR"] . ":8081/last/save/wait/img \>"
?>

I can get refreshed images from the first sensor (color).

*Uhhhh* I have the previous image at each refresh

===Switch between sensors===
I can now switch to the second (monochrome) sensor: http://192.168.0.9/359/reg_write.php?adr=0x835&data=2

data parameter is the sensor number (1, 2 or 3)

to get an image from this sensor I call again my script http://192.168.0.13/var/get1frame.php

===Adjust phase on a particular sensors===

==Snapshot mode==

=Conclusions=

User talk:Bnewbold

2008-09-09T16:15:14Z

Aegdss:

Hi.

The problem with VLC is due to RTP/RTSP implementation with live555. Our patches for mplayer solve this problem, you can try to modify the patch to work with VLC.

For lenses: try the Fujinon DF6HA-1B

ccam.cgi: we are working now on rewriting it with PHP. for the interface: yes camvc is something standard, you need something more adapted to your needs. Why not use Pure-Data to build a real hardware control unit? (with buttons, cross faders etc..)

== ROV ==

What is the maximum pressure you expect the Elphel to be handling? I see a possibility to use an Elphel as ROV too, but I wonder if the pressure it must handle could break it (especially when surfacing again).

Zook

We have made several housings for the camera. our latest housing will go 1000M deep. We only plan on going 300M this year but in the future we hope to go 2500M with this camera.

Of course it must be understood that the camera is in a pressure housing. The actual pressure that the camera parts (electronics boards 10353, 10359, sensors, and cables) will experience is only 1 atm (14.7 psi)

--[[User:Aegdss|aegdss]] 16:39:00, 2008-09-05 (CDT)

In this case you have a box in a box, how do you handle the optics in that respect? Is your ''hardware design'' also ''open'' I would really like to see how you have solved this.

--[[User:Skinkie|Skinkie]] 19:19, 8 September 2008 (CDT)

Not really a box in a box. The electronics (10353, 10359 etc.) are not in the standard elphel housing. They are in a pressure vessel (the SCINI robot) which has acrylic viewports through which the lenses see. [http://scini.mlml.calstate.edu/resources.html older SCINI drawing]. Bob Zook would know more about the licensing status of the design and when images of the new vehicle will be up. But he is SUPER busy right now getting ready for the Antarctic deployment.

You are correct in that optics are an issue. There was some problem last year as a ring of led lights around the c-mount lens was used. These LEDS caused a fair bit of flare. The viewport can be a dome or flat. Both types have various advantages/disadvantages but in general a dome port is better so that you can get a wider angle lens in and move in closer.

Underwater housings can be simple or complex. There are tons of links on the web. One DIY is [http://www.instructables.com/id/Improved-Underwater-Camera-Housing/ Homemade camera housing]. [http://www.prevco.com/ Prevco] also has some inexpensive optically clear housings.

--[[User:Aegdss|aegdss]] 11:03:50, 2008-09-09 (CDT)

User talk:Bnewbold

2008-09-09T16:03:50Z

Aegdss: /* ROV */

Hi.

The problem with VLC is due to RTP/RTSP implementation with live555. Our patches for mplayer solve this problem, you can try to modify the patch to work with VLC.

For lenses: try the Fujinon DF6HA-1B

ccam.cgi: we are working now on rewriting it with PHP. for the interface: yes camvc is something standard, you need something more adapted to your needs. Why not use Pure-Data to build a real hardware control unit? (with buttons, cross faders etc..)

== ROV ==

What is the maximum pressure you expect the Elphel to be handling? I see a possibility to use an Elphel as ROV too, but I wonder if the pressure it must handle could break it (especially when surfacing again).

Zook

We have made several housings for the camera. our latest housing will go 1000M deep. We only plan on going 300M this year but in the future we hope to go 2500M with this camera.

Of course it must be understood that the camera is in a pressure housing. The actual pressure that the camera parts (electronics boards 10353, 10359, sensors, and cables) will experience is only 1 atm (14.7 psi)

--[[User:Aegdss|aegdss]] 16:39:00, 2008-09-05 (CDT)

In this case you have a box in a box, how do you handle the optics in that respect? Is your ''hardware design'' also ''open'' I would really like to see how you have solved this.

--[[User:Skinkie|Skinkie]] 19:19, 8 September 2008 (CDT)

Not really a box in a box. The electronics (10353, 10359 etc.) are not in the standard elphel housing. They are in a pressure vessel (the SCINI robot) which has acrylic viewports through which the lenses see. [http://scini.mlml.calstate.edu/resources.html older SCINI drawing]. Bob Zook would know more about the licensing status of the design and when images of the new vehicle will be up. But he is SUPER busy right now getting ready for the Antarctic deployment.

You are correct in that optics are an issue. There was some problem last year as a ring of led lights around the c-mount lens was used. These LEDS caused a fair bit of flare. The viewport can be a dome or flat. Both types have various advantages/disadvantages but in general a dome port is better so that you can get a wider angle lens in and move in closer.

--[[User:Aegdss|aegdss]] 11:03:50, 2008-09-09 (CDT)

Talk:Implement calibration

2008-09-08T23:27:21Z

Aegdss: more compass talk

You are using the ocean server compass?

Are you using the depth sensor as well?

There is no calibration SW? or just no linux SW?
Would you know if there is depth calibration SW?

I would guess that the elphel should just be able to parse NMEA-0183, then it
can work with most compass modules (KVH, PNI TCM-2, etc.)

--[[User:Aegdss|aegdss]] 18:19:40, 2008-09-05 (CDT)

On IRC I heared there is no calibration on the compass. So probably it only gives lets say the rotation it makes like a gyro does.

--[[User:Skinkie|Skinkie]] 21:32, 5 September 2008 (CDT)

FWIW, the compass does support hard-iron calibration via simple serial commands plus manual rotation of the compass. See [http://www.ocean-server.com/download/OS5000_Compass_Manual.pdf ocean server compass manual]. This is similar to other compass modules. It would seem that this is an application level procedure and not really suitable for embedding in the camera. It would be nice if the camera did allow for a redirect of the serial comms to a network socket or something.

--[[User:Aegdss|aegdss]] 13:38:42, 2008-09-08 (CDT)

Why not doing it from the camera ? It's what we did the first time we got the compass. We calibrate it via the serial port with some special commands. It is possible I think to build a PHP app that will launch compass calibration on request from the browser. So the user will only have to manually rotate the camera.

--[[User:Polto|Alexandre.Poltorak]] 14:10, 8 September 2008 (CDT)

You guys love PHP don't ya ;) I'll see what I can come up with.

--[[User:Skinkie|Skinkie]] 15:13, 8 September 2008 (CDT)

No reason you couldn't do it in the camera, and using PHP if you wanted, but in some situations it would be nice to be able to get high update rate (10 Hz or whatever) from the compass without having to transmit images as well. If the camera could bridge the net interface to the serial port this would be trivial. But that's the really nice thing about open source, people can implement many different methods.

--[[User:Aegdss|aegdss]] 18:27:21, 2008-09-08 (CDT)

Talk:Implement calibration

2008-09-08T18:38:42Z

Aegdss: compass discussion

Talk:Implement calibration

2008-09-05T23:19:40Z

Aegdss:

C API

2008-09-05T22:15:39Z

Aegdss: another wish

One of the nice things about the elphel is that a whole lot is included;
multiple http servers, a few different ajax interfaces, /dev interfaces, php etc.

This can also be a curse as there are many ways to do the same thing. (See any perl vs python war :) )

It would be nice to have a simple straight c higher level api, maybe somewhat equivalent to the php api that could be used as a basis for custom firmware. Possibly with a very simple UDP packet streamer. The idea would be to enable easy custom software if the use of standard softwares (vlc, live555, mplayer etc.) is not desired.

--[[User:Aegdss|aegdss]] 17:15:39, 2008-09-05 (CDT)

Fast Boot

2008-09-05T22:10:06Z

Aegdss:

Fast Boot

2008-09-05T22:09:32Z

Aegdss: A wish

It would be nice if it was possible to speed up the system boot time, from power on to images on the wire.

I have not looked into this at all, but some ideas:

1) Benchmark current boot process
2) Strip out as much as possible
3) custom kernel
4) custom bootloader

Should be a fairly easy project, at least for the beginning steps.

Somewhere around 1-2 sec would be ideal.
--[[User:Aegdss|aegdss]] 17:09:32, 2008-09-05 (CDT)

Wishlist

2008-09-05T22:05:06Z

Aegdss: Some wishes

Today I received a development sample of the 353 camera. As ''user'' I noticed some things I wanted to have, I hope anyone that has ideas can write them on a central place and make a new page on the wiki to it. If a project has been completed just add the developer that did it, or is busy on it.

=== Sensor ===
* [[Dead/Hot pixel correction]]

=== Networking ===
* [[DHCP (timeouted) and DNS-SD]]

=== Fastest Boot ===
* [[Fast Boot]]

=== C API ===
* [[C API]]

User:Aegdss\Learning Curve

2008-09-05T21:57:51Z

Aegdss: /* progress */

User:Aegdss\Learning Curve

2008-09-05T21:56:33Z

Aegdss: /* Plunging into dual head */

== Diary of getting up to speed ==

== Unboxing ==
--[[User:Aegdss|aegdss]] 09:24:28, 2008-08-08 (CDT)

Got the camera including a few cat-5 and rs-232 Dsub shell etc which was very nice.

Dont have a POE switch and didnt want to cannibalize a cable or open the
housing yet, so I bought a POE injector (POI-2000 from CP Technology via amazon).

Camera came right up, could connect via telnet and browser, could acquire images and
modify settings. UI seemed a bit flakey at times (using Firefox) but that could certainly
have been op error.

Changed IP to 192.168.1.9, so it would work on my lan.

Attempted to get VLC and mplayer to work, but didnt have too much luck. Streamer seemed to start
as evidenced by ps and indicator on web ui. But I couldn't get client apps to receive a stream. I did manage to get mplayer to start crashing so It must have been doing something :)

Gonna try streaming with linux client and then once that is all working go back to vista.

----
VLC should work at least up to HD resolution on any OS. (take the last stable version of VLC. VLC need to be compiled with a liblivemedia >= 2007.02.20) We officially support only patched MPlayer. (Here also, last stable MPlayer, liblivemedia >= 2007.02.20) The patch to apply is just in mplayer-1.0~rc2/libmpdemux/demux_rtp.cpp replace #define MAX_RTP_FRAME_SIZE 50000 by #define MAX_RTP_FRAME_SIZE 5000000.

--[[User:Polto|Alexandre.Poltorak]] 02:51, 9 August 2008 (CDT)

== Streaming ==

Yes, VLC seems to work when using HD or less resolution. VLC is a touch on the flaky side, It would crash when using a built in image capture device (not elphel camera). Also, I could only get vlc to work using unicast streaming (rtsp://192.168.0.9:554). But that could easily have been operator error. I'll look into that further later, but first want to test out a patched mplayer under windows. But once I set the frame rate correctly and used unicast I didn't have any problems.

VLC had bad latency, on the order of 2-3 seconds, which seemed independent of resolution. The web interface, used at the same time as the streamer, did NOT exhibit the same latency. PC CPU load was only 25% or so. The other SCINI team members reported "very low" latency using VLC under linux, so evidence points to an issue with vlc on windows.

Aside:
The AJAX interface works well and is nice if a bit intimidating for the neophyte user,
the tooltips help a lot. I'm curious what is the frame rate limiting factor here, I need to
take a peek at the code when I get a sec.

--[[User:Aegdss|aegdss]] 14:01:39, 2008-08-11 (UTC)

== Use the src... ==

Seems like the ajax ui eventually turns off the compressor if streaming is not on,
I didnt look at the code yet though.
----
Please use camvc2.html and not camvc (index.html), camvc2 treat the compressor and the streamer independently.
You can also do all the setup using only PHP: [[PHP Examples]], see camera_demo.php
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----

Managed to get pretty good performance using the fast server (port 8081). Just start the compressor with fpcf -jpeg and then read from 8081/img as fast as I could. Gonna write a small little app to do it and see how fast I can get it on windows.

Loaded src onto a ubuntu machine today using install_from_cvs script. Went pretty smooth with only a few glitches...

1) the tcpdump.org was down and ./install_elphel wants to grab libpcap from there. Just download it from somewhere else and put it in the ~/distfiles dir.
----
we will check it, normally it should take from the mirror automatically in this case.
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----

2) apt-get install lex yacc doesn't work. Those are in flex and bison though, so apt-get install flex bison gets them.
(This was corrected in the wiki docs...--[[User:Aegdss|aegdss]] 09:26:52, 2008-08-25 (CDT))

3) the manual install of the cris compiler had problems, but the binary distribution worked just fine.
----
Please have a look on: [[Elphel_Software_Kit_for_Ubuntu#For_developers:]]
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----
[[Elphel_Software_Kit_for_Ubuntu#For_developers:]]
were the docs I was following, (which are pretty good btw.) The line
"sudo apt-get install cvs build-essential lex byacc bison libglib2.0-dev tcl gettext libncurses5-dev patch zlib1g-dev" was a problem cause apt-get couldnt install lex. I think maybe if lex is replaced by flex it would be fine. I didnt really investigate further.

I also first tried to install the cris compiler using the docs on the same page. This failed in the final step (sudo ./install-cris-tools.) I did not note the error and just went straight to the binary package (which worked fine.). Of course this is more an issue with the axis script (install-cris-tools) rather than the wiki doc which seems correct in this case. I just noted it in case anyone else has the same issue and doesnt have the time to debug the install script. I think the problem with the install-cris script is probably machine (or distribution) dependent and may work just fine for most everyone else. FWIW I'm installing on a fairly stock ubuntu 8.04.

Overall the user experience for setting up the dev environment using the binary package install for the cris tools and then [http://downloads.sourceforge.net/elphel/elphel353_install_from_cvs.sh.tar.gz?modtime=1195003055&big_mirror=0 elphel353_install_from_cvs.sh] was really very nice and easy.

--[[User:Aegdss|aegdss]] 08:28:11, 2008-08-22 (CDT)

== SCINI stuff ==

We are going to try to use a dual headed setup with one sensor fwd and one looking down. So looking into using the 10359 and what exactly is the best operational method of doing that.

--[[User:Aegdss|aegdss]] 14:28:38, 2008-08-21 (CDT)

== Plunging into dual head ==

After getting a great amount of support from the elphel team,
I managed to successfully test the 10359 board. Although only
with one sensor module (the other I got from SCINI team didnt work, but they had mention that they thought that they had killed it (static, bad voltage, penguin attack?, who knows...).

I'm trying to procure another sensor board today.

But FWIW I got images easily through the 10359 using the following sequence of steps (provide by Alexandre Poltorak):

http://192.168.0.13/camera_demo.php

http://192.168.0.13/359/sensors_init.php

http://192.168.0.13/ccam.php?trig=async&mode=set

http://192.168.0.13/359/tests_for_96mhz.php

http://192.168.0.13/compressor.php?cmd=run

http://192.168.0.13/sync.php?role=self&fps=single

http://192.168.0.13:8081/img

Gonna dig through those scripts now, while awaiting another sensor board.

--[[User:Aegdss|aegdss]] 09:21:27, 2008-08-25 (CDT)

Also anyone interested in Dual Head should take a look at [[10359_in_dual_sensor_setup]]

== Feet to the fire ==

Nothing like dangerously close deadlines to speed up the learning process...

Current plan is to have a c#/wpf dual head camera control app that also allows for science annotation...All using http, no rtp.

Actually making good progress. Playing/reading all the php scripts.
Got multi-threaded http image reader/display going on windows (C#, WPF). It seems
plenty fast, and no noticeably latency: This is using a single sensor running through the 10359 in
"Transparent" mode.

(image request, image read, display set source, display invalidate: )
8-9 ms (320x240) 
12-14 ms (640x480) 
19 - 20 ms (1296x960) but starts to clobber the UI of the app . 
45 - 50 ms (2592x1936) bit of stuttering and UI getting very unresponsive. 

So very very promising...need to clean up the app, better thread handling, add dual head, add camera control, etc. etc....

--[[User:Aegdss|aegdss]] 14:55:08, 2008-09-02 (CDT)

== Two heads are better... ==

Got some results attempting dual head. Managed to switch between sensors and get imagery from both, although there seems to be some issue with color and or syncs in the images. Looking into that now. But not bad for first time. Maybe I'm not stopping the compressor correctly, or not waiting long enough between stopping and starting. It currently takes about 3 seconds to do a switch (with messed up colors, but other than that working). This is kinda slow, so I may need to find a way to speed that up.

Using the php is pretty easy. Much nicer to have a bunch of custom scripts than to have to do everything by passing params to ccam.php. While I'd prefer a straight C interface with maybe a simple socket wrapper, I must admit that the php stuff makes it pretty easy.

--[[User:Aegdss|aegdss]] 15:37:58, 2008-09-03 (CDT)

Managed to get the "snapshot" mode working ok. Colors are messed up, but can acquire frames from both sensors. Here is the scripts used:

http://192.168.1.9/camera_demo.php

http://192.168.1.9/359/sensors_init.php

http://192.168.1.9/ccam.php?trig=async&mode=set

http://192.168.1.9/359/tests_for_96mhz.php

http://192.168.1.9/compressor.php?cmd=run

Then Repeat:

http://192.168.1.9/sync.php?role=self&fps=single

http://192.168.1.9:8081/torp/img/next/save

--[[User:Aegdss|aegdss]] 15:54:43, 2008-09-03 (CDT)

== Doh!!! ==

Important tip! When comparing images from a dual headed camera, make sure the iris's on both
lenses are open!!!!

Still don't fully understand phase setting, what is hitting sensor registers, etc.
I do fully understand the php interface and other various ajaxy scripts etc.

Weekend reading assignment is all src code. Hope to have SW done by end of next week, at least in some usable state, which I think is doable now.

--[[User:Aegdss|aegdss]] 16:51:49, 2008-09-05 (CDT)

User:Aegdss\Learning Curve

2008-09-05T21:51:49Z

Aegdss: /* progress notes. */

== Diary of getting up to speed ==

== Unboxing ==
--[[User:Aegdss|aegdss]] 09:24:28, 2008-08-08 (CDT)

Got the camera including a few cat-5 and rs-232 Dsub shell etc which was very nice.

Dont have a POE switch and didnt want to cannibalize a cable or open the
housing yet, so I bought a POE injector (POI-2000 from CP Technology via amazon).

Camera came right up, could connect via telnet and browser, could acquire images and
modify settings. UI seemed a bit flakey at times (using Firefox) but that could certainly
have been op error.

Changed IP to 192.168.1.9, so it would work on my lan.

Attempted to get VLC and mplayer to work, but didnt have too much luck. Streamer seemed to start
as evidenced by ps and indicator on web ui. But I couldn't get client apps to receive a stream. I did manage to get mplayer to start crashing so It must have been doing something :)

Gonna try streaming with linux client and then once that is all working go back to vista.

----
VLC should work at least up to HD resolution on any OS. (take the last stable version of VLC. VLC need to be compiled with a liblivemedia >= 2007.02.20) We officially support only patched MPlayer. (Here also, last stable MPlayer, liblivemedia >= 2007.02.20) The patch to apply is just in mplayer-1.0~rc2/libmpdemux/demux_rtp.cpp replace #define MAX_RTP_FRAME_SIZE 50000 by #define MAX_RTP_FRAME_SIZE 5000000.

--[[User:Polto|Alexandre.Poltorak]] 02:51, 9 August 2008 (CDT)

== Streaming ==

Yes, VLC seems to work when using HD or less resolution. VLC is a touch on the flaky side, It would crash when using a built in image capture device (not elphel camera). Also, I could only get vlc to work using unicast streaming (rtsp://192.168.0.9:554). But that could easily have been operator error. I'll look into that further later, but first want to test out a patched mplayer under windows. But once I set the frame rate correctly and used unicast I didn't have any problems.

VLC had bad latency, on the order of 2-3 seconds, which seemed independent of resolution. The web interface, used at the same time as the streamer, did NOT exhibit the same latency. PC CPU load was only 25% or so. The other SCINI team members reported "very low" latency using VLC under linux, so evidence points to an issue with vlc on windows.

Aside:
The AJAX interface works well and is nice if a bit intimidating for the neophyte user,
the tooltips help a lot. I'm curious what is the frame rate limiting factor here, I need to
take a peek at the code when I get a sec.

--[[User:Aegdss|aegdss]] 14:01:39, 2008-08-11 (UTC)

== Use the src... ==

Seems like the ajax ui eventually turns off the compressor if streaming is not on,
I didnt look at the code yet though.
----
Please use camvc2.html and not camvc (index.html), camvc2 treat the compressor and the streamer independently.
You can also do all the setup using only PHP: [[PHP Examples]], see camera_demo.php
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----

Managed to get pretty good performance using the fast server (port 8081). Just start the compressor with fpcf -jpeg and then read from 8081/img as fast as I could. Gonna write a small little app to do it and see how fast I can get it on windows.

Loaded src onto a ubuntu machine today using install_from_cvs script. Went pretty smooth with only a few glitches...

1) the tcpdump.org was down and ./install_elphel wants to grab libpcap from there. Just download it from somewhere else and put it in the ~/distfiles dir.
----
we will check it, normally it should take from the mirror automatically in this case.
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----

2) apt-get install lex yacc doesn't work. Those are in flex and bison though, so apt-get install flex bison gets them.
(This was corrected in the wiki docs...--[[User:Aegdss|aegdss]] 09:26:52, 2008-08-25 (CDT))

3) the manual install of the cris compiler had problems, but the binary distribution worked just fine.
----
Please have a look on: [[Elphel_Software_Kit_for_Ubuntu#For_developers:]]
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----
[[Elphel_Software_Kit_for_Ubuntu#For_developers:]]
were the docs I was following, (which are pretty good btw.) The line
"sudo apt-get install cvs build-essential lex byacc bison libglib2.0-dev tcl gettext libncurses5-dev patch zlib1g-dev" was a problem cause apt-get couldnt install lex. I think maybe if lex is replaced by flex it would be fine. I didnt really investigate further.

I also first tried to install the cris compiler using the docs on the same page. This failed in the final step (sudo ./install-cris-tools.) I did not note the error and just went straight to the binary package (which worked fine.). Of course this is more an issue with the axis script (install-cris-tools) rather than the wiki doc which seems correct in this case. I just noted it in case anyone else has the same issue and doesnt have the time to debug the install script. I think the problem with the install-cris script is probably machine (or distribution) dependent and may work just fine for most everyone else. FWIW I'm installing on a fairly stock ubuntu 8.04.

Overall the user experience for setting up the dev environment using the binary package install for the cris tools and then [http://downloads.sourceforge.net/elphel/elphel353_install_from_cvs.sh.tar.gz?modtime=1195003055&big_mirror=0 elphel353_install_from_cvs.sh] was really very nice and easy.

--[[User:Aegdss|aegdss]] 08:28:11, 2008-08-22 (CDT)

== SCINI stuff ==

We are going to try to use a dual headed setup with one sensor fwd and one looking down. So looking into using the 10359 and what exactly is the best operational method of doing that.

--[[User:Aegdss|aegdss]] 14:28:38, 2008-08-21 (CDT)

== Plunging into dual head ==

After getting a great amount of support from the elphel team,
I managed to successfully test the 10359 board. Although only
with one sensor module (the other I got from SCINI team didnt work, but they had mention that they thought that they had killed it (static, bad voltage, penguin attack?, who knows...).

I'm trying to procure another sensor board today.

But FWIW I got images easily through the 10359 using the following sequence of steps (provide by Alexandre Poltorak):

http://192.168.0.13/camera_demo.php

http://192.168.0.13/359/sensors_init.php

http://192.168.0.13/ccam.php?trig=async&mode=set

http://192.168.0.13/359/tests_for_96mhz.php

http://192.168.0.13/compressor.php?cmd=run

http://192.168.0.13/sync.php?role=self&fps=single

http://192.168.0.13:8081/img

Gonna dig through those scripts now, while awaiting another sensor board.

--[[User:Aegdss|aegdss]] 09:21:27, 2008-08-25 (CDT)

== Feet to the fire ==

Nothing like dangerously close deadlines to speed up the learning process...

Current plan is to have a c#/wpf dual head camera control app that also allows for science annotation...All using http, no rtp.

Actually making good progress. Playing/reading all the php scripts.
Got multi-threaded http image reader/display going on windows (C#, WPF). It seems
plenty fast, and no noticeably latency: This is using a single sensor running through the 10359 in
"Transparent" mode.

(image request, image read, display set source, display invalidate: )
8-9 ms (320x240) 
12-14 ms (640x480) 
19 - 20 ms (1296x960) but starts to clobber the UI of the app . 
45 - 50 ms (2592x1936) bit of stuttering and UI getting very unresponsive. 

So very very promising...need to clean up the app, better thread handling, add dual head, add camera control, etc. etc....

--[[User:Aegdss|aegdss]] 14:55:08, 2008-09-02 (CDT)

== Two heads are better... ==

Got some results attempting dual head. Managed to switch between sensors and get imagery from both, although there seems to be some issue with color and or syncs in the images. Looking into that now. But not bad for first time. Maybe I'm not stopping the compressor correctly, or not waiting long enough between stopping and starting. It currently takes about 3 seconds to do a switch (with messed up colors, but other than that working). This is kinda slow, so I may need to find a way to speed that up.

Using the php is pretty easy. Much nicer to have a bunch of custom scripts than to have to do everything by passing params to ccam.php. While I'd prefer a straight C interface with maybe a simple socket wrapper, I must admit that the php stuff makes it pretty easy.

--[[User:Aegdss|aegdss]] 15:37:58, 2008-09-03 (CDT)

Managed to get the "snapshot" mode working ok. Colors are messed up, but can acquire frames from both sensors. Here is the scripts used:

http://192.168.1.9/camera_demo.php

http://192.168.1.9/359/sensors_init.php

http://192.168.1.9/ccam.php?trig=async&mode=set

http://192.168.1.9/359/tests_for_96mhz.php

http://192.168.1.9/compressor.php?cmd=run

Then Repeat:

http://192.168.1.9/sync.php?role=self&fps=single

http://192.168.1.9:8081/torp/img/next/save

--[[User:Aegdss|aegdss]] 15:54:43, 2008-09-03 (CDT)

== Doh!!! ==

Important tip! When comparing images from a dual headed camera, make sure the iris's on both
lenses are open!!!!

Still don't fully understand phase setting, what is hitting sensor registers, etc.
I do fully understand the php interface and other various ajaxy scripts etc.

Weekend reading assignment is all src code. Hope to have SW done by end of next week, at least in some usable state, which I think is doable now.

--[[User:Aegdss|aegdss]] 16:51:49, 2008-09-05 (CDT)

User talk:Bnewbold

2008-09-05T21:39:00Z

Aegdss: /* ROV */

User:Aegdss\Learning Curve

2008-09-03T20:54:43Z

Aegdss: /* Two heads are better... */

== Diary of getting up to speed ==

== Unboxing ==
--[[User:Aegdss|aegdss]] 09:24:28, 2008-08-08 (CDT)

Got the camera including a few cat-5 and rs-232 Dsub shell etc which was very nice.

Dont have a POE switch and didnt want to cannibalize a cable or open the
housing yet, so I bought a POE injector (POI-2000 from CP Technology via amazon).

Camera came right up, could connect via telnet and browser, could acquire images and
modify settings. UI seemed a bit flakey at times (using Firefox) but that could certainly
have been op error.

Changed IP to 192.168.1.9, so it would work on my lan.

Attempted to get VLC and mplayer to work, but didnt have too much luck. Streamer seemed to start
as evidenced by ps and indicator on web ui. But I couldn't get client apps to receive a stream. I did manage to get mplayer to start crashing so It must have been doing something :)

Gonna try streaming with linux client and then once that is all working go back to vista.

----
VLC should work at least up to HD resolution on any OS. (take the last stable version of VLC. VLC need to be compiled with a liblivemedia >= 2007.02.20) We officially support only patched MPlayer. (Here also, last stable MPlayer, liblivemedia >= 2007.02.20) The patch to apply is just in mplayer-1.0~rc2/libmpdemux/demux_rtp.cpp replace #define MAX_RTP_FRAME_SIZE 50000 by #define MAX_RTP_FRAME_SIZE 5000000.

--[[User:Polto|Alexandre.Poltorak]] 02:51, 9 August 2008 (CDT)

== Streaming ==

Yes, VLC seems to work when using HD or less resolution. VLC is a touch on the flaky side, It would crash when using a built in image capture device (not elphel camera). Also, I could only get vlc to work using unicast streaming (rtsp://192.168.0.9:554). But that could easily have been operator error. I'll look into that further later, but first want to test out a patched mplayer under windows. But once I set the frame rate correctly and used unicast I didn't have any problems.

VLC had bad latency, on the order of 2-3 seconds, which seemed independent of resolution. The web interface, used at the same time as the streamer, did NOT exhibit the same latency. PC CPU load was only 25% or so. The other SCINI team members reported "very low" latency using VLC under linux, so evidence points to an issue with vlc on windows.

Aside:
The AJAX interface works well and is nice if a bit intimidating for the neophyte user,
the tooltips help a lot. I'm curious what is the frame rate limiting factor here, I need to
take a peek at the code when I get a sec.

--[[User:Aegdss|aegdss]] 14:01:39, 2008-08-11 (UTC)

== Use the src... ==

Seems like the ajax ui eventually turns off the compressor if streaming is not on,
I didnt look at the code yet though.
----
Please use camvc2.html and not camvc (index.html), camvc2 treat the compressor and the streamer independently.
You can also do all the setup using only PHP: [[PHP Examples]], see camera_demo.php
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----

Managed to get pretty good performance using the fast server (port 8081). Just start the compressor with fpcf -jpeg and then read from 8081/img as fast as I could. Gonna write a small little app to do it and see how fast I can get it on windows.

Loaded src onto a ubuntu machine today using install_from_cvs script. Went pretty smooth with only a few glitches...

1) the tcpdump.org was down and ./install_elphel wants to grab libpcap from there. Just download it from somewhere else and put it in the ~/distfiles dir.
----
we will check it, normally it should take from the mirror automatically in this case.
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----

2) apt-get install lex yacc doesn't work. Those are in flex and bison though, so apt-get install flex bison gets them.
(This was corrected in the wiki docs...--[[User:Aegdss|aegdss]] 09:26:52, 2008-08-25 (CDT))

3) the manual install of the cris compiler had problems, but the binary distribution worked just fine.
----
Please have a look on: [[Elphel_Software_Kit_for_Ubuntu#For_developers:]]
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----
[[Elphel_Software_Kit_for_Ubuntu#For_developers:]]
were the docs I was following, (which are pretty good btw.) The line
"sudo apt-get install cvs build-essential lex byacc bison libglib2.0-dev tcl gettext libncurses5-dev patch zlib1g-dev" was a problem cause apt-get couldnt install lex. I think maybe if lex is replaced by flex it would be fine. I didnt really investigate further.

I also first tried to install the cris compiler using the docs on the same page. This failed in the final step (sudo ./install-cris-tools.) I did not note the error and just went straight to the binary package (which worked fine.). Of course this is more an issue with the axis script (install-cris-tools) rather than the wiki doc which seems correct in this case. I just noted it in case anyone else has the same issue and doesnt have the time to debug the install script. I think the problem with the install-cris script is probably machine (or distribution) dependent and may work just fine for most everyone else. FWIW I'm installing on a fairly stock ubuntu 8.04.

Overall the user experience for setting up the dev environment using the binary package install for the cris tools and then [http://downloads.sourceforge.net/elphel/elphel353_install_from_cvs.sh.tar.gz?modtime=1195003055&big_mirror=0 elphel353_install_from_cvs.sh] was really very nice and easy.

--[[User:Aegdss|aegdss]] 08:28:11, 2008-08-22 (CDT)

== SCINI stuff ==

We are going to try to use a dual headed setup with one sensor fwd and one looking down. So looking into using the 10359 and what exactly is the best operational method of doing that.

--[[User:Aegdss|aegdss]] 14:28:38, 2008-08-21 (CDT)

== Plunging into dual head ==

After getting a great amount of support from the elphel team,
I managed to successfully test the 10359 board. Although only
with one sensor module (the other I got from SCINI team didnt work, but they had mention that they thought that they had killed it (static, bad voltage, penguin attack?, who knows...).

I'm trying to procure another sensor board today.

But FWIW I got images easily through the 10359 using the following sequence of steps (provide by Alexandre Poltorak):

http://192.168.0.13/camera_demo.php

http://192.168.0.13/359/sensors_init.php

http://192.168.0.13/ccam.php?trig=async&mode=set

http://192.168.0.13/359/tests_for_96mhz.php

http://192.168.0.13/compressor.php?cmd=run

http://192.168.0.13/sync.php?role=self&fps=single

http://192.168.0.13:8081/img

Gonna dig through those scripts now, while awaiting another sensor board.

--[[User:Aegdss|aegdss]] 09:21:27, 2008-08-25 (CDT)

== Feet to the fire ==

Nothing like dangerously close deadlines to speed up the learning process...

Current plan is to have a c#/wpf dual head camera control app that also allows for science annotation...All using http, no rtp.

Actually making good progress. Playing/reading all the php scripts.
Got multi-threaded http image reader/display going on windows (C#, WPF). It seems
plenty fast, and no noticeably latency: This is using a single sensor running through the 10359 in
"Transparent" mode.

(image request, image read, display set source, display invalidate: )
8-9 ms (320x240) 
12-14 ms (640x480) 
19 - 20 ms (1296x960) but starts to clobber the UI of the app . 
45 - 50 ms (2592x1936) bit of stuttering and UI getting very unresponsive. 

So very very promising...need to clean up the app, better thread handling, add dual head, add camera control, etc. etc....

--[[User:Aegdss|aegdss]] 14:55:08, 2008-09-02 (CDT)

== Two heads are better... ==

Got some results attempting dual head. Managed to switch between sensors and get imagery from both, although there seems to be some issue with color and or syncs in the images. Looking into that now. But not bad for first time. Maybe I'm not stopping the compressor correctly, or not waiting long enough between stopping and starting. It currently takes about 3 seconds to do a switch (with messed up colors, but other than that working). This is kinda slow, so I may need to find a way to speed that up.

Using the php is pretty easy. Much nicer to have a bunch of custom scripts than to have to do everything by passing params to ccam.php. While I'd prefer a straight C interface with maybe a simple socket wrapper, I must admit that the php stuff makes it pretty easy.

--[[User:Aegdss|aegdss]] 15:37:58, 2008-09-03 (CDT)

Managed to get the "snapshot" mode working ok. Colors are messed up, but can acquire frames from both sensors. Here is the scripts used:

http://192.168.1.9/camera_demo.php

http://192.168.1.9/359/sensors_init.php

http://192.168.1.9/ccam.php?trig=async&mode=set

http://192.168.1.9/359/tests_for_96mhz.php

http://192.168.1.9/compressor.php?cmd=run

Then Repeat:

http://192.168.1.9/sync.php?role=self&fps=single

http://192.168.1.9:8081/torp/img/next/save

--[[User:Aegdss|aegdss]] 15:54:43, 2008-09-03 (CDT)

User:Aegdss\Learning Curve

2008-09-03T20:37:58Z

Aegdss: /* Dual head 1st attempt */

== Diary of getting up to speed ==

== Unboxing ==
--[[User:Aegdss|aegdss]] 09:24:28, 2008-08-08 (CDT)

Got the camera including a few cat-5 and rs-232 Dsub shell etc which was very nice.

Dont have a POE switch and didnt want to cannibalize a cable or open the
housing yet, so I bought a POE injector (POI-2000 from CP Technology via amazon).

Camera came right up, could connect via telnet and browser, could acquire images and
modify settings. UI seemed a bit flakey at times (using Firefox) but that could certainly
have been op error.

Changed IP to 192.168.1.9, so it would work on my lan.

Attempted to get VLC and mplayer to work, but didnt have too much luck. Streamer seemed to start
as evidenced by ps and indicator on web ui. But I couldn't get client apps to receive a stream. I did manage to get mplayer to start crashing so It must have been doing something :)

Gonna try streaming with linux client and then once that is all working go back to vista.

----
VLC should work at least up to HD resolution on any OS. (take the last stable version of VLC. VLC need to be compiled with a liblivemedia >= 2007.02.20) We officially support only patched MPlayer. (Here also, last stable MPlayer, liblivemedia >= 2007.02.20) The patch to apply is just in mplayer-1.0~rc2/libmpdemux/demux_rtp.cpp replace #define MAX_RTP_FRAME_SIZE 50000 by #define MAX_RTP_FRAME_SIZE 5000000.

--[[User:Polto|Alexandre.Poltorak]] 02:51, 9 August 2008 (CDT)

== Streaming ==

Yes, VLC seems to work when using HD or less resolution. VLC is a touch on the flaky side, It would crash when using a built in image capture device (not elphel camera). Also, I could only get vlc to work using unicast streaming (rtsp://192.168.0.9:554). But that could easily have been operator error. I'll look into that further later, but first want to test out a patched mplayer under windows. But once I set the frame rate correctly and used unicast I didn't have any problems.

VLC had bad latency, on the order of 2-3 seconds, which seemed independent of resolution. The web interface, used at the same time as the streamer, did NOT exhibit the same latency. PC CPU load was only 25% or so. The other SCINI team members reported "very low" latency using VLC under linux, so evidence points to an issue with vlc on windows.

Aside:
The AJAX interface works well and is nice if a bit intimidating for the neophyte user,
the tooltips help a lot. I'm curious what is the frame rate limiting factor here, I need to
take a peek at the code when I get a sec.

--[[User:Aegdss|aegdss]] 14:01:39, 2008-08-11 (UTC)

== Use the src... ==

Seems like the ajax ui eventually turns off the compressor if streaming is not on,
I didnt look at the code yet though.
----
Please use camvc2.html and not camvc (index.html), camvc2 treat the compressor and the streamer independently.
You can also do all the setup using only PHP: [[PHP Examples]], see camera_demo.php
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----

Managed to get pretty good performance using the fast server (port 8081). Just start the compressor with fpcf -jpeg and then read from 8081/img as fast as I could. Gonna write a small little app to do it and see how fast I can get it on windows.

Loaded src onto a ubuntu machine today using install_from_cvs script. Went pretty smooth with only a few glitches...

1) the tcpdump.org was down and ./install_elphel wants to grab libpcap from there. Just download it from somewhere else and put it in the ~/distfiles dir.
----
we will check it, normally it should take from the mirror automatically in this case.
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----

2) apt-get install lex yacc doesn't work. Those are in flex and bison though, so apt-get install flex bison gets them.
(This was corrected in the wiki docs...--[[User:Aegdss|aegdss]] 09:26:52, 2008-08-25 (CDT))

3) the manual install of the cris compiler had problems, but the binary distribution worked just fine.
----
Please have a look on: [[Elphel_Software_Kit_for_Ubuntu#For_developers:]]
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----
[[Elphel_Software_Kit_for_Ubuntu#For_developers:]]
were the docs I was following, (which are pretty good btw.) The line
"sudo apt-get install cvs build-essential lex byacc bison libglib2.0-dev tcl gettext libncurses5-dev patch zlib1g-dev" was a problem cause apt-get couldnt install lex. I think maybe if lex is replaced by flex it would be fine. I didnt really investigate further.

I also first tried to install the cris compiler using the docs on the same page. This failed in the final step (sudo ./install-cris-tools.) I did not note the error and just went straight to the binary package (which worked fine.). Of course this is more an issue with the axis script (install-cris-tools) rather than the wiki doc which seems correct in this case. I just noted it in case anyone else has the same issue and doesnt have the time to debug the install script. I think the problem with the install-cris script is probably machine (or distribution) dependent and may work just fine for most everyone else. FWIW I'm installing on a fairly stock ubuntu 8.04.

Overall the user experience for setting up the dev environment using the binary package install for the cris tools and then [http://downloads.sourceforge.net/elphel/elphel353_install_from_cvs.sh.tar.gz?modtime=1195003055&big_mirror=0 elphel353_install_from_cvs.sh] was really very nice and easy.

--[[User:Aegdss|aegdss]] 08:28:11, 2008-08-22 (CDT)

== SCINI stuff ==

We are going to try to use a dual headed setup with one sensor fwd and one looking down. So looking into using the 10359 and what exactly is the best operational method of doing that.

--[[User:Aegdss|aegdss]] 14:28:38, 2008-08-21 (CDT)

== Plunging into dual head ==

After getting a great amount of support from the elphel team,
I managed to successfully test the 10359 board. Although only
with one sensor module (the other I got from SCINI team didnt work, but they had mention that they thought that they had killed it (static, bad voltage, penguin attack?, who knows...).

I'm trying to procure another sensor board today.

But FWIW I got images easily through the 10359 using the following sequence of steps (provide by Alexandre Poltorak):

http://192.168.0.13/camera_demo.php

http://192.168.0.13/359/sensors_init.php

http://192.168.0.13/ccam.php?trig=async&mode=set

http://192.168.0.13/359/tests_for_96mhz.php

http://192.168.0.13/compressor.php?cmd=run

http://192.168.0.13/sync.php?role=self&fps=single

http://192.168.0.13:8081/img

Gonna dig through those scripts now, while awaiting another sensor board.

--[[User:Aegdss|aegdss]] 09:21:27, 2008-08-25 (CDT)

== Feet to the fire ==

Nothing like dangerously close deadlines to speed up the learning process...

Current plan is to have a c#/wpf dual head camera control app that also allows for science annotation...All using http, no rtp.

Actually making good progress. Playing/reading all the php scripts.
Got multi-threaded http image reader/display going on windows (C#, WPF). It seems
plenty fast, and no noticeably latency: This is using a single sensor running through the 10359 in
"Transparent" mode.

(image request, image read, display set source, display invalidate: )
8-9 ms (320x240) 
12-14 ms (640x480) 
19 - 20 ms (1296x960) but starts to clobber the UI of the app . 
45 - 50 ms (2592x1936) bit of stuttering and UI getting very unresponsive. 

So very very promising...need to clean up the app, better thread handling, add dual head, add camera control, etc. etc....

--[[User:Aegdss|aegdss]] 14:55:08, 2008-09-02 (CDT)

== Two heads are better... ==

Got some results attempting dual head. Managed to switch between sensors and get imagery from both, although there seems to be some issue with color and or syncs in the images. Looking into that now. But not bad for first time. Maybe I'm not stopping the compressor correctly, or not waiting long enough between stopping and starting. It currently takes about 3 seconds to do a switch (with messed up colors, but other than that working). This is kinda slow, so I may need to find a way to speed that up.

Using the php is pretty easy. Much nicer to have a bunch of custom scripts than to have to do everything by passing params to ccam.php. While I'd prefer a straight C interface with maybe a simple socket wrapper, I must admit that the php stuff makes it pretty easy.

--[[User:Aegdss|aegdss]] 15:37:58, 2008-09-03 (CDT)

User:Aegdss\Learning Curve

2008-09-02T19:55:08Z

Aegdss: /* Progress update*/

== Diary of getting up to speed ==

== Unboxing ==
--[[User:Aegdss|aegdss]] 09:24:28, 2008-08-08 (CDT)

Got the camera including a few cat-5 and rs-232 Dsub shell etc which was very nice.

Dont have a POE switch and didnt want to cannibalize a cable or open the
housing yet, so I bought a POE injector (POI-2000 from CP Technology via amazon).

Camera came right up, could connect via telnet and browser, could acquire images and
modify settings. UI seemed a bit flakey at times (using Firefox) but that could certainly
have been op error.

Changed IP to 192.168.1.9, so it would work on my lan.

Attempted to get VLC and mplayer to work, but didnt have too much luck. Streamer seemed to start
as evidenced by ps and indicator on web ui. But I couldn't get client apps to receive a stream. I did manage to get mplayer to start crashing so It must have been doing something :)

Gonna try streaming with linux client and then once that is all working go back to vista.

----
VLC should work at least up to HD resolution on any OS. (take the last stable version of VLC. VLC need to be compiled with a liblivemedia >= 2007.02.20) We officially support only patched MPlayer. (Here also, last stable MPlayer, liblivemedia >= 2007.02.20) The patch to apply is just in mplayer-1.0~rc2/libmpdemux/demux_rtp.cpp replace #define MAX_RTP_FRAME_SIZE 50000 by #define MAX_RTP_FRAME_SIZE 5000000.

--[[User:Polto|Alexandre.Poltorak]] 02:51, 9 August 2008 (CDT)

== Streaming ==

Yes, VLC seems to work when using HD or less resolution. VLC is a touch on the flaky side, It would crash when using a built in image capture device (not elphel camera). Also, I could only get vlc to work using unicast streaming (rtsp://192.168.0.9:554). But that could easily have been operator error. I'll look into that further later, but first want to test out a patched mplayer under windows. But once I set the frame rate correctly and used unicast I didn't have any problems.

VLC had bad latency, on the order of 2-3 seconds, which seemed independent of resolution. The web interface, used at the same time as the streamer, did NOT exhibit the same latency. PC CPU load was only 25% or so. The other SCINI team members reported "very low" latency using VLC under linux, so evidence points to an issue with vlc on windows.

Aside:
The AJAX interface works well and is nice if a bit intimidating for the neophyte user,
the tooltips help a lot. I'm curious what is the frame rate limiting factor here, I need to
take a peek at the code when I get a sec.

--[[User:Aegdss|aegdss]] 14:01:39, 2008-08-11 (UTC)

== Use the src... ==

Seems like the ajax ui eventually turns off the compressor if streaming is not on,
I didnt look at the code yet though.
----
Please use camvc2.html and not camvc (index.html), camvc2 treat the compressor and the streamer independently.
You can also do all the setup using only PHP: [[PHP Examples]], see camera_demo.php
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----

Managed to get pretty good performance using the fast server (port 8081). Just start the compressor with fpcf -jpeg and then read from 8081/img as fast as I could. Gonna write a small little app to do it and see how fast I can get it on windows.

Loaded src onto a ubuntu machine today using install_from_cvs script. Went pretty smooth with only a few glitches...

1) the tcpdump.org was down and ./install_elphel wants to grab libpcap from there. Just download it from somewhere else and put it in the ~/distfiles dir.
----
we will check it, normally it should take from the mirror automatically in this case.
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----

2) apt-get install lex yacc doesn't work. Those are in flex and bison though, so apt-get install flex bison gets them.
(This was corrected in the wiki docs...--[[User:Aegdss|aegdss]] 09:26:52, 2008-08-25 (CDT))

3) the manual install of the cris compiler had problems, but the binary distribution worked just fine.
----
Please have a look on: [[Elphel_Software_Kit_for_Ubuntu#For_developers:]]
--[[User:Polto|Alexandre.Poltorak]] 15:42, 21 August 2008 (CDT)
----
[[Elphel_Software_Kit_for_Ubuntu#For_developers:]]
were the docs I was following, (which are pretty good btw.) The line
"sudo apt-get install cvs build-essential lex byacc bison libglib2.0-dev tcl gettext libncurses5-dev patch zlib1g-dev" was a problem cause apt-get couldnt install lex. I think maybe if lex is replaced by flex it would be fine. I didnt really investigate further.

I also first tried to install the cris compiler using the docs on the same page. This failed in the final step (sudo ./install-cris-tools.) I did not note the error and just went straight to the binary package (which worked fine.). Of course this is more an issue with the axis script (install-cris-tools) rather than the wiki doc which seems correct in this case. I just noted it in case anyone else has the same issue and doesnt have the time to debug the install script. I think the problem with the install-cris script is probably machine (or distribution) dependent and may work just fine for most everyone else. FWIW I'm installing on a fairly stock ubuntu 8.04.

Overall the user experience for setting up the dev environment using the binary package install for the cris tools and then [http://downloads.sourceforge.net/elphel/elphel353_install_from_cvs.sh.tar.gz?modtime=1195003055&big_mirror=0 elphel353_install_from_cvs.sh] was really very nice and easy.

--[[User:Aegdss|aegdss]] 08:28:11, 2008-08-22 (CDT)

== SCINI stuff ==

We are going to try to use a dual headed setup with one sensor fwd and one looking down. So looking into using the 10359 and what exactly is the best operational method of doing that.

--[[User:Aegdss|aegdss]] 14:28:38, 2008-08-21 (CDT)

== Plunging into dual head ==

After getting a great amount of support from the elphel team,
I managed to successfully test the 10359 board. Although only
with one sensor module (the other I got from SCINI team didnt work, but they had mention that they thought that they had killed it (static, bad voltage, penguin attack?, who knows...).

I'm trying to procure another sensor board today.

But FWIW I got images easily through the 10359 using the following sequence of steps (provide by Alexandre Poltorak):

http://192.168.0.13/camera_demo.php 
http://192.168.0.13/359/sensors_init.php 
http://192.168.0.13/ccam.php?trig=async&mode=set 
http://192.168.0.13/359/tests_for_96mhz.php 
http://192.168.0.13/compressor.php?cmd=run 
 
http://192.168.0.13/sync.php?role=self&fps=single 
http://192.168.0.13:8081/img 

Gonna dig through those scripts now, while awaiting another sensor board.

--[[User:Aegdss|aegdss]] 09:21:27, 2008-08-25 (CDT)

== Feet to the fire ==

Nothing like dangerously close deadlines to speed up the learning process...

Current plan is to have a c#/wpf dual head camera control app that also allows for science annotation...All using http, no rtp.

Actually making good progress. Playing/reading all the php scripts.
Got multi-threaded http image reader/display going on windows (C#, WPF). It seems
plenty fast, and no noticeably latency: This is using a single sensor running through the 10359 in
"Transparent" mode.

(image request, image read, display set source, display invalidate: )
8-9 ms (320x240) 
12-14 ms (640x480) 
19 - 20 ms (1296x960) but starts to clobber the UI of the app . 
45 - 50 ms (2592x1936) bit of stuttering and UI getting very unresponsive. 

So very very promising...need to clean up the app, better thread handling, add dual head, add camera control, etc. etc....

--[[User:Aegdss|aegdss]] 14:55:08, 2008-09-02 (CDT)

User:Aegdss\Learning Curve

2008-08-25T14:26:52Z

Aegdss: /* Use the src... UPDATE*/

User:Aegdss\Learning Curve

2008-08-25T14:21:27Z

Aegdss: /* SCINI stuff -- dual head*/

Roadmap

2008-08-23T15:17:29Z

Aegdss: Minor grammar cleanup

== Background ==
Elphel was started in 2001 (Magna, UT USA) when I quit my job inspired by the possibilities that Free Software gives to developers (it was not so obvious for my at the time employer). All the projects were covered in [http://www.linuxdevices.com LinuxDevices] (complete list on the articles is available [http://www.elphel.com/articles/index.html here]). For several years Elphel was a one-man company, in January 2004 I wrote an article [http://www.computerra.ru/hitech/tech/31862/ Taming of the Iron Penguin (Russian)] in the largest Russain computer-related magazine [http://www.computerra.ru Computerra] and announced there a competition among the software developers for the best video streamer to run in the camera. That was a good idea and after the competition itself was over most of the developers remained in the Elphel team. At first - as volunteers, later - as full/part time employees.

Not all of these developers live in Russia - two, including the winner of the competition are from Kiev, Ukraine. But still all of them know Russian much better than English and so most of our technical discussions were on our private Russian-language forum. So far I failed to move these discussions to the broader audience but believe that Wiki technology can help. Here we will mantain most of the site in English but still have some pages/discussions in Russian, translating documents as we go. Or when somebody else needs it and is not satisfied with [http://babelfish.altavista.com Babelfish] automatic translation. We will try to keep English pages current - anyway even in Elphel not everybody knows Russian.

Please excuse not-so-good English of our developers and feel free to fix the errors if you see them.

--[[User:Andrey.filippov|Andrey.filippov]] 15:34, 22 September 2005 (CST)
== Update on 353/363 cameras ==
There is preliminary documentation for [[353|the new model 353/353 cameras hardware here]]

353/363 cameras use software based on Linux kernel 2.6 (currently - 2.6.19). There will be more changes in software as we used different web server (lighttpd) and included PHP (as fastCGI application).

More information on software will follow, you may already find code here:
* [http://sourceforge.net/project/showfiles.php?group_id=105686&package_id=222883 elphel353 software package @ Sourceforge]
* [http://elphel.cvs.sourceforge.net/elphel/elphel353/elphel353 CVS @ Sourceforge]

== Software Architecture of Elphel 3x3 cameras ==
Software in the Elphel cameras started from [http://developer.axis.com/ Axis Developer Boards Software] and was amended for the camera specific functions. It was modified to work with newer hardware (models 303-313/323-333), support more features and now seems to be a good time to make a major redesign instead of applying incremental changes.

Some discussion already started in Russian here - [[Nc3x3]]

Related to the architecture are the [[#Camera Interface]] and the [[#Client Software]]

Elphel will continue developing a web browser based user interface with [http://en.wikipedia.org/wiki/AJAX AJAX] technology. That will require developing/modifying player plugins controllable from [http://en.wikipedia.org/wiki/Javascript JavaScript] and implementing specific features needed for video surveillance applications - multiple camera views on the same page, digital PTZ (inside the hi-res incoming stream) and temporal decimation (reducing frame rate) that uses as little CPU resources as possible.

The web-based user interface can be especially useful for open hardware as it reduces the entrance threshold for the developer who would like to customize the cameras functionality - regular web development tools are sufficient for the job.

=== Camera Interface ===

The camera now has two alternative APIs:

==== ccam.cgi ====

The original interface that supports most camera features - [[ccam.cgi]]

and

==== PHP API ====

=====[[PHP_in_Elphel_cameras| Using PHP in Elphel camera]]=====

=====[[Elphel PHP constants]]=====

=====[[PHP Examples]]=====

==== JavaScript library ====
We will create a set of javascript routines to control the cameras, which can be used in a different AJAX applications.
See [[JavaScript API]]

==== Web Interface Ideas ====
There are many new ideas for the web-control-panel. They are being [[Web Interface Ideas|developed]]

==== [[How to obtain an image or a video from an Elphel 353 camera?]] ====

=== Camera Software ===

==== Axis based SDK for GNU/Linux on EtraxFS ====
Our camera has two main CPUs: EtraxFS running GNU/Linux and Xilinx Spartan 3e FPGA.

The firmware of our cameras is based on [http://developer.axis.com/wiki/doku.php?id=axis:sdk, Axis SDK]. Sources & binaries of our firmwares can be downloaded from [http://sourceforge.net/project/showfiles.php?group_id=105686&package_id=222883, SourceForge project].

==== FPGA bitstream ====
Elphel uses Xilinx Spartant 3e FPGA for image/video encoding.

The FPGA code is distributed under [http://www.gnu.org/licenses/gpl.html. GNU/GPL v3 License].

[http://sourceforge.net/project/showfiles.php?group_id=105686&package_id=184538, VDT Eclipse plugin] can be used to edit Verilog code of the camera. Xilinx WebPACK ISE is free but the download is restricted, each end-user should register. That is why we did not include it in our [[ElphelSoftwareKit]], but you can download it from [http://www.xilinx.com/ise/logic_design_prod/webpack.htm, Xilinx web site.]

===== [[FPGA_Development_in_Elphel_cameras]] =====
This section discribes how to setup the environment for [[FPGA_Development_in_Elphel_cameras|FPGA development with Elphel cameras]].

==== How to hack ? ====
If you intend to modify source code (GNU/Linux or FPGA), download [[ElphelSoftwareKit]] and live-boot, or better yet install it on your (descent) computer.

But here are several things you can hack already with some softwares in the camera:

===== telnetd =====
By default the camera runs telnetd. Login "root", password "pass". You can telnet to the camera and explore the power of a full GNU/Linux distribution.

===== [[fpcf]] =====

You can use fpcf to adjust some FPGA settings. ''use it very carefully !! it may be dangerous and may destroy your hardware.''

===== hello =====
The Hello program is a little script by Andrey to [[Known problems | fix]] a stuck sensor.

==== File systems ====
[[333_File_System]]

==== Elphel 353 camera Unicast & Multicast RTSP streamer ====

The Elphel 353 camera is capable of streaming OGM/MJPEG via RTSP on Unicast or Multicast.

The streamer can be tuned via /etc/streamer.conf & /etc/image.conf (for syntax of image.conf have a look to [[Ccam.cgi]])

==== Control Panel ====
The [[Control Panel]] project is a simple page on the cameras to access some commonly used functions, without having to telnet into the camera.

=== Client Software ===

==== [[MPlayer]] ====
MPlayer is the main player for Elphel cameras. We have patches for MPlayer to make it compatible with a 3-5MPix resolution stream. We are in constant contact with MPlayer's team to integrate our patches to the mainstream. Patches for source code are accessible on our Source Forge project, the compiled package is only for Debian/Ubuntu on i386 architecture.

==== [[VLC]] ====

VLC is a free cross-platform media player. It supports a large number of multimedia formats, without the need for additional codecs. It can also be used as a streaming server, with extended features (video on demand, on the fly transcoding, ...)

====GSTreamer====

GSTreamer is a great free software that can be used with Elphel cameras in many different ways.

=====[[Elphel_Camera_Remote_Audio_using_GStreamer|Mux video & remote audio source]]=====
Describe how to use an Elphel 333/353 camera with MJPG in unicast or multicast stream and mux the video with PC's microphone and restream it on internet with a more suitable codec.

=====[[Make_a_movie_from_JPEG_images_using_gstreamer|make a movie from JPEG images]]=====
Compress many JPEG images into a OGG/Theora video.

=====[[Convert OGM/MJPEG to OGG/Theora]]=====
Transcode OGM/MJPEG video to a OGG/Theora video codec.

==== [[Talk:Recorder|Recorder]] ====
We will start a new recorder for a MJPEG RTP stream.
It will be a small standalone program, which will take a multicast IP address and port, receive a stream and record it to files or to stdout.
The most important thing with the recorder is to avoid frame drops (maybe something can be done with network buffering) and control them using timestamps.
Also, the recorder must provide manageable files (under 2GB), but with zero drops between them.

==== Plugins for browsers ====
[[GenReS|GenReS plugin]]

==== [[HTML Video Surveillance]] ====
[http://sourceforge.net/project/showfiles.php?group_id=105686&package_id=138717&release_id=358392 Multiple camera view HTML page] is based on [[GenReS |GenReS plugin]] for [http://www.mozilla.org/ Mozilla/FireFox].
Currently working: scrolling by picture dragging (digital PTZ), camera selection, zoom switch, automatic detection of stream stop by timeout.
List of camera addresses is now editable manually. It will be automatically generated in the [[Live CD]].
The page will run recording software by user request. Video will be saved to a fixed directory and split into separate files with a tunable number of frames.
Main parameters for video capture will be changeable from the page.
The page can later be used in the [[#Video Server]].

==== [[ElphelSoftwareKit]] ====
The Elphel Software Kit DVD contains software for camera users and developers.
The live DVD is based on [http://ubuntu.com/ Ubuntu Feisty].

Currently we only have a DVD for the i686 architecture.

The idea of keeping as full a Ubuntu as possible was to introduce GNU/Linux to the camera users who had never had this experience before.

One of the major additions is a preinstalled camera development environment based on [http://www.eclipse.org Eclipse]) to simplify the modification of the camera code. Again - don't forget that many of those future developers now only use Visual Studio (or whatever it is called?) and GNU/Linux can be somewhat alien to them. This environment allows them to start playing with their code without prior knowledge of the GNU/Linux software development process.

It can be useful for hardware/fpga developers too - to be able to write some code to support the hardware features without spending too much time on mastering the software development process.

==== [[Demosaic on client side]] ====
Our actual FPGA code on the camera uses a very simple algorithm to calculate YCbCr from the Bayer pixels. It uses just a 3x3 block of neighbors. The other point is that this algorithm is time consuming and with the 5MPix sensor the FPGA became the bottleneck. So we have added a special JP4 mode that bypasses the Demosaic in the FPGA and provides an image with pixels in each 16x16 macroblock that are rearranged to separate Bayer colors in individual 8x8 blocks, then encoded as monochrome. Demosaic will be applied during post-processing on the host PC. This section describe different algorithms and implementations used to provide this functionality.

== [[Network configuration]] ==
This section describe proper network configurations for the camera and the connected computer.

It also discuss some network hacks, wireless cards and gateways tested.

== Camera hardware ==
==== [[353]]/363 series ====
==== Basic Elphel 353 camera ====

Basic Elphel 353 Network camera is composed of:
* [[10353]] (processor board w/ CPU and FPGA)
* [[10338]] (sensor board for Micron MT9P031/MT9P001 5MPix)
* [[standard enclosure design for 353 and C/CS mount lenses]]

==== Basic Elphel 363 camera ====

* [[10353]] (processor board w/ CPU and FPGA)
* Kodak CCD [[10342]] (CCD Interface Board) with [[10347]]
* standard enclosure for Elphel 363

==== Add ons ====
===== [[10359]] (multi-sensor board/multifunction multiplexer) =====
===== [[10357]] (solid state memory) =====
===== [[10349]] (interface board: IDE, USB1.1, RS232, ...) =====

==== USB devices tested with Elphel 353 ====

Elphel 353 camera with 10349 extension boards have 1 external and 3 internal USB 1.1 connectors.

This section of the wiki describe all USB hardware what was tested with Elphel 353 camera.

===== Audio =====
===== Blue Tooth =====

USB-BlueTooth keys was tested with Elphel 353 (with 10349 board). One of the goal is to create a [[general propose bluetooth remote control]] program written in JAVA for mobiles phones.

===== [[Wifi_usb]] =====

===== flash memory and hardrive =====

Does not make really sens because of the speed of USB1.1, but work. You can use such storage for still images or running more software from the USB disk/flash.

===== keyboard & mouse =====

==== Other Hardware ====
[[RTC]] (real time clock), [[10331]], [[10332]], [[10334]] (USB lens control)

== Active Projects ==

=== [[HDR images with Elphel cameras]] ===

This section will describe HDR projects build on Elphel cameras by OpenSource Community.

=== [[Alternative IO board for 10353/10363 series]] ===
This page is an open discussion about the evolution of the [[10349]] additional board.

=== Exif data in JPEG images ===

Exif data (Exchangeable image file format) can be included inside each JPEG image. The [[Exif]] section will describe things what are possible to do with Exif data on Elphel cameras.

=== Synchronization of the Cameras ===

Sometimes you need to acquire images triggered by an extarnal event or several cameras need to be synchronized with each other. [[Camera Synchronization]] is all about this.

=== Photo-finish ===
Photo-finish device made using Elphel model 333 camera with additional FPGA code and software - [[Photo-finish]]

=== Zeroconf for Elphel cameras ===
[[zeroconf for Elphel cameras]]
=== Elphel cameras and Zoneminder ===
We plan to make the model 333 camera work with [http://www.zoneminder.com Zoneminder]
=== USB host interface ===

daughter board with USB and DC-DC power for lens control board [[10334]]

Proposal for a usb audio solution : [[PCM2903]]

=== Motorized lens control ===
I'll try to retrieve what was written before on the motorized lens control. In short - C/CS mount is rather old and does not work well for interchangeable motorized lenses. We are trying to build an adapter from C/CS-mount to a bayonet type connector. And place a tiny 5mm wide PCB ring in that adapter. This [[10331]] PCB has a reprogrammable microcontroller and uses just 2 connections to the camera for power and data signals combined. It provides all the necessary connections for most types of motorized lenses.

lens control board [[10331]]
DC-DC power board for motorized lens control board [[10332]]
lens control board In System Programmer [[lbcontrol]]

=== Outdoor enclosure ===

'''Step Zero'''

Determine working setup
-Does the system need a control board
-CCD board needs a longer cable for minimal package when stacking lens on top of board [http://www.maartenmenheere.nl/blog/images/014-001-0.jpg Camera casing]

'''Step one'''
Test setup. Assemble all components in a setup that can record video

Components in test setup
- Lens (Computar H3Z4512CS varifocal lens? using power)
- Elphel USB setup. Is it possible to directly plug in a usb drive. Where does the power come from?
- Battery
- Usb cable or network calbe
- Usb exteral harddrive or flashdrive
- ON/off switch

Objective: Does it work, at all?
Secondary: Battery life? Video quality?

'''Step two'''

Wooden box. Test setup 1 integrated in outside video testing setup.

Components added in test 2
- Hardboard casing

Objective: Optimize recording setup of video for ease of use
Secondary: optimal settings? correct lens?

'''Step three'''

Building of waterproof casing
- Amphenol plugs
- Camera window
- Casing camera (fibre reinforced composite)
- Casing base station (battery + storage) (fibre reinforced composite)

[http://www.maartenmenheere.nl/blog/images/outdoorvideosystem.jpg Schematic]
[http://www.maartenmenheere.nl/blog/images/014-001-0.jpg Camera casing]
[http://www.maartenmenheere.nl/blog/images/camera.jpg Camera casing]
[http://www.maartenmenheere.nl/blog/images/Radjump_elphel.jpg Outdoor enclosure]
[http://www.maartenmenheere.nl/blog/images/CamAssy-Sheet1.pdf Camera casing 2]

=== Current enclosure design ===

We are switching to extruded aluminum tube (actually original 303/313 also was design for a standard aluminum profile). Model 333 RJ-45 connector is designed to fit into RJField shell [http://www.rjfield.com/ethernet_connectors_rjf_en.htm].

[[Mechanical]]

=== Removal of distortion ===

Distortions from the non-instantaneous exposure of the frame can be done in [http://lives.sf.net LiVES]. But first some other infrastructure must be in place:

- Camera must start a [http://www.piksel.no/pwiki/VideoJack videojack] server on the host machine, with the correct fps, width, height and frame palette

- Camera must activate the videojack receiver in LiVES and connect it the correct videojack server

- Camera can start to send unpackaged compressed frames to videojack server, along with an array of floats

- Floats will be in pairs for each horizontal band: the vertical compression/expansion (1.0 means no compression) and the horizontal shift (+-shift/width)

- LiVES will pull these frames and the float array from the videojack server

- LiVES will decode each frame and pass it along with the float array to a [http://www.xs4all.nl/~salsaman/lives/docs/weedspec.txt Weed] effect which will apply the compress/expand/shift

- LiVES will receive the altered frame and save it to a stream
==== Post-processing - non realtime ====
CMOS sensor-specific distortions caused by the [[Electronic Rolling Shutter ]] do not need to be removed realtime - the PC power may be not enough to do so. It is perfectly OK to be able to just post-process the video recorded from the camera.

--[[User:Andrey.filippov|Andrey.filippov]] 02:39, 9 December 2005 (CST)

=== Synchronous lighting ===

External light control. [[Synchronous lighting]].

=== Auto focus System ===

One research team of EPFL is working about an auto focus with the Elphel 353 camera. A bi dimensional filter will be used to calculate the sharpness of the image and to search the best in focus image.

=== How to build a Canon EOS Lens adatator for Elphel 333 ===
- Canon EOS Lens with adaptator [http://community.elphel.com/pictures/jmfcontrib/jmf_canon_adap1.JPG] [http://community.elphel.com/pictures/jmfcontrib/jmf_canon_adapt2.JPG]

A easy way to build a C adapter for Canon EOS Lens [http://community.elphel.com/pictures/jmfcontrib/jmf_333_with_canon_std.JPG].

Take a protection of lens, make a central hole and fix two C/CS adapters [http://community.elphel.com/pictures/jmfcontrib/jmf_cs_c.JPG]
to have a good focal distance.

We have tested various Canon Lens that professional reporter lend me. [http://community.elphel.com/pictures/jmfcontrib/jmf_prof_lens.JPG]

- Canon Lens mounted on 333 : [http://community.elphel.com/pictures/jmfcontrib/IMG_5526.JPG] [http://community.elphel.com/pictures/jmfcontrib/jmf_view_canon17-40.JPG]

''Pictures result of various lens :''

The main goal of this test is to try to use Canon EOS lens, more reference and less expensive when C Lens.
The second goal is to be able to use hight definition of CMOS sensor without optical resolution of C Lens.
Canon EOS UMS PRO 17-40 : mount on 333 Elphel [http://community.elphel.com/pictures/jmfcontrib/jmf_view_canon17-40.JPG]

-- view of Strasbourg House (France) [http://community.elphel.com/pictures/jmfcontrib/17-40pos17equiv80.3bague.ferme.jpg]

-- second view with another set of Canon Lens (minimum apperture) [http://community.elphel.com/pictures/jmfcontrib/17-40pos28.2bagus.testlimit.diaph6mm.ferme.jpg]

-- view of cat and barbie dole [http://community.elphel.com/pictures/jmfcontrib/objectif50.2bagues.2chat.jpg]

In fact : a Canon large vision become a Power Zoom this CMOS size difference. 35mm to 1/2" [http://community.elphel.com/pictures/jmfcontrib/jmf_mount_canon_333.JPG]

Conclusion :
image quality is better than C lens (varifocal computar or fixed-focal Fujinon)
but Canon lens become a super Zoom Lens and we not certify thermal stability of adjustment action (focus)

It will be nice to test a Canon fishEyes.

Expensive project of Adaptor to use EOS Lens can be find on net [http://www.mir.com.my/rb/photography/hardwares/classics/eos/EF-lenses/index.htm]
or [http://www.birger.com/Merchant2/merchant.mvc?Screen=ef232_home]

=== Image motion tracking/measurement system ===

Measure image sequence parameters easy (like oscilloscope). [[Scope]].

=== Interesting camera links ===

Real Time 3D Reconstruction using moving cameras.
Using ERS distortions for dynamic scene interpretation and correction... [http://comsee.univ-bpclermont.fr/public/projects.php]

The Rubik’s Cube solving robot [http://www.mechatrons.com/rubotii.htm]

=== [[Porting Theora to 353 cameras]] ===

Porting the Ogg Theora encoder and streamer from the model 333 camera to the 353.

== Known problems ==

[[Known problems]]

== Diagnostic and repair ==

[[Diagnostic and repair]] page in the Cameras Manual

=== Changing or restoring the MAC address ===

The factory default MAC address of Elphel products is the same as the serial number which begin with 000E64. If you would like to use a MAC address different from the serial number you can edit the /etc/conf.d/mac file.

If the serial number has not been configured is possible to set it (but only once!). To set the serial number use the bootblocktool command on the camera:

<nowiki>bootblocktool -a SERNO 000E64xxxxxx</nowiki>

Exchange “xxxxxx” with the serial number of the board.

!As you can do it only once be careful! If you write the MAC address in a wrong format (ie with : separations) the camera will not boot any more.

You may do it with the special HTML [http://www.elphel.com/3fhlo/bootblock/bootblock333.html page] but those serial numbers are supposed to be factory programmed.--[[User:Andrey.filippov|Andrey.filippov]] 05:36, 30 December 2005 (CST)

==[[Project α]]==

== [[Pricing/Discount/Donation Policy]] ==

User Documentation

2008-08-23T15:04:30Z

Aegdss: Minor grammar cleanup

{{Manual Header}}

<center>[[Image:Elphel logo.png]]</center>
<h1><div style="display:inline; color:blue">SHORT OVERVIEW</div></h1>

There are many network cameras (cameras that can serve images/video without computer) on the market today. Some can provide high frame rate video, but are limited to 705x480 pixels or less. There are even some high-resolution (megapixel) network cameras, but they usually need a second or more to compress a full size image.

Elphel cameras can do both. They can serve full size (2592x1936) images really fast — at 15 frames per second. And much faster at lower resolutions. High resolution may be very useful for security applications — a single camera with a wide angle lens placed in the corner can see over the whole room with the same quality as a narrow angle NTSC camera placed on a pan/tilt platform. And it can see it all at the same time without the need for any scanning.

Full resolution high frame rate even makes it possible to avoid using "digital pan-and-tilt" (sending out just a subwindow of the whole frame) — the usual way to overcome the slow operation of high resolution network cameras.

Elphel cameras are powered by 48VDC through a LAN cable compliant to the IEEE 802.3af standard. This voltage makes it possible to use cables to the camera for about 100m - four times longer than 24VDC and 16 times longer than 12VDC — such lower voltages (not IEEE 802.3af compliant) are still used in some power over LAN cameras.

All the embedded software and FPGA bitstream are stored in the camera flash memory which can be upgraded through the Internet.

There are other features that are useful for developers. Both the embedded software and FPGA hardware algorithms are Free Software.

This Manual will help you not only to learn to use Elphel cameras more effectively, but also allow you to develop the camera software and hardware yourself.

----
''Free Software and Open Hardware. Elphel, Inc., 2005''

User:Aegdss\Learning Curve

2008-08-22T13:28:11Z

Aegdss: reply to polto

User:Aegdss\Learning Curve

2008-08-21T19:28:38Z

Aegdss:

User:Aegdss\Learning Curve

2008-08-11T14:01:39Z

Aegdss: /* Streaming etc. */

User:Aegdss

2008-08-08T14:26:09Z

Aegdss:

== Andrew Goldstein ==

I am the chief software engineer at [[Desert Star Systems]].

--[[User:Aegdss|aegdss]] 09:08:47, 2008-08-08 (CDT)Currently climbing learning curve and getting camera to place nice in windows. [[User:Aegdss\Learning_Curve]]

User:Aegdss\Learning Curve

2008-08-08T14:24:28Z

Aegdss: Getting up to speed

User:Aegdss

2008-08-08T14:08:47Z

Aegdss: Andy's user page

User talk:Aegdss

2008-08-08T14:07:56Z

Aegdss: /* Andrew Goldstein */

User talk:Aegdss

2008-08-08T14:03:07Z

Aegdss: Andy's talk page

== Andrew Goldstein ==

I am the chief software engineer at [[Desert Star Systems]].

UserProjects

2008-08-08T14:01:13Z

Aegdss: /* Research Projects */

== Research Projects ==
There are several research and educational projects that use Elphel cameras. Some are already active, others just starting or only in planning stage. We believe that scientific research is the application area where the open nature of our products is the most beneficial. The shortage of the powerful and at the same time open and flexible hardware was that "itch" that led me to start Elphel.

This page is started to provide resources to those who already uses or plans to use Elphel cameras. This is wiki, so please feel free to add you project description/link below.--[[User:Andrey.filippov|Andrey.filippov]] 14:59, 29 April 2007 (CDT)

=== [[SCINI: Submersible Capable of under Ice Navigation and Imaging]] ===

=== [[Rose-Hulman Robotics Team]] ===

=== [[Public Primary School Rosa Boekdrukker ]] ===

=== [[FPGA based DMX512]] ===

=== [[AHAB2: High altitude balloon payload]] ===

=== [[Barcode reader]] ===

=== [[Desert Star Systems]] ===

== [[Qualified projects]] ==
This page list the projects that were qualified to get a free of charge hardware from Elphel.

Desert Star Systems

2008-08-08T13:59:30Z

Aegdss: Desert Star Systems Project Page

== Desert Star Systems ==
[http://www.desertstar.com Desert Star Systems home page]

DSS is a small company that designs and manufactures a variety of equipment for specialty applications, primarily oceanographic and military.

We are currently helping support the [[SCINI: Submersible Capable of under Ice Navigation and Imaging]] with acoustic navigation and image data collection.
Our first project with the elphel camera will be a simplified image capture and annotation application in support of SCINI.

== Future Projects ==
We are also exploring the use of the camera in future imaging applications. Some research projects which we will be undertaking, once the learning curve has been climbed:

Histogram spreading to allow for the trade off of image noise vs exposure time/light level

BTC compression for high frame rate at the expense of bandwidth and to free up some on-board FPGA space.

More application specific autoexposure algorithms

Autofocus metric calculations.

Emccd (we currently use the tc-253).

Supporting the interfacing of an lcd viewport, and UI for handheld operation.

Cannon ef lens control drivers.

Autonomous image acquisition.

Image transfer via non-ethernet pipes.