[GreenKeys] WRU, SELCAL, and other features in TTY-CONNECT
Bob Camp
[email protected]
Tue, 27 Apr 2004 20:09:16 -0400
Hi
One quick observation: you actually have two carrier detect methods on
your normal RS-232 nine pin connector. Good old DCD (data carrier
detect) and RI (ring indicator). Either one works just fine for sending
in the carrier level switch from the TU.
Take Care!
Bob Camp
KB8TQ
On Apr 27, 2004, at 7:40 PM, gil smith wrote:
> 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
>