Controling a broadcast site

TTBAKMCU.JPG, 19 kB Example of a Unit Module located inside a transmitter.

The new control systems are installed at Cohasset, Chico, and Tuscan broadcast sites. The new system is comprised of distributed units, placed in a myriad of places throughout a broadcast plant. The Unit Modules are connected together with wire which contains system power and ground. No computers are considered as part of the system. However "speech" and "computers" are considered part of the human interfacing.
ALLcohMCU.gif, 34 kB A communications screen
A communications screen
There are many Unit modules at each site.

If you type from a computer (from any screen) the word "ALL" (or several other versions) a request will be sent out to all units. The request is a question: "What is your unit identification numbers and version number?" The request has a "255" for the address of the IDgroups which means "all groups". The request also has a "255" for the address for all individuals of those groups. In essence, all units will respond back. This is a handy command to see what units are attached to this LAN. The time for all units to Check-in is about a second. Here is a display at Cohasset...

Two pieces of information are displayed for each Unit Module: the Group ID and the formal individual ID. There are over 60,000 possible individuals. There is all kinds of additional information that can be returned on each unit, but in this case, we are only interested in who they are.

The only fitting screen for this information is in the "PORT" screen which handles communications. A screen, in green, floats on top of the Port screen, so it is actually two screens. The Port screen, and the floating green screen, are illicited with the typing of the word "ALL". Instantly the green screen fills up with responses. Every one of these responses also go to the data's individual destination screens. But in this case they are not visible. In the normal coarse of the day, as activities change for each unit, their screens may be visible and are placed on top of the previous: they take the "focus". The responses in this case are only versions and times of each unit. Minor stuff! This does not justify visibility.
PortScreenCaptureData.jpg, 38kB
I have made improvements over the years, and I don't believe there is a system like it. And communication is like no other. In fact handshaking is not really required; I use it for backwards compatibility. It is a dead artifact. It exists on the wires, but the communication modules do not need it.

Packets never have had software handshaking either. My protocol relies, and is totally depending, on prosode. Packets can be any length. And because I use the full ascii byte (8 bits), there is never an End of Character designation. Instead all bytes are used for all words. My devices have at their disposal 256 characters for their alphabet. Prosaical use is all that is left for sentence recognition; Identical to human speech. In addition, there exists a CRC byte at the end to not only validate the sentence but also an aid in demarcation. All of this is possible due to my slow baud rate:4800 bits/sec. There is plenty of time for analysis, and my microprocessors are "thinking" all during the time data is being received. Not just at the end! ...Just like human speech.

Even my sentence is unique. My sentences have nouns, verbs, adverbs , and adjectives. But location of object and subject are rigidly placed; Similar to a child's speech, or rigid "baby talk".

And armed with all that, my modules can spontaneously talk to each other at will.