▲ 172 points
back
62 comments
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.
1: https://en.wikipedia.org/wiki/Specific_Area_Message_Encoding 2: http://www.whence.com/minimodem/
Would anything interesting happen if a valid SAME packet were dropped into the FM sub-carrier of a television signal on a CATV or DBS network?
> 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.
> SIP, which is very much an internet protocol designed by phone people.
Allegedly SIP is much better than the ITU's H.32x standards, and if that is true, then H.32X has to be an unspeakable horror.
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.
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.
I hear you, thanks too, I like to think we have better tools for the job, and that we do apply it by learning from the past.
So my original OP should be rephrased: Thank god we learnt and are still learning creative ways to make things work.
Inband signalling was the way long distance trunk lines worked back in the MF signalling days decades before ISDN D channels and SS7 and all that.
A fun topic to google for is what and how the 2600 Hz signal worked.
Didnt some guy figure out how to get free phone calls using a cheap whistle from a cereal box :-)
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.
I wanted to echo this.
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...
> It really seems that in earlier years, when resources were limited, people really used their ingenuity far better than today.
Nowadays we would just NPM install a few gigabytes of shit (and some backdoors & malware for good measure) and call it a day!
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.
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.
It's like the old code: creativity and cleverness everywhere. But with each new generation some things get standardized.
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.
Ironically future generations will likely look back now and wonder of our cleverness.
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.
I mean, this is not particularly clever or creative. It's just a really straightforward solution to a simple problem.
Modern wireless microphone transmitters are configured and updated via audible tones generated by a smartphone app.
In-band signaling was the norm until the early 80's.
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.
Here's a collection of songs:
"I'm looking for songs that contain NASA radio transmission snippets, or a "space" theme conveyed in a creative manner. Examples in text" https://www.reddit.com/r/trance/comments/1vl39y/im_looking_f...
Ah, yes Highroller by Crystal Method is one I've heard
Aphex twin #1 https://www.youtube.com/watch?v=z6xn0SRFYh4
There’s a song that comes up on Spotify once in a while that has, IIRC, clips of John Glenn during the Gemini missions. Chills down my spine.
I think these guys agreed with you...
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.
so they could be removed with a single notch filter
Chatterer is my favorite mod for Kerbal Space Program, and it brings these tones (and other authentic sounds) to the game: https://forum.kerbalspaceprogram.com/index.php?/topic/83290-...
I know them as "roger beeps" from CB radio terminology.
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.
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.
> ...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.
Why not transmit continuously? That seems to be the problem they're solving, but I'm not sure why that would be a problem.
i thought there were just fancy roger-beeps...