Go Down

Topic: Telephone Caller ID Dev Kit (Read 1 time) previous topic - next topic


Oct 23, 2019, 06:31 pm Last Edit: Oct 23, 2019, 07:14 pm by 6v6gt
This is a relatively straight forward but comprehensive development system for creating the basis for landline (fixed telephone network) caller id applications such as display of incoming caller number and details, storage of call data, spam call protection etc. from the data transmitted along with each telephone call during the ringing phase.

It supports the main protocols for data transmission (MDMF and SDMF) but not the less used DTMF and other signaling methods like interrupted dial tone etc.

It consists of a reference server based on an ATMega328P with some signal conditioning hardware which demodulates and parses the encoded data, a number of alternative example  clients demonstrating different communications methods with the sever (SPI, Serial, I2C) and using different hardware platforms (Windows, ESP32, Raspberry Pi, AVR and Texas Instruments  MSP432P401R).

For simple applications, the server can even be used stand-alone without a client part, but then care is required when integrating code with it to avoid resource clashes with the signal processing functions. The sample clients have limited functionality, but enough to demonstrate transfer of call data etc. from the server part. Also referenced is a Java script based application for generating test data (incoming call, message waiting etc.) so the system can be tested independently from a telephone installation (published separately - [*Ref11]).

This solution uses easily available components and does not rely on any telephone specific chips.

Splitting the application over a server part and a client part has a number of advantages, but mainly that the user can develop an application incrementally and including features like call storage, telephone book lookup, special display logic etc. etc. without having to touch the core code for demodulating and parsing the transmitted data and this is a classic "offloading" scenario.

Further, the demodulator is quite an intense activity and can be impacted be other activities e.g. continually scanning a touch screen or a web server checking for client connections etc.

Another advantage this offloading brings is that some of the platforms either have no ADC or one of insufficient performance, so since another supporting chip is required for a solution anyway, so why not use one which is programmable and that includes a strong ADC.

Incidentally, this is one of the few areas where the ATMega328P is a more useful chip than, for example, the ESP8266 due to the performance of its peripheral devices (or maybe just unavailability of sufficient supporting documentation to exploit the full performance of such features).

The project is also interesting in that it is an illustration of the some of the possibilities for  interfacing between an AVR Arduino and a variety of different clients using several protocols.

I have published a couple of complete designs in the past for caller ID systems (see appendix [*Ref9] and [*Ref10]), but these were not really beginners projects. This is different in that it could  be tackled by a beginner but using the server in stand alone mode, say with the optional LCD and omitting any of the client options.  However, it stops at the point where it delivers decoded data. The user must then write routines for presentation and, if required, transmission, storage and retrieval of the data.

*References refer to the PDF document.

Server part:

Architecture including optional clients:

The attached zip file includes the software for the server part and all optional clients and also includes a sample audio file for testing the demodulator and parser-

The full PDF documentation including schematic is, because of its size, attached to the post #1 in this thread.


Oct 23, 2019, 06:31 pm Last Edit: Oct 23, 2019, 06:40 pm by 6v6gt
Schematic and Documentation attached.


Sep 11, 2020, 11:43 am Last Edit: Sep 11, 2020, 11:59 am by Athanassios
Hello My friend.

In your old version you were using the op-amp LM358N which included a "virtual ground" near the Vin- . (100k RV2)
(First Version)

In your updated version you replaced the LM358N opamp with the MCP6002 but you completely eliminated the virtual ground near the Vin-. Second Version

I assume without virtual ground it will not offset the output signal near 0v.  

May I ask you about the logic behind eliminating the virtual ground in your updated version?

Thank you


The MCP6002 op amp was introduced with an ESP8266 (3.3 volt) version of this circuit https://forum.arduino.cc/index.php?topic=528459.0. The performance of the LM358N is too poor at 3.3volts, hence the introduction of the rail to rail MCP6002. I continued to use this in the latest "Devkit" version, although that reverts back to 5 volts.
Only the ring detector part of the circuit has been substantially changed. This is looking for a signal over about 0.7 volts (above the voice channel). The part for handling the AFSK signal over the voice channel is more or less the same in all versions. I'll try to find  the simulations I ran to support the redesign.
In any future design, I'd anyway probably use a suitable opto coupler based ring detector on the high voltage side of the circuit. It would be easier to test and eliminate the software ring frequency detection.

Go Up