Date   

locked Colored box around call

Doug Munday
 

Somehow I changed a setting and have a colored border around calls, but I have no idea what that means and can not find the setting again.  What does the colored border mean, vs. the solid colored background?  I do know what the solid colored backgrounds mean. 

Also, have to ask - where can I find the user's manual for JT-Alert?

Thanks,
Doug - W7DRM


locked Re: WSJT-X Alt-Double-Click on CQ Calls

John H. Long Jr.
 

Sorry, I missed it.

What does (will) Alt double click on CQ do?



John H. Long Jr.
KW7A

Regarding New Feature - Support for WSJT-X Alt-Double-Click on CQ, requires WSJT-X builds only (r8108 or later),  I am running the latest Windows release WSJT-X v1.8.0-rc2 r8069. Since I am not savvy at programming will I need to wait for the next full Win release to enjoy the feature you've added to JT AlertX ?   I'll be fine with that, just want to make sure I'm not overlooking another route to upgrade WSJT-X.

Tnx for all you do, Laurie!
73, Terry - N4IYB


locked WSJT-X Alt-Double-Click on CQ Calls

Terry Scaia
 

Regarding New Feature - Support for WSJT-X Alt-Double-Click on CQ, requires WSJT-X builds only (r8108 or later),  I am running the latest Windows release WSJT-X v1.8.0-rc2 r8069. Since I am not savvy at programming will I need to wait for the next full Win release to enjoy the feature you've added to JT AlertX ?   I'll be fine with that, just want to make sure I'm not overlooking another route to upgrade WSJT-X.

Tnx for all you do, Laurie!
73, Terry - N4IYB


locked No more B4 in History window

pa1ns@...
 

Hello Laurie,

I am missing the B4 marks in the History window.
In the Settings - Window - Decodes History  ,the  [v] Show Callsign with B4 is marked.
It seems that the History window is following the B4 filter in the Main window.

I tried to select it On and Off in the History setting, also with restarting the program but no luck.
I personal don't want the B4 callsigns in the main window but I liked them recognizable in the History window as it was in the previous versions.

Is this done deliberately or overlooked?

B.T.W.  Thanks for all your work!

73,  Nico PA1NS


locked Re: JTalert not logging to DXkeeper

Randy
 

OK thank you very much for the reply which led me in the right direction.   Operator error it seems; I need to enable 'prompt to log qso' in KSJT-X otherwise nothing is logged.   All is good now.


---
~Randy


On 10/06/2017 6:50 pm, HamApps Support (VK3AMA) wrote:

On 7/10/2017 12:18 PM, amps@... wrote:
I see this issue has already been posted, but my situation seems unique.   I'm using JTalert 2.10.2 (just upgraded from 2.10.1) along with WSJT-X 1.8 RC2 and DXkeeper 14.2.2.

JTalert 'sees' DXkeeper -- test passes and also shows up in the DXkeeper server log.   I can use the context menu in JTkeeper to do callsign lookups in DXkeeper.   So the TCP/IP connection between the two is working.

The DXkeeper DB setting is same on both sides.   Logging checkbox is enabled.

Nothing is being ran under administrator.

The issue: JTalert is not logging any QSO's.   In fact, I think it might not even be detecting them since I don't get any error message that the logging failed.   It's just that nothing happens after the QSO -- no alert, nothing in the DXkeeper server log after the QSO.   During the QSO the calls are shown as RED so it's seeing them.

Any clues are welcome.

OM,

If you not getting a Success or Failure message from JTAlert after logging suggests that you are not performing the logging action in WSJT-X or you have the Log QSO popups disabled in JTAlert. Under the JTAlert Settings, Window -> Popup Windows section, enable both the Success and Failure options so there is some feedback as to what is occurring while your testing the failed logging.

Are you using the OK button on the WSJT-X Log QSO window. WSJT-X is not an automated QSO machine (unlike one of its clones), it requires the operator to action the logging operation.

Let me know how you get on.
If you still have problems, use the "? -> Contact Support" menu, on the JTAlert title-bar, to send me your Configuration and Session files for analysis. Include a note of the Callsign and utc time when the logging failed.
   
de Laurie VK3AMA
   


locked Re: JTalert not logging to DXkeeper

HamApps Support (VK3AMA)
 

On 7/10/2017 12:18 PM, amps@... wrote:
I see this issue has already been posted, but my situation seems unique.   I'm using JTalert 2.10.2 (just upgraded from 2.10.1) along with WSJT-X 1.8 RC2 and DXkeeper 14.2.2.

JTalert 'sees' DXkeeper -- test passes and also shows up in the DXkeeper server log.   I can use the context menu in JTkeeper to do callsign lookups in DXkeeper.   So the TCP/IP connection between the two is working.

The DXkeeper DB setting is same on both sides.   Logging checkbox is enabled.

Nothing is being ran under administrator.

The issue: JTalert is not logging any QSO's.   In fact, I think it might not even be detecting them since I don't get any error message that the logging failed.   It's just that nothing happens after the QSO -- no alert, nothing in the DXkeeper server log after the QSO.   During the QSO the calls are shown as RED so it's seeing them.

Any clues are welcome.

OM,

If you not getting a Success or Failure message from JTAlert after logging suggests that you are not performing the logging action in WSJT-X or you have the Log QSO popups disabled in JTAlert. Under the JTAlert Settings, Window -> Popup Windows section, enable both the Success and Failure options so there is some feedback as to what is occurring while your testing the failed logging.

Are you using the OK button on the WSJT-X Log QSO window. WSJT-X is not an automated QSO machine (unlike one of its clones), it requires the operator to action the logging operation.

Let me know how you get on.
If you still have problems, use the "? -> Contact Support" menu, on the JTAlert title-bar, to send me your Configuration and Session files for analysis. Include a note of the Callsign and utc time when the logging failed.
   
de Laurie VK3AMA
   


locked Re: JTalert not logging to DXkeeper

Randy
 

Can’t say what your problem is, but I also upgraded JTAlert (and associated stuff) today and the DXKeeper interface is logging just fine for me. I didn’t do anything but run the setup apps.

73,
Randy, KS4L 

On Oct 6, 2017, at 8:18 PM, amps@... wrote:

I see this issue has already been posted, but my situation seems unique.   I'm using JTalert 2.10.2 (just upgraded from 2.10.1) along with WSJT-X 1.8 RC2 and DXkeeper 14.2.2.

JTalert 'sees' DXkeeper -- test passes and also shows up in the DXkeeper server log.   I can use the context menu in JTkeeper to do callsign lookups in DXkeeper.   So the TCP/IP connection between the two is working.

The DXkeeper DB setting is same on both sides.   Logging checkbox is enabled.

Nothing is being ran under administrator.

The issue: JTalert is not logging any QSO's.   In fact, I think it might not even be detecting them since I don't get any error message that the logging failed.   It's just that nothing happens after the QSO -- no alert, nothing in the DXkeeper server log after the QSO.   During the QSO the calls are shown as RED so it's seeing them.

Any clues are welcome.


locked Re: JTAlertX 2.10.2

HamApps Support (VK3AMA)
 

On 7/10/2017 10:13 AM, Kevin Utzy wrote:
I just wanted to say in my particular situation I have found that v. 2.10.2 performed very well today for 4 hours straight.  The decodes seem to be faster and the issue I was having with the DX entity not matching the callsign has been resolved.  So I wanted to give you a positive report from my point of view.  Thank you!

73,
Kevin
Thanks Kevin.

Be sure to let me know if the incorrect Country Name problem reappears.

de Laurie VK3AMA
   


locked New JTAlert 2.10.3 Available - Fixes : #Announcement #NewRelease

HamApps Support (VK3AMA)
 

New JTAlert 2.10.3 is available for download.

*** Please review the Release Notes ***

Visit HamApps.com for the download link and upgrade instructions.

Release Notes for 2.10.3
  New Features:
    - Works with new 5.0 version of JT65-HF HB9HQX Edition.
       (Important Note: Only JT65-Log, the default, is supported)

  Fixes:
    - Truncated "Name" ($) Macros substitution. (2.10.2 defect)
    - HRD6 logging multiline address truncated. (now using undocumented API format)

de Laurie VK3AMA
   
 




locked JTalert not logging to DXkeeper

Randy
 

I see this issue has already been posted, but my situation seems unique.   I'm using JTalert 2.10.2 (just upgraded from 2.10.1) along with WSJT-X 1.8 RC2 and DXkeeper 14.2.2.

JTalert 'sees' DXkeeper -- test passes and also shows up in the DXkeeper server log.   I can use the context menu in JTkeeper to do callsign lookups in DXkeeper.   So the TCP/IP connection between the two is working.

The DXkeeper DB setting is same on both sides.   Logging checkbox is enabled.

Nothing is being ran under administrator.

The issue: JTalert is not logging any QSO's.   In fact, I think it might not even be detecting them since I don't get any error message that the logging failed.   It's just that nothing happens after the QSO -- no alert, nothing in the DXkeeper server log after the QSO.   During the QSO the calls are shown as RED so it's seeing them.

Any clues are welcome.


locked JTAlertX 2.10.2

Kevin Utzy
 

I just wanted to say in my particular situation I have found that v. 2.10.2 performed very well today for 4 hours straight.  The decodes seem to be faster and the issue I was having with the DX entity not matching the callsign has been resolved.  So I wanted to give you a positive report from my point of view.  Thank you!

73,
Kevin
KX4KU


locked Re: Problem with macros - Defect Confirmed

Dwaine Pipe
 

Thanks Laurie J

 

Wow!  Super fast service J

 

Cheers

David

VK7YUM

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: Saturday, 7 October 2017 9:57 AM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Problem with macros - Defect Confirmed

 

On 7/10/2017 9:49 AM, Dwaine Pipe wrote:

Hi Laurie

Noticed since the update my macros are playing up .....  please see attached picture ..



Its pulling the name/QTH info from hamQTH.com but it is only passing the 1st character.  Has anyone else noticed this or is my system needing a kick in the pants :)

Cheers
David
VK7YUM


David,

This defect is confirmed.
A fix has already been coded. I will wait a day to see if any other anomalies surface before posting a new release.

de Laurie VK3AMA
   


locked Re: Problem with macros - Defect Confirmed

HamApps Support (VK3AMA)
 

On 7/10/2017 9:49 AM, Dwaine Pipe wrote:
Hi Laurie

Noticed since the update my macros are playing up .....  please see attached picture ..



Its pulling the name/QTH info from hamQTH.com but it is only passing the 1st character.  Has anyone else noticed this or is my system needing a kick in the pants :)

Cheers
David
VK7YUM

David,

This defect is confirmed.
A fix has already been coded. I will wait a day to see if any other anomalies surface before posting a new release.

de Laurie VK3AMA
   


locked Re: 2 title bars

HamApps Support (VK3AMA)
 

On 5/10/2017 8:42 PM, Simon de Tute wrote:
Hi Laurie

Running Windows 10 and when program started up no prob then after logging a few qso it would double up.

Since the latest version i have not noticed it if it happens i will see if anything else has changed


73

Simon,

Thanks for the feedback.

Logging QSOs should not cause the problem.

The double-up of the title-bar is related to the Windows DWM process (Desktop Windows Manager).
JTAlert manages painting of the titlebar text, menus and band activity. There is different code depending on whether DWM is being used to manage Windows display and how it is being used. For Win10, DWM is always active (unlike Win7 where it is not when running a non-aero theme and XP where it doesn't exist) but changes in how it is managing the Windows presentation (font scaling, resolution, border sizes, colors, etc) can influence JTAlert.

While JTAlert is at fault, something is changing in Windows that JTAlert is not detecting. Rather than focusing on what JTAlert is doing when the problem occurs, look at what Windows is doing, or another application, try to determine a pattern of behaviour, as that will be the clue to hopefully reproducing the effect and ultimately coding a fix.

de Laurie VK3AMA
   


locked Re: States, LoTW and eQSL stripes not displaying.

Justin EI3CTB
 

Hi Laurie,

Perfect :-) Thanks for the fast reply. I reinstalled the Callsign database and everything is back up and running again.

I really appreciate your great support and excellent software.

73

Justin
EI3CTB


locked Problem with macros

Dwaine Pipe
 

Hi Laurie

Noticed since the update my macros are playing up .....  please see attached picture ..



Its pulling the name/QTH info from hamQTH.com but it is only passing the 1st character.  Has anyone else noticed this or is my system needing a kick in the pants :)

Cheers
David
VK7YUM


locked Re: HRD logging...just making sure.

Chris VK2BYI
 

No problem, just thought you should know.

The difficulty for HRD was at the CLI application layer, not the transport.

I have asked for the API changes to be documented.  I will chase that up with HRD.

I would like to think that QSO Relay brings benefits regardless. :)

73 Chris
VK2BYI


locked Re: HRD logging...just making sure.

HamApps Support (VK3AMA)
 

On 7/10/2017 8:42 AM, Chris VK2BYI wrote:
Laurie, I sent you an email re embedded newlines in the Address field being logged via the Logbook API.  It has information regarding how to handle embedded newlines with HRD 6.4.0.787.

I sent it to your Gmail account.  Let me know if you received it or not, and if I should send it to another account.

73 Chris
VK2BYI
Chris,

I have a backlog of unread emails I need to go through. This forum tends to take precedence.

I found your email.

So, the HRD API has changed but not documented.

2.10.2 still uses CRLFs in a multi-line address so that is still broken for HRD.

I don't understand why HRD has to be the odd-man-out, all the other Loggers support multi-line address data in their logging APIs without the need to make data substitutions. A TCP data packet doesn't care about the type of data it is conveying. Its not rocket science.

Perhaps I'll drop HRD logging permanently and leave it to QSORelay.

Sorry for the Rant.
de Laurie VK3AMA
   


locked Re: States, LoTW and eQSL stripes not displaying.

HamApps Support (VK3AMA)
 

On 7/10/2017 8:33 AM, Justin Behan wrote:
Hi,

I updated to version 2.10.2 but the decodes no longer display the US states, LoTW and eQSL stripes .  These used to display in version 2.10.1
Is there a new way of getting these to display or is there a problem with my install?
I have attached a couple of screenshots showing my settings and the result.  Strangely the B4 is displaying while the others are not!


73

Justin
EI3CTB
Justin,

Nothing changed in 2.10.2 to cause non-display of the QSL flags or State abbreviations.

What your describing occurs when the Callsigns database is not installed.

Did you uninstall the database or perhaps run a 3rd party uninstaller that removed the files?

Install the Callsign database will fix your problem.

de Laurie VK3AMA


locked Re: Scan log with DXK - update!

HamApps Support (VK3AMA)
 

On 7/10/2017 8:26 AM, Phil Cooper wrote:

Hi Laurie,

Yes, you did mention the reasons – thankyou.

I am surprised that my log is big enough to cause this, as I am sure there are others working with similar setups – ie JTAlert, WSJTx and logging to DXKeeper who must have significantly larger logs than mine.

One thing I am still not quite understanding is the CQ Marathon scan criteria.

From the looks of it, JTAlert is scanning each band and all modes, and the result is reporting how many I have worked on a per-band basis.

CQ Marathon slots only count once, so working a GU on one band is all that is needed for Marathon. Working GU on other bands doesn’t improve your score at all.

So, today on 15m, I had alerts for SV5, which I have worked on other bands already this year. In fact, one SV5 I have worked on several bands, to help with his DXCC totals, but every time he comes up on a “new band”, I also get a Marathon alert.

Plus, I think JTAlert is counting Marathon on a per mode basis too. CQ Marathon only counts DIGI as a mode, rather than RTTY, JT65, JT9 FT8 etc.

Is there a way to handle this? Again, not an urgent appeal…

73 de Phil GU0SUP

Phil,

First a History lesson ;) ...
In the past a Scan Log only performed a scan based on the Band and Mode tracking a user had set for a particular Wanted Alert. If the user changed the tracking the Wanted Alert settings would change and a new scan was needed. This caused much confusion with frequent complaints that settings were being lost when a user say changed from any mode to individual mode tracking for WAS as an example. The WAS settings were not being lost, they had never been set for the new tracking criteria or were old inaccurate settings from past scans and tracking expeimentation.

I changed the Scan Log function to always scan for all possible tracking type combinations, mode and band, for all the Wanted Alert types. This way if a user changed a tracking method, whether deliberately or due to experimentation, the Wanted Alert list for that new tracking method would be accurate.

All Wanted Alert types support the same mode and band tracking combinations, even if the award the user is chasing doesn't explicitly support working each mode on each band, as an example. A users tracking requirements (and the subsequent alerting) are a users choice. I chose for all the Wanted Alerts to support all tracking methods for the sake of uniformity across alerts and for simplicity in the programming. Some users want to work/confirm each mode on each band regardless.

While, scanning for all tracking method combinations does add overhead to the scan time, it made the end-user experience much less confusing (and my support time spent on explaining the apparent loss of settings dropped to near zero).

The Answer...
For you Marathon example, just set the mode and band tracking to "Any Band" and "Any Digital Mode" and ignore the Scan Log results where you observe specific mode and band data.

de Laurie VK3AMA