Gathering Caller ID info

I'm looking at ftp://nic.funet.fi/pub/doc/telecom/caller-id/frequent.asked.questions. The description of how Caller ID data is passed looks something like a serial connection to me. If I setup an Arduino serial connection at 1200 baud to listen after the first ring, could I then hear this information and allow the arduino to take action based on it? Perhaps I am showing my ignorance in electronics. I'd appreciate some direction to why not if I'm completely off my rocker. (Thanks!)

It says:

As a 1200 baud, 7 data bits, 1 stop bit data stream usually
transmitted following the first and before the second ring signal
on the line.
...

The "short form" stream consists of a set of null values,
followed by a two byte prefix, followed by the DATE (Month/Day),
TIME (24 hour format), and number including area code in ASCII,
followed by a 2s compliment checksum. Most modems/caller id
devices will format the data but the raw stream looks like this :
0412303232383134333434303735353537373737xx
or (prefix)02281334407555777(checksum)

A formatted output would look like this:
Date - Feb 28
Time - 1:34 pm
Number - (407)555-7777

So I found that the MT88E46 would probably help me out in this direction quite a bit, but I still wonder if I could get away with doing it all in software.

I still wonder if I could get away with doing it all in software

Probably. There are several packet radio devices that do software decoding of 1200 baud (Bell 202?) signals.

It isn't a simple serial connection though - it is modulated. In 1 is represented by a 2200hz tone and the 0 by a 1300hz tone. This is known as frequency shift keying (FSK).

To bit-bang the decoding, you have to look for the two tones (usually by detecting when the signal goes to zero, known as Zero-crossing detection or ZCD).

I'd get an IC to do the decoding.

-j

Thanks, it does sound like a lot of guess and check before I'd get even close. I see why the IC route is preferred. :slight_smile:

I see why the IC route is preferred.

Being a software guy by training, of course my preferred solution is to throw hardware at the problem. :slight_smile:

-j