Testing LinkSprite Caller ID Module (based on HT9032) with a PC

I would like to receive caller ID using a Raspberry Pi. I started off trying to use a winModem which failed epically. I then purchased a Trendnet TFM-56U1 which has also failed.

The TFM-56U1 modem works fine in all regards except for receiving caller id. The first one I had would only report caller id about 1 time in 10. I returned it and the second won’t report caller id at all.

After contacting Trendnet, their response is this modem will not support caller id (even though it obviously did at one time based on all the people using it specifically to obtain caller id).

The US Robotics model 5637 modem purportedly supports both Linux and caller ID, but at $40+, it is really too expensive for my testing since in the long run it won’t be my final solution anyway.

So I went looking for some device that would serially transmit caller ID. I found it in this LinkSprite Caller ID Module:

linksprite cid fig1

Which I purchased from here for $30.


Yes, it is not much less than the USR modem, but I’m thinking the HT9032 chip it is using may well be in my final design.


In getting this to work, I referred to the following resources:


I used an FTDI breakout board like this to interface the CID unit to a PC’s USB port:


The FTDI board is wired to the CID as follows:

linksprite cid fig2

Now connect the USB cable to your PC. It should find the drivers w/o much trouble if you used any FTDI device in the past. If not, you will have to locate the drivers.

Once the drivers are installed, the CID boards is accessed as a serial port:

linksprite cid fig3

Now connect a terminal emulator of your choice to the COM port using 1200 baud:

linksprite cid fig4

Once you connect to the CID board, garbage is going to start printing. That is OK. Well, appears to be normal anyway. According to the data sheet, the output line is held high when there is no data. That seems to translate to garbage being transmitted.

Here is what I see between calls:

linksprite cid fig5

My terminal emulator displays control characters, so I can see *everything* being transmitted. For example NU = null or 0x00.

Once I receive a call I see:

linksprite cid fig6

Removing the ‘garbage’, I’m left with:

linksprite cid fig7

Here is a break down of the call data:


When call data is about to be presented, the CID board will transmit alternating 010101… for 300 bits. Those 01’s become a string of ‘U’s.


The CID board then transmits 180 1’s. For the serial port, this may end up as one or more random characters.

When the CID board outputs a 0x80, that is the beginning of the actual data.

ASCII      HEX     Dec   Len   Pkt Position   Desc
<80>       80      128    1    N/A            Start Packet
'          27       39    1    N/A            len of entire CID string (start with next byte, exclude checksum at end)
<sh>       01        1    1     0             indicates packet is date/time
<bs>       08        8    1     1             len of date/time packet
date/time                 8     2             05221609
<sx>       02        2    1    10             calling line packet (e.g. phone # of caller) 
<lf>       0A       10    1    11             length of phone# packet
phone#                   10    12             8005551212
<bl>       07        7    1    22             name packet
<si>       0F       15    1    23             length of name
name                     15    24             wireless caller
<          3c       60    1    39             checksum

After this packet data, the CID board will begin transmitting garbage again.



This entry was posted in c-electronics and tagged . Bookmark the permalink.

3 Responses to Testing LinkSprite Caller ID Module (based on HT9032) with a PC

  1. Hey Big Dan,

    I’m also interested in getting caller id info on a Raspberry PI. Actually I want to go father and make an answering machine. Do you think the LinkSprite Caller ID Module can also pass the voice through to be captured as binary data?

    Thanks, Lou

  2. Hi Dan,

    Thanks for the reply. The Clare CYG2020 sounds good. I may buy one and see what I can do with it but wiring up chips like this will be a new experience for me. So if you make any progress, please let me know. Writing the code to control things is where I know what I’m doing. I will probably use Squeak Smalltalk.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s