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:

Which I purchased from here for $30.

http://store.linksprite.com/pstn-caller-id-module-for-arduino-pcduino/

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.

Resources

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

• LinkSprite CID Tutorial (connects to an Arduino):
• HT9032 Data Sheet
• HT9032 Application Note

Wiring

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:

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:

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

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:

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:

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

Here is a break down of the call data:

UUU...UUU

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.

3/4

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.