Category Archives: technology

new technologies, latest trends

Getting MTP devices to work on Linux: Nook HD(+)

Android devices typically require you to use MTP to read and write files, instead of using USB mass storage. Wondering why? A lot of other people have wondered the same thing. This post (from here, the XDA developer forum) provides an explanation:

“MTP is a big improvement over USB mass storage — for devices with lots of internal memory, a manufacturer no longer needs to come up with some hard partition between the USB mass storage and internal storage. Instead, they are all in one partition, with MTP providing access to the directory of media files that would normally be available through USB mass storage. This means there is no longer a need for apps on SD card for such devices, because what used to be the ‘internal SD card’ is in the same partition as where applications are stored. The storage on your device can be used for either applications or media, depending on what you want to put on it. You aren’t stuck with how much space the manufacturer decided to leave for the two areas.[…Also,] this means that the media storage doesn’t need to be unmounted from Android when it is being accessed through the PC”

Problem is, Linux MTP is a little problematic.  For example, the Nook I bought recently doesn’t work out of the box on my Slackware-current install despite having the latest libmtp – the device turned out to be read-only. Initially I had to use ADB to copy files onto it, but we found a simple solution. If your MTP devices turn out to be read-only on Linux, then there’s a strong possibility that the problem is with libMTP. Specifically, the devices may need to be listed in this file – music-players.h.  For this you need the vendor number and the device ID. To get these, plug the device in via USB and type ‘lsusb’. Find the relevant line:

Bus 001 Device 036: ID 2080:0006 Barnes & Noble

The first of those (2080) is the vendor ID. The second is the device ID. Adding these to libmtp and recompiling resolved the Nook HD issue for me; maybe it will work for you too. Pretty soon libmtp will contain these devices as standard (the HD+ is already in there), but then there’ll be another crop of Android devices with similar MTP problems around in  a minute, so it’s worth remembering the trick anyway.

Installation notes on ipython-notebook

ipython-notebook is a nice piece of kit, a sort of user-friendly pocket web interface slash gui for mucking around with Python. According to the official site, it’s “a web-based interactive computational environment where you can combine code execution, text, mathematics, plots and rich media into a single document”. More introductory information is available here (along with some very pretty screenshots).

I like the idea of it, not so much for development work but for data analysis and worked demonstration. For something to share it certainly beats a command-line session.

It looks rather like this:

python-notebook

I encountered it during an e-Humanities workshop yesterday and I’m already itching to play with it again.

Getting it to install on Slackware involved a few steps. There are probably better ways, but here’s how I did it, based more or less on http://raj.blog.archive.org/2012/02/02/installing-ipython-notebook-to-replace-matlab/:

Step 0: optional. Open sbopkg as root. Search for and install python3. Version 2.6 works with the ipython-notebook but 3 likes sets and UTF8 better.
Step 1: curl -O http://python-distribute.org/distribute_setup.py
Step 2: sudo python distribute_setup.py
Step 3: easy_install pip
Step 4: Now that you have pip, you can follow the latter part of the blog post above:

Open sbopkg as root. Search for and install zeromq.

For the moment, install libpgm-5.1.116~dfsg from source (tar xvfz libpgm-5.1.116~dfsg.tar.gz; ./configure; make; make install).

pip install ipython
pip install pyzmq
pip install tornado
pip install --upgrade ipython
pip install numpy
pip install matplotlib
Follow the configuration instructions described in the blog post.

The Raspberry Pi

Unless you’ve been living under a rock for the last six months or so, you’ll almost certainly have heard of the Raspberry Pi. If not, here’s the low-down. The Raspberry Pi is a single-board computer aimed at the hobbyist and educational markets. It comes in two flavours, the Model A and Model B, which are subtle references to the BBC Micro computers of the 1980s and 90s. Unfortunately, for the foreseeable future only the Model B – the higher specification model – is scheduled for production. Lurking within the guts of this credit-card sized wonder is 256mb of RAM, and a 700MHz ARM chip that is easily capable of being pushed to 800MHz. For audio and video there are RCA video and 3.5mm audio out, as well as an HDMI port. Resolutions covered range from VGA all the way up to 1080p (and beyond!), with almost all PAL and NTSC video standards covered. Connectivity is a doddle, as a 10/100 Ethernet socket is included on the board. WiFi is also possible; although ARM devices are notoriously finicky about which USB adapters they will work with. I/O is covered too – two USB ports are provided, and are extensible with a hub, and GPIO (general-purpose input/output) pins are provided for connections in and out to various devices, more about which will be covered shortly.

Raspberry Pi Board

The Raspberry Pi viewed side-on. Visible here is the the HDMI port (front centre), the SD card slot (left) the GPIO pins (back left), RCA video (yellow jack) USB ports (back right) and Ethernet port (front right).

While unfortunately the hardware of the Raspberry Pi is almost unchangeable (short of the size of the SD card used), this is more than made up by the choice of operating systems. In true hacking fashion, several operating systems have sprung up, each doing different things. Here are a selection:

1) Raspbian “Wheezy”

Raspbian is based on the Debian kernel, and is the recommended start point for beginners to the Raspberry Pi. It boots to a command prompt by default, but pre-installed is LXDE – a lightweight X11 manager. Other tools included include the Midori web browser, and all the development tools you’d expect on a Linux system, including Python and Java compilers. Of course, since it’s a Debian installation, new software is a doddle to install using the package manager. Within minutes I had set up VLC and was playing 1080p video with no problems.

2) Arch Linux ARM

Arch Linux is extremely popular with the modders and tweakers of the Raspberry Pi community. Its no-frills approach centres on “simplicity and full control for the end-user”. By default, no X11 server is included – it is up to the user to decide which (if any) they would like. Obviously, this distribution is not recommended for those with little to no Linux knowledge.

3) RaspBMC

On the other end of the scale, RaspBMC is totally different to either of the distributions mentioned above. When you use this distribution to boot the Raspberry Pi, it becomes a fully-fledged home media centre, with the ability to play films, music and even YouTube videos. RaspBMC is based on the very popular XBMC, a cross-platform media centre that is used by countless people worldwide.

 

RaspBMC screenshot

The default home screen for the really quite good RaspBMC media centre operating system for the Raspberry Pi.

One of the main reasons that the Raspberry Pi came about was to teach children in schools about electronics and programming. As such the GPIO pins can be used to interact with code and give sensor readings to programs. Unfortunately, in Raspbian at least, the Python modules for interacting with the GPIO pins are not included by default. Instructions for installing them are given here.  A popular way to interface the Raspberry Pi is a simple ribbon cable and a prototyping board, which will let you try out many different combinations before settling on something more permanent. One of the peripherals that has generated the most buzz lately is a camera module featured here which would pave the way to features such as image recognition for navigation, or more multimedia capabilities.

As with most things, however, there are a few drawbacks, but what else did you expect from a machine costing £25/$35? The biggest caveat for me was initially the lack of hardware MPEG-2 decoding, which meant my whole library of movies would have to be transcoded to h.264 for smooth playback on the device. However, the Raspberry Pi Foundation has now released licenses for roughly £2.50 for MPEG-2 and £1.50 for VC-1. The other gripe that some may have is the lack of expandable RAM, as it is all contained within the CPU. Such users may find the VIA APC or cubieboard a little more suitable for their use, however, for pure value for money and form factor, the Raspberry Pi is hard to beat.

Edit (1/11/12) – As of October 15th, the Raspberry Pi now ships with 512MB RAM, making it an even more attractive proposition for its price point.

Streaming video with VLC

Occasionally one wants to stream video for various reasons, whether it’s within the institutional network or a live feed from a conference venue. A few years ago Greg Tourte and I wrote a paper about the process of streaming video from a DV camera using FireWire, encoding into Ogg Theora/Vorbis, and transmitting the result to an audience via IceCast. For no adequately explored reason I have found myself playing with VLC’s inbuilt streaming methods for various purposes over the last week or so, and since VLC isn’t especially well documented, I’ve put the results up here.

 

1)  Streaming video to an icecast server.

Once you have the icecast server set up this is actually shockingly easy to do. Set up a mountpoint on the server side, in your icecast.xml setup (/usr/local/etc/icecast.xml by default):

<mount>
<mount-name>/test.ogg</mount-name>
<username>myusername</username>
<password>mypassword</password>
<max-listeners>10</max-listeners>
<burst-size>65536</burst-size>
</mount>

for example.

Now, on the client side (which could be anything from Windows to Linux to MacOS, because VLC is cross-platform, but this example is Windows), try

C:UsersEm>”c:Program Files (x86)VideoLANVLCvlc.exe” “C:UsersPublicVideosMy Video.wmv” –sout=#transcode{vcodec=theo,vb=800,scale=1,acodec=vorb,ab=128,channels=2,samplerate=44100}: std{access=shout,mux=ogg,dst=myusername:mypassword@myicecastserver.domain.com:port/test.ogg}

It should transcode on the fly into Ogg Vorbis/Theora and throw it at your icecast server. Viewers who go to myicecastserver.domain.com:port should be able to view it from there. Note that you can change various settings on the transcode process (for example scale=0.5, vb=400), so you can reduce the network bandwidth required, for example, but that paradoxically reducing some of these settings will actually increase the time taken for the transcoding process, so it can result in the transcode getting laggier than it was already.

Why transcode? Well, icecast only handles a limited format set. It’s really designed for audio data, not audiovisual. It’ll handle pretty well anything in an Ogg wrapper, though, and it is free. So if you want to stream video with Icecast, transcoding will probably be involved somewhere.

2)  Streaming from a DVD (previously recorded event)

One would expect this to be as simple as

“c:Program Files (x86)VideoLANVLCvlc.exe” dvdsimple:///E:/#1

but as it happens this seldom works, and the reason is the reaction time. Icecast is contacted with a header as soon as the streaming process begins. If it takes too long to get the DVD spun up and begin the process of streaming, icecast simply times out on you, leaving an error message along the lines of ‘ WARN source/get_next_buffer Disconnecting source due to socket timeout’.

Having tested this on various platforms, I find that the following string: “vlc dvdsimple:///dev/dvd –sout=’#transcode{vcodec=theo,vb=200,scale=0.4,theora-quality=10,fps=12,acodec=vorb,ab=48,channels=2}:std{access=shout,mux=ogg,dst=username:password@myicecastserver.domain.com:port/destination.ogg}’ –sout-transcode-audio-sync –sout-transcode-deinterlace” works very well in some cases. Apparently the DVD drive I first tested this with is just unusually slow. This DVD, being homegrown, doesn’t require libdvdcss to view/transcode.

3) Streaming with ffmpeg2theora

Bit of a Linux solution, this one. Install libvpx, libkate, scons and ffmpeg (all available as Slackbuilds for those who are that way inclined).  Install ffmpeg2theora. Install libshout and oggfwd.

Then: try a command line along the lines of the following:

ffmpeg2theora /source/material/in/ffmpeg/readable/format.ext -F 16 -x 240 -c 1 -A 32 –speedlevel 2 -o /dev/stdout –  | oggfwd myicecastserver.domain.com server_port password /test2.ogg

Obviously the output of this is not exactly high-quality; it’s been resized to a width of 240 pixels, audio has been reduced in quality, framerate’s been reduced to 16. But all these configuration options can be played with. Here’s a useful help page: http://commons.wikimedia.org/wiki/Help:Converting_video/ffmpeg2theora

Having called this a Linux solution, it’s worth pointing out that ffmpeg2theora is available for Windows (http://v2v.cc/~j/ffmpeg2theora/download.html) and that oggfwd/ezstream (http://www.icecast.org/ezstream.php/) have been used successfully on Windows as well. It’s also worth noting that, again, VLC can do the ogg/theora encoding too (and has done since 2006)- it’s just a question of seeing what’s better optimised for your purpose on your platform.

Note also that in this instance no username is needed, and the password used in this case is that set in the ‘<source-password>’ directive in icecast.xml.

4)  Streaming without icecast

Icecast is a useful default solution if you want to broadcast your event/recording to multiple people across the web. It’s also useful because, operating via HTTP, it doesn’t suffer from the sort of firewall/router problems that UDP-based video streaming, for example, typically encounters. On the other hand, if you’re streaming across a local LAN (for example, into the next room), there’s (usually) no network border police to get in your way — and VLC does also offer a direct VLC-to-VLC HTTP-based streaming solution. Unlike Icecast, though, it’s not ideal for one-to-many broadcast.

The Videolan documentation has a graphical explanation of this setup: http://www.videolan.org/doc/streaming-howto/en/ch02.html

 

5) Mixing video for streaming

An obvious application to test in this context is FreeJ. Sadly it’s a bit of a pain to compile as it doesn’t seem to have been touched for a while. You’ll need to use the following approach for configuring the code:

CXXFLAGS=-D__STDC_CONSTANT_MACROS  ./configure –enable-python –enable-perl –enable-java –disable-qt-ui

Typing ‘make’ will result in : error: ‘snprintf’ was not declared in this scope. Add #include <stdio.h> to any files afflicted in this way.

You then come across a crop of errors resulting from changes in recent ffmpeg. Some of these can be resolved with a patch, the rest, you’re better off going to the git repository rather than trying a stable version.

In principle you probably want to enable-qt-gui, but since it doesn’t currently compile I have left it as an exercise for some other day.

And once you have FreeJ working, you need to read the tutorial. Note this advice regarding addition of an audio track to FreeJ output.

 

 

Two cities, two hack days

During March and May, I attended two very different hack days. The first was part of Bath’s first ever digital festival, aptly called, Bath Digital Festival. The hack day was organised by local web development consultancy Storm.

Unlike previous Storm hack days that have had a theme, this one was open ended for the developers to develop anything they wished. They have had good success in their previous hack days resulting in some of the hacks being turned into finished products and released on Apple’s App Store, such as Spyhunt and Shaken created by local software development company Riot.

At the hack day I teamed up with fellow Ruby developer and hardware hacker Paul Leader (who just happens to work at Storm). We had borrowed a receipt printer from Mike Ellis (organiser of Bath Digital Festival) with the intention of plumbing it up to the internet in order to print out tweets from the conference as a physical takeaway memento for festival goers.

Arduino Printer wiring diagram

Working from a highly complicated wiring diagram, we attempted to connect the printer to the internet. Unfortunately for us after many hours in the morning trying to get this to work, we eventually gave up and had lunch. One of my fellow attendees sums this up quite nicely on her blog.

Conclusion

“I also spent a large part of the day sat next to Paul and Julian who were attempting to turn an old receipt printer into a tweet printer – sadly, they couldn’t get it to work, which was a shame – but it was interesting to see the processes and patience they both possessed to get to the desired result (or at least close to it).”

As is the way with most events the wifi during the morning wasn’t quite up to par, so the other 60+ developers in the room found it hard to implement the ideas they wanted to build. After a lunch the wifi was going strong and people started hacking again, I mainly spent the afternoon, finding out what others were working on, and also worked on a twitter text analysis tool with another at attendee.

I think the day went really well, I spoke to some interesting people and thought the event was well organised.

MRD Hack day

The Managing Research Data hack day in Manchester was part of the JISC call by the same name being run by Simon Hodson. Although technically I am not part of any of the projects in the MRD call, I was still asked to attend. The hack day was actually a hack two days, with the room we were in open until the last person left.

After a morning of talks about various projects on the MRD call and various other data related presentations, it was time to start/join a team and brainstorm some ideas. I joined forces with Nick Jackson and Harry Newton of Lincoln University and Nick Syrotiuk of Mimas. The idea of our project came from Joss Winn which he had got from an academic at Lincoln. The basic idea was to create a system whereby an academic could see the outputs of all the research projects not just in their department, but across theirs and every other university.

To get started we first chose a project name from a random name generator, and then I created a GitHub project for it. The project would now and forever be know as Project Rainbow Beam. Built onto of MongoDB I created a simple Sinatra web app to accept a JSON payload which would then be added to the Mongo database. We soon realised that the incoming JSON data need to by sanitised, I volunteered. As I was now chief of sanitisation, Nick J, rewrote the front end using a PHP framework called Codeigniter. To keep enable optimum developer communication we created a chatroom on Campfire, as we were using Campfire, it seemed a good idea to hook GitHub to the chat room, so that every time we pushed code, Campfire would play a Vuvuzela on all of our computers.

Skip to many hours later, Nick J and I were the last to go to bed having been up many hours hacking away at the project.

By mid to late morning day two, we had a fully Bootstrapped website, documentation, api endpoint, data sanitizer, and live feed which was updated via Pusher.

At the hack event, it was decided to vote on all the hack projects that had been going on to see which one would win a further two days development work. With the developers being whisked away to a hotel and given two days to make their project better. Unfortunately we didn’t win this, although our project was well received. The prize of getting two more days to work on their project went to the BitTorrent group whose idea was to use BitTorrent and SWORD to move large research data sets around.

Conclusion

These two events were very different, and were targeting very different audiences. However the common thread they shared was they were meant for developers. They both did well in catering for developer needs, coffee, wifi, and electricity. It was great to be part of these two events, I learned a lot and met lots of great people. I look forward to the next hack day to find a new challenge to work on.

3D imaging with Structured Light

We’re currently looking at ways to scan objects into a 3D mesh. In point of fact there are many of these, including but not limited to:

  • Stereo and multiview imaging
  • laser scanning (ie. DAVID laserscanning project or similar)
  • structured light (sample software available at http://code.google.com/p/structured-light/downloads/list)
  • Kinect depth imaging (actually uses the same principle as the above – but in a convenient reverse-engineered package).

A sample image below:

Detecting motion: DLP-TILT 2-axis accelerometer

Using an accelerometer to assess musculoskeletal stresses

Accelerometers are helpful for characterising device usage and detecting the mode of use. Most of these devices have an internal accelerometer, but it is convenient for our purposes to use an external device (requires less programming and does not require a jailbroken device).

Setup

In order to use this device, you must first set up the serial port with a line like the following:

stty -F /dev/ttyUSB0 raw ispeed 38400 ospeed 38400 cs8 -ignpar -cstopb -echo

Code

The code probably won’t tell you all that much, but here’s one way to make your life much easier: assuming you’re running this on Linux, set your device ID as /dev/dlptilt, then change the line ‘/dev/ttyUSB0’ to read ‘/dev/dlptilt’ in the code before compiling.

#include
#include
#include
#include
#include
#include
#include
#include 

#define BAUDRATE B38400
#define MODEMDEVICE "/dev/ttyS1"
#define _POSIX_SOURCE 1         //POSIX compliant source
#define FALSE 0
#define TRUE 1
#define DEBUG 0

volatile int STOP=FALSE;

void signal_handler_IO (int status);    //definition of signal handler
int wait_flag=TRUE;                     //TRUE while no signal received
char devicename[80];
long Baud_Rate = 38400;         // default Baud Rate (110 through 38400)
long BAUD;                      // derived baud rate from command line
long DATABITS;
long STOPBITS;
long PARITYON;
long PARITY;
int Data_Bits = 8;              // Number of data bits
int Stop_Bits = 1;              // Number of stop bits
int Parity = 0;                 // Parity as follows:
                  // 00 = NONE, 01 = Odd, 02 = Even, 03 = Mark, 04 = Space
int Format = 4;
FILE *input;
FILE *output;
int status;

main(int Parm_Count, char *Parms[])
{

   int fd, tty, c, res, i, error;
   char In1, Key;
   struct termios oldtio, newtio;
   struct termios oldkey, newkey;
   struct sigaction saio;
   char buf[255];
   char message[90];

   // set device name here
   strcpy(devicename,"/dev/ttyUSB0"); 

   newkey.c_cflag = BAUDRATE | CRTSCTS | CS8 | CLOCAL | CREAD;
   newkey.c_iflag = IGNPAR;
   newkey.c_oflag = 0;
   newkey.c_lflag = 0;
   newkey.c_cc[VMIN]=1;
   newkey.c_cc[VTIME]=0;
   BAUD=38400;
   DATABITS=CS8;
   STOPBITS=CSTOPB;
   PARITYON=0;
   PARITY=0;
   fd = open(devicename, O_RDWR | O_NOCTTY | O_NONBLOCK);
   if (fd < 0)
   {
   	perror(devicename);
   	exit(-1);
   }

   saio.sa_handler = signal_handler_IO;
   sigemptyset(&saio.sa_mask);
   saio.sa_flags = 0;
   saio.sa_restorer = NULL;
   sigaction(SIGIO,&saio,NULL);

   fcntl(fd, F_SETOWN, getpid());
   fcntl(fd, F_SETFL, FASYNC);

   tcgetattr(fd,&oldtio);
   newtio.c_cflag = BAUD | CRTSCTS | DATABITS | STOPBITS | PARITYON | PARITY | CLOCAL | CREAD;
   newtio.c_iflag = IGNPAR;
   newtio.c_oflag = 0;
   newtio.c_lflag = 0;
   newtio.c_cc[VMIN]=1;
   newtio.c_cc[VTIME]=0;
   tcflush(fd, TCIFLUSH);
   tcsetattr(fd,TCSANOW,&newtio);
   write(fd,"T",1);
   while (STOP==FALSE) {
       status=1;
       if (status==1) // so redundant...
		{
	if(DEBUG){
   		write(fd,"P",1);
		printf("Printed Pn");
	} else {
		// 7 - single a d conversion to host on current settings
		// z 3 bytes (both channels x and y of accelerometer)
		// s - 7 bytes (all 7 channels)
		// 8 - streaming a/d conversion data using current settings
   		write(fd,"z",1);
	}
	} 

         if (wait_flag==FALSE)  //if output is available
	{
		res = read(fd,buf,255);
		if (res>0)
		{

			// Print serial output
			for (i=0; i

Blink detection and attention evaluation: the NeuroSky MindWave

Hardware for UX evaluation

As part of Project Sunflower, we took various approaches to interface evaluation. Alongside heuristic evaluation, walkthroughs and so forth, we also used various bits of hardware to support trials. This post describes setup and sample code for the NeuroSky MindWave, an inexpensive BCI (brain-computer interface – think ‘electroencephalogram’, or ‘brain wave monitoring’) that uses a single sensor placed on the forehead to measure eye blinks, ‘attention’ and ‘meditation’. These two latter variables shouldn’t be taken at (scuse the pun) face value; according to a report by Travis Ross, they’re based on a proprietary algorithm, with attention reported to relate to beta waves, hence linked to wakefulness/focus, and meditation linked to alpha waves – level of calm. Vague, admittedly, but then these devices are priced for and in large part targeted at the consumer market. If you’ve ever seen those Mattel Jedi force-trainer toys, those are based around the same technology.

Setup

Having installed the software prerequisites and drivers, the next thing is to run the Thinkgear Connector. This is an extremely helpful little piece of kit, which listens to the USB radio link and makes the sensor data available to applications. This reduces the connection step to a couple of lines of code. Since the Thinkgear Connector will return JSON upon request, the data packets are easy to parse.

Code

import sys
import json
import time
from telnetlib import Telnet

tn=Telnet('localhost',13854);
start=time.clock();

i=0;
# app registration step (in this instance unnecessary)
# tn.write('{"appName": "Example", "appKey": "9f54141b4b4c567c558d3a76cb8d715cbde03096"}');
tn.write('{"enableRawOutput": true, "format": "Json"}');

outfile="null";
if len(sys.argv)>1:
        outfile=sys.argv[len(sys.argv)-1];
        outfptr=open(outfile,'w');

# default values
eSenseDict={'attention':0, 'meditation':0};
waveDict={'lowGamma':0, 'highGamma':0, 'highAlpha':0, 'delta':0, 'highBeta':0, 'lowAlpha':0, 'lowBeta':0, 'theta':0};
signalLevel=0;

while i

(Edit: The above code is truncated. See https://github.com/etonkin/neurosky-telnet for full code)

Example output

The code as written above produces very simple CSV output, which has the benefit of being very easy to plot using something like Gnuplot:

plot "test-output.log" using 1:3 with lines, "" using 1:4 with lines, "" using 1:5 with lines

Graph of three variables: working on a language problem.

Some sensor data captured: subject was working on a language problem. Red

Sensor data. Activity: Watching TV

Sensor data captured: individual was watching TV. Red

Note: the number of blinks captured is low enough that the chances are that the MindWave is not picking up all blink events.

Ebook reader basics: file transfer via USB

We covered some of the basics of these devices in an earlier series of posts, but it might be worth taking a few minutes to focus on the most basic behaviour of the lot: getting data onto the devices from a laptop. One might expect that all of these devices would operate as USB mass storage devices (plug it in and copy files on). As anybody who’s ever tried to copy data off an iPod knows, nothing could be further from the truth.

Assumptions used here: the task is to copy non-DRM’d ebook files onto an ebook reader.

Sony PRS-600, Hanvon n510, etc.

Like most of your basic e-Ink devices the Sony and its type are ridiculously straightforward to use, if a little slow, as long as you are familiar with copying files using a file manager. These devices function as USB mass storage devices. Plug it in, copy files, unplug it and (in the case of the Sony) wait for it to reindex pretty much the entire filesystem, including files that have been on the ebook reader for months. Don’t keep too many files on the Sony, or you’ll run out of battery life before you ever read a page – the indexing is the most power-hungry step it takes. The Hanvon doesn’t bother with exhaustive indexing, which saves time and battery life here but means that it doesn’t offer the same search functionality.

Filesystem speed stats were generated using:

rsync -auvh --progress --stats --no-o --no-g --no-p /some/files .

We ran this on Linux in each case, in order to ensure that there weren’t any confounding factors such as Spotlight indexing.

Results:  Hanvon N510: 2.34M bytes/sec

Kindle

The Mac recognises the Kindle as a USB drive, and allows you to copy items directly onto it (.pdf or .mobi – convert using Calibre if required). It’s not all plain sailing, though; the Kindle tends to place items imported in this way into a menu section entitled ‘items not yet indexed’. When this happens, it seems that you may need to reset the Kindle (hold the sleep button for 20 seconds), at which point it will reindex on startup.

File transfer rates: 1.87M bytes/sec
We found the Kindle’s file transfer rates to be unusually slow.

Xoom

The Xoom is a somewhat frustrating device. It’s using a driver called MPT (Motorola Phone Tools). Seems this is standard to Android devices, instead of SCSI-like hard drive/mass storage, so we’ll all have to get used to it… Google’s explanation for this decision may be found on this blog post: in short, MPT is seen as an improvement on USB mass storage because

‘for devices with lots of internal memory, a manufacturer no longer needs to come up with some hard partition between the USB mass storage and internal storage. Instead, they are all in one partition, with MTP providing access to the directory of media files that would normally be available through USB mass storage. This means there is no longer a need for apps on SD card for such devices, because what used to be the ‘internal SD card’ is in the same partition as where applications are stored. The storage on your device can be used for either applications or media, depending on what you want to put on it. You aren’t stuck with how much space the manufacturer decided to leave for the two areas. Also, this means that the media storage doesn’t need to be unmounted from Android when it is being access[ed] through the PC.’

On Windows, once the appropriate drivers are installed, it can be treated like a standard storage device – you can simply drag and drop files. On the Mac you’ll need to download the Android File Transfer software, which will allow you to drag and drop files in either direction, plus or minus the occasional bug.  On Linux, you can mount it through MPT using mptfs, a fusion driver for MPT drives. GNOME users will probably find that this happens automatically. The rest of us just do mptfs -o allow_other mountpoint. Android File Transfer on a Mac feels rather slow, but our test on Linux (see data below) suggests that mptfs is not unreasonably slow.

File transfer rates:
mptfs on Linux (calculated as above): 4.59M bytes/sec
Compare this to a similar test of an HP USB2 16GB USB drive: 7.66M bytes/sec

iPad

The iPad was clear winner of the ‘least cooperative’ award in this category. iDevices don’t show up in the filesystem by default. The traditional mechanism used to get files onto the device involves iTunes. This music software has been adapted after the fact for use as an ebook organiser, and its origins are still clearly visible. The results are indifferent: the right-click context menu in the ‘Books’ pane, for example, invites you to ‘download album artwork’. Using this approach, getting files onto your iPad is a multi-step process; download files, import them into iTunes, sync with iPad.

Right-click context menu for ebooks (iTunes screenshot)

Right-click context menu for ebooks (iTunes)

iTunes is the Vegemite of the tablet user; you either love it or hate it. Unless iTunes is a big part of your ebook-reading life already, it becomes an irritant, dragging out the file copy process unnecessarily. The OPDS approach is simpler, if all you want to do is get your files onto the iPad: just download them directly onto the iPad itself.

File transfer rates:
cannot be compared directly.