Date   

Re: Strange UI phenomenon

Björn SM7IUN
 

Great! Thank you Laurie.

Björn

Den sön 25 okt. 2020 kl 05:49 skrev HamApps Support (VK3AMA) <vk3ama.ham.apps@...>:

On 22/10/2020 7:31 pm, Björn SM7IUN wrote:
From time to time I find the "Help" menu replaced by the name of a newly connected audio device.

Is this intentional? I assume not.

Also, JTAlert seems to suffer from the inability to handle UTF-8 in device names of which some are 
created by default in non-English Windows. The different effects of this have been reported previously.

Björn SM7IUN

Björn,

FYI, these problems have now been resolved. Newly added Sound Device names no longer replace the "Help" menu and UTF-8 encoded Sound Device names are correctly handled. eg.
   

Check your email, I have sent you a link to this new build to test.

de Laurie VK3AMA



Re: Strange UI phenomenon

HamApps Support (VK3AMA)
 

On 22/10/2020 7:31 pm, Björn SM7IUN wrote:
From time to time I find the "Help" menu replaced by the name of a newly connected audio device.

Is this intentional? I assume not.

Also, JTAlert seems to suffer from the inability to handle UTF-8 in device names of which some are 
created by default in non-English Windows. The different effects of this have been reported previously.

Björn SM7IUN

Björn,

FYI, these problems have now been resolved. Newly added Sound Device names no longer replace the "Help" menu and UTF-8 encoded Sound Device names are correctly handled. eg.
   

Check your email, I have sent you a link to this new build to test.

de Laurie VK3AMA



Re: Strange UI phenomenon

HamApps Support (VK3AMA)
 

On 25/10/2020 8:25 am, g4wjs wrote:
On 24/10/2020 21:41, HamApps Support (VK3AMA) wrote:
As for the UTF-8 naming issue, I am investigating why that is occurring. The underlying code that retrieves all the audio endpoints defined on the PC fully supports UTF-8. Something is being lost in getting that data over to the main JTAlert executable.

de Laurie VK3AMA

Hi Laurie,

this may not be relevant and your comment above just be using incorrect terminology, but wide-strings in Windows are not utf-8, they are 16-bit characters encoded with utf-16 little-edian Unicode values. You might convert them to multi-byte Unicode strings, utf-8 for example, to send over the network, store in a file, or other space constrained media.


--
73
Bill
G4WJS.
Tnx Bill,

My head starts hurting every-time I have to start thinking about ANSI, ASCII, UTF-8, Unicode, codepages, multi-byte versus single-byte strings, etc, etc.

With respect to this sound device name problem. The strings returned from enumerating the endpoints are variable-length encoded UTF-8, but it was getting those strings over to JTAlert that was the issue. The AutoIT based string comparison routines
of JTAlert were not UTF-8 compatible, combined with legacy XP era winmm.dll calls conspired to bring on a migraine! Its my own fault for clinging onto the old AutoIT code base for so long and trying to be clever integrating .NET code. Code refactoring is currently underway

de Laurie VK3AMA


Re: 8-character Gridsquare

onaka@...
 

Thank you Laurie.
WSJT-X and JTDX can set 8 characters on the grid.
In PSKReporter, if there are local stations with the same grid, the icon display will overlap, so I set it to 8 characters so that the icons do not overlap.
PSKReportr can display a grid of up to 10 characters.
JA4JOE


JTAlert Wanted Callsigns in Decodes window

iain macdonnell - N6ML
 


During ES season, I accumulated a list of callsigns known to be operating 6m from FFMA grids that I still need (that set of grids is getting smaller), hoping to get a jump on them if they showed up, perhaps before JTAlert knows what grid they're operating from.

Unfortunately "Wanted Callsign" is not band-specific (AFAIK?), so on returning to HF, I was getting a lot of alerts for those callsigns, but I don't need them on the HF bands. It'd be great if itcould be made band-specific, but that seems like it'd be a fair amount of development work.

So I turned off "Enable Wanted Callsign Alert", which stopped the alerts, but....

I use the "Decodes" window with Filter including "Show only Alerts" as a way to observe if anything that I need has been decoded recently (I often leave the decoder running while I do other things)...

... but those pesky "Wanted callsigns" still appear in the Decodes window! The "Alert" column is empty, yet they get though the filter. They clutter the decodes window quite a bit.

I could empty out my "Wanted callsigns" list, but I'd quite like to keep them for later, and this seems like a bug?

73,

    ~iain / N6ML


Re: #FT8/JTAlert

Dave Garber
 

follow the order of opening 
call up the settings, then manage settings.

scroll down the the + window.  do not click on the + symbol.  extended display options is on the right side, near the top

see image attached. 
keep in mind, this is from version 2.16.14


Dave Garber
VE3WEJ / VE3IE


On Fri, Oct 23, 2020 at 8:20 AM Wes Elton <wes@...> wrote:
Hi Jim,

Thanks for the info. Laurie has told me the same thing but within the window/decode settings there is no Extended Display/show db option☹!

I'm  clearly missing something and have  asked Laurie for further advice.

Stay sake OM.
73,
Wes.
GW3RIH

-----Original Message-----
From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Jim N6VH
Sent: 22 October 2020 20:52
To: Support@HamApps.groups.io
Subject: Re: [HamApps] #FT8/JTAlert


On 10/22/2020 12:42 PM, Wes Elton wrote:
> Hi All,
> Can someone please advise where I can find the settings info that will
> enable received signal strength to appear beneath calls in the
> callsign display lines.
> I've searched the help files but see anything relevant.
>
> Cheers,
>
> Wes.
> GW3RIH.

Wes,

Go to Settings/Window. Click Show db (DXCC Name)

73,

Jim N6VH













Re: Strange UI phenomenon

g4wjs
 
Edited

On 24/10/2020 21:41, HamApps Support (VK3AMA) wrote:
As for the UTF-8 naming issue, I am investigating why that is occurring. The underlying code that retrieves all the audio endpoints defined on the PC fully supports UTF-8. Something is being lost in getting that data over to the main JTAlert executable.

de Laurie VK3AMA

Hi Laurie,

this may not be relevant and your comment above just be using incorrect terminology, but wide-strings in Windows are not utf-8, they are 16-bit characters encoded with utf-16 little-edian Unicode values. You might convert them to multi-byte Unicode strings, utf-8 for example, to send over the network, store in a file, or other space constrained media.


--
73
Bill
G4WJS.


Re: Strange UI phenomenon

HamApps Support (VK3AMA)
 

On 25/10/2020 6:49 am, Björn SM7IUN wrote:
Asking all users of non-English Windows to use a virtual audio cable (or manually rename their main audio 
device) seems like a somewhat complex solution to the problem that audio device names in JTAlert 
are stored in byte arrays, but if you think this is the best solution I of course respect that.

Björn SM7IUN

That was not what I was suggesting. Using the VB-Cable pair was suggested as a workaround for cases when a user could not rename their device in Windows due to their device driver not supporting/remembering the change.

As for the UTF-8 naming issue, I am investigating why that is occurring. The underlying code that retrieves all the audio endpoints defined on the PC fully supports UTF-8. Something is being lost in getting that data over to the main JTAlert executable.

de Laurie VK3AMA




Re: Strange UI phenomenon

Björn SM7IUN
 

Thanks Laurie, 

Interesting. The problems I have had with audio devices falling asleep have all been possible to 
address via Windows' power management settings. But then I have never used any HDMI audio 
device in a ham radio context.

Asking all users of non-English Windows to use a virtual audio cable (or manually rename their main audio 
device) seems like a somewhat complex solution to the problem that audio device names in JTAlert 
are stored in byte arrays, but if you think this is the best solution I of course respect that.

Björn SM7IUN


Den lör 24 okt. 2020 kl 20:44 skrev HamApps Support (VK3AMA) <vk3ama.ham.apps@...>:

On 23/10/2020 5:13 pm, Björn SM7IUN wrote:
Thanks Laurie.

I reported the audio device naming issue here in March and Panos SV1GRN confirmed it.

In the thread the problem was initially believed to be about remembering settings but it 
was really about character sets. Perhaps the later parts of that thread went past you.

The workaround we found was to replace the name of the audio device assigned by 
Windows to a name containing only plain ASCII characters.

Windows' default name for an output audio device contains non-ASCII characters in many 
languages. "Speaker" is "Högtalare" in Swedish etc. If you try to use a device with such a 
name you will get a pop-up "Cannot locate the last used sound output device" every time 
you start the program, forcing you to select it once again. 

JTAlert seems to replace non-ASCII characters in the device name with a question 
mark. (See below). This is the likely reason for it not being correctly remembered.

If you rename your own speaker to something with umlauts or diacriticals you should 
be able to easily reproduce this.

73

Björn SM7IUN

Thanks Björn

An alternative to renaming the device in Windows (not all drivers allow for that change) is to use a virtual audio device pair like the free version of VB-Audio (https://vb-audio.com/Cable/) and having one end pointing at your device and have JTAlert using the other end.

Somewhat related, some audio devices go to sleep after a period of inactivity and then when coming out of sleep the first part of the sound (that triggered coming out of sleep) is missed. This is very common with Nvidia HDMI devices which go to sleep after only ~ 5 seconds. I have used the VB-Audio pair technique to prevent the HDMI device going to sleep and causing the first part of a sound being truncated.

de Laurie VK3AMA


Re: 8-character Gridsquare

HamApps Support (VK3AMA)
 

On 23/10/2020 8:12 pm, onaka@... wrote:
I want the PSK reporter display to not overlap with the local station.
For this reason,  WSJT-X Gridsquare is set to 8 characters.
From Version 2.16.14, the attached warning is displayed when starting JTAlert.
Is it possible to stop the warning?
JA4JOE

JTAlert has long had the Grid mismatch warning, not just with 2.16.14.

WSJT-X and JTAlert both restrict Grids to 6 characters maximum.

WSJT-X doesn't allow for entering of more than 6 characters on the main window or in its Settings window. Similarly, JTAlert doesn't allow for more that 6 characters.

Since 8 character grids are not conveyed on air via FT8 or any of the other supported modes, I don't see any reason to extend JTAlert to use 8 character Grids.

Your only solution to this is to remove the 8 character edit you applied to the WSJT-X ini file.

I don't see how PSKReporter is relevant.

de Laurie VK3AMA


Re: Strange UI phenomenon

HamApps Support (VK3AMA)
 

On 23/10/2020 5:13 pm, Björn SM7IUN wrote:
Thanks Laurie.

I reported the audio device naming issue here in March and Panos SV1GRN confirmed it.

In the thread the problem was initially believed to be about remembering settings but it 
was really about character sets. Perhaps the later parts of that thread went past you.

The workaround we found was to replace the name of the audio device assigned by 
Windows to a name containing only plain ASCII characters.

Windows' default name for an output audio device contains non-ASCII characters in many 
languages. "Speaker" is "Högtalare" in Swedish etc. If you try to use a device with such a 
name you will get a pop-up "Cannot locate the last used sound output device" every time 
you start the program, forcing you to select it once again. 

JTAlert seems to replace non-ASCII characters in the device name with a question 
mark. (See below). This is the likely reason for it not being correctly remembered.

If you rename your own speaker to something with umlauts or diacriticals you should 
be able to easily reproduce this.

73

Björn SM7IUN

Thanks Björn

An alternative to renaming the device in Windows (not all drivers allow for that change) is to use a virtual audio device pair like the free version of VB-Audio (https://vb-audio.com/Cable/) and having one end pointing at your device and have JTAlert using the other end.

Somewhat related, some audio devices go to sleep after a period of inactivity and then when coming out of sleep the first part of the sound (that triggered coming out of sleep) is missed. This is very common with Nvidia HDMI devices which go to sleep after only ~ 5 seconds. I have used the VB-Audio pair technique to prevent the HDMI device going to sleep and causing the first part of a sound being truncated.

de Laurie VK3AMA


Re: Audible Alerts

Norm Fasoletos
 

Yes I have selected a sound file for each alert and tested it...works, except when someone call me..

Norm - K7NWF



On Oct 23, 2020, at 11:26 AM, chas cartmel <chas@...> wrote:



You say settings OK. Can I assume you have selected each of the sound files for each alert?


73 Charlie

G4EST

www.g4est.me.uk

Stay safe out there

 

 

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: 23 October 2020 18:24
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Audible Alerts

 

On 23/10/2020 5:04 pm, Norm Fasoletos wrote:

I have all the settings correct, when I test the sound "calling you" it works fine, I hear it. When someone calls me, I get a visual indication in red but no sound.

 

Not sure where to look further?

 

Norm - K7NWF


Norm,

Your settings image looks fine.

Please use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis.

de Laurie VK3AMA


Re: Question

Neil Foster
 

Thanks Laurie for pointing me in the right direction...now fixed
73 and stay well
Neil   N4FN


Re: Audible Alerts

chas cartmel
 

You say settings OK. Can I assume you have selected each of the sound files for each alert?


73 Charlie

G4EST

www.g4est.me.uk

Stay safe out there

 

 

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: 23 October 2020 18:24
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Audible Alerts

 

On 23/10/2020 5:04 pm, Norm Fasoletos wrote:

I have all the settings correct, when I test the sound "calling you" it works fine, I hear it. When someone calls me, I get a visual indication in red but no sound.

 

Not sure where to look further?

 

Norm - K7NWF


Norm,

Your settings image looks fine.

Please use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis.

de Laurie VK3AMA


Re: Audible Alerts

HamApps Support (VK3AMA)
 

On 23/10/2020 5:04 pm, Norm Fasoletos wrote:
I have all the settings correct, when I test the sound "calling you" it works fine, I hear it. When someone calls me, I get a visual indication in red but no sound.

Not sure where to look further?

Norm - K7NWF

Norm,

Your settings image looks fine.

Please use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis.

de Laurie VK3AMA


#FT8/JTAlert

Wes Elton
 

Hi Mike,

Got it😊!

Many thanks Mike, appreciate your help.

73,

Wes.

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Michael Black via groups.io
Sent: 23 October 2020 13:22
To: Support@HamApps.groups.io
Subject: Re: [HamApps] #FT8/JTAlert

 

It's not under Decodes....it's on the Window menu -- the one with the red box around it.

 

Mike W9MDB

 

 

 

 

On Friday, October 23, 2020, 07:20:13 AM CDT, Wes Elton <wes@...> wrote:

 

 

Hi Laurie,

 

Many thanks for the speedy response.

 

I’m running JTAlert version 2.16.4.

 

Under Window/Decodes the page displayed only shows Enable Decodes which is checked with, at the bottom of the page, Display Options which are unchecked. Checking them doesn’t make the required change. There are no Extended Display options in view.

 

Apologies if I’m missing something obvious!

 

Regards,

Wes.GW3RIH.

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: 22 October 2020 21:14
To: Support@HamApps.groups.io
Subject: Re: [HamApps] #FT8/JTAlert

 

On 23/10/2020 6:42 am, Wes Elton wrote:

Can someone please advise where I can find the settings info that will enable received signal strength to appear beneath calls in the callsign display lines.
I've searched the help files but see anything relevant.

Cheers,

Wes.
GW3RIH.



de Laurie VK3AMA


Re: #FT8/JTAlert

Wes Elton
 

Hi Laurie,

 

Found it😊! I was making the mistake of clicking where your cursor was not on the word windows.

As ever, thanks for your help and for the superb JTAlert software.

Much appreciated.

Stay safe OM.

73,

Wes.

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: 22 October 2020 21:14
To: Support@HamApps.groups.io
Subject: Re: [HamApps] #FT8/JTAlert

 

On 23/10/2020 6:42 am, Wes Elton wrote:

Can someone please advise where I can find the settings info that will enable received signal strength to appear beneath calls in the callsign display lines.
I've searched the help files but see anything relevant.

Cheers,

Wes.
GW3RIH.



de Laurie VK3AMA


8-character Gridsquare

onaka@...
 

I want the PSK reporter display to not overlap with the local station.
For this reason,  WSJT-X Gridsquare is set to 8 characters.
From Version 2.16.14, the attached warning is displayed when starting JTAlert.
Is it possible to stop the warning?
JA4JOE


Re: #FT8/JTAlert

Michael Black
 

It's not under Decodes....it's on the Window menu -- the one with the red box around it.

Mike W9MDB




On Friday, October 23, 2020, 07:20:13 AM CDT, Wes Elton <wes@...> wrote:


Hi Laurie,

 

Many thanks for the speedy response.

 

I’m running JTAlert version 2.16.4.

 

Under Window/Decodes the page displayed only shows Enable Decodes which is checked with, at the bottom of the page, Display Options which are unchecked. Checking them doesn’t make the required change. There are no Extended Display options in view.

 

Apologies if I’m missing something obvious!

 

Regards,

Wes.GW3RIH.

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: 22 October 2020 21:14
To: Support@HamApps.groups.io
Subject: Re: [HamApps] #FT8/JTAlert

 

On 23/10/2020 6:42 am, Wes Elton wrote:

Can someone please advise where I can find the settings info that will enable received signal strength to appear beneath calls in the callsign display lines.
I've searched the help files but see anything relevant.

Cheers,

Wes.
GW3RIH.



de Laurie VK3AMA


#FT8/JTAlert

Wes Elton
 

Hi Laurie,

 

Many thanks for the speedy response.

 

I’m running JTAlert version 2.16.4.

 

Under Window/Decodes the page displayed only shows Enable Decodes which is checked with, at the bottom of the page, Display Options which are unchecked. Checking them doesn’t make the required change. There are no Extended Display options in view.

 

Apologies if I’m missing something obvious!

 

Regards,

Wes.GW3RIH.

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: 22 October 2020 21:14
To: Support@HamApps.groups.io
Subject: Re: [HamApps] #FT8/JTAlert

 

On 23/10/2020 6:42 am, Wes Elton wrote:

Can someone please advise where I can find the settings info that will enable received signal strength to appear beneath calls in the callsign display lines.
I've searched the help files but see anything relevant.

Cheers,

Wes.
GW3RIH.



de Laurie VK3AMA