[GreenKeys] WRU, SELCAL, and other features in TTY-CONNECT

Thu, 29 Apr 2004 22:18:31 -0400

Hi Bob --

   Since all network traffic begins with the conditioning code, that code (whatever it is) takes care of what Bob calls the "SELCAL
in front of all net traffic" function.  I suggested 5 spaces 2 CR LF as the conditioning code, since that was widely used.  (Others
have pointed out "ZCZC" was commonly found in message headers, but may have forgotten that in those message formats ZCZC was
followed by 5 spaces 2 CR and a LF...)

   The key thing about a conditioning code is that it must NOT appear in the middle of any messages!  If the conditioning code
appears in the middle of a message, it will cause everyone's machine to treat the following text as a string of Call Director Codes
(i.e., station selectors) until something else in the message text that looks like the End of Address sequence appears.

   Therefore, we should NOT use ZCZC as the conditioning code.  Look at every ARRL bulletin: it has ZCZC right in the start of the
bulletin!  If someone were to transmit that text, everyone's machines would go back to hunting for Call Director Codes and probably
miss the rest of the bulletin text.

   5 spaces 2 CR LF was used as the conditioning code because message texts don't contain multiple spaces immediately followed by a
CR.

========

   "Message for everyone" call director code:  Yes, we should have one.  I don't see why ZCZC won't work if we are using 4-character
call director codes.

========

   I don't see the need for an "end of transmission" code.  The last message finished with NNNN.  Digital autostart will shut down
the machine with NNNN; analog autostart will shut down the machine when the carrier drops.  Defining an end-of-transmission code
adds more work to building up the systems (mechanical or digital), and doesn't provide any new functionality, and raises more new
questions such as the following:
   If the end-of-transmission code appears after the conditioning code, what happens to the machine?  Does it shut down?  Or is the
end-of-transmission code only considered valid if it occurs after NNNN and before a conditioning code?  Either approach would need
lots of extra stuff in order to make sure a mechanical stuntbox reverts back to the state where it is waiting for a new conditioning
code.
   If the end-of-transmission code appears after the end-of-address, but before NNNN, what happens to the machine?  Again, one would
have to provide more hardware to get the machine back into waiting for a new conditioning code.

   Furthermore, if one was to use an end-of-transmission code, it must be selected carefully.  CZCZ is a very bad choice because
three characters are identical to the 4-character ZCZC sequence, a 75% overlap.  A garble on a single character before or after
"ZCZC" could result in reception of "CZCZC" or "ZCZCZ", either of which would also trigger whatever functions were defined for the
end-of-transmission sequence.

   I would recommend against defining any end-of-transmission code.

========

   Tape punch turn on code:  Such a code should be incorporated between the conditioning code and the end of address code.  There
are two reasons for this:
a) the tape punch turn-on can be station-specific.  This allows a message to be sent to several stations at the same time, but only
specific ones would have their punch activated.
b) if the tape punch turn-on code occurred in the middle of a message (due to a garble or other reason), it would be ignored.  There
is little point in activating a tape punch in the middle of a message.

   One approach would be to append Figs Blank after the call director code (4-character sequence) of the station whose punch is to
be turned on.  Example:  K3NA Figs Blank would cause K3NA to copy the message, and additionally to turn on his tape punch (which
would run until NNNN).  Example: B8TQ Figs Blank space K3NA  would cause both KB8TQ and K3NA to copy the following message, but only
KB8TQ would have his punch turned on.

   The short, 2-character code reduces the number of slots required in a mechanical stunt box.

========

   "ASCII art":  This is probably a misnomer since we are running ITA2 (baudot), not IA5 (ASCII).  If this becomes an issue we could
discourage folks from transmitting art to the entire network.  If someone wants to send art to other specific stations, then that's
up to the sender and receiver.  If this becomes a serious problem then one needs to ask this question: "Will the person sending the
annoying art bother to precede it with the Art Code?"  If the answer is "No, that person already is violating network etiquette by
sending art to 'everyone', therefore we can not expect him to insert an Art Code", then the design objective is different.  The
objective is "a code that informs the recipient that the following message is NOT art"... which, to be successful, will have to be
implemented on the receive side by everyone who is annoyed by receiving art... and on the transmit side by everyone who sends
non-art messages.  The later may be difficult to get everyone to do.

   I suggest keeping the code set to a minimum for now (i.e., no art code), and seeing if we really wind up with an intractable
problem that can't be addressed by network etiquette and peer pressure.

========

   I apologize if others are tiring of emails about these nuances of automatic systems.  Proper system design takes some care as
there are traps (sometimes subtle) which need to be avoided.  An extensive interchange of views and candidate solutions now will
save a lot of re-design later.

-- Eric K3NA

-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Bob Camp
Sent: 2004 April 28 20:53
To: [email protected]
Cc: gil smith; GreenKeys
Subject: Re: [GreenKeys] WRU, SELCAL, and other features in TTY-CONNECT

Hi,

There are several codes needed:

1) Something that comes as a SELCAL in front of all net traffic. If I
want to copy all the net I set that up to fire up the print mechanism.
It also acts as the "turn on" code for digital motor control. ZCZC is
the obvious candidate.

2) Everybody needs their own SELCAL and we need to be consistent about
how many characters are in it.

3) We need an end of message code - NNNN is the obvious choice. If you
started up with your code then NNNN stops printing.

We *may* want to have a couple more codes defined. If we send them and
they are not recognized nobody is hurt.

1) Since ZCZC is already taken we need a "message for everybody" code.
Weather you call it a bulletin or what ever, you need it to wake up
those who are not copying the whole net. If we are going to use it we
need to agree on a code.

2) How about an end of transmission code? NNNN is nice for messages but
if you started up on ZCZC you would not shut down at the end of each
message. CZCZ would be fine with me unless that makes for a problem.

3) My personal favorite - the ascii art code. I can remember nothing
that ever brought up as much debate as big picture transmissions. A
number of people loved them and set up tape punches specifically to
copy them. They needed the code to turn on the punch. Others hated them
and wanted the code to shut everything down. Either way it's a handy
code to have if we are going to do pictures ...

I don't want to beat this to death. I would like to get a reasonable
discussion of the pros and cons before the software gets written.

	Take Care!

		Bob Camp
		KB8TQ