Masumi Zapater over at NIGEKA has done an interesting tutorial on turning the Raspberry Pi into an audio bug! Using a USB microphone and standard Linux audio tools, he has worked out how to record and stream the audio to a client computer. Not sure exactly how small a device can be when you add the USB and a battery pack, but it’s a bit of fun anyway! Read the tutorial here. The comments section contains information on capturing to MP3 which will come in useful when storage capacity is tight.
Someone has written a step-by-step guide to getting speech recognition working on the Raspberry Pi. It’s just a barebones tutorial but it does give you enough to get going if this is the kind of thing you want to do. Read more here. There is another tutorial using a different method here.
Techspect has posted a great how to for turning a Raspberry Pi into a streaming webcam server.
Good tutorial on How-To Geek about how to turn a Raspberry Pi into a low-power network storage device using Samba and NTFS. Quite disappointing response to comments, though, as there are lots of questions without answers… Read the article here
This project has been in progress since I first received my Raspberry Pi last July. Until now, I just haven’t had the time to record video.
The Picorder is a Pi/Arduino combination taking readings from 2 temperature sensors, a hall-effect magnetism sensor and an ultrasonic distance sensor which it then displays, with the aid of a Python script, on an LCD display. The Pi also displays it’s own IP address(es) which can come in useful sometimes!
Here is a list of components:
The scripts for the Picorder are held on my GitHub redwing-pi repository. The main driver Python script is pipodcorder4.py.
This project is also detailed on my project page at Ryan Walmsley’s Pideas.co.uk site, which is a fantastic place to add your own Pi project.
Here’s a photograph of the Picorder:
For a walkthrough of the components watch the following video:
See the device in action below:
I will be posting more technical details of the inner workings, code and such like, in the next week, so keep an eye on the blog using the RSS feed or subscribe via email at the top of the screen.
All the articles about, or related to, the Picorder are available here.
This guide is for ext4 , though I’ll explain how other filesystems can be cured along the way. The easiest way to carry all this out, seeing as your computer probably won’t boot at this stage, is to download and burn a copy of Parted Magic. Boot from that, and you’ll get access to a number of useful tools.
First, figure out what partition we’re dealing with.
sudofdisk-l
The above will list all the partitions on all the drives in your computer. To recover a lost partition, you’re going to need Testdisk. Testdisk is included in Parted Magic, and there’s a great guide on their site. For this though, we just need the partition number, such as /dev/sda3 or /dev/hdb1.
Now, make sure your superblock is the problem, by starting a filesystem check, replacing xxx with your partition name. Here, you can change ext4 to ext3, or ext2 to suit the filesystem.
sudofsck.ext4 -v/dev/xxx
If your superblock is corrupt, the output will look like this
fsck /dev/sda5
fsck 1.41.4 (27-Jan-2009)
e2fsck 1.41.4 (27-Jan-2009)
fsck.ext4: Group descriptors look bad... trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sda5
The superblock could not be read or does not describe a correct ext4
filesystem. If the device is valid and it really contains an ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Now lets find where your superblock backups are kept.
sudomke2fs -n /dev/xxx
Down at the bottom of this output, should be a list of the backups:
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
You’re almost there. Finally, restore the superblock from the backup, again replacing the x’s with your partition name, and block_number with the first backup superblock.
sudoe2fsck -b block_number /dev/xxx
Now reboot, and your superblock should be fixed. If it’s not, repeat the steps, but restore a different backup superblock 
If you want to check your Pi file system because you feel it might be having a problem, try the following:
First of all, shut down your Pi using the following which will make the Pi check it’s own file system on reboot:
sudo shutdown -F -r now
Once the Pi comes up again, check the results of the scan by looking at the following file:
/var/log/fsck/
