Somewhere between the day I got my prized possessions of the Teletype Models 15 and 19 and the day my oldest boy became interested in Christmastime, I came up with the scheme to run a Santa Tracking broadcast via teleprinter. From that hatched the less ambitious yet no less creative idea to run a Halloween night story broadcast.
That being said, what story is more fitting for teleprinter news adaptation than the radio adaptation of The War of the Worlds by Orson Welles?
Perfect Source Material
Why Orson Welles’ radio adaptation (which always is attributed to Welles as director and narrator but was written by Howard Koch)? Simple: he already adapted the original story into a condensed version mostly presented as a series of news bulletins– the exact medium teletypes were commonly used for at the time of the original radio broadcast, just in textual form instead of aural. I was able to more or less drop the text transcription of the original broadcast right into the teletype broadcast for many of the bulletins. It also helps that the 1938 broadcast is well known for inciting fear the night before Halloween some eighty two years ago. It was a no-brainer.
(While it’s true that the entire nation did not, in fact, descend into turmoil thinking Welles’ broadcast was true, modern day keyboard warriors will snidely state from the safety of the comments section that there was no panic whatsoever when in reality the evidence lies somewhere in the middle: some hundreds– probably some thousands– did panic, just not millions, and not to the point that the newspapers at the time would have had you believe).
I invented the fictional Teletype Broadcasting Network (TTBN) as the main source of bulletins for this broadcast, replacing Welles’ CBS. They and their dedicated network of in-office and in-field reporters would help this tale unfold for the first time in the medium of teleprinter communications… right to the grisly end.
The broadcast starts out with a seemingly benign weather report and continues with a bulletin every 3 – 10 minutes for the next three hours growing from relatively normal news bulletins to climax at ten bells rung before an emergency report of the Martians deploying a deadly black gas flooding the streets of Newark. Then one final report from a TTBN teletype operator in New York is issued as the Martians advance through the city and the operator types out his last words as he draws his final breath. It’s probably about as dramatic as a story framed within the world of teletype news bulletins can get; I include this broadcast here as it is perhaps the best part:
TTBN BUILDING, NEW YORK CITY ENEMY NOW IN SIGHT ABOVE THE PALISADES. FIVE GREAT MACHINES. FIRST ONE IS CROSSING RIVER. I CAN SEE IT FROM HERE, WADING THE HUDSON LIKE A MAN WADING THROUGH A BROOK. I WILL STAY HERE AND BROADCAST TO THE END. NOWHERE TO RUN. NOW THE FIRST MACHINE REACHES THE SHORE. HE STANDS WATCHING, LOOKING OVER THE CITY. HIS STEEL, COWLISH HEAD IS EVEN WITH THE SKYSCRAPERS. HE WAITS FOR THE OTHERS. THEY RISE LIKE A LINE OF NEW TOWERS ON THE CITY'S WEST SIDE. NOW THEY'RE LIFTING THEIR METAL HANDS. THIS IS THE END NOW. BLACK SMOKE, DRIFTING OVER THE CITY. PEOPLE IN THE STREETS SEE IT NOW. THEY'RE RUNNING TOWARDS THE EAST RIVER. THOUSANDS OF THEM, DROPPING IN LIKE RATS. SMOKE'S SPREADING FASTER-- REACHED TIMES SQUARE. PEOPLE TRYING TO RUN AWAY FROM IT, BUT IT'S NO USE. FALLING LIKE FLIES. SMOKE'S CROSSING 6TH AVE. 5TH AVE. 900 YARDS AWAY. FIFTY FEET. IT SEEPS INTO THE BUIDLING, COVER FACE, NO GIOOD. OTHRS WHOVE STASYED WITH EMN ASRE COLLAPSNGF. SMOKEE CANT BREEATH PEOPLR DUYING DMOKE DCOJR IS UI I DIE
The story, void of broadcasts for nearly ten minutes, thereafter follows a survivor scientist introduced early on in the broadcast who is able to access a few teletype transmitting stations and share his observations of the post-apocalyptic world around him on his way to find if anything is left of civilization anywhere.
An audio recording of the RTTY signals and a copy of the original text can be downloaded here (the text even includes the BEL characters, so if you pipe them through a Volpe board in ASCII translate mode, you’ll get the original bell alerts as with the RTTY audio). The images included below are simply for dramatic effect, and more details can be found under them. They are the only pieces of War of the Worlds related art that I’ve found that seem to capture the true horror (in spite of and perhaps even because of the cartoonish tripods), created by Henrique Alvim Correa for a 1906 limited edition French printing of the novel.
It’s safe to say that the options for teletype broadcasting software are limited (namely just the Teletype Broadcast Scheduler as far as I know). So I cobbled together my own.
Radio was the most common amateur’s method of teletype communication for decades. The signal mode is called RTTY, or radioteletype (in the military more often called RATT– also radioteletype). Transmission happened through a method we like to call modulation and demodulation (which is where the term MODEM comes from): the on/off binary electrical signal transmitted from a teletype can be modulated into audio signals by a modem (in this context the RTTY audio signals using AFSK– audio frequency shifted keying, which is just two audio tones separated or shifted by a certain frequency/pitch gap, one tone representing mark, or digital on or 1, and one tone representing space, or digital off or 0), sent across the airwaves as a radio signal, converted back to audio, and then demodulated back from AFSK via another modem to a binary electrical signal again, which keys the teletype on the other end as if the sending teletype were on the same circuit as the receiving one.
Traditionally you’d use what’s called a terminal unit, or TU, which acts as a modem to transmit/receive RTTY signals and converts it to electrical signals on your teletype current loop (serial communications circuit). In fact, from what I understand, the venerable Paul Heller runs the one true ITTY (Internet Teletype) station out of Colorado using a Raspberry Pi pumping RTTY audio steams online generated by several TUs in a tidy server rack.
I don’t have a TU, however, as much as I’d like to obtain one. So I relied entirely on software instead.
I did think it would be nice and tidy to rely on the somewhat ubiquitous minimodem program, shipped with many *nix distributions including MacOS. It’s a command line program that can be used to act as an RTTY AFSK modem, among other things. However, I ran into some issues with it and abandoned it in favor of the arguably more extensive if much heavier program called fldigi.
The neat thing about fldigi is it can be remotely controlled via the XML-RPC protocol– just a fancy term for being able to send remote commands via a network to an fldigi program instance listening on another computer.
There is a handy perl script to make the transmission of the XML-RPC commands easy, and it’s easily automatable.
I built a script around all this whose logic goes as follows:
- Load first message of designated broadcast into memory, checking how long to wait until message should be broadcast
- Wait designated number of seconds
- Using XML-RPC, set remote fldigi to transmit mode
- Send message to be transmitted by fldigi over XML-RPC
- Calculate amount of time message should take to transmit and wait that time period
- Set remote fldigi back to receive mode (non-transmit)
- Load next message of broadcast into memory, checking how long to wait until message should be broadcast
- Repeat steps 2 – 7 until last message has been transmitted.
The series of messages is meant to be divided up, one per file, in a series of plaintext files. Each one requires a TIMEDELAY parameter set, preferably at the top of the file, though technically it could be anywhere in the file. TIMEDELAY defines how much time to wait before transmitting the message.
Not the most user friendly setup, I grant you, though I have already improved on this vastly, which improvements will be outlined when I can write up more about the Santa Tracking broadcast. The important thing is that it worked pretty well.
This programmatic approach worked very well, integrating nicely with my custom setup. I did wish I could have programmatically imitated the natural hesitations and such inherent in a live transmission of someone typing on the keyboard– mainly to make the death of the TTBN operator (quoted above) more realistic as he types out his last words and slumps over the keyboard, gasping for breath as the Martian’s poisonous black gas asphyxiates him and the rest of New York City. The framework I set up did not lend itself to this, however, so I had to stow it for another time when I have more time to make such an improvement. I briefly considered prerecording the entire broadcast and injecting this one transmission as a manually recorded piece stitched into the overall programme, but programmatic transmission won the day.
One of the suboptimal features of this v1 of the broadcast software was that it did not rely on scheduled timings but rather had to be manually kicked off when the time was right (this has also since been rectified), each transmission thereafter being strung one after another by the TIMEDELAY variable of each. This required me to stay behind briefly while my family went to partake in the day’s festivities, but I kicked off the broadcast at the scheduled time and soon joined them.
This time I actually set up my 4K camera and live streamed my Model 19 receiving the broadcast on YouTube. Unfortunately about an hour and a half into the broadcast, the camera battery died in spite of being plugged in to a power source. I later discovered that even though the camera (a Sony RX10 III) was advertised as being able to stay on continuously if plugged into a power source, none of the power sources I’ve tried during and since that time seem to keep up with the power drain. It could be that 4K drains too much power and that I need to experiment in 1080p as I am streaming in 1080p regardless. There were only seven total viewers for the video broadcast, so it’s not like it was a huge loss anyway.
The audio, after being generated by fldigi on my trusty Mac Mini downstairs (incidentally originally purchased to run Plex) was streamed from a program called butt to an Icecast server I have running. Listeners were able to download the stream live and pipe to their teletypes or glass terminals and enjoy the show.
Giant Flaming Object
I had a maximum of nearly 40 concurrent listeners, though that metric does not count total listeners– some may have started the broadcast late or dropped early. The Icecast software only reflects the peak of concurrent listeners. Still, it was higher than I anticipated.
Reception was positive. There were various positive messages sent my way during and after the broadcast, all of which I very much appreciate:
Giant Flaming Object
Your broadcast is great fun. Thanks, Jordan!
So I am downstairs following the Martian invasion via Teletype. Suddenly, I hear the Emergency Broadcast System Alert from upstairs where the TV is on – blaaat blaaat blaaat.
OMG, are the Martians here????
Whew, just a severe thunderstorm alert.
Thank you, Jordan… Very much appreciated and enjoyed. Looking forward to Santa.
Nice work Jordan, this was a great project for Halloween night. Looking forward to more in the same vein going forward. Thanks!!
Hi again, Jordan…
I like this.
Thank you for your effort!!
A Halloween Tradition
As it was a success, the way was paved for the Santa Tracking broadcast, which will be published here later. The trail was blazed also for future Halloween broadcasts, which I fully intend to do each and every year from hereon out. I’m not sure if I’ll be able to top The War of the Worlds, but I don’t think I want to broadcast the exact same story each year, either, so we shall see what happens.