ATA Design

This page is about building an analog telephone adapter (ATA) which is wholly open-source and easily hack-able/adaptable to unusual use-cases (like payphones).

MCU/Processor Selection

There needs to be a main processor, and this section runs through my thoughts as I consider the available options.

Linux-capable

Being Linux-capable would be nice! It's not a requirement because... well we don't need it!

The big downsides to Linux-capability are:

• Complexity - these parts require a lot more support circuitry
• Availability - pre-made modules like the RaspberryPi are hard to get a hold of in reasonable quantities; cheaper linux-capable processors like Allwinner's stuff is hard to get from trustworthy sources like Digikey/Mouser
• Cost - these will be more expensive to manufacture and/or require more-expensive pre-made modules
• Real-time issues - making sure you get consistently paced DAC readings and push out consistent ADC updates may require extra support from the audio chipset
• GPIO limitations - we may need a separate low-power MCU to control the real-time bits/interface with higher-power domains as linux-capable MCUs generally don't have much GPIO strength

Big upsides:

• Libraries - most of the software will be done for free, we'll basically be plugging lego blocks together for most of it
• Scriptability/hackability - people will be able to use/modify/add behaviors without recompiling firmware
• CPU power - if we need to run several encode/decode streams, pretty much everything linux-capable will be able to keep up
• Memory - pretty much every linux-capable setup will have more than enough RAM to run several SIP streams simultaneously

For a quick rundown of the complexities of building a linux-capable system: https://jaycarlson.net/embedded-linux/

Processor Capabilities

I'm making the decision up-front to ignore anything in the 8-bit or 16-bit category. While it may be possible to make it work, for a project I'm doing for fun, I don't want to spend my time hyper-optimizing just to get basic functionality working. This means I won't be looking at the Microchip PIC8/12/14/16/18, the Atmel Atmega line, or TI's MSP430. What it leaves on the table is: Arm (bunch of manufacturers), Microchip's dsPIC line, Risc-V, and the ESP32-variants using the Xtensa CPUs. There may be others, but this is all I'm considering to start, mostly because it's what I know!

Connectivity

At a bare minimum, we'd like everything to have Ethernet. This is actually quite limiting! Things which still qualify:

• TI's ARM-R5 line and TMC129x line (Cortex-M4F)
• NXP has a few offerings in the LPC line, Kinetis/MK line, and the MIMXRT line
• Microchip/Atmel has a bunch of offerings - a number of ARM9 and Cortex-A5/A7 linux-capable units, and the ATSamE53x (Cortex-M4F, 120Mhz) and ATSamE7x (Cortex-M7, 300Mhz) lines
• Espressif currently only has the original ESP32 with ethernet, though for reasons described below, I'll keep the ESP32-S3 in the running as well
• Allwinner - I don't feel super confident evaluating these options, and so I've left them off
• RaspberryPi
• Beaglebone Black/Green

It would be nice to have WiFi, but I couldn't find any options for this aside from the the ESP32. Any option could be paired with an ESP32-C3/ESP8266 to provide wifi.

All options could be paired with something like an SPI-to-ethernet adapter. The esp-idf supports a number of such devices - https://github.com/espressif/esp-idf/blob/master/components/esp_eth/include/esp_eth_phy.h

Decode/Encode

The MCU/Processor should be powerful enough to handle a few ports worth of real-time audio - this will require some benchmarking! I think this will disqualify most MCUs which don't have a FPU, but I am unsure.

How powerful the MCU is sets which codecs we can support and how many FXS ports our ATA can handle.

RAM utilization also needs to be tested - multiple concurrent encode/decode streams, along with SIP management will probably require a fair bit of memory.

Audio input/Output

The MCU/Processor will either need a really good ADC and DAC per FXS port we support, or it will need to support interfaces which can run to DAC/ADC audio devices. This should probably mean I2S support, but I need to do a deeper dive on it.

Ease of Assembly

When building these boards, it would be convenient to have an option which doesn't require complex soldering. This would effectively limit us to boards which have easy-to-utilize, cheap devboards - the beaglebone/raspberrypi (we would build this as a cape/hat), the teensy4 and the i.mxrt106x, or the ESP32 and its many variants. I'm not sure how strongly we should adhere to this idea.