Remote Thermostat Update: Getting vgetty working on Raspberry Pi with cheap USB modem

For a little background on this, check out the project requirements. Vgetty should allow me to script in some menus that recognize DTMF tones to run commands. It also appears to support transitioning to a data connection with a specific input code.

The should be perfect for the project once it’s all working. The hard part was finding a modem that would work. I didn’t want to have to get a serial modem that is larger than the Pi, and add a USB-serial converter.

I did some looking around and found this cheap USB modem. Yes, that’s an Amazon affiliate link. Use it if you find this article helpful, but the modem is a TRENDnet TFM-561U if you’d prefer to find it on your own.

Based on the specs it looked like this modem should work, and it does. It uses the Conexant CX93001, so most of this should apply to any of the modems using the CX930xx Series chipset. I ran into some problems with vgetty, but I was able to find a pretty simple solution.

I’ll give the short version for getting it running in Raspbian on the Raspberry Pi, then I’ll fill in some of the details.

Install vgetty and pvftools. Pvftools are used for manipulating the audio files used with the modem, and will be used later.

sudo apt-get install mgetty-voice mgetty-pvftools

Following the vgetty beginners guide, edit /etc/mgetty/voice.conf. There are two important changes to make here, but most of it can be saved for later. The voice device needs to be set for the vm tool, and vgetty needs to be forced to use the V253 modem commands instead of letting it auto-detect.

The first thing to change is in the generic section. The line containing ‘forceV253subset’ needs to be uncommented and changed to true. This is modem dependent, but it may help to get other modems working as well.

forceV253subset TRUE

The second thing to change is in the vm section. The ‘voice_devices’ line needs to be updated to point to the correct device. In this case:

voice_devices ttyACM0

Next a line is added to /etc/inittab to start vgetty. I had to do it a little different than the suggestion, so here’s my completed line:

T3:2345:respawn:/usr/sbin/vgetty ttyACM0

Run ‘sudo init q’ to reload the inittab and vgetty should be running. You can perform some tests and other functions with the vm tool. Try ‘sudo vm help’ to get started with that.

I’ll get to more advanced configuration in another article. If you’re having trouble, or are otherwise interested in how I figured this out, keep reading.

To figure out the tty for the USB modem I ran ‘dmesg | grep tty’ and looked over the results. This line looked right, so I went with it:

cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device

I tried ‘sudo vm devicetest’ and got some promising results, so I went on to try ‘sudo vm beep’. This failed, so I turned up the logging level by setting ‘voice_log_level 6’ in voice.conf. I tried running some of the commands again and checked the logs. I discovered lots of errors from unsupported AT commands.

I realized that vgetty was loading the wrong modem “driver.”  My first reaction was to read through the modem chipset’s manual and dig into vgetty’s source to try to build a new driver for this modem. While I was digging through the source, I realized the ability to force-load generic drivers was built in.

I saw that the ‘AT+IFC’ command could help determine whether to use the V253 or its subset driver. I went ahead and used screen to communicate directly with the modem by typing ‘screen /dev/ttyACM0’. ‘AT+IFC’ returned ERROR, so this modem uses the subset. You can try typing ‘ATI’ and ‘ATIx’ where x is any single digit to see the various responses. Ctrl-a then ‘k’ will kill the session when finished.

After updating voice.conf with ‘forceV253subset TRUE’ I ran the vm devicetest again. It returned some better looking results, but more importantly there were no major errors in the log files. I tried vm beep and actually got a beep through the phone line. If you haven’t restarted or reloaded the inittab by now, do so by running ‘sudo init q’.

With the default settings vgetty should now answer after the specified number of rings, beep, then record a message for up to 5 minutes. If the 5 minute limit is reached it will beep again and save the file. The recording can be stopped by dialing # and the file will still be saved.

The silence and hang-up detection don’t seem to be working with the default settings. The sound quality for recording voice is very bad, but higher pitched tones seem fine. I’m thinking some of these problems are limitations of my test rig, and others are likely configuration problems.

I guess it’s worth noting that I picked up a phone line simulator for testing. You can build your own, buy one, or just use an actual phone line. I got a used Skutch AS-26 for a decent price on ebay.

 Look out for the next post for more on vgetty configuration and scripting.