Wowee! You’ve been assigned as an Engineer, and someone has bombed telecomms! Now no one gets to talk over radio and you have died a virgin… is what someone would say had you not read this guide.
Telecomms is by far one of the most persnickety parts of the station, and very, very easy to absolutely wreck (provided you can get to it).
This guide will be using Box Station’s telecomms setup because I’m lazy, however this guide is still usable on any station, though the specific layout or machine composition might be a bit different. If you can make an autolathe, you can make any of the telecomms machines.
Part 1: For it’s dark and it’s airless and cold
The telecomms room is cooled to around to 100K, as the machines heat up and need to be cooled, and is around 35kPa, meaning you will die if you aren’t in a space suit of some kind, or are drugged to hell. Grab a hardsuit and some oxygen.
The ONLY tool you need to fix telecomms (not counting a wrench if you’re totally reconstructing it) is a Multitool. It is absolutely 100% mandatory you will get NOTHING done without it.
Part 2: What even are the machines?
The default Telecomms setup is made up of 6 machines that actually matter. These are:
The HUB - Used to hook everything together. In a default telecommunications setup, this is vital. It’s also important for cross Z-level communication, such as with Lavaland.
The BUS - Used to ferry signals to-and-from the machines nigh-instantly.
The PROCESSOR - Decrypts and cleans up the incoming signal. Without it, your messages will be garbled nonsense. Obviously critical.
The SERVER - Used to handle specific frequencies, you need these to have Department channels.
The RECEIVER - You need these to actually get radio signals. Obviously critical.
The BROADCASTER - You need these to actually send radio signals. Obviously critical.
Part 2.1: Shit there’s more?
The AUTOMATED ANNOUNCEMENT SYSTEM can have its message changed to funny things, or update new arrivals on current events.
The MESSAGING SERVER is used to handle PDA messages. If it’s off, no messages will be received - they can still be sent, they’ll just never be seen.
The NTNET QUANTUM RELAY is used for tablet computers. I don’t think anyone ever cared about this machine.
The BLACKBOX RECORDER does something i dunno
The TELECOMMUNICATIONS RELAY is used for cross Z-level radio. If you turn it off, you can’t send or receive radio from other Z-levels. The Mining base has one.
Part 2.2: What even are Frequencies?
To properly fix tcomms, you have to know the frequencies. They are:
134.7 - Supply
134.9 - Service
135.1 - Science
135.3 - Command
135.5 - Medical
135.7 - Engineering
135.9 - Security
145.9 - Common
You can enter them either as 135.9 or 1359, the machine doesn’t care. Other frequencies exist, such as the AI’s private one, but they aren’t important.
Part 3: The Interface
The tcomms interface is a spooky beast, and - depending which machine you multitool’d - a long one.
Power Status: Take a guess
Identification String: Used to identify the machine on the monitoring console, and for organisation.
Network: Tells you which network it’s applied to. You can change it, but it’ll reset all the linked machines, meaning you have to go reset them.
Prefabrication: Doesn’t matter, it just tells you whether the machine was there at roundstart.
Linked Network Entities: Tells you what machines are linked to that specific machine.
Filtering Frequencies: Tells you what Frequencies are being run through that machine. E.G. the Bus connected to the SUPPLY SERVER and SERVICE SERVER will filter frequencies 134.7 and 134.9.
RECEIVER SPECIFIC
Remote Control: I have no fuckin’ clue but it doesn’t matter
Circuit Jammer Signals: I have no fuckin’ clue but it doesn’t matter
Part 4: Connecting the machines
Now for the actual important part, what machines are connected where and why - except in more specific terms.
To change any part of a machine via the interface, just click.
Linking machines literally takes the click of a button. Scroll down to when you see MULTITOOL BUFFER, and ADD MACHINE. Add the machine to your buffer, then move over to another machine and either LINK or FLUSH the buffer.
The Server
The SERVER connects directly to the BUS and the HUB in the default setup.
This is the server responsible for handling messages from the SUPPLY channel. It is connected to BUS 2, and is filtering frequency 134.7, as that is the designated SUPPLY frequency.
The Bus
BUS 2 is directly connected to the PROCESSOR, the SUPPLY SERVER, and the SERVICE SERVER. For this reason, it is filtering frequencies 134.7 and 134.9, as these are the frequencies assigned to the two channels.
The Processor
PROCESSOR 2 is connected to BUS 2. Processors are
ABSOLUTELY FUCKNG CRITICAL
Because if there is no processor involved, things like this will happen.
The Receiver
RECEIVERS are connected directly to the HUB, however they can be connected directly to the BUS. As many default telecomms setups make use of 2 RECEIVERS, this one is set to filter only its group’s frequencies, being SUPPLY, SERVICE, MEDICAL, and SCIENCE. They are even more mandatory than processors.
RECEIVER B is linked to about a dozen other frequencies due to the fact that the COMMON SERVER is filtering all frequencies that can be set by a radio headset.
The Broadcaster
BROADCASTERS are connected directly to the HUB, however they can be connected directly to the BUS. They don’t filter anything, but are even more mandatory than processors.
Part 5: Tcomms machine 
roke
Well, shit. Something’s gone wrong in telecomms. Generally this means it’s been blown to shit. This tends to happen on nukeops rounds, and in a roundtype like that, you needs comms up. Stat. There is a spare copy of every telecomms board within Tech Storage, alongside a collection of parts that can be used in an RPED.
The simplest (yet still effective) shape telecomms can take is this.
A PROCESSOR, BUS, BROADCASTER, and RECEIVER. Evey machine is linked to the BUS, and allows for common to be used with 0 issue. Without dedicated servers, no other channel will work. Ignore cooling them it doesn’t matter.
Part 5.1: Troubleshooting
Well, shit. Something’s gone wrong with telecomms, and there’s not been an explosion. So that means the least fun part of the job - figuring out what’s gone wrong.
Step 1: Does the room have power? If the answer’s no, there’s likely your problem.
Step 1.1: Is the machine turned on? If the answer’s no, there’s likely your problem.
Step 1.2 The machines have power, and are on, but look off and there’s nothing in the interface? This is an Ionospheric Anomaly, and temporarily disables tcomms. You have to wait it out.
Step 2: Are any machines missing? The most likely cause of this is the Processor Overload random event, which will detonate one of the processors, causing scrambled text. Another common cause is just them being deconstructed. This is frustrating, time-consuming, and incredibly easy to do - you need a screwdriver and crowbar to cripple tcomms. Grab the boards and parts from either the floor, or tech storage, and get fixing.
Step 3: Is it limited to a certain department? If only a specific department is having radio trouble, check the corresponding RECEIVER and BUS, and check whether they’re filtering the frequencies correctly. A revolutionary would only need a multitool and some door-hacking skills to completely disable Security and Command’s radio channel. Reset the frequencies to fix the channel.
Step 4: Is text scrambled despite the processors still being on? This is a random event which temporarily disables all PROCESSORS. You have to wait it out.
Step 4.5: Text is still scrambled, yet the processors are completely fine? There is a Radio Jammer nearby, a traitor item which can fit in backpacks.
Step 5: None of the above, yet the radio is still down? Your headset is turned off. Turn it back on.
Part 6: Conclusion
Telecomms is a time-consuming beast, but nothing beats the feeling of foiling some crafty traitor or overloading AI with good old work. It takes a bit of know-how to assemble an improvised tcomms, more to understand how default tcomms works, and a lot to be able to fix it from scratch. There are dozens of things that can go wrong with it, with many of the intentional acts incredibly easy to perform.
This is not intended to be a full guide of every single thing you can do with tcomms - and don’t even get me started with NTSL - but is intended to let any random engineer have the info they need to fix up the most important part of the station. I have absolutely not played enough in recent months to fully explain tcomms, or any changes that they’re undergone since.
If you have any questions, or anything is incorrect, just say so, and it’ll be either answered or changed. This was made at around 5am, so there’s a chance I’ve forgotten something.
Part 6.1: TLDR SIMPLIFY IDIOT
Grab a multitool, and space suit / hardsuit, or just brave it / heal until you die.
Link BROADCASTER to BUS
Set correct FREQUENCIES on SERVER , link SERVER to BUS
Link PROCESSOR to BUS
Set correct FREQUENCIES on BUS
Set correct FREQUENCIES on RECEIVER, link RECEIVER to BUS
If needs be, connect EVERYTHING except the PROCESSOR to the HUB
role