
Network Operation
SYNCHRONIZATION AND NETWORK ACQUISITION BY
SLAVES
This section describes the process through which a network
is initialized, and through which additional subscribers
(Slaves) join the network.
Slave Initialization
Upon initialization, a Slave must search for and find the tune
and bit rate currently in use. It proceeds as follows:
1. All tunes are searched, starting with the highest.
2. Within each tune search, bit rate is searched, starting at
the highest bit rate.
3. Within each bit rate, gain is optimized using the peak
search procedure described in 1 and 2.
4. If a valid packet is obtained during this process, then the
Slave knows the tune and switches to it, entering run
mode. The Slave knows a packet is valid when the error
code checks correctly.
5. If not, the Slave proceeds to search all the possible
tunes and bit rates, remaining on each combination for
four packet times.
This process is repeated until a valid packet is heard.
Master Initialization
The Master starts by performing the Slave initialization se-
quence to see if a network with the same network address
already exists. If so, it will listen and wait for that Master to
falter. When it no longer detects the other Master, it will step
in and try to take over.
Application software developed for IC/SS must keep track
of the number of Masters and their addresses, as the duel-
ing Master situation is impossible to prevent and can be
very confusing.
If the Master cannot find a Slave with its own network ad-
dress, it will proceed to the next frequency channel, and
repeat the process.
Network Runtime Operation
In order to keep the system gain and tune selection optimal,
the network is always kept active. In network mode, the
Master runs autopoll whenever there is no required host
traffic.
Once a network is established with one or more Slaves, the
tune control will be performed as described above.
ERROR CODING AND TIME DIVERSITY
In addition to frequency-dependent noise which is combat-
ed by the adaptive frequency hopping described above,
power lines suffer from impulsive noise. Impulsive noise
bursts occupy all frequency bands for relatively short peri-
ods, often less than one bit time. This noise tends to be
synchronous at 100 Hz or 120 Hz due to its origin.
In network mode and in the software loopback function of
transparent mode, two techniques are employed to reduce
sensitivity to impulse noise: error correction and overlay of
retries.
Error Detection
Bytes transmitted over the network are 9 bits long, 8 bits of
data plus a parity bit. This allows the receiving unit to detect
single-bit errors in any byte.
In addition a 27 bit error code is appended to the end of
each packet. It consists of three bytes plus byte parity. The
three bytes together comprise a CRC-24. This error coding
allows implementation in software in real time, meets IEC
and CENELEC requirements, and works well with the over-
lay technique.
Overlay of Retries
Overlay of retries means saving those portions of earlier
blocks which were not corrupted, so that on a subsequent
retry a complete message can be assembled. A single im-
pulse noise burst should only affect one or two bytes, and,
since the timing of retries is arbitrary due to variable block
length, it is unlikely that impulsive noise bursts will hit the
same portion of a message on successive retry attempts.
If a given byte of a packet has invalid parity, the receiver will
continue to collect data for the remainder of the packet, and
will store those bytes with valid parity in the receive buffer.
However, if the first byte, which contains the packet length,
is corrupted, the entire packet must be abandoned.
On subsequent retries, if any byte is invalid, it will not be
written to the receive buffer, but the corresponding byte al-
ready stored from the previous transmission or transmis-
sions will be used. At the end of the packet, if the 27 bit
error code is found to be valid, then a complete packet has
been assembled and it will be output as such.
This approach allows the system to communicate success-
fully even in an environment so noisy that every packet has
uncorrectable errors. It is only necessary that each byte get
through once.
PACKET STRUCTURE
Data is sent between units in packets of variable length,
containing from zero to 17 bytes of data, plus protocol infor-
mation and error coding. The packet format is shown inFig-
ure 5.
TL/DD/11727–10
FIGURE 5. Packet Structure
For all communication modes between Master and Slaves
except broadcast, a block-ahead acknowledgment proce-
dure is used. This ensures that packets are retried if errors
cannot be corrected. The number of retries is limited by a
retry count parameter. The application program is thus guar-
anteed that either a packet will be delivered to the far end,
or the application program will be notified that this is impos-
sible.
16