Date   

locked Re: Feature request: Current JTAlert mechanics vs. WAZ award

Björn SM7IUN
 

Laurie,

I would be both delighted and honored to assist you in verifying an updated version of JTAlert including such functionality.

73,

Björn



2018-07-06 3:47 GMT+02:00 HamApps Support (VK3AMA) <vk3ama.ham.apps@...>:

On 5/07/2018 10:16 PM, Björn Ekelund wrote:
I thought I had posted this before but it seems I accidentally sent it to the wrong email address...

I have a feature request that may or may not be realistic - to better align the CQ Zone alert with the WAZ rules.

I have been confused over the fact that DXLab Spotcollector considers stations "needed" for WAZ when JTAlert does not.

I found the reason to be that the WAZ rules does not regard RTTY a digital mode. There is a separate WAZ award for RTTY.  

Today JTAlert offers four alternatives for CQ Zone alerts: "Any Mode", "By Individual JT Mode", "Any Digital Mode", and "Any WSJT-X Mode".

I have a lot of RTTY and PSK QSO in my log and this becomes a problem when pursuing a digital WAZ. 

If I chose "Any Digital Mode" this includes my RTTY QSO which is wrong.

If I chose "Any WSJT-X Mode" this excludes my PSK QSO which is also wrong. 

Would it be possible to add a fifth option "Any Digital Mode except RTTY"?
Or simply not have RTTY count as a digital mode for CQ Zone alerts?

I of course realize the inconsistency with e.g. DXCC. 

73,

Björn SM7IUN
Björn,

I don't recall any previous message regarding this.

JTAlert Wanted Alerts are designed to be generic in nature, not aligned with the specific requirements of any of the many Awards available. The Wanted Zone alert is not meant to be a WAZ award alert.

RTTY is a digital mode and is why it is included in the "Any Digital Mode" tracking. To exclude it by creating a new "Any Digital Mode except RTTY" tracking definition would be a significant exercise, as it would involve the creation of a whole new set of lists, one for each Band and any Band. This adds to the size of the JTAlert configuration as well as the memory overhead and increased Scan Log processing time (~20% increase).

The better option would be the provision of a single checkbox that instructs the Log Scan to exclude RTTY from the sql instruction for  the "Any Digital Mode" tracking scan effectively making the "Any Digital Mode" list a "Any Digital Mode expect RTTY" list.

Since you raised the issue, you have volunteered to test JTAlert when I implement the change (it is unknown when that will happen however). Is that OK?

de Laurie VK3AMA

de Laurie VK3AMA



locked Re: Wanted Callsigns and B4 (a friends and family list so to speak)

Michael Black
 

Hmmm...it works for me.  Just had one today.  He's worked on 20M but still alerted since I have his callsign in the Wanted Call list.  You sure you have the audio alert working?

de Mike W9MDB




On Thursday, July 5, 2018, 10:27:49 PM CDT, Matt Thomas W5MT <w5mt@...> wrote:


My apologies if this subject has been covered before; a quick search did not find anything similar.  If it has, just point me in the right direction please.

I'm using JTAlertX.  I put the callsigns of my buddies in Wanted Callsigns so that they will be highlighted if the callsigns are decoded.  However, as you probably can figure out, once they are highlighted as a Wanted Callsign, those callsigns then go into the B4 bucket and will not be highlighted again (except as one of many B4s of course).

Is there a better way that I'm just not seeing to keep a list of callsigns that will always alert when decoded?

TU es 73 de Matt W5MT


locked Wanted Callsigns and B4 (a friends and family list so to speak)

Matt Thomas W5MT
 

My apologies if this subject has been covered before; a quick search did not find anything similar.  If it has, just point me in the right direction please.

I'm using JTAlertX.  I put the callsigns of my buddies in Wanted Callsigns so that they will be highlighted if the callsigns are decoded.  However, as you probably can figure out, once they are highlighted as a Wanted Callsign, those callsigns then go into the B4 bucket and will not be highlighted again (except as one of many B4s of course).

Is there a better way that I'm just not seeing to keep a list of callsigns that will always alert when decoded?

TU es 73 de Matt W5MT


locked Re: Feature request: Current JTAlert mechanics vs. WAZ award

Joe Subich, W4TV
 

I know it's a bit of a pain but in DXCC, WAS and WPX "Digital" would
include RTTY while in WAZ "Digital" would not include RTTY.

73,

... Joe, W4TV

On 2018-07-05 9:57 PM, HamApps Support (VK3AMA) wrote:
On 5/07/2018 10:59 PM, Joe Subich, W4TV wrote:
The technically correct solution would be to eliminate RTTY QSOs from
"Any Digital Mode" in zone alerts.  They should be included in "Any
mode" just like phone, cw and SSTV.

73,

   ... Joe, W4TV
Joe,
Your correct, see my other response re: a checkbox to exclude RTTY from the "Any Digital Mode" scan.
RTTY is already included on the "Any Mode" scan. In fact, when performing an "Any Mode" scan, the mode is never used in the sql query run against the log, so any future, as yet undefined Modes, are also included.
de Laurie VK3AMA


locked Re: Bug or wrong setting?

HamApps Support (VK3AMA)
 

On 6/07/2018 11:48 AM, Steve Larson wrote:
Interesting happening - and only once (so far), but not sure if it's a bug, or a setting:

Worked K7OP before in FN67.  Confirmed LoTW, etc, etc.
He was on last week calling CQ from FN56 but his callsign did not even show in JTAlert.  When I realized I needed FN56, I clicked on his call to work him, and JTAlert came up with a red "K7OP - B4".  I know JTAlert is supposed to handle rovers and such, so I'm presuming this was either a fluke or something I have set wrong.  Just an observation.

BTW, he confirmed FN56 via LoTW as well.

Steve, N3SL
Steve,

The Worked B4 checks do not consider the Grid of previous QSOs. It is on the todo list, but implementation is not imminent.

Currently, the only way to get correct non-B4 alerting of changed Grids for the same Callsign is to enable the Grid Chase option. I strongly suggest you don't do that unless your actively participating in the Chase and are willing to get alerted on previously worked grids as needed Grids every month (per the Grid Chase event rules).

de Laurie VK3AMA


locked Re: Feature request: Current JTAlert mechanics vs. WAZ award

HamApps Support (VK3AMA)
 

On 5/07/2018 10:59 PM, Joe Subich, W4TV wrote:
The technically correct solution would be to eliminate RTTY QSOs from
"Any Digital Mode" in zone alerts.  They should be included in "Any
mode" just like phone, cw and SSTV.

73,

   ... Joe, W4TV
Joe,

Your correct, see my other response re: a checkbox to exclude RTTY from the "Any Digital Mode" scan.

RTTY is already included on the "Any Mode" scan. In fact, when performing an "Any Mode" scan, the mode is never used in the sql query run against the log, so any future, as yet undefined Modes, are also included.

de Laurie VK3AMA


locked Bug or wrong setting?

Steve, N3SL
 

Interesting happening - and only once (so far), but not sure if it's a bug, or a setting:

Worked K7OP before in FN67.  Confirmed LoTW, etc, etc.
He was on last week calling CQ from FN56 but his callsign did not even show in JTAlert.  When I realized I needed FN56, I clicked on his call to work him, and JTAlert came up with a red "K7OP - B4".  I know JTAlert is supposed to handle rovers and such, so I'm presuming this was either a fluke or something I have set wrong.  Just an observation.

BTW, he confirmed FN56 via LoTW as well.

Steve, N3SL


locked Re: Feature request: Current JTAlert mechanics vs. WAZ award

HamApps Support (VK3AMA)
 

On 5/07/2018 10:16 PM, Björn Ekelund wrote:
I thought I had posted this before but it seems I accidentally sent it to the wrong email address...

I have a feature request that may or may not be realistic - to better align the CQ Zone alert with the WAZ rules.

I have been confused over the fact that DXLab Spotcollector considers stations "needed" for WAZ when JTAlert does not.

I found the reason to be that the WAZ rules does not regard RTTY a digital mode. There is a separate WAZ award for RTTY.  

Today JTAlert offers four alternatives for CQ Zone alerts: "Any Mode", "By Individual JT Mode", "Any Digital Mode", and "Any WSJT-X Mode".

I have a lot of RTTY and PSK QSO in my log and this becomes a problem when pursuing a digital WAZ. 

If I chose "Any Digital Mode" this includes my RTTY QSO which is wrong.

If I chose "Any WSJT-X Mode" this excludes my PSK QSO which is also wrong. 

Would it be possible to add a fifth option "Any Digital Mode except RTTY"?
Or simply not have RTTY count as a digital mode for CQ Zone alerts?

I of course realize the inconsistency with e.g. DXCC. 

73,

Björn SM7IUN
Björn,

I don't recall any previous message regarding this.

JTAlert Wanted Alerts are designed to be generic in nature, not aligned with the specific requirements of any of the many Awards available. The Wanted Zone alert is not meant to be a WAZ award alert.

RTTY is a digital mode and is why it is included in the "Any Digital Mode" tracking. To exclude it by creating a new "Any Digital Mode except RTTY" tracking definition would be a significant exercise, as it would involve the creation of a whole new set of lists, one for each Band and any Band. This adds to the size of the JTAlert configuration as well as the memory overhead and increased Scan Log processing time (~20% increase).

The better option would be the provision of a single checkbox that instructs the Log Scan to exclude RTTY from the sql instruction for  the "Any Digital Mode" tracking scan effectively making the "Any Digital Mode" list a "Any Digital Mode expect RTTY" list.

Since you raised the issue, you have volunteered to test JTAlert when I implement the change (it is unknown when that will happen however). Is that OK?

de Laurie VK3AMA

de Laurie VK3AMA


locked Re: DXKeeper distance no longer working

HamApps Support (VK3AMA)
 

On 5/07/2018 8:49 PM, Dave K8HW wrote:
Laurie,

This happened on all QSO's since I upgraded. I fixed each log by going into propagation area in DXKeeper and changing the Antenna from short path, which was already indicated, to long path and then back to short path. That's when the distance showed up. Any logging to DXKeeper from it's capture window worked just fine. That's when I went to JTAlertX version 2.11.5 and everything works just fine now.

By the way, I was the guy that was having trouble with the decodes history window. That problem just seemed to go away after several upgrades to JTAlertX. I am wondering how much of this is caused by Windows 10, which is the biggest piece of you know what I have ever dealt with! Sorry for the vent, but I am thoroughly frustrated with Windows.

73 - K8HW - Dave
Dave,

Sorry, I don't have an explanation. I cant reproduce here. I would need to see your session files (after first enabling Debug recording) for when this is happening.

Since you have downgraded JTAlert, I suggest doing nothing until the next JTAlert release and you try that version. If you experience the same behaviour with a new release you would need to do the following...
  • Enable debug recording via the "Settings -> Enable Debug Recording" JTAlert title-bar menu.
  • Restart JTAlert, that is close JTAlert and then start JTAlert.
  • Operate as normal.
  • Once a DXKeeper distance logging failure occurs send the support request.
  • Leave the "Enable Debug Recording" menu enabled.
  • Once a solution is found for your problem you can turn off debugging.

de Laurie VK3AMA


locked Re: Help with font scaling issue

 

Genius!

Laurie, VK3AMA, you corrected my issue.  Very good.  It is working well, now.  THANK YOU.

Tomas


locked Re: Help with font scaling issue

HamApps Support (VK3AMA)
 

On 6/07/2018 5:59 AM, Tomas, NW7US wrote:
Greetings.
 
Has anyone here experienced this problem, and found a solution?
 
On my Windows 10 Pro computer, I have two Acer CB281HK-4 LED 4k UHD FreeSync Monitors driven by an NVidia GeForce GTX 1070, set to 3840 x 2160 resolution, 59 Hz resolution, 8-bit depth, at 150% scaling. All of my other programs output fonts at the appropriate resolution. However, JTAlert does NOT scale correctly, as demonstrated in the screen capture.
 
Two screen capture images (the second one is just a collection of screen grabs.):
 
2018-07-05_13-44-44_FontsTooSmall.jpg
Thank you,
 
Tomas David Hood - NW7US
Thomas,

The fix is simple. Open the JTAlert Settings, "Window" section, and turn off the "Auto adjust font to reduce cropping of Callsign text" checkbox (see under the "Decoded Callsigns Display" area).

JTAlert overrides the automatic font scaling done by Windows itself for the Callsigns only (why? its a long and complicated story).

The problem your experiencing is due to code JTAlert uses (standard Windows api calls) to determine the level of scaling and the dpi of the users screen. For some as yet undermined reason, the api calls are retuning inaccurate values for users running 4K monitors (as I do).

de Laurie VK3AMA
 


locked Help with font scaling issue

 

Greetings.
 
Has anyone here experienced this problem, and found a solution?
 
On my Windows 10 Pro computer, I have two Acer CB281HK-4 LED 4k UHD FreeSync Monitors driven by an NVidia GeForce GTX 1070, set to 3840 x 2160 resolution, 59 Hz resolution, 8-bit depth, at 150% scaling. All of my other programs output fonts at the appropriate resolution. However, JTAlert does NOT scale correctly, as demonstrated in the screen capture.
 
Two screen capture images (the second one is just a collection of screen grabs.):
 
2018-07-05_13-44-44_FontsTooSmall.jpg
Thank you,
 
Tomas David Hood - NW7US
http://me.nw7us.us
 


locked Re: Spotting Mode Error

HamApps Support (VK3AMA)
 

On 6/07/2018 12:49 AM, w7psk wrote:
just noticed on Ham Spots my station reporting a 12m conact as CW, Im on FT8. Im on VFO A
on my 7300

11m AA5AT 12 CW 00

Scotty W7PSK
Scotty,

Your not spotting the wrong mode.
You made a Cluster spot without any indication in the notes as to the mode, "
CN87VW<>EM40". HamSpots has to make a guess as to the true mode based on the frequency reported. If you had include FT8 in the spot notes than the mode would have been correctly identified. eg "FT8 CN87VW<>EM40"

If you had gone to your myspots page on HamSpots, the extended display includes a Spot Source column, "S" (hover your mouse to see the different source abbreviations). In that column for that spot was a "C", short for Cluster.
 
To avoid inaccurate mode from frequency determination, simply include the mode in your spot notes, or don't bother making an FT8 Cluster spot.

de Laurie VK3AMA


locked Spotting Mode Error

Rick W7PSK
 

just noticed on Ham Spots my station reporting a 12m conact as CW, Im on FT8. Im on VFO A
on my 7300

11m AA5AT 12 CW 00

Scotty W7PSK


locked Wish List - Top Alert Log

Charles Jessee
 

It might be nice to have a log for Top Alert. I’m working13 Colonies over the July 4th week in the US and there are 13 states operating K2A-K2M on all bands/modes. I have the callsigns working fine as Callsign Alert in top priority. If I walk away it might be helpful to check the log to see if they were on the band/mode (FT8).

Bret/N4SRN


locked Re: Feature request: Current JTAlert mechanics vs. WAZ award

Joe Subich, W4TV
 

Would it be possible to add a fifth option "Any Digital Mode except
RTTY"? Or simply not have RTTY count as a digital mode for CQ Zone
alerts?
The technically correct solution would be to eliminate RTTY QSOs from
"Any Digital Mode" in zone alerts. They should be included in "Any
mode" just like phone, cw and SSTV.

73,

... Joe, W4TV


On 2018-07-05 8:16 AM, Björn Ekelund wrote:
I thought I had posted this before but it seems I accidentally sent it to
the wrong email address...
I have a feature request that may or may not be realistic - to better align
the CQ Zone alert with the WAZ rules.
I have been confused over the fact that DXLab Spotcollector considers
stations "needed" for WAZ when JTAlert does not.
I found the reason to be that the WAZ rules does not regard RTTY a digital
mode. There is a separate WAZ award for RTTY.
Today JTAlert offers four alternatives for CQ Zone alerts: "Any Mode", "By
Individual JT Mode", "Any Digital Mode", and "Any WSJT-X Mode".
I have a lot of RTTY and PSK QSO in my log and this becomes a problem when
pursuing a digital WAZ.
If I chose "Any Digital Mode" this includes my RTTY QSO which is wrong.
If I chose "Any WSJT-X Mode" this excludes my PSK QSO which is also wrong.
Would it be possible to add a fifth option "Any Digital Mode except RTTY"?
Or simply not have RTTY count as a digital mode for CQ Zone alerts?
I of course realize the inconsistency with e.g. DXCC.
73,
Björn SM7IUN


locked Feature request: Current JTAlert mechanics vs. WAZ award

Björn SM7IUN
 

I thought I had posted this before but it seems I accidentally sent it to the wrong email address...

I have a feature request that may or may not be realistic - to better align the CQ Zone alert with the WAZ rules.

I have been confused over the fact that DXLab Spotcollector considers stations "needed" for WAZ when JTAlert does not.

I found the reason to be that the WAZ rules does not regard RTTY a digital mode. There is a separate WAZ award for RTTY.  

Today JTAlert offers four alternatives for CQ Zone alerts: "Any Mode", "By Individual JT Mode", "Any Digital Mode", and "Any WSJT-X Mode".

I have a lot of RTTY and PSK QSO in my log and this becomes a problem when pursuing a digital WAZ. 

If I chose "Any Digital Mode" this includes my RTTY QSO which is wrong.

If I chose "Any WSJT-X Mode" this excludes my PSK QSO which is also wrong. 

Would it be possible to add a fifth option "Any Digital Mode except RTTY"?
Or simply not have RTTY count as a digital mode for CQ Zone alerts?

I of course realize the inconsistency with e.g. DXCC. 

73,

Björn SM7IUN


locked Re: DXKeeper distance no longer working

Dave K8HW <k8hwdave@...>
 
Edited

Laurie,

This happened on all QSO's since I upgraded. I fixed each log by going into propagation area in DXKeeper and changing the Antenna from short path, which was already indicated, to long path and then back to short path. That's when the distance showed up. Any logging to DXKeeper from it's capture window worked just fine. That's when I went to JTAlertX version 2.11.5 and everything works just fine now.

By the way, I was the guy that was having trouble with the decodes history window. That problem just seemed to go away after several upgrades to JTAlertX. I am wondering how much of this is caused by Windows 10, which is the biggest piece of you know what I have ever dealt with! Sorry for the vent, but I am thoroughly frustrated with Windows.

73 - K8HW - Dave


locked Re: Can you disable Unique Callsign popup?

HamApps Support (VK3AMA)
 

On 5/07/2018 5:04 AM, Don Hill AA5AU wrote:
Seems to get in the way and sometimes gets stuck in the up position and you
have to mouse over it again to get it to drop down again.

Thanks,
Don AA5AU
All the options for the Band Activity Display are available in the Settings, "Window -> Band Activity Window" section.

de Laurie VK3AMA


locked Re: Text Message window reciept

HamApps Support (VK3AMA)
 

On 5/07/2018 1:55 AM, w7psk wrote:
Maybe Im just old and blind
But I cannot find where to enable this.  Id like to see if someone
is on or not .. great idea, just not intuitive for this old guy

Scotty W7PSK
Its enabled by default. There is no setting.
If the Callsign in the Test Message window changes, JTAlert automatically sends a request to the HamSpots sever to see if they are online. That online check looks for a flag that is created/updated when that target Callsign does its own waiting message check.

The "Online" message indicates that they have communicated with the HamSpots server within the last 5 minutes.

The is no "Not Online" indicator as that may not be entirely correct.

de Laurie VK3AMA

16801 - 16820 of 37660