Watchdog for asterisk: implementation (Part VI)

Part VI: Coping with Changing Temperatures

Ceramic capacitors come with nominal values, but there is typically a relatively large range of tolerance (e.g., 20%). In addition, its effective capacitance varies with temperature. This is a particularly nasty problem for timing circuits whose parameters are based on RC. This plainly titled article explores some of the mechanisms of capacitance variations. Here is a short white paper with information on the temperature coefficients of ceramic capacitors, including an explanation on the various designations (X5R, Y5V, NPO, etc.). Ah, things one never quite learns in school ...

The two subcircuits of the watchdog, namely, the tone detector and the missing-pulse detector, each have an RC timing network. For the tone detector, the RC value determines the center frequency of the tone. For the missing-pulse detector, the RC value sets the time-out period when no pulses are seen at the input.

Since the time-out period is not required to be accurate (45 seconds or 55 seconds doesn't really matter, since we'll be sending pulses in 5-10 second intervals), we can use a fixed resistor (1Meg) and a fixed capacitor (47uF). For the tone-detector, on the other hand, a higher accuracy is required, even though there is a bandwidth tolerance. A trimpot was used to allow some adjustment during prototyping, and its setting is left alone after that.

As I anticipated some variation in the center frequency due to changing temperatures (on a typical day, the high and low temperatures of location of my linux server can easily have a range of 20-degrees centigrade), I generated sine-wave tones of 0.1 seconds each, ranging from 18950Hz to 20000Hz, in 150Hz intervals. The reason that these frequencies are higher than what I had during prototyping and tuning is that the location of the finished product is hotter, thereby decreasing the effective capacitance of the capacitance that sets the center frequency. In addition, the temperature becomes higher during the day; so at least one or two of these tones should be detectable by the tone decoder.

Here is the asterisk_watchdog script:

#!/bin/sh

TONES_DIR=/etc/asterisk/watchdog/tones
INTERVAL=5
amixer set 'Master' '100%'
amixer -- set 'PCM' '-4.50dB'

run_watchdog()
{
while (true)
do
  if [ -f /var/run/asterisk.pid ]; then
    ASTERISK_PID=$(cat /var/run/asterisk.pid)
    RUNNING=$(ps auxw|egrep '^[^ ]+ +'$ASTERISK_PID' '|grep -c asterisk)
    if [ $RUNNING = "1" ]; then
        for tone in ${TONES_DIR}/*.raw
        do
          aplay -q -f cd $tone
          sleep 0.5
        done
    fi
  fi
  sleep $INTERVAL
done
}

run_watchdog &

The amixer settings were derived by trial and error. At these settings with my raw files (magnitude 0.45 from audacity), the tone decoder seems to work the best.

The "*.raw" files are raw (headerless) samples that can be played by aplay with -f cd. Initially, I generated one .raw file for each frequency, and by making the watchdog script read from the directory of raw files, I can easily add and remove additional frequencies. However, when I was satisfied with the set of frequencies, I combined these all into one raw file, with 0.35 second of silence in between. In the end I just need one file, so that aplay won't be called multiple times per iteration.

Note that the main loop is encapsulated in a shell function, and the last statement of the script is an invocation of the function followed by the backgrounding ampersand &. This is a nifty way of running a shell script as a daemon. I also wrote (copied-pasted-modified) an asterisk_watchdog init.d script and placed it under /etc/init.d, and added it to the list of daemons to be started at regular runlevels (2, 3, 4, and 5) via chkconfig.

And now the watchdog is running. It's been running pretty reliably for more than a week now, and I am very happy with the result.

Of course, one question remains: who will watch the watchdog? (See next part.)

UPDATE (2009-07-15): I stumbled upon this neat article from EDN that uses a "digital variable resistor" (actually a more complex device than the name implies) to perform temperature compensation for a voltage regulator. It would be an overkill for this project to use this device (I might have chosen a better capacitor instead), since I can achieve my objective through software. Nevertheless, I thought the design in the article is pretty cool.