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

gil smith [email protected]
Wed, 28 Apr 2004 11:55:34 -0700


Hi Roy:

TU Autostart (if enabled) will activate on the first char from the TU 
port.  Since the TU (and loop) ports are bit-banged, it simply means that I 
have found valid start and stop bits half-way through the respective bit 
times.  If the TU is on a noisy channel, this may give false autostart 
triggers if there is a mark-to-space transition and then a space is found 
in the middle of the start bit period  (an apparent start bit), and a mark 
is also found in the middle of the stop bit period (an apparent stop 
bit).  This is the only framing check I am doing.  I could, perhaps, 
qualify multiple samples in the start/stop bits.

Autostart on the PC port will be no problem, since the chars will always be 
good.  Is there a better way to qualify autostart on the TU port?  Someone 
mentioned looking for a SPACE char.

Suggestions?

gil


At 11:36 AM 4/28/2004, you wrote:
>Hi Gill,
>
>Please,please make sure there is a provision for copying every valid
>RTTY signal that appears on channel for those who want to copy
>everything, coupled with an autostart that turns on the TTY motor ONLY
>when a valid digital signal is being received.  AUTOSTART operation on
>the HF bands using the TU's mark carrier sensing work very poorly in
>practice.  They trigger every time a carrier crosses the freq and on
>stations that are too weak to copy.
>
>Roy --K4EEG
>
>
>-----Original Message-----
>From: [email protected]
>[mailto:[email protected]] On Behalf Of gil smith
>Sent: Tuesday, April 27, 2004 5:41 PM
>To: [email protected]
>Cc: [email protected]
>Subject: RE: [GreenKeys] WRU, SELCAL, and other features in TTY-CONNECT
>
>Hi Eric et al:
>
>Thanks for the feedback, and detailed examples -- I've never been
>involved
>in the radio side of things, so this selcal/wru stuff is new to me.
>
>First of all, the TTY-CONNECT micro code has several functions:
>
>1)  Allow an ascii PC-232 port to talk baudot to one of three powered
>tty
>loops, or the TU-232 port, at any of the standard tty speeds (60 to
>100-wpm).  The PC-232 port is fixed ascii @ 38400-baud, and uses
>xon/xoff
>for data throttling -- the unit automatically converts to/from
>baudot.  Note that all ports on TTY-CONNECT are regen.  This section of
>the
>code is done.
>
>2) Allow a baudot TU-232 port to talk directly to one of the three
>powered
>tty loops, at any of the standard tty speeds (60 to 100-wpm).  The TU
>and
>TTY must be on the same speed.  Code half done.
>
>3) Monitor the receive stream and provide programmable options for
>auto-crlf, unshift-on-space, autostart, selcal, wru, etc.  Selcal could
>even be used with the PC and multiple TTY-CONNECT boards, since the
>PC-232
>port can be daisy-chained with a special cable (as George requested).
>Code
>in the works.
>
>4) Allow a baudot TU-232 port to talk directly to one of the three
>powered
>tty loops -- at DIFFERENT SPEEDS (60 to 100-wpm).  A PC must be
>connected,
>and running a buffering program, for connecting the high-to-low speed
>stream.
>
>5) Allow a baudot TTY to talk directly to another baudot TTY on two
>different powered tty loops -- at DIFFERENT SPEEDS (60 to 100-wpm).  A
>PC
>must be connected, and running a buffering program, for connecting the
>high-to-low speed stream.  Half done.
>
>6)  Have the PC-232 port to talk raw 5,6,7,8-bit data to one of three
>powered tty loops, or the TU-232 port, at adjustable speed
>(45-110-baud).  The PC-232 port is fixed ascii @ 38400-baud, and uses
>xon/xoff for data throttling.  This allows connection to ascii ttys
>(M33/35...) and provides  for custom codes, such as non-ustty 5-level,
>or
>6-level TTS.  Done.
>
>
>I still have questions:
>
>- Auto-CRLF Insertion:
>--------------------------------------
>Could have a max trigger count (eg: 72) that forces return, and a
>smaller
>trigger (eg: 66) that waits for SPACE also, to keep words from
>breaking.  CR CR LF LTRS seems like a decent default string.  Tim
>suggested
>sending  \ CR CR LF LTRS ...  which also sounds handy.
>
>
>- Autostart:
>-----------------
>Well, I can't detect carrier, since the TU is a simple 232 port which
>will
>always mark or space -- I will simply wait for a valid char from the TU
>(or
>PC) before powering the tty motor.  I realize that LTRS are not needed
>to
>spin up the motor, but it is easy for me to just stuff them into the tty
>
>buffer first, as a delay mechanism.  I will make it a programmable
>number,
>with a default of perhaps 5.
>
>But what about turning off the motor?  As Tom suggested, I could wait
>for
>30-secs or so of inactivity, and then power-down.  What about sensing
>NNNN
>(or NNN), and then imposing a timeout delay after that?  Could also make
>
>motor-off a different programmable option (autostop).
>
>The ideas about a new end-of-message code make sense too -- how about
>ZZZ?  Then the motor can catch some Zs.
>
>
>- Selcal:
>--------------
>I don't see a reason to start the motor until the selcal string is fully
>
>qualified.  Was this done to allow motor start time?  I also don't see
>why
>end of address code is mandatory.
>
>Are only two selcals needed now (ZCZC for all/bulletin, or callsign for
>individual)?
>
>I could easily implement the following:
>
>SP SP SP CR      (required conditioning code)
>ZCZC                  (4-char selcal id;  ZCZC for all/bulletin, or
>callsign for individual)
>(motor starts)
>(message prints)
>NNN                     (or new eom code)
>(motor stops)
>(insert 12 LTRS)    (optional)
>
>
>- WRU:
>----------
>This is easily added to the selcal code by sensing the Figs H after the
>4-char selcal id.
>
>
>thanks,
>
>gil
>
>
>At 01:02 PM 4/27/2004, Eric Scace  K3NA wrote:
>
> >- Auto-CRLF Insertion:
> >    For TTY machines, the inserted sequence should be CR CR LF.  Two
>CRs
> > are needed to allow time for the typebox (or its equivalent)
> >to get back to the left margin, and to be de-bounced.
> >
> >- Autostart:
> >    The following points are applicable if no SelCal is being used, or
>if
> > the SelCal stuff is being implemented outside of your box:
> >    Carrier detect on the mark frequency should be used to power up the
>
> > motor relay.  Don't insert LTRS characters; the transmitting
> >station will do that.  Ltrs are not needed to spin up the motor.
> >    If you want to be fancy, you can delay powering up the motor until
>you
> > hear valid signals on both mark and space frequencies.
> >That's a little more precise and prevents the motor start from being
> >triggered by slow CW.
> >    Important: Don't turn off the motor with NNNN!  A station may send
> > several messages in a single transmission!  If you power off
> >the motor with NNNN, then the receiving station will miss the chance to
>
> >copy the 2nd and subsequent messages.
> >
> >    If your box is to be used to implement the selective calling
> > procedure, then the box may follow this procedure:
> >
> >    Motor start:  upon receipt of the conditioning code.  My proposed
> > conditioning code is 12 LTRS, 5 SP, 2 CR and LF.  To allow for
> >some errors, your box can consider 3 SP followed by 1 CR as a valid
> >conditioning code, and turn on the motor.
> >
> >    Motor stop:  Occurs upon end of address if the station was not
> > selected, or upon end of message.  My proposed end of address was
> >CR CR LF; you could use a single CR LF.  My proposed end of message was
>
> >LTRS LTRS CR CR 4 LF NNNN followed by 12 LTRS; you could use
> >NNN as sufficient (allows for an error in the first or last N).  (The 4
>LF
> >spaces the paper down at the end of the message; the 12
> >LTRS gives an area of all-holes in a paper tape where the tape can be
> >easily torn.)
> >
> >    A station would be selected if it received the general selection
>code
> > (e.g., ZCZC) or its specific, individual code (last 4
> >characters of the callsign).
> >
> >    Here is an example of a general bulletin followed by a message to
> > WB6ABC and N7UA, using the procedures which I suggested
> >earlier:
> >[carrier on] 12 LTRS, CR CR LF LTRS LTRS <<-- just to get local
>printers
> >(and stations not using SelCal) in sync and on a new line.
> >QST DE K3NA  <<-- legal ID
> >12 LTRS, 5 SP, 2 CR, LF  <<-- conditioning code
> >ZCZC CR CR LF  <<-- general call directing code, end of address.
> >[text of bulletin]
> >LTRS LTRS CR CR LF LF LF LF NNNN 12 LTRS  <<--- end of message.
> >5 SP, 2CR, LF  <<-- conditioning code
> >6ABC N7UA CR CR LF  <<--- two call directing codes for the two targeted
>
> >stations, end of address
> >[ text of message to wb6abc and n7ua ]
> >LTRS LTRS CR CR LF LF LF LF NNNN 12 LTRS  <<--- end of message.
> >CR CR LF LTRS LTRS DE K3NA SK  <<-- legal ID on separate line.
> >
> >- Selcal-Bulletin:
> >ZCZC will be used for all bulletins, so no need for a separate selcal
> >sequence.
> >
> >- 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.
> >
> >COMMENT:  Based on my earlier suggestions, this is how a WRU would
> >work.  The scenario is that K3NA wants to find out if DL6LAU can
> >copy him, before attempting to send a message to him.
> >
> >[carrier on] 12 LTRS, CR CR LF  LTRS LTRS <<-- just to get local
>printers
> >(and stations not using SelCal) in sync and on a new line.
> >QST DE K3NA  <<-- legal ID
> >12 LTRS, 5 SP, 2 CR, LF  <<-- conditioning code
> >6LAU FIGS H [carrier off]  <<-- Figs H is end of address for everyone
> >except DL6LAU.
> >
> >    At this point, everyone else except DL6LAU will have shut down.
>But
> > DL6LAU will respond with his pre-programmed response.  Since
> >your box is generating this automatically, there is no need for a rigid
>
> >size limit.  (I think the Model 28 machines could send up to
> >16 characters from a special WRU response unit.)  Here is a 16
>character
> >response.
> >
> >[carrier on] CR CR LF Ltrs DE DL6LAU CR CR LF [carrier off]
> >
> >    At this point K3NA, now satisfied the DL6LAU is hearing him, could
> > send DL6LAU a message using the format described earlier (and
> >starting from the very top):
> >[carrier on] 12 LTRS, CR CR LF  LTRS LTRS<<-- just to get local
>printers
> >(and stations not using SelCal) in sync and on a new line.
> >DL6LAU DE K3NA  <<-- legal ID
> >12 LTRS, 5 SP, 2 CR, LF  <<-- conditioning code
> >6LAU CR CR LF  <<-- general call directing code, end of address.
> >[ text of message]
> >LTRS LTRS CR CR LF LF LF LF NNNN 12 LTRS  <<--- end of message.
> >CR CR LF LTRS LTRS DE K3NA SK  <<-- legal ID.
> >
> >-A fixed Conditioning-Code ..
> >COMMENT:  A conditioning code and end of address code is
> >mandatory.  Otherwise, as you pointed out, the system is subject to
>false
> >selections.
> >
> >- What is the max size of the selcal string?
> >
> >- Can the selcal string be mandated to be a fixed-length?
> >
> >COMMENT:  Four characters (the last four of the station callsign)
>should
> >be enough.  Portable designations should be ignored when
> >forming the call directing code; e.g., W2NQ/7's code will be "W7NQ".
>In
> >the unusual case of a station with a three-character call
> >(e.g., M0B or K1A), I would suggest the default padding character is a
>"Q"
> >at the BEGINNING; e.g., "QM0B" or "QK1A".  I suggest "Q"
> >because Q is rarely used to form the start of a callsign.
> >
> >- (same questions apply to WRU string).
> >
> >COMMENT:  See WRU discussion above: it's just the call directing code
>plus
> >Figs H.
>
>;-----------------------------------------------------------------------
>--
>;  vaux electronics, inc.             480-354-5556
>;  www.vauxelectronics.com    (fax: 480-354-5558)
>;-----------------------------------------------------------------------
>--
>
>
>_______________________________________________
>GreenKeys mailing list
>[email protected]
>http://mailman.qth.net/mailman/listinfo/greenkeys

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