[GreenKeys] WRU, SELCAL, and other features in TTY-CONNECT
Roy Norris
[email protected]
Wed, 28 Apr 2004 12:36:33 -0600
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