Date   

locked Re: Ignored Call Signs/Automatically Clear on Startup?

Bill Barrett
 

Hi Laurie-

Sri about being confused. However, unchecking the HotKeys feature
eliminates the keyboard slowdown.
Thanks for researching this problem.
Bill W2PKY

On Sat, Sep 26, 2020 at 5:39 PM Laurie, VK3AMA
<hamapps.support@vkdxer.com> wrote:



On 27/09/2020 7:23 am, Bill W2PKY wrote:
Laurie-
I did not see any improvement
Bill W2PKY
Bill,

Wrong message thread?

Your referring to the build I sent you with a tweak for the keyboard
latency. This thread is in relation to a build that has a new temporary
ignored callsign feature.

de Laurie VK3AMA






--
Bill Barrett
352-437-4758


locked Re: Ignored Call Signs/Automatically Clear on Startup?

Laurie, VK3AMA
 

On 27/09/2020 7:23 am, Bill W2PKY wrote:
Laurie-
I did not see any improvement
Bill W2PKY
Bill,

Wrong message thread?

Your referring to the build I sent you with a tweak for the keyboard latency. This thread is in relation to a build that has a new temporary ignored callsign feature.

de Laurie VK3AMA


locked Re: Ignored Call Signs/Automatically Clear on Startup?

Bill W2PKY
 

Laurie-
I did not see any improvement 
Bill W2PKY 


On Sep 26, 2020, at 16:42, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 18/09/2020 8:58 am, commercialpilot01@... wrote:
Yes, that's a better/more comprehensive solution.  More work, too.  I'll look forward to it.

W0KDT
W0KDT,

How did the new JTAlert build, with the temp ignored option, I sent you work out? I would appreciate some feedback.

de Laurie VK3AMA


locked Re: Ignored Call Signs/Automatically Clear on Startup?

HamApps Support (VK3AMA)
 

On 18/09/2020 8:58 am, commercialpilot01@... wrote:
Yes, that's a better/more comprehensive solution.  More work, too.  I'll look forward to it.

W0KDT
W0KDT,

How did the new JTAlert build, with the temp ignored option, I sent you work out? I would appreciate some feedback.

de Laurie VK3AMA


locked Re: Keyboard latency with multiple JTAlert processes running.

HamApps Support (VK3AMA)
 

On 26/09/2020 10:09 pm, Bill Barrett wrote:
The PC CPU is only stressed during the decode period. Otherwise the
CPU is 93% idle.
WSJT-X and JTA take almost no CPU power during the sampling process.
The keyboard slow down is noticed anytime.
I'm sure Laurie will determine the cause and correct the problem now
that it's been uncovered.
Since most users do not run more than one instance of JTA and "X" they
do not notice the problem.
Bill W2PKY

Bill,

Resolving this issue will likely not happen until the root cause is identified.

At this time, I am unable to reproduce this keyboard input latency issue you describe.

I just now ran a test on a heavily loaded PC, 12 WSJT-X/JTAlert instances without observing any keystroke backlog.
While I don't have a Flex or the associated SDR software (I suspect this is may be where the incompatibility lies) the test environment included Firefox (~ 50 tabs open), Chrome (~15 tabs with one open playing a YouTube video), A TeamViewer session to a remote PC, Thunderbird for email, and 2 instances of Visual Studio.

de Laurie VK3AMA


locked MYSQL Connection Error: Client does not support authentication protocol requested by server; consider upgrading MySQL client

 

Laurie,
I know this is probably not a high priority item: Any view of JTAlert V3 in which you indicated you would support SSL MySQL connections using the official Oracle client.

73 de k1jbd
bammi


locked Re: Keyboard latency with multiple JTAlert processes running.

HamApps Support (VK3AMA)
 

On 27/09/2020 12:02 am, Bill Barrett wrote:
The timings reported by this routine are the same with multiple JTAs running or none.
The problem is after the keyboard interrupts are captured they get stacked up somewhere and released in batches.
Bill W2PKY
Bill,

Try disabling the HotKeys in JTAlert. "Miscellaneous -> Hot Keys" section of the Settings window.
With multiple instances and a single shared JTAlert config to ensure the setting change is retained do the following..
  • Shutdown all JTAlert instances
  • Start a single instance
  • Disable HotKeys in the Settings window.
  • Start your other JTAlert instances.

Low-level HotKey code in JTAlert are handled by a third-party library. That library may be conflicting with your Flex software.

de Laurie VK3AMA


locked Re: Keyboard latency with multiple JTAlert processes running.

HamApps Support (VK3AMA)
 

On 26/09/2020 8:46 pm, m_scot_alex wrote:
Laurie - I think this a keyboard event trapping race condition caused by 'hotkey' overlays in other programs. I'm travelling and this difficult to isolate remotely because of remote access latency, but I reduced the keyboard latency on my main JT-mode system by stopping an Intel video 'hotkey' utility. I'll provide more data next week and can send you a support request if you think it would help.

73,

Mike - N8MSA

Mike,

Try disabling the HotKeys in JTAlert. "Miscellaneous -> Hot Keys" section of the Settings window.
With multiple instances and a single shared JTAlert config to ensure the setting change is retained do the following..
  • Shutdown all JTAlert instances
  • Start a single instance
  • Disable HotKeys in the Settings window.
  • Start your other JTAlert instances.

Low-level HotKey code in JTAlert are handled by a third-party library. That library may be conflicting with your Flex software.

de Laurie VK3AMA


locked Re: Keyboard latency with multiple JTAlert processes running.

Bill Barrett
 

Hello Mike-
The timings reported by this routine are the same with multiple JTAs running or none.
The problem is after the keyboard interrupts are captured they get stacked up somewhere and released in batches.
Bill W2PKY

On Sat, Sep 26, 2020 at 9:18 AM Michael Black via groups.io <mdblack98=yahoo.com@groups.io> wrote:
Try this website and start flicking keys.  It will tell you the key down time it sees.
I found flicking a cursor key worked pretty well to get 1ms times frequently.

Also check these settings...in particular the bounce time.
And I found this utility which may be of use in diagnosing things
Inline image


Mike W9MDB


On Saturday, September 26, 2020, 07:10:10 AM CDT, Bill Barrett <billbarrett174@...> wrote:


Tom-
The PC CPU is only stressed during the decode period. Otherwise the
CPU is 93% idle.
WSJT-X and JTA take almost no CPU power during the sampling process.
The keyboard slow down is noticed anytime.
I'm sure Laurie will determine the cause and correct the problem now
that it's been uncovered.
Since most users do not run more than one instance of JTA and "X" they
do not notice the problem.
Bill W2PKY

On Sat, Sep 26, 2020 at 1:57 AM TomK <QSO@...> wrote:
>
> From the FWIW (For What It's Worth) depart.
> Sorry, if you know this, it have help others understand CPU loading issues.
>
> WSJT and JTA present X-Large and Large processor task loads.
> For JTA alone, think about the high message rate to display, lookup, resolve, flag, audio alert ... whoa!
>
> As processes consume PC cycles, other processes are obviously given less time.
> Moreover, a keyboard is an interrupt-driven task.
> When you click a key, interrupts are thrown, the BIOS passes it to the OS.
> It then passes control to an interrupt handler which passes control to registered s/w handlers.
> The registered interrupt handlers do their things then finish (consuming more CPU cycles).
> Only at a logically high level, are interrupts "asynchronous".
> The reality is that multiple interrupts may asynchronously trig interrupt handlers.
> However, once those handlers start to execute, the same CPU's cycles are consumed for all tasks.
> At each CPU's level, you have synchronous code streams.
> Multicore CPUs can ameliorate that but their allocations are seldom what an app would like.
> While all that is happening, the CPU is still being interrupted 6 ways from Sunday.
> So, with all that intense backdrop, you still have intense CPU tasks to execute.
>
> So, a keyboard should and will slow down when the CPU is already heavily occupied and can't process all the interrupts.
> Add 2, 3, or more JTA's and/or WSJT and it all gets that much worse.
>
> The fact that NOT running any JTA instances makes your k/b faster seems entirely logical and expected.
>
> I only suspect empirically, without seeing the code, that JTA doesn't do a lot of k/b interrupts itself.
>
> In short, it's bloody amazing that a PC can handle the intense FFT's in WSJT as well as all that JTA does.
>
> Just my 13 cents
> TomK KT1TK 73
>
>
> -----Original Message-----
> From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Bill Barrett
> Sent: Friday, September 25, 2020 7:42 AM
> To: Support@hamapps.groups.io
> Subject: Re: [HamApps] Keyboard latency with multiple JTAlert processes running.
>
> Hello Laurie-
>
> I have noticed this for a long time. Never knew what caused it. Always assumed it was due to running multiple instances of WSJT-X.
> The reason Flex users notice it is because we have multiple slices and run multiple instances of WSJT-X.
> The keyboard delay is definitely related to using JTAlert. Without JTAlert the keyboard response if fast.
> In my case with the 6700 can run as many as 8 instances of "X" and JTAlert. Then the keyboard response seems stacked up.
> When pressing down on the left or right arrow key may take a second before there is a response on the screen and then the cursor moves several positions.
> Hard to tell where the interference is happening, however, seems like the keyboard interrupt handler is stalled.
> Hope this helps.
> Bill W2PKY
>
>
> On Thu, Sep 24, 2020 at 10:44 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
> >
> > On 23/09/2020 6:54 am, Patrick Skerrett wrote:
> >
> > Has anyone encountered this before?
> >
> > I am running version 2.16.13 of jtalert, 2.2.2 of WSJT-x and 15.8.0 of Dxkeeper.
> >
> > W9PDS
> >
> >
> > Has this always been a problem with your Flex and multi-instance JTAlert or is it a recent manifestation? If it is recent, what was the last version of JTAlert that didn't exhibit this behavior?
> >
> > de Laurie VK3AMA
> >
> >
> >
>
>
>
> --
> Bill Barrett
> 352-437-4758
>
>
>
>
>
>
>
>
>
>
>
>


--
Bill Barrett
352-437-4758







--
Bill Barrett
352-437-4758


locked Re: Any plans to add more RX squares ?

Hasan Schiers N0AN
 

I would like a filter that allows us to exclude USA only, NA is too broad, misses some of the more interesting Carribean islands.

...and I agree more squares is just a distraction as well as slowing things down. 

So, atm, the only filter I find that helps is worked b4 filter. That reduces things a bit, but a USA filter (for display, while still permitting new STATE and Grid by Band Alerts), would be most welcome.

73, N0AN
Hasan


On Sat, Sep 26, 2020 at 8:52 AM Bill Barrett <billbarrett174@...> wrote:
Hello Tom-
This is a big help but wish the filter was applied to the regular JTA
window as well.
For those not familiar with the decodes window, Left click VIEW on JTA
window, Left click on Decode Window.
Follow Tom's directions.

On Sat, Sep 26, 2020 at 2:17 AM TomK <QSO@...> wrote:
>
> Not sure this is what you want but there is a way to filter out 1+ DXCC's.
>
> Wait till you see any US station in the DECODES window.
> Then Right-Click "United States" in the [Country Name] column.
> The select "Hide DXCC Name = United States"
> Then use the [Filter] menu to save this filter as something like "All but US"
> Will that do it for you?
>
> TomK KT1TK 73
>
> -----Original Message-----
> From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Bill Barrett
> Sent: Friday, September 25, 2020 7:51 AM
> To: Support@hamapps.groups.io
> Subject: Re: [HamApps] Any plans to add more RX squares ?
>
> Since I'm only interested in DX I filter out NA and that reduces the displayed calls to a few even on 20M. I would like one added filter to exclude only USA calls since the caribbean is of interest to me.
> Finally, would be nice if the filters were selectable for each instance of JTAlert.
> Bill W2PKY
>
> On Thu, Sep 24, 2020 at 8:48 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
> >
> > On 25/09/2020 10:15 am, ed.n5dg@... wrote:
> >
> > 36 RX squares is fine on most bands . 20m and 40m being the busy bands an extra 16 squares would be about right . instead of 4 x 9 squares 4 X 13 would make the width about the same as WSJTX.
> > Thanks for the great SW , Ed N5DG
> >
> >
> > Ed,
> >
> > This has been discussed many time. See
> > https://hamapps.groups.io/g/Support/message/29940
> >
> > IMHO, 36 displayed Callsigns is TOO many. It is a chaotic mess of multiple colored callsigns. A better option is to filter out most of the unwanted Callsigns. Use the Alert Filters to help reduce the number displayed. Try filtering out B4s and non-alerting callsigns.
> >
> > A JTAlert window with few callsigns displayed due to filtering makes for a more enjoyable (IMO) experience in the shack. It is less stressful time without trying to decide every 15 seconds which Callsign could be a possible QSO candidate. It is a far less chaotic experience.
> >
> > The beauty with filtering is that a Callsign that is displayed in JTAlert (has passed the filtering) is likely a good candidate for a QSO. But this approach wont appeal to those more interested in racking up a high QSO count, that is qso "quantity" rather than qso "quality".
> >
> > Currently, there is code with the Test Team (not yet available for public release) that removes the limit on the number of displayed Callsigns. While this new code allows for more than 36 callsigns, its primary focus is providing a flexible display window without any size restriction (width or height) with flexible sizing comes the additional benefit of increased callsigns displayed. Sorry, there is no ETA on when this will be available publicly.
> >
> > de Laurie VK3AMA
> >
> >
>
>
>
> --
> Bill Barrett
> 352-437-4758
>
>
>
>
>
>
>
>
>
>
>
>


--
Bill Barrett
352-437-4758






locked Re: Any plans to add more RX squares ?

Bill Barrett
 

Hello Tom-
This is a big help but wish the filter was applied to the regular JTA
window as well.
For those not familiar with the decodes window, Left click VIEW on JTA
window, Left click on Decode Window.
Follow Tom's directions.

On Sat, Sep 26, 2020 at 2:17 AM TomK <QSO@kt1tk.com> wrote:

Not sure this is what you want but there is a way to filter out 1+ DXCC's.

Wait till you see any US station in the DECODES window.
Then Right-Click "United States" in the [Country Name] column.
The select "Hide DXCC Name = United States"
Then use the [Filter] menu to save this filter as something like "All but US"
Will that do it for you?

TomK KT1TK 73

-----Original Message-----
From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Bill Barrett
Sent: Friday, September 25, 2020 7:51 AM
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Any plans to add more RX squares ?

Since I'm only interested in DX I filter out NA and that reduces the displayed calls to a few even on 20M. I would like one added filter to exclude only USA calls since the caribbean is of interest to me.
Finally, would be nice if the filters were selectable for each instance of JTAlert.
Bill W2PKY

On Thu, Sep 24, 2020 at 8:48 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@gmail.com> wrote:

On 25/09/2020 10:15 am, ed.n5dg@gmail.com wrote:

36 RX squares is fine on most bands . 20m and 40m being the busy bands an extra 16 squares would be about right . instead of 4 x 9 squares 4 X 13 would make the width about the same as WSJTX.
Thanks for the great SW , Ed N5DG


Ed,

This has been discussed many time. See
https://hamapps.groups.io/g/Support/message/29940

IMHO, 36 displayed Callsigns is TOO many. It is a chaotic mess of multiple colored callsigns. A better option is to filter out most of the unwanted Callsigns. Use the Alert Filters to help reduce the number displayed. Try filtering out B4s and non-alerting callsigns.

A JTAlert window with few callsigns displayed due to filtering makes for a more enjoyable (IMO) experience in the shack. It is less stressful time without trying to decide every 15 seconds which Callsign could be a possible QSO candidate. It is a far less chaotic experience.

The beauty with filtering is that a Callsign that is displayed in JTAlert (has passed the filtering) is likely a good candidate for a QSO. But this approach wont appeal to those more interested in racking up a high QSO count, that is qso "quantity" rather than qso "quality".

Currently, there is code with the Test Team (not yet available for public release) that removes the limit on the number of displayed Callsigns. While this new code allows for more than 36 callsigns, its primary focus is providing a flexible display window without any size restriction (width or height) with flexible sizing comes the additional benefit of increased callsigns displayed. Sorry, there is no ETA on when this will be available publicly.

de Laurie VK3AMA



--
Bill Barrett
352-437-4758











--
Bill Barrett
352-437-4758


locked Re: Keyboard latency with multiple JTAlert processes running.

Michael Black
 

Try this website and start flicking keys.  It will tell you the key down time it sees.
I found flicking a cursor key worked pretty well to get 1ms times frequently.

Also check these settings...in particular the bounce time.
And I found this utility which may be of use in diagnosing things
Inline image


Mike W9MDB


On Saturday, September 26, 2020, 07:10:10 AM CDT, Bill Barrett <billbarrett174@...> wrote:


Tom-
The PC CPU is only stressed during the decode period. Otherwise the
CPU is 93% idle.
WSJT-X and JTA take almost no CPU power during the sampling process.
The keyboard slow down is noticed anytime.
I'm sure Laurie will determine the cause and correct the problem now
that it's been uncovered.
Since most users do not run more than one instance of JTA and "X" they
do not notice the problem.
Bill W2PKY

On Sat, Sep 26, 2020 at 1:57 AM TomK <QSO@...> wrote:
>
> From the FWIW (For What It's Worth) depart.
> Sorry, if you know this, it have help others understand CPU loading issues.
>
> WSJT and JTA present X-Large and Large processor task loads.
> For JTA alone, think about the high message rate to display, lookup, resolve, flag, audio alert ... whoa!
>
> As processes consume PC cycles, other processes are obviously given less time.
> Moreover, a keyboard is an interrupt-driven task.
> When you click a key, interrupts are thrown, the BIOS passes it to the OS.
> It then passes control to an interrupt handler which passes control to registered s/w handlers.
> The registered interrupt handlers do their things then finish (consuming more CPU cycles).
> Only at a logically high level, are interrupts "asynchronous".
> The reality is that multiple interrupts may asynchronously trig interrupt handlers.
> However, once those handlers start to execute, the same CPU's cycles are consumed for all tasks.
> At each CPU's level, you have synchronous code streams.
> Multicore CPUs can ameliorate that but their allocations are seldom what an app would like.
> While all that is happening, the CPU is still being interrupted 6 ways from Sunday.
> So, with all that intense backdrop, you still have intense CPU tasks to execute.
>
> So, a keyboard should and will slow down when the CPU is already heavily occupied and can't process all the interrupts.
> Add 2, 3, or more JTA's and/or WSJT and it all gets that much worse.
>
> The fact that NOT running any JTA instances makes your k/b faster seems entirely logical and expected.
>
> I only suspect empirically, without seeing the code, that JTA doesn't do a lot of k/b interrupts itself.
>
> In short, it's bloody amazing that a PC can handle the intense FFT's in WSJT as well as all that JTA does.
>
> Just my 13 cents
> TomK KT1TK 73
>
>
> -----Original Message-----
> From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Bill Barrett
> Sent: Friday, September 25, 2020 7:42 AM
> To: Support@hamapps.groups.io
> Subject: Re: [HamApps] Keyboard latency with multiple JTAlert processes running.
>
> Hello Laurie-
>
> I have noticed this for a long time. Never knew what caused it. Always assumed it was due to running multiple instances of WSJT-X.
> The reason Flex users notice it is because we have multiple slices and run multiple instances of WSJT-X.
> The keyboard delay is definitely related to using JTAlert. Without JTAlert the keyboard response if fast.
> In my case with the 6700 can run as many as 8 instances of "X" and JTAlert. Then the keyboard response seems stacked up.
> When pressing down on the left or right arrow key may take a second before there is a response on the screen and then the cursor moves several positions.
> Hard to tell where the interference is happening, however, seems like the keyboard interrupt handler is stalled.
> Hope this helps.
> Bill W2PKY
>
>
> On Thu, Sep 24, 2020 at 10:44 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
> >
> > On 23/09/2020 6:54 am, Patrick Skerrett wrote:
> >
> > Has anyone encountered this before?
> >
> > I am running version 2.16.13 of jtalert, 2.2.2 of WSJT-x and 15.8.0 of Dxkeeper.
> >
> > W9PDS
> >
> >
> > Has this always been a problem with your Flex and multi-instance JTAlert or is it a recent manifestation? If it is recent, what was the last version of JTAlert that didn't exhibit this behavior?
> >
> > de Laurie VK3AMA
> >
> >
> >
>
>
>
> --
> Bill Barrett
> 352-437-4758
>
>
>
>
>
>
>
>
>
>
>
>


--
Bill Barrett
352-437-4758






locked Re: Help For Greenhorn

John Singler
 
Edited

I don't remember having to restart JTAlert when I have changed that setting. At the bottom of the screen, just below Mike's scree shot above, there are 3 buttons. The right hand one is something like Save or Apply  (I'm on the wrong device now. No JTA for android). Hit that and then the left hand one.
John KA5BJC
On the laptop now and the buttons to hit are Save, then OK
John


locked Re: Keyboard latency with multiple JTAlert processes running.

Bill Barrett
 

Tom-
The PC CPU is only stressed during the decode period. Otherwise the
CPU is 93% idle.
WSJT-X and JTA take almost no CPU power during the sampling process.
The keyboard slow down is noticed anytime.
I'm sure Laurie will determine the cause and correct the problem now
that it's been uncovered.
Since most users do not run more than one instance of JTA and "X" they
do not notice the problem.
Bill W2PKY

On Sat, Sep 26, 2020 at 1:57 AM TomK <QSO@kt1tk.com> wrote:

From the FWIW (For What It's Worth) depart.
Sorry, if you know this, it have help others understand CPU loading issues.

WSJT and JTA present X-Large and Large processor task loads.
For JTA alone, think about the high message rate to display, lookup, resolve, flag, audio alert ... whoa!

As processes consume PC cycles, other processes are obviously given less time.
Moreover, a keyboard is an interrupt-driven task.
When you click a key, interrupts are thrown, the BIOS passes it to the OS.
It then passes control to an interrupt handler which passes control to registered s/w handlers.
The registered interrupt handlers do their things then finish (consuming more CPU cycles).
Only at a logically high level, are interrupts "asynchronous".
The reality is that multiple interrupts may asynchronously trig interrupt handlers.
However, once those handlers start to execute, the same CPU's cycles are consumed for all tasks.
At each CPU's level, you have synchronous code streams.
Multicore CPUs can ameliorate that but their allocations are seldom what an app would like.
While all that is happening, the CPU is still being interrupted 6 ways from Sunday.
So, with all that intense backdrop, you still have intense CPU tasks to execute.

So, a keyboard should and will slow down when the CPU is already heavily occupied and can't process all the interrupts.
Add 2, 3, or more JTA's and/or WSJT and it all gets that much worse.

The fact that NOT running any JTA instances makes your k/b faster seems entirely logical and expected.

I only suspect empirically, without seeing the code, that JTA doesn't do a lot of k/b interrupts itself.

In short, it's bloody amazing that a PC can handle the intense FFT's in WSJT as well as all that JTA does.

Just my 13 cents
TomK KT1TK 73


-----Original Message-----
From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Bill Barrett
Sent: Friday, September 25, 2020 7:42 AM
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Keyboard latency with multiple JTAlert processes running.

Hello Laurie-

I have noticed this for a long time. Never knew what caused it. Always assumed it was due to running multiple instances of WSJT-X.
The reason Flex users notice it is because we have multiple slices and run multiple instances of WSJT-X.
The keyboard delay is definitely related to using JTAlert. Without JTAlert the keyboard response if fast.
In my case with the 6700 can run as many as 8 instances of "X" and JTAlert. Then the keyboard response seems stacked up.
When pressing down on the left or right arrow key may take a second before there is a response on the screen and then the cursor moves several positions.
Hard to tell where the interference is happening, however, seems like the keyboard interrupt handler is stalled.
Hope this helps.
Bill W2PKY


On Thu, Sep 24, 2020 at 10:44 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@gmail.com> wrote:

On 23/09/2020 6:54 am, Patrick Skerrett wrote:

Has anyone encountered this before?

I am running version 2.16.13 of jtalert, 2.2.2 of WSJT-x and 15.8.0 of Dxkeeper.

W9PDS


Has this always been a problem with your Flex and multi-instance JTAlert or is it a recent manifestation? If it is recent, what was the last version of JTAlert that didn't exhibit this behavior?

de Laurie VK3AMA




--
Bill Barrett
352-437-4758











--
Bill Barrett
352-437-4758


locked Re: Keyboard latency with multiple JTAlert processes running.

m_scot_alex
 

This isn't a 'miracle of computing' issue; I can totally saturate the CPU, the GPU and the PCI bus(es) in all of my systems, including the system that I use WSJT-X/JT Alert most often, with 3D modelling or synthetic benchmarks and I don't see this behavior. This is very specific to JT Alert - I can shut down the WSJT-X instances and still have this problem as long as JT Alert is running. I suspect that this is ecosystem-specific, and not everyone experiences this issue, but it's real and it's not a CPU overload issue.

Laurie - I think this a keyboard event trapping race condition caused by 'hotkey' overlays in other programs. I'm travelling and this difficult to isolate remotely because of remote access latency, but I reduced the keyboard latency on my main JT-mode system by stopping an Intel video 'hotkey' utility. I'll provide more data next week and can send you a support request if you think it would help.

73,

Mike - N8MSA


locked Re: Any plans to add more RX squares ?

TomK
 

Not sure this is what you want but there is a way to filter out 1+ DXCC's.

Wait till you see any US station in the DECODES window.
Then Right-Click "United States" in the [Country Name] column.
The select "Hide DXCC Name = United States"
Then use the [Filter] menu to save this filter as something like "All but US"
Will that do it for you?

TomK KT1TK 73

-----Original Message-----
From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Bill Barrett
Sent: Friday, September 25, 2020 7:51 AM
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Any plans to add more RX squares ?

Since I'm only interested in DX I filter out NA and that reduces the displayed calls to a few even on 20M. I would like one added filter to exclude only USA calls since the caribbean is of interest to me.
Finally, would be nice if the filters were selectable for each instance of JTAlert.
Bill W2PKY

On Thu, Sep 24, 2020 at 8:48 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@gmail.com> wrote:

On 25/09/2020 10:15 am, ed.n5dg@gmail.com wrote:

36 RX squares is fine on most bands . 20m and 40m being the busy bands an extra 16 squares would be about right . instead of 4 x 9 squares 4 X 13 would make the width about the same as WSJTX.
Thanks for the great SW , Ed N5DG


Ed,

This has been discussed many time. See
https://hamapps.groups.io/g/Support/message/29940

IMHO, 36 displayed Callsigns is TOO many. It is a chaotic mess of multiple colored callsigns. A better option is to filter out most of the unwanted Callsigns. Use the Alert Filters to help reduce the number displayed. Try filtering out B4s and non-alerting callsigns.

A JTAlert window with few callsigns displayed due to filtering makes for a more enjoyable (IMO) experience in the shack. It is less stressful time without trying to decide every 15 seconds which Callsign could be a possible QSO candidate. It is a far less chaotic experience.

The beauty with filtering is that a Callsign that is displayed in JTAlert (has passed the filtering) is likely a good candidate for a QSO. But this approach wont appeal to those more interested in racking up a high QSO count, that is qso "quantity" rather than qso "quality".

Currently, there is code with the Test Team (not yet available for public release) that removes the limit on the number of displayed Callsigns. While this new code allows for more than 36 callsigns, its primary focus is providing a flexible display window without any size restriction (width or height) with flexible sizing comes the additional benefit of increased callsigns displayed. Sorry, there is no ETA on when this will be available publicly.

de Laurie VK3AMA



--
Bill Barrett
352-437-4758


locked Re: Keyboard latency with multiple JTAlert processes running.

TomK
 

From the FWIW (For What It's Worth) depart.
Sorry, if you know this, it have help others understand CPU loading issues.

WSJT and JTA present X-Large and Large processor task loads.
For JTA alone, think about the high message rate to display, lookup, resolve, flag, audio alert ... whoa!

As processes consume PC cycles, other processes are obviously given less time.
Moreover, a keyboard is an interrupt-driven task.
When you click a key, interrupts are thrown, the BIOS passes it to the OS.
It then passes control to an interrupt handler which passes control to registered s/w handlers.
The registered interrupt handlers do their things then finish (consuming more CPU cycles).
Only at a logically high level, are interrupts "asynchronous".
The reality is that multiple interrupts may asynchronously trig interrupt handlers.
However, once those handlers start to execute, the same CPU's cycles are consumed for all tasks.
At each CPU's level, you have synchronous code streams.
Multicore CPUs can ameliorate that but their allocations are seldom what an app would like.
While all that is happening, the CPU is still being interrupted 6 ways from Sunday.
So, with all that intense backdrop, you still have intense CPU tasks to execute.

So, a keyboard should and will slow down when the CPU is already heavily occupied and can't process all the interrupts.
Add 2, 3, or more JTA's and/or WSJT and it all gets that much worse.

The fact that NOT running any JTA instances makes your k/b faster seems entirely logical and expected.

I only suspect empirically, without seeing the code, that JTA doesn't do a lot of k/b interrupts itself.

In short, it's bloody amazing that a PC can handle the intense FFT's in WSJT as well as all that JTA does.

Just my 13 cents
TomK KT1TK 73

-----Original Message-----
From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Bill Barrett
Sent: Friday, September 25, 2020 7:42 AM
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Keyboard latency with multiple JTAlert processes running.

Hello Laurie-

I have noticed this for a long time. Never knew what caused it. Always assumed it was due to running multiple instances of WSJT-X.
The reason Flex users notice it is because we have multiple slices and run multiple instances of WSJT-X.
The keyboard delay is definitely related to using JTAlert. Without JTAlert the keyboard response if fast.
In my case with the 6700 can run as many as 8 instances of "X" and JTAlert. Then the keyboard response seems stacked up.
When pressing down on the left or right arrow key may take a second before there is a response on the screen and then the cursor moves several positions.
Hard to tell where the interference is happening, however, seems like the keyboard interrupt handler is stalled.
Hope this helps.
Bill W2PKY


On Thu, Sep 24, 2020 at 10:44 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@gmail.com> wrote:

On 23/09/2020 6:54 am, Patrick Skerrett wrote:

Has anyone encountered this before?

I am running version 2.16.13 of jtalert, 2.2.2 of WSJT-x and 15.8.0 of Dxkeeper.

W9PDS


Has this always been a problem with your Flex and multi-instance JTAlert or is it a recent manifestation? If it is recent, what was the last version of JTAlert that didn't exhibit this behavior?

de Laurie VK3AMA




--
Bill Barrett
352-437-4758


locked Re: Help For Greenhorn

Cliff Fox (KU4GW)
 

Thank you so much Mike! That fixed it, but I did have to exit JT Alert and restart it so it could read the new settings first, but no more popping up! I sure do appreciate your help! I just joined this group earlier today and it has already been helpful to me.

Very 73,
Cliff, KU4GW


locked Re: Help For Greenhorn

Michael Black
 

Check the options for bringing the window to front.

Mike W9MDB
Inline image





On Friday, September 25, 2020, 12:59:36 PM CDT, Cliff Fox (KU4GW) <cliffku4gw@...> wrote:


What setting in either JT Alert or WSJT-X will make the docked together WSJT-X & WSJT-X-JTAlertX windows from automatically popping up on my PC about once every minute? It drives ne nuts when I'm trying to do anything else on my computer. I'm brand new at this, just got FT8 using WSJT-X v2.2.2 and WSJT-X-JTAlertX v2/16.13 running 2 days ago. You can reply off list if you like by emailing me at my call at arrl.net. Thanks in advance for your help!

Very 73,
Cliff, KU4GW


locked Help For Greenhorn

Cliff Fox (KU4GW)
 

What setting in either JT Alert or WSJT-X will make the docked together WSJT-X & WSJT-X-JTAlertX windows from automatically popping up on my PC about once every minute? It drives ne nuts when I'm trying to do anything else on my computer. I'm brand new at this, just got FT8 using WSJT-X v2.2.2 and WSJT-X-JTAlertX v2/16.13 running 2 days ago. You can reply off list if you like by emailing me at my call at arrl.net. Thanks in advance for your help!

Very 73,
Cliff, KU4GW

4801 - 4820 of 36363