Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RTTY\]\s+The\s+RTTY\s+efficiency\s+myth\s+and\s+SUPERFILL\s*$/: 23 ]

Total 23 documents matching your query.

1. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: Tim Shoppa <tshoppa@gmail.com>
Date: Wed, 16 Jul 2014 12:42:29 -0400
In a real RTTY contest, the "PLEASE COPY" is surprisingly rare. (It was pretty common on field day, which thank God is not an actual contest!) More common in real RTTY contests, are long preambles of
/archives//html/RTTY/2014-07/msg00044.html (8,012 bytes)

2. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: Jeff Stai <wk6i.jeff@gmail.com>
Date: Wed, 16 Jul 2014 11:32:51 -0700
I'll just make one fill button for each variable, that sends it two or three times. 90% of the time that's enough for the conditions. If I need to send more I just tap the same button two or three ti
/archives//html/RTTY/2014-07/msg00045.html (8,185 bytes)

3. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: john <w8wej@citynet.net>
Date: Wed, 16 Jul 2014 22:24:16 +0000
with great reluctance,,, I was going to eliminate the "TU" in the exchange--I have always felt, and still feel that the rtty bunch is the nicest group of competitors that I have ever encountered, and
/archives//html/RTTY/2014-07/msg00047.html (10,990 bytes)

4. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: Dave Greig <daven3buo@att.net>
Date: Wed, 16 Jul 2014 17:26:28 -0500
John I also send TU in contests for the same reason. Thank You! Dave Greig N3BUO *801 Tactical* Phone: (682) 422-6667 http://www.801tactical.com Google Plus: gplus.to/801Tactical Facebook: https://ww
/archives//html/RTTY/2014-07/msg00048.html (12,630 bytes)

5. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: Hank Garretson <w6sx@arrl.net>
Date: Wed, 16 Jul 2014 15:38:52 -0700
Absolutely. Keep the TU. Indeed, TU is equivalent to QSL. CQ TEST W6SX W6SX CQ P40X P40X 599 03 W6SX 599 P40X TU W6SX CQ My TU to P40X says Thank You AND QSL, the contact is complete. Keep the TU. Co
/archives//html/RTTY/2014-07/msg00049.html (9,384 bytes)

6. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: "Jeff AC0C" <keepwalking188@ac0c.com>
Date: Wed, 16 Jul 2014 17:52:26 -0500
I'm confused; is someone advocating dropping the TU? Most guys use it. And from a S&P rate standpoint, it's very helpful for the run station to lead with that TU - as it let's the S&P caller know he'
/archives//html/RTTY/2014-07/msg00051.html (11,815 bytes)

7. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: Bill Turner <dezrat@outlook.com>
Date: Wed, 16 Jul 2014 16:28:56 -0700
ORIGINAL MESSAGE: (may be snipped) REPLY: Leading with the TU could cause problems when there are two stations that both think they are the one you are working. If they both see the TU and take off,
/archives//html/RTTY/2014-07/msg00052.html (8,219 bytes)

8. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: "Jeff AC0C" <keepwalking188@ac0c.com>
Date: Wed, 16 Jul 2014 20:29:37 -0500
Bill, You are correct. That was my meaning but got in a rush to type the reply. 73/jeff/ac0c www.ac0c.com alpha-charlie-zero-charlie ORIGINAL MESSAGE: (may be snipped) REPLY: Leading with the TU coul
/archives//html/RTTY/2014-07/msg00053.html (9,136 bytes)

9. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: "Ian White" <gm3sek@ifwtech.co.uk>
Date: Thu, 17 Jul 2014 11:06:56 +0100
Absolutely! A QSO is not complete until BOTH stations have received an acknowledgement of the information they have sent - which means that the run station must <send> that final acknowledgement befo
/archives//html/RTTY/2014-07/msg00054.html (9,241 bytes)

10. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: "john@kk9a.com" <john@kk9a.com>
Date: Thu, 17 Jul 2014 06:25:08 -0500
Efficiency is a good thing however rather than eliminate the TU, QSL or other form of acknowledgment, I would eliminate sending the callsign of the station that you are working. Sending P40X before T
/archives//html/RTTY/2014-07/msg00055.html (10,327 bytes)

11. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: Bill Turner <dezrat@outlook.com>
Date: Thu, 17 Jul 2014 05:44:55 -0700
ORIGINAL MESSAGE: (may be snipped) On 7/17/2014 4:25 AM, john@kk9a.com wrote: I would eliminate sending the callsign of the station that you are working. Sending P40X before TU W6SX serves no purpose
/archives//html/RTTY/2014-07/msg00056.html (9,034 bytes)

12. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: "Ian White" <gm3sek@ifwtech.co.uk>
Date: Thu, 17 Jul 2014 14:28:45 +0100
no just spinning the than you This unending debate between 'speed' and 'security' is why advanced operators are moving towards modular messages that can be optimized on the fly. Program the default
/archives//html/RTTY/2014-07/msg00057.html (10,000 bytes)

13. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: "Ed Muns" <ed@w0yk.com>
Date: Thu, 17 Jul 2014 06:36:23 -0700
My QSL message is typically: TU W0YK CQ If I have stacked call signs, it is: W6WRT TU, NW KK9A 599 03 In the first case, I've opted to trade-off a few cases of confusion for far more cases of a short
/archives//html/RTTY/2014-07/msg00058.html (10,517 bytes)

14. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: "John L Merrill" <johnn1jm@gmail.com>
Date: Thu, 17 Jul 2014 06:44:15 -0700
.......and please send the signal report if required :-)!!! John N1JM Absolutely! A QSO is not complete until BOTH stations have received an acknowledgement of the information they have sent - which
/archives//html/RTTY/2014-07/msg00059.html (10,586 bytes)

15. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: Hank Garretson <w6sx@arrl.net>
Date: Thu, 17 Jul 2014 07:24:39 -0700
There are many ways to skin a cat. Below is an piece I wrote for National Contest Journal (November/December 2013). My most important point is the W6SX Prime Directive: The first rule of contesting i
/archives//html/RTTY/2014-07/msg00062.html (18,616 bytes)

16. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: "john@kk9a.com" <john@kk9a.com>
Date: Thu, 17 Jul 2014 11:20:39 -0500
Just to be clear, Since the original post was regarding dropping TU from the acknowledgement, I suggested not sending the callsign in the last line of W6SX's example and only sending TU W6SX CQ. Of c
/archives//html/RTTY/2014-07/msg00064.html (10,018 bytes)

17. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: "David G3YYD" <g3yyd@btinternet.com>
Date: Thu, 17 Jul 2014 12:31:44 -0500
The messages when running are interesting. I normally use HISCALL 599001 001 HISCALL. The reasoning is as follows. If I am working through a number of stations calling then often the first call sent
/archives//html/RTTY/2014-07/msg00065.html (10,635 bytes)

18. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: Jeff Stai <wk6i.jeff@gmail.com>
Date: Thu, 17 Jul 2014 09:44:13 -0700
I agree with everything (though the casual contester we all rely on may not have clued in to TOO) but... 599 001 001 We like to click on the exchanges - 599001 means you have to type it when the seco
/archives//html/RTTY/2014-07/msg00066.html (9,900 bytes)

19. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: "David G3YYD" <g3yyd@btinternet.com>
Date: Thu, 17 Jul 2014 14:58:10 -0500
Jeff If you use N1MM then N2AMG is very nifty with the programming. Click on 599001 when on the exchange window guess what no 599 appears... It is even clever on processing time exchange used for the
/archives//html/RTTY/2014-07/msg00069.html (10,495 bytes)

20. Re: [RTTY] The RTTY efficiency myth and SUPERFILL (score: 1)
Author: Robert Chudek - K0RC <k0rc@citlink.net>
Date: Thu, 17 Jul 2014 14:22:05 -0500
/"//This selfish practice can easily be stamped out by working those individuals but not logging the QSO."/ If I were a contest adjudicator and detected this practice, I would DQ the operator (the on
/archives//html/RTTY/2014-07/msg00072.html (11,587 bytes)


This search system is powered by Namazu