Académique Documents
Professionnel Documents
Culture Documents
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.
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!
1. Phone lines require a 600 Ohm "balanced line". You can't just slap any
old circuit between your "TIP" and "Ring".
2. 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.
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.
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.)
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
BroHogan at 2:29 PM
41 comments:
thanks in advanced
Reply
Replies
Reply
thanks
Reply
http://www.digikey.com/product-detail/en/MT2492SMI-L-92/591-1064-
ND/1681859
Includes DAA, dtmf, all the good stuff, upgraded modules include voice
record/playback and speakerphone I/O...basically everything you want to
do, and it's an approved device. I'm pretty sure adding an arduino doesn't
compromise that. I mean, adding a computer to your faxmodem doesn't
invalidate it's fcc compliance.
Reply
Is it as simple as sending analog data to the TX line of the DAA and reading
analog data from the RX line of the DAA???
Reply
LuizAnonio Nascimento August 1, 2013 at 10:53 AM
Hello could you send me a schematic to make the link with the Arduino, I
learned to make this connection with the pins of the arduino right.
email: luiz_antoniosp@yahoo.com.br
Reply
Replies
Reply
Reply
Replies
Reply
Replies
BroHogan December 6, 2015 at 12:52 PM
I'm not anxious to re-look at a project I've done 6 years ago. I
think you can figure out which pins go where by looking at the
schematic and the pin map in the sketch. I'm pretty sure I have
provided all you need to duplicate this here.
Then if you have any specific questions I'll try to answer them.
Reply
Add comment
‹ Home ›
View web version
Powered by Blogger.