"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects." (Robert A. Heinlein)

Saturday, 21 April 2018

Remotely controlling the Raspberry Pi Zero and Pi Camera

Here I am continuing my very slow paced building of a Raspberry Pi Zero based camera. After experimenting with raspberry-desktop file exchanging I’ve now took some time experimenting with remote controlling options. I’ll eventually have to wire to the Raspberry some, at least minimal, physical interface, but remote control, trough a Android smart-phone, could be a viable solution to avoid a too complex hardware interface.

The ready-made solution: Raspicam Remote

The first solution I found in Android Play store has been Raspicam Remote. Raspicam is a quite simple application providing a simple but complete user interface and connecting to the Raspberry Pi using Wi-Fi and SSH.
Unfortunately Raspicam doesn’t work on my old phone (Jelly bean) but it works fine in my much newer tablet. I understand you can’t keep backwards compatibility with everything. Other solutions are available but they look more suited for remote surveillance than camera interface.

The mostly Do-it-yourself solution: BlueDot

Interfacing to the Raspberry trough Wi-Fi offers clear advantages a specially in terms of connection speed but also poses some disadvantage. Setting-up a Wi-Fi connection might be trivial while at home where is available an already configured access point but it’s not the same while outside. Connecting the Raspberry with a smart-phone using Wi-Fi means configuring one of them to act as access-point, its not difficult but it might become tricky. Also on the power consumption aspect must be kept in consideration especially for the device acting as access-point.
Bluetooth overcomes both set-up and power consumption problems in exchange, of course, for transfer speed and connection range.
Here comes to play BlueDot: a simple looking Android application that together with a easy to use Python library allows a unidirectional Bluetooth communication between smart-phone and a Raspberry device.
Installing BlueDot means, on the Android side, just installing the BlueDot application from Android Play Store. On the Raspberry side some Python library is necessary. Since I’m quite new to Python and have no backward compatibility problems I’ve choose to use exclusively Python 3.
sudo apt-get install python3-picamerasudo apt-get install python3-dbussudo apt-get install python3-pipsudo pip3 install bluedot
Once everything has been installed the Raspberry and the phone must be paired in order to communicate freely over Bluetooth. I followed this tutorial and used the bluetoothctl command.
sudo bluetoothctl
this command has its own command line interface: the commands ...
agent ondefault-agent
enable the pairing agent, then the command …
scan on
start scanning for available devices. Once the my phone has been listed …
pair <device-id>
start the pairing procedure.
When all preliminary operations have been completed I verified BlueDot was working by starting the simple demo Python scripts available at BlueDot site. Among the already povided BlueDot demos one is dedicated to taking a photo at the press of application “blue dot”.

Sending back photos using Bluetooth

BlueDot is a one-way-only communication system, so I thought on I the raspberry could send back photos to cell-phone. The file transfer protocol over Bluetooth most commonly used is called OBEX FTP, back some year ago, when most phones didn't have wireless support, it was more common having to deal with it. Now it’s almost forgotten but still supported both from Linux and Android phones.
OBEX FTP is installed on Raspbian with the following command
sudo apt-get install obexftp bluetooth
As install completed I’ve been able to interrogate my, already paired, phone for available Bluetooth services.
sudo sdptool browse <device-id>
Among the available services I took note of the channel number (12 in my case) of “OBEX push service” the one allows receiving files like a message. After some searching on the Internet I eventually came to the right command to send a file:
obexftp --nopath --noconn --uuid none –bluetooth <device-id> --channel <channel> -p <file>
File transfer is quite slow, even slower than I used to remember, so is not fit as main file transfer mean but it could be enough to get a preview from a display-less camera.

Saturday, 3 March 2018

Sharing files on the Raspberry Pi Zero W

I eventually managed to find some time to continue working to my Pi-zero camera project. During initial tests I took advantage of Pi-Zero wireless interface and used “sftp" command in order to transfer files between Raspberry and desktop computer. A more suitable way of transferring files using USB, like real digital cameras, would be of course advisable.

Raspberry Pi Zero as mass storage

The Pi Zero USB port is directly connected to processor, unlike others Raspberrys using a on-board USB Hub. This, cheaper, solution means the Pi Zero can be configured to act as USB host, like a computer, or as a “USB gadget” like all cell-phones and digital cameras do. In order to activate such “USB gadget” mode some specific “dcw2” kernel modules must be enabled, in my specfic case the needed module is called “g_mass_storage”. I followed this simple guide from a Github user.
First I enabled DCW2 USB driver
echo "dtoverlay=dwc2" | sudo tee -a /boot/config.txtecho "dwc2" | sudo tee -a /etc/modules

then I created a virtual disk image to be mounted as mass storage and formatted if as a FAT32 disk.
sudo dd if=/dev/zero of=/usb-drive.img bs=1M count=1000sudo mkdosfs -F 32 /usb-drive.img
Once the Raspberry PI is conncted to a computer the mass storage can be enabledl ike this
sudo modprobe g_mass_storage file=/usb-drive.img stall=0 removable=1
and disabled with following modprobe command
sudo modprobe -r g_mass_storage
the same virtual disk can be availabe to Raspberri PI by mounting it
sudo mkdir /media/usb-drivesudo mount -o loop,rw /usb-drive.img /media/usb-drive/
of course the same virtual disk cannot be both available as mass storage drive and mounted on Raspberry at the same time, since it could lead to disk corruption. The camera software will have so to manage the switch between two modes.

Wednesday, 17 January 2018

New toy on the desk: Raspberry PI zero W and Raspberry Camera

Just before Christmas I have been to an electronics and surplus fair where I bought myself, among other things, a new Raspberry family “thing”. I started with a vague idea of building my very own “hackable” camera. I didn't have, and still don't, have a definitive idea of how it must be or what to do with it ... just it must be hackable i.e. I must be able to reprogram it once I need it for something else. I so bought a Raspberry Pi Zero kit, including the official withe-red case heath sink and male pin strip, and a 8 M pixel Pi Camera.

Headless installation

I'm getting quite used to prepare and install Raspberry Pi images, it's the fourth time, almost always headless. Plenty of tutorials can be found on the Internet by the way. This time is not very different apart from just one detail: I had to configure the Raspberry to connect to WIFI network from the very beginning.
So after copying the latest Raspbian image on the micro-SD card withe the usual “dd” command
sudo dd if=2017-11-29-raspbian-stretch-lite.img of=/dev/sdd

I configured Raspbian to enable SSH by default
sudo touch /media/maxx/boot/ssh

Then on the same root directory I created a “wpa_supplicant” WIFI configuration file
sudo vim.tiny /media/maxx/boot/wpa_supplicant.conf

Where I wrote down my wireless network configuration
country=ITctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdevupdate_config=1

At last I powered the Raspberry Pi and scanned the WIFI network for the new entry computer.
I connected trough SSH and I went, of course, trough the usual post-installation operations like changing the Pi user password and expanding the file system to the full micro-SD extent.

Pi Camera installation

Once I verified the Raspberry was correctly working I powered it back down and connected the Pi Camera using the small flat cable also included in the Pi-Zero kit I bought.

Sunday, 31 December 2017

Saturday, 30 December 2017

Backing-Up Your Data With Raspberry Pi

Among information technology bad practices not backing-up your data is the one you are going to regret more as something goes wrong. For too many years I’ve been relying solely on the good health of my disk drives, that means I was relying mostly on good luck, and on manually copying data, mostly photos and videos, on different supports. I decided so to buy myself a bigger disk drive with the sole purpose of keeping a backup copy of my data.

Hardware set-up

First things first, I bought an external 2TB USB disk. The disk size is enough to backup my 1TB NAS disk and other data I actually keep on the Raspberry Pi server or the desktop PC. More importantly the disk is externally powered since the Raspberry couldn’t power it by itself.
I formatted the , with the XDS file-system, by using the tool provided with my NAS disk, after attaching the new disk to the NAS spare USB port. This step is not strictly necessary but it will allow me, in future, to share the backup disk just by connecting it to the NAS USB port.
I then connected the backup disk to the Raspberry Pi 3 and configured the /etc/fstab file in order to mount it on start-up
/dev/sdb1 /media/backup xfs rw,defaults 0 0

Software set-up: rdiff-backup

While I was looking for a backing-up software solutions I was mostly thinking to some directory mirroring tool like RSync but, like often happens, I stumbled in a more complete solution when I did read this page describing a backup system based on Raspberry Pi and rdiff-backup.
Rdiff-backup is a command line based backup tool, it provide all basic backing-up features like differential backups or time based restore. More importantly, to me, it’s based on standards tools like Rsync directory mirroring and tar archives, meaning that archives are easily readable without the need of rdiff-backup itself.
I installed rdiff-backup with apt-get tool:
sudo apt-get install rdiff-backup

Then created some target folder in the backup drive
sudo mkdir /media/backup/public
sudo mkdir /media/backup/nas
sudo chown pi:pi /media/backup/public/
sudo chown pi:pi /media/backup/nas/

Then I manually started the initial backup, knowing the operation was going to take some time I started a independent shell session with the screen command.

rdiff-backup --exclude /media/public/BTdownload /media/public/ /media/backup/public/

The backup command just needs source and destination folders path, many optional switches are available like the one I used, “--exclude”, which exclude from the backup process some sub-folder.
Once the initial backup completed successfully I used the crontab command to schedule the backup command.
crontab -e
Since most of backed-up data are photos and videos I produce during week-ends I scheduled it weekly ad Tuesday (Monday is already SD-card backup day)
0 5 * * 2 rdiff-backup --exclude /media/public/BTdownload /media/public/ /media/backup/public/

Some notes on performances

The initial backup of my photos and videos collection, about 300 GB, took most of the day to complete. The poor performance is mostly because I keep my data on a Samba share. Rdiff-backup documentation discourages backing up networked disks through in favor of the better optimized SSH protocol, unfortunately my NAS disk doesn't support this option. Not a big problem in my case anyway, because future differential backups will need less time, of course, and the backup process will be performed automatically between two always-on devices.