A Battery-powered Time-Lapse Camera

Introduction

The time-lapse camera system described in my earlier post is fine where mains power is available, but for remote locations and longer durations it rather falls down. At 5-6W power consumption it will flatten even a large wet-cell lead-acid battery in 3-4 days. Taking pictures less frequently does little to reduce the power consumption as the camera and NSLU2 run all the time.

Unless we turn the system off — or rather, get it to turn itself off. The NSLU2 has an onboard power supply switch controlled by a separate piece of circuitry that turns power on to the main processor when the power button is pressed. The power button cannot, however, turn the switch off. Instead the switch is designed so that the processor itself has to commit electronic suicide and turn its own power off by sending a signal to the switch. In the ‘off’ state — which as you can see, isn’t really off — only the power switch circuitry uses power, and it uses very little, only 1.3mA. The main processor and anything connected to the USB ports are simply disconnected from the supply voltage. So turning the power off is easy – OpenWRT provides the poweroff command, which does just what it says. The question then becomes, how do we turn the power back on at regular intervals?

A hardware modification

The NSLU2 has an X1205 real-time clock chip that keeps the time and date. It runs continuously, even when the power supply is physically unplugged – that is its 3V battery in the middle of the board. This chip has an alarm facility; it has a pin that can be programmed to send an interrupt signal to the main processor at a specific time and date, up to a year ahead. On the NSLU2 board, this interrupt signal pin is not connected to anything. If we connect it to ‘on’ input of the power supply switch, the X1205 can turn the NSLU2 on when the alarm time is reached. This turns out to be a fairly simple hardware mod. A wire connecting pin 3 of the X1205 to the U15 side of R94 will do the job. The wire has to run from one side of the board to the other, and requires a fine-tipped soldering iron as R94 and the X1205 are both surface mount devices. The photographs below show where it goes.

RTC power switch mod, front

RTC power switch mod rear

Software changes

Having added this wire, all we need is some software to set the alarm time and all sorts of interesting possibilities appear. The software turned out to be a little more complicated than I had expected, as it turned out that the low-level Linux driver for the X1205 wasn’t quite working properly. It didn’t correctly set the alarm values or provide a way to enable the interrupt pin. Nor, having fixed the driver, is there a standard Linux tool for setting up the alarm in the way we need. Fortunately there is a program out there called rtcwake that does nearly the job we want, and I was able to modify it to make a similar program I have called rtcalarm.

With rtcalarm, the fixed driver, and the wire in place, we can now have the NSLU2 turn on, take a single photo, and turn itself off again at any interval. Well, almost any interval. It takes a little over a minute to start up, so the smallest sensible interval would be longer than that, say 90 seconds. The longer the interval, the lower the power consumption.

There was one small remaining problem with this setup. When the time came to make a movie out of the contents of the flash drive, the file renaming strategy described in my earlier post on time-lapse cameras no longer worked. Now the serial number part of the filename is always 000000000, because MJPG-streamer is being restarted every time. The solution to this was to make a small change to the output_file plugin of MJPG-streamer to omit the serial number and the underscore characters separating the time fields. The file names now have the form yyyyymmddmmhhss.jpg. This makes converting them to movies with QuickTime Pro straightforward – no file name changes are required.

The end result: a power-cycling time-lapse camera

An OpenWRT firmware build with the rtcalarm tool and the driver patch, openwrt-nslu2-uvc-webcam3.bin is available here. It provides the same three modes as the build described in A MegaPixel Time-Lapse Camera System – webcam, dual webcam, and time-lapse. In time-lapse mode, however, it now requires the hardware mod, and takes pictures every six minutes, turning itself off for five minutes out of six.

The net power consumption of the new time-lapse mode is a little tricky to work out, as the camera only starts using power quite late in the boot-photograph-shutdown cycle, so the full 1100mA is only used for about ten seconds at the end. I used a data acquisition system to monitor the current draw at 5V over a single photo cycle, and it looks like this:

NSLU2 power profile

This shows that it takes 47.6 A/secs to take a photo, if I can be excused for employing such units. The profile above is for a unit not connected to Ethernet. With Ethernet, power use is slightly higher but the cycle runs some ten seconds shorter and uses 44.6 A/secs. At 5V thats 238W/secs per photo with no network. With these figures in hand, we can estimate how many photos we can get from a battery. For example, a 12V 7AH gel cell running the NSLU2 through my switching voltage regulator contains 12×7 = 84W/hours. If the regulator is 88% efficient we get 73.9W/hours delivered to the NSLU2, which is 266112W/secs and therefore about 1118 photos. This number is largely independent of the interval between photos, because the power consumption of the NSLU2 while off is so low.

Internal details

This build is based on a later version of the OpenWRT trunk, revision 11566. It has a later version (r63) of the MJPG-streamer software, which has some bug fixes and should behave better when streaming to a web browser. I had to apply a patch I found here to the /sbin/usb-storage script to get the flash drive to mount correctly at power-on. As usual, most of the controlling code is in /etc/init.d/done. The only exception is the script at /root/whoa which sets the RTC alarm and turns the power off. If you want to change the number of seconds between pictures, edit the rtcalarm command in this script. The /root/whoa script is called by the MJPG-streamer output_file plugin via the -c option

The source for the rtcalarm tool can be found here, along with the patched rtc-x1205.c driver and the other patches.

, , ,

  1. #1 by Nelson Neves on June 26, 2008 - 10:22 pm

    Uau! Very nice work! I just keep on getting surprised with your articles!

    Correct me if I’m wrong, taking 1 picture each 6 minutes making a total of 1118 photos, would give a maximum of 6708 minutes of autonomy, meaning 111.8 hours, 4.64 days of autonomy.

    Have you thought about using a Solar Panel + Electronics to recharge the battery? Don’t really know if it would be efficient has I don’t have any experience on this field.

    I’ve seen some tests with slug and solar panel here and found it to be quite interesting, but it fails due to lack of battery support: http://chezphil.org/solarslug/

    Don’t get me wrong, 4.64 days is quite amazing for this Time-Lapse Camera! I’m just throwing some ideas into the table that I think useful.

  2. #2 by johnarthur on June 27, 2008 - 10:50 am

    You are quite right, and the final destination that I’m working toward for this system does indeed have a solar panel. I hope to run it continuously at some low rate. But its the middle of winter here and we get only eight hours of daylight a day – some of which is sunshine if we are lucky. It makes me a bit wary of solar panels.

    I still want to look at reducing power consumption by having the NSLU2 take less time to start up; it really shouldn’t take a 266MHz CPU nearly a full minute to boot OpenWRT. I’m sure improvements can be made there.

  3. #3 by cynfab on July 9, 2008 - 1:32 pm

    I’m having trouble with the webcam3 binary mounting a usb drive. The mjpg-streamer webcam mode seems to work ok, but when I plug in an ext2 formatted usb drive it will eventually mount, but after many “usb 1-1: reset high speed USB device using ehci-hcd and address 2” messages in dmesg. Once mounted cat /proc/partitions shows the same data as on my x86 desktop Ubuntu system. However, nothing shows up in the mount point whereas there are several files on the usb drive that do show up on the desktop. It also seems as though once removed that it will never be recognized again (till a reboot). This usb drive is plugged into the top port whide the webcam is in the bottom port.
    Plugging the webcam (orbit AF) into the top port works, but the stream seems to be jerkyer.
    Any thoughts on what might be going on?
    thanks.

  4. #4 by johnarthur on July 9, 2008 - 1:52 pm

    I haven’t tried ext2-formatted drives on that build, so its difficult to say. There might well be software issues with the auto-mount. The dmesg’s do suggest hardware difficulties, though. I would look at logread, and if possible swap the power supply to the NSLU2; they have been known to misbehave and could cause those symptoms.

  5. #5 by cynfab on July 9, 2008 - 3:21 pm

    I tried a usb 1 vfat formatted 1gb drive on the bottom port and got the following:
    hub 1-0:1.0: unable to enumerate USB device on port 1

    I then tried the ext2 formatted drive on the top port and got:

    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

    usb 1-2: new high speed USB device using ehci_hcd and address 3
    usb 1-2: configuration #1 chosen from 1 choice
    scsi0 : SCSI emulation for USB Mass Storage devices
    usb-storage: device found at 3
    usb-storage: waiting for device to settle before scanning
    scsi 0:0:0:0: Direct-Access Memorex TD 2B PMAP PQ: 0 ANSI: 0 CCS
    sd 0:0:0:0: [sda] 1015808 512-byte hardware sectors (520 MB)
    sd 0:0:0:0: [sda] Write Protect is off
    sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
    sd 0:0:0:0: [sda] Assuming drive cache: write through
    sd 0:0:0:0: [sda] 1015808 512-byte hardware sectors (520 MB)
    sd 0:0:0:0: [sda] Write Protect is off
    sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
    sd 0:0:0:0: [sda] Assuming drive cache: write through
    sda:usb 1-2: reset high speed USB device using ehci_hcd and address 3
    usb 1-2: device descriptor read/64, error -110
    usb 1-2: device descriptor read/64, error -110
    usb 1-2: reset high speed USB device using ehci_hcd and address 3
    usb 1-2: device descriptor read/64, error -110
    usb 1-2: device descriptor read/64, error -110
    usb 1-2: reset high speed USB device using ehci_hcd and address 3
    usb 1-2: device descriptor read/8, error -110
    usb 1-2: device descriptor read/8, error -110
    usb 1-2: reset high speed USB device using ehci_hcd and address 3
    usb 1-2: device descriptor read/8, error -110
    usb 1-2: device descriptor read/8, error -110
    sd 0:0:0:0: Device offlined – not ready after error recovery
    sd 0:0:0:0: [sda] Result: hostbyte=0x07 driverbyte=0x00
    end_request: I/O error, dev sda, sector 0
    Buffer I/O error on device sda, logical block 0
    sd 0:0:0:0: rejecting I/O to offline device
    Buffer I/O error on device sda, logical block 0
    unable to read partition table
    sd 0:0:0:0: [sda] Attached SCSI removable disk
    usb 1-2: USB disconnect, address 3
    usb-storage: device scan complete
    usb 1-2: new high speed USB device using ehci_hcd and address 4
    usb 1-2: device descriptor read/64, error -110
    usb 1-2: device descriptor read/64, error -110
    usb 1-2: new high speed USB device using ehci_hcd and address 5
    usb 1-2: device descriptor read/64, error -110
    usb 1-2: device descriptor read/64, error -110
    usb 1-2: new high speed USB device using ehci_hcd and address 6
    usb 1-2: device descriptor read/8, error -110
    usb 1-2: device descriptor read/8, error -110
    usb 1-2: new high speed USB device using ehci_hcd and address 7
    usb 1-2: device descriptor read/8, error -110
    usb 1-2: device descriptor read/8, error -110
    hub 1-0:1.0: unable to enumerate USB device on port 2

    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

    This was without the webcam plugged in.
    the same error messages appear in the logread output.

    rebooting with the ext formatted drive in the top port I get:

    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

    Jul 9 14:50:37 OpenWrt user.info : /etc/rc.common: eval: line 1: swapon: not found
    Jul 9 14:50:38 OpenWrt user.notice root: waiting on usb drive 1 …
    Jul 9 03:13:00 OpenWrt authpriv.info dropbear[2158]: Running in background
    Jul 9 03:13:01 OpenWrt user.info : sysctl: error: ‘net.ipv6.conf.all.forwarding’ is an unknown key
    Jul 9 03:13:01 OpenWrt user.notice root: waiting on usb drive 2 …
    Jul 9 03:13:02 OpenWrt user.notice root: waiting on usb drive 3 …
    Jul 9 03:13:03 OpenWrt user.notice kernel: scsi 0:0:0:0: Direct-Access Memorex TD 2B PMAP PQ: 0 ANSI: 0 CCS
    Jul 9 03:13:03 OpenWrt user.notice kernel: sd 0:0:0:0: [sda] 1015808 512-byte hardware sectors (520 MB)
    Jul 9 03:13:03 OpenWrt user.notice kernel: sd 0:0:0:0: [sda] Write Protect is off
    Jul 9 03:13:03 OpenWrt user.debug kernel: sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
    Jul 9 03:13:03 OpenWrt user.err kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through
    Jul 9 03:13:03 OpenWrt user.notice kernel: sd 0:0:0:0: [sda] 1015808 512-byte hardware sectors (520 MB)
    Jul 9 03:13:03 OpenWrt user.notice kernel: sd 0:0:0:0: [sda] Write Protect is off
    Jul 9 03:13:03 OpenWrt user.debug kernel: sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
    Jul 9 03:13:03 OpenWrt user.err kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through
    Jul 9 03:13:03 OpenWrt user.info kernel: sda:
    Jul 9 03:13:03 OpenWrt user.info kernel: sda1
    Jul 9 03:13:03 OpenWrt user.notice kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk
    Jul 9 03:13:03 OpenWrt user.debug kernel: usb-storage: device scan complete
    Jul 9 03:13:03 OpenWrt user.notice root: waiting on usb drive 4 …
    Jul 9 03:13:05 OpenWrt user.notice root: mounting /dev/sda1 on /mnt/sda1
    Jul 9 03:13:05 OpenWrt user.warn kernel: EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
    root@OpenWrt:/# mount
    rootfs on / type rootfs (rw)
    /dev/root on /rom type squashfs (ro)
    proc on /proc type proc (rw)
    sysfs on /sys type sysfs (rw)
    tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
    tmpfs on /dev type tmpfs (rw)
    devpts on /dev/pts type devpts (rw,mode=600)
    /dev/mtdblock5 on /jffs type jffs2 (rw)
    mini_fo:/jffs on / type mini_fo (rw)
    none on /proc/bus/usb type usbfs (rw)
    /dev/sda1 on /mnt/sda1 type ext2 (rw,errors=continue)
    root@OpenWrt:/# ls /mnt/sda1/
    000_signatures NSLU2_V23R63.bin diagnostics
    root@OpenWrt:/#

    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

    Which looks like the drive was detected, and mounted, and is readable, I can write to it too.
    lsusb -v output (on my desktop) indicates that the webcam is asking for 500ma (don’t know how much it is actually drawing) so there may indeed be a power supply issue.

    …ken…

  6. #6 by cynfab on July 9, 2008 - 3:37 pm

    It looks like there is something going on with the automounter stuff as well. The usb1 vfat drive plugged into the top port is mounted properly at powerup:

    >>>>>>>>>>>>>>>>>>>>>>>>>>

    scsi 0:0:0:0: Direct-Access USB 2.0 SD/MMC Reader PQ: 0 ANSI: 0 CCS
    sd 0:0:0:0: [sda] 2012160 512-byte hardware sectors (1030 MB)
    sd 0:0:0:0: [sda] Write Protect is off
    sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
    sd 0:0:0:0: [sda] Assuming drive cache: write through
    sd 0:0:0:0: [sda] 2012160 512-byte hardware sectors (1030 MB)
    sd 0:0:0:0: [sda] Write Protect is off
    sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
    sd 0:0:0:0: [sda] Assuming drive cache: write through
    sda: sda1
    sd 0:0:0:0: [sda] Attached SCSI removable disk
    usb-storage: device scan complete

    root@OpenWrt:/mnt/sda1# mount
    rootfs on / type rootfs (rw)
    /dev/root on /rom type squashfs (ro)
    proc on /proc type proc (rw)
    sysfs on /sys type sysfs (rw)
    tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
    tmpfs on /dev type tmpfs (rw)
    devpts on /dev/pts type devpts (rw,mode=600)
    /dev/mtdblock5 on /jffs type jffs2 (rw)
    mini_fo:/jffs on / type mini_fo (rw)
    none on /proc/bus/usb type usbfs (rw)
    /dev/sda1 on /mnt/sda1 type vfat (rw,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1)
    root@OpenWrt:/mnt/sda1#

    …ken…

  7. #7 by johnarthur on July 9, 2008 - 3:47 pm

    Odd. It shouldn’t care what port its in, unless your two-port power mod has a soldering issue of some kind… it would be relevant to know if the vfat or ext2 drives automount correctly in either port without the camera present. They should do so, I think.

  8. #8 by cynfab on July 10, 2008 - 12:49 pm

    I’ve done a few tests and a bit of research and have found a few interesting things.

    1. My Linksys manual says to only put a usb flash drive in port 2 (the top port).
    2. This is the port that is missing FB12.
    3. I removed my FB12 mod and measured 0ohms between the port2 and port1 5V pins.
    4. I plugged my camera into each port in turn and it worked in both after boot up.
    5. I tried a vfat usb flash drive in both ports and it worked in both after bootup.
    6. I measured +%VDC at the power pins of both USB connectors without FB12.

    In the picture of the nslu2 board showing the missing FB12, the board has a date code of 0547 (47th week of 2005) my board has a date code of 0433 (33rd week of 2004) so I guess my board could have a pcb error that connected the 2 5V pins together. If I get ambitious I’ll unsolder the port2 USB connector and see what’s underneath, but I find it curious that Linksys says to put the flash drives in port2, which is supposed to be unpowered.

    I think the flash drive problems I was having yesterday were due to the fact that I was plugging in the flash drive after bootup and thinking that the automount stuff would work…. silly me. ;>)
    It seems to work fine from a power off bootup.

    …ken…

  9. #9 by Tim on September 19, 2008 - 4:59 am

    Hi I am also doing an NSLU2 project on battery power and the ability to set a wake-up alarm would be very handy… I’m not using openWRT though, I wonder would you share the source to your alarm program so I could compile it for angstrom?

    …tim

  10. #10 by johnarthur on September 19, 2008 - 8:23 am

    The source to the rtcwake tool and the kernel patch needed to make it work are available at the link mentioned at the end of the post (http://www.mediafire.com/?zibnf3jbtsf). If your kernel version is more recent than 2.6.26rc-9 it should have the patch in it. I hope it behaves under Angstrom…

  11. #11 by Tim on September 19, 2008 - 8:55 pm

    Thanks and sorry! I should have read more carefully.,

    I’ll let you know how I get on.

  12. #12 by Tim on September 26, 2008 - 2:23 am

    > I’ll let you know how I get on.

    Not too well..

    (my kernel version is

    If I compile rtcalarm.c and try:

    root@ixp4xxbe:~$ rtcalarm -s 100
    rtcalarm: assuming RTC uses UTC …
    set rtc alarm: Input/output error

    There is a device /dev/rtc0 but I don’t know what its compiled from as rtc-x1205.c isn’t in my source tree, I’m not too sure how to configure it.

    My kernel is 2.6.21.7..

    I’m thinking of trying to build kernel-module-rtc-x1205 and load it manually, do you think that would work?

    Tim

  13. #13 by johnarthur on September 26, 2008 - 8:28 am

    The module should certainly work with your kernel; it doesn’t use anything thats new. I don’t understand why the x1205 code isn’t in your kernel source as there must be something there, or it wouldn’t be working at all… thats mysterious.

  14. #14 by Tim on September 29, 2008 - 6:38 am

    Hi- hmm, after much frustration I’ve managed to put the updated rtc-x1205.c file into a kernel source archive and recompile it- however it gives errors such as:

    drivers/rtc/rtc-x1205.c:628: error: initializer element is not computable at load time

    drivers/rtc/rtc-x1205.c:628: error: (near initialization for ‘x1205_id[0].id’)

    drivers/rtc/rtc-x1205.c:628: warning: excess elements in struct initializer

    drivers/rtc/rtc-x1205.c:628: warning: (near initialization for ‘x1205_id[0]’)

    drivers/rtc/rtc-x1205.c:637: error: unknown field ‘probe’ specified in initializer

    —I don’t think this is compatable with the necessary interface in kernel 2.6.21.7, what do you think?

  15. #15 by johnarthur on September 29, 2008 - 8:11 am

    That does look like it; I think there must have been some fields added to the initializer structs between 2.6.21 and 2.6.26. You would need to track down what the changes were and adapt the code to them. The changes are probably pretty small but enough to mean it won’t compile. My apologies, I didn’t appreciate how much things change between kernel versions; theres a lot going on…

  16. #16 by Tim on September 29, 2008 - 9:08 am

    I’ve gone through it and I think I’ve made the changes. The i2c interface seems to have changed but the underlying code seems nearly identical.

    I’m interested however as to why your program didnt manage to connect to the driver.. my NSLU2 said:

    set rtc alarm: Input/output error

    Whereas looking at the driver code, I’m not sure it would be aware that the driver wasnt able to set the alarm time. I think theres some other issue.

    Anyway…

    We built your efficient voltage regulator and got it working! Thanks for that!

  17. #17 by Tim on September 29, 2008 - 1:16 pm

    And the alarm now works!

    Thanks so much.

  18. #18 by johnarthur on September 29, 2008 - 8:20 pm

    Great! Looks like Angstrom is coming along well. Glad to hear the votage regulator works too, NatSemi seem to have done a good job at making a high-speed switcher that is not impossible for normal humans to construct :-).

  19. #19 by Rod Whitby on December 7, 2008 - 7:52 pm

    I’ve linked your page onto http://www.nslu2-linux.org/wiki/HowTo/HomePage in the Hardware section.

    Great article. Thanks!

    — Rod Whitby
    — NSLU2-Linux Project Lead

  20. #20 by lars on December 12, 2008 - 12:38 pm

    Great!!
    My SLUG has now a 9000 webcam and an USB memory stick, and /mnt/sda1 mounted on /. A huge memory for pictures and .gci stuff.
    I now want to include some of my own c programs. Sorry to say, I can not figure out how to get gcc installed.
    Of course this is not the place to ask for help with elementaries, but you guys here seem to be kind enough to at least publish a link.

    Best regards from Sweden
    lars

  21. #21 by lars on January 9, 2009 - 1:35 pm

    Lars back again!

    Sorry for breaking the high standard here by my problems with native compiling…

    Another question, hopefully more suitable: How are the httpd files used? busybox has normally an entrance to the http daemon, but so is not the case here. I miss the possibility to require user/password for access to the http-server.

    Lars

    • #22 by johnarthur on January 9, 2009 - 1:44 pm

      MJPG-streamer is responsible for all the http serving; you need to look at the source for that. I presume it could be modified to require a password, but I’m araid I don’t know how…

  22. #23 by lars on January 10, 2009 - 10:24 pm

    When you have a (personal) problem you might consult a main-stream coach and present your how-to-get-rid-of question. You then don’t get any answer, just return-questions forcing you to deeper and deeper understand your problem. During the wait for solutions of my published problems the same mechanism has worked.

    The httpd included in standard OpenWrt Busybox can handle multi-instance versions, separated by -p (port number) and with different configs. I forced ipkg to replace the Busybox included in your package with the older standard version.

    Johnarthur, thank you very much for your excellent blog pages. Please come back with new contributions and don’t stop at June 2008!

    Your pupil Lars (born 1941)

  23. #24 by MobileBob on April 1, 2009 - 6:48 pm

    Thanks for this great firmaware and for all your efforts. It’s so convenient having this thing running in minutes without having to configure anything !

  24. #25 by Ghatothkach Yadav on April 23, 2010 - 4:20 am

    hi

    I am using the …webcam3 image to set up a dual USB camera…
    Looks like there are UVC driver issues, the 1st USB cam works but the second does not..

    root@OpenWrt:/etc/init.d# /sbin/mjpg_streamer -i “input_uvc.so -y -d /dev/video1 -r QVGA -f 7” -o “output_http.so -p 80 -w /jffs/webcam_www1”
    MJPG Streamer Version.: 2.0
    i: Using V4L2 device.: /dev/video1
    i: Desired Resolution: 320 x 240
    i: Frames Per Second.: 7
    i: Format…………: YUV
    i: JPEG Quality……: 80
    o: www-folder-path…: /jffs/webcam_www1/
    o: HTTP TCP port…..: 80
    o: username:password.: disabled
    o: commands……….: enabled
    Unable to start capture: No space left on device
    i: Error grabbing frames

    I tried reducing framerate and size etc but in vain…

    any clue as to how to enable 2 camera’s with the NSLU2 ?

    Seems to be similar to
    http://www.mail-archive.com/linux-uvc-devel@lists.berlios.de/msg03820.html

    Ghat

    • #26 by johnarthur on April 24, 2010 - 9:07 am

      I’m afraid I can’t be much help, it just worked for me. I was using two Logitech cameras. I presume you are assigning them to different ports; when you issue the command above you have started the other camera on port 8080? Are your cameras perhaps both running at USB 1 speed (“full” speed as against “high” speed). If its a USB bandwidth issue as your link suggests that might cause the problem.

  25. #27 by Jean-Francois on November 18, 2010 - 5:43 am

    Hello John Arthur,

    I tried your firmware with my NSLU2 and it is working fine (I am using motion on an other computer to monitor a room).
    But I noticed that when I unplug the webcam (so there is no USB device pluged on the NSLU2), the NSLU2 boot again and again every 2 minutes.
    I am not able to fine which process is doing that, can you help?

    Thanks a lot,

    Jean-Francois

    • #28 by johnarthur on December 4, 2010 - 7:55 am

      I don’t think thats anything I’m doing; it may be mjpg-streamer doesn’t like having the camera taken away from it when it is using it…

  1. eclectronics.org » Blog Archive » Auto power management for the Angstrom NSLU2

Leave a reply to Jean-Francois Cancel reply