[GreenKeys] WRU and SELCAL
[email protected]
[email protected]
Tue, 27 Apr 2004 3:04:42 +0000
Hi Eric,
Great suggetions !!! I agree, we should maintain complete comptability with mechanial selcal and wru.
Regards -- Roy, K4eeg
>
> From: Eric Scace K3NA <[email protected]>
> Date: 2004/04/26 Mon PM 01:59:52 GMT
> To: Roy Norris <[email protected]>, [email protected]
> Subject: RE: [GreenKeys] WRU and SELCAL
>
> Suggestions:
>
> 1) Stick to "NNNN" (four "N") as the standard turn-off sequence, but programming the SelCal system to turn off on receipt of 3 Ns.
> This takes one less slot in a stunt box. This has work successfully for decades on commercial and military RTTY circuits.
>
> 2) No need for double-LF in the sequences.
>
> 3) Why use [callsign]ZW for the WRU interrogation? What was wrong with the traditional "[callsign]Figs H Ltrs" followed by
> immediate drop of carrier? The stuntbox would be set to respond upon receipt of [call] Figs H; the Ltrs was used as a buffer to
> compensate for mechanical lag. (See page 17 of the "Teletype Model 28 Stuntbox" booklet.)
>
> 4) Given the scarcity of function bars, latches, forks, pawls, levers, etc., perhaps we could agree to use the last 4 characters of
> a callsign as the actual selection sequence. For four-character calls like "K3NA", this amounts to a full call. But for "WB3ABC",
> "3ABC" would be the sequence encoded into the stuntbox or its electronic equivalent. The cases of overlapping 4-character sequences
> would be rare.
>
> 5) A complete SelCal system needs to define:
> -- "conditioning code": the sequence of characters used to alert machines that call-directing codes are to follow. Upon receipt,
> a machine is in the 'select non-print' state.
> -- "call directing code" (CDC): this is what selects a machine to receive the message. Selected machines switch to the 'select
> print' state.
> -- "end of address code": this tells machines that all CDCs have been sent; if the machine hasn't been selected yet, it need not
> pay attention to the message. All non-selected machines move to the 'non-select' state and don't pay any attention to anything else
> until the next conditioning code is heard.
> -- "end of message code" (EOM): this tells machines that were selected that the message has been completed. They can move to the
> 'non-select' state now.
>
> An example of a commonly used approach:
>
> conditioning code: twelve LTRS, five SP, CR CR LF. Note that normal message text would be unlikely to send a sequence of spaces
> followed by a CR. The stuntbox might be encoded to use just four or three spaces, followed by one CR, to actually put the machine
> in the 'select non-print' state. The twelve LTRS are sent to allow all the machines to get synchronized.
>
> call directing code: last four characters of a callsign, or ZCZC (selects everyone).
>
> end of address code: CR CR LF. Detection of CR CR or CR LF should be sufficient to put unselected machines into the non-select
> state. For reasons discussed below, Figs H must also be interpreted as an end-of-address code.
>
> end of message code: NNNN. Detection of NNN should be sufficient to put a selected machine into the non-select state.
>
> 6) If the above definitions are used, the WRU function can be:
> 12 Ltrs, 5 SP, CR CR LF Ltrs K Figs 3 Ltrs N A Figs H Ltrs (drop carrier).
> This uses the conditioning code, CDC, and Figs-H as a WRU/end-of-address code. For the called station, Figs-H triggers the WRU
> response. For the other stations, Figs-H places their machines in the non-select state because their CDC did not immediately
> precede the Figs H.
>
> As I recall, in the Model 28 world the WRU response was generated by a drum encoded with the response. I don't remember the
> number of characters available on the drum, but it should be enough to send some number of Ltrs, CR CR LF DE [callsign]. The drum
> clicked on right away after Figs-H was received.
>
> ========
>
> Of course all of this can be imitated by computers or other electronic controllers. I detect that one of the desires of the
> community is to use sequences which can be handled by traditional machines as well, which is why I made the above suggestions.
>
> -- Eric K3NA
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Roy Norris
> Sent: 2004 April 26 00:58
> To: [email protected]
> Subject: [GreenKeys] WRU and SELCAL
>
>
>
> I have been searching the internet and old issues of RTTY Journal
> looking for suitable designs for a WRU (answerback) and SELCAL design
> that would serve our purposes for an auto start net. While this could
> be done on a PC, my thought is that most would not want to keep a PC
> running continuously to provide that function. WRU and SELCAL functions
> can be provided in a model 28 stunt box arrangement however that
> approach would require leaving the TTY machine on or the use of an
> analog/TU based autostart which are notoriously sensitive to false
> triggers by noise or off frequency signals and carriers.
>
> It seems to me that an ideal solution would be an external,
> microcontroller based box connected to the TU via an RS-232 port that
> would provide the following functions:
>
> 1. PROVIDE DIGITAL AUTOSTART. - monitor the RS-232 output of the
> TU and when a valid digital signal is present, close a relay that would
> turn on the teletype machine. Turn off the teletype machine when an
> "NNNN" is detected.
> 2. PROVIDE WRU CAPABILITY - monitor the RS-232 output of the TU and
> when either the sequence "ZCZC" or (callsign)ZW was received, close a
> relay which would key the push-to-talk switch on a transceiver and send
> the following string to the TU
> : " (20 diddles)(CR)(CR)(LF)(LF)(LTRS)(LTRS) DE (Callsign), (name),
> in (location) (CR)(CR)(LF)(LF)(LTRS) NNNNN (CR)(CR)(LF)(LF)(LTRS)",
> followed by turning off the relay which had activated the
> push-to-talk switch.
> 3. PROVIDE MULTIPLE SELCAL - monitor the RS-232 output of the TU
> and when any of several individually selectable code sequences were
> received, close a relay that turns on the teletype machine.
> Monitor for "NNNN" and turn off the relay that operates the TTY machine
> when received. Codes would include a) ones for receiving a message
> directed at that particular station (possibly use the station callsign
> as a selcal trigger). b) a code for receiving bullitiens c) a code for
> receiving "all-calls".. Each code would be individually activated by a
> front panel switch so that an operator could choose to receive or not
> receive messages addressed to his station, messages that were bulletins,
> messages that were "all-calls".
>
> All of this capability has been incorporated in various devices in the
> past so there is nothing new here. I don't recall seeing it available
> all in one external unit.
>
> IIt would be wonderful if this capability could be incorporated in the
> TTY Connect project currently underway by Gil Smith. I believe he has
> made provisions for an optional microcontroller on the board he is
> developing but I am not sure the board is designed so that it could
> provide these functions. (What say, Gil??) Alternative, a small
> inexpensive stand alone box could be designed using a microcontroller.
> If there is anyone on GreenKeys that has the necessary skills and would
> be willing to undertake the project, please speak up.
>
> Alternatively, I will try and do it myself, although it has been 20
> years since I did any programming of this nature and it was on 8085
> computers, not microcontrollers. But I guess I could get back up to
> speed in a couple of months. It would be tremendously helpful if I
> could locate any of IRV Hoff's source code for his RMON program or his
> standard teletype program that was use on the 20 meter autostart
> frequency of 14.0875 Mhz. Does anyone on the list have this or have an
> idea of where I might find it??
>
> I have looked at the aforementioned RTTY12 program. It is written in
> Basic and has selcal but no WRU that I can find. Irv Hoff's code would
> be the best if we can find it. I hate that I threw away my copies some
> years ago.
>
> Thoughts? Suggestiohns ?? Ideas, pro and con ??
>
> Best regards - Roy Norris, K4EEG
>
>
> --- StripMime Report -- processed MIME parts ---
> multipart/alternative
> text/plain (text body -- kept)
> text/html
> The reason this message is shown is because the post was in HTML
> or had an attachment. Attachments are not allowed. To learn how
> to post in Plain-Text go to: http://www.expita.com/nomime.html ---
> _______________________________________________
> GreenKeys mailing list
> [email protected]
> http://mailman.qth.net/mailman/listinfo/greenkeys
>
>
>
>
>