Voice Announcements via Modem

We have a PBX system through which it’s possible to make announcements, some of which I find myself making regularly.  Having an old voice modem lying about, I decided to program it to make regular announcements for me.

Rather than dedicate a modem to voice announcements, I decided to share a modem that’s also used for HylaFAX, on the principle that the less hardware to have to worry about, the better.  HylaFAX shares a locking system with minicom, meaning that if I use minicom for the voice announcements, I don’t have to worry about who has control of the modem, or of relinquishing control to HylaFAX.

I located an ancient voice command  manual for my US Robotics voice modem online.  While it took some trial-and-error, I eventually whanged together this script:

#/bin/bash
if [ "$1" = "--help" ] || [ "$1" = "" ] || [ "$2" = "" ]; then
echo 1>&2 Usage: $0 [# to dial] [voicefile.rmd]
echo --help      this message
exit 1
fi
PID=$$
cd /tmp
echo print "starting" > /tmp/minicom.$PID
echo send "ATZ" >> /tmp/minicom.$PID
echo expect { >> /tmp/minicom.$PID
echo \"OK\" >> /tmp/minicom.$PID
echo } >> /tmp/minicom.$PID
echo send "AT#CLS=8" >> /tmp/minicom.$PID
echo expect { >> /tmp/minicom.$PID
echo \"OK\" >> /tmp/minicom.$PID
echo } >> /tmp/minicom.$PID
echo send "AT#VRN=0" >> /tmp/minicom.$PID
echo expect { >> /tmp/minicom.$PID
echo \"OK\" >> /tmp/minicom.$PID
echo } >> /tmp/minicom.$PID
echo send "AT#VRA=0" >> /tmp/minicom.$PID
echo expect { >> /tmp/minicom.$PID
echo \"OK\" >> /tmp/minicom.$PID
echo } >> /tmp/minicom.$PID
echo send "AT#VSM=129,8000" >> /tmp/minicom.$PID
echo expect { >> /tmp/minicom.$PID
echo \"OK\" >> /tmp/minicom.$PID
echo } >> /tmp/minicom.$PID
echo send "ATS46=255" >> /tmp/minicom.$PID
echo expect { >> /tmp/minicom.$PID
echo \"OK\" >> /tmp/minicom.$PID
echo } >> /tmp/minicom.$PID
echo send "AT#VRA=0" >> /tmp/minicom.$PID
echo expect { >> /tmp/minicom.$PID
echo \"OK\" >> /tmp/minicom.$PID
echo } >> /tmp/minicom.$PID
echo send "ATDT,$1" >> /tmp/minicom.$PID
echo expect { >> /tmp/minicom.$PID
echo \"VCON\" >> /tmp/minicom.$PID
echo } >> /tmp/minicom.$PID
echo "sleep 1" >> /tmp/minicom.$PID
# here's the voice part
echo send "AT#VTX" >> /tmp/minicom.$PID
echo expect { >> /tmp/minicom.$PID
echo \"CONNECT\" >> /tmp/minicom.$PID
echo } >> /tmp/minicom.$PID
echo "sleep 1" >> /tmp/minicom.$PID
echo "! cp $2 /dev/ttyUSB0" >> /tmp/minicom.$PID
# end
echo >> /tmp/minicom.$PID
echo sleep 2 >> /tmp/minicom.$PID
echo ! killall minicom >> /tmp/minicom.$PID
/usr/bin/minicom -S /tmp/minicom.$PID
cat /tmp/minicom.$PID
rm /tmp/minicom.$PID

It’s fairly linear — it puts the modem into voice mode, sets a number of parameters, and escapes to the shell to copy a file to the device.  What remained is to create a file in a format that the modem could consume.

Luckily, Ubuntu has a package called mgetty-pvftools which contains all the binary files necessary to make it happen.  (These files are bundled with vgetty on Gentoo, but vgetty conflicts with HylaFAX, and all I need are the audio conversion binaries.)

It’s several steps to convert, but this script does it handily:

#!/bin/bash
PID=$$
if [ "$1" = "--help" ] || [ "$1" = "" ] || [ "$2" = "" ]; then
echo 1>&2 Usage: $0 [from.mp3] [to.rmd]
echo --help      this message
exit 1
fi
echo "mp3->wav"
sox -V --norm $1 -r 8k -c 1 /tmp/$PID.wav
echo "wav->pvf"
wavtopvf /tmp/$PID.wav /tmp/$PID.pvf
echo "pvf->rmd"
pvftormd US_Robotics 4 /tmp/$PID.pvf $2
rm /tmp/$PID.wav
rm /tmp/$PID.pvf

So, all that’s left to do is to set up the first script in an “at” or “cron” job.  However, it turns out that minicom requires an interactive terminal to run, so simply running the first script from an “at” job resulted in this error:

No cursor motion capability (cm)

Since the script will run minicom without being attended, a simple way around this is to use the “screen” program to provide an interactive terminal for minicom to use within cron/at:

screen -d -m announce.sh 111 announcefile.rmd
Share

LED Isolators for HDD LEDs

LED Isolator

LED Isolator

A while ago, I posted a design for a home-made circuit designed to connect multiple hard drive add-on cards (and the motherboard) to a single case LED.  I made a handful of these for the servers around here, and in the three years or so since then, I’ve yet to see anything similar.  It’s possible that nobody but me actually cares if their case light reflects drive activity across all their drives — then again, it’s also possible that the people who actually cared simply made their own.

On the off chance that anybody wants one, I went to the trouble of making some professional-looking boards.  More detail is available here.

Share