FOR INFO Mine resets to 1st call also! Ken.. G0ORH
Sent from my iPad > On 8 Dec 2019, at 04:58, Jon Anhold <j...@anhold.com> wrote: > > 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.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
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
