MSHV multistream and WSJT-X F/H (2024)

HI All
I received this message from WSJT-X development group (Uwe, DG2YCB).
------------------------------------------------------------------------------------------------------------------------------------------------------------------
In my eyes, it is time to overcome the incompatibilities between MSHV multistream and F/H. The current situation is as follows:

1. AutoSeq in WSJT-X and wsjt-x_improved is currently not able to correctly answer MSHV multistream messages.
2. Some stations using MSHV multistream transmit in the "wrong" time slot. As you know, Fox stations must always transmit even (00/30).
3. MSHV multistream transmits somewhere in the normal FT8 sub-bands and doesn't care about the 1000 Hz rule.

OK, so let's try to find solutions for each:

on 1.: I already re-programmed AutoSeq in WSJT-X and wsjt-x_improved, so that with the next versions, the WSJT-X programs are now able to correctly answer any MSHV multistream message. I think, this is a big step to overcome the current incompatibilities.
on 2.: This is VERY ANNOYING in my eyes (because it confuses many users), and also not really necessary. So, my request to you is: Can't you change this so that when someone activates multistream in MSHV, the time slot is automatically switched to even (00/30)? That would be a BIG HELP for all of us!
on 3.: This is admittedly unpleasant, because it spoils the good manners and as a consequence many users also transmit at F/H below 1000 Hz and thus generate QRM. However, it does not really lead to incompatibilities.

Conclusion: In my eyes, the incompatibilities between MSHV and WSJT-X could be overcome with the measures 1 and 2. Measure 1 is already done (will be released soon for wsjt-x_improved as an intermediate v2.6.1 update, and will come for the original WSJT-X with v2.7.0-rc1), meaning that my proposed measure 2 would be really nice if you implement this as soon as possible.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Please for you opinion for all this ?
LZ2HV Christo.

I agree with John.

However, I would suggest one more step ... *IF* MSHV is in
multistream mode with n > 2 (i.e., more than one audio frequency)
it should *both* enforce the "1000 Hz Rule" and prevent (which I
think it already does) transmission on the "common" frequencies.
I believe these steps are minimum standards of "good operating
practice" and should be enforced by the application if necessary.

This would go a long way toward addressing Uwe's third concern
(as well as helping to repair MSHV's reputation with some
influential DXers).

73,

... Joe, W4TV

*LIKE IT OR NOT WSJTX DEFINED THE PROTOCOL*

Either one works with (coexists with) the existing protocol
or one can be an ass and cause confusion for the thousands
of users who do not understand the difference and can not
comprehend.

This is what I mean by MSHV having a very bad reputation among
certain segments of not only the developer community but among
influential DXers.

The DX station always transmits first ... that even predates
WSJTX with F/H.

73,

... Joe, W4TV

On Apr 12, 2023, at 02:20, "Christo, LZ2HV" <lz2hv@...> wrote:

Hi All

2. When MSHV is in MADX Mode it would be a good idea to only TX 00/30

3. Many DXpeditions is still using the old MSHV versions witch can TX Multislot on normal FT8 QRG but newer versions of MSHV does not TX multistreams in Normal FT8 QRG - only on non-standard QRG. The problem with MSHV not has the 1000 Hz rule is that many stations are calling the DX directly on their TX-Slot and that's making QRM. So maybe when MSHV is in MADX Mode then adapting the 1000 Hz rule

Another thing that realy confusing people is the Smsg because when people see those they automaticly think Fox/Hound Mode.

73 de 5p1kzx Michael

Den 11-04-2023 kl. 20:20 skrev Christo, LZ2HV:

Hi All,

I'm a one of bastards "folks" (Joe) which used WSJT & MSHV from "baby years" of digital modes and specially FTx modes .
Thank you to K1JT get source to the ham world a unique possible to decode and transmit a signals deep below of level of noise .
That was a also good chance to part of "tremendous software " to establish a new soft with a lot of feature inside which iscompatible with main source .and make a live in ham radio moreincredible ..

just want to comment a something regarding announce from Joe,W4TV:

On 4/12/2023 3:03 PM, Andy, LZ2HM via groups.io wrote:

sample: if you have a local TX station which is used FTx and transmits in opposite period your noise on the radio will be very high and he cant give you chance to Receive a low level station.
what will be if this station is more strong that you... we will do
nothing

If the DX is using multi-stream (audio tones > 1) they should be using
a frequency other than the common frequencies and can pick a frequency
without the local QRM. In that case, there is no penalty to being
first/even.

If the DX is operating on the common frequencies (with *one* audio tone) they can operate anywhere in the 3 KHz "band" and on either even or odd
sequence.

*if WSJT keep only the FOX station instead of HOUND all be normal .*

No, it is the "hound mode" that minimizes QRM to the FOX (DX) *and*
allows the chaser (hound) to move to a relatively clearer frequency to
send their report. This frequency division makes the process more
efficient and generally produces higher rates of *completed* QSOs to
the benefit of *everybody*. Allowing callers to call below 1000 Hz
makes copy of the DX station much more difficult.

The active work on air and the correct attitude of the operators this
will contribute to the efficiency of the use of programs in the
future of FTx or other new digital modes of work.

There are far too many operators who will never "read the directions"
and almost as many who have to have it their way (sound familiar?)
regardless of the way it has been done before. It is up to the soft-
ware to provide "guard rails" for good behavior - particularly when
doing so would be quite easy.

I *like* the ability to use multi-answer (one audio frequency) in
the common frequencies and proposed that to K1JT before MSHV even
added FT8 support. However, multi-stream (multiple audio channels)
should be first/even only and limited to frequencies > 3 KHz from
the base frequencies for the benefit *everyone*.

73,

... Joe, W4TV

On 4/12/2023 3:03 PM, Andy, LZ2HM via groups.io wrote:

Hi All,
I'm a one of bastards "folks" (Joe) which used WSJT & MSHV from "baby years" of digital modes and specially FTx modes .
Thank you to K1JT get source to the ham world a unique possible to decode and transmit a signals deep below of level of noise .
That was a also good chance to part of "tremendous software developer & LZ2HV ( developer@LZ2HV ) " to establish a new soft with a lot of feature inside which is compatible with main source . and make a live in ham radio moreincredible ..
just want to comment a something regarding announce from Joe,W4TV:
-------------------------------------------------------------------------------------------------
*LIKE IT OR NOT WSJTX DEFINED THE PROTOCOL*
Either one works with (coexists with) the existing protocol or one can be an ass and cause confusion for the thousands of users who do not understand the difference and can not comprehend.
This is what I mean by MSHV having a very bad reputation among certain segments of not only the developer community but among influential DXers.
The DX station always transmits first ... that even predates WSJTX with F/H.
------------------------------------------------------------------------------------------------------
1) every software have a own evolution in development which is follow a own PROTOCOL where this protocol is compatible with WSJT and result is on the screen .... that one is different from F/H and also have another NAME
2) The "bad reputation" like Joe say is regarding the ignorance of the users and the ego not to ask the developer how to deal with the problem or how to use the program
3) DX Station always transmits first ..... this is not correct !!! Every DXpedition and crew have a own vision how to handle a work in air .( sample: if you have a local TX station which is used FTx and transmits in opposite period your noise on the radio will be very high and he cant give you chance to Receive a low level station. what will be if this station is more strong that you... we will do nothing )
Regarding my comment 3) and sample to suggest of Uwe :DG2YCB
on 2.: This is VERY ANNOYING in my eyes (because it confuses many users), and also not really necessary. So, my request to you is: Can't you change this so that when someone activates multistream in MSHV, the time slot is automatically switched to even (00/30)? That would be a BIG HELP for all of us!
*I want to have in software ( WSJT ) or ( MSHV ) a possible to use( choice ) a different period for work instead of 00/30.*
3. MSHV multistream transmits somewhere in the normal FT8 sub-bands and doesn't care about the 1000 Hz rule.
*if WSJT keep only the FOX station instead of HOUND all be normal .*
The active work on air and the correct attitude of the operators this will contribute to the efficiency of the use of programs in the future of FTx or other new digital modes of work.
73 ! Andy LZ2HM

HI Joe, W4TV
This is exactly what I was waiting for someone to write
dot 1. ----------------------------------------------- W4TV ------------------------------------------------------------------
No, it is the "hound mode" that minimizes QRM to the FOX (DX) *and*
allows the chaser (hound) to move to a relatively clearer frequency to
send their report. This frequency division makes the process more
efficient and generally produces higher rates of *completed* QSOs to
the benefit of *everybody*. Allowing callers to call below 1000 Hz
makes copy of the DX station much more difficult.
end dot 1. -------------------------------------- W4TV END ------------------------------------------------------------------
If you're not familiar, with the new "WSJT-X" and "MSHV" decoders, they monitor for "TD" and "frequency", and exactly what you're saying doesn't apply.
If someone changes their frequency, it is much more difficult to be accepted by "FOX or MADX"
For this reason, this "dot 1 you opinion (W4TV) " is not a good idea (and idea from wsjt team too)
In other words if you change your frequency you have a much smaller chance of being accepted by "FOX or MADX station"
LZ2HV Christo.

Hi Christo

Would you be so kind and explain the new "WSJT-X" and "MSHV" decoders that are monitoring for "TD" and " frequency". What does that exactly means?

73 de Michael 5p1kzx

Den 12-04-2023 kl. 22:39 skrev Christo, LZ2HV:

If that is the case, why do so many stations using MADX not
send RR73 to stations they have previously sent the initial
report and who have replied with R-xx ... even though those
stations show up in online logs (like Clublog)?

Strictly segregating the DX station and callers above/below
1000 Hz and "moving" the caller to the DX station's frequency
for the (R-xx) report still seems to be the best way to minimize
QRM and maximize "throughput". This is whether WSJTX and MSHV
use a priori decoding techniques.

73,

... Joe, W4TV

Having used WSJT F/H on an expedition (A35EU) should I ever go on another, I will use MSHV as I feel the throughput of QSOs would be greater. I have noted a few people complaining about MSHV not receiving the RR73, but I have to say that I have never experienced that. Perhaps its something to do with QSB, I don't know. MSHV Multistream for me is the way to go, if we must have FT8

Tom

GM4FDM

Hello Christo -san,

WSJT-X improved 2.6.2 has been released. I read its release notes.

----------------
- Furthermore, Christo LZ2HV seems to have accepted my suggestion that
in the future
MSHV also transmits only even (00/30) when multi-stream mode is
enabled.
Thanks for the cooperation!
Thanks for the cooperation!
----------------

Will MSHV also transmits only even (00/30) when multi-stream mode is
enabled in the future?

73

Best Regards

Yoshiharu Tsukuura JP1LRT
https://www.qrz.com/db/JP1LRT

*HI All*
*I received this message from WSJT-X development group(Uwe, DG2YCB**).*
------------------------------------------------------------------------------------------------------------------------------------------------------------------
In my eyes, it is time to overcome the incompatibilities between MSHV
multistream and F/H. The current situation is as follows:

1. AutoSeq in WSJT-X and wsjt-x_improved is currently not able to
correctly answer MSHV multistream messages.
2. Some stations using MSHV multistream transmit in the "wrong" time
slot. As you know, Fox stations must always transmit even (00/30).
3. MSHV multistream transmits somewhere in the normal FT8 sub-bands and
doesn't care about the 1000 Hz rule.

OK, so let's try to find solutions for each:

on 1.: I already re-programmed AutoSeq in WSJT-X and wsjt-x_improved, so that with the next versions, the WSJT-X programs are now able to
correctly answer any MSHV multistream message. I think, this is a big
step to overcome the current incompatibilities.
on 2.: This is VERY ANNOYING in my eyes (because it confuses many
users), and also not really necessary. So, my request to you is: Can't
you change this so that when someone activates multistream in MSHV, the
time slot is automatically switched to even (00/30)? That would be a BIG HELP for all of us!
on 3.: This is admittedly unpleasant, because it spoils the good manners and as a consequence many users also transmit at F/H below 1000 Hz and
thus generate QRM. However, it does not really lead to incompatibilities.

Conclusion: In my eyes, the incompatibilities between MSHV and WSJT-X
could be overcome with the measures 1 and 2. Measure 1 is already done
(will be released soon for wsjt-x_improved as an intermediate v2.6.1
update, and will come for the original WSJT-X with v2.7.0-rc1), meaning
that my proposed measure 2 would be really nice if you implement this as soon as possible.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
*Please for you opinion for all this ?*
*LZ2HV Christo.*

--
このメールは、アバスト アンチウイルス ソフトウェアでウイルス チェックされています。
www.avast.com

I have noted a few people complaining about MSHV not
receiving the RR73,

No, it's MSHV not *SENDING* the RR73. Sloppy and causes
excess QRM when the receiving stations continue to send
their report or recycle can call the DX again and again.

73,

... Joe, W4TV

On 4/14/2023 10:14 AM, Tom, GM4FDM wrote:

Having used WSJT F/H on an expedition (A35EU) should I ever go on another, I will use MSHV as I feel the throughput of QSOs would be greater. I have noted a few people complaining about MSHV not receiving the RR73, but I have to say that I have never experienced that. Perhaps its something to do with QSB, I don't know. MSHV Multistream for me is the way to go, if we must have FT8
Tom
GM4FDM
On 14/04/2023 14:15, Joe, W4TV wrote:

If that is the case, why do so many stations using MADX not
send RR73 to stations they have previously sent the initial
report and who have replied with R-xx ... even though those
stations show up in online logs (like Clublog)?

Strictly segregating the DX station and callers above/below
1000 Hz and "moving" the caller to the DX station's frequency
for the (R-xx) report still seems to be the best way to minimize
QRM and maximize "throughput". This is whether WSJTX and MSHV
use a priori decoding techniques.

73,

... Joe, W4TV

On 4/12/2023 4:39 PM, Christo, LZ2HV wrote:

[Edited Message Follows]

HI Joe, W4TV
*This is exactly what I was waiting for someone to write*
*dot 1*. ----------------------------------------------- W4TV ------------------------------------------------------------------
No, it is the "hound mode" that minimizes QRM to the FOX (DX) *and*
allows the chaser (hound) to move to a relatively clearer frequency to
send their report. This frequency division makes the process more
efficient and generally produces higher rates of *completed* QSOs to
the benefit of *everybody*. Allowing callers to call below 1000 Hz
makes copy of the DX station much more difficult.
*end dot 1*. -------------------------------------- W4TV END ------------------------------------------------------------------
If you're not familiar, with the new "WSJT-X" and "MSHV" decoders, they monitor for "TD" and "frequency", and exactly what you're saying doesn't apply.
If someone changes their frequency, it is much more difficult to be accepted by "FOX or MADX"
For this reason, this " *dot 1 you opinion (* W4TV *)* " is not a good idea (and idea from wsjt team too)
*In other words if you change your frequency you have a much smaller chance of being accepted by "FOX or MADX station"*
LZ2HV Christo.

On Fri, Apr 14, 2023 at 04:15 PM, Joe, W4TV wrote:

If that is the case, why do so many stations using MADX not
send RR73 to stations they have previously sent the initial
report and who have replied with R-xx ... even though those
stations show up in online logs (like Clublog)?

Strictly segregating the DX station and callers above/below
1000 Hz and "moving" the caller to the DX station's frequency
for the (R-xx) report still seems to be the best way to minimize
QRM and maximize "throughput". This is whether WSJTX and MSHV
use a priori decoding techniques.

Hi Joe,

now we have a very fresh sample T30UN DX pedition which used a WSJT-X and 80% of people dont get a RR73 but they are in clublog confirm QSO
also this T30UN used a standard freq to work F/H mode ... why ? ( lets say some ham like collect a green stamps :( )
I have a chat with them first to complain if they used a some old version of MSHV or .....WTF they have to make this ...
They confirm that don't use a MSHV but they make some mods in setup (whats?1?)
the guys use a sequencer to control amplifier because last few expedition they blow its due a fast PTT ........OK they protect a amps, but they insert inside of transmit message extra sec and the others operators can get a complete Smsg like W4TV RR73; LZ2HM <T30UN> -10 ...this 12sec is not enough your software to decode msg which already confirm your QSO and give rprt to next ....

This one approve one more time that the user of software ( WSJT,MSHV,JTDX..etc) need to know specifics of program and more of errors and misunderstanding coming from "the best operator" ( i know everything ,I can make it , Dont need help .... bla bla .

NOw back to main discussion :

regarding 1 pos.
1. AutoSeq in WSJT-X and wsjt-x_improved is currently not able to correctly answer MSHV multistream messages.
on 1.: I already re-programmed AutoSeq in WSJT-X and wsjt-x_improved, so that with the next versions, the WSJT-X programs are now able to correctly answer any MSHV multistream message. I think, this is a big step to overcome the current incompatibilities.

This problem of WSJT Team which was necessary to fix a long time ago . ( because now Uwe use this like "look I make this ,now you do this ") come on ....regarding 2 pos.
2. Some stations using MSHV multistream transmit in the "wrong" time slot. As you know, Fox stations must always transmit even (00/30).
on 2.: This is VERY ANNOYING in my eyes (because it confuses many users), and also not really necessary. So, my request to you is: Can't you change this so that when someone activates multistream in MSHV, the time slot is automatically switched to even (00/30)? That would be a BIG HELP for all of us!

I suggest to follow this "ïdea" where by default all DXpedition stations in MSHV multistream mode switch to even (00/30) but I want to have a choice inside of menu to change to ODD (15/45) this need to be choice by DXP operators ( if have a some local problem with "unfriendly" HAMs or MIL)
or
Regarding a developer we can keep a same protocol without any change just kindly noted somewhere in program please run even(00/30) when you choice MADX

regarding pos.3
3. MSHV multistream transmits somewhere in the normal FT8 sub-bands and doesn't care about the 1000 Hz rule.

I suggest don't change anything . This is same like to work on CW/SSB/RTTY or digy used a SHIFTs . Every one DX pedition operator can take a choice how to work where to tune his multistream transmission regarding a Band, QRMs, another DXpeditions , license and etc.Have a nice Easter Holidays
73 ! Andy LZ2HM