Continue reading »]]> One of my hobbies is motorcycling. I have travelled extensively by bike in central and southern europe over many years, but oddly, I have never visited scotland before. I intend rectifying that shortly. When travelling in europe I have always made do with the excellent Michelin range of 1/1000000 (1 cm to 10 km) maps. These maps are of sufficient detail to aid serious navigation and they also fold quite neatly to fit in a motorcycle tank bag top. Never before have I felt the need of a GPS satnav device.

My wife, however, has a TomTom in her car and I noted that the device has two distinct advantages over a static map. Firstly it is immensely useful in the “last 5 mile stage” when you are hunting for a B&B in an unfamilar town, and secondly (of most use when in trouble) it has a “where am I” function that pinpoints location so that you can give your co-ordinates to a rescue service. This latter function is reassuring to someone travelling alone (or to someone left behind by someone travelling alone). So, since I shall be travelling alone in Scotland over some wild and windy expanses where the weather is notoriously less predictably friendly than it is in southern europe at this time of year, I saw the sense in getting a satnav. I bought a garmin (small, light and cheap). Mine even came with a free lifetime subscription to map updates. The device itself is a doddle to set up and works very well. But it has a fatal design flaw – all software and map updates assume that you have a microsoft windows or apple OSX desktop at home. Well, guess what. I don’t.

The garmin update mechanism uses a plugin to IE, firefox, safari or chrome. But only if you are using a “compatible” operating system. No matter how hard I tried to fool the site using a user agent switcher I couldn’t get the plugin to work. I even tried using wine (which according to one or two sites on-line) should have worked, but no, garmin refused to play ball. I can happily mount the satnav as a removable drive on my linux desktop so copying maps (or even software) to the device should be easy.

Now this is more than just a little irritating. I have paid for a device with a “lifetime map update licence”. But I can’t update the maps without a PC running a particular OS. I’m pretty sure that garmin satnavs run a version of embedded linux so the company cannot pretend they have no linux expertise. Worse, they can produce a plugin for OSX machines (which is BSD based) but not something which is debian based.

Garmin, I am disappointed. And annoyed as hell.

Continue reading »]]> A few days ago my sheevaplug died. Beyond the obvious lack of response either over the network or through the USB serial connection, the symptoms (single green LED rather than blue and green LED lit, ethernet LED light steady rather than flashing) were all consistent with a blown PSU.

This problem is well known and well documented on the Newit forum and the plugcomputer forum as well as plenty of other sites, so I was pretty confident in my diagnosis. The general consensus seems to be that the low quality components used by Globalscale in what is, after all, supposed to be a piece of development kit, coupled with its low power output, means that it can’t really cope with the demands placed upon it – particularly if you attach unpowered USB peripheral devices. Even so, I was pretty pissed off that it failed after only two years.

I use my plug as my NTP time source, network “apt-get” cache and local end point for my ssh proxy tunnel to tor. So it was quite important to me that I get it working again. Fortunately Newit now stock replacement PSUs. Mine arrived within a couple of days of order.

Newit have kindly placed a “howto fix your fscked plug” guide online. I found the process relatively easy, with the exception of replacing the new AC inlet plug back in the chassis. In the end I pushed hard and held my breath in case something snapped, but I got it in.

I have seen many pictures of the PSU on-line, but I confess I was pretty shocked at the completely amateurish look of the thing when I pulled mine out.

The picture above shows the PSU in its case as I pulled it out of the plug.

and this one shows the contents of the PSU when the case lid is removed. It looks like the sort of breadboard setup I last saw in a 1960s transistor radio built by my uncle. Certainly not of the quality I would expect from a major electronics company. Mind you, the new replacement unit (see below) is not /that/ much better.

This final picture shows the new PSU installed in what is actually the top half of the plug.

The plug is now back together, and to my relief it booted fine first time. But I’m now not at all confident that it will last. And since one of my earliest slugs is now becoming a little unstable, I’m looking for a replacement for both.

Continue reading »]]> A couple of weeks ago, I wrote about the problems I had with a TP-Link IP camera. Today I received a comment on that post from a guy called Luke in the TP-Link support team. In that response he apologises for the difficulties I had and promises to investigate further.

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.

Continue reading »]]>  

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.

Continue reading »]]> I came across a potential new entry to the “slug replacement” competition today in the shape of a 2GHz Sheeva Marvell based plug computer by Ionics called the Nimbus 2000 (all the company’s products seem to be named after cloud types – wonder why).

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.

Continue reading »]]> My earlier problems with the sheevaplug all seem to have stemmed from the fact that I had installed Lenny to SDHC cards. As I mentioned in my post of 7 March, I burned through two cards before eventually giving up and trying a new installation to USB disk. This seems to have fixed the problem and my plug is now stable. I had a series of problems with the SD cards I used (class 4 SDHC 8 GB cards) which may have been related to the quality of the cards I used. Firstly the root filesystem would often appear as readonly and the USB drive holding my apt-mirror (mounted as /home2) would similarly appear to be mounted read-only. This seemed to occur about every other day and suggested to me that the plug had seen a problem of some kind and rebooted. But of course since the filesystem was not writeable, there were no logs available to help my investigations.

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.

Continue reading »]]> I’m still having a variety of problems with my sheevaplug. Not least of which is the fact that SDHC cards don’t seem to be the best choice of boot medium. I have had failures with two cards now and some searching of the various on-line fora suggests that I am not alone here. In particular, SD cards seem to suffer badly under the read/write load that is routine for an OS writing log files – let alone one running a file or web server. I have also had several failures with my external USB drive. It seems that the plug boots too quickly for the USB subsystem to initialise properly. This means that there is not enough time for the relevant device file (/dev/sda1 in my case) to appear before /etc/fstab is read to mount the drive. A posting on the plugcomputer.org forum suggested a useful workaround (essentially introducing a wait), but even that was only partially sucessful. Sometimes it worked, sometimes it didn’t. In fact, the USB drive still often fails after a random (and short) time and then remounts read-only. Attempts to then remount the drive manually (after a umount) result in failure with the error message “mount: special device /dev/sda1 does not exist”.

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.

Continue reading »]]> Well this took rather longer than expected. I intended to write about my latest toy much earlier than this, but several things got in the way – more of which later.

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.

Continue reading »]]> I normally read the register for its IT tech related reporting – and I enjoy it just because it is a wonderfully scurrilous rag. However, an article about the Swedish supercar maker Koenigsegg’s “Quant”, which el Reg chose to call “Mary”, piqued my interest somewhat. I can’t quite make the arithmetic work out. To quote the article:

“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.

Continue reading »]]> Recently you may have seen adverts in a wide variety of publications for a USB turntable. This product is aimed at people (like me) who have a collection of old vinyl recordings but no longer have the means to play them as they have moved to CD and/or digital recordings. Most of the turntables I have seen are priced at around £110. You don’t need to spend that much. And you certainly don’t need USB connectivity. Any turntable which includes its own pre-amp will do (but the pre-amp is necessary, it is no good buying a turntable without one). I bought one made by Bush for less than £50.00 – I’m sure a conversation with your local audio supplier will unearth others.

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.