The basic idea was to allow the MCU to make calls by transmitting DTMF tones, and to receive and decode DTMF tones (keystrokes) made on the phone that was called.
There are other possibilities however. Using the complete interface, it should be possible for the MCU to answer calls, and to transmit "room sounds" picked up by a microphone to the other phone.
If you're only interested in sending and receiving DTMF tones and not interfacing to a phone line, you can skip the next dozen or so paragraphs. The schematics and code samples will still apply.
It all begins with the interface to the actual telephone line. Unfortunately this is trickiest part!
There are two reasons for this:
- Phone lines require a 600 Ohm "balanced line". You can't just slap any old circuit between your "TIP" and "Ring".
- It's illegal!
Lets start with #2. Here I'm speaking from a US and Canadian perspective, but I'm sure it's similar in many countries. In the US, it's FCC Part 68 that makes it illegal to connect any unapproved device across your phone lines. So what can they do? Well, I'm sure it's much worse than tearing off that tag on your mattress. I've read that if you create a problem that must be investigated by the phone company, and it's due to a little circuit you whipped together - your financially liable to cover the cost of the phone companies time. And it's relatively easy to do horrible things to your phone line during the process of creating an interface, and that leads to point #1.
When you Google "phone interface" you'll be drinking from a fire hose of circuits, methods, and projects. I spent a lot of time researching them, and did indeed come up with an interface that "worked". However, what I ended up with, struck me as being sensitive to component values, and somewhat "fragile". By this I mean, for example, that the correct "polarity" for TIP and RING was required. Given that the line should be "balanced" I felt like I disturbed the balance of the force. In short, after all of my experience with electronics, I felt like I was over my head with the interface I came up with. Ironic considering you're dealing with a system that has been around for so long.
For those who want to ignore points 1 & 2 above, here are some of the best resources I found, as well as the schematic for the "working" interface I was using. Big disclaimer here! I do not recommend building your own unapproved interface. Furthermore, I am not responsible for anything you do with any information I am providing. Everything here you use at your own risk.
Some of the telephone interface links I found helpful are:
Just looking at the variety of this information should give you an idea what your up against when rolling your own POTS interface. The interface that I tried is here.
Not a very encouraging beginning is it?
Enter the "Direct Access Arrangement" DAA. This little module is an FCC Part 68 approved interface. Does it make everything OK? I don't think so - it really just makes it a lot easier for you to get your device FCC approved. Will it give you peace of mind? You bet. After switching to a DAA, the TIP and RING polarity did not matter, and everything seems to be much more solid - calls go through 100% of the time. The DAA also saves you from buying an isolation transformer, relay, transistor, and a large capacitor.
The problem is getting your hands on one without having to special order 54 of them from Mouser, etc. After a lot of searching, the best deal I found, for my use, was for a Cermetek CH1817-LM (discontinued) still some left on eBay - here. It will cost you $15-$18 shipped.
Note: If your interested in capturing caller ID, I don't think this is the DAA for you. However, while searching I did see some that will output CID. I also ran across the Holtek HT9032C which looks like an interesting CID chip, but they seem to be hard to find.
Sorry if the above was long and detailed. I wrote it in the interest of saving you a lot of time. However, as always, YMMV.
Once connected to the phone line, I wanted to do several things:
- Have the Nex10 dial my cell when an event ("macro") was triggered.
- Leave a message - a series of beeps.
- Optionally be able to listen in on the room noise from the called phone. (work in progress)
- Capture any key presses I made from my cell. (Not sure how I want to use this yet.)
Note that currently all the communication is initiated by the Nex10. In fact, it is possible to use the RI (ring indicator) on the DAA to answer calls with the Nex10. (No plans yet for this.)
To do the things above, I used 2 chips from Holtek - an HT9200B DTMF generator to dial the call, and a HT9170B DTMF receiver to read the key presses once connected. Both are less than 70¢ each at Futurlec.
I wired both chips per the datasheets and ran the HT9240B in serial mode. Here is my schematic and an Arduino example sketch for the project at that point.
I could have stopped there, but even with serial mode, the interface to the MCU required 8 pins + power. I also want the Nex10 to accept "plug-in modules" - so an I2C interface seemed like the way to go.
I picked the PCF8574 I2C GPIO chip to go between the MCU and the DTMF chips. It's also available at Futurlec and is also wired per the datasheet. (Note: the PCA8574 is a newer version and runs at the faster I2C speed but was not carried by Futurlec.)
Both the DTMF receiver and the I2C GPIO have a nice feature that sets an interrupt line when new data is received. I wanted to use the INT line on the GPIO. However, because the DTMF receiver latches it's output, there was no easy way to read multiple presses of the same key. So, I am currently using the interrupt on the DTMF receiver (DV). Either way an external interrupt is triggered when new tones are received. This saves me from having to poll for changes.
Using the I2C GPIO with the interrupt line saves 5 pins on the MCU. Here is the current schematic and Eagle files. And here is the current example sketch for the completed project using the DAA, DTMF, and GPIO.
The short movie below describes the state of the project before adding the GPIO. (Looks the same now - only less wires to the Arduino.)
Enjoy
The short movie below describes the state of the project before adding the GPIO. (Looks the same now - only less wires to the Arduino.)
Enjoy
