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

[gil smith]

Hi folks:

Well, I am back into the middle of the TTY-CONNECT pic code, to implement 
selcal and other requested features.  There have been quite a few different 
suggestions bouncing around here, and I am not sure what consensus, if any, 
has been reached on selcal and wru.

Let me tell you where I am, and see if we can iron out some details.  Note 
that this code is easy to modify in the field with a download from a pc, so 
changes later are not a problem.  I just need to get the framework established.

All programmable features in TTY-CONNECT are stored in non-volatile memory 
(pic eeprom).  This includes the current connection (TU to HV1 loop, PC to 
LV loop...), current port parameters (60-wpm...), selcal sequences, which, 
if any, selcals are enabled, etc.

The received stream of characters destined for the tty loop, runs through 
the section of code I am working on at the moment, where the optional 
features reside.  This includes features we talked about ages ago, as well 
as the stuff being discussed currently:

- Data Invert:
If enabled, inverts RX/TX data streams (for TUs with MIL STD 188 port 
instead of RS-232).

- RX-Diddle Filter:
If enabled, discards two or more successive LTRS or FIGS chars.

- TX-Diddle Insertion:
If enabled, constantly send LTRS or FIGS chars when TX stream is idle.
Is this really needed by anyone?

- Auto-CRLF Insertion:
If enabled, counts chars until it hits a CR or a trigger count.  If it hit 
the CR first, it resets the counter to zero (since this line was short 
enough).  If it hits the trigger count, it waits for the next SPACE char 
(so as not to break a word), and then inserts CR and LF into the tty 
stream.  The trigger count will initially be 66 chars, but is 
programmable.  Note this will actually insert a programmable string, so 
additional carriage delay can be added as needed.

- Unshift on SPACE:
If enabled, when in FIGS mode will shift to LTRS mode after receipt of 
SPACE char.
Someone suggested unshift on CR as well -- is this useful?

- Autostart:
If enabled, detects the first char in the stream, activates a signal line 
which drives an optional tty motor relay, and inserts X number of LTRS 
chars into the tty stream to allow motor spool-up.  X will be programmable, 
of course, but I need to know a decent initial value.  When NNNN is 
received, motor is turned off.
Note that Autostart has priority over any selcal.

- Selcal:
If enabled, detects a programmable sequence (callsign...) in the stream, 
activates a signal line which drives an optional tty motor relay, and 
inserts X number of LTRS chars into the tty stream to allow motor 
spool-up.  When NNNN is received, motor is turned off.

- Selcal-Bulletin:
If enabled, detects a programmable sequence (BULL?) in the stream, 
activates a signal line which drives an optional tty motor relay, and 
inserts X number of LTRS chars into the tty stream to allow motor 
spool-up.  When NNNN is received, motor is turned off.

- Selcal-All:
If enabled, detects a programmable sequence (ZCZC?) in the stream, 
activates a signal line which drives an optional tty motor relay, and 
inserts X number of LTRS chars into the tty stream to allow motor 
spool-up.  When NNNN is received, motor is turned off.

- WRU Query:
If enabled, detects a programmable sequence (WRU?) in the stream, activates 
the PTT signal line for transmitter activation, sends a programmable 
sequence back, then deactivates PTT.

Most of this is pretty straightforward.  The Selcal and WRU sequences, will 
be programmable strings, but I need defaults to start with.

I have never done any 28 stuntbox work, but looking at a 28 doc I find that 
there is more than just the selcal string involved.  eg:
- Conditioning-Code:      FIGS-H-LTRS
- Call-Directing-Code:    this is the selcal string
- End-of-Address:          CR-LF-LTRS
- (message body)
- End-of-Message:        FIGS-H-LTRS  (what happened to NNNN?)

I guess this is all programmable in the stuntbox, and this is only an 
example.  I also imagine that the Conditioning-Code and End-of-Address only 
need to be sent for compatibility with real stuntboxes.

Some other questions:
-A fixed Conditioning-Code ahead of the selcal string would prevent a 
callsign in a message body from triggering an unwanted selcal.  What say ye 
on Conditioning-Code?

- What is the max size of the selcal string?

- Can the selcal string be mandated to be a fixed-length?

- (same questions apply to WRU string).

Any input appreciated,

gil



;-------------------------------------------------------------------------
;  vaux electronics, inc.             480-354-5556
;  www.vauxelectronics.com    (fax: 480-354-5558)
;-------------------------------------------------------------------------