You guys say "Just don't use Call 1st" - well, in a contest this can destroy your rate (see below).
Now, I'm not blaming or shaming WA3EKL - I think maybe his software got wedged somehow - it happens to the best of us. When this happens, at least in RTTY Roundup mode, it keeps answering even if I uncheck "Call 1st" and when I re-enable TX, Call 1st keeps getting checked automatically. Some way to lockout a dupe that keeps calling is a good idea. 73 de KM8V [image: image.png] On Wed, Dec 4, 2019 at 6:22 AM Martin Davies G0HDB <marting0...@gmail.com> wrote: > On 3 Dec 2019 at 22:10, Eric Spero via wsjt-devel wrote: > > > Amazing how those who don't see a need for a new option have their > > opinions and reflect only a view from their use of the software. Again, > > we need to think and view this issue from the operator's point of view > > that is located in remote DX wanted locations, and end up in a pile-up. > > If the operator of a station in a remote or 'interesting' location is > seeing a large pile-up of > callers developing then perhaps the operator should consider switching to > using WSJT-X's > DXpedition Fox & Hounds mode, which already provides a queuing capability; > F & H mode > also *requires* the operator of the Fox station to select which of the > Hound callers listed in > the 'Stations calling DXpedition' window to move into the QSO queue. This > puts the onus on > the Fox operator to make decisions about which Hounds to have a QSO with, > which is what > the advocates of the 'callsign lockout' function seem to be unwilling or > incapable of doing for > themselves through their use of the 'Call 1st' function. > > > Mostly these stations are getting calls from others not calling CQ > > themselves. These users have many reasons why a call blocking option is > > a good idea. Many of you will not experience a true pile-up including > > myself, operating from our stateside locations in the US mainland. I > > spoke with one ham who I know and lives in AK who gets inundated with > > hams blind calling him, because he gets reported on a spotting system. > > He gets what he calls " blind calling " from stations who want to get > > his DX. What happens, stations will call him and they can't hear him, > > hoping to be logged, some of them keep calling and calling and sending > > false reports like TX3 or TX4 hoping he will log them. WSJT-X will keep > > putting that call sign in the TX window for your reply back with an > > automatic response, for them, interrupting the QSO in progress, which > > again is only a one-way call they can't hear him. You can't get rid of > > them, from the decoded Q, they keep calling with a report, and even try > > sending RR73. If there was a call blocking "OPTION" yes option, I said, > > you could click on that call sign, and stop them from decoding and > > interrupting the working QSO , for some period of time. > > There is already a perfectly straightforward and easy-to-use option in > 'standard' FT8 for > ignoring a persistent or an unwanted caller - it's called disabling 'Call > 1st' so that WSJT-X > doesn't keep trying to initiate a QSO with the unwanted caller and then > for the *OPERATOR* > to make the decision about whom to have a QSO with and which callsigns to > ignore. It's > really not that difficult at all, and should easily be within the > capabilities of even an > inexperienced operator. There's absolutely no need whatsoever for a > function that provides > users of the 'Call 1st' function, who for whatever reason insist on having > it enabled even > when it's unnecessary, with the ability to 'lock out' what they deem to be > an unwanted caller. > > No-one is *obliged* to have a QSO with anyone who might be calling them > and in most (all?) > scenarios it should be entirely up to the operator to decide who their QSO > partner will be; > using 'Call 1st' takes this control completely away from the operator and > the proposed > 'callsign lockout' function is simply a kludge to facilitate lazy > operating practices. > > As for persistent or unwanted callers, eg. those in EU who almost > inevitably respond to my > directional 'CQ DX' calls, I just completely ignore them or occasionally > resort to sending a > free-text Tx5 message along the lines of 'CQ DX NOT EU'. > > Lest anyone decide to deem me a 'casual' user without experience of busy > conditions, on > occasions I've operated as the wanted station (which is surprising for a G > callsign!) in > mini-pileup conditions and have had up to maybe five or six stations > calling me in each 15sec > timeslot. In such scenarios I always operate with 'Call 1st' disabled so > that *I* can select > which of the callers to initiate a QSO with, and I've never experienced > any difficulties in doing > so, although it can take a couple of seconds or so to decide which of the > list of callers in the > 'Rx frequency' window to double-click on to start the QSO. > > > I want to make a point, what is wrong with options to improve the > > operations of our ham software? Some of you are making new options or > > changes that can improve the operations as being a bad thing. If you as > > a user don't want to use a let's say " blocking option ", don't use it. > > If the developers Joe, Steve, and Bill, feel it is helpful to the DX > > operations, and the F/H mode, and they decide to add this option or any > > other, then it should be fine for all of us, if it is not helpful for > > your station operations, then don't use it. I would think the only hams > > who would object to a call sign blocking as a option is maybe a ham who > > might be blocked someday? If that was the case, just move on to the next > > station who will want to work you, it's not that important, remember its > > only one QSO! > > I'm all in favour of new functions and options for WSJT-X being proposed > and discussed > when there's a clear and widely-accepted need for a capability that > doesn't already exist, but > this isn't the case for the 'callsign lockout' function. As has already > been explained ad > nauseam, what the proponents of 'callsign lockout' appear to want already > exists - all it needs > is for an operator to use their own judgement and capabilities rather than > relying on the > software to decide who to have a QSO with. If you want to go down the > automation route, > and from all the evidence the WSJT-X developers definitely don't, then > anyone who wants to > relinquish control of their QSO-making almost entirely to the software > should perhaps > consider using something other than the WSJT-X software, which is designed > to require > some operator involvement and skill... > > --- > Martin, G0HDB > > > > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel >
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
