The Story Behind OpenPayphone (Part 2: Let’s Go Hardware Shopping)

...continued from Part 1

This is part two of three, wherein we join our protagonist having just decided to re-implement the inner electronics of an unpopular COCOT payphone from 1996 with modern (2025) components.

It may be popularly known “well begun is half done,” but I have found in most cases “once begun is half done” works too. So to get going I decided to 3D print some blank out panels to cover the lock holes, since I wouldn’t be needing the locks and was happy with just the T-key to keep things secure. Success begets success, and the outside looked nice again.

Getting down to business, the most recent related thing on my mind was the PJSIP Project. Earlier, while anticipating restoring the original electronics, I was looking for a way to connect to a modem call only from software over a VoIP connection for programming the phone at 300 baud. I had identified the PJSIP Project as a likely component in this abandoned endeavor. I recognized it as a component from configuring Asterisk, a reliable telephony server, so it seemed likely that it would be a robust component in my project, and give me the control I needed to reproduce the correct payphone behaviors. Perhaps an odd place to start, but middle out development is the future. Process patent, please.

I could probably build PJSIP without much trouble for a real embedded system with a real RTOS, like an actual ATA manufacturer might do, but writing and debugging that sounds awful, so I’m going to opt for maximum convenience and say the main software component is going to be Python and we’re going to run this on Linux.

There is one obvious frontrunner manufacturer of hobby-accessible, tiny, extensible, Linux-capable boards and that’s Raspberry Pi, so naturally I started there. I didn’t have to look far. I also wanted to run this thing on Power-over-Ethernet (PoE) since that eliminates the need for mains power nearby, so I spec’d out the Raspberry Pi Zero 2W, and Waveshare’s PoE hat. I don’t really need the wireless “W” of the 2W, but I didn’t see an option to purchase without it at least at the time I wanted to buy. At $15/board it was well within the budget I hadn’t set for this. The PoE “hat” cost almost 2x more than the Zero itself, at $28. Worth it though.

The PoE hat is an interesting beast, because it’s more like Raspberry Pi’s pants than its hat. It doesn’t use the 40-pin header and it connects to the +5V bus and the d+/d- of the USB by poking pogo pins onto test points and using standoffs to compress itself against the underside of the Pi. Smart idea Waveshare. Maybe Raspberry could have just given us a header for this though? They didn’t, but it worked great after one re-seating.

That takes care of core compute and power. We’re going to need audio. The Pi Zero 2W only has audio output on its HDMI, so we’re going to need an upgrade. Looking around, the IQCodec Zero (aka Raspberry Pi Codec Zero) is an audio card that fits the bill nicely for an additional $20. It interfaces the DA7212 chip to the Pi, which has plenty of configuration options for audio routing (sidetone is going to be important.) As an officially supported hat, it includes a pre-programmed eeprom that allows the Pi to autoconfigure the board so it works right out of the box as an ALSA device, and PJSIP talks ALSA.

One of the best features the Codec Zero has for this application though is its amplified speaker output which claims 1.2W into 8 Ohms. That would be destructively loud if our handset was actually 8 Ohms, but it’s probably more like 100 Ohms (I didn’t measure). At 8% of 1.2W, full volume would yield 96 mW, which is still at least 4x more power than needed for calls and plenty even for the howler if I get that far. So I’m thinking for 20 bucks I can drive the handset microphone and speaker directly from this board which seems totally worth it.

So, we’ve got power, compute, audio. Next, I’ll need to interface to those external components – the +/-12V relay, the +/-200V-ish bell (@ 20 Hz), the 3x4 keypad matrix, the hook switch, and the coin detection switches. The most intimidating requirement was getting the bell ring signal correct, but after a brief search found the Silvertel AG1171 SLIC. It’s an $8 component that gets you a subscriber line interface (intended to drive an analog phone line) from TTL level inputs, which includes a ringing function provided you have a digital source at the right frequency. Driving the external components is going to take some interfacing, and I am hopeful, but not sure, at this point, that there are enough GPIOs on the Pi that I can drive what I need directly and not resort to bit banging latches or off-board multiplexing. So I needed to do some preliminary pin assignments to figure out if all that fit.

All good and one to spare! I actually doubled up here on GPIOs 23 and 24. Technically they are in use by the Codec Zero board, but only to drive LEDs, so I assigned them the two outputs needed to drive the coin relay (which needs two outputs because there are three states: return coins, collect coins, do nothing).

So the bell is handled in theory, the keypad matrix, the hook switch, and the coin detection switches will just require a few passives. I’ll drive the matrix scan from software, by flashing the outputs on the columns to find the row after a press, and the switches – we’ll do those as pull-high inputs that connect a few KOhms to ground when active.

This leaves the matter of the relay. The PoE hat will give me a solid +5V, but I’ll need +12V, and also -12V at least from the relay’s perspective (but not at the same time). To get a +12V rail I found a tiny and convenient boost converter in an SO-92, the LT1109CZ-12, which can do 50-100 mA on the output with a tiny (few tens of uH) inductor. I probably could have characterized the relay at this point in terms of in-rush and steady-state current requirements, but I know the original board is capable of running from the POTS line (meaning, essentially no current when on hook) and, while I was recapping it, I could tell that a 3300 uF capacitor was used to drive the relay, so I’ll just copy that and see what happens.

To get the 12V power out to the relay with reversible polarity, I decided to repurpose an IC usually intended to drive a motor. It implements an H-bridge capable of ~4A and 50V, and I can drive the TTL levels it needs directly from the Pi: the TI DRV8871DDAR. Drive “forward” to return coins, drive in “reverse” to collect them, and “coast” to leave them in escrow. Very convenient.

At this point all that was left to do was build the board, oh, and write all the software, but build the board first…

To create a PCB, in the last 30 years, you will usually use an electronic design and automation tool (EDA), which brings together schematic capture, footprint design, and board layout. Having spent most of my career in software and management, whatever design skills I had acquired in electrical engineering grad school were definitely atrophied. Unable to locate my Eagle 5.0 license file from 2008, I decided it might be a good time to see how things had changed since the aughts.

I figured I’d probably need two revs of the board. One, to get things working basically, and a second to fix the mistakes I was planning on making on the first. This also gave me the opportunity to try out a couple different programs. For the first board I found JLCPCB, which had an entirely cloud-based EDA, called EasyEDA, which was free and, according to its name, easy, which sounded good. I threw the components into a schematic quickly, dropped them somewhat randomly on the board, and hit autoroute. After a little nudging I had something I thought would work, and got it shipped by FedEx from China which cost 2000% more, literally, than the boards themselves, which were only a couple bucks (2 layer, 65mm x 55mm).

After all the components arrived from DigiKey, I assembled the board, which caused me to remember how much I did not enjoy 0603 SMDs without a hotplate. I then attempted to power it with 5V from a bench supply. It immediately went overcurrent, but I quickly discovered that I’d soldered the DRV IC backward. Hoping I hadn’t destroyed anything, I flipped the IC right way round and then everything seemed stable. Having a low current limit on the bench supply had prevented any damage.

With the board stable, I proceeded to mount it atop my growing tower of “hats” which, 5-deep, now included (1) the PoE lower board with RJ-45, (2) the PoE upper board with USB and the pogo pins, (3) the Pi Zero 2W, (4) the Codec Zero audio hat, and (5) my payphone interface hat, which I called “pp-hat” in all the file names and docs, and probably should have said it out-loud before settling on that name – in retrospect “phat” would have been much better and a nod to the ‘90s.

I booted the Pi with an image of its “lite” OS since I didn’t have any human-interface peripherals and quickly tested the various components with the built-in command line tools for GPIO manipulation and ALSA audio control. I had made two minor mistakes, which seems like a lot considering the board only has a dozen components. The bell in the payphone housing did not have an inline capacitor, which I hadn’t accounted for, so I needed to add a high-voltage 0.47 uF polypropylene, which I did by cutting a trace and soldering it between the AG1171 output and the bell’s connection jack on the board. The second mistake was the coin switch header pinout was backward, meaning the common pin only connected to one of the switches, but I snipped off the tab on the header and flipped it around, at which point everything worked hardware-wise. Woo hoo!

The board worked as is, but I thought it would be nice if I ended up with a revision without mistakes, and I wanted to add a few additional components to protect the GPIOs in the case of (for example) multiple key presses connecting outputs to each other at different levels. For rev 2, I decided to try KiCAD as the EDA, because it seemed to have become fairly popular in the hobby world. It was also free, and I could keep the files on my own machine rather than have them primarily kept in the cloud in China. This time I used 1206 SMD, because I’m neither a masochist nor skilled at SMD soldering, but I still sent the Gerbers to JLCPCB for fab, because they cost $2 to make over there, and chose slow shipping since I wasn’t blocked by not having them ready to go.

I can only imagine that the EE’s who do this for a living probably have some choice words, but for everyone else, please enjoy the schematic geometry. I think there is a certain artsy beauty to schematics.

Solder, solder, push, stack, cut, print, flash. Moments (days?) later and the full stack was running. It’s shown here on the first board rev with the ring cap patched onto the board.

At this point I knew the dream of a fully functional payphone was possible, and I was close to realizing it. This was down to “a small matter of programming.”

Continued in Part 3...