Tag Archives: esp8266

Wifi CLIP v1

Wifi CLIP Thingy

Forgive me for the click-bait summary. Well, what I said there is not entirely false.

Its been more than just more than a year since I re-started my electronics hobby (since some 16 years ago, I guess). Around that time (1 year, not 16 years) an oldish DIY project article on the Internet clued me in that caller ID was transmitted as DTMF tones (in India). It was true, I even could read the info with CM8870. Within a a couple of months I noticed that the DTMF business was not working but my phone was displaying the info – which means the exchange did not disable the feature. This meant they switched the signaling. Couple of experiments with an opamp and DSO proved it – they were using FSK (wiki)

The 3 portions of the CLIP signalling.

The 3 portions of the CLIP signaling.

Then came the futile attempt to demodulate it using a CD4046 (PLL). Lot of trial and error but could not get clean bits out of it – something to do with lousy low pass filter design. After some googling I came to the standalone decoder chip HT9032. It does the demodulation and gives us plain logic output. There are two variants of this chip, the ‘C’ and ‘D’ – the D version is the smaller one with 8pins but does not offer ring detection (that has to be done separately).

Portion of the FSK signal

Portion of the FSK signal (at the boundary of the stretch of ‘1’s and the data)


There are four blocks in the circuit

There is always a block diagram !!! (POTS = telephone line)

  1. FSK Demodulator which converts the FSK signal to stream of UART like bits
  2. Ring detector which give a logic high when the high voltage ring signal arrives.
  3. Caller ID message (CND) Parser which pulls out the data fields from frame of data
  4. Wifi interface that dispatches the info for fun and profit.

The Telephone decoupling

Transformer's revenge

Transformer’s revenge. I had pulled out a fallen transformer (from an ADSL splitter for first experiment – its not a 1:1 transformer).

The telephone lines (called TIP and RING) don’t have ground reference so we can’t really stick it on to one of our chips (unless it knows what its doing). One usually has to use a 1:1 transformer with (600 ohm facing the PSTN line) to get the signal – I’ve used one of those to get the audio signal for HT9032 to devour. The ring detection is separated using an opto-coupler (4N35, its a ‘jelly-bean’ variety I think).

I once tried not using the 1:1 transformer and instead using just capacitors – all sort of noise from micro-controllers went back up the line – so, that’s not a good way to do it.

Key interconnects

  • The ring detector output (from the LM393) goes to the ATTiny84 PA1 (Port A, bit D1)
  • Demodulated logic stream from HT9032 goes to ATTiny84 PA2.
  • The unpacked number info (or error) goes from ATTiny’s PA0 to the UART0 RX of the ESP8266 module.
A portion of the schematic.

A portion of the schematic. Click the pic for the full schematic.

There is a jumper on the ESP’s UART0 RX line to select between ESP’s serial programming input and the ATTiny’s output.

Software CND parsing

The message frame that comes from the demodulator mostly carries only one type of message the ‘CND’ (Caller Number Delivery). Telephone company may provide other kind of services for e.g. CNAM (not seen any of those). I used an Arduinoâ„¢ clone in the first prototype to parse the message and send it for further processing. I later used an ATTiny84 micro-controller. The parser is not stable as the logic stream is not rock solid in pulse width as a typical UART signal (although the framing is same). I’ve added lot of fuzzy guess work to figure out the bits (You can check out the source code and suffer).

CND Message

CND Message. The message bytes are in hex – the date, time and number are ASCII text. Summing up all the bytes including the checksum should have remainder of 0 when divided by 256 (Which I don’t do in the code).

Forwarding over WiFi

The star of 2015 ESP8266 does the job of forwarding the CLIP info. I’ve continued the use of Raspberry-Pi and Node-Red + mosquitto combination I mentioned in my earlier post about dot-matrix display. This time the ESP “publishes” the information to (or ‘as’ ?) the topic /clipdev on the MQTT agent running on the Raspberry Pi. A sample flow available at aniline/clip_display_flow.json does that and sends it to the dot-matrix display. If you want to try it you can copy the JSON text and paste it in new flow sheet on the NodeRed UI. After that you can select the portion that grabs the CLIP info and save it as a sub-flow or attach other elements to it.

Portion of the CLIP grabbing flow. Why make a single function when you could have fun with all those boxes.

Portion of the CLIP grabbing flow. Why make a single function when you could have fun with all those boxes.

Some fixing needed, what next, etc.

  • Reliability (read usability): The de-modulator spew out wrong bits occasionally.
  • Power supply regulation is non-existent on the existing prototype and right now I run it using a mobile phone charger with a USB micro-B connector at its end.
  • There are lots of ‘defensive’ / conservative telephone decoupling. It could lose some zener diodes and capacitors.

This happens to be my first more involved use of Kicad. Had made a couple of symbols, foot-prints and 3D models for this. They are available on github (links below).


There are a bunch of nice articles on various methods of interfacing here:

MQTT Display

I had been fooling around cheap ESP8266 based modules. Running HTTP server to do the network end of module. It never felt right because it felt too heavy and clunky, the web server, often having trouble with concurrent connections. However the combination of Node-Red and MQTT really looks promising – learned it from Peter Scargill’s blog. I used tuanpt/esp_mqtt and a Max 7219 based dot matrix driver on arduino to build an MQTT display. So it subscribes to topic like /leddisp1/show and various kinds of messages (though I had originally meant for it to show caller-id info for my wired phone).

The board itself is a kludge and you’d find lot of connectors left open for experimentation. The ESP8266 module communicates with the Arduino Pro Mini clone (5V, 16 Mhz) via SPI with ESP acting as master (and does the clocking). You can see really ugly diode based level shifting, which did work on bread board prototype but broke on the PCB I made. The dot-matrix I’ve got display is a set of 6 daisy chained Max7219 based 8×8 single color displays.


Schematic (Click)

The display would show stuff you publish as payload on the topic /leddisp1/show Also the payload has a format like <m>,<n>,<message> where m is the number of seconds the display should be showing the message, n is an option telling the display to scroll (when its value is “1”) and not to scroll (when its value is “0”). So you can do something like the following on Linux:

bash$ mosquitto_pub -h MQTT-broker-hostname -p MQTT-port \
-m "5,1,Kake is a lie" -t /leddisp1/show

In my setup Node-Red and MQTT broker (mosquitto) run on a Raspberry-Pi, which felt just right. Although Node-Red is not really necessary it lets you wire the display up in crazy ways. For instance, couple of clicks and I had a the display showing current time.

LED Display flow for Node-Red.

LED Display flow for Node-Red.

My ‘test’ flow is shown in the picture above. I’ve marked some ‘sub-flows’ like ‘serializing’ a JSON payload to the display’s message format (mentioned above) marked in green. There is a pretty MQTT topic which accepts JSON payload. There is an HTTP element which you can use to display stuff by making a request like, say:


Since the picture itself does tell you whats inside the elements, I’ve pasted the flow aniline/led_display_flow.json

References, code and stuff.