Pictorial Diagram

PICTORIAL

INPUTS:
Each module has various inputs. The number of inputs varies according to the module's duties - perhaps many dozens. The inputs are sampled many times a second; and the module locally analyses (internally) each input parameter.

The inputs are of two types...

One is ANALOG signals.
Analog signals are varing amounts of value; they can literally have any value. The module measures the value; and assigns a numerical value to the input signal.
The process is called digitization; the input signal is digitized, and given (assigned) a numerical value.
The other type of input signal is DIGITAL.
Digital signals are simply "on" or "off". For example, a digital signal could be an input of either zero volts, or five volts - no voltage in between these two values! The input signal represents a parameter as either on or off; existing or not existing; good or bad; etc. The time to determine one of two possible states is much faster than a digitization evaluation; This type of input has advantages.
 Each Node has both inputs and outputs...

Outputs are of two types: Hexfets and Relays.
Hexfets were used during 1993, but I have found relays to be more reliable in hazardous conditions; such as lightning and it's induced EMP voltages; and AC interruptions with their induced spikes and transients.
By 1995 I was using exclusively small reed relays onboard. The reed relays control a voltage isolated from the board; usually a 12v wall pack. (Board voltages are sacred, and are kept away from all external voltages. ) This isolated voltage then controls an auxillary relay located at the equipment. Each stage of relay isolation gives further voltage protection from potentially volatile equipment.
The remote control system, and its internal voltages, are sacred - never to be adulterated!

After the inputs are analyzed, judicious control is given to outputs. In an Autonomous Node's domain, each node (or module) is quite effective in the synergy of knowing and acting; and the two actions are as one.

Not only does each Node control it's own affairs, as discussed above, but in addition, autonomous devices communicate amongst themselves. Autonomous Nodes may have specific, special events of interest: specifically "this one" to "that one". And, - all Autonomous Nodes - have interest in community events in general. For example community events is the status of PG&E, which may effect all the controled equipment of all modules; Or a prime directive, which may effect the manner of operation of all modules. My modules are gregarious; they have interests outside of themselves.

Depicted is an external event (upper left). A module sees the event and communicates information to other members.

The objective of my control system is to not need computers. By FCC mandate, the system must have a human interface. Human interface is required, but computers are not. The casual observer will see computers, monitors, and printers connected to my system; and they may falsely assume that my system needs these devices; It does NOT!

Each local net, or community of devices, as many nodes (depicted by blue discs). Each node is shown exemplifying inputs and outputs (depicted by arrows pointing in or out). The inputs see and measure things; The outputs control things. Usually, each node has an interest in only one area, or piece of equipment. The nodes communicate amongst themselves within their groups.

I make a bold assertion, and, no dought, a fact: I was the first broadcaster in the world, to not only have, but also to design and build, such an advanced system.

The two depicted local nets are connected together by wireless modems. In practice, the links connect cities or sites. My connected sites are Chico, Cohasset, Tuscan, and Redding; all in California.

The end result is an autonomous system. Before the time my system was invented, there was only a computer type of controller: That computer micro-managed many parameters in fine detail. I was the first broadcaster, to not only invent on paper, but also build (physically develop) autonomous systems.
Those companies and controlled transmission sites are:

Module personality

Each module is hardwired to its devices (motors, sensors, etc); and as such, cannot change its function. However, the personality of each module can be changed. And, in theory (and I have not done this), each module can do an entirely different job. Because my systems are hardwired - the modules can only modify the way that they control their external things. When my modules come to life, they are born with a default personality. And this is how they handle business-as-usual. Personality - is controlled by one byte yielding a possible 255 different personalities. Theoretically, if a module is destroyed by chemicals, explosion, etc; then another module could assume some of those responsibilities by changing its personality.

Communication syntax and grammar

 "Todays robots are very primitive, capable of understanding only a few simple instructions such as "go left", "go right", and "build car"". - John Sladek
My modules communicate using nouns, verbs, and adverbs; much the same as an abstract sentence from a human. Other control programs used direct commands that were quite explicit: such things as "go right" or "turn it to 7". My modules, on the other hand, were the first devices to use primitive sentence structure.

As an example:
If a human wishes to raise the power on a visual transmitter; a packet of 22 bytes is issued to the site that has the device (in this case a transmitter). The packet is encapsulated (in an addressed envelope), so as to arrive at the correct site. Once at the site, the encapsulation is stripped away, and the 22 bytes are injected into the local public net, and distributed to all modules at the site.

All devices look at the first 5 bytes unconditionally.
The first byte is the number of bytes in the packet (in this case 22)
the next two bytes is the identity of the sending entity (in this case a human on a certain computer).
The next byte is the group destination (in this case the Transmitter Group).
The next byte is the formal individual (in this case a visual transmitter).
This byte may also be global and means All members of the group. (The global value is 255.)

Most modules will now drop out of the Listening mode, and will disregard the rest of the packet, and will return to their normal business.

With formalities over, we begin a communication discipline.
The sentence begins...
The next byte is the Personality.
I have also called this byte in my documentation as the "Pronoun".

After the Pronoun comes a one byte Verb (in this case - Raise).

Next comes the predicate section...
After the Verb comes the Object (in this case, a noun - power).

Next usually comes an Adverb signifying the duration of the raise,

But it could be a Preposition
signifying TO something (in this case a predefined objective of power). (The TO as one byte and the Power as one byte)

Next comes two bytes of CRCs(Cyclic Redundancy Checks) : one conventional, and one of my own design.
CRCs (error checking) are important in large, high power equipment: help prevent the danger of people being injured.
(In addition to CRCs to help prevent injury, I have provided Human Speech warnings in over head speakers.) Packet errors are almost non existant; but the stakes are high, and one can not take the chance.

My favorite chip is the Microchip PIC16C73B because this chip will handle the communication without additional communication chips. Memory constraints of the MicroChip PIC16C73B limit the versatility of "equipment speech", and as a consequence communication structure is quite rigid, and extremely well-defined. Fortunately, control is more predictable with limitations! I have no complexity of sentence structure. The only variance is one of Values of Predefined Parameters, and also the sentence length. Sentence length typically varies between 6 to 24 bytes. I have been controlling Broadcast equipment with these variable lengths sence 1995.

A notation should be made of what my communication scheme is not...
The scheme is not free open dialog between devices; no rhetoric is understood; all communication is short and specific. Otherwise, instability would result - and I do not want to deal with it. The memory constraints in my devices prohibit such advanced concepts; and, gratefully, relieve me of even the slightest prospect of physically obtaining adaptive artificial intelligence.

There is one more type of communication on the net: I call it a "literal quote". It is used by the EBS (AES) system in Chico; it is interfaced to my system. An AES receiver will cause a computer to dump several hundred bytes of literal quote into my net to be received by another computer. This communication is "verbose", and takes up a lot of traffic time. I do not permit this type of communication at Tuscan or Cohasset, where there are a lot of machines. At such sites, communication from machine device to machine device is paramount. ©®copyright 1995