#bcm2835

So at first i've searched for a tts-tool. Very popluar are festival and eSpeak. For using synthesized speech later its important to cache speech as wav-files - such an option is alread included in both tools (espeak -w / text2wave). I've compared both tools on raspberry pi - the synthesized speech sounds similar, but espeak seems to be a bit faster with generating wav-files and is more adjustable. But at least which tool is choosen is a question of taste. Both tools are available via apt:

sudo apt-get install espeak espeak-data sudo apt-get install festival

For making calls i've decided to use a sip/voip based system. I've found at least two possible tools which are controllable via command line: Linphone (linphonec/linphonecsh) and PJSIP. After a few tests i've sorted out linphone because its way to difficult to include into own applications/scripts in comparison to PJSIP. PJSIP delivers not only a command line interface - it provides a powerfull library/api (PJSUA) for using within own sip-based projects - so it was predestinated for my proposition.

For start using PJSIP/PJSUA you need to download and compile it by yourself - its not installable via apt but this is not really a problem:

sudo apt-get install subversion svn checkout http://svn.pjsip.org/repos/pjproject/trunk

sudo apt-get install build-essential automake autoconf libtool libasound2-dev libpulse-dev libssl-dev libsamplerate0-dev libcommoncpp2-dev libccrtp-dev libzrtpcpp-dev libdbus-1-dev libdbus-c++-dev libyaml-dev libpcre3-dev libgsm1-dev libspeex-dev libspeexdsp-dev libcelt-dev

cd trunk ./configure && make dep && make clean && make && make install

After finishing compilation (you can have a coffee or two meanwhile) you can test a bit around with pjsystest or pjsua which are available in /pjsip-apps/bin. With the actual raspbian-os i've discovered some sound-problems with making normal calls to another phone (echo/jitter) which seems to be alsa/pulse-based.

For my proposition i've created two tools: sipcall and sipserv. With sipcall you can easily make an automated call to a specified number with a text to speech. Its easy usable via bash-script for example to check a system or sensor state and place a call if a critical threshold is reached. Sipserv however acts more like a service - you can make a call to it and query informations or execute commands via phone (your sip-provider needs to support inbound dtmf - i'm using sipgate, which works fine). You can download them from my github-repository. For compiling both tools you need the pkg-config-package:

sudo apt-get install pkg-config make

I've also created a simple bash-script for checking actual load and placing a call if load is too high. For sipserv there is a sample configuration and a bash-script for starting/stopping the service available. All files are well documented to understand how it works - general infos are also available in the readme-file.

Luckily the BCM2835 SoC has a hardware-based watchdog timer on board - but sadly there are no further informations about it in the actual datasheet. If i'm right informed this watchdog timeout register has 20 bits and counts down every 16µs (source: Raspberry PI BB), so the the hardware timer limit is something around 16 seconds (16*2^20µs) which seems to be right according to bcm2708_wdog module source. The actual firmware includes the driver-module bcm2708_wdog (or if you compiled your kernel by yourself ensure that you have enabled BCM2835 watchdog support [CONFIG_WATCHDOG=y, CONFIG_BCM2708_WDT=m|y]). Just load it and add it if necessary to your modules-configuration for loading it at startup:

sudo modprobe bcm2708_wdog sudo nano /etc/modules (add line "bcm2708_wdog")

This will create the device /dev/watchdog. The watchdog is automatically started once the device is opened. Once the watchdog is started, it needs to get feeded with heartbeats - this is done by writing anything but the character "V" to the device (see watchdog api). "V" is a magic character which will disable the watchdog - so it's important to know that just closing the device without writing the magic char to it won't stops the watchdog, quite the contrary will happen and the timer limit will be reached and the reset gets triggered.

If you want to use the watchdog within an own application scenario its recommended to use ioctl-api. For feeding the watchdog you can insert WDIOC_KEEPALIVE via ioctl. You can get or set the soft timer limit via WDIOC_GETTIMEOUT and WDIOC_SETTIMEOUT, but remember that its hard limited to 16s, so if you set a soft-timeout larger than this limit it will be just setted to 15s. Also remember to disable the watchdog by writing a "V" for a straight program exit.

I have written a small test-snippet for demonstrating the use of the watchdog timer within an own application. You can find it in my github-repository - Just build it and play with it - It supports a clean and a failure exit for testing purposes:

cc -o wdt_test wdt_test.c (or just:) make sudo ./wdt_test      (for a clean exit) sudo ./wdt_test -t  (for a failure exit)

If you don't want to control the watchdog by your own, of course you can use a ready-to-use watchdog-daemon, which provides some more features than just feeding the dog with heartbeats every 10 or 15s. It can also run several tests to check the system healthfulness like monitoring memory and load, checking ping-results, measuring temperature or performing user-defined commands to do arbitrary tests and trigger reboot when they fail.

sudo bash apt-get install watchdog chkconfig chkconfig watchdog on /etc/init.d/watchdog start nano /etc/watchdog.conf (enable line "watchdog-device = /dev/watchdog")

So now its time to test if everything works as it should be. Ensure that there aren't any critical processes running and try to cause a kernel panic for example. This can be tried with deactivating any swap space and a nasty forkbomb (: (){ :|:& };:), but more reliable will be a fake kernel-module.