[GreenKeys] WRU and SELCAL

Tue, 27 Apr 2004 18:43:32 -0400

Hi

A couple of points to clarify between this and the pic software thread.

1) Use ZCZC as the "printer on" code just like you mention below. In 
the stunt box the printer motor is already on. In the pic version this 
turns on the motor. If we have a cpu let's use it to avoid false motor 
cycles.

2) Use QST for the bulletin code. That way it can be directed to a 
specific printer or what ever. At least you can sort things out.

3) Come up with an explicit "end of transmission" code. NNN or NNNN is 
commonly used as a message separator. End of transmission does not make 
a lot of sense in a rag chew environment but it's a good thing at the 
end of a set of bulletins.  In a PIC driven system this would let us 
only have the motor on between when we get a ZCZC and a what ever code.

If we have the QST in all the transmissions and it won't fit in a 
particular stunt box then the ZCZC code would at least lock out weird 
stuff. If the stunt box ignores the end of transmission code then the 
motor will simply time out after carrier drop.

	Take Care!

		Bob Camp

On Apr 27, 2004, at 10:44 AM, Eric Scace K3NA wrote:

> Bob --
>
>    My suggestion is to use "ZCZC" as the four-character code for all 
> bulletins deemed by the sender to be of general interest.  The
> ZCZC sequence is already at the start of ARRL bulletins, so it makes 
> it somewhat easier to prepare them.  (I haven't checked to see
> if the 5 SP 2CR 1LF sequence is present before ZCZC; if not, it would 
> be easy enough to send.)  If someone else has a message of
> general interest, it can be sent with ZCZC.  If someone is felt to be 
> abusing the ZCZC general call, a little social engineering
> should be adequate to address the problem.
>
>    As you pointed out, we don't want too many selector sequences 
> because there is a limit which can fit into stunt boxes.  If one
> used all the features suggested by my previous message, one would have:
>   3 SP CR - conditioning code.
>   ZCZC - turns on printer.
>   last 4 characters of your call - turns on printer.
>   last 4 characters followed by Figs H - turns on WRU.  (I think this 
> just requires function bars for the Figs H with the correct
> pawls and such; one doesn't need to encode the last 4 characters of 
> the call again if one is clever).
>   CR LF - end of address code.
>   NNN - end of message code.
>
>    That seems like enough to get started.  Fortunately, a lot of these 
> sequences are standard so one might find parts already
> available for them.
>
> -- Eric K3NA
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Bob Camp
> Sent: 2004 April 27 08:15
> To: [email protected]
> Cc: [email protected]; [email protected]; greenkeys List
> Subject: Re: [GreenKeys] WRU and SELCAL
>
>
> Hi
>
> There are two ends to the mechanical compatibility issue. One is on the
> sending end the other is on the receiving end. I agree totally with the
> idea that the receiving end needs to be mechanical compatible. On the
> sending end I guess I have always assumed that you would punch up a
> tape with what ever you need to fire things up on it. You could come up
> with some kind of mechanical robot to do it all but that sounds like a
> bit more work that it's worth. I don't remember any "real world" gear
> out there that did the send end of the setup without using a tape. Of
> course that may not mean a lot ....
>
> If we go feature nuts on the sending end it just adds stuff to a tape.
> If we go feature nuts on the receiving end that fills up stunt boxes
> and it's a problem. I'm not really suggesting that we go feature nuts,
> only that we need to look at which end of the process is impacted by a
> given feature.
>
> Here's an example: Maybe I'm into propagation forecasts. After a bit of
> yack it turns out that there are others who have the same interest. Up
> goes Bob's daily propagation forecast. I can send a long string of
> SELCAL's (one for each guy who wants a copy) -or- I can send it blind
> and you have to copy everything to get it -or- we can invent a unique
> SELCAL for the thing.
>
> All three approaches work. The first one with a long chain of call
> signs is a pain to administer but it makes the receiving end of things
> easy. The second approach also works and it's very simple, it just uses
> a lot of paper. The third approach makes things like stunt boxes fill
> up with extra parts.
>
> If everybody invents a new "bulletin" SELCAL then we need stunt boxes
> the size of a small car to keep up with everything.
>
> In this case here's what I would suggest. Add a single feature - a
> bulletin SELCAL. That way you can reasonably decide to get the
> bulletins but not copy everything on the whole net. If we make it
> something simple it should still fit in a more or less normal stunt
> box. If we follow the bulletin SELCAL with a bulletin specific tag then
> people with fancy setups can get more selective about which bulletins
> to accept. In other words you keep the "feature" simple enough to work
> on the receiving end and add a little to the sending end to do give us
> full functionality.
>
> I hope that makes some sort of sense. I'm not really going to get into
> the propagation  bulletin business but it is a reasonable example.
> Bulletins make good things for adjustment and test of setups. I think
> they are something we want to encourage. I also think we want to do it
> as simply as we can. I think we can come up with a pretty darn simple
> system that also is very flexible if we work it out in advance. Tearing
> into stunt boxes on a regular basis isn't a real good idea. There are
> only just so many selector bars left in the world ....
>
> 	Enjoy!
>
> 		Bob  Camp
> 		KB8TQ
>
>
> _______________________________________________
> GreenKeys mailing list
> [email protected]
> http://mailman.qth.net/mailman/listinfo/greenkeys
>