Date   

locked Re: Multiple Log Entries in Ham Radio Deluxe

Irwin Darack
 

I just gave it a try and yes it is a new feature in Ham Radio Deluxe. It seems to be allowing logging directly from both FT8 and JS8Call. I will test further later in the week.

Thanks, Irwin KD3TB


On Sat, Nov 16, 2019 at 9:10 PM Irwin Darack via Groups.Io <idarack=gmail.com@groups.io> wrote:
Thanks, I will try this after this weekend contest. I am also now using JS8Call Software too.

Best regards, Irwin KD3TB

On Sat, Nov 16, 2019 at 7:25 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 17/11/2019 7:45 am, Irwin Darack wrote:
HRD came out with a new version (6.7.0.244) and when logging FT8 QSO's with JT Alert 2.14.5 I am getting multiple entries into the log. Some of which have no info.

How do I stop this so I only get one entry.

--
Irwin KD3TB

Duplicate HRDLogbook QSOs is due to HRDLogbook directly logging the adif broadcast data of WSJT-X as well as logging the log QSO command from JTAlert using the HRD TCP API.
The log record with minimal data compared to the other record would be the one coming direct from WSJT-X.

If this is new behavior suggests that perhaps the new HRD release enabled that direct logging by default where in the past it had to be user enabled.

I don't know the name or location of the setting in HRDLogbook to turn off this direct logging, but it can be turned off by disabling the ADIF broadcast in WSJT-X (see the Reporting Tab of the WSJT-X Settings).

de Laurie VK3AMA



--
Irwin KD3TB



--
Irwin KD3TB


locked Re: Multiple Log Entries in Ham Radio Deluxe

Irwin Darack
 

Thanks, I will try this after this weekend contest. I am also now using JS8Call Software too.

Best regards, Irwin KD3TB


On Sat, Nov 16, 2019 at 7:25 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 17/11/2019 7:45 am, Irwin Darack wrote:
HRD came out with a new version (6.7.0.244) and when logging FT8 QSO's with JT Alert 2.14.5 I am getting multiple entries into the log. Some of which have no info.

How do I stop this so I only get one entry.

--
Irwin KD3TB

Duplicate HRDLogbook QSOs is due to HRDLogbook directly logging the adif broadcast data of WSJT-X as well as logging the log QSO command from JTAlert using the HRD TCP API.
The log record with minimal data compared to the other record would be the one coming direct from WSJT-X.

If this is new behavior suggests that perhaps the new HRD release enabled that direct logging by default where in the past it had to be user enabled.

I don't know the name or location of the setting in HRDLogbook to turn off this direct logging, but it can be turned off by disabling the ADIF broadcast in WSJT-X (see the Reporting Tab of the WSJT-X Settings).

de Laurie VK3AMA



--
Irwin KD3TB


locked Re: Multiple Log Entries in Ham Radio Deluxe

HamApps Support (VK3AMA)
 

On 17/11/2019 7:45 am, Irwin Darack wrote:
HRD came out with a new version (6.7.0.244) and when logging FT8 QSO's with JT Alert 2.14.5 I am getting multiple entries into the log. Some of which have no info.

How do I stop this so I only get one entry.

--
Irwin KD3TB

Duplicate HRDLogbook QSOs is due to HRDLogbook directly logging the adif broadcast data of WSJT-X as well as logging the log QSO command from JTAlert using the HRD TCP API.
The log record with minimal data compared to the other record would be the one coming direct from WSJT-X.

If this is new behavior suggests that perhaps the new HRD release enabled that direct logging by default where in the past it had to be user enabled.

I don't know the name or location of the setting in HRDLogbook to turn off this direct logging, but it can be turned off by disabling the ADIF broadcast in WSJT-X (see the Reporting Tab of the WSJT-X Settings).

de Laurie VK3AMA


locked New JTAlert 2.15.3

Gary Gorniak
 

2.15.3 fixed my sound issue.  Thanks Laurie!

 

73 de Gary – W9BS

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: Friday, November 15, 2019 8:56 PM
To: Support@HamApps.groups.io
Subject: [HamApps] New JTAlert 2.15.3 is available. #Announcement #NewRelease

 

The Latest JTAlert version 2.15.3 is now available @ https://hamapps.com/JTAlert/

Significant in this release are fixes to non-playing audio plus other audio fixes and usability improvements.

Please review the Release notes at the end of this message.

de Laurie VK3AMA

The Release Notes...


  *** Includes Callsign database file version 2019-11-16 (2019-November-16)

  New Features:

    - Ability to select the Sound device to use for alerts via the "Sound" menu.

  Changes:

    - Toggle Sound on/off hotkey has been removed.

    - Country name change, Swaziland is now "Kingdom of Eswatini". This is a
       cosmetic change, the underlying dxcc number as used by the Dxcc Alert
       remains unchanged (# 468).

  Fixes:

    - Sound Card drop-down list in the Settings window not highlighting active
       selection after JTAlert restart.

    - Sound not playing for a small number of users.

    - Callsigns display not cleared for non FT8/FT4 modes (JT65, JT9, MSK144)
       at approximately 48 seconds of the current minute.

    - Installed callsign database version included with the JTAlert installer not
       shown in the Program Updates section of the Settings window when an older
       database was previously installed by the standalone Database installer.


de Laurie VK3AMA


locked Re: Normal behaviour?

HamApps Support (VK3AMA)
 

On 16/11/2019 6:00 am, Uwe wrote:
Hi, I am using JTAlert 2.15.2 with logging enabled (Standard ADIF File). ADIF file contains all necessary information about DXCC, CQZ, ITUZ, State, QSL and so on. Scan Log and Rebuild also works fine so far. Setting under DXCC "Tracking" to one of the possible combinations fives always the intended logic.

However, when I am working a new DXCC (by band or mode) JTAlert doesn't recognize this as "worked" unless I manually click on "Scan Log and Rebuild".

Is that by design? Or am I doing something wrong?

At "Scan Log and Rebuild" / "Wanted DXCC" I've selected "No QSL Confirmation (Any Worked Station).

73 de Uwe, DG2YCB

The ability to remove a Wanted type (eg dxcc, state, grid, etc) after working a station is not available. That feature is on the todo list but unlikely to be implemented any time soon. At this time, the only way to automatically remove a Wanted type is by running the "Scan Log" even if the Scan is set for no QSL confirmation.

de Laurie VK3AMA


locked Re: logging wrong frequency aafter QSO

HamApps Support (VK3AMA)
 

On 17/11/2019 2:26 am, Tory Wiedenkeller wrote:
I use N3FJP in conjunction with WSJT-X and JT-Alert. The WSJT-X is setup for rig control of my Icom 7300. I'm working almost entirely in FT8  among the: 80, 40, 20, 17m bands.
I've noticed on a few occasions now when I've logged a QSO, there is a discrepancy between the band/freq that N3FJP logs the QSO, and the actual band/freq the QSO took place on
For ex. I recently had a QSO with a station in Alaska on 40m band. Everything seemed to log into N3FJP fine, but when I went back and looked at this log, it showed the QSO actually took place on the 80m band rather than 40m
       So, I'm wondering if anyone knows why this would happen and how to fix this problem?  I'm getting emails from these stations telling me the info is wrong. Of course it is. N3FJP is not logging the data correctly.

JTAlert logs the frequency contained in the QSO logged data packet received from WSJT-X. If JTAlert is logging the wrong frequency, than WSJT-X is showing the wrong frequency.

Once the Log QSO window in WSJT-X is open the logging frequency is set and will not change even if the WSJT-X QRG is changed before finalizing the logging (hitting the OK button). However, if you change frequency in WSJT-X before hitting the Log QSO button in WSJT-X the frequency logged will be the new frequency, not the frequency of the actual QSO.

de Laurie VK3AMA


locked Re: Band activity - how long to close?

HamApps Support (VK3AMA)
 

On 17/11/2019 3:25 am, Ed wrote:
Placing the cursor over the list of bands in the upper right hand corner of the JTalert window the activity per band listing pops up. What controls how long the popup stays open? Is there some action I can take to close it on demand?

Thank you,

Ed W2GHD
"What controls how long the popup stays open"? The length of time your mouse cursor remains over the Band numbers area. If you don't move your mouse off that area, the popup will remain open.

de Laurie VK3AMA


locked Re: logging wrong frequency aafter QSO

John K9IJ
 

I'm using ACL for rig control, not WSJTX. I'm not sure what WSJTX does when it's being used
for rig control. I don't really find a need for rig control in FT8/4. I set the rig to the base FT8 frequency
for the band I'm working and don't need to move around from there.

On 11/16/2019 3:50 PM, Tory Wiedenkeller wrote:
Thanks for the info, but WSJT-X selects the frequency / band. So, if I use WSJT-X to go from 80-40m, the rig will switch over. If I use the VFO knob on the rig to change the frequency, 
I get a 'red' window on WSJT-X showing that I'm not on the freq. I should be on.

-Tory

On Sat, Nov 16, 2019 at 11:00 AM John K9IJ <k9ij@...> wrote:
Tory,

The band logged is dependent on the band selected in WSJT. If that band is wrong, the QSO will still take place
but the band sent to JTAlert will be incorrect and then logged incorrectly to ACLog. Even if rig control is running
and the rig is on a different band.

John - K9IJ


On 11/16/2019 9:26 AM, Tory Wiedenkeller wrote:
I use N3FJP in conjunction with WSJT-X and JT-Alert. The WSJT-X is setup for rig control of my Icom 7300. I'm working almost entirely in FT8  among the: 80, 40, 20, 17m bands.
I've noticed on a few occasions now when I've logged a QSO, there is a discrepancy between the band/freq that N3FJP logs the QSO, and the actual band/freq the QSO took place on
For ex. I recently had a QSO with a station in Alaska on 40m band. Everything seemed to log into N3FJP fine, but when I went back and looked at this log, it showed the QSO actually took place on the 80m band rather than 40m
       So, I'm wondering if anyone knows why this would happen and how to fix this problem?  I'm getting emails from these stations telling me the info is wrong. Of course it is. N3FJP is not logging the data correctly.

-- 
No trees were killed in the sending of this message. However, a large number of electrons were terribly inconvenienced !

k9ij@...
Webmaster, Network Admin, Janitor

-- 
No trees were killed in the sending of this message. However, a large number of electrons were terribly inconvenienced !

k9ij@...
Webmaster, Network Admin, Janitor


locked Re: logging wrong frequency aafter QSO

Tory Wiedenkeller
 

Thanks for the info, but WSJT-X selects the frequency / band. So, if I use WSJT-X to go from 80-40m, the rig will switch over. If I use the VFO knob on the rig to change the frequency, 
I get a 'red' window on WSJT-X showing that I'm not on the freq. I should be on.

-Tory

On Sat, Nov 16, 2019 at 11:00 AM John K9IJ <k9ij@...> wrote:
Tory,

The band logged is dependent on the band selected in WSJT. If that band is wrong, the QSO will still take place
but the band sent to JTAlert will be incorrect and then logged incorrectly to ACLog. Even if rig control is running
and the rig is on a different band.

John - K9IJ


On 11/16/2019 9:26 AM, Tory Wiedenkeller wrote:
I use N3FJP in conjunction with WSJT-X and JT-Alert. The WSJT-X is setup for rig control of my Icom 7300. I'm working almost entirely in FT8  among the: 80, 40, 20, 17m bands.
I've noticed on a few occasions now when I've logged a QSO, there is a discrepancy between the band/freq that N3FJP logs the QSO, and the actual band/freq the QSO took place on
For ex. I recently had a QSO with a station in Alaska on 40m band. Everything seemed to log into N3FJP fine, but when I went back and looked at this log, it showed the QSO actually took place on the 80m band rather than 40m
       So, I'm wondering if anyone knows why this would happen and how to fix this problem?  I'm getting emails from these stations telling me the info is wrong. Of course it is. N3FJP is not logging the data correctly.

-- 
No trees were killed in the sending of this message. However, a large number of electrons were terribly inconvenienced !

k9ij@...
Webmaster, Network Admin, Janitor


locked Multiple Log Entries in Ham Radio Deluxe

Irwin Darack
 

HRD came out with a new version (6.7.0.244) and when logging FT8 QSO's with JT Alert 2.14.5 I am getting multiple entries into the log. Some of which have no info.

How do I stop this so I only get one entry.

--
Irwin KD3TB


locked Suggestion for "Wanted" selections dialog boxes

WB5JJJ - George
 

I find JTA invaluable in filling in the missing entities of a 45+ year ham radio experience now that the bands are not all that great.  It's keeping me active until the next cycle creeps in and I can do more of my beloved SSB operation. 

OK first off, I use the latest JTAlert use it to keep watch on ALL my DXCC activities for any mode I operate, both digital and SSB/CW that are confirmed in HRD LB over the last 45+ years.  Yes I know, HRD LB has only been around for about 15 years, but I exported/imported my logs from so many previous loggers before stopping with HRD in the Simon days.  Therefore, I can't use the scan log function as it does scan for the JTA digital modes,but it also removes all my diligently, manually included States/DXCC on other digital and SSB/CW confirmed contacts, as I found out the hard way some months back.  It's a bit cumbersome, but I've got a system that works for me, using the best of both worlds. 

Having said all of that as background, my main concern is the inconsistent naming of DXCC entries versus ARRL conventions and thus LoTW verification.  In particular are the DXCC's with "Saint" in them.  ARRL and others have "Saint" while JTA, and a couple others use "St.", which sorts them differently.  Also, "South Africa" and "Republic of South Africa".  These are the main differences I've found, but there were others from time to time, mostly in the spelling of the entity or the lack of "Is." in the name.  Is it possible to provide a more consistent lookup for these, especially with LoTW, which is pretty much the de facto DXCC standard? 

Also, is there function to backup all the "Not Wanted" data? 

--
73's
George - WB5JJJ


locked Re: V2.15.2 looses audio alerts

Gary - AC6EG <gdefeyter@...>
 

I found that v2.15.3 intermittently caused my alert sounds to "studder."  The alerts would sound great for a few minutes, but would then start to sound like the words were spoken underwater.  Once it started doing that, the only cure was to stop and restart the program.
I am using JTAlert on a Win7 Pro - 32bit desktop with WSJT-X v2.1.0 and a TS-590SG.  I've temporarily reverted back to JTAlert v2.15.1. 

de Gary - AC6EG   


locked Re: logging wrong frequency aafter QSO

John K9IJ
 

Tory,

The band logged is dependent on the band selected in WSJT. If that band is wrong, the QSO will still take place
but the band sent to JTAlert will be incorrect and then logged incorrectly to ACLog. Even if rig control is running
and the rig is on a different band.

John - K9IJ


On 11/16/2019 9:26 AM, Tory Wiedenkeller wrote:
I use N3FJP in conjunction with WSJT-X and JT-Alert. The WSJT-X is setup for rig control of my Icom 7300. I'm working almost entirely in FT8  among the: 80, 40, 20, 17m bands.
I've noticed on a few occasions now when I've logged a QSO, there is a discrepancy between the band/freq that N3FJP logs the QSO, and the actual band/freq the QSO took place on
For ex. I recently had a QSO with a station in Alaska on 40m band. Everything seemed to log into N3FJP fine, but when I went back and looked at this log, it showed the QSO actually took place on the 80m band rather than 40m
       So, I'm wondering if anyone knows why this would happen and how to fix this problem?  I'm getting emails from these stations telling me the info is wrong. Of course it is. N3FJP is not logging the data correctly.

-- 
No trees were killed in the sending of this message. However, a large number of electrons were terribly inconvenienced !

k9ij@...
Webmaster, Network Admin, Janitor


locked logging wrong frequency aafter QSO

Tory Wiedenkeller
 

I use N3FJP in conjunction with WSJT-X and JT-Alert. The WSJT-X is setup for rig control of my Icom 7300. I'm working almost entirely in FT8  among the: 80, 40, 20, 17m bands.
I've noticed on a few occasions now when I've logged a QSO, there is a discrepancy between the band/freq that N3FJP logs the QSO, and the actual band/freq the QSO took place on
For ex. I recently had a QSO with a station in Alaska on 40m band. Everything seemed to log into N3FJP fine, but when I went back and looked at this log, it showed the QSO actually took place on the 80m band rather than 40m
       So, I'm wondering if anyone knows why this would happen and how to fix this problem?  I'm getting emails from these stations telling me the info is wrong. Of course it is. N3FJP is not logging the data correctly.


locked File naming on site

Guy G4DWV 4X1LT
 

Hi,

Since the "HamApps" was dropped from the filename of JTAlert, the files for download have lost their consistency. That means I have to rename at least one to keep them together in my downloads.

Could either the old name be reinstated or could  "JTAlert" replace the "HamApps" in the other two?
--
73 de Guy G4DWV 4X1LT


locked Band activity - how long to close?

Ed
 

Hello,

Placing the cursor over the list of bands in the upper right hand corner of the JTalert window the activity per band listing pops up. What controls how long the popup stays open? Is there some action I can take to close it on demand?

Thank you,

Ed W2GHD


locked Re: V2.15.2 looses audio alerts

Rick Boswell
 

Yaay! 2.15.3 fixes my "no sound" problem with 2.15.2. Thanks!

Rick
K8EZB


locked New JTAlert 2.15.3 is available. #Announcement #NewRelease

HamApps Support (VK3AMA)
 

The Latest JTAlert version 2.15.3 is now available @ https://hamapps.com/JTAlert/

Significant in this release are fixes to non-playing audio plus other audio fixes and usability improvements.

Please review the Release notes at the end of this message.

de Laurie VK3AMA

The Release Notes...

  *** Includes Callsign database file version 2019-11-16 (2019-November-16)

  New Features:

    - Ability to select the Sound device to use for alerts via the "Sound" menu.

  Changes:

    - Toggle Sound on/off hotkey has been removed.

    - Country name change, Swaziland is now "Kingdom of Eswatini". This is a
       cosmetic change, the underlying dxcc number as used by the Dxcc Alert
       remains unchanged (# 468).

  Fixes:

    - Sound Card drop-down list in the Settings window not highlighting active
       selection after JTAlert restart.

    - Sound not playing for a small number of users.

    - Callsigns display not cleared for non FT8/FT4 modes (JT65, JT9, MSK144)
       at approximately 48 seconds of the current minute.

    - Installed callsign database version included with the JTAlert installer not
       shown in the Program Updates section of the Settings window when an older
       database was previously installed by the standalone Database installer.


de Laurie VK3AMA


locked Re: Normal behaviour?

Joe Subich, W4TV
 

On 2019-11-15 2:00 PM, Uwe wrote:

However, when I am working a new DXCC (by band or mode) JTAlert doesn't recognize this as "worked" unless I manually click on "Scan Log and Rebuild". >
Is that by design?
Yes, JTAlert does not update its database until "Scan Log and Rebuild".

Typically, one would not want to take an entity off the "needed" list
until receiving a card or confirmation by LotW. That would only be
recorded as a result of scanning the log.

73,

... Joe, W4TV


On 2019-11-15 2:00 PM, Uwe wrote:
Hi, I am using JTAlert 2.15.2 with logging enabled (Standard ADIF File). ADIF file contains all necessary information about DXCC, CQZ, ITUZ, State, QSL and so on. Scan Log and Rebuild also works fine so far. Setting under DXCC "Tracking" to one of the possible combinations fives always the intended logic.
However, when I am working a new DXCC (by band or mode) JTAlert doesn't recognize this as "worked" unless I manually click on "Scan Log and Rebuild".
Is that by design? Or am I doing something wrong?
At "Scan Log and Rebuild" / "Wanted DXCC" I've selected "No QSL Confirmation (Any Worked Station).
73 de Uwe, DG2YCB


locked Normal behaviour?

Uwe, DG2YCB
 

Hi, I am using JTAlert 2.15.2 with logging enabled (Standard ADIF File). ADIF file contains all necessary information about DXCC, CQZ, ITUZ, State, QSL and so on. Scan Log and Rebuild also works fine so far. Setting under DXCC "Tracking" to one of the possible combinations fives always the intended logic.

However, when I am working a new DXCC (by band or mode) JTAlert doesn't recognize this as "worked" unless I manually click on "Scan Log and Rebuild".

Is that by design? Or am I doing something wrong?

At "Scan Log and Rebuild" / "Wanted DXCC" I've selected "No QSL Confirmation (Any Worked Station).

73 de Uwe, DG2YCB