Raspberry Pi Dumb Terminal




Introduction: Raspberry Pi Dumb Terminal

About: Every week two geeky people in Rochester MN spend every ounce of their freetime creating educational videos, podcasts, articles, and music. They publish it all on the internet, free to anyone in the whole univ…

Back in my day the internet was a dumb terminal connected at 300 baud through an acoustic coupler to a timeshare system, and we liked it!

Ok I'm not actually that old, but how amazing it must have been to be using telephones to connect up to the ARPANET before it was legal to even connect a modem directly to your phone line (yeah for real, direct modems were illegal)!

This time period was so magical! The computer industry and telecommunications industry were colliding like two galaxies, and no one had any idea how it would all pan out. I may not be old enough to have lived through it, but the tech that fueled this paradigm shift to a new age is still around, collecting dust in surplus stores and buried in boxes in our grandfather's basements.

I recently acquired an early 300 baud acoustic coupler (how modems worked before you were allowed to connect modems directly to a phone jack). Let's dust it off and build our own dumb terminal using an old phone, the coupler, a Raspberry Pi, some wires, a few capacitors, a serial transceiver chip, and some solder!

Get off my lawn with your newfangled 4G. Where did I leave my teeth? Here we go!

Step 1: The Circuit

Modern devices like a Raspberry Pi generally use a 3.3v TTL UART for hardware serial communications. Vintage equipment (like the beautiful 300 baud acoustic coupler we are going to interface to) use +/-15v RS-232 for their hardware serial communications.

To get around this, we are going to use a special integrated circuit called a transceiver. This device only has one job, to translate back and forth between TTL and RS-232. The part I chose for the circuit is SP2322E a 'true +3.0v to +5.5v RS-232 Transceiver'. This part gets its power from the Raspberry Pi. The Raspberry Pi, however, does not have the ability to source +/-15v. Where do these voltages come from? The transceiver chip uses a set of external capacitors as part of its charge pump circuits. In other words, with a little help from its capacitive friends, the transceiver is capable of generating its own +/-15 rails. Fancy!

While this part is capable of two serial channels, we only require one for this job. Connected to the Raspberry Pi's GPIO UART are transceiver pins T1IN and R1OUT. Connected to the RS-232 cable are transceiver pins T1OUT, R1IN, and GPIO GND (need that ground reference, buddy).

So there we have it, a simple circuit that will allow our new-fangled Raspberry Pi to talk to 40 year old telecommunications equipment.

Let's build it!

Step 2: Soldering

Instructables sent us a Perma-Proto Pi Hat board along with a Raspberry Pi 2 as part of the Raspberry Pi 2 Build Night earlier this year. I'm going to use this to make building my circuit onto the Raspberry Pi quick and easy.

I started by soldering a 16 pin dip socket onto the hat. Then I angled the pins on the IC properly and inserted it into the socket.

I soldered a blue jumper wire between the transceiver T1IN pin and Raspberry Pi GPIO TXD pin. Then a yellow jumper between the transceiver R1OUT pin and the Raspberry Pi GPIO RXD pin.

I scrounged around my junk boxes for a standard DB9 serial port. I soldered a green wire to pin 5, a blue wire to pin 3 and a yellow wire to pin 2. I soldered the green wire to the GND rail on the hat. I soldered the blue wire to the transceiver T1OUT pin. I soldered the yellow wire to the transceiver R1IN pin.

I soldered all of the capacitors in place.

I soldered a black jumper wire between the transceiver GND pin and the GND rail on the hat.

I soldered a red jumper wire between the transceiver VCC pin and the +3.3v rail on the hat.

I soldered the included female 2x20 header onto the hat, facing down.

Our transceiver hat is now complete, let's hook it up!

Step 3: Connections

The antique Novation 300 baud acoustic coupler modem relies on a DB25 RS-232 cable for serial communications. So I connect a DB9 to DB25 adapter cable between the transceiver hat and the coupler.

I place a type G telephone handset into the acoustic coupler's cups.

The rest is monitor, keyboard, power, etc.

Let's get it working!

Step 4: Configuration

Out of the box, a Raspbian installation assigns a process to handle everything that happens on the Raspberry Pi's GPIO UART serial port (ttyAMA0). This process is getty, and it allows you to log into your Raspberry Pi directly over the serial port at 115200 baud. Pretty cool, but absolutely in our way at the moment. We need that serial port to be open and unoccupied!

The first step to taking back the serial port is to stop the system from setting it up as a console in /boot/cmdline.txt

Let's start by backing up the file

sudo cp /boot/cmdline.txt /boot/cmdline_backup.txt

Alright, now to edit the file (I'm going to use vim for this)

sudo vim /boot/cmdline.txt

Remove these two settings (you may only find the first setting if you are on a NOOBS install):

  • console=ttyAMA0,115200
  • kgdboc=ttyAMA0,115200

Save the file.

Now we need to stop the system from using getty to handle data on the serial port. This handler is assigned to the serial port in another file: /etc/inittab. Let's edit the file.

sudo vim /etc/inittab

Comment out the serial port handler line by changing

2:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100


#2:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

Save the file.

At this point the serial port will no longer be used by the system at bootup. Now we need a program that allows us to type into and read back from with the serial port directly. I'm going to use Picocom. Picocom is a very stripped down command line terminal emulator.

sudo apt-get install picocom

Once it is installed you can run it like this:

picocom -b 300 /dev/ttyAMA0

The -b sets the baud rate. This is the fastest rate my antique modem functions, so I'm going with that! And /dev/ttyAMA0 is our GPIO UART serial port, of course. With Picocom running, everything you type gets sent down the serial port, and everything sent up from the serial port gets printed directly on your screen. Old School!

You can now interface your ancient telecommunications equipment directly to a modern Raspberry Pi. This opens up all sorts of great project ideas. Let us know yours in the comments section.


You could stop there, but I want a REALLY dumb terminal. So I'm going to go a step further and make my Raspberry Pi boot directly into Picocom with no login. Time for hack-foo!

Create a bash script. This script clears the screen, prints a welcome message, then runs Picocom.

sudo vim /usr/bin/vterm



echo "Toymaker Television Terminal"

/usr/bin/picocom -b 300 /dev/ttyAMA0

Save the file.

Set the file to be executable

sudo chmod +x /usr/bin/vterm

Now for the deep magic. We're going to assign the handling of tty1 (the console you get attached to when the Raspberry Pi boots up, and that you usually log into) to our own script. In a normal world tty1 is handled by a getty process, but we're feeling adventurous so

sudo vim /etc/inittab


1:2345:respawn:/sbin/getty --noclear 38400 tty1



Save the file.

So now, when the Raspberry Pi boots up, instead of asking you to login it is instead going to hand you over to our vterm script. Which clears the screen, prints a welcome message, and starts Picocom connected to the GPIO UART serial port (and our acoustic coupler). Note that 'respawn'. What that means is that if you exit Picocom (and the script ends) the system will respawn a new vterm script and hook you to it. Cool!

So you might think, well ok, but how the heck do I log back into my Raspberry Pi now? We've disabled the serial port login, and we've hijacked the tty1 login!

Don't worry, by default Raspbian starts a whole bunch of ttys (you may have noticed them while you were editing /etc/inittab). You can switch another tty by holding ALT on your keyboard along with one of the F keys (F1 = tty1, F2 = tty2, etc). If you switch to tty2, you'll get your usual Login: prompt, allowing you to get into your Raspberry Pi.

I hope you found this Instructable fun and informative. Thanks for taking the time out of your day!

Raspberry Pi Contest

Participated in the
Raspberry Pi Contest

Phone Contest

Participated in the
Phone Contest

Be the First to Share


    • Big and Small Contest

      Big and Small Contest
    • Game Design: Student Design Challenge

      Game Design: Student Design Challenge
    • For the Home Contest

      For the Home Contest



    Question 4 years ago on Step 4

    Hi, how have you solved the item to connect the old clicking keyboard to the rsapberry usb? Did you use a ps2 to usb keyboard converter?

    And what about the monocrome monitor? In what way did you connect it to the raspberry?

    The olda monitor is a composite video type monitor? Or did hou have to use an adapter for the hdmi?

    Many thanks!



    7 years ago

    Hardware handshaking (RTS/CTR/DSR/DTR) was needed in the bad slow days. Then computers got faster, and we could mostly dispense with it. Then came windows 95, and with it the return to the need for hardware handshake. We can call these the bad fast days. Post Windows 95, it was no longer possible for an application program to determine when serial data might be sent or received. Windows buffers serial out data, and sends it when it feels like it. Windows also ignores serial interrupts if it is busy telling the user about unused icons on the desktop, or telling the user they didn't successfully enter the WiFi key the same way twice, or if it is a day ending in y. Seriously, without hardware handshaking you will never get reliable data transfer under windows....and that is pretty much the story on why serial ports on PCs have gone the way of the dodo. Well that and real RS-232 ports needed voltages that were inconvenient, even though port chips with onboard charge pumps to generate 9V levels from 5V supply are common.

    There were just enough options on how to do hardware handshaking that it often took a guru with a breakout box to get it to function...that was me, by the way. Serial got a reputation for being hard to deal with...then USB got cheap and simple, and faster.... sinara '232.

    RS-485 endures in the industrial control world. It is fast enough for plenty of things and you can get distance that USB can't touch. Ethernet is taking over though.


    7 years ago on Introduction

    Why is it you never ever see an RPi or arduino project using serial data that uses RTS/CTR or DTR/DSR any more? They were absolutely essential in the modem days or you would get data overruns and lost characters...


    Reply 7 years ago on Introduction

    In our case, they really did not matter at all. Like AlyssonR2 mentioned, the Raspberry Pi and the modem on the other side are so fast compared to the speed of the acoustic coupler that we simply did not have to interface to 'Clear to Send' or 'Data Set Read'y pins on the coupler.

    Our first attempt at interfacing this modem involved using a five wire usb to rs232 cable but the manufacturer didn't design the charge pump properly. Their voltages were not swinging nearly far enough and it was causing the modem to essentially brownout with every bit that came in.

    Also interesting to note, there is no controlling inside of this modem. It's all op-amps and a 555 timer. Pretty awesome old tech.


    Reply 7 years ago on Introduction

    A very nice 'ible on the melding of vintage and modern hardware. Most modern users forget the origins of their serial communications ports as being based in the +/- 15V RS232C standard.

    @ gtoal:

    Modern systems run so fast that the FIFO buffers tend to not overrun any more - and where software allows, then the buffer size is simply expanded as required.

    The last time I used equipment that actually usilised the RTS/STS DSR/DTR signals was a 1200/1200 baud modem back in the late 1970's - ever since then it has been XON/XOFF TRON/TROFF (software) flow control.

    At 300 baud, the system at both ends spend a lot of its time simply waiting for data. Modern telephone systems don't suffer the amount of noise that the older network hardware exhibited, so a 300 baud signal is likely to pass without error first time, every time. Bad packets will be handled by software, these days, rather than the communication hardware.

    This all makes RTS/CTR, DTR/DSR protocols redundant, and usually obviates the need for XON/XOFF as well.


    Reply 7 years ago on Introduction

    That would be true for machine to machine communication with a proper PC running the comms, but I've personally seen at least two examples of data overrun using serial: the first in my vinyl cutter, which doesn't have the capacity to buffer an entire print job in its tiny embedded controller, and the second in an arduino device that drives an etch-a-sketch over a USB/serial FTDI link. These are basically the same problem as old HPGL pen plotters and require the same solution - flow control, whether hardware or software. Hardware is much more reliable but these FTDI dongles used now to interface USB to RS423 etc never implement a 5 wire interface. I'm not disputing your observations, I'm just criticising the hardware manufacturers for dropping a piece of technology that was well understood and worked fine for decades, just for the cost-engineering of two tracks on a PCB :-(


    Reply 7 years ago on Introduction

    @ gtoal:

    The overrun you have experienced is quite definitely an ouch!

    devices with slow data consumption and small buffers should always have
    an XON/XOFF protocol written into their interfaces.

    I have a couple of older FTDI USB to RS232(TTL) cables that have the 5-wire interface which is absent on the newer cables.

    LC Studio RS232 breakouts utilising the MAX3232 ICs have the second
    send/recieve pair brought out to a 0.1" header, ready for use as either a
    second 3-wire port or for wiring onto the 9-pin D connector for
    conversion to a 5-wire interface.

    Sadly, the smart RS232C devices
    with built-in FIFO and built-in HW/SW flow-control don't seem to have
    made it down as far as the microcontroller hobbyist market - probably
    because of the ubiquity of the dreaded USB interface.

    I cannot
    help but feel that the vanilla serial port with flow control
    capabilities still has an enormous amount to offer, and I regret its
    disappearance from our systems.