locked #Important : JTDX users MUST use the JTAlert JTDX shortcut #Important


HamApps Support (VK3AMA)
 

In recent weeks there have been a number of users repeatedly spotting FT4 spots to HamSpots as Q65.

This is caused by the user using the JTAlert WSJT-X shortcut when running JTDX.

The problem stems from changes the JTDX people made to the WSJT-X UDP protocol. Specifically, the UDP decode message contains a single character that identifies the mode for the decode. The WSJT-X standard uses ":" to identify Q65, but JTDX chose to use ":" to identity FT4 decodes.

JTAlert overcomes this by using an alternate character to mode mapping table for JTDX users.

To change the character to mode mapping JTAlert needs to know what application you have JTAlert working against, WSJT-X or JTDX, this is why there are different shortcuts to start JTAlert, the Red "X" icon for WSJT-X and the Blue "X" icon for JTDX. This has been in place for quite some time.

Recently a number of users have been using the WSJT-X shortcut when running JTDX, as a result, if they are working FT4 all spots to HamSpots are flagged as Q65.

The fix is simple, use the correct JTAlert shortcut.


de Laurie VK3AMA


Jim Brown
 

Hi Laurie,
I use WSJT-X almost exclusively for very long haul DX on 160 and chasing grids on 6M. I don't use FT4, so this is not an issue for me. But a point of information for you -- last year, many 6M ops started using both WSJT-X and JTDX simultaneously, because both programs (but most often JTDX), catch a weak decode that the other misses.

73, Jim K9YC


On Tue, Jun 22, 2021 at 3:48 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
In recent weeks there have been a number of users repeatedly spotting FT4 spots to HamSpots as Q65.

This is caused by the user using the JTAlert WSJT-X shortcut when running JTDX.

The problem stems from changes the JTDX people made to the WSJT-X UDP protocol. Specifically, the UDP decode message contains a single character that identifies the mode for the decode. The WSJT-X standard uses ":" to identify Q65, but JTDX chose to use ":" to identity FT4 decodes.

JTAlert overcomes this by using an alternate character to mode mapping table for JTDX users.

To change the character to mode mapping JTAlert needs to know what application you have JTAlert working against, WSJT-X or JTDX, this is why there are different shortcuts to start JTAlert, the Red "X" icon for WSJT-X and the Blue "X" icon for JTDX. This has been in place for quite some time.

Recently a number of users have been using the WSJT-X shortcut when running JTDX, as a result, if they are working FT4 all spots to HamSpots are flagged as Q65.

The fix is simple, use the correct JTAlert shortcut.


de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 23/06/2021 2:31 pm, Jim Brown wrote:
I use WSJT-X almost exclusively for very long haul DX on 160 and chasing grids on 6M. I don't use FT4, so this is not an issue for me. But a point of information for you -- last year, many 6M ops started using both WSJT-X and JTDX simultaneously, because both programs (but most often JTDX), catch a weak decode that the other misses.

73, Jim K9YC
Jim,

Running WSJT-X and JTDX concurrently is not a problem, it is when someone is using JTDX and starting JTAlert with the WSJT-X shortcut, not the JTDX shortcut. By doing this the necessary character to mode remapping I need to do for JTDX FT4 spots doesn't get done and the FT4 spots appear as Q65. I have seen this mainly on 20m & 40m. I don't recall seeing it on 6m, but the band is not important.

de Laurie VK3AMA