His response deserves as wide an audience as my original post, so I am drawing attention to it here.

Thank you Luke for taking the time to comment.

Standalone IP cameras have come down in price quite remarkably over the past few years. It is now perfectly possible to get a camera for between £50.00 and £75.00, and this makes them attractive for anyone wanting to set up simple “home surveillance” systems. I bought one recently just to see what I could realistically do with such a beast. I chose the TP-Link TL-SC3130G,

which goes for around £60.00. I bought mine from amazon. I chose this particular camera because, on paper, it looked to have a good specification at a keen price point. According to the TP Link website, the camera’s highlights include:

• 54Mbps wireless connectivity brings flexible placement
• Bi-directional audio allows users to listen and talk remotely
• Excellent low light sensitivity ensures good video quality even in the dawn
• MPEG-4/MJPEG dual streams for simultaneous remote recording and local surveillance

plus an impressive list of protocol capabilities all in a reasonably compact and attractive hardware package.

When the camera arrived I was pleased to find that the hardware was indeed quite solid and attractive. Such a shame I can’t say anything good about the software though.

As you would expect, I had to first configure the camera over a wired link. By default the camera comes up on 192.168.1.10. The login credentials are the usual “admin/admin” – which is the first thing you should change, but sadly I’ll bet that few people bother. The web interface presents the user with a set of configuration menus on the left of the screen and an image taken from the camera towards the centre of the screen. The software assumes that the user has IE and ActiveX running so for those of us with more sensible setups, some of the configuration and control options on the camera (such as snapshot, zoom and audio volume control) are unavailable. No matter, the important thing from my point of view, and the reason I bought this camera rather than its slightly cheaper brother, the SC3130, is the supposed wireless capability. At first sight, the camera and network configuration options look surprisingly comprehensive. In fact, I’d go so far as to say that the list of options available might confuse a user who had little networking experience. For example, besides the obvious options to set new static IP addressing or change to DHCP, you can change HTTP, RTP and RTSP ports, set up multicast streaming, change the multicast address, change the ports used for video and audio streaming, set viewer authentication, set the camera to use PPPoE and dynamic DNS and even send users an alert via email containing the new network settings (such as IP address) should these change. Of course, in order to do so the user must first configure email on the camera. Altogether an impressive looking range of capabilities. Again, such a shame they don’t all work.

Annoyingly, the web interface sometimes simply refused to accept changes or the system reset the changes after reboot, I first noticed this when changing the camera’s clock setting to sync with the time on my PC. It simply refused. NTP worked eventually, but it tended to stop working for no apparent reason. But by far the worst fault was in the WiFi stack. WiFi configuration options were all accepted and it was soon possible to connect wirelessly both to configure the camera and to view either a video stream or a still image. However, as soon as the wired connection was removed, both interfaces went down. Nor was it possible to connect wirelessly if the camera was booted without a cable inserted. Now it is pretty pointless to have a WiFi camera that insists on having a wired connection present as well and I couldn’t believe that no-one had tested this so I assumed that there was some way to get the thing working. Besides I hate being beaten. So I spent what was, on reflection, a disproportionately silly amount of time playing with various configuration options (DHCP vs static addressing, various combinations of UPnP and no UPnP (which involved me changing my router configs as well), changing various network port numbers, all to no avail. I searched the manufacturer’s website in case there was a new firmware image I could try, but that was a waste of time because the image on the website (1.6.17 dated 29 October 2010) was older than the firmware on the camera (1.6.18 dated 17 March 2011).

After trying umpteen variations of settings, at one point the camera froze completely and refused to boot. I had to resort to a hardware reset to get the thing back up again. Here it got weirder still. The camera came back up on 192.168.1.97 and not the default 192.168.1.10 (I found it with a sniffer). God help the average punter trying to get this thing to work.

I sent it back, and amazon refunded my money. Do yourself a favour. Don’t even think about buying one.

In addition to that rather fast ARM CPU, this little beast boasts: 512 MB DDR2 RAM at 400 MHz; 512 MB NAND Flash; one USB 2.0 port and a Gigabit LAN port. The plug apparently runs a 2.6.23 kernel in a custom embedded linux. Now if we can get debian onto that little thing (as is the case with the 1.2GHZ sheevaplug from Global Scale Technologies), it looks like being an attractive proposition for anyone wanting a small, but powerful web or file server.

But, whilst I was scanning the company web site I was struck by their “careers” page. Here’s a sample:

DESIGN LIBRARY ENGINEER II
• Female
• Bachelor’s degree in Computer Engineering or Electronics & Communications Engineering
• Strong background in electronics engineering
• At least 1 year experience in design library with emphasis on schematic symbol and component footprint creation
• Preferable with experience using Mentor PADS, Cadence OrCAD, Cadence Allegro or equivalent EDA tools

and

ODM QUALITY ASSURANCE MANAGER
• Male
• Candidate must be a graduate of BS Engineering
• Background in electrical or electronics is desirable for this position.
• Must have experience in Original Equipment Manufacturer / Original Design Manufacturer.
• The candidate must have demonstrated previous supervisory experience.
• Strong computer skills to oversee electronic quality management systems including document control and CAPA.
• Willing to be assigned in Calamba City, Laguna

I suppose they must have some odd policy of balancing the sexes across the disciplines. At least they are not advertising for “Secretary – female” and “Engineer – Male” as we might have done a few years back.

I persevered for around two weeks during which time I completely rebuilt both the original SD card and another with Martin’s tarball, reflashed uboot with the latest from his site, and reset the uboot environment to the factory defaults before trying again. I also changed /etc/fstab to take out the “errors=remount-ro” entry against the root filesystem, and reduced the number of writes to the card by adding “noatime, commit=180″ in the hope that I could a) gain stability, and b) find out what was going wrong. No joy. I still came home to a plug with a /home2 that was either unmounted or completely unreadable or mounted RO. The disk checked out fine on another machine and I could find nothing obvious in the logs to suggest why the damned thing was failing in the first place. Martin’s site says that “USB support in u-boot is quite flaky”. My view is somewhat stronger than that, particularly when the plug boots from another device and then attaches a USB disk.

But I don’t give up easily. After getting nowhere with the SDHC card installation from Martin’s tarball, I reset the uboot environment on the plug to the factory default (again) and then ran a network installation of squeeze to a 1TB USB disk (following Martin’s howto). It took me two attempts (I hit the bug in the partitioner on the first installation) but I now have a stable plug running squeeze. It is worth noting here that I had to modify the uboot “bootcmd” environment variable to include a reset (as Martin suggests may be necessary) so that the plug will continue to retry after a boot failure until it eventually loads. The relevant line should read:

setenv bootcmd ‘setenv bootargs $(bootargs_console); run bootcmd_usb; bootm 0×00800000 0×01100000; reset’

The plug now boots successfully every second or third attempt. So far it has been up just over ten days now without any of the earlier problems recurring.

My experience appears not to be all that unusual. There has been some considerable discussion on the debian-arm list of late about problems with installation to SDHC cards. Most commentators conclude that wear levelling on the cards (particularly cheap ones) may not be very good. SD cards are sold formatted as FAT or FAT32 (depending on the capacity of the card). Modern journalling filesystems such as ext3 on linux result in much higher read/write rates and the quality of the cards becomes a much greater concern. Perhaps my cards just weren’t good enough.

In my attempts to cure both the booting problems and the USB connection failures I have installed the latest uboot (3.4.27 with pingtoo patches linked to from Martin’s site) and updated my lenny kernel to Martin’s 2.6.32-2-kirkwood in the (vain as it turns out) hope that the latest software would help. Here I also discovered another annoying problem – installing the latest kernel does not result in a new kernel image, the plug still boots into the old kernel until you run “flash-kernel”. Fortunately this is reasonably well known and is covered in Martin’s troubleshooting page.

I will persevere for perhaps another week with the current plug configuration. If I can’t get a stable system though I will try installing to USB drive (perverse as that may seem) and changing the uboot to boot from that rather than the flaky SD card. Most on-line advice suggests that USB support in uboot is rather “immature”, but it can’t be any worse than the current setup. My thinking is that if I can introduce a delay in the boot process by uboot so that I can successfully boot from an external HDD, the drive connection might then be stable enough to be usable.

Of course I could be completely wrong.

About three or four weeks ago I bought myself a new sheevaplug.

The plug has been on sale in the US for some time, but UK shipping costs added significantly to $99 US retail price. Recently however, a UK supplier (Newit) has started stocking and selling the plugs over here – and at very good prices too. My plug arrived within three days of order and I can thoroughly recommend Newit. The owner, one Jason King no less (fans of 1970′s TV will recognise the name), kept me informed of progress from the time I placed the order to the time it was shipped. He even took the trouble to email me after shipping to check that I had received it OK. Nice touch, even if it was automated.

Looking much like a standard “wall wart” power supply typically attached to an external disk, the plug is actually quite chunky, but it will still fit comfortably in the palm of your hand. Inside that little box though there is enough computing power to make a slug owner more than happy. The processor is a 1.2 GHz Marvell Kirkwood ARM-compatible device and it is coupled with 512MB SDRAM and 512MB Flash memory. Compare that to the poor old slug’s 266 MHz processor and 32 MB of flash and you can see why I’d be interested – particularly since the plug can run debian (and Martin Michlmayr has again provided a tarball and instructions to help you out.

The plugs come in a variety of flavours, but all offer at least one USB 2.0 port, a mini usb serial port, gigabit ethernet and an SDHC slot. This means that debian (or another debian based OS such as Ubuntu) can be installed either to the internal flash or to one of the external storage media available. Newit ship the plugs in various configurations and will happily sell you a device fully prepared with debian (either Lenny or Squeeze according to your taste) on SD card to go with the standard Ubuntu 9.04 in flash. Personally I chose to install debian myself, so I bought the base model. (No, I’m not a cheapskate, I just prefer to play. Where’s the fun in buying stuff that “just works”?)

Given that Martin’s instructions suggest that installing to USB disk can be problematic, and that I have debian lenny on my slugs (and had a spare 4 Gig SDHC card lying around) I chose to use his tarball to install lenny to my SDHC card. Firstly I formatted the card (via a a USB mounted card reader) as below:

/dev/sdb1 512 Meg bootable
/dev/sdb2 2.25 Gig
/dev/sdb3 1024 Meg swap

(note that the plug will see these devices as “/dev/mmcblk0pX” when the card is loaded. The “/dev/sdbX” layout simply reflects the fact that I was using a USB mounted card reader on my PC. )

I then downloaded and installed Martin’s lenny tarball to the newly formatted card and as instructed edited the /etc/fstab to match my installation. Martin’s fstab file is below:

# /etc/fstab: static file system information.
#
#
proc /proc proc defaults 0 0
# Boot from USB:
/dev/sda2 / ext2 errors=remount-ro 0 1
/dev/sda1 /boot ext2 defaults 0 1
/dev/sda3 none swap sw 0 0
# Boot from SD/MMC:
#/dev/mmcblk0p2 / ext2 errors=remount-ro 0 1
#/dev/mmcblk0p1 boot ext2 defaults 0 1
#/dev/mmcblk0p3 none swap sw 0 0

As you can see it defaults to assuming a USB attached device. You need to comment out the USB boot entries and uncomment the SD/MMC entries if. like me, you are intending to boot from SD card. At this stage I also edited “/etc/network/interfaces” to change the eth0 interface from dhcp to static (to suit my network) and I changed “/etc/resolv.conf” because the default includes references to cyrius.com and a local IP address for DNS.

Before we can boot from the SD card, we have to make a few changes to the uboot boot loader configuration to stop it using the default OS on internal flash (where the factory installed Ubuntu resides). Again, Martin’s instructions are helpful here but he points to the openplug.org wiki for instructions in setting up the necessary serial connection to the plug. On my PC (running Ubuntu 8.04 LTS) I got no ttyUSB devices by default and “modprobe usbserial” did not work but “modprobe ftdi_sio vendor=0x9e88 product=0x9e8f” did work for me.

Now open a TTY session using cu thusly “cu -s 115200 -l /dev/ttyUSB1” – don’t use putty on linux, it doesn’t allow cut and paste which can be very useful if you are following on-line instructions (of course it helps if you cut and paste the right instructions). I found that booting is too fast if you have to switch on the plug and then return to a keyboard so I recommend simply leaving the terminal session open and resetting the plug with a pin or paper clip. Hit any key to interrupt the boot session, then follow Martin’s instructions for editing the uboot environment.

My plug was running v 3.4.16 of uboot, so at first I used version 3.4.27 (downloaded from plugcomputer.org) and loaded that via tftp as described by Martin, But this turmed out to be a mistake because my plug failed to boot thereafter. I got the following error message via the serial console:

## Booting image at 00400000 …
Image Name: Debian kernel
Created: 2009-11-23 17:25:02 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1820320 Bytes = 1.7 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum … Bad Data CRC

Some searching suggested that the uboot image was probably the problem and that reverting to v3.4.19 would solve this. So I downloaded 3.4.19 from “vioan’s” post “#6 on: November 16, 2009, 03:21:34 PM” at the plugcomputer.org forum and reflashed the plug with that image. Success – my plug now booted into debian lenny. Tidy up, update the OS and add a normal user as recommended and we’re ready to go.

My plug was intended to replace the slug I was using as my local apt-mirror. That mirror is now fairly large because I have a mix of 32 and 64 bit ubuntus (of varying vintages) and 386 and ARM versions of debian. I therefore recycled an unused 500 gig lacie USB disk and mounted that as /home2 (originally as /home, but I soon changed that when I wanted to unmount it frequently and then lost my home directory….) Copying the apt-mirror (175 Gig) over the network from my old slug was clearly going to take forever – high speed networking is not the slug’s forte, so I mounted both the slug and the plug’s disks locally on my PC and copied the files over USB – much faster. It was here that I discovered why the old lacie disk (a “designed by porsche” aluminium coated beast) was lying idle. I’d forgotten that it sounded like a harrier jump jet on take off when in use. I put up with that for a week – just long enough to get me to a free weekend when I could rebuild the old slug (now used as just an NTP server and the webcam) to boot from a 4 gig USB stick so that I could recycle its disk onto the plug. I’ve just finished doing that.

One other problem I found with the plug which caused me much head scratching (and delayed my writing this as I noted above) was that it consistently failed to boot back into my debian install after a “reboot” or “shutdown -r” – I had to power cycle the device to get it to boot properly. I spent some time this weekend with the serial port connected before I noticed (using “printenv” at the uboot prompt) that I had mixed up the uboot environment variables printed on Martin’s site. I had actually copied part of the instructions for the USB boot variant instead of the correct ones for the SD card boot. Sometimes “cut and paste” can be a mistake.

“The Mary has a top speed of 275kph (171mph), a 0-62 time of 5.2 seconds, a range of 500km (312 miles) and is powered by two electric motors pumping out a combined 512bhp (381kW) of power and 715nm (527lb ft) of torque.

While Koenigsegg is shy on exact technical details, its press release abounds with interesting ‘facts’ – including the claim that that it will be possible to charge the Mary’s NLV-developed “redox FAES (Flow Accumulator Energy Storage) to full capacity in 20 minutes and give the vehicle a range of 500 kilometres”.”

Now we if we unpick that a bit we get the following:

- the car uses 381kW of power at peak – let’s say a maximum 200kW at a sensible cruising speed of 100 kph.
- it can travel for 500 kilometers on one charge.
- it can be charged to capacity in 20 minutes.

Now 500 kilometers at 100 kph is 5 hours travel. Multiply that by 200kW and we get 1000kWh. But it can be charged in 20 minutes, so the charge rate must be three times that – i.e. 3000kWh.

No way can you get that through a 13 amp socket.

Once you have the turntable you can easily connect it to your existing HiFi and rediscover the joys of your old vinyl. But the best bit (and this is where the pre-amp comes into use) is that you can plug the turntable directly into the line-in jack on the sound card of your PC and record to disk for conversion to digital format (MP3 if you must, but OGG vorbis for preference). The key to this magic is a nice piece of open source software called Audacity. If, like me, you run Linux, then you can probably simply install the package supplied with your chosen distro, If your distro doesn’t provide it by default, then the website has pre-built packages for most of the popular distros. You can, of course, build from source if you wish. Audacity is cross platform and is available for Windows users. Windows users can then discover the power of free, open source software

Give it a try.

A bit bigger than a transistor