Hi Rich,
It is my understanding from the way I ready the help file, the fox running WSJT_X calls CQ and transmits on offset below 1000HZ. The fox then decodes stations replying to his CQ or calling it above 1000HZ. A station running wsjt-x as hound, calls the fox above 1000 H. However, it only decodes messages below 1000Hz
When it detects the fox replying to it, its supposed to automatically switch to the offset of the fox below 1000HZ, and that is where it decodes all incoming messages. If I am not mistaken, it only attempts to decode messages below 1000Hz. 
If I am correct in my interpretation of the help file, that potentially can create a problem when the fox is running an alternate such as MSHV above 1000Hz. While the fox will decode the hound, the hound may stop decoding the fox.
Theoretically, while running WSJT-X as hound, you should not be decoding any station above 1000Hz and therefore you would not be decoding those MSHV instances running as FOX. If you are seeing station above 1000Hz, it should be an indication that either they are not running as a fox, or they are running as a fox using an alternate to WSJT-X 
73,  
Sam W2JDB

Rich,

Can I assume that since the Fox monitors the entire passband, it can
still complete a QSO with such a station without it being moved to a lower tone frequency as is usually done when using the F/H mode?

Since the "fox" does not transmit a flag that identifies whether he
is using WSJTX or one of the bastard "forks", it is difficult to give
an authoritative answer. However, I have not lost *any* QSOs by simply
operating WSJTX in the normal mode and not moving frequency to that of
the "fox" when called by any station operating in "multi-stream" mode.

As far as I can tell, the only reason for the "hound" to move (QSY)
when replying to a "fox" who has answered the "hound's" call is to
move the hound out of the pack so it will be more easily copied by
the fox.

73,

... Joe, W4TV

On 2022-09-20 5:45 PM, Rich - K1HTV wrote:

*I know that stations using other software, such as MSHV, can complete
contacts with callers without being moved from their calling tone frequency
to a lower one. *
*When a Fox is using WSJT-X software and is called by a station using the
normal mode and not as a Hound, can the Fox complete the QSO with that
station? Can I assume that since the Fox monitors the entire passband, it
can still complete a QSO with such a station without it being moved to a
lower tone frequency as is usually done when using the F/H mode? *
*73,*
*Rich - K1HTV*

On 9/20/2022 3:32 PM, Joe Subich, W4TV wrote:

As far as I can tell, the only reason for the "hound" to move (QSY)
when replying to a "fox" who has answered the "hound's" call is to
move the hound out of the pack so it will be more easily copied by
the fox.

Exactly right. A solid clue that the DX is NOT using Fox/Hound mode is that WSJT-X won't work that mode in a standard frequency window.

73, Jim K9YC

A solid clue that the DX is NOT using Fox/Hound mode is
that WSJT-X won't work that mode in a standard frequency window.

With all the bastard forks running around, that doesn't mean much
when stations are not on the "standard" frequency on each band.
Every fork responds differently but it does not appear to be
necessary to QSY for the report regardless.

73,

... Joe, W4TV

On 2022-09-20 7:01 PM, Jim Brown wrote:

On 9/20/2022 3:32 PM, Joe Subich, W4TV wrote:

As far as I can tell, the only reason for the "hound" to move (QSY)
when replying to a "fox" who has answered the "hound's" call is to
move the hound out of the pack so it will be more easily copied by
the fox.

Exactly right. A solid clue that the DX is NOT using Fox/Hound mode is that WSJT-X won't work that mode in a standard frequency window.
73, Jim K9YC

I must be late to the party. I believed only DX expeditions stations should be using F/H function.
Has that been co-opted? Can anyone use this function now? Believe F/H function creates many
issues. Recommend it become a locked feature with limited access granted only to DX expeditions.
DX expeditions could be granted time sensitive keys.

Really sad if have to go that far an besides forks would just appear anyhow. Since the code is open source (I think it is but not sure) someone could just go around this anyway.

Outlook LT Gil W0MN
Hierro Candente Batir de Repente
44.08226 N 92.51265 W EN34rb

It is really intended for dxpeditions as it is a hog of limited bandwidth otherwise.

I can see the temptation by some as I have been trying to respond to multiple callers at once sometimes....but that's been on the usual bands.

And if they don't announce they are using Fox mode on their QRZ page or such how is anybody to know?

Is this a big problem we don't know about?  Just call them out on it and hopefully they'll stop.

We don't need restrictions on it....nor cluttering the code with temporary security keys.

Mike W9MDB

I'm going to request ARRL write a story. Try to get as much exposure as we
can. Frustrating watching it happen more often.

Gilbert Daniel-
Cell 715-660-8608
gdanielone@...

On Thu, Sep 22, 2022, 12:33 AM Michael Black via groups.io <mdblack98=
yahoo.com@groups.io> wrote:

It is really intended for dxpeditions as it is a hog of limited bandwidth
otherwise.

I can see the temptation by some as I have been trying to respond to
multiple callers at once sometimes....but that's been on the usual bands.

And if they don't announce they are using Fox mode on their QRZ page or
such how is anybody to know?

Is this a big problem we don't know about? Just call them out on it and
hopefully they'll stop.

We don't need restrictions on it....nor cluttering the code with temporary
security keys.

Mike W9MDB








On Wednesday, September 21, 2022 at 06:00:44 PM CDT, Gilbert Daniel <
gdanielone@...> wrote:





I must be late to the party. I believed only DX expeditions stations
should be using F/H function.
Has that been co-opted? Can anyone use this function now? Believe F/H
function creates many
issues. Recommend it become a locked feature with limited access granted
only to DX expeditions.
DX expeditions could be granted time sensitive keys.

Joe, as for the “bastard forks” you’ve mentioned more than once, remember that Joe Taylor intentionally released the software as open source and explicitly invited independent experimentation and testing in order to foster innovation. You’re suggesting that anyone embracing Joe’s invitation is somehow doing something worthy of that particular invective.

That is true ... but its also true that some of them added 'features'
that specifically went against the operating rules of many countries
(automatic QSOs), ignored the requests of many operators to refrain from
causing issues on the 'normal' frequencies (pseudo F/H), and violated
the terms of the open source license.

Neil, KN3ILZ

On 2022-09-22 8:51 AM, Randy K7RAN wrote:

You’re suggesting that anyone embracing Joe’s invitation is somehow doing something worthy of that particular invective.

No, I'm stating that those forks that are violating Joe Taylor's
request that his protocols not be used for automatic (robot)
operations and those that misuse the multiple stream capability
contrary to the limitations in WSJTX are most certainly bastards
(as are their developers).

These developers are not promoting innovations that would enhance
the art ... they are creating confusion, QRM and fracture.

73,

... Joe, W4TV

On 2022-09-22 8:51 AM, Randy K7RAN wrote:

Joe, as for the “bastard forks” you’ve mentioned more than once, remember that Joe Taylor intentionally released the software as open source and explicitly invited independent experimentation and testing in order to foster innovation. You’re suggesting that anyone embracing Joe’s invitation is somehow doing something worthy of that particular invective.

I'm temporarily locking this thread whilst I consider a post which is awaiting moderation.

73
Roger
GW4HZA
moderator