Topics

locked unsuccessful contacts with 7q7ru


HamApps Support (VK3AMA)
 

On 17/11/2020 8:46 pm, Tom Melvin wrote:
Does any of this have anything to do with JTAlert?  

Since it seems to be 100% related to wsjt-x would it not be better moving this over to the WSJTX mailing list.

Tom
GM8MJV

I agree, thread is now locked.

de Laurie VK3AMA


Guy G4DWV 4X1LT
 

JTDX does not use the WSJT-X decoders, though the ones in the program are based on the originals. Theirs are much better in that they get more decodes than the original program. You can even download their audio samples and prove it for yourself if you do not believe the devs.
I only have WSJT-X installed for testing purposes and do not use it for QSOs.
--
73 de Guy G4DWV 4X1LT


Tom Melvin
 

Does any of this have anything to do with JTAlert?  

Since it seems to be 100% related to wsjt-x would it not be better moving this over to the WSJTX mailing list.

Tom
GM8MJV

On 17 Nov 2020, at 02:58, ray cathode via groups.io <ray_cathode1@...> wrote:

Joe,



I'll do that but I pretty much know what I will find..



73,

W9RF - Joe





On Monday, November 16, 2020, 8:38:50 PM CST, Joe Subich, W4TV <lists@...> wrote:



> Has the F/H protocol changed since WSJT-X 2.0?

This would be a question for K1JT on the WSJTX list - not here
as it is not a function of JTAlert.

Why don't you check the change log/Release Notes:
  <https://physics.princeton.edu/pulsar/k1jt/Release_Notes.txt>

73,

    ... Joe, W4TV


On 2020-11-16 8:01 PM, ray cathode via groups.io wrote:
>  Here is my latest test with
> JTalert ver 2.16.15WSJT ver 2.2.2F/H mode30 meters
>
> 235315 Tx 1114 ~ 7Q7RU W9RF EM57
> 235330 -14 -0.3 349 ~ W9RF 7Q7RU -04
>
> 235345 Tx 349 ~ 7Q7RU W9RF R-14
>
> 235415 Tx 649 ~ 7Q7RU W9RF R-14
>
> 235445 Tx 649 ~ 7Q7RU W9RF R-14
>
> 235500 -14 -0.3 349 ~ EA2KB 7Q7RU -09
>
> 235515 Tx 649 ~ 7Q7RU W9RF R-14
>
> 235545 Tx 649 ~ 7Q7RU W9RF R-14
>
> 235600 -14 -0.3 349 ~ W9RF 7Q7RU -04
>
> 235615 Tx 349 ~ 7Q7RU W9RF R-14
>
> 235630 -9 -0.3 289 ~ W9RF 7Q7RU -04
>
> 235645 Tx 289 ~ 7Q7RU W9RF R-09
>
> 235700 -11 -0.3 289 ~ W9RF 7Q7RU -04
>
> 235715 Tx 289 ~ 7Q7RU W9RF R-11
>
> 235730 -9 -0.3 289 ~ CQ 7Q7RU KH67
>
> 235745 Tx 589 ~ 7Q7RU W9RF R-11
>
>
> sent into never never land
> 2nd try
> JTalert ver 2.16.15WSJT ver 2.2.2F/H mode TURNED OFF
> 30 meters
>
>
> 005830 -4 0.0 289 ~ CQ 7Q7RU KH67
> 005845 Tx 1325 ~ 7Q7RU W9RF EM57
>
> 005900 -6 -0.1 289 ~ W9RF 7Q7RU -01
>
> 005915 Tx 1325 ~ 7Q7RU W9RF R-06
>
> 005930 -6 -0.1 289 ~ W9RF 7Q7RU RR73
>
> 005945 Tx 1325 ~ 7Q7RU W9RF 73
>
> 010000 -8 -0.2 289 ~ CQ 7Q7RU KH67
>
>
>
>
>
>      On Monday, November 16, 2020, 5:09:11 PM CST, ray cathode via groups.io <ray_cathode1=yahoo.com@groups.io> wrote:

>    Laurie,
>
> Has the F/H protocol changed since WSJT-X 2.0?
>
> 73,
> W9RF - Joe
>

>
>      On Monday, November 16, 2020, 5:04:14 PM CST, Jim Cooper <jtalert@...> wrote:

>  Their website says they are using WSJT-X v2.0 which is very old and might explain some of the oddities of operation ...
>
> One would think that, embarking on such a long-distance and expensive DXpedition, they would be sure to have the most up to date version of all their software ...  but apparently not.   Apparently Malawi is the safest place in the world to be this week, so we do owe a lot of thanks for them to follow thru on the DXpedition.
> jim  w2jc
> On 16 Nov 2020 at 17:24, Joe Subich, W4TV wrote:
>> Are you sure 7q7ru is using WSJTX> and not a [garbage] clone like MSHV or> JTDX? > > Some of the clones do not implement> the F/H protocol correctly but do> allow for multiple simultaneous> QSOs.  It may be that 7q7ru is using> one of the incompatible software> packages and using the *NON F/H* mode> in WSJTX is the correct way to> operate!
>   
>
>
>
>
>
>







Joe - W9RF
 

Joe,



I'll do that but I pretty much know what I will find..



73,

W9RF - Joe





On Monday, November 16, 2020, 8:38:50 PM CST, Joe Subich, W4TV <lists@...> wrote:



> Has the F/H protocol changed since WSJT-X 2.0?

This would be a question for K1JT on the WSJTX list - not here
as it is not a function of JTAlert.

Why don't you check the change log/Release Notes:
  <https://physics.princeton.edu/pulsar/k1jt/Release_Notes.txt>

73,

    ... Joe, W4TV


On 2020-11-16 8:01 PM, ray cathode via groups.io wrote:
>  Here is my latest test with
> JTalert ver 2.16.15WSJT ver 2.2.2F/H mode30 meters
>
> 235315 Tx 1114 ~ 7Q7RU W9RF EM57
> 235330 -14 -0.3 349 ~ W9RF 7Q7RU -04
>
> 235345 Tx 349 ~ 7Q7RU W9RF R-14
>
> 235415 Tx 649 ~ 7Q7RU W9RF R-14
>
> 235445 Tx 649 ~ 7Q7RU W9RF R-14
>
> 235500 -14 -0.3 349 ~ EA2KB 7Q7RU -09
>
> 235515 Tx 649 ~ 7Q7RU W9RF R-14
>
> 235545 Tx 649 ~ 7Q7RU W9RF R-14
>
> 235600 -14 -0.3 349 ~ W9RF 7Q7RU -04
>
> 235615 Tx 349 ~ 7Q7RU W9RF R-14
>
> 235630 -9 -0.3 289 ~ W9RF 7Q7RU -04
>
> 235645 Tx 289 ~ 7Q7RU W9RF R-09
>
> 235700 -11 -0.3 289 ~ W9RF 7Q7RU -04
>
> 235715 Tx 289 ~ 7Q7RU W9RF R-11
>
> 235730 -9 -0.3 289 ~ CQ 7Q7RU KH67
>
> 235745 Tx 589 ~ 7Q7RU W9RF R-11
>
>
> sent into never never land
> 2nd try
> JTalert ver 2.16.15WSJT ver 2.2.2F/H mode TURNED OFF
> 30 meters
>
>
> 005830 -4 0.0 289 ~ CQ 7Q7RU KH67
> 005845 Tx 1325 ~ 7Q7RU W9RF EM57
>
> 005900 -6 -0.1 289 ~ W9RF 7Q7RU -01
>
> 005915 Tx 1325 ~ 7Q7RU W9RF R-06
>
> 005930 -6 -0.1 289 ~ W9RF 7Q7RU RR73
>
> 005945 Tx 1325 ~ 7Q7RU W9RF 73
>
> 010000 -8 -0.2 289 ~ CQ 7Q7RU KH67
>
>
>
>
>
>      On Monday, November 16, 2020, 5:09:11 PM CST, ray cathode via groups.io <ray_cathode1=yahoo.com@groups.io> wrote:

>    Laurie,
>
> Has the F/H protocol changed since WSJT-X 2.0?
>
> 73,
> W9RF - Joe
>

>
>      On Monday, November 16, 2020, 5:04:14 PM CST, Jim Cooper <jtalert@...> wrote:

>  Their website says they are using WSJT-X v2.0 which is very old and might explain some of the oddities of operation ...
>
> One would think that, embarking on such a long-distance and expensive DXpedition, they would be sure to have the most up to date version of all their software ...  but apparently not.   Apparently Malawi is the safest place in the world to be this week, so we do owe a lot of thanks for them to follow thru on the DXpedition.
> jim  w2jc
> On 16 Nov 2020 at 17:24, Joe Subich, W4TV wrote:
>> Are you sure 7q7ru is using WSJTX> and not a [garbage] clone like MSHV or> JTDX? > > Some of the clones do not implement> the F/H protocol correctly but do> allow for multiple simultaneous> QSOs.  It may be that 7q7ru is using> one of the incompatible software> packages and using the *NON F/H* mode> in WSJTX is the correct way to> operate!
>   
>
>
>
>
>
>






Joe - W9RF
 

Gary,

All my contacts with them has been confirmed via Clublog with a RR73 and me clicking on "log qso"

(I run DXKeeper also)

Next time you try, don't use F/H and see how it works out.


73,

W9RF - Joe








On Monday, November 16, 2020, 8:31:32 PM CST, Gary Gorniak <w9bs@...> wrote:


You might want to check ClubLog to see if they logged your QSO.  I had the same problem as you when I worked them on 30m.  I tried for hours to initiate another contact with them, without success.  Today I checked ClubLog, and indeed they logged the QSO.  I reconstructed the entry for my log (DXKeeper) by using the ALL.txt file in WSJT-X to retrieve the necessary info.

 

GL and 73

Gary – W9BS

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of ray cathode via groups.io
Sent: Monday, November 16, 2020 8:02 PM
To: Support@HamApps.groups.io; Support@HamApps.groups.io
Subject: Re: [HamApps] unsuccessful contacts with 7q7ru

 

Here is my latest test with

JTalert ver 2.16.15

WSJT ver 2.2.2

F/H mode

30 meters

 

235315 Tx 1114 ~ 7Q7RU W9RF EM57

235330 -14 -0.3 349 ~ W9RF 7Q7RU -04

235345 Tx 349 ~ 7Q7RU W9RF R-14

235415 Tx 649 ~ 7Q7RU W9RF R-14

235445 Tx 649 ~ 7Q7RU W9RF R-14

235500 -14 -0.3 349 ~ EA2KB 7Q7RU -09

235515 Tx 649 ~ 7Q7RU W9RF R-14

235545 Tx 649 ~ 7Q7RU W9RF R-14

235600 -14 -0.3 349 ~ W9RF 7Q7RU -04

235615 Tx 349 ~ 7Q7RU W9RF R-14

235630 -9 -0.3 289 ~ W9RF 7Q7RU -04

235645 Tx 289 ~ 7Q7RU W9RF R-09

235700 -11 -0.3 289 ~ W9RF 7Q7RU -04

235715 Tx 289 ~ 7Q7RU W9RF R-11

235730 -9 -0.3 289 ~ CQ 7Q7RU KH67

235745 Tx 589 ~ 7Q7RU W9RF R-11

 

 

sent into never never land

 

2nd try

 

JTalert ver 2.16.15

WSJT ver 2.2.2

F/H mode TURNED OFF

30 meters

 

 

 

005830 -4 0.0 289 ~ CQ 7Q7RU KH67

005845 Tx 1325 ~ 7Q7RU W9RF EM57

005900 -6 -0.1 289 ~ W9RF 7Q7RU -01

005915 Tx 1325 ~ 7Q7RU W9RF R-06

005930 -6 -0.1 289 ~ W9RF 7Q7RU RR73

005945 Tx 1325 ~ 7Q7RU W9RF 73

010000 -8 -0.2 289 ~ CQ 7Q7RU KH67

 

 

 

 

 

On Monday, November 16, 2020, 5:09:11 PM CST, ray cathode via groups.io <ray_cathode1@...> wrote:

 

 

Laurie,

 

 

Has the F/H protocol changed since WSJT-X 2.0?

 

 

73,

 

W9RF - Joe

 

 

 

 

On Monday, November 16, 2020, 5:04:14 PM CST, Jim Cooper <jtalert@...> wrote:

 

 

Their website says they are using WSJT-X v2.0

which is very old and might explain some of the

oddities of operation ...

 

graphic

 

One would think that, embarking on such a long-distance and

expensive DXpedition, they would be sure to have the most

up to date version of all their software ...  but apparently not.   Apparently Malawi is the safest place in the world to be this week, so we do owe a lot of thanks for them to follow thru on the DXpedition.

 

jim  w2jc

 

On 16 Nov 2020 at 17:24, Joe Subich, W4TV wrote:

 

> Are you sure 7q7ru is using WSJTX

> and not a [garbage] clone like MSHV or

> JTDX?

>

> Some of the clones do not implement

> the F/H protocol correctly but do

> allow for multiple simultaneous

> QSOs.  It may be that 7q7ru is using

> one of the incompatible software

> packages and using the *NON F/H* mode

> in WSJTX is the correct way to

> operate!

 

  


Joe Subich, W4TV
 

Has the F/H protocol changed since WSJT-X 2.0?
This would be a question for K1JT on the WSJTX list - not here
as it is not a function of JTAlert.

Why don't you check the change log/Release Notes:
<https://physics.princeton.edu/pulsar/k1jt/Release_Notes.txt>

73,

... Joe, W4TV


On 2020-11-16 8:01 PM, ray cathode via groups.io wrote:
Here is my latest test with
JTalert ver 2.16.15WSJT ver 2.2.2F/H mode30 meters
235315 Tx 1114 ~ 7Q7RU W9RF EM57
235330 -14 -0.3 349 ~ W9RF 7Q7RU -04
235345 Tx 349 ~ 7Q7RU W9RF R-14
235415 Tx 649 ~ 7Q7RU W9RF R-14
235445 Tx 649 ~ 7Q7RU W9RF R-14
235500 -14 -0.3 349 ~ EA2KB 7Q7RU -09
235515 Tx 649 ~ 7Q7RU W9RF R-14
235545 Tx 649 ~ 7Q7RU W9RF R-14
235600 -14 -0.3 349 ~ W9RF 7Q7RU -04
235615 Tx 349 ~ 7Q7RU W9RF R-14
235630 -9 -0.3 289 ~ W9RF 7Q7RU -04
235645 Tx 289 ~ 7Q7RU W9RF R-09
235700 -11 -0.3 289 ~ W9RF 7Q7RU -04
235715 Tx 289 ~ 7Q7RU W9RF R-11
235730 -9 -0.3 289 ~ CQ 7Q7RU KH67
235745 Tx 589 ~ 7Q7RU W9RF R-11
sent into never never land
2nd try
JTalert ver 2.16.15WSJT ver 2.2.2F/H mode TURNED OFF
30 meters
005830 -4 0.0 289 ~ CQ 7Q7RU KH67
005845 Tx 1325 ~ 7Q7RU W9RF EM57
005900 -6 -0.1 289 ~ W9RF 7Q7RU -01
005915 Tx 1325 ~ 7Q7RU W9RF R-06
005930 -6 -0.1 289 ~ W9RF 7Q7RU RR73
005945 Tx 1325 ~ 7Q7RU W9RF 73
010000 -8 -0.2 289 ~ CQ 7Q7RU KH67
On Monday, November 16, 2020, 5:09:11 PM CST, ray cathode via groups.io <ray_cathode1=yahoo.com@groups.io> wrote:
Laurie,
Has the F/H protocol changed since WSJT-X 2.0?
73,
W9RF - Joe
On Monday, November 16, 2020, 5:04:14 PM CST, Jim Cooper <jtalert@jimcooper.org> wrote:
Their website says they are using WSJT-X v2.0 which is very old and might explain some of the oddities of operation ...
One would think that, embarking on such a long-distance and expensive DXpedition, they would be sure to have the most up to date version of all their software ...  but apparently not.   Apparently Malawi is the safest place in the world to be this week, so we do owe a lot of thanks for them to follow thru on the DXpedition.
jim  w2jc
On 16 Nov 2020 at 17:24, Joe Subich, W4TV wrote:
Are you sure 7q7ru is using WSJTX> and not a [garbage] clone like MSHV or> JTDX? > > Some of the clones do not implement> the F/H protocol correctly but do> allow for multiple simultaneous> QSOs.  It may be that 7q7ru is using> one of the incompatible software> packages and using the *NON F/H* mode> in WSJTX is the correct way to> operate!


Gary Gorniak
 

You might want to check ClubLog to see if they logged your QSO.  I had the same problem as you when I worked them on 30m.  I tried for hours to initiate another contact with them, without success.  Today I checked ClubLog, and indeed they logged the QSO.  I reconstructed the entry for my log (DXKeeper) by using the ALL.txt file in WSJT-X to retrieve the necessary info.

 

GL and 73

Gary – W9BS

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of ray cathode via groups.io
Sent: Monday, November 16, 2020 8:02 PM
To: Support@HamApps.groups.io; Support@HamApps.groups.io
Subject: Re: [HamApps] unsuccessful contacts with 7q7ru

 

Here is my latest test with

JTalert ver 2.16.15

WSJT ver 2.2.2

F/H mode

30 meters

 

235315 Tx 1114 ~ 7Q7RU W9RF EM57

235330 -14 -0.3 349 ~ W9RF 7Q7RU -04

235345 Tx 349 ~ 7Q7RU W9RF R-14

235415 Tx 649 ~ 7Q7RU W9RF R-14

235445 Tx 649 ~ 7Q7RU W9RF R-14

235500 -14 -0.3 349 ~ EA2KB 7Q7RU -09

235515 Tx 649 ~ 7Q7RU W9RF R-14

235545 Tx 649 ~ 7Q7RU W9RF R-14

235600 -14 -0.3 349 ~ W9RF 7Q7RU -04

235615 Tx 349 ~ 7Q7RU W9RF R-14

235630 -9 -0.3 289 ~ W9RF 7Q7RU -04

235645 Tx 289 ~ 7Q7RU W9RF R-09

235700 -11 -0.3 289 ~ W9RF 7Q7RU -04

235715 Tx 289 ~ 7Q7RU W9RF R-11

235730 -9 -0.3 289 ~ CQ 7Q7RU KH67

235745 Tx 589 ~ 7Q7RU W9RF R-11

 

 

sent into never never land

 

2nd try

 

JTalert ver 2.16.15

WSJT ver 2.2.2

F/H mode TURNED OFF

30 meters

 

 

 

005830 -4 0.0 289 ~ CQ 7Q7RU KH67

005845 Tx 1325 ~ 7Q7RU W9RF EM57

005900 -6 -0.1 289 ~ W9RF 7Q7RU -01

005915 Tx 1325 ~ 7Q7RU W9RF R-06

005930 -6 -0.1 289 ~ W9RF 7Q7RU RR73

005945 Tx 1325 ~ 7Q7RU W9RF 73

010000 -8 -0.2 289 ~ CQ 7Q7RU KH67

 

 

 

 

 

On Monday, November 16, 2020, 5:09:11 PM CST, ray cathode via groups.io <ray_cathode1@...> wrote:

 

 

Laurie,

 

 

Has the F/H protocol changed since WSJT-X 2.0?

 

 

73,

 

W9RF - Joe

 

 

 

 

On Monday, November 16, 2020, 5:04:14 PM CST, Jim Cooper <jtalert@...> wrote:

 

 

Their website says they are using WSJT-X v2.0

which is very old and might explain some of the

oddities of operation ...

 

graphic

 

One would think that, embarking on such a long-distance and

expensive DXpedition, they would be sure to have the most

up to date version of all their software ...  but apparently not.   Apparently Malawi is the safest place in the world to be this week, so we do owe a lot of thanks for them to follow thru on the DXpedition.

 

jim  w2jc

 

On 16 Nov 2020 at 17:24, Joe Subich, W4TV wrote:

 

> Are you sure 7q7ru is using WSJTX

> and not a [garbage] clone like MSHV or

> JTDX?

>

> Some of the clones do not implement

> the F/H protocol correctly but do

> allow for multiple simultaneous

> QSOs.  It may be that 7q7ru is using

> one of the incompatible software

> packages and using the *NON F/H* mode

> in WSJTX is the correct way to

> operate!

 

  


Joe - W9RF
 

Here is my latest test with
JTalert ver 2.16.15
WSJT ver 2.2.2
F/H mode
30 meters

235315 Tx 1114 ~ 7Q7RU W9RF EM57

235330 -14 -0.3 349 ~ W9RF 7Q7RU -04

235345 Tx 349 ~ 7Q7RU W9RF R-14

235415 Tx 649 ~ 7Q7RU W9RF R-14

235445 Tx 649 ~ 7Q7RU W9RF R-14

235500 -14 -0.3 349 ~ EA2KB 7Q7RU -09

235515 Tx 649 ~ 7Q7RU W9RF R-14

235545 Tx 649 ~ 7Q7RU W9RF R-14

235600 -14 -0.3 349 ~ W9RF 7Q7RU -04

235615 Tx 349 ~ 7Q7RU W9RF R-14

235630 -9 -0.3 289 ~ W9RF 7Q7RU -04

235645 Tx 289 ~ 7Q7RU W9RF R-09

235700 -11 -0.3 289 ~ W9RF 7Q7RU -04

235715 Tx 289 ~ 7Q7RU W9RF R-11

235730 -9 -0.3 289 ~ CQ 7Q7RU KH67

235745 Tx 589 ~ 7Q7RU W9RF R-11



sent into never never land

2nd try

JTalert ver 2.16.15
WSJT ver 2.2.2
F/H mode TURNED OFF
30 meters



005830 -4 0.0 289 ~ CQ 7Q7RU KH67

005845 Tx 1325 ~ 7Q7RU W9RF EM57

005900 -6 -0.1 289 ~ W9RF 7Q7RU -01

005915 Tx 1325 ~ 7Q7RU W9RF R-06

005930 -6 -0.1 289 ~ W9RF 7Q7RU RR73

005945 Tx 1325 ~ 7Q7RU W9RF 73

010000 -8 -0.2 289 ~ CQ 7Q7RU KH67






On Monday, November 16, 2020, 5:09:11 PM CST, ray cathode via groups.io <ray_cathode1@...> wrote:


Laurie,


Has the F/H protocol changed since WSJT-X 2.0?


73,

W9RF - Joe




On Monday, November 16, 2020, 5:04:14 PM CST, Jim Cooper <jtalert@...> wrote:


Their website says they are using WSJT-X v2.0
which is very old and might explain some of the
oddities of operation ...

graphic

One would think that, embarking on such a long-distance and
expensive DXpedition, they would be sure to have the most
up to date version of all their software ...  but apparently not.   Apparently Malawi is the safest place in the world to be this week, so we do owe a lot of thanks for them to follow thru on the DXpedition.

jim  w2jc

On 16 Nov 2020 at 17:24, Joe Subich, W4TV wrote:

> Are you sure 7q7ru is using WSJTX
> and not a [garbage] clone like MSHV or
> JTDX?
>
> Some of the clones do not implement
> the F/H protocol correctly but do
> allow for multiple simultaneous
> QSOs.  It may be that 7q7ru is using
> one of the incompatible software
> packages and using the *NON F/H* mode
> in WSJTX is the correct way to
> operate!

  


Joe - W9RF
 

Jim,


Their call/call back/confirm (if that's how you explain it) is absolutely terrible, I would guess lees that 5%

I've been trying with ver 2.2.2 WSJT but they are only working nostly JA's for now.


73,

W9RF - Joe








On Monday, November 16, 2020, 5:04:14 PM CST, Jim Cooper <jtalert@...> wrote:


Their website says they are using WSJT-X v2.0
which is very old and might explain some of the
oddities of operation ...

graphic

One would think that, embarking on such a long-distance and
expensive DXpedition, they would be sure to have the most
up to date version of all their software ...  but apparently not.   Apparently Malawi is the safest place in the world to be this week, so we do owe a lot of thanks for them to follow thru on the DXpedition.

jim  w2jc

On 16 Nov 2020 at 17:24, Joe Subich, W4TV wrote:

> Are you sure 7q7ru is using WSJTX
> and not a [garbage] clone like MSHV or
> JTDX?
>
> Some of the clones do not implement
> the F/H protocol correctly but do
> allow for multiple simultaneous
> QSOs.  It may be that 7q7ru is using
> one of the incompatible software
> packages and using the *NON F/H* mode
> in WSJTX is the correct way to
> operate!

  


Joe - W9RF
 

Laurie,


Has the F/H protocol changed since WSJT-X 2.0?


73,

W9RF - Joe




On Monday, November 16, 2020, 5:04:14 PM CST, Jim Cooper <jtalert@...> wrote:


Their website says they are using WSJT-X v2.0
which is very old and might explain some of the
oddities of operation ...

graphic

One would think that, embarking on such a long-distance and
expensive DXpedition, they would be sure to have the most
up to date version of all their software ...  but apparently not.   Apparently Malawi is the safest place in the world to be this week, so we do owe a lot of thanks for them to follow thru on the DXpedition.

jim  w2jc

On 16 Nov 2020 at 17:24, Joe Subich, W4TV wrote:

> Are you sure 7q7ru is using WSJTX
> and not a [garbage] clone like MSHV or
> JTDX?
>
> Some of the clones do not implement
> the F/H protocol correctly but do
> allow for multiple simultaneous
> QSOs.  It may be that 7q7ru is using
> one of the incompatible software
> packages and using the *NON F/H* mode
> in WSJTX is the correct way to
> operate!

  


Jim Cooper
 

Their website says they are using WSJT-X v2.0
which is very old and might explain some of the
oddities of operation ...

graphic

One would think that, embarking on such a long-distance and
expensive DXpedition, they would be sure to have the most
up to date version of all their software ...  but apparently not.   Apparently Malawi is the safest place in the world to be this week, so we do owe a lot of thanks for them to follow thru on the DXpedition.

jim  w2jc

On 16 Nov 2020 at 17:24, Joe Subich, W4TV wrote:

> Are you sure 7q7ru is using WSJTX
> and not a [garbage] clone like MSHV or
> JTDX?
>
> Some of the clones do not implement
> the F/H protocol correctly but do
> allow for multiple simultaneous
> QSOs.  It may be that 7q7ru is using
> one of the incompatible software
> packages and using the *NON F/H* mode
> in WSJTX is the correct way to
> operate!

  


Björn SM7IUN
 

Since WSJT-X is open source even the garbage clones use Joe's decoder so decoding performance should be equivalent.

If the DX systematically fails to complete QSO this means there is QRM in the listening slots on the DX's frequency.

Björn SM7IUN

Den mån 16 nov. 2020 kl 23:44 skrev ray cathode via groups.io <ray_cathode1=yahoo.com@groups.io>:

Joe,


I'm pretty much convinced of that.

Since you have reminded me, that's what I remember about the clones, no F/H but appears to be in F/H mode.

I am running an older version of WSJT but Laurie suggested I upgrade to the newest one.

Going to do that and test a little more tonight.


You are right about the garbage clones they might be using, could be why you see 10-20 calls moved down to the 0-500 slot then never get answered..


73,

W9RF - Joe





On Monday, November 16, 2020, 4:24:32 PM CST, Joe Subich, W4TV <lists@...> wrote:



Joe,

Are you sure 7q7ru is using WSJTX and not a [garbage] clone like MSHV
or JTDX?

Some of the clones do not implement the F/H protocol correctly but
do allow for multiple simultaneous QSOs.  It may be that 7q7ru is
using one of the incompatible software packages and using the
*NON F/H* mode in WSJTX is the correct way to operate!

73,

    ... Joe, W4TV


On 2020-11-16 5:12 PM, ray cathode via groups.io wrote:
>  Laurie,
>
>
>
> I suppose it could be but did the parameters for F/H change since 2.1.2?
> I'll upgrade and see what happens
>
>
> 73,
> W9RF - Joe
>
>
>
>
>      On Monday, November 16, 2020, 4:05:42 PM CST, Laurie, VK3AMA <hamapps.support@...> wrote:


>
> On 17/11/2020 8:49 am, ray cathode via groups.io wrote:
>> There might be some validity in your reasoning BUT I will stick with
>> the PLAIN FT8 (at least for 7q7ru)
>>
>> 9 times of making contact then getting put up to the 500_ slot is not
>> coincidence.
>>
>>
>> I just made another qso on 20 meters with 7q7ru in PLAIN FT8 mode
>> (4'th call) fairly bad signal reports.
>>
>>
>
> Could it be your very old WSJT-X version?
> 2.1.2 is rather dated.
>
> de Laurie VK3AMA
>








Björn SM7IUN
 

As long as you stay above 1000Hz you will not hurt anybody by 
running vanilla FT8 with a F/H DX station so if you find it works for you, 
nobody can complain.

The original idea of FT8 to reserve the lowest 1000Hz in the passband for 
concluding QSO was a good idea in theory but unfortunately Joe et al underestimated 
the effect LIDS would have on the model. On bad days I wish there was some hidden flag 
in the Fox transmission that would block WSJT-X from manually transmitting within 500Hz 
of such a carrier...

Björn

Den mån 16 nov. 2020 kl 22:50 skrev ray cathode via groups.io <ray_cathode1=yahoo.com@groups.io>:

Bjorn,


There might be some validity in your reasoning BUT I will stick with the PLAIN FT8 (at least for 7q7ru)

9 times of making contact then getting put up to the 500_ slot is not coincidence.


I just made another qso on 20 meters with 7q7ru in PLAIN FT8 mode (4'th call) fairly bad signal reports.




213430 -10 0.1 289 ~ CQ 7Q7RU KH67

213445 Tx 1325 ~ 7Q7RU W9RF EM57

213500 -15 0.1 348 ~ W9RF 7Q7RU -06

213515 Tx 1325 ~ 7Q7RU W9RF R-15

213530 -16 0.1 348 ~ W9RF 7Q7RU -06

213545 Tx 1325 ~ 7Q7RU W9RF R-16

213600 -11 0.1 288 ~ W9RF RR73; K8SIX <7Q7RU> -04

213615 Tx 1325 ~ 7Q7RU W9RF R-16

213630 -11 0.1 289 ~ W9RF 7Q7RU RR73

213646 Tx 1325 ~ 7Q7RU W9RF 73



73,

W9RF - Joe



On Monday, November 16, 2020, 3:24:37 PM CST, Björn SM7IUN <bjorn@...> wrote:


It's not the DX that pulls you down in frequency. It's the logic in your WSJT-X just following the F/H protocol.

The fact that you succeeded just meant they could decode you correctly and has nothing to do with F/H or not. 
Or software compatibility for that matter.

If there are lots of LIDS using plain FT8 calling on or around the DX' frequency, you will struggle 
to make QSO with F/H since the frequency you move to (i.e. the carrier of the responding stream) 
is clobbered. If you are unlucky, the secondary (random but below 1000Hz) frequency the software 
moves you to after three failed attempts may still be that of a LID. 

Björn SM7IUN

Den mån 16 nov. 2020 kl 21:22 skrev ray cathode via groups.io <ray_cathode1=yahoo.com@groups.io>:
Roger,




For what it's worth here is another update on my unsuccessful confirmation with 7q7ru in F/H mode.

Yesterday evening the problem on 30 meters F/H mode was remedied buy switching out of F/H mode.


Same thing happened to me today.

While calling them at 18.095 F/H mode I was answered with a +1 report both ways and after a few exchanges I was thrown up to the 500+ slot and they began calling other calls.

I took Jtalert/WSJT-X out of F/H mode and called again with plain FT8 at 1325, third try they answered me, did NOT pull me down to their freq, and after 2 exchanges they gave me a confirmation (RR73)


SO, if anyone is having the same problem I have been experiencing I would suggest giving a plain FT8 a try.


I feel the only answer is software incompatibility at some level.

and before anyone asks, this is what I understand to be F/H  mode.

182145 Tx 1325 ~ 7Q7RU W9RF EM57

182200 1 0.1 286 ~ K4PX RR73; NB2P <7Q7RU> -10

182200 1 0.1 346 ~ W9RF 7Q7RU +01

182215 Tx 1325 ~ 7Q7RU W9RF R+01

182230 1 0.1 346 ~ W9RF 7Q7RU +01

182245 Tx 1325 ~ 7Q7RU W9RF R+01

182300 6 0.1 286 ~ W9RF RR73; W1KG <7Q7RU> -04








On Sunday, November 15, 2020, 9:07:50 PM CST, ray cathode via groups.io <ray_cathode1=yahoo.com@groups.io> wrote:


Roger,


I finally worked him just now on 10.131 but I was NOT in f/h mode, although he is in f/h mode, unless he switched on the fly, go figure??

Called him at 1500 and he did not call me to his freq but we exchanged reports and got a RR73 from him..


73,

W9RF - Joe








On Sunday, November 15, 2020, 6:52:45 PM CST, Roger M via groups.io <ac6bw=yahoo.com@groups.io> wrote:


Joe,
OK, fair enough. Yes, it does seem strange.
All I can suggest is keep trying. Are you using WSJT-X, or JTDX? I recently switched over to JTDX, because it has better decode sensitivity, as well as some other features that I like. If you have both programs installed, perhaps you can try one or the other in F/H mode, and see if that makes a difference.
Also, it's possible that something is not configured correctly on the Fox end, but I wouldn't know exactly what. There are a lot of settings that the Fox can enable.
--
73,
Roger
AC6BW


Joe - W9RF
 

Joe,


I'm pretty much convinced of that.

Since you have reminded me, that's what I remember about the clones, no F/H but appears to be in F/H mode.

I am running an older version of WSJT but Laurie suggested I upgrade to the newest one.

Going to do that and test a little more tonight.


You are right about the garbage clones they might be using, could be why you see 10-20 calls moved down to the 0-500 slot then never get answered..


73,

W9RF - Joe





On Monday, November 16, 2020, 4:24:32 PM CST, Joe Subich, W4TV <lists@...> wrote:



Joe,

Are you sure 7q7ru is using WSJTX and not a [garbage] clone like MSHV
or JTDX?

Some of the clones do not implement the F/H protocol correctly but
do allow for multiple simultaneous QSOs.  It may be that 7q7ru is
using one of the incompatible software packages and using the
*NON F/H* mode in WSJTX is the correct way to operate!

73,

    ... Joe, W4TV


On 2020-11-16 5:12 PM, ray cathode via groups.io wrote:
>  Laurie,
>
>
>
> I suppose it could be but did the parameters for F/H change since 2.1.2?
> I'll upgrade and see what happens
>
>
> 73,
> W9RF - Joe
>
>
>
>
>      On Monday, November 16, 2020, 4:05:42 PM CST, Laurie, VK3AMA <hamapps.support@...> wrote:


>
> On 17/11/2020 8:49 am, ray cathode via groups.io wrote:
>> There might be some validity in your reasoning BUT I will stick with
>> the PLAIN FT8 (at least for 7q7ru)
>>
>> 9 times of making contact then getting put up to the 500_ slot is not
>> coincidence.
>>
>>
>> I just made another qso on 20 meters with 7q7ru in PLAIN FT8 mode
>> (4'th call) fairly bad signal reports.
>>
>>
>
> Could it be your very old WSJT-X version?
> 2.1.2 is rather dated.
>
> de Laurie VK3AMA
>








wc3w
 

I definitely believe what you are saying is true—I cannot get my band activity screen to scroll when changing to F/H….I can hear the signals coming in but it refuses to decode!

Mark
WC3W

On Nov 16, 2020, at 3:24 PM, Joe Subich, W4TV <lists@subich.com> wrote:


Joe,

Are you sure 7q7ru is using WSJTX and not a [garbage] clone like MSHV
or JTDX?

Some of the clones do not implement the F/H protocol correctly but
do allow for multiple simultaneous QSOs. It may be that 7q7ru is
using one of the incompatible software packages and using the
*NON F/H* mode in WSJTX is the correct way to operate!

73,

... Joe, W4TV


On 2020-11-16 5:12 PM, ray cathode via groups.io wrote:
Laurie,
I suppose it could be but did the parameters for F/H change since 2.1.2?
I'll upgrade and see what happens
73,
W9RF - Joe
On Monday, November 16, 2020, 4:05:42 PM CST, Laurie, VK3AMA <hamapps.support@vkdxer.com> wrote:
On 17/11/2020 8:49 am, ray cathode via groups.io wrote:
There might be some validity in your reasoning BUT I will stick with
the PLAIN FT8 (at least for 7q7ru)

9 times of making contact then getting put up to the 500_ slot is not
coincidence.


I just made another qso on 20 meters with 7q7ru in PLAIN FT8 mode
(4'th call) fairly bad signal reports.

Could it be your very old WSJT-X version?
2.1.2 is rather dated.
de Laurie VK3AMA






Joe Subich, W4TV
 

Joe,

Are you sure 7q7ru is using WSJTX and not a [garbage] clone like MSHV
or JTDX?

Some of the clones do not implement the F/H protocol correctly but
do allow for multiple simultaneous QSOs. It may be that 7q7ru is
using one of the incompatible software packages and using the
*NON F/H* mode in WSJTX is the correct way to operate!

73,

... Joe, W4TV

On 2020-11-16 5:12 PM, ray cathode via groups.io wrote:
Laurie,
I suppose it could be but did the parameters for F/H change since 2.1.2?
I'll upgrade and see what happens
73,
W9RF - Joe
On Monday, November 16, 2020, 4:05:42 PM CST, Laurie, VK3AMA <hamapps.support@vkdxer.com> wrote:
On 17/11/2020 8:49 am, ray cathode via groups.io wrote:
There might be some validity in your reasoning BUT I will stick with
the PLAIN FT8 (at least for 7q7ru)

9 times of making contact then getting put up to the 500_ slot is not
coincidence.


I just made another qso on 20 meters with 7q7ru in PLAIN FT8 mode
(4'th call) fairly bad signal reports.

Could it be your very old WSJT-X version?
2.1.2 is rather dated.
de Laurie VK3AMA


Joe - W9RF
 

Laurie,



I suppose it could be but did the parameters for F/H change since 2.1.2?

I'll upgrade and see what happens



73,

W9RF - Joe





On Monday, November 16, 2020, 4:05:42 PM CST, Laurie, VK3AMA <hamapps.support@...> wrote:




On 17/11/2020 8:49 am, ray cathode via groups.io wrote:
> There might be some validity in your reasoning BUT I will stick with
> the PLAIN FT8 (at least for 7q7ru)
>
> 9 times of making contact then getting put up to the 500_ slot is not
> coincidence.
>
>
> I just made another qso on 20 meters with 7q7ru in PLAIN FT8 mode
> (4'th call) fairly bad signal reports.
>
>

Could it be your very old WSJT-X version?
2.1.2 is rather dated.

de Laurie VK3AMA







Laurie, VK3AMA
 

On 17/11/2020 8:49 am, ray cathode via groups.io wrote:
There might be some validity in your reasoning BUT I will stick with the PLAIN FT8 (at least for 7q7ru)

9 times of making contact then getting put up to the 500_ slot is not coincidence.


I just made another qso on 20 meters with 7q7ru in PLAIN FT8 mode (4'th call) fairly bad signal reports.

Could it be your very old WSJT-X version?
2.1.2 is rather dated.

de Laurie VK3AMA


Joe - W9RF
 

Bjorn,


There might be some validity in your reasoning BUT I will stick with the PLAIN FT8 (at least for 7q7ru)

9 times of making contact then getting put up to the 500_ slot is not coincidence.


I just made another qso on 20 meters with 7q7ru in PLAIN FT8 mode (4'th call) fairly bad signal reports.




213430 -10 0.1 289 ~ CQ 7Q7RU KH67

213445 Tx 1325 ~ 7Q7RU W9RF EM57

213500 -15 0.1 348 ~ W9RF 7Q7RU -06

213515 Tx 1325 ~ 7Q7RU W9RF R-15

213530 -16 0.1 348 ~ W9RF 7Q7RU -06

213545 Tx 1325 ~ 7Q7RU W9RF R-16

213600 -11 0.1 288 ~ W9RF RR73; K8SIX <7Q7RU> -04

213615 Tx 1325 ~ 7Q7RU W9RF R-16

213630 -11 0.1 289 ~ W9RF 7Q7RU RR73

213646 Tx 1325 ~ 7Q7RU W9RF 73



73,

W9RF - Joe



On Monday, November 16, 2020, 3:24:37 PM CST, Björn SM7IUN <bjorn@...> wrote:


It's not the DX that pulls you down in frequency. It's the logic in your WSJT-X just following the F/H protocol.

The fact that you succeeded just meant they could decode you correctly and has nothing to do with F/H or not. 
Or software compatibility for that matter.

If there are lots of LIDS using plain FT8 calling on or around the DX' frequency, you will struggle 
to make QSO with F/H since the frequency you move to (i.e. the carrier of the responding stream) 
is clobbered. If you are unlucky, the secondary (random but below 1000Hz) frequency the software 
moves you to after three failed attempts may still be that of a LID. 

Björn SM7IUN

Den mån 16 nov. 2020 kl 21:22 skrev ray cathode via groups.io <ray_cathode1=yahoo.com@groups.io>:
Roger,




For what it's worth here is another update on my unsuccessful confirmation with 7q7ru in F/H mode.

Yesterday evening the problem on 30 meters F/H mode was remedied buy switching out of F/H mode.


Same thing happened to me today.

While calling them at 18.095 F/H mode I was answered with a +1 report both ways and after a few exchanges I was thrown up to the 500+ slot and they began calling other calls.

I took Jtalert/WSJT-X out of F/H mode and called again with plain FT8 at 1325, third try they answered me, did NOT pull me down to their freq, and after 2 exchanges they gave me a confirmation (RR73)


SO, if anyone is having the same problem I have been experiencing I would suggest giving a plain FT8 a try.


I feel the only answer is software incompatibility at some level.

and before anyone asks, this is what I understand to be F/H  mode.

182145 Tx 1325 ~ 7Q7RU W9RF EM57

182200 1 0.1 286 ~ K4PX RR73; NB2P <7Q7RU> -10

182200 1 0.1 346 ~ W9RF 7Q7RU +01

182215 Tx 1325 ~ 7Q7RU W9RF R+01

182230 1 0.1 346 ~ W9RF 7Q7RU +01

182245 Tx 1325 ~ 7Q7RU W9RF R+01

182300 6 0.1 286 ~ W9RF RR73; W1KG <7Q7RU> -04








On Sunday, November 15, 2020, 9:07:50 PM CST, ray cathode via groups.io <ray_cathode1=yahoo.com@groups.io> wrote:


Roger,


I finally worked him just now on 10.131 but I was NOT in f/h mode, although he is in f/h mode, unless he switched on the fly, go figure??

Called him at 1500 and he did not call me to his freq but we exchanged reports and got a RR73 from him..


73,

W9RF - Joe








On Sunday, November 15, 2020, 6:52:45 PM CST, Roger M via groups.io <ac6bw=yahoo.com@groups.io> wrote:


Joe,
OK, fair enough. Yes, it does seem strange.
All I can suggest is keep trying. Are you using WSJT-X, or JTDX? I recently switched over to JTDX, because it has better decode sensitivity, as well as some other features that I like. If you have both programs installed, perhaps you can try one or the other in F/H mode, and see if that makes a difference.
Also, it's possible that something is not configured correctly on the Fox end, but I wouldn't know exactly what. There are a lot of settings that the Fox can enable.
--
73,
Roger
AC6BW


Björn SM7IUN
 

It's not the DX that pulls you down in frequency. It's the logic in your WSJT-X just following the F/H protocol.

The fact that you succeeded just meant they could decode you correctly and has nothing to do with F/H or not. 
Or software compatibility for that matter.

If there are lots of LIDS using plain FT8 calling on or around the DX' frequency, you will struggle 
to make QSO with F/H since the frequency you move to (i.e. the carrier of the responding stream) 
is clobbered. If you are unlucky, the secondary (random but below 1000Hz) frequency the software 
moves you to after three failed attempts may still be that of a LID. 

Björn SM7IUN

Den mån 16 nov. 2020 kl 21:22 skrev ray cathode via groups.io <ray_cathode1=yahoo.com@groups.io>:

Roger,




For what it's worth here is another update on my unsuccessful confirmation with 7q7ru in F/H mode.

Yesterday evening the problem on 30 meters F/H mode was remedied buy switching out of F/H mode.


Same thing happened to me today.

While calling them at 18.095 F/H mode I was answered with a +1 report both ways and after a few exchanges I was thrown up to the 500+ slot and they began calling other calls.

I took Jtalert/WSJT-X out of F/H mode and called again with plain FT8 at 1325, third try they answered me, did NOT pull me down to their freq, and after 2 exchanges they gave me a confirmation (RR73)


SO, if anyone is having the same problem I have been experiencing I would suggest giving a plain FT8 a try.


I feel the only answer is software incompatibility at some level.

and before anyone asks, this is what I understand to be F/H  mode.

182145 Tx 1325 ~ 7Q7RU W9RF EM57

182200 1 0.1 286 ~ K4PX RR73; NB2P <7Q7RU> -10

182200 1 0.1 346 ~ W9RF 7Q7RU +01

182215 Tx 1325 ~ 7Q7RU W9RF R+01

182230 1 0.1 346 ~ W9RF 7Q7RU +01

182245 Tx 1325 ~ 7Q7RU W9RF R+01

182300 6 0.1 286 ~ W9RF RR73; W1KG <7Q7RU> -04








On Sunday, November 15, 2020, 9:07:50 PM CST, ray cathode via groups.io <ray_cathode1=yahoo.com@groups.io> wrote:


Roger,


I finally worked him just now on 10.131 but I was NOT in f/h mode, although he is in f/h mode, unless he switched on the fly, go figure??

Called him at 1500 and he did not call me to his freq but we exchanged reports and got a RR73 from him..


73,

W9RF - Joe








On Sunday, November 15, 2020, 6:52:45 PM CST, Roger M via groups.io <ac6bw=yahoo.com@groups.io> wrote:


Joe,
OK, fair enough. Yes, it does seem strange.
All I can suggest is keep trying. Are you using WSJT-X, or JTDX? I recently switched over to JTDX, because it has better decode sensitivity, as well as some other features that I like. If you have both programs installed, perhaps you can try one or the other in F/H mode, and see if that makes a difference.
Also, it's possible that something is not configured correctly on the Fox end, but I wouldn't know exactly what. There are a lot of settings that the Fox can enable.
--
73,
Roger
AC6BW