Re: [wsjt-devel] Feature Request: Hound Mode

[Grant Willis via wsjt-devel]

Jim,

FYI - Neil and James don't believe a clear frequency matters based on past
conversations I have had with them. I contend they have never tried chasing
DX where every path starts at 8000 miles (ie out of VK). The standard FT8
channels are so congested these days that trying to target working
particular stations can be futile because I can't find (and don't know) a
clear RX slot at the other end of the path to try calling on. I have called
it the "hidden transmitter" syndrome in a conversation with Joe K1JT in the
past, but he didn't seem to understand the reference (it was an old
description of CSMA problems we used to have on AX.25 packet nets when not
everyone could hear everyone). A similar situation impacts the
decision making when picking a channel to transmit on today in FT8 - which
notably Phil Karn KA9Q also has picked up on in some of his recent posts to
the list.

As for the choice of 40m FT4 frequency - I had quite animated arguments
with Bill Somerville about it - and all logic fell on deaf ears. Through my
IARU global HF band planning reform proposals I am hoping we can finally
address that injustice.

Best regards,
Grant VK5GR
IARU R3 HF Band Planning Chair


On Mon, Oct 11, 2021 at 2:20 PM Jim Brown via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> On 10/10/2021 7:12 PM, Neil Zampella via wsjt-devel wrote:
> > as F/H specifically requires you to reply to a Fox CQ above 1000 hz, and
> > since the decoder decodes the entire passband based on the base
> > frequency set, you would not need any 'waterfall history' to determine
> > where to Tx your reply.
>
> Sure we do -- we want to choose a relatively clear frequency to TX, and
> you need that history to make that judgement call. And smart operators
> will occasionally skip TX for a sequence to see what might have changed.
>
> I had exactly that experience working S9OK today on 12M. Although
> they're not running F/H, they are multi-streamed using other software.
> By making what turned out to be a good choice of TX, I worked them with
> two calls from NorCal, an 8,000 mile path.
>
> 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] Feature Request: Hound Mode

[Grant Willis via wsjt-devel]

Neil,

I wish to take a moment please to outline what I see is the problem with
the configuration options as a solution that everyone keeps answering with
when this comes up. I dont think the case why the configuration mode
changes annoy many has ever been clearly articulated.

If I am tuning around the band and see some FT8, dial my receiver onto it
and see what is happening. If I see they are running in F/H mode - then if
I use configurations to change to that mode,  I need to often a) add a
frequency to the config, b) reselect the frequency I was just on and c)
loose the waterfall history I would want to use to pick where to drop my
transmitter to start calling.

In quick fire DX Chasing that is all lost time and multiplication of effort
that to be frank is a PITA.

The reason people keep asking for a button to switch to hound mode and back
on the main screen is so they can do what people should more naturally be
doing - that is spin the dial of their radio, look at what's on the band,
and then pick the right mode to work what they hear *quickly and
efficiently*. Sure the work arounds work - but they are clunky and kludgy
to a DX operator.

The alternative solutions might be - preserve the
frequency/band/sub-frequency settings across a configuration settings
change and get the waterfall not to be reset when you swap configurations.
I believe that would be much more work for the programming team than having
a simple tick switch linked to hound mode on / off on the main page. Having
said that, the developers have made it clear they are not interested - so
yes it is also a lost cause.

Oh and to those that say "grab the source and roll your own" - not everyone
can or has the time to write software and roll their own.

Regards,
Grant VK5GR





On Mon, Oct 11, 2021 at 11:55 AM Neil Zampella via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> In your case I would suggest create a separate CONFIGURATION for each mode
> you're using.You can setup one for regular use, then one for other
> special modes such as the NA VHF contest, Field Day, Fox & Hound, etc.
>
> All you need to do is switch over to the mode you're going to use by
> selecting the configuration.
>
> I've been using this feature since it was first created.
>
> Neil, KN3ILZ
> On 10/10/2021 6:12 PM, Dennis Younker NE6I wrote:
>
> Put me down for also wishing to have that on the main screen. Or more
> accurately in my case, having a check box or link on the main screen that
> is linked to Special Operating Activity. Yes, handy to quickly go to and
> from F/H mode but also convenient at the start and end of one of the
> contests listed on the Advanced tab. I have, for example, operated an NA
> VHF Contest over a weekend and then forgot to uncheck the box after the
> contest. And then been bitten for a moment later in the week when operating
> normal FT8 or MSK.
>
>
>
> I am not a programmer and not interested in becoming one (again). It’s
> great that the source code is available for anyone to modify to their
> heart’s content but I’m not interested in doing that. I did a lot of
> programming and compiling of code several decades ago, and spent MANY an
> all nighter doing that. That ship has now sailed for me, and I’m not
> interested in getting on board again.
>
>
>
> I am hugely appreciative of K1JT and the entire WSJT-X team for their
> work. I for one know how much time and effort goes into this. It’s truly a
> labor of love.
>
>
>
> --Dennis NE6I
>
>
>
> *From:* Jeff Stillinger via wsjt-devel 
> 
> *Sent:* Sunday, October 10, 2021 9:53 AM
> *To:* WSJT software development 
> 
> *Cc:* Jeff Stillinger  
> *Subject:* Re: [wsjt-devel] Feature Request: Hound Mode
>
>
>
> Not exactly a secret.  For building on Microsoft virus, the sdk is located
> here:
>
> https://sourceforge.net/projects/jtsdk/
>
> It is my understanding that it's going through some updates, but what is
> posted should work.  Last time I played with it was back in version 1.7.  I
> haven't kept up with that platform since I do everything on Linux.
>
>
>
> On 10/10/21 10:43 AM, Jon Anhold wrote:
>
> Hi Jeff,
>
>
>
> Yes, I agree - I am a contributor to some other open source projects.
> Thanks for your helpful suggestion.
>
>
>
> I've given that some thought, but at least the last time I looked the
> build process / toolkit for building WSJT-X on Windows is like top secret
> or something, and I haven't spent any time recently trying to uncover it or
> get it to build.
>
>
>
> Also, unfortunately, it doesn't seem that the authors are very open to
> pull requests, so I make feature suggestions here.
>
>
>
> Thanks & 73 de KM8V Jon
>
>
>
> On Sun, Oct 10, 2021 at 9:37 AM Jeff Stillinger via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
> How about an alternative to your prediction.   WSJT-X is open source.  You
> have complete access to the source code, and one of the wonderful
> conveniences of the package is the ability to customize the software to a
> 

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

[Grant Willis]

Steve,

Sorry that is my mistake. It was an incorrect memory based on when I was
reviewing the ALL.TXT file trying to find broken log records when we got
home after A35JT. (I had discovered that ALL.TXT didnt store the TX strings
from the FOX transmissions - instead it only stored one string and  not the
contents of the up to 5 FOX TX channels). I incorrectly turned my
conclusion of 5 weeks ago that ALL.TXT was incomplete when it came to
tracing broken log entries into the incorrect memory/assumption that
ALL.TXT didnt have the fox band activity data in it at all.

My apologies for making an invalid later assumption that ALL.TXT didnt have
FOX channel traffic at all. Goes to show one should never assume anything
as it makes one look like an ASS - sorry about that. An unnecessary
distraction to the real debate about band activity visualisation in FOX
mode.

So to clarify - ALL.TXT does appear to log the FOX Channel receive activity
and running a tail job in a separate window would provide band activity
monitoring needed to detect channel collisions.

The debate however then becomes is that something that the majority of FOX
operators would know how to do? My suggestion is that it isn't. Finding a
better solution to warning FOX operators that there are people on their
channel calling other expeditions is still very important in my mind.
Taking rows from the Band activity where the FOX station callsign is not
even present and putting them into the RX activity window would be a good
start to enabling a channel self monitoring function inside the software
IMHO.

As an aside - looking back at ALL.TXT - it does raise a point. The contents
of the TX channels that are sent over the air in FOX mode are not being
recorded in ALL.TXT currently. Is that by design or is that a BUG?

In fact it is very strange that RX records are still being written when I
an transmitting in the next cycle. I enclose a sample of my ALL.TXT file
here. It might reveal more of whats going on? I can send the whole file
along with the FOXQSO.TXT file if it would help try to get a handle on
whats actually going on with ALL.TXT?

190929_00393014.067 Rx FT8 -2  0.0 1895 A35JT VK5BC PF95
190929_00393014.067 Tx FT8  0  0.0  538 VK3BDX A35JT RR73
 <-- I answered more than VK3BDX in this over
190929_00393014.067 Rx FT8 -2  0.4 2112 A35JT 6K5YIA PM45
<--  am still receiving even though my TX is up for the next over?
190929_00393014.067 Rx FT8 11 -0.0 2294 A35JT XE1TD DL80
190929_00393014.067 Rx FT8  9  0.0 2460 A35JT VE7SV CN99
190929_00393014.067 Rx FT8-14  0.0 2972 A35JT N5WXY R-09
190929_00393014.067 Rx FT8  3  0.0 3071 A35JT JH0INP PM96
190929_00393014.067 Rx FT8-14  0.2 1037 A35JT VK3GWS QF22
190929_00393014.067 Rx FT8 -8  0.1 1088 A35JT JG3KLF PM74
190929_00393014.067 Rx FT8-19  0.0 1544 A35JT N2AJ FN30
190929_00394514.067 Rx FT8 -4  0.0 1019 A35JT K9NU EN55
190929_00394514.067 Rx FT8 -9  0.1 1088 A35JT JG3KLF PM74
190929_00394514.067 Rx FT8 -4  0.1 1274 A35JT W7DN CN85
190929_00394514.067 Rx FT8-10  0.4 1337 A35JT KI5BLU CN87
190929_00394514.067 Rx FT8  5  0.1 1388 A35JT VE3VEE EN94
190929_00394514.067 Rx FT8 -4  0.2 1495 A35JT PP2FRS GH63
190929_00394514.067 Rx FT8 -7 -0.2 1599 A35JT K5GS DM42
190929_00394514.067 Rx FT8  1  0.0 1689 A35JT JR1JYR PM95
190929_00400014.067 Tx FT8  0  0.0  538 VK3BDX A35JT RR73  <-- same
string grabbed again by the SW but I answered others
190929_00400014.067 Rx FT8 -2  0.0 1821 A35JT KQ5M DM65   <---
still receiving things after I started TX
190929_00400014.067 Rx FT8 -6 -0.0 1895 A35JT VK5BC PF95
190929_00400014.067 Rx FT8  3  0.0 2057 VK6MIT AA4M DM42
190929_00400014.067 Rx FT8 -8  0.4 2112 A35JT 6K5YIA PM45
190929_00400014.067 Rx FT8  6  0.0 2295 A35JT XE1TD DL80
190929_00400014.067 Rx FT8  1  0.0 2459 A35JT VE7SV CN99
190929_00400014.067 Rx FT8-13  0.0 2510 A35JT N5WXY R-13
190929_00400014.067 Rx FT8-15  0.2 2993 A35JT JA6KLP PM53
190929_00400014.067 Rx FT8  4  0.0 3072 A35JT JH0INP PM96
190929_00400014.067 Rx FT8-11  0.3 1036 A35JT VK3GWS QF22
190929_00401514.067 Rx FT8  4  0.0  596 A35JT NU1O R-15
190929_00401514.067 Rx FT8  2  0.0 1018 A35JT K9NU EN55
190929_00401514.067 Rx FT8-11  0.3 1337 A35JT KI5BLU CN87
190929_00401514.067 Rx FT8-12  0.2 1358 A35JT YV5AJ FK60
190929_00401514.067 Rx FT8  2  0.7 1514 A35JT VK3OD QF22
190929_00401514.067 Rx FT8 -3  0.1 1598 A35JT K5GS DM42
190929_00401514.067 Rx FT8-15  0.4 1684 A35JT W9ZCL EN62
190929_00401514.067 Rx FT8  3  0.0 1774 A35JT W5XU EM40
190929_00401514.067 Rx FT8  1  0.0 1821 A35JT KQ5M DM65
190929_00403014.067 Tx FT8  0  0.0  538 VK3BDX A35JT RR73

190929_00403014.067 Rx FT8 -4 -0.0 1895 A35JT VK5BC PF95
190929_00403014.067 Rx FT8  

Re: [wsjt-devel] setting an NTP time service in windows

[Grant Willis]

FWIW I have used this software on DXPeditions to Niue and Vanuatu since
July 2017 - works a treat.

On Thu, Dec 6, 2018 at 10:28 AM Stephen Ireland  wrote:

> Folks,
>
>
>
> This article, written by me and co-authored with Roger VK3FZ, was
> published  in the September 2018 edition of “Amateur Radio” – the Journal
> of the Wireless Institute of Australia.
>
>
>
> It details a relatively inexpensive software tool ($20) and cheap GPS
> modules (Ebay - $10) that can be used to synchronise our PCs off the
> constellation of GPS satellites and their inbuilt atomic clocks.
>
>
>
> It was written with wsjt-x in mind...
>
>
>
> Perhaps someone could create a module that could be deployed into WSJT-X
> to support these UBLOX modules and/or other well-structured NMEA-data
> sources?
>
>
>
> 73
>
>
>
> Steve I
>
> VK3VM / VK3SIR
>
>
>
>
>
>
>
> Sent from Mail  for
> Windows 10
>
>
> --
> *From:* Al Flapan 
> *Sent:* Thursday, December 6, 2018 9:07:29 AM
> *To:* WSJT8
> *Subject:* [wsjt-devel] setting an NTP time service in windows
>
> Here is an article on how to set a time service in Windows using the
> registry.
>
> Al  AF4FA
>
> https://timetoolsltd.com/time-sync/configuring-a-windows-time-server/
>
>
>
> ___
> 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] Frequency Management in Contest Mode.

[Grant Willis]

Ill do some more checking and try to reproduce. I didn’t have enough time this 
morning to explore further.

Regards,
Grant Willis

> On 3 Dec 2018, at 8:19 am, Bill Somerville  wrote:
> 
>> On 02/12/2018 21:22, Grant VK5GR wrote:
>> I double clicked on his call in the Band Activity window and then wondered 
>> why he disappeared. After about 90 seconds I glanced over at my SDR and 
>> realised my signal was in the lower cluster of signals – looked at the rig 
>> and realised it had jumped back to 7074.
> 
> Hi Grant,
> 
> that's not supposed to happen. Was it the double-clicking of a call that 
> caused it to skip to a preset frequency or something else? Is it reproducible?
> 
> 73
> Bill
> G4WJS.
> 
> 
> 
> ___
> 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] Observation on Expedition Mode

[Grant Willis]

.
> 
> Regards,
> 
> take
> 
> de JA5AEA
> 
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows 10
> 
> 
> *From:* Grant Willis 
> *Sent:* Tuesday, July 3, 2018 7:05:09 AM
> *To:* 'WSJT software development'
> *Subject:* Re: [wsjt-devel] Observation on Expedition Mode
> 
> Everyone,
> 
> The thread hi-jacking has been interesting but time to bring it back to 
> my original question perhaps please?
> 
> Take,
> 
> Yes – the problem with varying power is I might hear him CQ when he 
> transmits with only one channel but when -14dB of power reduction 
> results from 5 responses I could loose him )and did do so several 
> times). The CW and the power of the channels I am listening to of him 
> calling everyone else needs to remain constant as an individual channel 
> otherwise this wildly varying link budget just breaks contacts.
> 
> A worthy modification would be to resolve the varying individual channel 
> power dilemma I feel. I would be interested in Joe and Steve’s thoughts 
> on this?
> 
> Regards,
> 
> Grant VK5GR
> 
> P.S. The CQ calling is nice – and KH1/KH7Z could make better use of it 
> and free text to control their pile more – but blocking people calling 
> as proposed by others here until certain preconditions are met – based 
> on my observations of the traffic patterns I don’t see it helping the 
> situation at all.
> 
> *From:*Tsutsumi Takehiko [mailto:ja5...@outlook.com]
> *Sent:* Monday, 2 July 2018 3:09 PM
> *To:* WSJT software development
> *Subject:* Re: [wsjt-devel] Observation on Expedition Mode
> 
> Grant,
> 
> Allow me to write my comment on your topic as I have same topic interest 
> writing “FOX adaptive power control” in this thread.
> 
> Concerning your proposal, i.e.“to have the setting of number of channels 
> vs the number of active channels maintain a constant PER CHANNEL TX power”
> 
> My comment is
> 
>  1. When fox sets 5 slot mode and it activates 5 slots, the average
> power per channel is -20*LOG(5) dB=-14dB. This means about 20W per
> channel if fox uses 500W linear.
> 
>  2. When active channel is actually 1 slot, What does fox obtain the
> benefit to maintain link with a particular hound keeping 20W instead
> it can transmit 500W?  Please keep in mind fox uses his channel to
> send his message to particular fox such as “VK5GR KH7Z -05”, “VK5GR
> RR73”. It is not the messages to me JA5AEA.
> 
>  3. Instead,  I agree to keep CQ message to be fixed, i.e. 20W as this
> is a broad cast message. If fox sends 500W, it is disastrous.
> (KH1/KHZ may be confusing us and creating lengthy arguments by this
> high power CQ feature??)
> 
> Regards,
> 
> take
> 
> de JA5AEA
> 
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows 10
> 
> 
> 
> *From:*Grant Willis 
> *Sent:* Saturday, June 30, 2018 9:47:02 PM
> *To:* 'WSJT software development'
> *Subject:* [wsjt-devel] Observation on Expedition Mode
> 
> Joe,
> 
> An observation if I may about expedition mode. I see with KH1/KH7Z that 
> the number of Fox TX channels varies – I presume as they place more 
> stations in the queue. As expected, the power per channel drops the more 
> channels running so that the amplifiers can keep up. However, this has 
> an unintended consequence perhaps of potentially breaking QSOs. A few 
> times now I have started calling KH1/KH7Z on 20m when I am receiving 
> them around -09 (but with pretty low S-meter  signal strength). Usually 
> this is with 1-2 channels running on their downlink. If they go to 3 
> channels I can still receive but it falls to say -15. If they bring up 
> channel 4 and 5 I loose them. There just isn’t the link budget left to 
> receive them when the power is split between more than 3 channels in 
> this example.
> 
> Now the issue is, if they answer me by adding the 4^th channel – I wont 
> hear them under those conditions. If I am part way through a QSO I can 
> loose the RR73 for the same reason if they answer someone else on the 
> 4^th channel– simply because the link runs out of steam.
> 
> Now if I couldn’t hear them in the first place I wouldn’t have tried 
> calling. In this case however, they can disappear under load effectively 
> and I loose them mid QSO.
> 
> For future consideration perhaps is to have the setting of number of 
> channels vs the number of active channels maintain a constant PER 
> CHANNEL TX power rather than the variable situation we have now. Ie I 
> enable my fox 

Re: [wsjt-devel] Observation on Expedition Mode

[Grant Willis]

Everyone,

 

The thread hi-jacking has been interesting but time to bring it back to my
original question perhaps please?

 

Take,

 

Yes - the problem with varying power is I might hear him CQ when he
transmits with only one channel but when -14dB of power reduction results
from 5 responses I could loose him )and did do so several times). The CW and
the power of the channels I am listening to of him calling everyone else
needs to remain constant as an individual channel otherwise this wildly
varying link budget just breaks contacts.

 

A worthy modification would be to resolve the varying individual channel
power dilemma I feel. I would be interested in Joe and Steve's thoughts on
this?

 

Regards,

Grant VK5GR

 

P.S. The CQ calling is nice - and KH1/KH7Z could make better use of it and
free text to control their pile more - but blocking people calling as
proposed by others here until certain preconditions are met - based on my
observations of the traffic patterns I don't see it helping the situation at
all. 

 

From: Tsutsumi Takehiko [mailto:ja5...@outlook.com] 
Sent: Monday, 2 July 2018 3:09 PM
To: WSJT software development
Subject: Re: [wsjt-devel] Observation on Expedition Mode

 

Grant,

 

Allow me to write my comment on your topic as I have same topic interest
writing "FOX adaptive power control" in this thread.

 

Concerning your proposal, i.e."to have the setting of number of channels vs
the number of active channels maintain a constant PER CHANNEL TX power"

 

My comment is 

 

1.  When fox sets 5 slot mode and it activates 5 slots, the average
power per channel is -20*LOG(5) dB=-14dB. This means about 20W per channel
if fox uses 500W linear.

 

2.  When active channel is actually 1 slot, What does fox obtain the
benefit to maintain link with a particular hound keeping 20W instead it can
transmit 500W?  Please keep in mind fox uses his channel to send his message
to particular fox such as "VK5GR KH7Z -05", "VK5GR RR73". It is not the
messages to me JA5AEA.

 

3.  Instead,  I agree to keep CQ message to be fixed, i.e. 20W as this
is a broad cast message. If fox sends 500W, it is disastrous. (KH1/KHZ may
be confusing us and creating lengthy arguments by this high power CQ
feature??)

 

Regards,

 

take

 

de JA5AEA

 

Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986>  for Windows
10

 

 

  _  

From: Grant Willis 
Sent: Saturday, June 30, 2018 9:47:02 PM
To: 'WSJT software development'
Subject: [wsjt-devel] Observation on Expedition Mode 

 

Joe,

 

An observation if I may about expedition mode. I see with KH1/KH7Z that the
number of Fox TX channels varies - I presume as they place more stations in
the queue. As expected, the power per channel drops the more channels
running so that the amplifiers can keep up. However, this has an unintended
consequence perhaps of potentially breaking QSOs. A few times now I have
started calling KH1/KH7Z on 20m when I am receiving them around -09 (but
with pretty low S-meter  signal strength). Usually this is with 1-2 channels
running on their downlink. If they go to 3 channels I can still receive but
it falls to say -15. If they bring up channel 4 and 5 I loose them. There
just isn't the link budget left to receive them when the power is split
between more than 3 channels in this example.

 

Now the issue is, if they answer me by adding the 4th channel - I wont hear
them under those conditions. If I am part way through a QSO I can loose the
RR73 for the same reason if they answer someone else on the 4th channel-
simply because the link runs out of steam.

 

Now if I couldn't hear them in the first place I wouldn't have tried
calling. In this case however, they can disappear under load effectively and
I loose them mid QSO.

 

For future consideration perhaps is to have the setting of number of
channels vs the number of active channels maintain a constant PER CHANNEL TX
power rather than the variable situation we have now. Ie I enable my fox
station to run say 4 channels, but only reply on 1 channel, then the output
power should be the equivalent of the power that would be in that channel if
all 4 were in fact on air but aren't. At least that way I have a constant
link budget I am working with on my comms channel with the fox station
rather than one that can have them drastically cut power mid QSO without
reference to the conditions on the path I am working them via.

 

If what I am describing is not how it is supposed to work already then there
is another factor at work somewhere in the chain to be explored. I would be
happy to discuss this further and use the KH1/KH7Z expedition to observe and
learn more about how the multi-channel nature of the mode works.

 

Regards,

Grant VK5GR

 

--
Check out the vibrant tech community on one of the world's most
enga

[wsjt-devel] Observation on Expedition Mode

[Grant Willis]

Joe,

 

An observation if I may about expedition mode. I see with KH1/KH7Z that the
number of Fox TX channels varies - I presume as they place more stations in
the queue. As expected, the power per channel drops the more channels
running so that the amplifiers can keep up. However, this has an unintended
consequence perhaps of potentially breaking QSOs. A few times now I have
started calling KH1/KH7Z on 20m when I am receiving them around -09 (but
with pretty low S-meter  signal strength). Usually this is with 1-2 channels
running on their downlink. If they go to 3 channels I can still receive but
it falls to say -15. If they bring up channel 4 and 5 I loose them. There
just isn't the link budget left to receive them when the power is split
between more than 3 channels in this example.

 

Now the issue is, if they answer me by adding the 4th channel - I wont hear
them under those conditions. If I am part way through a QSO I can loose the
RR73 for the same reason if they answer someone else on the 4th channel-
simply because the link runs out of steam.

 

Now if I couldn't hear them in the first place I wouldn't have tried
calling. In this case however, they can disappear under load effectively and
I loose them mid QSO.

 

For future consideration perhaps is to have the setting of number of
channels vs the number of active channels maintain a constant PER CHANNEL TX
power rather than the variable situation we have now. Ie I enable my fox
station to run say 4 channels, but only reply on 1 channel, then the output
power should be the equivalent of the power that would be in that channel if
all 4 were in fact on air but aren't. At least that way I have a constant
link budget I am working with on my comms channel with the fox station
rather than one that can have them drastically cut power mid QSO without
reference to the conditions on the path I am working them via.

 

If what I am describing is not how it is supposed to work already then there
is another factor at work somewhere in the chain to be explored. I would be
happy to discuss this further and use the KH1/KH7Z expedition to observe and
learn more about how the multi-channel nature of the mode works.

 

Regards,

Grant VK5GR

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Expeditionj & Standard Mode Enhancement Requests - from an expeditioner's perspective

[Grant Willis]

Hello,

 

I recently returned home having run a mini DXPedition from Vanuatu for 2
weeks in the South Pacific as YJ0AG. While there I ran a lot of FT8
operations among other modes. At Joe's request I deliberately did not run
expedition mode, and can see that real problems are going to arise if a way
to control access to expedition mode as a Fox is not hard coded into the
software before the GA release. At the same time, if you can't run
expedition mode, there are some enhancements that I would have found very
valuable running FT8 pileups from Vanuatu in standard mode (where I still
reached 50 contacts/hr). I am hoping perhaps some of these could be taken on
board by the developer team.

 

Expedition Mode Useability Feedback

 

Firstly, for Expedition Mode, access control to the mode is paramount before
pandemonium reigns. We are already seeing expeditions trying to use it on
the main FT8 channels (ignoring the fact that it isn't supposed to be used
yet). I would strongly recommend the following additions to the software be
considered prior to GA release:

 

1.  Can access to expedition mode only be via a time restricted key -
expeditions planning to use the mode as a FOX have to apply for a key
against an expedition callsign that the software is programmed to recognise
as only valid between certain dates. You have to have the key and enter the
correct callsign to enable fox mode. Make sure of course that the key cant
be decrypted back or reverse engineered (goes without saying probably). 

 

a.  To support this I see that there would need to be an application portal
perhaps via the WSJT website where expedition operators can apply for
expedition mode access, and potentially have this administered through 2-3
of the major DX Associations - eg NCDXF, CDXC etc

 

In this way you can minimise the risk of FOXs proliferating when the people
are not really expeditions. The definition of expediton may also need to be
considered as any operator in a rare DXCC entity that has regular pileup
situations to contend with (eg XZ2A in Myanmar, 9G1SD in Ghana, VK0AI on
Macquarie Is etc).

 

2.  Can expedition mode only be activated in the software when the selected
radio frequency is NOT one of the main FT8 channels? Lock it out so that you
cant turn on fox or hound mode if you are on one of 1840, 3573, 7074, 10136,
14074, 18100, 21074, 24915 or 28074? Other proposed Expedition mode
frequencies are included in the software so let it only be activated away
from the main channels?

 

These two steps should prevent widespread abuse of expedition mode. 

 

Standard Mode Useability Feedback

 

In standard mode when faced with a major pileup, the following ideas would
be very helpful. These are mostly GUI changes.

 

1.  In standard mode there is a simple tweak to the GUI that would be
helpful. When I am being called currently I get everyone coming back marked
in RED - I can have up to 50 stations replying (and did when I was running
YJ0AG last month). Now I do not always let it run with call first for
various reasons - mlostly revolving around trying to provide ATNOs or target
particular call areas). What would be really handy is if the station I was
actually working who was listed in my message sequencves was in a colour
other than the colour of the stations calling me. I could pick them out much
easier if I wanted to follow their sequence and make sure the contact didnt
just stall for some reason. (I do watch very closely otherwise I found if
you get stuck on someone having issues you can loose minutes and badly hit
your contact rate).

 

2.  If I am observing things correctly, the call first is taking the first
station on the decode list. I find with pileup situations where there is a
dominant country that is not the area I want to work (say for example Japan)
I have to disable call first and make my selections by hand to get around
it. This list appears to be populated with the lowest station on the band or
it seems sometimes the lowest plus strongest which is I presume because it
was decoded in the first  pass, with the weaker lower stations  being
decoded on the second pass. What would help this is some sort of
randomisation function within the call first algorithm that ignores the
"first decoded" and instead calls a random station from the list. It would
reduce the chances of being dominated by strong stations from one area low
in the band to the detriment of other fainter stations which otherwise have
no hope of being picked unless the callers from the dominant country stop
calling. I can see there are issues where on slow processors with deep
decoding selected you might still be finishing up the decoding process
before the next slot - but from a practical standpoint that doesn't really
matter when the pile is 20 deep - you will pick someone - and if there is no
pile - you will pick whomever you decode anyway.

 

3.  More controversially - provide a call first filter mechanism. The need
to black list 

Re: [wsjt-devel] Second Public Test of FT8 DXpedition Mode: April 7, 1400-1600 UTC

[Grant Willis]

That looked to be a pirate – 3B7A was working 20CW at the time and I could hear 
them here but I couldn’t hear their RTTY signal (de Grant VK5GR)

 

From: Andras Bato [mailto:ha6nn.a...@gmail.com] 
Sent: Sunday, 8 April 2018 12:38 AM
To: WSJT software development
Subject: Re: [wsjt-devel] Second Public Test of FT8 DXpedition Mode: April 7, 
1400-1600 UTC

 

Stop someone that 3B7A Agalega Island RTTY station whose pile up buried the 
test subband!!!

gl de ha6nn

Andras

 

On Sat, Apr 7, 2018 at 2:38 PM, Gene Marsh  wrote:

Joe and the group:

First, no propagation in northeast OH for the first test. Bummer.

Second, maybe I’m confused (as usual):
-  I thought signals below 1000Hz are ignored?  Many are. Some are not.
-  I thought the Hounds were expected to transmit above 1000Hz and the Fox 
would ignore below?

See the attached picture.


73 de W8NET Gene
3905 Century Club Master #47
Portage County Amateur Radio Service (PCARS) since 2008
ARRL A-1 Op




> On Apr 5, 2018, at 10:49 AM, Joe Taylor  wrote:
>
> Hi all,
>
> I write to remind you of the second public test of *FT8 DXpedition Mode* 
> scheduled for Saturday, April 7, 1400-1600 UTC.  You are cordially invited to 
> participate -- the more participants, the better!
>
> Our main goal is to simulate pileups in which many "Hounds" call and attempt 
> to work a desirable rare DX station, the "Fox".  The test will help us to 
> improve our software so as to maximize the practical QSO rate in such 
> situations.  We hope you can be there and try to work both Foxes.
>
> Here's the detailed schedule:
>
> Date  UTC   FrequencyFox Callsign  Operator
> ---
> April 7  1400   14.105 MHzW1/KH7Z   N1DG
> April 7  1500   14.105W7/KH7Z   AA7A
>
> All participating stations must use program version WSJT-X v1.9.0-rc3. If you 
> don't yet have it, download links are available near the bottom of the page 
> here:
> https://physics.princeton.edu/pulsar/k1jt/wsjtx.html
>
> [If you are compiling the program for yourself, be sure to use code revision 
> r8576 or later, taken from the repository's WSJT-X development branch.  All 
> revisions since r8576 will perform identically in FT8 DXpedition Mode.]
>
> Detailed instructions for both Fox and Hound are posted here:
> http://physics.princeton.edu/pulsar/k1jt/FT8_DXpedition_Mode.pdf
> Some details in these instructions have changed, so be sure to read and 
> follow the latest instructions carefully!  Don't just try to wing it.
>
> As you will know after reading the instructions, Fox can conduct up to 5 QSOs 
> simultaneously, using frequency slots spaced by 60 Hz.  Fox transmissions 
> always occur in the frequency range 300-900 Hz above dial frequency.
>
> If you (as a Hound) can legitimately use more than one callsign -- your 
> spouse's call, club call, etc. -- feel free to work each Fox multiple times.  
> No dupe QSOs with the same call, though.
>
> Real-time liaison will be available on the "Ping Jockey Relief" chat page 
> (PJB), https://www.pingjockey.net/cgi-bin/pingtalkB .  Everyone should 
> monitor this page for possible last-minute announcements of a frequency 
> change, etc.  To ensure that announcements from Fox stations are easily 
> visible, Hounds should monitor PJB but not post messages there during the 
> test.
>
> The deepest pileups will help us tune the final-release software version for 
> optimum performance on both Fox and Hound sides.  After the test, please post 
> any comments you feel will be helpful to one of our two email forums, 
> wsjtgr...@yahoogroups.com or wsjt-devel@lists.sourceforge.net .  You will 
> need to be subscribed to the list in order to post there.
>
> We sincerely hope you can join us for this test, and that you will work both 
> Foxes!
>
>-- 73, Joe, K1JT (for the WSJT Development Group)
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net

Re: [wsjt-devel] Premature use of FT8 DXpedition Mode

[Grant Willis]

Joe,

I am new to this list (having only realised it was open for me to subscribe to 
this week). I was also one of those pesky DXPedition stations who wanted to 
(and originally had intended to) use Expedition mode pre-GA when I reach 
Vanuatu on the 16th of April. 

I've now, out of respect of your now very clearly stated wishes this morning, 
made the decision that there will be no use of expedition mode from YJ0AG 
unless there is a GA release (which isn’t expected before the close of the 
expedition).. (see http://vk5gr-iota.net).

Having said that, if the testing team were willing to allow me to join in the 
testing effort, I would be more than willing to run it as part of an extended 
test from Vanuatu (only if you agreed). I would only, however, offer to do this 
if it could be structured in such a way as to be beneficial to the team here. 

I see this as a real world opportunity to evaluate just how it will react over 
a wide variety of bands, propagation types and times of day. This suggestion is 
made with the knowledge that the user community will not behave and will use 
the wrong version of software, not set the right mode, not set their CAT 
controls etc etc. I feel that those inputs are in fact valid considerations for 
any Beta test. The earlier versions of the software are out there now and in a 
real world situation you will not be able to avoid those operator errors. 
Consider it destructive testing. Surely it would be worthwhile to consider all 
the bad things it does as well as the good in finalising the design?

Of course, I would take all measures necessary to collect whatever logging and 
evidence your team requires in support of the testing. Ideally, (internet 
connectivity permitting) my intention would be to send you those logs whilst I 
am still on Vanuatu.

Please give my request to participate in the project some consideration. I am 
not a coder, but my observation and testing skills hopefully could make a 
worthwhile contribution if the team was willing to include me.

Regards,
Grant VK5GR / E6AG / YJ0AG - IOTA DXPeditioner

P.S. I realise I am unknown to this team. I offer the following  to perhaps set 
the tone for my request more properly: 

* I have worked professionally in the cellular telecoms engineering arena for 
over 25 years and more recently systems architecture areas. I have in that time 
been involved in complex software development processes (albeit not down at 
coding level) in particularly around high level requirements and test plan 
design and execution.

* I have been active in digital modes within the hobby for over 30 years having 
operated AX.25 networks, RTTY and PSK extensively as well as JT65, FT8, JT9 and 
others.

* I have backgrounds in IARU (I was the VK liaison for a number of years) and 
HF/VHF/UHF Band Planning through my previous engagements on the technical 
advisory board of the WIA. Though this work perhaps I could also offer some 
commentary and feedback on frequency selection. You will note from my blog I 
have elected to use alternate frequencies that differ from your proposals. I am 
happy to discuss my choices and justifications down the track.




-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: Friday, 30 March 2018 5:46 AM
To: WSJT software development
Subject: [wsjt-devel] Premature use of FT8 DXpedition Mode

Everyone paying attention should already know what's contained in this message 
-- but it's clear that some do not.

The current General Availability (GA) release of WSJT-X is v1.8.0.  That 
program version does not include FT8 DXpedition Mode.

We have made beta-level "release candidates" available for the explicit purpose 
of testing FT8 DXpedition Mode.  The release candidates have included 
cautionary warnings to the effect that in its present form, DXpedition Mode 
should be used only for controlled testing.

A few operators or groups have ignored our warnings and tried to use FT8 
DXpedition Mode in true pileup situations.  The consequences are predictably 
bad -- especially when the offending operator(s) have chosen their frequencies 
badly and other operators are using a mix of program versions including v1.8.0, 
v1.9.0-rc2, v1.9.0-rc3, some version of JTDX.

FT8 DXpedition Mode is not yet ready for “production” use. Until WSJT-X
v1.9.0 is fully released -- not a beta-level "release candidate", but a full 
General Availability release -- DXpedition Mode should be used only in 
controlled test situations.

The next public test of FT8 DXpedition Mode conducted by the WSJT Development 
Group will be conducted on April 7, a little over a week from now.  You are 
cordially invited to join us for this test.  See the announcement posted here 
yesterday (Subject: WSJT-X v1.9.0-rc3: Testing of FT8 DXpedition Mode) for 
details.

-- 73, Joe, K1JT

--
Check out the vibrant tech community on one of the world's most