Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Grant VK5GR]

George,

 

Allow me to answer your questions in line:

 

| Aren’t major efforts (those we expect to use F/H) frequencies pre-coordinated 
and published in advance of the trip? 

 

You would like to think so. In practice despite trying to do just that the 
larger expeditions just took the information I tried sending about 

A35JT and filed it into the circular filing cabinet – then published my 
proposed A35JT frequencies as their own despite being told we 

were going out there months before they published theirs. So you cannot rely on 
pre-coordination.

 

| Do holiday-style trips really need F/H?

 

Depends on where they go now doesn’t it? If it was a one man holiday trip to a 
top 40-50 most wanted destination (or even a top 100 it seems) 

you can very quickly overwhelm and destroy the main standard FT8 channels. 
Whether it is one person or 30 at the DXpedition site doesn’t matter. 

If the location they are operating from is rarely activated and they have more 
than 5-6 callers at a time trying to work them, then there is a case 

to move to Fox/Hound mode, one – to speed up your QSO rate and two – to prevent 
overwhelming the main channels.

 

| Major dxpeditions should never operate in the standard watering holes, right? 
Isn’t there advice about this in the manual?

 

The software in fact means that you cant activate FOX mode on one of the 
primary frequencies. We are not talking about running FOX mode on the 

Existing standard mode frequencies anyway.

 

| So, why would operators looking to maximize QSO count need additional band 
monitoring displays? Shouldn’t they 
| concentrate on answering the calls headed their way? Clearing contacts would 
seem to be the goal, not searching a 
| pileup for a multiplier or rare one, right?

 

Sorry but this looks like a question from someone who has never been on the 
receiving end of an expedition FOX operation.

 

a.   We are trying to maximise QSO count

b.  There is no band activity display currently – so if another FOX 
operation starts up on top of you, you really don’t know about it initially – 
only secondary indications start to give you a hint that there is a problem.

c.   The multiplier comment is also irrelevant because in FOX mode I can do 
that today with the controls I have for stations calling me 
anyway – if I want to preference someone I can without the band activity window

 

| I grant you, DQRM or operator error can wreak havoc. Wouldn’t this show up in 
the fox’s completion rate and thus 
| raise suspicion by an experienced operator?

 

And it does – but it takes time and an experienced operator to see their 
completion rate fall. Unfortunately there are multiple reasons the

completion rate can fall – often caused by people using standard mode to call a 
FOX station repeatedly on the FOX uplink sub-channel. Direct
evidence on screen that there are callers for another FOX on the same frequency 
as yourself would allow you to more quickly take evasive 
action – or better still give you pause and not start up your FOX CQ on top of 
someone else in the first place. 

 

| For hounds not willing to set up a profile, why? It is extremely easy and 
affords you the ability to enter the Dxpeditions 
| published frequencies, switch between them nearly instantly, and keep some 
semblance of order by not editing your normal 
| frequency list. Is there an advantage I am missing?

 

Couldn’t agree more – do it all the time – but this is not at issue here

 

Your other questions I will leave others to reply to as they are not about FOX 
mode operation from the FOX operator position.

 

Regards,

Grant VK5GR – Dxpedition Leader for A35JT Tonga

 

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

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[George J Molnar]

A couple recent comments on Fox/Hound mode have me perplexed. 

Aren’t major efforts (those we expect to use F/H) frequencies pre-coordinated 
and published in advance of the trip? 

Do holiday-style trips really need F/H?

Major dxpeditions should never operate in the standard watering holes, right? 
Isn’t there advice about this in the manual?

So, why would operators looking to maximize QSO count need additional band 
monitoring displays? Shouldn’t they concentrate on answering the calls headed 
their way? Clearing contacts would seem to be the goal, not searching a pileup 
for a multiplier or rare one, right?

I grant you, DQRM or operator error can wreak havoc. Wouldn’t this show up in 
the fox’s completion rate and thus raise suspicion by an experienced operator?

For hounds not willing to set up a profile, why? It is extremely easy and 
affords you the ability to enter the Dxpeditions published frequencies, switch 
between them nearly instantly, and keep some semblance of order by not editing 
your normal frequency list. Is there an advantage I am missing?

Hound mode allows full passband monitoring capability, check-box on the main 
screen. Is this insufficient to check band activity before jumping in? I 
thought the receive side of hound mode looks and acts like “normal” FT8. 

In the event of multi-signal operation from non-WSJT-x operations (perhaps in 
the watering holes), why would there be interest in switching to hound mode? 
Standard FT8 works perfectly in this situation. Identifying the mode of 
operation takes little time - if you see someone above 1000 Hz complete a 
contact, it’s not F/H. Or am I confused?

I appreciate the group’s indulgence and patience.

George J Molnar, KF2T 
Arlington, Virginia, USA___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[George J Molnar]

Please forgive what may be ridiculous questions. Some are for foxes, others 
for hounds.

Fox/Hound operation should only be carried out away from the main “watering 
holes,” right? For expeditions, isn’t it standard practice to coordinate with 
other expeditions before leaving home to ensure efficient spectrum use?

Why is looking for another station on the same DF and cycle helpful? Wouldn’t 
the sudden influx of calls for someone-not-you be a tipoff?

Is building a configuration for F/H so onerous, since it could even include the 
announced DXpedition frequencies in the drop down without messing with 
day-to-day use?

Isn’t there a “receive all frequencies” checkbox on the main screen during F/H 
operation? Is this not sufficient to monitor the pileup before jumping in?

Is there value to monitoring another frequency while operating F/H that can’t 
best be solved with a second instance?





George J Molnar, KF2T 
Arlington, Virginia, USA
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[David Gilbert]

I don't use Fox/Hound, of course, but it seems to me that VK5GR's 
request when using it is legitimate.  I wouldn't have said anything at 
all if it weren't for the dev reply that cited a lack of screen real 
estate as the reason for not addressing it.


It's not bitching to point out the obvious.

Dave   AB7E


On 11/20/2019 4:29 AM, Fred Price wrote:
Ya know if you so much want this why not open your computer and 
reprogram the interface yourself?
What's it take 30 seconds to open settings or change a config? Is the 
DX going to disappear in that time?
I guess everyone forgot about when the NA contest mode had a check box 
on the GUI. So many wondered why they were in contest mode because 
they mistakingly checked the box.
Most like the dev group has a lot more to do then move a check box. 
I'd bet they have life's outside of ham radio as well. I think the dev 
group does a helluva job. Just one last thing, how can anybody bitch 
about free software


On Nov 19, 2019 7:25 PM, David Gilbert  wrote:


If anyone was seriously concerned about real estate usage in the
WSJT-X
user window there wouldn't be all that wasted space in the lower left
corner for any of the modes.  The Frequency display doesn't need
to be
anywhere near that large, DX Call and DX Grid is mostly
superfluous, the
size of the Date/Time box is ridiculous ...   and all of that
could be
resized and repositioned under the Auto Seq and Call 1st buttons.

All of which has been brought up before.

Dave   AB7E

On 11/19/2019 2:36 PM, Grant VK5GR wrote:
> Joe,
>
> As for the band activity window - yes screen realestate is
cluttered as it
> stands - but not being able to see the band activity is an
extremely serious
> problem on the air. The "workarounds" proposed are just that -
workarounds.
> Not all Fox operators will be that savvy (although I wish I had
thought of
> the tail ALL.TXT idea out on the island).
>
> Regards,
> Grant
>



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

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Joe Taylor]

Grant --

On 11/19/2019 4:36 PM, Grant VK5GR wrote:


We tested a lot of the station before we left - as much functionality and
hardware as we could in fact. However in the case of FOX mode, that is
something that is extremely difficult to test ... 


Actually, the disabling of *Tx Enable* after Fox sends RR73 in WSJT-X 
2.1.0 is very easy to confirm.  Fox needs only make a single QSO with 
someone acting as Hound.  Do it over the air, if you wish, but it's 
trivial to simulate by using two instances of WSJT-X running on a single 
computer, with loop-back audio.



... until you arrive somewhere
where people will a) accept you should be running FOX mode and b) are able
to attract enough callers to even conduct the test. I'm afraid your
suggestion of "test before you leave" in this case perhaps isn't a practical
one :) 


Quite the contrary.


Most expeditions running FOX mode these days start with small 2-3 man
shows which head out to exotic places that justify FOX mode. Things like the
RR73 problem only really become apparent after perhaps 15-30 minutes of use
when it dawns on you what is going on too. In reality most FOX stations
don't have the resources to try a full FOX mode QSO test as you suggested
prior to leaving.


Again, this makes no sense.


As for the band activity window - yes screen realestate is cluttered as it
stands - but not being able to see the band activity is an extremely serious
problem on the air. The "workarounds" proposed are just that - workarounds.
Not all Fox operators will be that savvy (although I wish I had thought of
the tail ALL.TXT idea out on the island).


Managing a pileup, perhaps in the presence of unrelated QRM, is surely 
the responsibility of the operator of a much desired DX station. 
Yesterday I described two different ways to keep track of such 
"unrelated QRM".


-- Joe, K1JT


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

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Tom Ramberg via wsjt-devel]

Fred, I see no bitching here, just friendy questions and mostly very polite 
answers.

73 de Tom OH6VDA (occasionally semi-rare JW6VDA)

Sendt fra min iPad Air 2

> 20. nov. 2019 kl. 13:34 skrev Fred Price :
> 
> 
> Ya know if you so much want this why not open your computer and reprogram the 
> interface yourself?
> What's it take 30 seconds to open settings or change a config? Is the DX 
> going to disappear in that time?
> I guess everyone forgot about when the NA contest mode had a check box on the 
> GUI. So many wondered why they were in contest mode because they mistakingly 
> checked the box.
> Most like the dev group has a lot more to do then move a check box. I'd bet 
> they have life's outside of ham radio as well. I think the dev group does a 
> helluva job. Just one last thing, how can anybody bitch about free software
> 
> On Nov 19, 2019 7:25 PM, David Gilbert  wrote:
> 
> If anyone was seriously concerned about real estate usage in the WSJT-X 
> user window there wouldn't be all that wasted space in the lower left 
> corner for any of the modes.  The Frequency display doesn't need to be 
> anywhere near that large, DX Call and DX Grid is mostly superfluous, the 
> size of the Date/Time box is ridiculous ...   and all of that could be 
> resized and repositioned under the Auto Seq and Call 1st buttons.
> 
> All of which has been brought up before.
> 
> Dave   AB7E
> 
> On 11/19/2019 2:36 PM, Grant VK5GR wrote:
> > Joe,
> >
> > As for the band activity window - yes screen realestate is cluttered as it
> > stands - but not being able to see the band activity is an extremely serious
> > problem on the air. The "workarounds" proposed are just that - workarounds.
> > Not all Fox operators will be that savvy (although I wish I had thought of
> > the tail ALL.TXT idea out on the island).
> >
> > Regards,
> > Grant
> >
> 
> 
> ___
> 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] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Fred Price]

Ya know if you so much want this why not open your computer and reprogram the 
interface yourself?
What's it take 30 seconds to open settings or change a config? Is the DX going 
to disappear in that time?
I guess everyone forgot about when the NA contest mode had a check box on the 
GUI. So many wondered why they were in contest mode because they mistakingly 
checked the box.
Most like the dev group has a lot more to do then move a check box. I'd bet 
they have life's outside of ham radio as well. I think the dev group does a 
helluva job. Just one last thing, how can anybody bitch about free software

On Nov 19, 2019 7:25 PM, David Gilbert  wrote:

If anyone was seriously concerned about real estate usage in the WSJT-X
user window there wouldn't be all that wasted space in the lower left
corner for any of the modes.  The Frequency display doesn't need to be
anywhere near that large, DX Call and DX Grid is mostly superfluous, the
size of the Date/Time box is ridiculous ...   and all of that could be
resized and repositioned under the Auto Seq and Call 1st buttons.

All of which has been brought up before.

Dave   AB7E

On 11/19/2019 2:36 PM, Grant VK5GR wrote:
> Joe,
>
> As for the band activity window - yes screen realestate is cluttered as it
> stands - but not being able to see the band activity is an extremely serious
> problem on the air. The "workarounds" proposed are just that - workarounds.
> Not all Fox operators will be that savvy (although I wish I had thought of
> the tail ALL.TXT idea out on the island).
>
> Regards,
> Grant
>


___
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] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Tom Melvin]

Dave

There is not a lot of space under the 'Auto Seq' box - I will agree date and 
time could be smaller - but disagree as to the DX Call/Grid  - they need to be 
easily seen/entered for distance/Bearing - my eyes are not quite what the were 
a few years back and with all the different frequencies in use I really do need 
to see that easily at a glance.

See attached if it made it through



--
73’s

Tom
GM8MJV (IO85)





On 20 Nov 2019, at 00:25, David Gilbert  wrote:

> 
> If anyone was seriously concerned about real estate usage in the WSJT-X user 
> window there wouldn't be all that wasted space in the lower left corner for 
> any of the modes.  The Frequency display doesn't need to be anywhere near 
> that large, DX Call and DX Grid is mostly superfluous, the size of the 
> Date/Time box is ridiculous ...   and all of that could be resized and 
> repositioned under the Auto Seq and Call 1st buttons.
> 
> All of which has been brought up before.
> 
> Dave   AB7E
> 
> 
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[David Gilbert]

If anyone was seriously concerned about real estate usage in the WSJT-X 
user window there wouldn't be all that wasted space in the lower left 
corner for any of the modes.  The Frequency display doesn't need to be 
anywhere near that large, DX Call and DX Grid is mostly superfluous, the 
size of the Date/Time box is ridiculous ...   and all of that could be 
resized and repositioned under the Auto Seq and Call 1st buttons.


All of which has been brought up before.

Dave   AB7E


On 11/19/2019 2:36 PM, Grant VK5GR wrote:

Joe,

As for the band activity window - yes screen realestate is cluttered as it
stands - but not being able to see the band activity is an extremely serious
problem on the air. The "workarounds" proposed are just that - workarounds.
Not all Fox operators will be that savvy (although I wish I had thought of
the tail ALL.TXT idea out on the island).

Regards,
Grant





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

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Grant VK5GR]

Joe,

We tested a lot of the station before we left - as much functionality and
hardware as we could in fact. However in the case of FOX mode, that is
something that is extremely difficult to test until you arrive somewhere
where people will a) accept you should be running FOX mode and b) are able
to attract enough callers to even conduct the test. I'm afraid your
suggestion of "test before you leave" in this case perhaps isn't a practical
one :) Most expeditions running FOX mode these days start with small 2-3 man
shows which head out to exotic places that justify FOX mode. Things like the
RR73 problem only really become apparent after perhaps 15-30 minutes of use
when it dawns on you what is going on too. In reality most FOX stations
don't have the resources to try a full FOX mode QSO test as you suggested
prior to leaving.

As for the band activity window - yes screen realestate is cluttered as it
stands - but not being able to see the band activity is an extremely serious
problem on the air. The "workarounds" proposed are just that - workarounds.
Not all Fox operators will be that savvy (although I wish I had thought of
the tail ALL.TXT idea out on the island). 

Actually, on reflection from when I parsed the .TXT files on returning home
to find any unlogged contacts, I don't recall seeing FOX mode channel
activity being logged in ALL.TXT at all. FOXQSO.TXT appears to be but I am
pretty sure ALL.TXT isn't - and I don't recall FOXQSO showing band activity
- only QSO activity. So again that workaround perhaps isn't a solution
either?

Option 2 for band activity could simply be inject copies of the decoded
signals where station B is not the FOX into the existing Rx Frequency window
in a different colour. This would highlight to the FOX operator that someone
is responding to someone other than this FOX station on the FOX stations
frequency. When the fox operator sees multiple rows of such traffic, that is
enough of a warning that we have a frequency clash to alert the FOX
operators to take action and at least stop and look at their channel perhaps
in standard mode for a few minutes. No more screen realestate required than
is being used today yet required functionality substantially delivered. 

Your thoughts on this option please?

Regards,
Grant

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: Wednesday, 20 November 2019 1:51 AM
To: WSJT software development
Subject: Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator
enhancement request

Hi Grant,

On 11/18/2019 4:20 PM, Grant VK5GR wrote:

> Thanks for the reply - I am really pleased that the RR73 problem is in
fact
> a bug. I can tell you that it is driving FOX operators nuts on
expeditions.
> I guess we should have spoken up sooner.

Memo to file:

It's ALWAYS best to make relevant tests of critical software before 
embarking on a DXpedition, and to communicate with the software authors 
if issues are found.  We could very easily have saved you lots of grief.

> ...
> Bottom line - FOX operators need some channel awareness to avoid these
> collisions. An in built band activity window is vital.
> 
> As for running a second instance, we did consider it - but facing fox mode
> with 5 channels and hundreds of callers some of our laptops on the
> expedition started to run out of grunt and screen real-estate given N1MM
is
> also active. To be practical, it really needs the band activity window
> visible native in FOX mode within the instance the operator is running.

What you're requesting would also require screen real-estate.  Making 
visible just the Band Activity portion of a second instance's main 
window would not require much screen space.

A better solution to your problem might be the one suggested by Iztok, 
S52D:  monitor the tail end of the ALL.TXT file.  You could use the free 
utility "BareTail".  Or install the GNU utilities for Win32, for example 
http://unxutils.sourceforge.net/ .

-- 73, Joe, K1JT


___
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] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Joe Taylor]

Hi Grant,

On 11/18/2019 4:20 PM, Grant VK5GR wrote:


Thanks for the reply - I am really pleased that the RR73 problem is in fact
a bug. I can tell you that it is driving FOX operators nuts on expeditions.
I guess we should have spoken up sooner.


Memo to file:

It's ALWAYS best to make relevant tests of critical software before 
embarking on a DXpedition, and to communicate with the software authors 
if issues are found.  We could very easily have saved you lots of grief.



...
Bottom line - FOX operators need some channel awareness to avoid these
collisions. An in built band activity window is vital.

As for running a second instance, we did consider it - but facing fox mode
with 5 channels and hundreds of callers some of our laptops on the
expedition started to run out of grunt and screen real-estate given N1MM is
also active. To be practical, it really needs the band activity window
visible native in FOX mode within the instance the operator is running.


What you're requesting would also require screen real-estate.  Making 
visible just the Band Activity portion of a second instance's main 
window would not require much screen space.


A better solution to your problem might be the one suggested by Iztok, 
S52D:  monitor the tail end of the ALL.TXT file.  You could use the free 
utility "BareTail".  Or install the GNU utilities for Win32, for example 
http://unxutils.sourceforge.net/ .


-- 73, Joe, K1JT


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

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Grant VK5GR]

Joe,

Thanks for the reply - I am really pleased that the RR73 problem is in fact
a bug. I can tell you that it is driving FOX operators nuts on expeditions.
I guess we should have spoken up sooner.

As for the band activity window, unfortunately the premise of having a well
advertised channel window etc sounds good in theory - but in practice, with
so many expeditions around at times each with differing levels of
"advertising" knowhow, that theory is breaking down. For example, when I was
on Tonga last month as A35JT, there were 5 expeditions present at the same
time (eg ZK3A, A82X etc). We also found particularly on 40m that we also had
to dodge QRM, finding our advertised channel full of SSB and other rubbish
which forced us to be flexible and to QSY on the fly (fortunately we had
internet so using the cluster to advertise the change was relatively easy
for us - it isn't always so). The ability to pre-plan on everyone having
their own slot on every band (given a slot is 3-4kHz and some bands are only
15kHz wide) really doesn't work in peak expedition season. (My attempts to
in fact plan and coordinate with the other expeditions failed also. Despite
sending A35JT's proposed band plans to several of them months beforehand,
putting the data on social media and on our website, I still had "larger"
expeditions ignore me and jump my proposed A35JT frequencies for
themselves). 

Bottom line - FOX operators need some channel awareness to avoid these
collisions. An in built band activity window is vital.

As for running a second instance, we did consider it - but facing fox mode
with 5 channels and hundreds of callers some of our laptops on the
expedition started to run out of grunt and screen real-estate given N1MM is
also active. To be practical, it really needs the band activity window
visible native in FOX mode within the instance the operator is running.

A quick fix might be to report to a FOX operator if a hound is calling
another station other than yours in the receive window - coloured with a
different colour. This at least would provide some warning that a channel
clash has occurred. Adding the band activity window back can be a topic for
later after that. (I have some ideas for how to potentially improve the FOX
mode operator experience too which perhaps the window idea could be better
incorporated within - more on this later).

Regards,
Grant VK5GR


-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: Tuesday, 19 November 2019 3:48 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator
enhancement request

Hi Grant and all,

Thanks for reporting the bug in WSJT-X v2.1.0 that causes *Tx Enable* to 
be turned off when Fox sends RR73.  We knew about this issue and 
corrected it several months ago, back in August, but -- having received 
no complaints from users -- we have been waiting to issue a bug-fix 
release until several other issues are resolved.

We will schedule a release of WSJT-X v2.1.1 soon.

Your other request, to have standard "Band Activity" displayed when in 
Fox mode, will not be addressed in v2.1.1.  Code for Fox mode is based 
on an understanding that you (the Fox) will have a well-advertised band 
segment to yourself.

Have you tried simply running a second instance of WSJT-X, in normal 
mode, so that you can monitor what's going on in a difficult situation?

-- 73, Joe, K1JT


___
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] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Tom Ramberg via wsjt-devel]

Hello Joe, thanks for the info. Awaiting 2.1.1 then! 

73 de Tom, sporadically JW6VDA



Sendt fra min iPhone

> 18. nov. 2019 kl. 19:18 skrev Joe Taylor :
> 
> Hi Grant and all,
> 
> Thanks for reporting the bug in WSJT-X v2.1.0 that causes *Tx Enable* to be 
> turned off when Fox sends RR73.  We knew about this issue and corrected it 
> several months ago, back in August, but -- having received no complaints from 
> users -- we have been waiting to issue a bug-fix release until several other 
> issues are resolved.
> 
> We will schedule a release of WSJT-X v2.1.1 soon.
> 
> Your other request, to have standard "Band Activity" displayed when in Fox 
> mode, will not be addressed in v2.1.1.  Code for Fox mode is based on an 
> understanding that you (the Fox) will have a well-advertised band segment to 
> yourself.
> 
> Have you tried simply running a second instance of WSJT-X, in normal mode, so 
> that you can monitor what's going on in a difficult situation?
> 
>-- 73, Joe, K1JT
> 
> 
> ___
> 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] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Joe Taylor]

Hi Grant and all,

Thanks for reporting the bug in WSJT-X v2.1.0 that causes *Tx Enable* to 
be turned off when Fox sends RR73.  We knew about this issue and 
corrected it several months ago, back in August, but -- having received 
no complaints from users -- we have been waiting to issue a bug-fix 
release until several other issues are resolved.


We will schedule a release of WSJT-X v2.1.1 soon.

Your other request, to have standard "Band Activity" displayed when in 
Fox mode, will not be addressed in v2.1.1.  Code for Fox mode is based 
on an understanding that you (the Fox) will have a well-advertised band 
segment to yourself.


Have you tried simply running a second instance of WSJT-X, in normal 
mode, so that you can monitor what's going on in a difficult situation?


-- 73, Joe, K1JT


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

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Neil Zampella]

FWIW ... we've not heard from any of the developers on this yet.   I
suspect Bill and Joe may have been busy over the weekend. Wouldn't
it be a good idea to first hear from them before any changes are
made?    There could be a regression that crept in and they never
realized, or other reason for the problem seen.

Neil, KN3ILZ

On 11/18/2019 6:52 AM, David Tiller wrote:

I’m no expert on Fox/hound, but could you use an audio file (either
‘played’ via the wsjtx menu item or via a virtual audio cable) to
simulate the hounds? You could create as many hounds as you like in
whatever state you need to reproduce the issue.

On Nov 18, 2019, at 06:46, Grant VK5GR mailto:vk5gr.ra...@gmail.com>> wrote:


Dave,

To prove the fix you would probably need about 8-10 hounds in fact to
see the behaviour properly and confirm it is no longer doing it.

Having said that, I am sure I can round up some willing test
volunteers across VK and work with you on the testing if that would help.

Regards

Grant VK5GR

*From:*Dave Slotter, W3DJS [mailto:slotter+w3...@gmail.com]
*Sent:* Monday, 18 November 2019 6:34 AM
*To:* WSJT software development
*Subject:* Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode
Operator enhancement request

I agree that these are reasonable requests. If Bill et al cannot find
time to address, as a software engineer who has actually modified the
WSJT-X code to fix an Enable button defect, I'd be willing to fix
these unwanted Fox mode behaviors.

BUT... (There's always a but, isn't there?) I'd need 2-3 Hounds to
test the Enable button fix.

-Dave

 W3DJS

___
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] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Bill Barrett]

Using iPod etc earphone/microphone scotch tape the earphone to the
microphone so the transmitted audio feeds back to the microphone input.
Configure and start 5 or more instances of WSJT-X with different call
letters/frequencies as Hounds along with the Fox instance.
Have the Fox call CQ and respond with each Hound instance, test away.
Hope his helps.

On Mon, Nov 18, 2019 at 8:29 AM David Tiller 
wrote:

> I’m no expert on Fox/hound, but could you use an audio file (either
> ‘played’ via the wsjtx menu item or via a virtual audio cable) to simulate
> the hounds? You could create as many hounds as you like in whatever state
> you need to reproduce the issue.
>
> On Nov 18, 2019, at 06:46, Grant VK5GR  wrote:
>
> Dave,
>
>
>
> To prove the fix you would probably need about 8-10 hounds in fact to see
> the behaviour properly and confirm it is no longer doing it.
>
>
>
> Having said that, I am sure I can round up some willing test volunteers
> across VK and work with you on the testing if that would help.
>
>
>
> Regards
>
> Grant VK5GR
>
>
>
>
>
> *From:* Dave Slotter, W3DJS [mailto:slotter+w3...@gmail.com
> ]
> *Sent:* Monday, 18 November 2019 6:34 AM
> *To:* WSJT software development
> *Subject:* Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator
> enhancement request
>
>
>
> I agree that these are reasonable requests. If Bill et al cannot find time
> to address, as a software engineer who has actually modified the WSJT-X
> code to fix an Enable button defect, I'd be willing to fix these unwanted
> Fox mode behaviors.
>
>
>
> BUT... (There's always a but, isn't there?) I'd need 2-3 Hounds to test
> the Enable button fix.
>
>
>
> -Dave
>
>  W3DJS
>
> ___
> 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] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[David Tiller]

I’m no expert on Fox/hound, but could you use an audio file (either ‘played’ 
via the wsjtx menu item or via a virtual audio cable) to simulate the hounds? 
You could create as many hounds as you like in whatever state you need to 
reproduce the issue.

On Nov 18, 2019, at 06:46, Grant VK5GR 
mailto:vk5gr.ra...@gmail.com>> wrote:

Dave,

To prove the fix you would probably need about 8-10 hounds in fact to see the 
behaviour properly and confirm it is no longer doing it.

Having said that, I am sure I can round up some willing test volunteers across 
VK and work with you on the testing if that would help.

Regards
Grant VK5GR


From: Dave Slotter, W3DJS [mailto:slotter+w3...@gmail.com]
Sent: Monday, 18 November 2019 6:34 AM
To: WSJT software development
Subject: Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator 
enhancement request

I agree that these are reasonable requests. If Bill et al cannot find time to 
address, as a software engineer who has actually modified the WSJT-X code to 
fix an Enable button defect, I'd be willing to fix these unwanted Fox mode 
behaviors.

BUT... (There's always a but, isn't there?) I'd need 2-3 Hounds to test the 
Enable button fix.

-Dave
 W3DJS
___
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] FT8 Fox and Hound Mode - FOX Mode Operator enhancement

[Tom Ramberg via wsjt-devel]

Frode, I had to re-read your Norwegian ranslation of the maual after reading 
your mail, so that's the reason for replying late. In that manual, I cannot see 
that the need for enabling TX after every RR73 is mentioned at all. Please tell 
me if there is a point here that I have overlooked.

I tried FOX (WSJT-X, 2.1.0) on my last trip to Svalbard. I see you are 
emphasising the "rare DX"here, and JW is hardly rare, even though the pileups, 
and thus demand, can be really big if conditions are there. I have never seen a 
definitien of "really rare", so if you suggest above a specific rating on the 
most wanted list, I find it hard to follow you. IMHO, "rare" is decided by the 
demand, and not a list position.  And I have a pileup when the right pane is 
completely red, and my own yellow TX line is scrolled up out of the window. So 
I took the chance, qsyed down from 7074 and started as FOX. I had the exact 
same experience as Rich describes. It was the same fun as running a pileup in 
any mode, I can tell you.

Now, on an earlier trip to JW-land, in March 2019, I did the same, but with v 
2.0.1 (I don't remember which RC#), and then I could "fill the queue", and TX 
did not stop as long as there were calls in the box. Wether this was 
intentional or not from the dev team I do not know, but operating as FOX, I 
thought it was great. I can assure you there was no unattended operation there! 
Since there is a limit to how "old" a call from a hound can be before it falls 
out of the que, you have to watch the queue constantly, keep in mind how many 
streams you want to operate - an important decision when the number of callers 
with weak signals are big - and keep the queue alive. By the way, I also think 
I had activated automatic logging (like in contest mode), but it is possible 
that my memory does not serve me right on that one.

Back to v 2.1.0 in October 2019, I expected the same behaviour, and lost 
several TX cycles because I was unprepared for the necessity to arm the tx 
button for every RR73 I sent. With  few repeats, and mostly operating 1 to 3 
streamsI was able to maintain  a qso rate of about 100/h. Without the lost TX 
cycles, it could have been - albeit slightly - higher.

So again, I support Rich's view. The need to push TX for every RR73 is not 
nesessary. The 15 seconds you have from the end of one TX cycle to the next are 
not hard to fill with chores.



73 de Tom - from time to time JW6VDA

Sendt fra min iPad Air 2

> 18. nov. 2019 kl. 12:48 skrev Frode Igland :
> 
> 
> As I read Rich's message in digest format, a response may already be given, 
> so my apologies if I repeat a previous reply. 
> 
> It seems like the check box under Settings - General - "Disable Tx after 
> sending 73" repeatedly creates some confusion. The mouse-over help text 
> describes exactly what checking this box does: "Turns off automatic 
> transmission after sending 73 or any other free text message". Nothing more 
> is implied, and specifically this does not mean that unchecking (the default 
> state) it enables automatic transmissions after sending 73. The opposite, or 
> the antithethical interpretation if you like, just does not apply, nor does 
> the mouse-over help text indicate that it applies. Specifically, unchecking 
> this box is no workaround to automatically create a red "Enable TX" button 
> again after sending 73. That would possibly create an FT8 QSO robot enabling 
> operations with no operator in attendance/control, which is illegal in many 
> (most/almost all?) countries. 
> 
> WSJT-X includes considerably more demanding modes than FT8, e.g. meteor 
> modes, where repeating the message after sending 73 may be required to 
> complete a QSO and is normal until a return 73 has been received. However, 
> sometimes the conditions are good even for these modes, and then it may be 
> desirable to not transmit again after sending 73. That is a case when you 
> check the box "Disable Tx after sending 73". For FT8 the general disabling of 
> "Enable TX" after sending your 73 is desired actions and cannot overridden in 
> standard WSJT-X, which has not prevented operators from creating robots.
> 
> Having not worked as a Fox, I am not in a position to jugde whether clicking 
> the "Enable TX" button is a sufficient PITA to enable DXpedition QSO robots. 
> However, even for expeditions to very rare DXCC entities (for which FT8 
> DXpedition mode is created), the requirement for a control operator applies. 
> Unattended FT8 QSO robots are no more legal in exotic places than other 
> places. I understand the clicking inconvenience, but as far as I understand, 
> all other modes used by DXpeditions require the operator to key the 
> transmitter for each exchange in a QSO, either by stepping on a foot switch 
> or a mike PTT button or by pressing a function key on a keyboard, so I don't 
> know if clicking the "Enable TX" button once per QSO is widely different or 
> too much to ask for FT8 Fox operations.

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Grant VK5GR]

Dave,

 

To prove the fix you would probably need about 8-10 hounds in fact to see the 
behaviour properly and confirm it is no longer doing it.

 

Having said that, I am sure I can round up some willing test volunteers across 
VK and work with you on the testing if that would help.

 

Regards

Grant VK5GR

 

 

From: Dave Slotter, W3DJS [mailto:slotter+w3...@gmail.com] 
Sent: Monday, 18 November 2019 6:34 AM
To: WSJT software development
Subject: Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator 
enhancement request

 

I agree that these are reasonable requests. If Bill et al cannot find time to 
address, as a software engineer who has actually modified the WSJT-X code to 
fix an Enable button defect, I'd be willing to fix these unwanted Fox mode 
behaviors.

 

BUT... (There's always a but, isn't there?) I'd need 2-3 Hounds to test the 
Enable button fix.

 

-Dave

 W3DJS

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

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement

[Grant VK5GR]

Frode,

 

As you have said you have never run FOX mode as a FOX. I can let you know that 
it is quite different to being a hound. I am not looking to turn it into a QSO 
robot and indeed if you read the logic I propose carefully and understand 
properly how FOX mode works you will come to see that the modification proposed 
will not yield that as a result. 

 

My request to modify the behaviour from “stop the transmitter after every time 
an RR73 is sent” to “only stop the transmitter when the operator selected 
caller queue is empty” (ie the last RR73 is sent or the 3 transmission timeout 
has occurred for all 5 potential QSO channels) will not turn it into a QSO 
robot. The operator still has to be actively there ADDING stations to the queue 
to keep the transmitter alive! When the operator stops adding stations to the 
queue and the queue empties then the software should rightly stop the 
transmitter. 

 

However as long as you have the operator having to hit enable after every 30 
second over invariably the operator will be late selecting it every now and 
then and the transmitter will only activate for part of a transmission as a 
result. This costs everyone a retry typically, which when there are only three 
retries before a callsign is kicked out of the queue, greatly enhances the 
chances of the QSO not completing at all. This wastes channel time, and causes 
angst among the hounds chasing us with lots of “Missing Log Record” requests 
which are indeed just incomplete QSOs.

 

NOTE: I am not looking for the behaviour to be changed for any other mode 
within WSJT. As it stands it works as it should for EVERY other mode. However 
no other mode has a 5 channel parallel QSO capability either. The issue with 
the parallel QSO capability is that an RR73 in one channel will kill the 
transmitter for the other 4 QSOs that are still in progress. It is destructive 
to say the least.

 

Regards,

Grant VK5GR – A35JT DXpedition Team Leader

 

P.S. As a FOX running 5 channels you see things quite differently after 2 
weeks. Mindless having to hit the enable button just to keep QSOs going all the 
time drove my crew to hate using it at all. As it is currently designed, the 
frustration felt by the A35JT team running it lead to an FT8 mutiny – resulting 
in them abandoning FT8 for a couple of days in favour of PSK and RTTY instead.

 

 

From: Frode Igland [mailto:frodeigla...@gmail.com] 
Sent: Monday, 18 November 2019 9:10 PM
To: WSJT software development
Subject: Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement

 

As I read Rich's message in digest format, a response may already be given, so 
my apologies if I repeat a previous reply. 

 

It seems like the check box under Settings - General - "Disable Tx after 
sending 73" repeatedly creates some confusion. The mouse-over help text 
describes exactly what checking this box does: "Turns off automatic 
transmission after sending 73 or any other free text message". Nothing more is 
implied, and specifically this does not mean that unchecking (the default 
state) it enables automatic transmissions after sending 73. The opposite, or 
the antithethical interpretation if you like, just does not apply, nor does the 
mouse-over help text indicate that it applies. Specifically, unchecking this 
box is no workaround to automatically create a red "Enable TX" button again 
after sending 73. That would possibly create an FT8 QSO robot enabling 
operations with no operator in attendance/control, which is illegal in many 
(most/almost all?) countries. 

 

WSJT-X includes considerably more demanding modes than FT8, e.g. meteor modes, 
where repeating the message after sending 73 may be required to complete a QSO 
and is normal until a return 73 has been received. However, sometimes the 
conditions are good even for these modes, and then it may be desirable to not 
transmit again after sending 73. That is a case when you check the box "Disable 
Tx after sending 73". For FT8 the general disabling of "Enable TX" after 
sending your 73 is desired actions and cannot overridden in standard WSJT-X, 
which has not prevented operators from creating robots.

 

Having not worked as a Fox, I am not in a position to jugde whether clicking 
the "Enable TX" button is a sufficient PITA to enable DXpedition QSO robots. 
However, even for expeditions to very rare DXCC entities (for which FT8 
DXpedition mode is created), the requirement for a control operator applies. 
Unattended FT8 QSO robots are no more legal in exotic places than other places. 
I understand the clicking inconvenience, but as far as I understand, all other 
modes used by DXpeditions require the operator to key the transmitter for each 
exchange in a QSO, either by stepping on a foot switch or a mike PTT button or 
by pressing a function key on a keyboard, so I don't know if clicking the 
"Enable TX" button once per QSO i

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement

[Frode Igland]

As I read Rich's message in digest format, a response may already be given,
so my apologies if I repeat a previous reply.

It seems like the check box under Settings - General - "Disable Tx after
sending 73" repeatedly creates some confusion. The mouse-over help text
describes exactly what checking this box does: "Turns off automatic
transmission after sending 73 or any other free text message". Nothing more
is implied, and specifically this does *not* mean that *un*checking (the
default state) it *en*ables automatic transmissions after sending 73. The
opposite, or the antithethical interpretation if you like, just does not
apply, nor does the mouse-over help text indicate that it applies.
Specifically, unchecking this box is no workaround to automatically create
a red "Enable TX" button again after sending 73. That would possibly create
an FT8 QSO robot enabling operations with no operator in
attendance/control, which is illegal in many (most/almost all?) countries.

WSJT-X includes considerably more demanding modes than FT8, e.g. meteor
modes, where repeating the message after sending 73 may be required to
complete a QSO and is normal until a return 73 has been received. However,
sometimes the conditions are good even for these modes, and then it may be
desirable to not transmit again after sending 73. That is a case when you
check the box "Disable Tx after sending 73". For FT8 the general disabling
of "Enable TX" after sending your 73 is desired actions and cannot
overridden in standard WSJT-X, which has not prevented operators from
creating robots.

Having not worked as a Fox, I am not in a position to jugde whether
clicking the "Enable TX" button is a sufficient PITA to enable DXpedition
QSO robots. However, even for expeditions to very rare DXCC entities (for
which FT8 DXpedition mode is created), the requirement for a control
operator applies. Unattended FT8 QSO robots are no more legal in exotic
places than other places. I understand the clicking inconvenience, but as
far as I understand, all other modes used by DXpeditions require the
operator to key the transmitter for *each* exchange in a QSO, either by
stepping on a foot switch or a mike PTT button or by pressing a function
key on a keyboard, so I don't know if clicking the "Enable TX" button once
per QSO is widely different or too much to ask for FT8 Fox operations.

man. 18. nov. 2019 kl. 01:03 skrev Rich Zwirko - K1HTV :

> Grant,
> By any chance could the problem described have been caused because under
> Settings, General tab you had the "Disable Tx after sending 73' check box
> checked? I don't know if this might be bypassed in the Fox mode. If not, it
> should be disabled automatically when the Fox mode is used.
>
> 73,
> Rich - K1HTV
>
> = = =
>
> VK5GR wrote:
>
> 2.   Secondly, and this was a MOST frustrating aspect of using the
> software. No matter what we did we couldn’t seem to find any settings that
> would stop the “Enable TX” button from being cancelled *every time* the
> FOX sent RR73 on any channel. Now it appears as though this is by design
> although I hope it is in fact a bug. Our view is that if the FOX operator
> had made the deliberate effort to load a station into the calling queue
> then *the enable TX button should remain active until the last station
> leaves the calling queue.*
> ___
> 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] FT8 Fox and Hound Mode - FOX Mode Operator enhancement

[Rich Zwirko - K1HTV]

Grant,
By any chance could the problem described have been caused because under
Settings, General tab you had the "Disable Tx after sending 73' check box
checked? I don't know if this might be bypassed in the Fox mode. If not, it
should be disabled automatically when the Fox mode is used.

73,
Rich - K1HTV

= = =

VK5GR wrote:

2.   Secondly, and this was a MOST frustrating aspect of using the
software. No matter what we did we couldn’t seem to find any settings that
would stop the “Enable TX” button from being cancelled *every time* the FOX
sent RR73 on any channel. Now it appears as though this is by design
although I hope it is in fact a bug. Our view is that if the FOX operator
had made the deliberate effort to load a station into the calling queue
then *the enable TX button should remain active until the last station
leaves the calling queue.*
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Dave Slotter, W3DJS]

I agree that these are reasonable requests. If Bill et al cannot find time
to address, as a software engineer who has actually modified the WSJT-X
code to fix an Enable button defect, I'd be willing to fix these unwanted
Fox mode behaviors.

BUT... (There's always a but, isn't there?) I'd need 2-3 Hounds to test the
Enable button fix.

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

Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Tom Ramberg via wsjt-devel]

For what it’s worth: I support Grant’s request, specially regarding the 
required need to hit “enable tx” almost constantly. 

Tom JW6VDA 


Sendt fra min iPhone

> 17. nov. 2019 kl. 06:30 skrev Grant VK5GR :
> 
> Folks,
>  
> Having returned home a few weeks ago from conducting the A35JT DXpedition to 
> the south Pacific, there are a number of things in FT8 fox mode that I feel 
> need urgent attention for future expeditions. Some of these are on the 
> critical list and some are workflow and control things that I will discuss at 
> a later date.
>  
> The two items on the critical list that I would encourage the team to quickly 
> address for the sake of current and near future expeditions are as follows:
>  
> 1.   There is a need to restore visibility of the band activity window 
> when you are in FOX operator mode (not hound mode). Right now, a classic 
> example of why FOX operators need access to this window is playing out of 
> 21091. Both YJ0FWA and TX7T are on 21091. As a FOX operator I am pretty sure 
> they have no idea that they are co channel. When you are in FOX mode, you 
> have no access to the band activity window and so cant see if someone else 
> starts up on the same frequency as you.
>  
> When I was in Tonga this was a problem too with 3 other major expeditions 
> running at the same time as A35JT. (it also drove us down to 14067 at times 
> to get away from all of the other activity with FT4 on 080, A82X on 084, ZK3A 
> on 090 and then not wanting to clobber the beacons on 100 or WSPR on 097 or 
> the ALE/Automated  stations above 100).
>  
> So can I please urgently request the development team consider re-instating 
> visibility of the Band Activity window as a high priority so that we can stop 
> having blind fox operators not knowing they are suddenly sharing the channel? 
> (consider that expedition operators do NOT always have access to Internet or 
> clusters to receive other warnings either).
>  
> 2.   Secondly, and this was a MOST frustrating aspect of using the 
> software. No matter what we did we couldn’t seem to find any settings that 
> would stop the “Enable TX” button from being cancelled every time the FOX 
> sent RR73 on any channel. Now it appears as though this is by design although 
> I hope it is in fact a bug. Our view is that if the FOX operator had made the 
> deliberate effort to load a station into the calling queue then the enable TX 
> button should remain active until the last station leaves the calling queue.
>  
> The old 2.0.1 version did work like this when unchecked the “stop 
> transmitting on RR73” option in settings - but had too many other problems 
> with logging to be usable. 2.1.0 however does not work the same way – and 
> even when that setting is unchecked it still stops transmitting whenever an 
> RR73 is sent regardless of the progression state of any other channels that 
> are active mid QSO at the time. The RR73 TX disable appears to work as an OR 
> function (when any channel sends RR73 shut down the TX) where it really needs 
> to be an AND function (when all channels have either sent their RR73 or have 
> timed out due to retries and have nothing more to send).
>  
> The impact of this is that as a FOX operator you are having to hit TX Enable 
> constantly particularly when multiple channels are running, in particular so 
> that you don’t break in progress QSOs that are not at RR73 stage on the other 
> channels. At night when our operator count was low (we had to sleep at some 
> stage), we would have one operator sitting in front of three transmitters VNC 
> networked to a common terminal running 3 band synchronous FT8 fox mode to 
> maintain a presence on the bands. He found that he was constantly hitting 
> enable in all three instances of WSJT – an activity that patently didn’t add 
> value to a QSO’s progression where it would have been better to spend more 
> time watching queue progression and managing sub-channel count to try to 
> increase the success of each QSO in progress.
>  
> For the developer’s consideration please?
>  
> Best Regards,
> Grant VK5GR – A35JT DXpedition Team Leader + E6AG, YJ0AG
>  
> Email: vk5gr.ra...@gmail.com
> Website: https://vk5gr-iota.net/
>  
>  
>  
> ___
> 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] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request

[Grant VK5GR]

Folks,

 

Having returned home a few weeks ago from conducting the A35JT DXpedition to
the south Pacific, there are a number of things in FT8 fox mode that I feel
need urgent attention for future expeditions. Some of these are on the
critical list and some are workflow and control things that I will discuss
at a later date.

 

The two items on the critical list that I would encourage the team to
quickly address for the sake of current and near future expeditions are as
follows:

 

1.   There is a need to restore visibility of the band activity window
when you are in FOX operator mode (not hound mode). Right now, a classic
example of why FOX operators need access to this window is playing out of
21091. Both YJ0FWA and TX7T are on 21091. As a FOX operator I am pretty sure
they have no idea that they are co channel. When you are in FOX mode, you
have no access to the band activity window and so cant see if someone else
starts up on the same frequency as you. 

 

When I was in Tonga this was a problem too with 3 other major expeditions
running at the same time as A35JT. (it also drove us down to 14067 at times
to get away from all of the other activity with FT4 on 080, A82X on 084,
ZK3A on 090 and then not wanting to clobber the beacons on 100 or WSPR on
097 or the ALE/Automated  stations above 100).

 

So can I please urgently request the development team consider re-instating
visibility of the Band Activity window as a high priority so that we can
stop having blind fox operators not knowing they are suddenly sharing the
channel? (consider that expedition operators do NOT always have access to
Internet or clusters to receive other warnings either).

 

2.   Secondly, and this was a MOST frustrating aspect of using the
software. No matter what we did we couldn't seem to find any settings that
would stop the "Enable TX" button from being cancelled every time the FOX
sent RR73 on any channel. Now it appears as though this is by design
although I hope it is in fact a bug. Our view is that if the FOX operator
had made the deliberate effort to load a station into the calling queue then
the enable TX button should remain active until the last station leaves the
calling queue. 

 

The old 2.0.1 version did work like this when unchecked the "stop
transmitting on RR73" option in settings - but had too many other problems
with logging to be usable. 2.1.0 however does not work the same way - and
even when that setting is unchecked it still stops transmitting whenever an
RR73 is sent regardless of the progression state of any other channels that
are active mid QSO at the time. The RR73 TX disable appears to work as an OR
function (when any channel sends RR73 shut down the TX) where it really
needs to be an AND function (when all channels have either sent their RR73
or have timed out due to retries and have nothing more to send). 

 

The impact of this is that as a FOX operator you are having to hit TX Enable
constantly particularly when multiple channels are running, in particular so
that you don't break in progress QSOs that are not at RR73 stage on the
other channels. At night when our operator count was low (we had to sleep at
some stage), we would have one operator sitting in front of three
transmitters VNC networked to a common terminal running 3 band synchronous
FT8 fox mode to maintain a presence on the bands. He found that he was
constantly hitting enable in all three instances of WSJT - an activity that
patently didn't add value to a QSO's progression where it would have been
better to spend more time watching queue progression and managing
sub-channel count to try to increase the success of each QSO in progress.

 

For the developer's consideration please?

 

Best Regards,

Grant VK5GR - A35JT DXpedition Team Leader + E6AG, YJ0AG

 

Email: vk5gr.ra...@gmail.com

Website:   https://vk5gr-iota.net/

 

 

 

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