locked Not alerting new DXCC when double message comes in


Paul AC9O
 

I noticed this today. Running v2.5.0 or WSJT-X and V2.50.7 of JT Alert.

3DA0WW alerts when the message is standard, but does not when it's combined as seen below.

Thanks and 73
Paul, AC9O


Joe Subich, W4TV
 

JT Alert has *never* highlighted on the "compound" (or Fox/Hound)
messages. You can see that with "real" F/H operation on dedicated
frequencies. JTAlert will highlight "standard" messages (messages
to one station) but not the compound (report to one station, RR73
to a second) messages.

Laurie, will need to explain what is different in the UDP traffic
from WSJTX that prevents that but I suspect it is due to some
missing data in the UDP specification.

73,

... Joe, W4TV

On 2021-10-20 10:52 AM, Paul AC9O wrote:
I noticed this today. Running v2.5.0 or WSJT-X and V2.50.7 of JT Alert.
3DA0WW alerts when the message is standard, but does not when it's combined as seen below.
Thanks and 73
Paul, AC9O


g4wjs
 

Hi Joe,

that's unlikely Joe, the decoded message is included, in full, in the Decode UDP messages.

73
Bill
G4WJS.

On 20/10/2021 16:28, Joe Subich, W4TV wrote:

JT Alert has *never* highlighted on the "compound" (or Fox/Hound)
messages.  You can see that with "real" F/H operation on dedicated
frequencies.  JTAlert will highlight "standard" messages (messages
to one station) but not the compound (report to one station, RR73
to a second) messages.

Laurie, will need to explain what is different in the UDP traffic
from WSJTX that prevents that but I suspect it is due to some
missing data in the UDP specification.

73,

   ... Joe, W4TV


On 2021-10-20 10:52 AM, Paul AC9O wrote:
I noticed this today. Running v2.5.0 or WSJT-X and V2.50.7 of JT Alert.

3DA0WW alerts when the message is standard, but does not when it's combined as seen below.

Thanks and 73
Paul, AC9O



--
73
Bill
G4WJS.


Joe Subich, W4TV
 

that's unlikely Joe, the decoded message is included, in full, in the
Decode UDP messages.
I haven't seen specifications for the decoded messages but Laurie is
only looking at the second field. That is he highlights on (standard)
messages in the form of: <callsign_1> <callsign_2> <report> or
CQxx <Callsign> <grid> (grid being optional)

If the wanted (DX) call is in the fourth field, he's not looking there
(only a "compound" message has more than three fields).

73,

... Joe, W4TV


On 2021-10-20 11:49 AM, g4wjs wrote:
Hi Joe,
that's unlikely Joe, the decoded message is included, in full, in the Decode UDP messages.
73
Bill
G4WJS.
On 20/10/2021 16:28, Joe Subich, W4TV wrote:

JT Alert has *never* highlighted on the "compound" (or Fox/Hound)
messages.  You can see that with "real" F/H operation on dedicated
frequencies.  JTAlert will highlight "standard" messages (messages
to one station) but not the compound (report to one station, RR73
to a second) messages.

Laurie, will need to explain what is different in the UDP traffic
from WSJTX that prevents that but I suspect it is due to some
missing data in the UDP specification.

73,

   ... Joe, W4TV


On 2021-10-20 10:52 AM, Paul AC9O wrote:
I noticed this today. Running v2.5.0 or WSJT-X and V2.50.7 of JT Alert.

3DA0WW alerts when the message is standard, but does not when it's combined as seen below.

Thanks and 73
Paul, AC9O
--
73
Bill
G4WJS.


HamApps Support (VK3AMA)
 

On 21/10/2021 1:52 am, Paul AC9O wrote:
3DA0WW alerts when the message is standard, but does not when it's combined as seen below.

Thanks and 73
Paul, AC9O
JTAlert currently does not handle the WSJTX multi-message format decodes for Fox/Hound mode. Any decode that appears to be of a non-standard type is discarded. Decodes containing one or more ";" characters fall into this category.

Interesting that your image shows lots of non-Fox/Hound decodes, was 3DA0WW operating in F/H mode in the common FT8 watering-holes? I thought WSJTX locked out F/H from theses common frequencies.

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 21/10/2021 2:28 am, Joe Subich, W4TV wrote:
Laurie, will need to explain what is different in the UDP traffic
from WSJTX that prevents that but I suspect it is due to some
missing data in the UDP specification.

73,

   ... Joe, W4TV

Joe,

There is nothing unusual/different in the UDP data for these multi-message format F/H decodes. JTAlert is not alerting because it is not coded to consider the semicolon delimited messages. They are seen as non-standard format decode messages and are simply ignored. This is due to the decode parsing code having been written long before F/H mode existed.

When F/H mode was released, it was deemed non-critical that Fox callsigns were not alerted since hound stations would knew who they were chasing as the activity was restricted to frequencies away from the standard FT8 watering-holes.

Now that we have inconsiderate DXpeditions polluting the bands with their activity in the traditional non-dxpedition areas of activity, I will look at refactoring the message parsing/alerting code to consider all parts of a multi-message decode. I'll posts a new build to the Test group when it is done.

de Laurie VK3AMA


Ron W3RJW
 

On Wed, Oct 20, 2021 at 11:50 PM, HamApps Support (VK3AMA) wrote:
Interesting that your image shows lots of non-Fox/Hound decodes, was 3DA0WW operating in F/H mode in the common FT8 watering-holes?
3DA0WW was/is using MSHV or like (Multi carrier variant) often on the standard frequencies.
 
--
73
Ron, W3RJW

FTdx-5000, Timewave Navigator, WSJT-x Improved 2.5.0, JTAlert 2.50.7, HRD Deluxe v6.7.0.391
FTdx-3000, SignaLink USB


Michael
 

Hi Laurie

Neither 3DA0WW nor 3DA0RU was in F/H mode at any time. For some people it looks like they was. Both #DA Stations (and S9OK) are using MSHV Software. At non-standard FT8 QRG's MSHV can work in up to 5 channals at the same time just as wsjt-x. So on those QRG's it looks like F/H but it ain't. At standard FT8 QRG's MSHV can only work in one channal in the same time but can still send out SPmg (msg to two stations in same line) and that's what confusing people. S9OK was operating on Non-standard FT8 QRG's in Multichannal Mode and one could work them in either F/H or Standard FT8 Mode.

73 de Michael 5p1kzx


Den 21-10-2021 kl. 05:50 skrev HamApps Support (VK3AMA):

On 21/10/2021 1:52 am, Paul AC9O wrote:
3DA0WW alerts when the message is standard, but does not when it's combined as seen below.

Thanks and 73
Paul, AC9O
JTAlert currently does not handle the WSJTX multi-message format decodes for Fox/Hound mode. Any decode that appears to be of a non-standard type is discarded. Decodes containing one or more ";" characters fall into this category.

Interesting that your image shows lots of non-Fox/Hound decodes, was 3DA0WW operating in F/H mode in the common FT8 watering-holes? I thought WSJTX locked out F/H from theses common frequencies.

de Laurie VK3AMA





Dave Garber
 

Laurie, as far as I saw, 3da0   ( all of them ) were using the mshv as a get around for not using F/H.   when busy, they also moved off the normal frequency

Dave Garber
VE3WEJ / VE3IE


On Wed, Oct 20, 2021 at 11:50 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 21/10/2021 1:52 am, Paul AC9O wrote:
> 3DA0WW alerts when the message is standard, but does not when it's
> combined as seen below.
>
> Thanks and 73
> Paul, AC9O

JTAlert currently does not handle the WSJTX multi-message format decodes
for Fox/Hound mode. Any decode that appears to be of a non-standard type
is discarded. Decodes containing one or more ";" characters fall into
this category.

Interesting that your image shows lots of non-Fox/Hound decodes, was
3DA0WW operating in F/H mode in the common FT8 watering-holes? I thought
WSJTX locked out F/H from theses common frequencies.

de Laurie VK3AMA