Temporary Swap File on Ubuntu

 I am training a Machine Learning (Neural Network, "AI") model for epileptic seizure detection.   An issue I have is that I have a lot more false alarm data than I do genuine seizure data, so I am using 'Data Augmentation' to make more seizure-like data.

Unfortunately when doing this using Python, it seems to eat huge amounts of memory.   The 16GB on my computer is not enough, so I added more swap space using the following:

fallocate -l 16G /swapfile2

chmod 600 /swapfile2

mkswap /swapfile2

swapon /swapfile2

Check it is working with 

swapon --show

or

free -h

Using a Kobo Ebook Reader as a Gmail Notifier

A certain person that I know well does not read her emails very often and sees it as a chore to switch on the computer to see if she has any.  And no, I can't interest her in a smartphone that will do email for her....This post is about making a simple device to hang on the wall like a small picture next to the calendar so she can always see if she has emails to know if it is worth putting the computer on.

I was in WH Smith the other day and realised that they were selling Kobo Mini e-book readers for a very good price (<£30).   When you think about it the reader is a small battery powered computer with wifi interface, a 5" e-ink screen with a touch screen interface.    This sounds like just the thing to hang on the wall and use to display the number of un-read emails.

Fortunately some clever people have worked out how to modify the software on the device - it runs linux and the manufacturers have published the open source part of the device firmware (https://github.com/kobolabs/Kobo-Reader).   I haven't done it myself, but someone else has compiled python to run on the device and use the pygame library to handle writing to the screen (http://www.mobileread.com/forums/showthread.php?t=219173).  Note that I needed this later build of python to run on my new kobo mini as some of the other builds that are available crashed without any error messages - I think this is to do with the version of some of the c libraries installed on the device.
Finally someone called Kevin Short wrote a programme to use a kobo as a weather monitor, which is very similar to what I am trying to do and was a very useful template to start from - thank you, Kevin! (http://www.mobileread.com/forums/showthread.php?t=194376).

The steps I followed to get this working were:

• Enable telnet and ftp access to the kobo (http://wiki.mobileread.com/wiki/Kobo_Touch_Hacking)
• Put python on the 'user' folder of the device (/mnt/onboard/.python).
• Extend the LD_LIBRARY_PATH in /etc/profile to point to the new python/lib and pygame library directories.
• Add 'source /etc/profile' into /etc/init.d/rcS so that we have access to the python libraries during boot-up.
• Prevented the normal kobo software from starting by commenting out the lines that start the 'hindenburg' and 'nickel' applications in /etc/init.d/rcS.
• Killed the boot-up animation screen by adding the following into rcS:
        killall on-animator.sh
        sleep 1
• Added my own boot-up splash screen by adding the follwing to rcS:
        cat /etc/images/SandieMail.raw | /usr/local/Kobo/pickel showpic 
• Enabled wifi networking on boot up by referencing a new script /etc/network/wifiup.sh in rcS, which contains:
        insmod /drivers/ntx508/wifi/sdio_wifi_pwr.ko
        insmod /drivers/ntx508/wifi/dhd.ko
        sleep 2
        ifconfig eth0 up
        wlarm_le -i eth0 up
        wpa_supplicant -s -i eth0 -c /etc/wpa_supplicant/wpa_supplicant.conf -C         /var/run/wpa_supplicant -B sleep 2
        udhcpc -S -i eth0 -s /etc/udhcpc.d/default.script -t15 -T10 -A3 -f -q
• Started my new gmail notifier program using the following in rcS:
        cd /mnt/onboard/.apps/koboGmail
        /usr/bin/python gmail.py > /mnt/onboard/gmail.log 2>&1 &

The actual python program to do the logging is quite simple - it uses the pygame program to write to a framebuffer screen, but uses a utility called 'full_update' that is part of the kobo weather project to update the screen.   The program does the following:

• Get the battery status, and create an appropriate icon to show battery state.
• Get the wifi link status and create an appropriate icon to show the link state.
• Get the 'atom' feed of the user's gmail account using the url, username and password stored in a configuration file.
• Draw the screen image showing the number of unread emails, and the sender and subject of the first 10 unread mails, and render the battery and wifi icons onto it.
• Update the kobo screen with the new image.
• Wait a while (5 seconds at the moment for testing, but will make it longer in the future - 5 min would probably be plenty).
• Repeat indefinitely.

The source code is in my github repository.

The resulting display is pretty basic, but functional as shown in the picture.

Things to Do

There are a few improvements I would like to make to this:

1. Make it less power intensive by switching off wifi when it is not needed (it can flatten its battery in about 12 hours so will need to be plugged into a mains adapter at the moment).
2. Make it respond to the power switch - you can switch it off by holding the power switch across for about 15 seconds, but it does not shutdown nicely - no 'bye' display on the screen or anything like that - just freezes.
3. Get it working as a usb mass storage device again - it does usb networking at the moment instead, so you have to use ftp to update the software or log in and use vi to edit the configuration files - not user friendly.
4. Make it respond to the touch screen - I will need to interpret the data that appears in /dev/input for this.  The python library evdev should help with interpreting the data, but it uses native c code so I need a cross compiler environment for the kobo to use that, which I have not set up yet.  Might be as easy to code it myself as I will only be doing simple things.
5. Get it to flash its LED to show that there are unread emails - might have to modify the hardware to add a bigger LED that faces the front rather than top too.
6. Documentation - if anyone wants to get this working themselves, they will need to put some effort in, because the above is a long way off being a tutorial.   It should be possible to make a kobo firmware update file that would install it if people are interested in trying though.

Breaking out of a Frozen SSH Terminal Session

For a long time I have found that if the internet connection is broken during a ssh terminal session that the terminal hangs and the keyboard is un-responsive - CTRL-C, CTRL-D etc. do not do anything.  I have always just cursed and closed the terminal window.

I just found that ~. will break out of the frozen session, giving you access back to the terminal.   ~? gives a list of other escape commands, but I am not sure what I would use those for.

Samsung Colour Laser Printer and Ubuntu Linux

Note:  You might find a more recent post more useful.

I have got sufficiently sick of my Epson inkjet printer suffering from clogged print heads, and noticed how cheap colour laser printers have become, so decided to give one a try.

I settled for a Samsung CLP-325W (w=wireless) colour laser printer.   The reason for this is that Samsung provide linux drivers for it, and I had an old Samsung laser printer a few years ago that worked nicely with linux.

To start with, the CD that came with the printer would not mount on my daughter's Ubuntu 11.04 machine - no idea why, so we downloaded the Samsung unified driver for linux from the Samsung UK support web site.

We installed the driver by running install.sh as root, plugged in the printer and it detected ok and seems to work.  We had to select the "Samsung CLP-300 Series (SPL-C)" driver, because the recommended "CLP-325 foomatic...." one only printed black and white.

So far, so good!

The fun came when I tried to set up wireless printing so I could print to it from my laptop without my daughter's computer being switched on.   The first attempt was to repeat what I had done for the other computer, and install the Samsung unified driver on my laptop.  Unfortunately it refused to detect the printer, even when it was plugged into the USB port on the laptop.   I never found out why and tried a different approach.

I plugged the printer into my ethernet network and re-started it.  I found out that to print the diagnostics you hold the 'cancel' button (with the triangle symbol on it) for a few seconds.  This printed  out a network diagnostic page that said the network type was 'dhcp' and the ip address was 192.0.0.192.   This is odd because my router, which would act as dhcp server should give out addresses 192.168.1.*, so I assumed that it was lying about using dhcp and had a static default address.
Re-configured laptop to use the 192.0.0.* subnet and tried looking for the printer - tried a web browser, ping and nmap, and no sign of it.

Had a look at my router's dhcp list, and realised that the printer had been assigned an ip address by the router, which was not the one on the network diagnostics!!!!!
Re-printed the network diagnostics and got the correct ip address - don't know what happened there.

Pointed a web browser at the printer's IP address and got a nice status web page, with a 'login' option at the top right hand corner of the screen (once I had scrolled across because I couldn't see it on my laptop screen for some reason....).   Had to search on the internet for the default login credentials - found out that it is user name -  "admin", password - "sec00000".

Once logged in, I could set up the network to use a static IP address (so I always know where it is, and connect it to my wireless network).

Disconnected the lan cable from the printer, and sure enough, I can see the printer from my laptop.  Used the Samsung printer configuration tool to set it up as a network printer on the laptop and....it works!!!

phew!

Disk Crash on Linux

Well, I thought that the introduction of the ext3 (and higher) file systems had stopped all of the problems of disk crashes and mangled filesystems on linux.
But, after a few years of reliable operation the root filesystem on my home server (my old Fujitsu Siemens laptop) seems to have mangled.
The symptoms were....not booting - you get the 'Starting up......' message during boot then the system appears to hang.  But if you listen carefully you hear that the disk is actually doing something.  So I left it for a few hours.....
When I came back to it there was a 'failed to mount /dev/sda1' type error message, with an option to skip mounting or manually fix it.
I went for manually fixing it, because not mounting the root filesystem will not get me very far.
This dropped me into a single user shell.
I ran fsck and it said that an Inode has illegal blocks.  I selected the option to clear them...and again said yes when it asked me again.
It then said it was restarting e2fsck from the beginning, and spent quite a few minutes checking....

Then at Pass 2 fsck said it had found a deleted or unused inode.  Again I said 'y' to the 'Clear?' question....
Then lots of offers to fix things (to the extent that I just held my finger on the 'y' key...)

Then fsck announced that it was complete and I should re-boot linux.   Re-ran fsck and it announced that /dev/sda1 was clean, so re-booted.....but booting is taking a suspiciously long time.....like it has been trying for 10 minutes and hasn't got past the boot up splash screen...I'm going to need a plan B...

Well, I don't know what the problem is.   Tried booting off a USB memory stick, and the disk checks ok and mounts, but the boot process just hangs.   I decided I had spent too long on this so it is currently installing Ubuntu 10.10 on the disk instead, so can't try any more diagnosis!

Utility Meter Monitor

I have had a simple utility meter monitoring system working in my parents and my house for a few years.  It uses an NSLU2 single board computer connected to a simple USB input/output interface, as described at http://meterserv.webhop.net.
It worked fine for at least 3 years, but started to misbehave recently.  I have not been able to determine if it is a hardware or software fault - I suspect that I may have worn out the USB memory sticks that I used for the root filesystems.
We have gone for a hardware change to see if that is the problem, but I want to develop the software a bit more too.
Future developments include:

• Add support for cheap electricity meters (e.g. OWL USB energy monitors).
• Add support for temperature sensing.
• Better web interface (the current one uses perl based CGI scripts, which are awful to maintain).
• A simple (end user friendly) software upgrade process.

I want to get rid of the perl cgi scripts because I don't really speak perl, so they are hard to follow - will change them for an ajax based front end with python server side scripts.

The first stage is to get a sofware development environment working.  The original version used the nslu2-linux slugos operating system.  This has been changed quite a bit since I used it, so I decided that as I will need to do a complete re-build, I will standardise and use OpenWRT for all my little embedded system projects.

Compiling OpenWRT for the nslu2 was nice and easy - in the menuconfig just select the processor as an ixp4xxx and the sub-type as nslu2.

Edit target/linux/ixp4xxx/base_files/etc/config/network to give a default network configuration that will work on your system (the openwrt default ip address is 192.168.1.1, which clashes with my router....).

This creates a file called bin/ixp4xxx/openwrt-nslu2-squashfs.bin which can be flashed onto the nslu2 as follows:

• Put the NSLU2 into upgrade mode by switching off, then powering on while holding in the reset button for about 10 seconds.   When the status LED changes colour (at about 10 sec), release the reset button.  The status LED now flashes different colours (very subtly different colours if you are colour blind like me!).
• Use upslug2 (sudo apt-get install upslug2 on Ubuntu) to upgrade the NSLU2 using:  upslug2 -d wlan0 --image=openwrt-nslu2-squashfs.bin
• The NSLU2 will re-boot, but then take a while (a few minutes) to set up a writeable overlay file system before being accessible over the network.

This showed that I could build software for the NSLU2 using openwrt, but now I need to port meterserv to OpenWRT, which will be a separate post....

OpenWRT on Linksys NSLU2

I have had a couple of NSLU2's running a little application to monitor utility meter readings for a few years now (meterserv).   It worked fine until the autumn when my Dad's one stopped recording readings.  I have not been able to find out why - it looks ok.  It may be that the interface card has broken, or I do wonder if I have worn out the USB flash drive that I am using for the root filesystem.

In my inability to find a fault, I decided to do a clean install on a usb disk to rule out software and flash drive problems.   They had been using OpenSlug (now called SlugOsBE) from nslu2-linux, but it is now very out of date, because I have not updated them for a few years.  This means that all the links to package directories are broken etc.

Given the recent success in building OpenWRT for the bifferboard, I decided to use OpenWRT for the re-build.   These are my notes so I can do it again next time....

• In the MenuConfig system, set the target system to 'Intel IXP4xx', sub target to 'Generic' and target profile to 'Linksys NSLU2'.
• Because this is not my new router, I do not want it to use the default IP address of 192.168.1.1.  This can be changed in the 'Image Configuration' bit of the configuration menu.
• I would like to re-code some of the meterserv software in python, so I need python and pyusb installed in the flash image - these were selected from the 'Languages' section of the openwrt menu.
• Make builds a firmware image in bin/ixp4xxx called openwrt-nslu2-squashfs.bin, which is an 8MB image - there is a 16MB one too, but I am not convinced that my nslu2 has that much flash memory.
• You have to put the nslu2 into 'recovery mode'  by holding the re-set button in while you power up the machine - you have to release the reset button as soon as the status LED changes colour, after about 10 seconds.  The status LED then flashes a couple of different colours.
• Flash the new firmware image onto the NSLU2 using upslug2 (sudo apt-get install upslug2 on ubuntu) - the command line was sudo upslug2 --target 00:14:bf:64:df:be --image openwrt-nslu2-squashfs.bin.
• The machine now appears on the network with the right IP address.  Telnet into it and change the root password, then connect using SSH instead.

The only problem is that when I type 'python' I get an error "python: can't resolve symbol 'BC'".  So now I need to work out which package is missing - looks like openWRT missed a dependency, but I don't know which one!

I have had a bit more of a look at it.  There are two surprising things.  The first is that if I write a simple 'hello world' script and execute it, it works, so it is just interactive python that is broken.

The second is that doing "ldd /usr/bin/python" on the nslu2 and on the bifferboard give very similar results, except that the bifferboard one is linked against libgcc and libc, but the nslu2 one is linked against libc.

I think this is telling me something, but I am not sure what....

OpenWRT on Linksys NSLU2

I have had a couple of NSLU2's running a little application to monitor utility meter readings for a few years now (meterserv).   It worked fine until the autumn when my Dad's one stopped recording readings.  I have not been able to find out why - it looks ok.  It may be that the interface card has broken, or I do wonder if I have worn out the USB flash drive that I am using for the root filesystem.

In my inability to find a fault, I decided to do a clean install on a usb disk to rule out software and flash drive problems.   They had been using OpenSlug (now called SlugOsBE) from nslu2-linux, but it is now very out of date, because I have not updated them for a few years.  This means that all the links to package directories are broken etc.

Given the recent success in building OpenWRT for the bifferboard, I decided to use OpenWRT for the re-build.   These are my notes so I can do it again next time....

• In the MenuConfig system, set the target system to 'Intel IXP4xx', sub target to 'Generic' and target profile to 'Linksys NSLU2'.
• Because this is not my new router, I do not want it to use the default IP address of 192.168.1.1.  This can be changed in the 'Image Configuration' bit of the configuration menu.
• I would like to re-code some of the meterserv software in python, so I need python and pyusb installed in the flash image - these were selected from the 'Languages' section of the openwrt menu.
• Make builds a firmware image in bin/ixp4xxx called openwrt-nslu2-squashfs.bin, which is an 8MB image - there is a 16MB one too, but I am not convinced that my nslu2 has that much flash memory.
• You have to put the nslu2 into 'recovery mode'  by holding the re-set button in while you power up the machine - you have to release the reset button as soon as the status LED changes colour, after about 10 seconds.  The status LED then flashes a couple of different colours.
• Flash the new firmware image onto the NSLU2 using upslug2 (sudo apt-get install upslug2 on ubuntu) - the command line was sudo upslug2 --target 00:14:bf:64:df:be --image openwrt-nslu2-squashfs.bin.
• The machine now appears on the network with the right IP address.  Telnet into it and change the root password, then connect using SSH instead.

The only problem is that when I type 'python' I get an error "python: can't resolve symbol 'BC'".  So now I need to work out which package is missing - looks like openWRT missed a dependency, but I don't know which one!

I have had a bit more of a look at it.  There are two surprising things.  The first is that if I write a simple 'hello world' script and execute it, it works, so it is just interactive python that is broken.

The second is that doing "ldd /usr/bin/python" on the nslu2 and on the bifferboard give very similar results, except that the bifferboard one is linked against libgcc and libc, but the nslu2 one is linked against libc.

I think this is telling me something, but I am not sure what....

Personal Weather Station using BifferBoard

I have managed to re-compile openWRT to run on the bifferboard, and include python, libusb and pyusb in the main root directory.   I also included the wget utility, because I thought it would come in useful, plus a few other potential future extensions (lighttpd web server and wireless LAN support).
This fits on the bifferboard onboard flash memory, with about 1MB to spare.

I created a /home/weather directory and extracted a recent pywws tar archive into it.   I was very pleased that running TestWeatherStation.py produced a table of numbers as expected, so it looks as though the bifferboard is talking to the weather station ok.
Here it is:

Set up the initial weather database by doing

cd /home/weather 

python pywws/pywws/LogData.py -vvv /home/weather/data

This creates /home/weather/data/weather.ini and a directory /home/weather/data/raw which contains the raw data.

Run Hourly.py for the first time to process the data, and set up the weather.ini file ready for customisation:

pywws/Hourly.py /home/weather/data

Customise /home/weather/data/weather.ini to do what you want it to do - in my case update weatherunderground....

All is looking promising here - seems to send the update ok on an hourly basis.  There are two problems though:

• There is not much disk space left now I have added all of January's weather data (256kB ish)
• I am concerned that I will wreck the flash chip on the bifferboard with all this writing.

One option is to store the weather data in a ram disk and just accept that after a power-off it will need to re-initialise itself - not sure how pywws will cope with this - I will need to load some default weather.ini file from flash every time it boots, then let it update itself as best it can.

As a quick alternative I have found an old 256MB SD card and created an ext3 filesystem on it.  This detects as /dev/sda1 when plugged into the bifferboard.   I have modified /etc/rc.local to mount this as /home/weather.  This should solve my full filesystem problems.  [Note:  I used an ext3 filesystem because my openWRT build could not detect ext2 - this was a bit of a surprise because I thought you got ext2 support free with every Linux kernel...].
Then it is just a matter of a cron job to do the hourly updates - crontab -e, then add:

13 * * * *       python /home/weather/pywws/Hourly.py -v /home/weather/data >> /home/weather/Hourly.log 2>&1

If it works, you should continue to see the weather in our back garden at: http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=IHARTLEP2.

Mistake 1:  If you put an SD card into the dual USB bifferboard, it disables one of the USB ports.  This is bad if it was the one the weather station was connected to....

Mistake 2:  Believe people when they say the clock on a board is no good.  The Bifferboard clock is no good.  Not only does it loose its time when powered off, but it drifts - by a few minutes an hour.  This meant that pywws got confused about when it should update weatherunderground, because it thought time had suddenly gone back to 2009....   To avoid this I compiled ntpclient as a package and downloaded it onto the bifferboard.   I now have it set to be called once on boot, then every 10 minutes by a cron job.  This should keep it somewhere close - just hope the time server owner doesn't mind - If I get a complaint I will have to set up my own time server...

Building openWRT for BifferBoard

I had a go at building openWRT for my new bifferboard computer last weekend, but had trouble with it - it looked like the kernel started, but then panicked around the time it was supposed to be starting init. I suspect it was something to do with the j2ffs file system.

I decided to try to be clever and rather than fix openWRT, start from scratch with an OpenEmbedded based build. I think this was too big a step - the main problem was that OpenEmbedded failed to build because some sources from handhelds.org are not available, so I had to learn how to alter 'recipes' to build them from sources from another location. I got ipkg-utils to build this way, but then hit more trouble with openssh. I decided it was going to take me a long time, so went back to openWRT for now to try to get something working!

This time I followed the exact instructions from the bifferboard site, including downloading the specific revision of openWRT.   This all compiled nicely without any errors, so the next challenge was to get it onto the board.

Flashing over the serial line seemed to take a very long time, so I had a go with network setup.
I downloaded the bifferboard utilities using:

svn co https://bifferboard.svn.sourceforge.net/svnroot/bifferboard

This provides a simple python based tftp server.   I had to modify it to use a fixed ip address for my host computer, because the script assumes that you are using eth0 for the network interface, and I was using wireless.
You then need to make sure that there is a file called bzImage in your working directory and start bootp_server.py - I had to do it as root because I got some permission denied errors about opening sockets, and the easiest way to fix it was to be root - there is probably a more elegant solution though.

First I created a symbolic link to the bzImage file that openWRT had produced.   Then booted the bifferboard with the serial line connected and pressed ESC to stop the boot process.   Entering the tftpflash command downloaded the bzImage from the server and flashed it to the disk - much quicker than a serial line.
The kernel started, but failed with a lot of j2ffs errors - I think this is because I had my old root filesystem in the flash memory.
For the next attempt I created a symbolic link from openwrt-rdc-jffs2-64k-bifferboard.img to bzImage.
Re-flashed it again the same way and it boots!

A minor detail was that I could not log into it - the serial console was fine and both telnetd and dropbear (the SSH server) were running, but I got 'connection refused' when I tried to connect.   It turned out that there was something called 'firewall' running.   I deleted /etc/rc.d/S45firewall and re-booted and it worked properly - I could telnet in initially without a password, set a root password, then use ssh to connect.
Success - Now I just need to sort out the weather station software to run on it - back to the cross compiler....

running make package/symlinks in the openWRT directory adds all of the available packages to the openWRT menuconfig program.
Added the ones I know I need (libusb, python, pyusb), plus a few others that might come in useful later (atheros wireless card drivers).  Then make.....and wait...

A "Hacking Embedded Linux Devices" wiki site?

I have done a bit of work trying to hack cheap consumer devices to run different software - NSLU2, mediaMVP, musicPal, edimax IP Cameras etc.   I have also had a look at 'off the shelf' single board computers like bifferboard.
Whenever I start I have the difficult learning curve of trying to remember how to set up a cross compiler, cross compile libraries and link them into new software.
I also think it would be useful to have a nice list of which devices have been successfully hacked and which ones are difficult.
I am thinking of setting up a site to collate such basic information, which could then link out to the more specific project sites.
Unless anyone knows of one already?

I think it would need a wiki to store most of the information, and an email discussion group.  I wonder how best to do it - there are google sites and google groups, wikispaces, pbworks.

Any suggestions on the best way to do this?

Building openWRT

I have got a little bifferboard single board computer which I intend to use to run pywws to send data from our weather station to the weather underground site on the internet.

The bifferboard comes installed with a very small linux distribution called openWRT.   It has a very small python installed, but no python USB support.

I have struggled a bit to work out how the openWRT package system works - the official wiki is a bit confused about what the current version is called (kamikaze or backfire).  It implies you can add packages by downloading them from svn, but this didn't seem to do anything.
I found a useful forum post here, which seems to be the best set of instructions.
You can do

./scripts/feeds update -a

This downloads the list of packages, but does not do anything else.

To get the buildroot system to compile it for you you need to 'install' it using:

./scripts/feeds install python 
./scripts/feeds install pyusb
You can then do "make menuconfig" and python and pyusb are shown to be compiled as packages "".

'make' actually compiles it.

I'll update this when I work out how to add these to the firmware image...

Building openWRT

I have got a little bifferboard single board computer which I intend to use to run pywws to send data from our weather station to the weather underground site on the internet.

The bifferboard comes installed with a very small linux distribution called openWRT.   It has a very small python installed, but no python USB support.

I have struggled a bit to work out how the openWRT package system works - the official wiki is a bit confused about what the current version is called (kamikaze or backfire).  It implies you can add packages by downloading them from svn, but this didn't seem to do anything.
I found a useful forum post here, which seems to be the best set of instructions.
You can do

./scripts/feeds update -a

This downloads the list of packages, but does not do anything else.

To get the buildroot system to compile it for you you need to 'install' it using:

./scripts/feeds install python 
./scripts/feeds install pyusb
You can then do "make menuconfig" and python and pyusb are shown to be compiled as packages "".

'make' actually compiles it.

I'll update this when I work out how to add these to the firmware image...

Hacking the Parrot-DF3120 Picture Frame

Some clever people have been working on running Linux on a parrot DF-3120 Picture Frame, as described on http://sites.google.com/site/repurposelinux/df3120.  
The device sounds like a little computer with a colour display, USB connection, SD card and bluetooth wireless (I would have liked a wireless lan, but never mind!).   Most significantly, Amazon are selling them for less than £10, so I thought it was worth getting one to play with.   It arrived very quickly so I started to play with it yesterday.

The instructions at http://sites.google.com/site/repurposelinux/df3120 fall into two distinct parts:

1. Produce a cross compiler for the board, and use it to compile a Linux kernel, busybox and other things needed to construct a basic root filesystem.  This is all done by a single clever script (minifs).   It actually took a bit of doing to get it to work on my Ubuntu 10.10 system - when it fails you have to look at the log files to see why it has failed.   The most noticeable thing was that I had to install gtk-doc from a source tarball because Ubuntu does not have a package for it - everything else (bison, flex etc.) were installed from ubuntu packages.  
   The script produced an iso image of a root filesystem.
2. Install a boot loader on the device.   The instructions have you download and compile the u-boot boot loader for the device, and package it into  a false firmware upgrade file (.plf) file.   There is some black magic required to copy the file file onto the device in the right directory etc.

The boot loader installation apparently worked.  If you just switch on the device without touching anything, it boots normally.  If you hold down the centre and left buttons (when viewed from the front of the device) as you power it on, the screen goes blank, which is what the instructions said would happen if u-boot tries to boot linux.

In the 'black screen' mode, connecting the device to my computer creates a /dev/ttyACM0 device, which sounds promising for this being the u-boot serial console.

I have tried using a terminal emulator program to connect to the device via ttyACM0 (picocom /dev/ttyACM0, or cu -l /dev/ttyACM0).  In both cases the program connects without error, but I do not see anything on the display or in the terminal.

The copy of u-boot seems to have come from openMoko, so I tried their wiki (http://wiki.openmoko.org/wiki/U-boot).   It sounds like what I am doing should have worked - tried a few baud rates, but I am getting nothing, rather than gibberish - I think I'll read through the u-boot configuration that I just installed and try to work it out.....

Hacking the Parrot-DF3120 Picture Frame

Some clever people have been working on running Linux on a parrot DF-3120 Picture Frame, as described on http://sites.google.com/site/repurposelinux/df3120.  
The device sounds like a little computer with a colour display, USB connection, SD card and bluetooth wireless (I would have liked a wireless lan, but never mind!).   Most significantly, Amazon are selling them for less than £10, so I thought it was worth getting one to play with.   It arrived very quickly so I started to play with it yesterday.

The instructions at http://sites.google.com/site/repurposelinux/df3120 fall into two distinct parts:

1. Produce a cross compiler for the board, and use it to compile a Linux kernel, busybox and other things needed to construct a basic root filesystem.  This is all done by a single clever script (minifs).   It actually took a bit of doing to get it to work on my Ubuntu 10.10 system - when it fails you have to look at the log files to see why it has failed.   The most noticeable thing was that I had to install gtk-doc from a source tarball because Ubuntu does not have a package for it - everything else (bison, flex etc.) were installed from ubuntu packages.  
   The script produced an iso image of a root filesystem.
2. Install a boot loader on the device.   The instructions have you download and compile the u-boot boot loader for the device, and package it into  a false firmware upgrade file (.plf) file.   There is some black magic required to copy the file file onto the device in the right directory etc.

The boot loader installation apparently worked.  If you just switch on the device without touching anything, it boots normally.  If you hold down the centre and left buttons (when viewed from the front of the device) as you power it on, the screen goes blank, which is what the instructions said would happen if u-boot tries to boot linux.

In the 'black screen' mode, connecting the device to my computer creates a /dev/ttyACM0 device, which sounds promising for this being the u-boot serial console.

I have tried using a terminal emulator program to connect to the device via ttyACM0 (picocom /dev/ttyACM0, or cu -l /dev/ttyACM0).  In both cases the program connects without error, but I do not see anything on the display or in the terminal.

The copy of u-boot seems to have come from openMoko, so I tried their wiki (http://wiki.openmoko.org/wiki/U-boot).   It sounds like what I am doing should have worked - tried a few baud rates, but I am getting nothing, rather than gibberish - I think I'll read through the u-boot configuration that I just installed and try to work it out.....

Edimax IC-3010 Firmware Modification

I just discovered the 'stats' facility in blogger.com and realised that the most read posts in my blog are the ones about the Edimax IC3010 wireless ip camera. People are also looking at my web pages about it (http://ic-3010wg.webhop.net).
This got me thinking about it again so I have had a poke around inside the case - I'll post some pictures at the weekend.
There is not much to see in side - there is a mini wireless card and a single board computer. I was hoping to see a USB port, but the nearest I can find is a four pin header that is likely to be one (or more of):
- USB Port
- Serial (RS232 ish) console
- JTAG interface

I'll have to find the main system-on-chip pin-outs to try to decide what it is.

The main thing I struggle with is getting into the firmware files - I think the choice if you want to hack a device is to either connect a serial line to the console to get access to the boot loader, or modify the firmware.   Modifying the firmware sounds simplest, but you run the risk of turning the device into a brick....

That is about where I got to in the summer of 2009.  I am just downloading the latest firmware and source code from edimax to try to de-code the firmware building utility.   While I was doing this, I discovered that someone has already done it - http://www.suborbital.org.uk/canofworms/index.php?/archives/3-Getting-telnet-access-on-an-Edimax-IC3010-webcam.html.   Well done to them!

Edimax IC-3010 Firmware Modification

I just discovered the 'stats' facility in blogger.com and realised that the most read posts in my blog are the ones about the Edimax IC3010 wireless ip camera. People are also looking at my web pages about it (http://ic-3010wg.webhop.net).
This got me thinking about it again so I have had a poke around inside the case - I'll post some pictures at the weekend.
There is not much to see in side - there is a mini wireless card and a single board computer. I was hoping to see a USB port, but the nearest I can find is a four pin header that is likely to be one (or more of):
- USB Port
- Serial (RS232 ish) console
- JTAG interface

I'll have to find the main system-on-chip pin-outs to try to decide what it is.

The main thing I struggle with is getting into the firmware files - I think the choice if you want to hack a device is to either connect a serial line to the console to get access to the boot loader, or modify the firmware.   Modifying the firmware sounds simplest, but you run the risk of turning the device into a brick....

That is about where I got to in the summer of 2009.  I am just downloading the latest firmware and source code from edimax to try to de-code the firmware building utility.   While I was doing this, I discovered that someone has already done it - http://www.suborbital.org.uk/canofworms/index.php?/archives/3-Getting-telnet-access-on-an-Edimax-IC3010-webcam.html.   Well done to them!

Personal Weather Station using NSLU2

While I wait for my new bifferboard to be delivered I thought I would get the weather station working and updating to weatherunderground.com using a Linksys NSLU2 that I have available.
The NSLU2 is already configured to run Linux.  There are quite a few varieties of NSLU2 linux, and I think this one was called OpenSlug when I installed it, but it now seems to be called SlugOSBE.
When I first set it up there was no python package available for it, so I had to write my utility meter monitoring program using Perl (yuk!).
Fortunately there is now a repository at http://ipkg.nslu2-linux.org/feeds/optware/slugosbe/cross/unstable/ that includes python packages.
To get python running (with USB support) on the NSLU2 I had to download the following packages from the repository, and install them with ipkg install .ipk:
libusb, libdb, libstdc++,ncursesw,readline,sqlite_3, zlib, python25, py25-usb

The python distribution did not put an executable in /usr/bin, so I had to do
ln -s /opt/bin/python2.5 /usr/bin/python

With all this installed I could plug the weather station into the NSLU2 (via a USB hub in my case) and pywws just worked.
I hope the bifferboard is as easy!

Personal Weather Station using NSLU2

While I wait for my new bifferboard to be delivered I thought I would get the weather station working and updating to weatherunderground.com using a Linksys NSLU2 that I have available.
The NSLU2 is already configured to run Linux.  There are quite a few varieties of NSLU2 linux, and I think this one was called OpenSlug when I installed it, but it now seems to be called SlugOSBE.
When I first set it up there was no python package available for it, so I had to write my utility meter monitoring program using Perl (yuk!).
Fortunately there is now a repository at http://ipkg.nslu2-linux.org/feeds/optware/slugosbe/cross/unstable/ that includes python packages.
To get python running (with USB support) on the NSLU2 I had to download the following packages from the repository, and install them with ipkg install .ipk:
libusb, libdb, libstdc++,ncursesw,readline,sqlite_3, zlib, python25, py25-usb

The python distribution did not put an executable in /usr/bin, so I had to do
ln -s /opt/bin/python2.5 /usr/bin/python

With all this installed I could plug the weather station into the NSLU2 (via a USB hub in my case) and pywws just worked.
I hope the bifferboard is as easy!

Ubuntu Linux on a Packard Bell OneTwo

This post is a record of me getting Ubuntu Linux (Release 10.10 - Maverick) running on our new Packard Bell OneTwo all-in-one touch screen PC.   I will update it as I make progress fixing the bits that have caused problems.

Installation
Installation was pretty easy - I booted of an Ubuntu 10.10 USB memory stick, and selected manual disk partitioning.
I kept the Windows 7 partition (/dev/sda1) unchanged, and did not touch the other two windows partitions (/dev/sda2 and /dev/sda3).   I deleted the blank 'Data' partition (/dev/sda4) and created a new swap partition (/dev/sda5) and ext4 root partition (/dev/sda6).
Installation went without problem and the machine now dual boots Ubuntu and Windows 7.

Note that I did have a funny happening yesterday when the machine completely refused to boot after I had been using windows.  I fixed this by booting off the USB memory stick and re-installing grub as described in a previous post - This has not happened again.

Audio
Worked out of the box.

Video
Ubuntu did not detect the correct screen size initially - it used a normal aspect ratio rather than wide screen, so only the centre of the screen was used, and the touch screen calibration was way out - this is because it thinks it has two displays (I don't know where the second is - there is no VGA or s-video connector on the back).
This was fixed by going to the System->Preferences->Monitor menu and un-checking the "Same image in all monitors" option.
You can then drag the main screen (labelled "Laptop") away from the second (labelled "Unknown") and set the laptop resolution to 1600x900 resolution.

This makes the screen the correct size, but every now and then it flickers twice within less than a second - it seems that the screen backlight dims momentarily before coming back to full brightness.  This seems to be associated with disk activity - I don't know what causes this - it does not do it in Windows - Any suggestions for fixing it would be appreciated!.

Touch Screen
I was impressed that the touch screen worked 'out of the box' once I had fixed the monitor resolution issue.
Update 01/01/2011 - I decided to do a clean install of Ubuntu 10.10, just in case I had mangled it installing different testing packages going through bugs on launchpad.   Having done the install and updating all packages using update manager, the touch screen is working perfectly - pressing the screen is the same as moving the mouse to the location and left click - Success!!!! (I hope!)  - Ok, I'll give it a couple of days to make sure it doesn't beak before I say success.

Unfortunately there are problems with it.   It seems that once you have done a 'drag' using the touch screen, x-windows thinks the mouse button is still pressed - moving the real mouse changes the shape of the drag region, and worse still, the real mouse button stops working.   Sometimes the keyboard stops working too (both mouse and keyboard are wireless, using a USB receiver)


Investigations so far:

sudo apt-get install input-utils

provides a program called 'lsinput'.  Doing

sudo lsinput

lists the touch screen as:

/dev/input/event6

   bustype : BUS_USB

   vendor  : 0x408

   product : 0x3001

   version : 272

   name    : "PixArt Imaging Inc. Optical Touc"

   phys    : "usb-0000:00:1a.2-1/input0"

   uniq    : ""

   bits ev : EV_SYN EV_KEY EV_ABS EV_MSC

Installing multi-touch utilities by doing:

sudo apt-get install utouch libutouch-grail-dev utouch-grail-tools

sudo apt-get install mtdev-tools

bzr branch lp:~utouch-team/utouch/mtview

cd mtview

make

Provides amongst other things a utility called mtview.  Running that lets you draw pretty patterns on the screen using multi touch - it certainly seems capable of detecting and tracking two fingers at once.

Given this I think the touch screen is basically working, and it is the interface to x-windows that is the problem.

I'll have to work out how x-windows drivers work to fix this though....

I will update this section as I investigate further.

Web Cam
Not tested.