Re: [wsjt-devel] Callsign lockout

[Ken Chandler]

FOR INFO
Mine resets to 1st call also!

Ken.. G0ORH

Sent from my iPad


> On 8 Dec 2019, at 04:58, Jon Anhold  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
> 
> 
> 
> 
>> On Wed, Dec 4, 2019 at 6:22 AM Martin Davies G0HDB  
>> 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 init

Re: [wsjt-devel] Callsign lockout

[Jon Anhold]

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 
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 th

Re: [wsjt-devel] Callsign lockout

[Martin Davies G0HDB]

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 t

Re: [wsjt-devel] Callsign lockout

[Zeev Stadler]

Agreed.

In addition, as a CQ caller, you have no control over the order in which
WSJT-X decoded the received calls and who's first.

AFAIK, the "persistent" caller can remain 1st if he calls on a frequency
lower than the other callers and the signal is strong enough to be decoded
on the first pass...

I also fail to understand the objections to this feature request. Using the
feature is completely optional and no operational change is required by
anyone who doesn't need it. On the other hand, in this long discussion I
have not seen alternative solutions for the problematic scenarios describes
by the supporters of the proposal.

73
Zeev
4X5ZS

On Wed, Dec 4, 2019 at 7:42 AM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> It's not a lockout file.
>
> The idea is very simple.
>
> Right now call first always picks the 1st decode...ergo the problem
>
> So the idea is that once a call is worked it gets put in a list (doesn't
> matter whether or not you log it).  The call first logic checks the list
> and ignores anybody in it.
> If call first does not trigger then the 1st entry that was detected would
> be used.
> So it would all be completely transparent, only temporarily blocks calls,
> and clears itself.
>
> If you have 5 people calling you it will go 1,2,3,4,5 and start over again
> whereas right now it's 1,1,1,1,1, ad nauseum.
>
> For the most part nobody would even notice this was happening except the
> 1st decode may not be the one chosen.
>
> de Mike W9MDB
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Tom Melvin]

Just another view on this - last night there was a UK contest - despite it 
being a ‘Normal’ mode contest a pile of people were using ‘EU Contest mode’. 
What was noticeable, yes WSJT switched modes to follow but in many cases while 
switching you ‘lost’ the report.

While the system went on to sent RR73 etc. and log the contact - it was not 
complete - so stations had to call again.  If there was yet another option to 
remember to switch off/on and both ends needing to recognise the need if one 
was ‘hidden’ 

Nope sorry leave it up to the operator.

Tom

P.S.   I could see on a QUIET band there would be benefit of suppressing the 
odd local - glance at screen if activity cool band opening work the band - the 
local 5 miles away (running in robot mode) makes it not that easy. Thankfully 
JTAlert can limit by distance but that is Windows only.  You would need to make 
sure the entries fully supported ‘wildcards’.

--
73’s

Tom
GM8MJV (IO85)





On 4 Dec 2019, at 05:37, Black Michael via wsjt-devel 
 wrote:

> It's not a lockout file.
> 
> The idea is very simple.
> 
> Right now call first always picks the 1st decode...ergo the problem
> 
> So the idea is that once a call is worked it gets put in a list (doesn't 
> matter whether or not you log it).  The call first logic checks the list and 
> ignores anybody in it.
> If call first does not trigger then the 1st entry that was detected would be 
> used.
> So it would all be completely transparent, only temporarily blocks calls, and 
> clears itself.
> 
> If you have 5 people calling you it will go 1,2,3,4,5 and start over again 
> whereas right now it's 1,1,1,1,1, ad nauseum.
> 
> For the most part nobody would even notice this was happening except the 1st 
> decode may not be the one chosen.
> 
> de Mike W9MDB
> 
> 
> 
> 
> On Tuesday, December 3, 2019, 11:28:30 PM CST, Jim Brown 
>  wrote:
> 
> 
> W9MDB wrote:
> 
> > I'm all ears for opinions from operators who have had a call pileup on them.
> 
> I've been a ham since 1955, General in '56, Extra '59. I've always been 
> primarily a CW op, mostly contesting and chasing DX. I've been the guy 
> on the DX end of pileups working CW in a major contest, no split 
> operation. I also work RTTY contests as part of a club that often wins 
> them. So far, I've not gotten interested in FT4/FT8 contesting on HF.
> 
> I'm near San Francisco and have a very good station. I use FT8 
> extensively on 160M during the winter to work EU, and both FT8 and 
> MSK144 on 6M chasing grids. I rarely call CQ, mostly tail-ending 
> stations I want to work, just as Dave does. That's smart operating.
> 
> The craziest I've seen FT8 is when 6M is open to JA, often with 
> JTAlert's 4x9 display nearly full of decodes. By far the best way to 
> work it is to call CQ with Call First off, Auto Seq on, Hold TX Freq on, 
> and pick the station I want to respond to.
> 
> As to this lockout thing -- IMO, the nuisance calls come from new folks 
> who have little HF experience, have massive receive noise, and never 
> realize the band is open for DX, only look at JTAlert, and are calling 
> the only signals strong enough to get through their noise. A library of 
> lockout calls is quite unlikely to work, because it's different new 
> folks every time! Indeed, those JA openings are almost the only time I 
> call CQ, and for that reason! The only folks I want calling me are the 
> DX I want to work, and I don't want guys who can't hear or don't have a 
> clue covering them up!
> 
> 73, Jim K9YC
> 
> 
> 
> ___
> 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

Re: [wsjt-devel] Callsign lockout

[Black Michael via wsjt-devel]

It's not a lockout file.
The idea is very simple.
Right now call first always picks the 1st decode...ergo the problem
So the idea is that once a call is worked it gets put in a list (doesn't matter 
whether or not you log it).  The call first logic checks the list and ignores 
anybody in it.If call first does not trigger then the 1st entry that was 
detected would be used.So it would all be completely transparent, only 
temporarily blocks calls, and clears itself.
If you have 5 people calling you it will go 1,2,3,4,5 and start over again 
whereas right now it's 1,1,1,1,1, ad nauseum.
For the most part nobody would even notice this was happening except the 1st 
decode may not be the one chosen.
de Mike W9MDB

 

On Tuesday, December 3, 2019, 11:28:30 PM CST, Jim Brown 
 wrote:  
 
 W9MDB wrote:

> I'm all ears for opinions from operators who have had a call pileup on them.

I've been a ham since 1955, General in '56, Extra '59. I've always been 
primarily a CW op, mostly contesting and chasing DX. I've been the guy 
on the DX end of pileups working CW in a major contest, no split 
operation. I also work RTTY contests as part of a club that often wins 
them. So far, I've not gotten interested in FT4/FT8 contesting on HF.

I'm near San Francisco and have a very good station. I use FT8 
extensively on 160M during the winter to work EU, and both FT8 and 
MSK144 on 6M chasing grids. I rarely call CQ, mostly tail-ending 
stations I want to work, just as Dave does. That's smart operating.

The craziest I've seen FT8 is when 6M is open to JA, often with 
JTAlert's 4x9 display nearly full of decodes. By far the best way to 
work it is to call CQ with Call First off, Auto Seq on, Hold TX Freq on, 
and pick the station I want to respond to.

As to this lockout thing -- IMO, the nuisance calls come from new folks 
who have little HF experience, have massive receive noise, and never 
realize the band is open for DX, only look at JTAlert, and are calling 
the only signals strong enough to get through their noise. A library of 
lockout calls is quite unlikely to work, because it's different new 
folks every time! Indeed, those JA openings are almost the only time I 
call CQ, and for that reason! The only folks I want calling me are the 
DX I want to work, and I don't want guys who can't hear or don't have a 
clue covering them up!

73, Jim K9YC


___
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

Re: [wsjt-devel] Callsign lockout

[Jim Brown]

W9MDB wrote:


I'm all ears for opinions from operators who have had a call pileup on them.


I've been a ham since 1955, General in '56, Extra '59. I've always been 
primarily a CW op, mostly contesting and chasing DX. I've been the guy 
on the DX end of pileups working CW in a major contest, no split 
operation. I also work RTTY contests as part of a club that often wins 
them. So far, I've not gotten interested in FT4/FT8 contesting on HF.


I'm near San Francisco and have a very good station. I use FT8 
extensively on 160M during the winter to work EU, and both FT8 and 
MSK144 on 6M chasing grids. I rarely call CQ, mostly tail-ending 
stations I want to work, just as Dave does. That's smart operating.


The craziest I've seen FT8 is when 6M is open to JA, often with 
JTAlert's 4x9 display nearly full of decodes. By far the best way to 
work it is to call CQ with Call First off, Auto Seq on, Hold TX Freq on, 
and pick the station I want to respond to.


As to this lockout thing -- IMO, the nuisance calls come from new folks 
who have little HF experience, have massive receive noise, and never 
realize the band is open for DX, only look at JTAlert, and are calling 
the only signals strong enough to get through their noise. A library of 
lockout calls is quite unlikely to work, because it's different new 
folks every time! Indeed, those JA openings are almost the only time I 
call CQ, and for that reason! The only folks I want calling me are the 
DX I want to work, and I don't want guys who can't hear or don't have a 
clue covering them up!


73, Jim K9YC


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Eric Spero via wsjt-devel]

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. 
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.


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!


As Mike said ears for the opinions from those hams who have lived in a 
pile-up at their location with the WSJT-X modes.

73
Eric/WA1SXK

On 12/2/2019 4:52 PM, Black Michael via wsjt-devel wrote:
I'm all ears for opinions from operators who have had a call pileup on 
them.


If Call 1st is to be implemented at all it should be robust.

It's a trivial patch which I'll make myself and submit for 
consideration in WSJT-X.


de Mike W9MDB



___
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

Re: [wsjt-devel] Callsign lockout

[Ron WV4P]

David,

As I suspected you are a casual user, hence why you are not able to
comprehend the benefits. For Comparison, since you brought it up..Many
weeks I was doing 1500 + Q's  in FT-8 only last year during the grid chase.
I was on the FT-4 Alpha Test Team and I won First Place World in the last
FT Roundup. Now that we got the dick measuring out of the way, please try
to understand that there many different types of users and features that
would be of great benefit to some may be useless to others. Your continued
attempt to belittle people because YOU don't see a use in something has run
it's course. Much the same as you stated Over and Over in respect to Call
First, if we can get this much needed and much wanted feature, you do NOT
have to use it. It will have Zero effect on you. Have a great evening OM.
Ron, WV4P

PS
Maybe spend your time Uploading to LOTW so people can get credit for the
2000 Q's you have made, I'm sure they would appreciate it and it would have
more benefit than lobbying against something that does not effect you.

On Tue, 3 Dec 2019 at 16:36, David Gilbert  wrote:

>
> Not so.  Any of it.
>
> I've made over 2,000 FT8/FT4 contacts (over 130 countries) in about three
> months time and the only ones that weren't DX were the ones that called
> me.  I tail end DX stations for many of my contacts, but when I call CQ DX
> I have zero problem ignoring the persistent stateside stations that often
> call me.
>
> Those unwanted stations calling you aren't "QRM'ing" your ability to
> receive either.  That is simply in your imagination.  And if they are
> calling you on your transmit frequency they aren't very smart anyway, and
> you blocking them from showing up in the Activity window isn't going to do
> a thing to keep them from transmitting there.  How can you not understand
> that?   Most of the more experienced stations, like the ones likely to be
> in a contest, are going to lock their transmit frequency and won't be on
> the same frequency.
>
> I'm not telling you not to use "Call 1st".  I'm only saying that your
> insistence on doing so is the root of your imaginary problem, not the fact
> that there isn't the capability in the software to blacklist a callsign.  I
> guarantee that I can make more QSOs in a given period of time by not
> spending time blacklisting callsigns that are more easily ignored.
>
> There is no wild tangent here.  I'm simply directly responding to a
> proposal you've made that makes no sense, and you've been using arguments
> that don't make technical sense either.
>
> Dave   AB7E
>
>
> On 12/3/2019 11:54 AM, Ron WV4P wrote:
>
> Dave, with all due respect, maybe you need to read the thread again... You
> are going off on wild tangents in your attempt to discredit and trash talk
> every operator you can.
> The Reason this is needed is to block Lids from tripping Call First, and
> or to prevent them from calling you at all. Maybe a casual user will never
> experience these issues, as I suspect you are. More advanced users,
> especially those contesting or primarily interested in DX need a way to
> filter calls. As more and more people with different experience and IQ
> levels use the FT Modes the problems get worse and worse. When using a
> Directional CQ and the same users over and over QRM you, a way to deal with
> that should be present. They are taking away from your time and enjoyment.
> If I want to call CQ on the Greyline to Asia I should have that right...
> But I will, 100% of the time be QRM'd by USA callers answering my
> Directional CQ. Both in Contesting and Directional CQ's "Call First" is a
> very important tool that stacks the odds in your favor of completing a
> QSO... If you choose not to use it, that's your prerogative, but, Please,
> do not tell me not to use it, nor what features could also make the
> experience better. Ron, WV4P
>
> On Tue, 3 Dec 2019 at 12:37, David Gilbert 
> wrote:
>
>>
>> The point is that you said you needed a block to prevent the impact of an
>> unwanted caller on your receiver.  You just made that up.
>>
>> The program was designed to require you to actually be an operator, which
>> is why you have to enable each QSO instead of it being fully robotic.
>> "Call 1st" is merely a crutch for those of us who may not have the reflexes
>> to select a new caller within the first 2 seconds of the next frame.  I
>> sincerely doubt its primary purpose was to remove all thought process from
>> making QSOs.
>>
>> In order to achieve such significant weak signal performance certain
>> rigid operating constraints are inherently necessary.  The requirement for
>> locked time windows, predetermined message format, and fixed coding schemes
>> are there to facilitate the weak signal result.  In order to mitigate that
>> rigidity certain "automation" features exist in the application ... such as
>> "Call 1st", "odd/even", and having TX Enable locked to the beginning of a
>> time frame.  I'm pretty sure they weren't put there to remove the need

Re: [wsjt-devel] Callsign lockout

[David Gilbert]

Not so.  Any of it.

I've made over 2,000 FT8/FT4 contacts (over 130 countries) in about 
three months time and the only ones that weren't DX were the ones that 
called me.  I tail end DX stations for many of my contacts, but when I 
call CQ DX I have zero problem ignoring the persistent stateside 
stations that often call me.


Those unwanted stations calling you aren't "QRM'ing" your ability to 
receive either.  That is simply in your imagination.  And if they are 
calling you on your transmit frequency they aren't very smart anyway, 
and you blocking them from showing up in the Activity window isn't going 
to do a thing to keep them from transmitting there.  How can you not 
understand that?   Most of the more experienced stations, like the ones 
likely to be in a contest, are going to lock their transmit frequency 
and won't be on the same frequency.


I'm not telling you not to use "Call 1st".  I'm only saying that your 
insistence on doing so is the root of your imaginary problem, not the 
fact that there isn't the capability in the software to blacklist a 
callsign.  I guarantee that I can make more QSOs in a given period of 
time by not spending time blacklisting callsigns that are more easily 
ignored.


There is no wild tangent here.  I'm simply directly responding to a 
proposal you've made that makes no sense, and you've been using 
arguments that don't make technical sense either.


Dave   AB7E


On 12/3/2019 11:54 AM, Ron WV4P wrote:
Dave, with all due respect, maybe you need to read the thread again... 
You are going off on wild tangents in your attempt to discredit and 
trash talk every operator you can.
The Reason this is needed is to block Lids from tripping Call First, 
and or to prevent them from calling you at all. Maybe a casual user 
will never experience these issues, as I suspect you are. More 
advanced users, especially those contesting or primarily interested in 
DX need a way to filter calls. As more and more people with different 
experience and IQ levels use the FT Modes the problems get worse and 
worse. When using a Directional CQ and the same users over and over 
QRM you, a way to deal with that should be present. They are taking 
away from your time and enjoyment. If I want to call CQ on the 
Greyline to Asia I should have that right... But I will, 100% of the 
time be QRM'd by USA callers answering my Directional CQ. Both in 
Contesting and Directional CQ's "Call First" is a very important tool 
that stacks the odds in your favor of completing a QSO... If you 
choose not to use it, that's your prerogative, but, Please, do not 
tell me not to use it, nor what features could also make the 
experience better. Ron, WV4P


On Tue, 3 Dec 2019 at 12:37, David Gilbert > wrote:



The point is that you said you needed a block to prevent the
impact of an unwanted caller on your receiver.  You just made that up.

The program was designed to require you to actually be an
operator, which is why you have to enable each QSO instead of it
being fully robotic.  "Call 1st" is merely a crutch for those of
us who may not have the reflexes to select a new caller within the
first 2 seconds of the next frame.  I sincerely doubt its primary
purpose was to remove all thought process from making QSOs.

In order to achieve such significant weak signal performance
certain rigid operating constraints are inherently necessary.  The
requirement for locked time windows, predetermined message format,
and fixed coding schemes are there to facilitate the weak signal
result.  In order to mitigate that rigidity certain "automation"
features exist in the application ... such as "Call 1st",
"odd/even", and having TX Enable locked to the beginning of a time
frame. I'm pretty sure they weren't put there to remove the need
for functioning brain cells.

Dave   AB7E


On 12/3/2019 10:15 AM, Ron WV4P wrote:

If he's not tripping my Call First so I can use the program as it
was designed, I don't give a damn what he's doing... Ron, WV4P

On Tue, 3 Dec 2019 at 10:51, Gary McDuffie mailto:mcduf...@ag0n.net>> wrote:



> On Dec 2, 2019, at 19:57, Carey Fisher
mailto:careyfis...@gmail.com>> wrote:
>
> That's ridiculous. A "block" wouldn't keep a station from
transmitting, just from being displayed. Can't you just
ignore it?

Exactly.  Blocking your program from showing him won’t do a
thing about the way his signal affects your receiver or how
much spectrum is being used.  It only keeps you from seeing him.

Gary - AG0N

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-d

Re: [wsjt-devel] Callsign lockout

[Jim Brown]

On 12/3/2019 10:11 AM, David Gilbert wrote:

find it ridiculous that people smart enough to get a license


Sadly, too many did nothing more than memorizing answers to multiple 
guess questions, not bothering to study the concepts behind the questions.


73, Jim K9YC


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Ron WV4P]

Dave, with all due respect, maybe you need to read the thread again... You
are going off on wild tangents in your attempt to discredit and trash talk
every operator you can.
The Reason this is needed is to block Lids from tripping Call First, and or
to prevent them from calling you at all. Maybe a casual user will never
experience these issues, as I suspect you are. More advanced users,
especially those contesting or primarily interested in DX need a way to
filter calls. As more and more people with different experience and IQ
levels use the FT Modes the problems get worse and worse. When using a
Directional CQ and the same users over and over QRM you, a way to deal with
that should be present. They are taking away from your time and enjoyment.
If I want to call CQ on the Greyline to Asia I should have that right...
But I will, 100% of the time be QRM'd by USA callers answering my
Directional CQ. Both in Contesting and Directional CQ's "Call First" is a
very important tool that stacks the odds in your favor of completing a
QSO... If you choose not to use it, that's your prerogative, but, Please,
do not tell me not to use it, nor what features could also make the
experience better. Ron, WV4P

On Tue, 3 Dec 2019 at 12:37, David Gilbert  wrote:

>
> The point is that you said you needed a block to prevent the impact of an
> unwanted caller on your receiver.  You just made that up.
>
> The program was designed to require you to actually be an operator, which
> is why you have to enable each QSO instead of it being fully robotic.
> "Call 1st" is merely a crutch for those of us who may not have the reflexes
> to select a new caller within the first 2 seconds of the next frame.  I
> sincerely doubt its primary purpose was to remove all thought process from
> making QSOs.
>
> In order to achieve such significant weak signal performance certain rigid
> operating constraints are inherently necessary.  The requirement for locked
> time windows, predetermined message format, and fixed coding schemes are
> there to facilitate the weak signal result.  In order to mitigate that
> rigidity certain "automation" features exist in the application ... such as
> "Call 1st", "odd/even", and having TX Enable locked to the beginning of a
> time frame.  I'm pretty sure they weren't put there to remove the need for
> functioning brain cells.
>
> Dave   AB7E
>
>
> On 12/3/2019 10:15 AM, Ron WV4P wrote:
>
> If he's not tripping my Call First so I can use the program as it was
> designed, I don't give a damn what he's doing... Ron, WV4P
>
> On Tue, 3 Dec 2019 at 10:51, Gary McDuffie  wrote:
>
>>
>>
>> > On Dec 2, 2019, at 19:57, Carey Fisher  wrote:
>> >
>> > That's ridiculous. A "block" wouldn't keep a station from transmitting,
>> just from being displayed. Can't you just ignore it?
>>
>> Exactly.  Blocking your program from showing him won’t do a thing about
>> the way his signal affects your receiver or how much spectrum is being
>> used.  It only keeps you from seeing him.
>>
>> Gary - AG0N
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>
>
> ___
> wsjt-devel mailing 
> listwsjt-devel@lists.sourceforge.nethttps://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

Re: [wsjt-devel] Callsign lockout

[David Gilbert]

The point is that you said you needed a block to prevent the impact of 
an unwanted caller on your receiver.  You just made that up.


The program was designed to require you to actually be an operator, 
which is why you have to enable each QSO instead of it being fully 
robotic.  "Call 1st" is merely a crutch for those of us who may not have 
the reflexes to select a new caller within the first 2 seconds of the 
next frame.  I sincerely doubt its primary purpose was to remove all 
thought process from making QSOs.


In order to achieve such significant weak signal performance certain 
rigid operating constraints are inherently necessary.  The requirement 
for locked time windows, predetermined message format, and fixed coding 
schemes are there to facilitate the weak signal result.  In order to 
mitigate that rigidity certain "automation" features exist in the 
application ... such as "Call 1st", "odd/even", and having TX Enable 
locked to the beginning of a time frame.  I'm pretty sure they weren't 
put there to remove the need for functioning brain cells.


Dave   AB7E


On 12/3/2019 10:15 AM, Ron WV4P wrote:
If he's not tripping my Call First so I can use the program as it was 
designed, I don't give a damn what he's doing... Ron, WV4P


On Tue, 3 Dec 2019 at 10:51, Gary McDuffie > wrote:




> On Dec 2, 2019, at 19:57, Carey Fisher mailto:careyfis...@gmail.com>> wrote:
>
> That's ridiculous. A "block" wouldn't keep a station from
transmitting, just from being displayed. Can't you just ignore it?

Exactly.  Blocking your program from showing him won’t do a thing
about the way his signal affects your receiver or how much
spectrum is being used.  It only keeps you from seeing him.

Gary - AG0N

___
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

Re: [wsjt-devel] Callsign lockout

[David Gilbert]

That's an absolutely terrible idea unless it was purely an option. When 
I have several callers I queue up the next one in the messages boxes if 
I'm confident the station in QSO is sending me his final 73.  I am then 
able to answer the next station immediately upon conclusion of the QSO 
and I don't miss any time frames.


Having all callers still available in the Band Activity window doesn't 
solve the problem created by your suggestion since during a busy period 
a large portion of them have scrolled up out of the window.  Making me 
scroll back through the Band Activity window to find my callers because 
you can't handle the ones you get is a really bad tradeoff.


I find it ridiculous that people smart enough to get a license can't 
figure out how to choose who they want to work without the software 
doing it for them.


Dave   AB7E



On 12/3/2019 5:56 AM, Andy Durbin wrote:


Not easy to ignore when all callers are displayed in Rx frequency 
window.  A large part of this problem would be fixed by making the RX 
frequency window display only calls on the RX Frequency.


If more complexity is allowed I would propose that:

     When not in QSO any and all callers are displayed in RX freq

     Once a QSO is started then only the station I'm in QSO with is 
displayed in RX freq window (this allows for a change in         QSO 
partner's TX freq.


    When QSO ends go back to displaying all callers.

All callers would still be displayed in Band Activity window so those 
that enjoy multi-tasking can be aware of who is calling.



Andy, k3wyc


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Ron WV4P]

If he's not tripping my Call First so I can use the program as it was
designed, I don't give a damn what he's doing... Ron, WV4P

On Tue, 3 Dec 2019 at 10:51, Gary McDuffie  wrote:

>
>
> > On Dec 2, 2019, at 19:57, Carey Fisher  wrote:
> >
> > That's ridiculous. A "block" wouldn't keep a station from transmitting,
> just from being displayed. Can't you just ignore it?
>
> Exactly.  Blocking your program from showing him won’t do a thing about
> the way his signal affects your receiver or how much spectrum is being
> used.  It only keeps you from seeing him.
>
> Gary - AG0N
>
> ___
> 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

Re: [wsjt-devel] Callsign lockout

[Gary McDuffie]

> On Dec 2, 2019, at 19:57, Carey Fisher  wrote:
> 
> That's ridiculous. A "block" wouldn't keep a station from transmitting, just 
> from being displayed. Can't you just ignore it?

Exactly.  Blocking your program from showing him won’t do a thing about the way 
his signal affects your receiver or how much spectrum is being used.  It only 
keeps you from seeing him.

Gary - AG0N

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Callsign lockout

[Andy Durbin]

"That's ridiculous. A "block" wouldn't keep a station from transmitting,
just from being displayed. Can't you just ignore it?"

Not easy to ignore when all callers are displayed in Rx frequency window.  A 
large part of this problem would be fixed by making the RX frequency window 
display only calls on the RX Frequency.

If more complexity is allowed I would propose that:

 When not in QSO any and all callers are displayed in RX freq

 Once a QSO is started then only the station I'm in QSO with is displayed 
in RX freq window (this allows for a change in QSO partner's TX freq.

When QSO ends go back to displaying all callers.

All callers would still be displayed in Band Activity window so those that 
enjoy multi-tasking can be aware of who is calling.


Andy, k3wyc


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[David Gilbert]

It's pretty difficult to ignore a LID  on CW or SSB, but it's really 
easy to do so on FT8.  I do it all the time when I'm calling CQ DX and 
somebody stateside insists upon calling me over and over again. I 
consider it to be one of the beauties of FT8.  If I'm actively working 
stations he doesn't even significantly affect scrolling.


I'm rather astounded that others find that so hard to do.  On FT8, LIDs 
are only annoying if you let them.


Dave   AB7E


On 12/2/2019 6:26 PM, Ron WV4P wrote:
There are Many reasons to block a caller, they may be a Lid, they may 
be disrupting a QSO, they may just be Very annoying. As it stands we 
have No way to deal with them. We need a way. Just last night I had a 
PA station I had never worked send me RR73 over and over for 30 min. 
Ron, WV4P






___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Sam W2JDB via wsjt-devel]

Hi Ron, In your particular situation, I would send them a 73 (tx5) and don't 
log them. If they ever ask for a confirmation, I reject it.  73,  Sam W2JDB
  -Original Message-
From: Ron WV4P 
To: WSJT software development 
Sent: Mon, Dec 2, 2019 8:29 pm
Subject: Re: [wsjt-devel] Callsign lockout

There are Many reasons to block a caller, they may be a Lid, they may be 
disrupting a QSO, they may just be Very annoying. As it stands we have No way 
to deal with them. We need a way. Just last night I had a PA station I had 
never worked send me RR73 over and over for 30 min. Ron, WV4P
On Mon, Dec 2, 2019, 7:19 PM Gary Kohtala - K7EK via wsjt-devel 
 wrote:

 I agree. I believe a lockout feature could be abused. Case in point wasduring 
the heyday of packet radio (I call it the Packet Radio Wars).If you did not 
march to 'their' drum you were locked out of all nodes, BBS'gateways, etc. Such 
a thing should be banned. If it is there, someonewill use it to push their 
agenda. That's not in the spirit of amateur radio.
Best regards
Gary, K7EK

---

On Monday, December 2, 2019, 04:39:31 PM EST, David Gilbert 
 wrote:  
 
 
I have the same opinion.  I almost never use "Call 1st" and I find it 
trivial to operate without it no matter how many callers I get.

Even FT8 should be able to handle some degree of operator proficiency.

73,
Dave AB7E



On 12/2/2019 1:00 PM, Jim Brown wrote:
> On 12/2/2019 2:54 AM, Martin Davies G0HDB wrote:
>> In summary, I don't see any need whatsoever for any modification of 
>> the 'Call 1st' capability
>> to include any forms of queuing or callsign lockout
>
> Agreed. This is an operator issue, not a software one.
>
> 73, Jim K9YC
>



___
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
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Carey Fisher]

That's ridiculous. A "block" wouldn't keep a station from transmitting,
just from being displayed. Can't you just ignore it?

On Mon, Dec 2, 2019 at 8:29 PM Ron WV4P  wrote:

> There are Many reasons to block a caller, they may be a Lid, they may be
> disrupting a QSO, they may just be Very annoying. As it stands we have No
> way to deal with them. We need a way. Just last night I had a PA station I
> had never worked send me RR73 over and over for 30 min. Ron, WV4P
>
> On Mon, Dec 2, 2019, 7:19 PM Gary Kohtala - K7EK via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>> I agree. I believe a lockout feature could be abused. Case in point was
>> during the heyday of packet radio (I call it the Packet Radio Wars).
>> If you did not march to 'their' drum you were locked out of all nodes,
>> BBS'
>> gateways, etc. Such a thing should be banned. If it is there, someone
>> will use it to push their agenda. That's not in the spirit of amateur
>> radio.
>>
>> Best regards
>>
>> Gary, K7EK
>>
>>
>> ---
>>
>>
>> On Monday, December 2, 2019, 04:39:31 PM EST, David Gilbert <
>> xda...@cis-broadband.com> wrote:
>>
>>
>>
>> I have the same opinion.  I almost never use "Call 1st" and I find it
>> trivial to operate without it no matter how many callers I get.
>>
>> Even FT8 should be able to handle some degree of operator proficiency.
>>
>> 73,
>> Dave AB7E
>>
>>
>>
>> On 12/2/2019 1:00 PM, Jim Brown wrote:
>> > On 12/2/2019 2:54 AM, Martin Davies G0HDB wrote:
>> >> In summary, I don't see any need whatsoever for any modification of
>> >> the 'Call 1st' capability
>> >> to include any forms of queuing or callsign lockout
>> >
>> > Agreed. This is an operator issue, not a software one.
>> >
>> > 73, Jim K9YC
>> >
>>
>>
>>
>> ___
>> 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
>


-- 
Carey Fisher
careyfis...@gmail.com
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Bill Frantz]

Hi Gary -

Part of my reason for using Call 1st is philosophical: When I 
call CQ, I am saying I'm willing to work anybody who answers. If 
I say CQ ND, for example, I'm saying, "If you're in North 
Dakota, I'd really like a QSO." Other operators give CQ a 
different meaning.


I will note that I mostly call CQ when operating QRP, since 
that's the best way to ensure that the other station has heard 
my signal. (I don't operate from rare locations, so blind calls 
based on spots aren't a real problem.)


I do use Call 1st because by the time the decodes have been 
displayed, and my eyes have had a chance to look at them, I've 
lost the 15 second window, which really cuts into my rate. (I 
discovered early that I don't have the patience for JT9.)


I do sympathize with people who have stations calling them who 
can't hear them, and stations which don't complete the QSO. 
Michael's algorithm seems like a good one for handling these 
stations: Give new stations the first shot, and if there aren't 
any of those, retry the old stations in rotation.


73 Bill AE6JV

On 12/1/19 at 2:56 PM, mcduf...@ag0n.net (Gary McDuffie) wrote:

I’m curious why you use Call 1st anyway.  I never use it and 
have never found a use for it.  I want to have control over who 
I answer or call.

---
Bill Frantz| When an old person dies, a   | Periwinkle
(408)356-8506  | library burns. - Joe McGawon | 16345 
Englewood Ave
www.pwpconsult.com | Irish Ethnographer   | Los Gatos, 
CA 95032




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Larry B. via wsjt-devel]

It was probably a robot! 

73 -- Larry -- W1DYJ



From: Ron WV4P 
Sent: Monday, December 02, 2019 20:26
To: WSJT software development 
Subject: Re: [wsjt-devel] Callsign lockout

There are Many reasons to block a caller, they may be a Lid, they may be 
disrupting a QSO, they may just be Very annoying. As it stands we have No way 
to deal with them. We need a way. Just last night I had a PA station I had 
never worked send me RR73 over and over for 30 min. Ron, WV4P

On Mon, Dec 2, 2019, 7:19 PM Gary Kohtala - K7EK via wsjt-devel 
 wrote:

  I agree. I believe a lockout feature could be abused. Case in point was
  during the heyday of packet radio (I call it the Packet Radio Wars).
  If you did not march to 'their' drum you were locked out of all nodes, BBS'
  gateways, etc. Such a thing should be banned. If it is there, someone
  will use it to push their agenda. That's not in the spirit of amateur radio.

  Best regards

  Gary, K7EK


  ---


  On Monday, December 2, 2019, 04:39:31 PM EST, David Gilbert 
 wrote: 



  I have the same opinion.  I almost never use "Call 1st" and I find it 
  trivial to operate without it no matter how many callers I get.

  Even FT8 should be able to handle some degree of operator proficiency.

  73,
  Dave AB7E




  On 12/2/2019 1:00 PM, Jim Brown wrote:
  > On 12/2/2019 2:54 AM, Martin Davies G0HDB wrote:
  >> In summary, I don't see any need whatsoever for any modification of 
  >> the 'Call 1st' capability
  >> to include any forms of queuing or callsign lockout
  >
  > Agreed. This is an operator issue, not a software one.
  >
  > 73, Jim K9YC
  >



  ___
  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
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Ron WV4P]

There are Many reasons to block a caller, they may be a Lid, they may be
disrupting a QSO, they may just be Very annoying. As it stands we have No
way to deal with them. We need a way. Just last night I had a PA station I
had never worked send me RR73 over and over for 30 min. Ron, WV4P

On Mon, Dec 2, 2019, 7:19 PM Gary Kohtala - K7EK via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> I agree. I believe a lockout feature could be abused. Case in point was
> during the heyday of packet radio (I call it the Packet Radio Wars).
> If you did not march to 'their' drum you were locked out of all nodes, BBS'
> gateways, etc. Such a thing should be banned. If it is there, someone
> will use it to push their agenda. That's not in the spirit of amateur
> radio.
>
> Best regards
>
> Gary, K7EK
>
>
> ---
>
>
> On Monday, December 2, 2019, 04:39:31 PM EST, David Gilbert <
> xda...@cis-broadband.com> wrote:
>
>
>
> I have the same opinion.  I almost never use "Call 1st" and I find it
> trivial to operate without it no matter how many callers I get.
>
> Even FT8 should be able to handle some degree of operator proficiency.
>
> 73,
> Dave AB7E
>
>
>
> On 12/2/2019 1:00 PM, Jim Brown wrote:
> > On 12/2/2019 2:54 AM, Martin Davies G0HDB wrote:
> >> In summary, I don't see any need whatsoever for any modification of
> >> the 'Call 1st' capability
> >> to include any forms of queuing or callsign lockout
> >
> > Agreed. This is an operator issue, not a software one.
> >
> > 73, Jim K9YC
> >
>
>
>
> ___
> 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

Re: [wsjt-devel] Callsign lockout

[Gary Kohtala - K7EK via wsjt-devel]

 I agree. I believe a lockout feature could be abused. Case in point wasduring 
the heyday of packet radio (I call it the Packet Radio Wars).If you did not 
march to 'their' drum you were locked out of all nodes, BBS'gateways, etc. Such 
a thing should be banned. If it is there, someonewill use it to push their 
agenda. That's not in the spirit of amateur radio.
Best regards
Gary, K7EK

---

On Monday, December 2, 2019, 04:39:31 PM EST, David Gilbert 
 wrote:  
 
 
I have the same opinion.  I almost never use "Call 1st" and I find it 
trivial to operate without it no matter how many callers I get.

Even FT8 should be able to handle some degree of operator proficiency.

73,
Dave AB7E



On 12/2/2019 1:00 PM, Jim Brown wrote:
> On 12/2/2019 2:54 AM, Martin Davies G0HDB wrote:
>> In summary, I don't see any need whatsoever for any modification of 
>> the 'Call 1st' capability
>> to include any forms of queuing or callsign lockout
>
> Agreed. This is an operator issue, not a software one.
>
> 73, Jim K9YC
>



___
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

Re: [wsjt-devel] Callsign lockout

[James Shaver]

Same - I figure the automation functions are an operator aid, not an operator 
replacement. 

Jim S. 
N2ADV

> On Dec 2, 2019, at 4:37 PM, David Gilbert  wrote:
> 
> 
> I have the same opinion.  I almost never use "Call 1st" and I find it trivial 
> to operate without it no matter how many callers I get.
> 
> Even FT8 should be able to handle some degree of operator proficiency.
> 
> 73,
> Dave AB7E
> 
> 
> 
>> On 12/2/2019 1:00 PM, Jim Brown wrote:
>>> On 12/2/2019 2:54 AM, Martin Davies G0HDB wrote:
>>> In summary, I don't see any need whatsoever for any modification of the 
>>> 'Call 1st' capability
>>> to include any forms of queuing or callsign lockout
>> 
>> Agreed. This is an operator issue, not a software one.
>> 
>> 73, Jim K9YC
>> 
> 
> 
> 
> ___
> 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

Re: [wsjt-devel] Callsign lockout

[Black Michael via wsjt-devel]

I'm all ears for opinions from operators who have had a call pileup on them.
If Call 1st is to be implemented at all it should be robust.
It's a trivial patch which I'll make myself and submit for consideration in 
WSJT-X.
de Mike W9MDB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[David Gilbert]

I have the same opinion.  I almost never use "Call 1st" and I find it 
trivial to operate without it no matter how many callers I get.


Even FT8 should be able to handle some degree of operator proficiency.

73,
Dave AB7E



On 12/2/2019 1:00 PM, Jim Brown wrote:

On 12/2/2019 2:54 AM, Martin Davies G0HDB wrote:
In summary, I don't see any need whatsoever for any modification of 
the 'Call 1st' capability

to include any forms of queuing or callsign lockout


Agreed. This is an operator issue, not a software one.

73, Jim K9YC





___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Jim Brown]

On 12/2/2019 2:54 AM, Martin Davies G0HDB wrote:

In summary, I don't see any need whatsoever for any modification of the 'Call 
1st' capability
to include any forms of queuing or callsign lockout


Agreed. This is an operator issue, not a software one.

73, Jim K9YC


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Martin Davies G0HDB]

On 1 Dec 2019 at 12:56, Gary McDuffie wrote:

> > On Nov 30, 2019, at 15:15, Black Michael via wsjt-devel 
> >  wrote:
> > 
> > What is needed is the ability to block a callsign for an adjustable time 
> > out period defaulting perhaps to 15 minutes.
> 
> I´m curious why you use Call 1st anyway.  I never use it and have
> never found a use for it.  I want to have control over who I answer or
> call. 

You've absolutely hit the nail on the head, Gary - anyone who is troubled by 
their system 
replying to 'unwanted' callers simply needs to disable 'Call 1st' and then use 
a bit of skill and 
experience to decide which caller to respond to.  That's how it's always been 
done when 
using the 'legacy' modes of CW, SSB and RTTY and there's no obvious reason why 
a 
different, de-skilled modus operandi should be adopted for the JT/FT modes.

Although I do call CQ on a fairly regular basis I (almost) always prefer to 
leave 'Call 1st' 
unchecked which puts the onus on me to double-click on whichever callsign I 
decide I want to 
work in preference to others that appear in the list of decodes addressed to my 
callsign.  I 
never, ever feel obliged to have a QSO with a caller just because they've 
called me - I decide 
who I want to have the QSO with, and I regularly ignore persistent callers that 
I'm not 
interested in working!

As for it taking maybe a couple of seconds to decide which callsign from the 
list of decodes 
to work, that isn't usually an issue because the software at the distant end is 
generally quite 
capable of getting a good decode from my transmission even if it's started a 
bit late in the 
15sec timeslot.  However, there can be occasions when a retry is needed, but 
again that's no 
different to operating using the 'legacy' modes.

With regard to stations not sending their Tx3 message in response to a 'DX' 
station's (eg. the 
KL7 mentioned by the OP) Tx2, there can be numerous reasons (eg. QSB, QRM, QRN, 
etc 
etc) why the Tx2 message might not have been received by the caller - there's 
no way of 
knowing what the factors are so I'd suggest that if the 'DX' station hasn't 
received the caller's 
Tx3 message after say three or four retries then it's time to move on and try 
to complete a 
QSO with another caller.  This is after all what DX stations have done for 
decades when 
working CW, SSB and RTTY pileups; all it needs is the operator of the 'DX' 
station to use 
their skill and experience and not rely too heavily on the automation 
facilities that the WSJT-X 
software provides.

In summary, I don't see any need whatsoever for any modification of the 'Call 
1st' capability 
to include any forms of queuing or callsign lockout - IMO they would be 
entirely superfluous 
and unnecessary.  If a 'DX' station wants to have some form of queuing incoming 
callers then 
perhaps they should use the DXpedition Fox & Hounds mode.

---
Martin, G0HDB



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Topher Petty]

I'd love to be able to lock out operators who like to answer your CQ, but
never get beyond their report to you... 20 minutes of cycling  back and
forth, until you just change bands to get away from them...


On Sun, Dec 1, 2019 at 8:08 PM Al Pawlowski  wrote:

> The lockout que/buffer idea seems a reasonable way to improve “Call 1st”
> operation.
>
> Call signs would be locked out automatically after failing to answer (n
> times?) a CQ sender's response. The lockout/s would then clear be cleared
> manually, or automatically (by operator selection?), when a CQ’r finishes
> an established QSO.
>
>
> Al Pawlowski, K6AVP
> Los Osos, CA USA
>
>
>
> ___
> 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] Callsign lockout

[Al Pawlowski]

The lockout que/buffer idea seems a reasonable way to improve “Call 1st” 
operation.

Call signs would be locked out automatically after failing to answer (n times?) 
a CQ sender's response. The lockout/s would then clear be cleared manually, or 
automatically (by operator selection?), when a CQ’r finishes an established QSO.


Al Pawlowski, K6AVP
Los Osos, CA USA



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Gary McDuffie]

> On Nov 30, 2019, at 15:15, Black Michael via wsjt-devel 
>  wrote:
> 
> What is needed is the ability to block a callsign for an adjustable time out 
> period defaulting perhaps to 15 minutes.

I’m curious why you use Call 1st anyway.  I never use it and have never found a 
use for it.  I want to have control over who I answer or call.

Gary - AG0N

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Zeev Stadler]

On Sun, Dec 1, 2019 at 2:22 PM Larry Burke  wrote:

> >> You have no idea if they are calling blind until you send them TX2 and
> they don't send you TX3.
>
>
>
> While I agree that there are some who call blind, there are other reasons
> for the caller not replying with a TX3… QSB being the one that comes to
> mind. This IS a weak signal mode and sometimes it takes a few sequences to
> make the connection. Particularly if one of the stations is “less equipped”
> than the other.
>

I agree that there are situations where a well behaving operator may not
respond to our reply.

In practical terms, it does not really matter what is the reason the remote
station keeps calling us but does not respond to our reply. The need to be
able and proceed with a workable "Call First" solution for the other
stations is still there.

That's my 2 cents...

73, Zeev 4X5ZS
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Larry Burke]

>> You have no idea if they are calling blind until you send them TX2 and they 
>> don't send you TX3.

 

While I agree that there are some who call blind, there are other reasons for 
the caller not replying with a TX3… QSB being the one that comes to mind. This 
IS a weak signal mode and sometimes it takes a few sequences to make the 
connection. Particularly if one of the stations is “less equipped” than the 
other. 

 

 

 

>> you check their spot history (for those that have PSKReporter or JTAlert 
>> running) they've never seen the dx station

 

I’ve worked many a DX station who, for whatever reason, doesn’t get spotted by 
me on PSKReporter when forwarding is checked. 

 

While some operating practices are frustrating, I think we need to be careful 
about too many lockouts. 

 

Larry K5RK

 

From: Black Michael via wsjt-devel  
Sent: Saturday, November 30, 2019 11:16 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Black Michael 
Subject: Re: [wsjt-devel] Callsign lockout

 

You're assuming they are not calling blind.  You have no idea if they are 
calling blind until you send them TX2 and they don't send you TX3.

 

This is noticeable all the time on dxpeditions where you will see a dozen 
people constantly calling and if you check their spot history (for those that 
have PSKReporter or JTAlert running) they've never seen the dx station.

 

Les hit the problem with a bunch of European stations trying to work him 
(Alaska being somewhat rare) and was sending TX2 and never getting replies from 
numerous ops.

 

I think one way to do this is for call first to use a queue and when you work 
somebody they go to the bottom of the queue.  So until such time as they bubble 
up to the top they won't get worked again.  Call first would take each call 
coming in and check the queue, if not in the queue work it and stick it in the 
queue at the bottom.  If all decodes are in the queue pop the top one off and 
work it.  Keep the queue depth to a limit or add time to it to time out entries 
after a programmable limit.

 

Mike

 

 

 

On Saturday, November 30, 2019, 10:17:58 PM CST, Jim Brown 
mailto:k...@audiosystemsgroup.com> > wrote: 

 

 

On 11/30/2019 2:15 PM, Black Michael via wsjt-devel wrote:
> who was complaining about operators calling him in the blind.  And when 
> you have Call First checked the blind callers become a PITA.

Hmmm. If I'm not mistaken, "Call First" would apply to those answering a 
CQ. I rarely call CQ, so I don't use that function much. On more than 
one occasion, I've been calling EU stations on 160M (I'm near San 
Francisco), and some turkey in the next county calls and calls and 
calls, why I don't know. But since I have "Auto-Complete" checked but 
not "Call First," WSJT-X dutifully ignore the caller, and waits for a 
call from the guy I'm calling. This happened a few nights ago when I was 
trying to work an island expediton

Same thing happens on 6M in the middle of a double-hop opening. Again, I 
don't call CQ much, but when I do, I usually turn off "Call First" to 
avoid those locals, instead trying to be fast to respond to one of the 
stations I want to work.

BTW -- I suspect the root cause of the problem is that these callers are 
only looking at JTAlert, and haven't learned to recognize when a decode 
is not a CQ. :)

73, Jim K9YC






___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto: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

Re: [wsjt-devel] Callsign lockout

[Paul Randall]

When calling CQ dx on 80m at dusk (my loop is regularly heard in VK) there are 
local EU stations that give me just a single call then disappear, presumably 
just to be a PITA by triggering the "call 1st" feature on my rig. My answer is 
to switch it off. It means I have to sit in front of the radio and actually 
operate it but that is no different from any other mode.  It is easy to get 
reliant on the automation. The downside of my manual system means if i do 
respond to a caller my reaction time does usually mean a missed 30 second cycle 
and that isn't like other modes.
73 Paul.



Sent from my Samsung Galaxy smartphone.



 Original message 
From: Ron WV4P 
Date: 01/12/2019 00:18 (GMT+00:00)
To: Black Michael , WSJT software development 

Subject: Re: [wsjt-devel] Callsign lockout

This function has Desperately been needed for a long time. Ron, WV4P

On Sat, Nov 30, 2019, 4:21 PM Black Michael via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net>> 
wrote:
Was just communicating with an Alaskan operator who was complaining about 
operators calling him in the blind.  And when you have Call First checked the 
blind callers become a PITA.

What is needed is the ability to block a callsign for an adjustable time out 
period defaulting perhaps to 15 minutes. (don't even show them in the band 
activity).  Maybe it could be done with a ctrl-click on TX 1 or some other 
better method.  Turn off Enable, clear the DXCall box and then the next valid 
decode would be able to start up.

de Mike W9MDB


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto: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

Re: [wsjt-devel] Callsign lockout

[Black Michael via wsjt-devel]

You're assuming they are not calling blind.  You have no idea if they are 
calling blind until you send them TX2 and they don't send you TX3.
This is noticeable all the time on dxpeditions where you will see a dozen 
people constantly calling and if you check their spot history (for those that 
have PSKReporter or JTAlert running) they've never seen the dx station.
Les hit the problem with a bunch of European stations trying to work him 
(Alaska being somewhat rare) and was sending TX2 and never getting replies from 
numerous ops.
I think one way to do this is for call first to use a queue and when you work 
somebody they go to the bottom of the queue.  So until such time as they bubble 
up to the top they won't get worked again.  Call first would take each call 
coming in and check the queue, if not in the queue work it and stick it in the 
queue at the bottom.  If all decodes are in the queue pop the top one off and 
work it.  Keep the queue depth to a limit or add time to it to time out entries 
after a programmable limit.
Mike
 

On Saturday, November 30, 2019, 10:17:58 PM CST, Jim Brown 
 wrote:  
 
 On 11/30/2019 2:15 PM, Black Michael via wsjt-devel wrote:
> who was complaining about operators calling him in the blind.  And when 
> you have Call First checked the blind callers become a PITA.

Hmmm. If I'm not mistaken, "Call First" would apply to those answering a 
CQ. I rarely call CQ, so I don't use that function much. On more than 
one occasion, I've been calling EU stations on 160M (I'm near San 
Francisco), and some turkey in the next county calls and calls and 
calls, why I don't know. But since I have "Auto-Complete" checked but 
not "Call First," WSJT-X dutifully ignore the caller, and waits for a 
call from the guy I'm calling. This happened a few nights ago when I was 
trying to work an island expediton.

Same thing happens on 6M in the middle of a double-hop opening. Again, I 
don't call CQ much, but when I do, I usually turn off "Call First" to 
avoid those locals, instead trying to be fast to respond to one of the 
stations I want to work.

BTW -- I suspect the root cause of the problem is that these callers are 
only looking at JTAlert, and haven't learned to recognize when a decode 
is not a CQ. :)

73, Jim K9YC




___
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

Re: [wsjt-devel] Callsign lockout

[Ron WV4P]

This function has Desperately been needed for a long time. Ron, WV4P

On Sat, Nov 30, 2019, 4:21 PM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Was just communicating with an Alaskan operator who was complaining about
> operators calling him in the blind.  And when you have Call First checked
> the blind callers become a PITA.
>
> What is needed is the ability to block a callsign for an adjustable time
> out period defaulting perhaps to 15 minutes. (don't even show them in the
> band activity).  Maybe it could be done with a ctrl-click on TX 1 or some
> other better method.  Turn off Enable, clear the DXCall box and then the
> next valid decode would be able to start up.
>
> de Mike W9MDB
>
>
> ___
> 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] Callsign lockout

[Black Michael via wsjt-devel]

Was just communicating with an Alaskan operator who was complaining about 
operators calling him in the blind.  And when you have Call First checked the 
blind callers become a PITA.
What is needed is the ability to block a callsign for an adjustable time out 
period defaulting perhaps to 15 minutes. (don't even show them in the band 
activity).  Maybe it could be done with a ctrl-click on TX 1 or some other 
better method.  Turn off Enable, clear the DXCall box and then the next valid 
decode would be able to start up.
de Mike W9MDB

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel