Tried a bit of nostalgia driven "comfort" programming making wmapcups. It is a Window Maker dockapp that presents the status of an APC UPS via the apcupsd.

Window maker itself is a bit dated compared to the 'desktop managers' these days but it is fast if can look past that. If your keyboard sees more action than your mouse and you don't want to to overboard with tiling window managers this is a good trade off. I use window maker at work on one of the older PCs while the newer ones run xfce4. I use dockapps under Xfce through a panel plugin called xfce4-wmdock-plugin which gobbles up X11 programs that provide the hints that they are dockapps.

Dockapps are widget-ey programs with UI made of a small square (64x64 or 48x48 pixels) mostly presenting some information. Most dockapps would serve some purpose now handled by panel (or taskbar) plugins except they have the same consistent 'square' tile feel. The whole 'style' of window maker and dockapps is inherited from the NextSTEP OS.

To write a dockapp, some familiarity with X11 programming would be useful. However its quite simple to glean the essence of it from the existing dockapp sources. Also there is library called libdockapp that wraps up the most common pattern used in the sources. For pythonistas there is a module for writing dockapps as well (I've not tried it yet).

Window maker development was dead for many years during before being started up again in 2012. The current team accepts patches for window maker and few orphaned dockapps that they've adopted.

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)

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).

Hardware

There are four blocks in the circuit

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

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.

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).

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.

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).

Links

• Hardware files (Kicad) : aniline/wifi_pstn_cid
• Firmware files (AVR and ESP8266): aniline/wifi_pstn_cid_fw
• My basket of kicad schematic symbols (not too many, I guess I'll adding to it): aniline/akn-kicad-libs
• Related foot prints: aniline/akn_transformers.pretty, aniline/akn_misc.pretty
• And 3D models (sometimes I think this is as equally fun as the rest of the project): aniline/akn.3dshapes

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

• http://www.epanorama.net/circuits/teleinterface.html
• Interfacing Audio and POTS, Dennis Bohn, Rane Corp.
• DTMF CLIP project (CC Dharmani' blog): Design Caller ID using DTMF decoder MT8870
• Talks of other FSK messages: Caller ID Basics by Michael W. Slawson

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).

::: {.wp-caption .aligncenter style=”width: 320px;”}

Display running :::

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 8x8 single color displays.

The display would show stuff you publish as payload on the topic /leddisp1/show Also the payload has a format like ,, 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.

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:

http://noderedhost:1880/dispshow?text=Aaappi&option=1

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.

• Tuan's MQTT library: tuanpmt/esp_mqtt
• Peter Scargill's blog: tech.scargill.net
• Code for Arduino part: aniline/arduino-sketchbook/mqtt_display
• Code for ESP part: aniline/esp_mqtt_display
• Schematic and board files: ESP-AVR-Display.zip
• Node-Red test flow: aniline/led_display_flow.json