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
