Now, with him coming from that side, he's a bit prone to overestimating his systems understanding. So, when he was assigned to a project to make a new space for weather presenters in our renovated newsroom, he of course thought up the entire solution in his head and ordered stuff before talking to network engineering. The specific part he needed help with was transmitting a relay closure to the machine room. The presenter has a small handheld radio remote, and it will pull relays in a receiver box. The closure will then advance the chroma-key weather map to the next picture, so it needs to be fed to the computer generating the map picture..
The radio of course is more or less line of sight; it needs to be in the same room. The machine room is reachable from the wiring room adjacent to the presenter room, but only via optical fibre. So, he'd concluded that he needed a way to push a relay closure over singlemode fibre.
Here's where he got in touch with me, because I have stock of SFPs (small optical plug-in module) and the thing he'd bought uses those for line interface. -- "I want two SFP's" he said. And dumped a PDF containing the thing's manual in the email too. -- "No", I said, having read the manual. "You are not getting a 9/125µm pair from A to B for that. You are getting a network port in the wiring closet, and one in the machine room. Fibres are relatively scarce; network ports in switches are abundant."
This being the first time I work with those Things, I decided to verify the solution properly. Also, I -- regardless of verification -- needed to check that everything actually worked, and learn how to program it. Lab time! I brought my toolcase and my latest counter acquisition, the 5316A, to work and started to wire things up. Now, the initial setup was, with the test points in ():
radio clicker -> receiver giving relay closure (5316A A in)-> Thing A having optocoupler input biased to 5V -> network to local switch -> Thing B -> relay output > (5316A B in)
After an ungodly amount of trial and error in triggering the 5316A A>B mode properly and actually understanding what the fuck I was doing, I had to find the control software for the Thing, (and here, about, is where the idea the PM had would break, because there was no way to control the Things in his solution.) be allowed to install it on a Windows machine, and finding the Things and when I'd found and controlled them, I actually could send a closure over the wire and I could see that the receiver trigged properly.
The yellow box is the radio receiver, the green ones are the Things. The plushies are Guardians of the TE.
There is some delay variation, but I could reliably get the signal over in about 3ms. Sometimes as low as 2,1ms, sometimes up to 3,5, but never above about 4. Now, here comes the funny part.
As I pulled a long cable to another wiring closet, and thus forced the signal through not only one, but 6 consecutive switching or routing hops, the latency through the system did not change. In my testing, the latency is entirely down to the whims of relays and optocoupler debouncing. Electro-mechanickal things are slow. Ask Konrad Zuse, the man who built a Turing-complete mechanical computer with a clock frequency of 1Hz.
Of course, were I to run this along some wide area path, the speed of light in silica glass (about 0,667 c) would interfere, but for runs of 1 km (common length of cable in our facility, if you have go to the computing centre and back out to another room) the additional latency is perhaps 5 x 10-6 seconds.
TE saves the day! From meetings and boredom, that is. That was fun.
