| Organization: | Project SCINI at Moss Landing Marine Labs |
|---|---|
| Date: | December, 2007 |
| Disclaimer: | This material is based on work supported by the National Science Foundation under Grant No. ANT-0619622 (http://www.nsf.gov). Any opinions, findings and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation. |

Typically, we manually enter the static IP of the camera as host on all client computers with name cam, cam1``etc. On unix machines, edit ``/etc/hosts; on windows edit C:\WINDOWS\system32\drivers\etc\hosts. Add a line like:
192.168.0.10 cam1
By default the cameras' IP addresses are 192.160.0.9; this can be changed (eg, using multiple cameras together) by logging in as root with telnet:
$ telnet 192.168.0.10 Trying 192.168.0.10... Connected to 192.168.0.10 Escape character is '^['. Elphel353 login: root Password: pass
Then use your favorite text editor to edit /etc/conf.d/net.eth0 and change the IP= line to whatever you want.
Now the camera can be addressed by name, for things like ping cam or wget http://cam/.
All of these statistics are based on video taken in the lab with little motion, reasonable dynamic range, two client streaming computers on the Belkin router (multicast), no telnet session, 70% JPEG quality, centered image, fisheye lens, and a 3mpix sensor board. "sdp" frames per second are those reported by the camera in the session.sdp file; the other frames per second column are those reported by the client.
All these values are +/- 5% or more due to rounding, manual timing, 1000/1024 conversions, etc.
| Resolution | Binning | FPS (sdp) | FPS | Bandwidth | MB/min | GB/hour |
|---|---|---|---|---|---|---|
| 2048x1536 [*] | 1x | 12.00 | 11.99 | 12083 kb/s | 88.5 | 5.185 |
| 1024x768 | 2x | 12.00 | 11.97 | 3980.1 kb/s | 29.15 | 1.708 |
| 1024x768 | 1x | 12.00 | 11.98 | 3814 kb/s | 27.00 | 1.582 |
| 800x608 | 1x | 15.11 | 15.09 | 3064 kb/s | 23.00 | 1.347 |
| 672x512 | 3x | 12.00 | 10.57 | 2007.4 kb/s | 14.69 | 0.861 |
| 640x480 | 1x | 18.34 | 18.3 | 2700 kb/s | 18.72 | 1.097 |
| 320x240 | 1x | 29.34 | 29.26 | 1000 kb/s | 8.58 | 0.503 |
| [*] | VLC threw up at this resolution, so only one streaming client and no recording to disk... used ElphelOgm, which was great, only dropped 2 frames! |
This is probably the best solution for saving streams, it can handle very high resolutions, has low CPU overhead, and is easily script-able.
Runs on the elphel Kubuntu distro like so:
$ ElphelOgm -a 232.0.0.1 -p 20000 >> vid.mjpg $ ElphelOgm -a 232.0.0.1 -p 20000 | mplayer -nocache -
At full 3mpix resolution, it can handle 12fps to disk or 6fps to large external monitor; many frames are dropped when displaying to screen.
It's pretty easy to view and save streams with VLC on any platform. First start up the camera and go to the web interface with a browser (open http://cam/). Setup the resolution, exposure, etc that you like and then start multicast streaming (arrow button at the top, then click the Video Streamer box. Next, using either the browser or wget, download the file http://cam/var/session.sdp. Open this file in VLC and you're rolling.
To save a stream, first get it working just to view. Then go to File/Wizard... and select Transcode/Save to file. Select the existing playlist item. We usually don't transcode the stream (just record the raw frames), but you could here if you wanted to. If you want to view and transcode at the same time, just open a second instance of VLC for each. The View/Steam and Media Info screen can be useful.
mplayer is the best client for viewing extra large resolution video, as compiled with elphel patches to allow very large image frames. However, it can be a bit finicky to get running. Occasionally starting an mplayer stream won't start fetching multicast packets, but if you "prime" the stream with VLC, mplayer will get rolling and VLC can be closed.
The usual mplayer command is something like:
$ wget http://cam/var/session.sdp $ mplayer sdp://session.sdp
The following script works well to start streams:
#!/bin/bash rm session.sdp; wget http://cam/var/session.sdp && mplayer sdp://session.sdp
If latency has to be as low as possible, at the cost of frame rate, you can append the -nocache option, which I believe drops frames to keep things running fast, but can make for glitchy video:
$ mplayer sdp://session.sdp -nocache
The image sensor is somewhat inadvertently thermally connected to the LED ring heat sink, which can cause image artifacts and eventually "crash" the imaging sensor.
Here is a table of how long it takes artifacts to creep in with the camera bottle assembled but the dome removed in open air; temperature was measured with a remote IR sensor near the center of the heat sink ring on the front:
| Time | Temp | Effects |
|---|---|---|
| 0min | 26c | Fine |
| 4min | 36c | Faint horizontal lines, flicker in and out |
| 7min | 44c | Constant flickering faint horizontal lines, shifting position |
| 12min | 52c | Color shift, vertical lines, large horizontal lines, approaching un-usability |
| 21min | 58c | Continual badness, flickers, disconnected lights |
| 34min | 34c | No flicker or horizontal lines, but color is still off and there are vertical lines. Rebooted, everything is back to normal. |
| 1hr+ | 29c |
If the bottle is allowed to really heat up, eventually the image will look like this:

Different lenses on the LEDs give different light dispersal; in the 2007 season we settled on the 20 degree by 5 degree "wide" lenses; there also circular 10 degree, 25 degree, and 5 degree lenses. The below photos show what the lighting patterns look like on the bottom of a 1 meter deep test tank with the camera bottle powered up and the dome just under the water. There is no cage and the lighting baffle is not installed around the camera lens.
20 by 5:

5 degrees:

10 degrees:

25 degrees:
