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

[Bob Camp]

Hi

A few observations:

TX diddle is also a good thing if we have some of the old auto tune  
TU's on the net. I have never used one so by definition they must be  
old :) .... The tuning voltage comes off of an average between the mark  
and space voltages out of the discriminator. If you feed them full mark  
they miss tune. If we are going to be compatible with all the possible  
hardware we may need to include this sort of thing.

Multiple SELCAL's are a good idea. We have three hams in the shack here  
....

Keep QST as the bulletin flag sequence. A bulletin ID sequence might  
also be nice. In other words QST first and then an ability to identify  
the actual bulletin.

On a model 15 the normal CR/LF sequence needs to be at least a  
CR/CR/LF. I would recommend CR/CR/LF/LTRS since it takes care of  
garbage copy issues and it lets stuff that's even slower than a 15  
catch up.

A a motor on = ZCZC capability.

We need a motor off string (CZCZ ???) since NNN or NNNN is really a  
message separator.

Figure about a second for the delay for the motor to start up. Allow  
about 100 ms between the end of a WRU request and hitting the  
transmitter key line. Allow about 100 ms between keying the transmitter  
and actually sending the reply string.  Same sort of delay after the  
end of data to unkeying the PTT.

SELCAL strings are commonly pretty short on RTTY. The main driver has  
always been the size of the stunt box. To SELCAL me you would send  
KB8TQ. My stunt box would recognize B8TQ and go from there. On a PIC  
that doesn't apply. Since the sender gives the whole call we might as  
well recognize the whole thing if we have the capacity in EE memory to  
store it.  I doubt that more than 8 characters would be useful ....

I think that WRU = SELCAL + terminator. If we use a standard terminator  
(like FIGS H) then you only store the SELCAL. If you do it that way  
then there probably needs to be a bit flag to enable WRU for a given  
SELCAL.

I would vote for a conditioning code in front of any command. On a  
stunt box it would be ignored. On the PIC it would help keep down the  
false starts. What ever it is should be easy to send. Five spaces and a  
CR/CR/LF/LTRS is probably a pretty good string.

	Take Care!

		Bob Camp
		KB8TQ




On Apr 27, 2004, at 1:41 PM, gil smith wrote:

> 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)
> ;---------------------------------------------------------------------- 
> ---
>
>
> _______________________________________________
> GreenKeys mailing list
> GreenKeys@mailman.qth.net
> http://mailman.qth.net/mailman/listinfo/greenkeys
>