A somewhat similar system used in modern radio systems (well, radio systems that are now outdated, but still in widespread use) is two-tone sequential paging or the related QuikCall. These are in-band audio tones used to cause some receivers to open squelch as a form of selective calling.
The method is predominantly used in public safety radio systems, where tone paging may be used to cause a fixed receiver in a station to open squelch (triggering an alarm) or cause a portable paging receiver (like a Motorola Minitor) to open squelch as a simple form of paging. Rural VFDs often rely on the latter to call out volunteers.
Anyway, the world of in-band signaling in voice communications is really pretty interesting, and while digital systems have reduced the need for in-band there are still a lot of real-world systems that rely on it for compatibility with legacy equipment. The telephone system has largely moved on (except for various niche uses of DTMF) but in-band signaling is still pretty common in radio systems, where upgrading to a digital system is high cost and comes with its own limitations.
Another example off-hand: most large-area public address systems, the type of thing the military often calls Giant Voice and might be used for tornado warning in some areas, use either DTMF or SelCall (five-tone) on the control radio channel (which in many cases is the same radio system used by public safety portable radios) to cause the loudspeakers to activate. A particular oddity of a lot of these systems is that they have different generations of receivers that use different methods, so sometimes you'll end up hearing the tones played aloud if a receiver opens squelch in reaction to something earlier in the sequence.
And a last example, also usually seen in public safety - some radio schemes like MDC transmit a burst that sounds like a roger beep whenever the PTT is released, but is actually a short data packet that identifies the transmitting radio. This allows a specially equipped base station to show e.g. a dispatcher who was just transmitting. Sometimes the same signaling system is used to implement other features like 'man down' detection where a radio signals if it is not upright or has not moved for a period of time (common safety feature in fire departments), but sometimes these kinds of systems also just use a sample-based speech synthesizer if there's no digital system already in use.
Oh, I can't resist one more. The "buzz," repeated three times, which proceeds emergency alert messages in the US is actually a short data packet which gives certain metadata about the alert and causes hardware in receiving radio stations (the system operates a bit like a "calling tree") to cut out the program audio and switch over the received alert. The two-tone beep which follows is a legacy system for the same purpose, although today no such receivers should still be in use. It's amusing that many phones use that two-tone signal as their ringtone for emergency alerts considering how divorced that is from its original purpose, but it's quite recognizable. Emergency alert messages should be followed by a three shorter data bursts which inform receivers that the alert is over. A closely related scheme is used by NOAA All-Hazards Radio to cause dedicated "weather emergency" receivers in people's homes to open squelch, these are more common in tornado-prone areas but generally work throughout the US. As the name suggests, All-Hazards also retransmits alerts from agencies other than NOAA including emergency alert system messages.
The NOAA system has a name: SAME, or Specific Area Message Encoding[1]. As the name implies, those three bursts actually contain a whole packet of information regarding the incoming message, including areas of effect, hazard type, duration, source of the alert, etc. There are pieces of software out there that let you decode the packets, and some let you encode your own, like minimodem[2]. Do be aware that transmitting valid SAME packets over broadcast media tends to be very poorly viewed by the FCC because it actually triggers mechanisms in the broadcast system, as GP noted.
> A particular oddity of a lot of these systems is that they have different generations of receivers that use different methods, so sometimes you'll end up hearing the tones played aloud if a receiver opens squelch in reaction to something earlier in the sequence.
Good grief, I'm getting old...
First thing I thought of after reading that:
> if NASA wanted to send control signals like transmit on and off, they’d need to run a whole parallel set of wires, which would be expensive. So, they came up with a solution: use the same lines for control signals as well!
It really seems that in earlier years, when resources were limited, people really used their ingenuity far better than today.
Maybe I have rose tinted glasses, but the level of creativity and cleverness seen in old solutions to problems/challenges just blows my mind all the time.
I agree that it seems like engineers of the past were more clever than us today, but I suspect that we feel that way only because a lot of the garbage systems and code have been lost to time. The good stuff gets immortalized and passed down, while the bad stuff isn't, much in the same way that nobody will see my hacky Python scripts in 30 years (with any luck). It's a selection bias.
See also people who are convinced they were born in the wrong time period. Much more annoying that you or me, I'd say, but the same principle nonetheless.
> much in the same way that nobody will see my hacky Python scripts in 30 years (with any luck)
LOTS of us have seen legacy systems long outlast their intended lifespan. I've seen this in enterprise settings, web development, small business, etc... I've got multiple custom web solutions (niche industry product catalogs) I developed in my early 20's that are still going strong 10-15 years later. The code behind them is dated and god awful, but if/when you talk to the client it's the "don't fix what's not broken" mentality.
Due to this experience I've learned to document the hell out of my projects because of really positive feedback from developers who have had to support/modify my work down-the-road. Docs can be a lifesaver in a less-than-ideal situation.
Just sharing my anecdotal experience of "holy cow that's STILL LIVE?!" and, "here's a DB2 mess from the late 80's ... figure it out kid." =)
"It really seems that in earlier years, when resources were limited, people really used their ingenuity far better than today."
We still use the same system today: most ham radio repeaters are triggered (and can be remotely configured by the owners) through audio tones; also most license free radios implement subtone codes (ctcss) to trigger the audio output when a radio with the same code is transmitting. The idea is that people wanting to talk each other use the same code so that they won't listen to transmissions by others. The system works as intended but is flawed by giving a false sense of privacy when users think others won't be able to listen to their conversations just because they use that code, which is false as there is no proteciton at all: the code is merely used on the receiver to voluntarily squelch off the audio when the same code isn't provided by the transmitter, but anyone with a receiver not using codes can listen to them.
Inband vs out-of-band signalling is one of those great debates in telecoms. You can see it in RS232 as well, with "XON/XOFF" characters versus "RTS/CTS" extra signalling lines.
Most internet protocols are "in-band", but there are two big exceptions in FTP and SIP, which is very much an internet protocol designed by phone people.
H.323 is the internet protocol designed by phone people, SIP is prime example of second systems effect caused by internet people trying to make it “more internet-ish”.
The reason why H.323 is “unspeakable horror” to internet people is mostly about it being built on top of existing practice of telco signaling, so: global titles instead of URIs and ASN.1 PER instead of HTTP-style (in case of SIP arguably overly verbose and complex) text messages.
Edit: and IIRC there is significant user experience difference caused by that: H.323 supports the traditional telco style Initial address/Subsequent address/Address complete dialing, while SIP works in terms of complete SIP URIs and the user terminal has to somehow divine that the dialed number is complete.
> while SIP works in terms of complete SIP URIs and the user terminal has to somehow divine that the dialed number is complete
I've never used a softphone that doesn't have an explicit Call button. You're telling me that there are terminals where people can just pound SIP URIs in one character at a time, and the call will just decide to initiate at some point?
That is how the normal POTS phone works and there is some expectation that physical SIP VoIP phone would work in same manner. For the VoIP phone the usual implementation is that the hardware SIP phones have configurable regular expression that describes all possible complete numbers and configurable dial timeout. Getting this to work reliably is somewhat intractable problem, while with H.323 or Cisco SCCP phones it just works. For SCCP because the phones are more or less dumb terminals and with H.323 because the signaling protocol is designed with this in mind.
On the other hand desktop phones are today mostly used in office environments, where essentially everybody today enters number first and then does some action that signifies that it is the complete address (pickups handset or enables speakerphone)
Edit: motivational example: suppose that random person pick ups random SIP phone and punches in 1-1-2 (or 9-1-1), then reasonable expectation is that the phone somehow divines, that what the user really means is 112@sip.exapmle.com(or 911@...) and immediately sends the INVITE, getting it to work that way for arbitrary numbers is somewhat nontrivial.
The creativity and cleverness is still there. It's just being applied differently.
That kind of insight is very "clean" when it's being applied at the level of bare wires, or to code crammed into tens of bytes. It's harder to see when it's part of a large app or extensive system, but it's still there.
Developers today are neither more nor less clever. The solutions they come up with every day are just less broadly applicable, because the broadly applicable ones are either low-hanging fruit long since picked, or unnecessary drains of developer time that are better spent solving more domain-specific problems. Forty years ago I'd admire a programmer who could cleverly eke out a few bytes per record, but today (in most circumstances) I'd fire them for making their code less flexible and harder to maintain.
The book "Exploding The Phone" goes into all of these stories and much more. If you ever wanted to know about how and why the analog phone system was so hackable/phreakable, this book is for you.
You say that, but phone phreaking was possible because of in-band signaling. People back in the day had much the same tradeoffs we did; by necessity, they just came down on the side of less security / less portability / less reusability.
NASA would not have used this technique of they had today's signal proccessing/bandwidth/resources. They used these clever tricks because that was the only option.
These clever tricks have major downsides. They are more fragile and easier to get wrong. Just like code today, the most clever code is often the least maintainable.
> It really seems that in earlier years, when resources were limited, people really used their ingenuity far better than today.
Naw. We just use our ingenuity to solve higher level problems. Or more precisely use it to solve the “actual problem” trying to be solved and not incidental problems caused by not being able to work at the right level of abstraction.
Mumble mumble Mythical Man Month and “no silver bullet”. There will always be the “real problem” to solve. It is just over time our level of tooling will let us focus more and more on solving the problem itself instead of tooling problems...
Modern EE is full of clever tricks like this, just a lot less about cost because it's marginal but for very subtle things like DFM, reliability, etc... Just look at a mass manufactured board like from Apple or Samsung. Shit is fucking whack, yo.
When I first started getting into Arduino type systems, I was concerned about the limited number of inputs. After studying other designs, I saw a simple method of making each pin capable of accepting multiple inputs. Each input had a different resistor attached so that the voltage from each input/button was unique on that pin. Very simple/basic solution, but still creatively done nonetheless.
It really seems that in earlier years, when resources were limited, people really used their ingenuity far better than today.
I think that's the wrong way to look at it. There are a few factors at play here. One is selection bias (there was a lot of crap written then too).
More importantly though, "ingenuity" is somewhat a limited resource. If your systems are highly constraining, you burn a lot of it on working around the constraints. It can be clever as hell, but also means a lot of other stuff couldn't be done.
Also, there are vastly more people working in the area now, with the corresponding regression to the mean.
In addition to what else has been said, we have more ready-made solutions we've converged on, which pushes the scope for creativity higher in the stack. For example, we don't have to hack up a low-level communications system because we can just put JTAG parts on and use something everyone understands. We don't have to figure out how to allow multiple users to share the same network without stepping on anyone else's toes because we have TCP/IP and decades' worth of cleverness poured into things like creating a transparent, securely-encrypted tunnel over that protocol suite.
So our cleverness is inside the applications, getting stuff at the top of the stack to do things it wasn't intended to do by combining relatively high-level pieces. I've done that, I'm sure a lot of us here have done that.
If there is a more effortless way to do it, it will be done this way. It's getting interesting when there is no such way because the problem is at the edge of our current capabilities.
If I wanted to search for ingenuity and creative solutions, I would start at the cutting edge or maybe even moonshot projects.
Some massproduced parts also contain a fair bit of ingenuity in their circuitry, though usually of the "they summoned Satan just so they don't need this $0.02 part" type of ingenuity.
Now that you mention it, my little nephew could not wrap his head around how we used to not have mobile phones, and even when we did, we used to only use SMS and MMS for more expensive bills, and we even had emojis !
This is the way the telephone system worked while eliminating human switchboard operators. In-band signaling is what allowed the phreaks of the 60s and 70s to do what they did.
When these tones are used in music, it instantly instills a sense of mystery and wonder. I don't know if it's something intrinsic to the sound, or if it's because of the recognizable context of exploration and discovery. One song that comes to mind is Satellite by BT, but I know I've heard it elsewhere too.
I think it's the same reason I tear up uncontrollably watching rocket launches. It's just so epic and bigger than any one human. See also: overwatch effect.
Does anyone know why they picked frequencies quite close together for the in/out tones (2525Hz/2475Hz) when the pass band for telephony was much wider?
-Probably placed at the upper end of the passband so you could use a single high-pass filter in front of the detector to get rid of any noise on the line, easing detection.
Also, if you wanted to remove the tones from the passband for some reason or other, you could do that with a single notch filter if the tones were sufficiently close.
Based on some quick Googling, it looks like the pass band they used for voice (at least for Apollo) was 300Hz to 2.3kHz. Assuming that filtering was being applied in the audio gear and the RF side of things was a bit more permissive, that would allow them to keep the control tones outside the range of any vox transmission.
The exact tones were generated from Quindar manufactured equipment and would be specific to that equipment. So CB radio beeps wouldn't be Quindar tones.
Also the purpose is different. Quindar tones are intended to control intermediate equipment, while roger beep is meant as replacement for user saing "over" at the end of transmission.
The article mostly talks about CTCSS/DCS, which really are tones intended to control equipment, but these are mostly designed to not be audible (both CTCSS and DCS is sent during the whole transmission on frequencies below the voice pass band).
Roger beep is a tone that is generated by the transmitting station when user lets go of the PTT (in similar way to Quindar outro tone). Using this tone to control anything in CB/HAM context is not really possible because there is essentially no standardization of how the beep sounds. Also IIRC having roger beep turned on is mostly frowned upon on ham bands.
>Also IIRC having roger beep turned on is mostly frowned upon on ham bands.
Except the Roger beep coming from the repeater, which is semi-important in that it denotes that the repeater has unlatched and the transmit timer is reset.
If a repeater user keys up before hearing the Roger beep, the repeater doesn't restart the transmit timer, so there is a chance that your transmission will time out.
Yes, CTCSS/DCS is a control tone. Definitely. The first HT I had had a CTCSS board added to it, and could only be set for a single tone! Things have changed since then.
I've always thought that the beeps at the end of a user-initiated (not repeater) transmission would be cool, but they are indeed frowned upon. They aren't necessary, anyway. I'm sure if they became necessary for any reason, hams would be on the cutting edge.
Interestingly a digital mode called JS8Call uses framed transmissions, linked together, to send text over HF. At the end of a frame set, an ascii diamond is transmitted to signify EOL. Otherwise the receiving station doesn't know if they are done, or if they dropped a frame, or what. Not audible of course.
I've always enjoyed these beeps...to me, for technical radio comms, they lend a sense of "tightness" or maybe even "seriousness" that normal comms don't have. Control purposes aside, I just love them. And until now, I had no idea they were different frequencies...now that I know this, I can tell.
The method is predominantly used in public safety radio systems, where tone paging may be used to cause a fixed receiver in a station to open squelch (triggering an alarm) or cause a portable paging receiver (like a Motorola Minitor) to open squelch as a simple form of paging. Rural VFDs often rely on the latter to call out volunteers.
Anyway, the world of in-band signaling in voice communications is really pretty interesting, and while digital systems have reduced the need for in-band there are still a lot of real-world systems that rely on it for compatibility with legacy equipment. The telephone system has largely moved on (except for various niche uses of DTMF) but in-band signaling is still pretty common in radio systems, where upgrading to a digital system is high cost and comes with its own limitations.
Another example off-hand: most large-area public address systems, the type of thing the military often calls Giant Voice and might be used for tornado warning in some areas, use either DTMF or SelCall (five-tone) on the control radio channel (which in many cases is the same radio system used by public safety portable radios) to cause the loudspeakers to activate. A particular oddity of a lot of these systems is that they have different generations of receivers that use different methods, so sometimes you'll end up hearing the tones played aloud if a receiver opens squelch in reaction to something earlier in the sequence.
And a last example, also usually seen in public safety - some radio schemes like MDC transmit a burst that sounds like a roger beep whenever the PTT is released, but is actually a short data packet that identifies the transmitting radio. This allows a specially equipped base station to show e.g. a dispatcher who was just transmitting. Sometimes the same signaling system is used to implement other features like 'man down' detection where a radio signals if it is not upright or has not moved for a period of time (common safety feature in fire departments), but sometimes these kinds of systems also just use a sample-based speech synthesizer if there's no digital system already in use.
Oh, I can't resist one more. The "buzz," repeated three times, which proceeds emergency alert messages in the US is actually a short data packet which gives certain metadata about the alert and causes hardware in receiving radio stations (the system operates a bit like a "calling tree") to cut out the program audio and switch over the received alert. The two-tone beep which follows is a legacy system for the same purpose, although today no such receivers should still be in use. It's amusing that many phones use that two-tone signal as their ringtone for emergency alerts considering how divorced that is from its original purpose, but it's quite recognizable. Emergency alert messages should be followed by a three shorter data bursts which inform receivers that the alert is over. A closely related scheme is used by NOAA All-Hazards Radio to cause dedicated "weather emergency" receivers in people's homes to open squelch, these are more common in tornado-prone areas but generally work throughout the US. As the name suggests, All-Hazards also retransmits alerts from agencies other than NOAA including emergency alert system messages.