Up until the mid-1980s, connecting a computer to a phone line was tricky: many phone companies didn’t allow the connection of unlicensed equipment to their network, and even if they did, you might still find yourself blocked by a lack of standardized connectors. A simple workaround for all this was an acoustic coupler, a device that played your modem’s sounds directly into a phone’s receiver without any electrical connection. Modem speeds were slow anyway, so the limited bandwidth inherent in such a system was not much of a problem.
Nowadays it’s easier to find an internet connection than a phone line in many places, but if you’re stuck in an ancient hotel in the middle of nowhere you might just find [GusGorman]’s modern take on the acoustic coupler useful. The basic design is quite simple: it’s a 3D-printed box with two cups that fit a typical phone handset and a space to put a USB speaker and microphone. Thanks to minimodem it’s easy to set up a connection with any other computer equipped with a phone connection.
The maximum speed achievable with this setup is between 100 and 300 bits per second, so using it for anything more than text-based messaging is pretty much impossible. [Gus] therefore also designed a simple BBS-like system that can be used to acces things like weather reports and cryptocurrency wallet information. Thanks to VoIP, the server doesn’t need a physical phone line and could even be running on a cloud computing service.
The BBS system is quite limited as of now, but can easily be adapted to interface with any kind of online service. We’ve seen a similar setup in a teletype that queries Wolfram Alpha, for example. Although acoustic couplers have been obsolete for decades, they still sometimes come in handy for circumventing internet censorship.
How about a game of global thermal nuclear war?
Wouldn’t you prefer a good game of chess?
How about tic-tact-toe?
tic-tactical-nuclear-weapon-toe?
We used to call them agnostic complicators ;-)
This technology is/was somewhat related to Packet-Radio. The classic Packet-Radio used AX.25 protocol on the digital side and AFSK on the analog side (DPSK was used once also experimentally used).
It allowed between 300 Baud (used on shortwave) and 1200 (or 2400) Baud on VHF. Just like with an acoustic coupler, audio tones were used – 1200 and 2200 Hz with the common 1200 Baud rate.
But instead of using an acoustic coupler, users had little intelligent modems, so called Terminal Node Controllers (TNCs). They were the equivalent to Smart Modems (Hayes modems), essentially. These little boxes contained a simple computer and the radio modem.
Later, when home computers/PCs got more powerful, TNCs had been replaced by end users by simple modems (no intelligence, just a filter; like Baycom or PC-COM) and sound card solutions. Digital repeaters (digipeaters) continued to use TNCs, though, due to them being more reliable and less power hungry. Reliable, because there’s no other software interrupting the decoding/emcoding, as it may happen on multitasking OSes.
That being said, simple TNCs can still be befound in the forms of Arduino-based TNCs. Those KISS-TNCs (Keep it simple and stupid) do mainly conversion between ASCII and AX.25/AFSK. The rest is up to the device itself (say, UI-View or Xastir running on PC).
I used to use packet radio in the early 90s and enjoyed it immensely. Had I known about it sooner, I would have used it on my C64 more for sending files to my friend across town instead of tying up the phone line all the time. I so want to have an echolink for texting so I could turn on a little device, send texts to my home station which in turn would send it around the globe to another ham with a little hand-held packet device or even send texts to my wife’s phone via the text to email service.
I was doing FT8 and PSK31 on 10m ham radio a few weeks ago by holding my PC headphones up to my handheld mic for my radio. It’s amazing how often we come back to the same old, “obsolete” way of doing things when we just want to get something done.
Those soft modems were kind of a joke. You got much better data rates with the hardware modems, which is why I only bought Zoom modems – they kept all the modem functions onboard rather than offloading them to that ultra-powerful 486. ;)
I srsly recommend the CCC’s Datenklo (Datatoilet) -> https://duckduckgo.com/?q=ccc+datenklo&t=ffsb&iar=images&iax=images&ia=images
Less wasted 3D prints, fits many more phone handsets, more off the shelf parts…
Part of it is the esthetics of this style of coupler. It worked “well” with the Ma Bell phones of the time since they were the only design available. The Swedish Televerket also had a monopoly on equipment connected to its wires so at the time you knew how the handset looked.
I carried an acoustical coupler well into the 2000s while on vacations in the event I was needed for work and no phone outlets were available. I would visit my grandparents in rural Indiana and they didn’t have a good setup. Also it was still exceedingly rare to find Wi-Fi in most rural places like that. Never needed the coupler even once, but tested it a few times; If I recall I did get decent speeds with it. I could SSH to my server and get work done. It was a more modern design; I seem to recall it had a 9V battery and Velcro to keep the handset attached.
And you can even dismantle it to fix your plumbing if needed on a holiday!
I heard someone brought an original one to 36c3. It was named such because the original design used rubber seals originally designed for toilets as the cups for the telephone handset.
most speakers can work as a microphone (a very bad one).
so it should be possible to use a set of headphones.. (as a covert coupler).
you just need a stereo splitter, and use left & right, as microphone & speaker.
and maybe an extra microphone preamp..
Might get better results using an audio transformer to transform the 32ohm impedance of the headphone speaker to something >1kOhm. Also, if you’re connecting to a “typical” microphone input — use a DC blocking capacitor since your headphone speaker is essentially being used as a dynamic microphone.
“most speakers can work as a microphone (a very bad one).”
I’ve done that actually.
The speaker inside of a classic handset has a better audio quality than the corresponding carbon mic.
With a simple one-transistor amplifier, such a loudspeaker can sound quite nice.
Not studio quality by any means, but better than a carbon microphone or a miniature electret capsule. 🙂
Didn’t they make acoustic couplers that were just “cups”? One for the earpiece and one for the mouthpiece? Seems that would be a simpler design to carry around. Oh well, v2 I guess.
In the video he more or less says that this is a nostalgia/scratching a itch project, and the classic coupler looks like this, colour not withstanding.
But you are right that it would be easier to carry around but the computers of the era was stationary and portable computers only really hit the market after acoustic couplers had disappeared from the general market, and if you had a portable computer of the era (Osborne 1 for example) it was so big (it would have had a CRT screen for starters) that the size of the coupler was not a big deal.
The modem pcb was also the size of the box of the coupler in the article, so it would not have been smaller in total anyway.
tl. dr.
They wanted a classic looking acoustic coupler and had pink filament.
Well they certainly hit the classic look on the mark and for the pink colour it makes me think that if they had portable computers in the ’50s that this is the acoustic coupler they would have marketed to women! “New for 1955 the Mrs. Modem in pink!”
Yes. And the Radio Shack Model 100 had an internal modem. Out of the box, you’d plug it into a phone line. But you cold also buy cups to use with a phone, like in a public space.
At 300baud, you won’t be streaming Netflix with this, but might be good for the odd (plain-text!) email or three.
Linux CLI can be used this way, but beware of commands that generate lots of output: Linux systems have pretty big buffers.
Years ago, my workplace had to replace a weighbridge system that was built on SCO OpenServer using UUCP over dial-up lines across a network spanning Central Queensland. Being rural, some of the phone lines were pretty crappy, so the core server used to answer the phone at 1200 baud. The system was configured to “dial back” the remote stations — but for admin tasks, you were stuck at 1200 baud. (We did not have SSH access into the system.)
The replacement used Ubuntu 12.04 (latest LTS release at the time) and taylor-uucp, to remain compatible with the existing SCO-based remote stations, which themselves were slowly replaced with Ubuntu machines.
Run a command like `cat` with a big file… and with the size of buffers in a typical Linux machine… you hit ^C, then sit there and wait, and wait … and wait… while pages and pages of text go scrolling through your terminal… before the buffer is finally “flushed” and it appears to act on your ^C.
I believe the system has since retired its old SCO fleet, a system put in place back in the mid-90s and running continuously since then. Apparently many Microsoft-based systems tried to replace it, but none succeeded. Today, I understand the machines have been updated to a newer Ubuntu release, and UUCP-over-dialup has been replaced with conventional SCP/SFTP over permanent LTE-based IP links.
Probably the only time this century I had a use for my old 14.4kbps modem (closest I could find “similar” to the ones being used on site).
1200 baud is a good reading pace. Why would you ever need faster?
Memories of my c64 and hacking a modem to connect with my phone. No idea why I had to do it, but that was one of my first hacks.
Can you imagine getting to go back and do it all again with the skills you have now?
Oops. Didn’t mean to tag your comment.
Good reading pace? As fast as needs to be? Love it.
Hacking the baud rate in my C64 and my friend’s CoCo we could push 450 baud, and between two C64s we could reach over 500 baud.
“1200 baud is a good reading pace. Why would you ever need faster? ”
That brings back memories of Bildschirmtext (BTX), the German equivalent to the French Minitel/Teletel service.
The standard baud rate was 1200 Baud down and 75 Baud up.
This was also the limit of higher end acoustic couplers back then, I believe.
The DBT-03, the proprietary modem of the German postal office, also used 1200/75 Baud, if my memory serves me well. It was a simplistic modem with a tone detection IC and a primitive microcontroller.
If one of the pins in the computer cable (serial V24) were activated by the computer software, the DBT-03 would begin dialing (pulse dial, afaik) the phone number for the BTX computer and transmit the user ID (Teilnehmerkennung). There was no Hayes command set yet. Both the number and ID were hard-coded into a ROM chip.
I am too young for this, but when i read BTX i immediately think of this hack that made the CCC famous. Must have been a great time.
I actually still have one of the portable acoustic couplers they aimed at business people back in the day, it goes on trips with me for “just in case” and has actually been useful for sending faxes on multiple occasions.
Is there a version or alternative for windows of that minimodem program? I’ve actually been looking for something like that for a while.
Where would you even dial into these days?
Even in far out of the way places you are likely to find digital voice in the stream, and that needs to specifically support modems I’m told since the compression and filtering might prevent it otherwise.
But at least in the earlier days of VOIP most actually did make it compatible.
Maybe also because Fax was still used?
Back in late 80’s one model of NCR cash register (2140) had programming stored in EAROM. Each rom had a specific part of the overall program to run the register and each rom was identified by it’s socket number (16 roms on the main board and 24 on the extended memory board). These roms “wore” out quite often and to load up a replacement we had a rom loader device a bit smaller than a loaf of bread that had acoustic couplers and a zif socket. On site at a store I would call an automated phone system, select the ROM number to download and then stuff the phone in the coupler and watch flashing lights hoping after 10 minutes that the green good receive light would come on. I would then put a replacement ROM in the the zif socket and “burn” the replacement. The problems in those days were line noise and someone picking up a phone extension during reception of the ROM image meaning starting the phone call all over. The line noise interruption was no big deal as I had a TRS80 with a cassette deck at the time.
Hi Garth.
I remember burning a bunch of ROMs for the 2140 and the 2125, during my career at NCR using that portable ROM burner.
The TRS80 Model 1 I had didn’t have the acoustic coupler, although you could buy one for it. I had the Radio Shack 300 baud direct connect modem instead and used it to connect to BBS’s.
At 300 baud you could watch the characters being drawn on the screen.
In later years I even ran a WildcatBBS for a while.
Good times!
Nice to see another NCR Field Engineer (I was in the Peoria, Il. District) here who remembers the “fun” times with the 2140 especially with the ANSWER printer. 😁 It was very advanced in it’s time with EAROM and NVRAM, cassette data capture and even a modem. For 10 years I ran a TBBS based BBS (The Bread Board System – Phil Becker – creator. Side note: Phil Becker also worked on the communication software for the Viking Mars lander) .
I meet you at the NCR School in the 80’s. I was working in Dubuque during that time. I remember getting together with you at the school, since we were the only two people with TRS80 computers there.
The Iowa Liquor stores (state owned) decided to install the 2140 registers in all of their stores. I think it had every PCB that the 2140 could use installed. This was after the 2140 was already discontinued and NCR had to scrounge the warehouse to find enough parts to build the registers.
After I transferred to the Denver Region, I ran the NCR BBS using the WildcatBBS software. It was primarily set up to provide a parts DB program that one of the Denver CE’s wrote. But after hours I would run as a regular BBS.
This 2140 talk sends me right back as well,
Setting them up with MT2 cassettes, data pack host, primary , secondary groups, constantly re- burning roms via acoustic coupler as you mentioned earlier .
2140-7200, 2125, 2152…
I need a drink . Lol
What a flash back.
One of our first computers when I was 10, in 1982 was a TRS-80, we had one of those modems with the phone coupler. Mostly used by my mom to send/receive basic text data via a school BBS. I remember the bleeps n sounds still.
On several occasions I carried a Texas Instruments Silent 700 terminal which printed on thermal sensitive 8.5 inch wide roll paper. There were rubber cups which were designed to accept the Type G handset of a Western Electric Model 2500 phone. The terminal was used to look up information for clients from a federal database of available science grants at 300 bps (or Baud, as they’re the same for AFSK modulation).
We had a handful of the Silent 700s and several had their switch mode power supplies fail fairly quickly. We also had one unit, a desktop version, forget the model number, which had a dual cassette tape drive. I never used that one, so I don’t know exactly how the tapes were used.
I wonder if you could encode data through the use of phonemes at speed, that would allow any voice communication to do it, and would sound amusing, and might be faster than 300 baud.
And you can ask chatGPT to set it up for you so you don’t even have to figure out optimum phonemes.
I don’t think it would be faster, but it would be hilarious. Well, actually, with phonemes, you might have a point (?) I’m not sure. Perhaps using aggressive compression. The math is beyond me. Voice communication is extremely inefficient. International links used in the telephone network (starting in the 1960s and some operating until at least the late 90s) used to multiplex multiple calls in the same frequency band by taking advantage of the silence on the line during conversations.
Send the to ruzzia! That’s all the tech they’ll be able to use pretty soon.
What I want to know is where the guy is finding a dial up service with which to use this!? Unless he is running his own ISP as well?
@Derek Tombrello
I have a ‘landline’ in the form of VOIP as part of my internet subscription.
And so do hundreds/thousands of millions of other people all over the world.
Now sure it might not be used that much by many, but it’s there.
It’s handy for those ‘help’ lines that put you on hold for an hour for example.
lol… I, too, have a landline. Only mine is a real landline. Copper wire and all that. Comes in handy when you don’t have a cell phone :) I didn’t mean how as in phone line. I mean how as in, unless [Gus] has a dedicated BBS into which he can dial, there aren’t any ISPs that allow dial up that I know of. I’ve tried.
@Derek Tombrello
You are absolutely right, we had an ISP that went on with dial-up for a log time but then finally a year or so ago called it quits too, and I’m not sure there is any left over here.
But this project seems to be more generic, I quote:
“It acts a general-purpose software FSK modem, and includes support for various standard FSK protocols such as Bell103, Bell202, RTTY, TTY/TDD, NOAA SAME, and Caller-ID. ”
So it’s a general tool for tinkering it seems.
Here’s an application he lists: “[application] Sega Saturn Save Game Extractor – Transmit Sega Saturn save game files as audio. Based on minimodem.”
Is a full-screen terminal application even usable at 300 baud? The first modem I had was 2400 baud, and using BBSs was painful. I have used a 300 baud modem, and, well, the data rate is truly glacial. Words cannot do it justice; you have to experience it. I cannot imagine attempting to use TCP/IP at 300 baud. Yeah, sure, it’s blazing in comparison to baudot, but still …
My dear friends,
I need alike solution for GSM smartphone to let me relay phone call made from 1st smartphone to 2nd smartphone, to the 3rd smartphone.
So how to couple 2 smartphones to transfer DTMF codes to execute Hayes AT commands remotely on the 3rd smartphone.
thank you