Date   

locked Config nightmares: FT8, JTAlert, Log4OM #FT8 #JTDX

Peter Klein - KD7MW
 

Is there a way to configure JTAlert so it only monitors the received stream from JTDX or WSJT-X, but doesn't act as a go-between program between the FT8 program and Log4OM?

I'm asking because this "A thing on top of a thing, on top of another thing" multiple program configuration thing is getting frustrating.  :-)  Two programs, reasonably easy. Three programs handing off several functions to each other on multiple ports ...  not so easy when it breaks. Like the old Abbott and Costello routine, "Who's on first?"

Background:  When I started using FT8 four years ago, I ran WSJT-X with my logger, Log4OM. Then I found out about JTAlert, which made operating and logging much easier. I didn't care about JTAlert's DX cluster notifications and alarms. But I loved the clear presentation of received callsigns, Worked Before status and US States. The configuration was quite a bit more complex, but OK.

Then I tried JTDX, and liked it very much. So that's what I mostly use now. Using the Log4OM manual, I created a configuration that worked well with either WSJT-X or JTDX. It also allowed me to quickly switch to FLDigi if I heard an Olivia signal (or other conversational mode), without having to close and restart Log4OM with a new configuration.

The trouble was, it seems like every other time I upgraded one of the three programs, my configuration broke and I had to start over. After the latest JTDX upgrade, I got sufficiently frustrated that I uninstalled JTAlert and set things up so WSJT-X and JTDX interact directly with Log4OM. That's easy, and easy to troubleshoot if anything breaks.  But of course, I miss the JTAlert display, and the display of US callsigns with their States.

So I was wondering, is there a way for JTAlert interact only with the running FT8 program, reading and displaying the callsigns received, but not acting as a link in the chain between FT8 program and Log4OM?  That way, if something breaks, I would know exactly where to go to fix it. Ideally, JTAlert would still load wsjtx_log.adi from the FT8 program to see who I'd worked before.

Thanks!
--Peter, KD7MW


locked Re: New install not picking old log #HRD

Tom Job
 

If I remember correctly, in JTAlert setting>Logging>HRD, I think you have to point JTAlert to the log file.  I could be wrong as I only used the v5 HRD. 

Back then it was an MDB file(MS Access) ...don't know what they use now cuz I don't use it any more.

It sounds like you have two log files, a new one and an old one.  You may have to combine them in HRD by importing the old one into the new one, or visa versa, as I don't think JTAlert can use two logs at the same time.  And then point JTAlert to that new, combined file, which should contain everything.

Good luck...

Tom Job
ve3ii@...
Mobile: 705-791-0048


On 2022-01-15 12:19, AH0U wrote:
When I do a rebuild it only shows the new ones and none of the old log




Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com



locked Re: New install not picking old log #HRD

AH0U
 

Tnx but that is exactly what I did... when I  do a rebuild it only shows the new


locked Re: New install not picking old log #HRD

AH0U
 

When I do a rebuild it only shows the new ones and none of the old log


locked Re: New install not picking old log #HRD

Roger- AC6BW
 

Did you import the old QSOs into the new log as a ADIF file, or as a XML file (backup)?
If it was an ADIF file, the QSOs will not have all the QSL information in the file.
The correct procedure is to backup your log on your old PC to a XML file. Then copy that XML file over to the new PC, and import the XML file into the new HRD log. The XML file contains ALL of the fields that HRD uses, including the QSL sent/received, LoTW sent/received, etc.
--
73,
Roger
AC6BW


locked Re: New install not picking old log #HRD

AH0U
 

Yes.. all my old QSO's show in my new HRD install


locked Re: RTTY RU Worked Before Problem - Fault Found

neil_zampella
 

If one uses the WSJT-X built-in Cabrillo log, it will properly use DG for any FTx contact.

 

Neil, KN3ILZ


locked Re: RTTY RU Worked Before Problem - Fault Found

Jeff Young
 

I edited a copy of my log and changed the mode from DG back to FT4. Wrote out the cabillio file and it converted FT4 to DG. 

So, my error was using the mode change function to log contacts as DG during the contest.

73 
Jeff

-------- Original message --------
From: "Joe Subich, W4TV" <lists@...>
Date: 1/14/22 6:42 PM (GMT-06:00)
To: Support@HamApps.groups.io
Subject: Re: [HamApps] RTTY RU Worked Before Problem - Fault Found


Without checking the N3FJP software ... it *should* record the QSO with
the mode that was used on the air and *export* FT4/FT8 QSOs as DG for
the Cabrillo file.  ADIF exports should use <MODE:3>FT8 for FT8 and
<MODE:4>MFSK<SUBMODE:3>FT4 for LotW.  In any case the log should have
the correct mode *NOT* DG/RY.

73,

    ... Joe, W4TV


On 2022-01-14 6:48 PM, Jeff Young wrote:
> Will Cabrillo convert an FT4 to DG from a log that logged a QSO as FT4?
> If so, that's were I went wrong because I used the option in N3FJP'S
> RTTY RU to log contacts as DG immediately in the log during the contest.
> Jeff KB3HF
>
>
> -------- Original message --------
> From: Jim Cooper <JTalert@...>
> Date: 1/14/22 5:40 PM (GMT-06:00)
> To: Support@HamApps.groups.io
> Subject: Re: [HamApps] RTTY RU Worked Before Problem - Fault Found
>
> On 15 Jan 2022 at 10:10, HamApps Support (VK3AMA)
> wrote:
>
>  > Without any testing done yet, I have
>  > located the cause of the
>  > inconsistent B4 reporting. It is due
>  > to the mode logged as "DG" rather than
>  > "FT4". JTAlert would never find FT4
>  > worked B4 QSOs which are logged as
>  > "DG". That is not a mode JTAlert is
>  > looking for. I note that you have a
>  > mixture of "FT4" and "DG" logged for
>  > the contest.
>
> FYI, I can note for you that the RU contest
> Cabrillo file submission wants RY for RTTY
> contacts and DG for all other digital contacts.
>
> 2.4 In the Cabrillo formatted log, RTTY contacts use RY and
> all other digital modes use the DG
> mode abbreviations.
>
> I don't know if these get put into the ADIF log file,
> but that's basically where the DG comes from.
>
> w2jc
>








locked Re: RTTY RU Worked Before Problem - Fault Found

Joe Subich, W4TV
 

Without checking the N3FJP software ... it *should* record the QSO with
the mode that was used on the air and *export* FT4/FT8 QSOs as DG for
the Cabrillo file. ADIF exports should use <MODE:3>FT8 for FT8 and
<MODE:4>MFSK<SUBMODE:3>FT4 for LotW. In any case the log should have
the correct mode *NOT* DG/RY.

73,

... Joe, W4TV

On 2022-01-14 6:48 PM, Jeff Young wrote:
Will Cabrillo convert an FT4 to DG from a log that logged a QSO as FT4? If so, that's were I went wrong because I used the option in N3FJP'S RTTY RU to log contacts as DG immediately in the log during the contest.
Jeff KB3HF
-------- Original message --------
From: Jim Cooper <JTalert@jimcooper.org>
Date: 1/14/22 5:40 PM (GMT-06:00)
To: Support@HamApps.groups.io
Subject: Re: [HamApps] RTTY RU Worked Before Problem - Fault Found
On 15 Jan 2022 at 10:10, HamApps Support (VK3AMA)
wrote:

> Without any testing done yet, I have
> located the cause of the
> inconsistent B4 reporting. It is due
> to the mode logged as "DG" rather than
> "FT4". JTAlert would never find FT4
> worked B4 QSOs which are logged as
> "DG". That is not a mode JTAlert is
> looking for. I note that you have a
> mixture of "FT4" and "DG" logged for
> the contest.
FYI, I can note for you that the RU contest
Cabrillo file submission wants RY for RTTY
contacts and DG for all other digital contacts.
2.4 In the Cabrillo formatted log, RTTY contacts use RY and
all other digital modes use the DG
mode abbreviations.
I don't know if these get put into the ADIF log file,
but that's basically where the DG comes from.
w2jc


locked Re: RTTY RU Worked Before Problem - Fault Found

JTAlert Support (VK3AMA)
 

On 15/01/2022 10:40 am, Jim Cooper wrote:
FYI, I can note for you that the RU contest 
Cabrillo file submission wants RY for RTTY 
contacts and DG for all other digital contacts. 

2.4 In the Cabrillo formatted log, RTTY contacts use RY and 
all other digital modes use the DG
mode abbreviations.

I don't know if these get put into the ADIF log file, 
but that's basically where the DG comes from. 

w2jc 

It looks like a bad design decision by N3FJP, IMHO. changing the logged mode to meet the requirements of a Cabrillo log submission. If it was me, I would log the mode correctly, as used on-air, then change the mode as part of the Cabrillo file generation.

de Laurie VK3AMA


locked Re: RTTY RU Worked Before Problem - Fault Found

JTAlert Support (VK3AMA)
 

On 15/01/2022 10:36 am, Jeff Young wrote:
I changed the mode to DG because the ARRL RTTY RU  rules said RTTY QSOs were to be logged as "RY" and Digital  modes were to be logged as "DG". The one FT4 you found was because I forgot to change the mode. This apparently is a new feature in N3FJPs software to comply with the rules.
73 
JEFF KB3HF 

FYI, I counted over 70 QSOs logged as FT4 , not one. Regardless, "DG" is not a mode that JTAlert looks for when doing its B4 checks.

Since the N3FJP logger is remapping the mode during the logging, you need to set the "Alerts -> Worked B4" to ignore the mode.

de Laurie VK3AMA


locked Re: RTTY RU Worked Before Problem - Fault Found

Jeff Young
 

That's the solution when using log software that is specific to the contest and is a unique log compared to your main log that is used everyday. I didn't notice that option because how JTAert reads the file for B4 wasn't obvious to me

Jeff KB3HF

-------- Original message --------
From: "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...>
Date: 1/14/22 5:44 PM (GMT-06:00)
To: Support@HamApps.groups.io
Subject: Re: [HamApps] RTTY RU Worked Before Problem - Fault Found

On 15/01/2022 10:16 am, Michael Black via groups.io wrote:
Would that be RTTY perhaps?

Mike W9MDB

Don't know. If it is the case than the JTAlert B4 options need to be set to "ignore mode" in order to avoid dupes when a previous QSO was logged as DG and JTAlert not picking them up when the mode is FT4.

de Laurie VK3AMA


locked Re: RTTY RU Worked Before Problem - Fault Found

Jeff Young
 

Will Cabrillo convert an FT4 to DG from a log that logged a QSO as FT4? If so, that's were I went wrong because I used the option in N3FJP'S RTTY RU to log contacts as DG immediately in the log during the contest.
Jeff KB3HF 


-------- Original message --------
From: Jim Cooper <JTalert@...>
Date: 1/14/22 5:40 PM (GMT-06:00)
To: Support@HamApps.groups.io
Subject: Re: [HamApps] RTTY RU Worked Before Problem - Fault Found

On 15 Jan 2022 at 10:10, HamApps Support (VK3AMA)
wrote:

> Without any testing done yet, I have
> located the cause of the
> inconsistent B4 reporting. It is due
> to the mode logged as "DG" rather than
> "FT4". JTAlert would never find FT4
> worked B4 QSOs which are logged as
> "DG". That is not a mode JTAlert is
> looking for. I note that you have a
> mixture of "FT4" and "DG" logged for
> the contest.

FYI, I can note for you that the RU contest
Cabrillo file submission wants RY for RTTY
contacts and DG for all other digital contacts.

2.4 In the Cabrillo formatted log, RTTY contacts use RY and
all other digital modes use the DG
mode abbreviations.

I don't know if these get put into the ADIF log file,
but that's basically where the DG comes from.

w2jc









locked Re: RTTY RU Worked Before Problem - Fault Found

JTAlert Support (VK3AMA)
 

On 15/01/2022 10:16 am, Michael Black via groups.io wrote:
Would that be RTTY perhaps?

Mike W9MDB

Don't know. If it is the case than the JTAlert B4 options need to be set to "ignore mode" in order to avoid dupes when a previous QSO was logged as DG and JTAlert not picking them up when the mode is FT4.

de Laurie VK3AMA


locked Re: RTTY RU Worked Before Problem - Fault Found

Jim Cooper
 

On 15 Jan 2022 at 10:10, HamApps Support (VK3AMA)
wrote:

Without any testing done yet, I have
located the cause of the
inconsistent B4 reporting. It is due
to the mode logged as "DG" rather than
"FT4". JTAlert would never find FT4
worked B4 QSOs which are logged as
"DG". That is not a mode JTAlert is
looking for. I note that you have a
mixture of "FT4" and "DG" logged for
the contest.
FYI, I can note for you that the RU contest
Cabrillo file submission wants RY for RTTY
contacts and DG for all other digital contacts.

2.4 In the Cabrillo formatted log, RTTY contacts use RY and
all other digital modes use the DG
mode abbreviations.

I don't know if these get put into the ADIF log file,
but that's basically where the DG comes from.

w2jc


locked Re: RTTY RU Worked Before Problem - Fault Found

Jeff Young
 

Laurie, 
I changed the mode to DG because the ARRL RTTY RU  rules said RTTY QSOs were to be logged as "RY" and Digital  modes were to be logged as "DG". The one FT4 you found was because I forgot to change the mode. This apparently is a new feature in N3FJPs software to comply with the rules.
73 
JEFF KB3HF 

-------- Original message --------
From: "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...>
Date: 1/14/22 5:11 PM (GMT-06:00)
To: Support@HamApps.groups.io
Subject: Re: [HamApps] RTTY RU Worked Before Problem - Fault Found

Jeff,

I received your RU log, thanks.

Without any testing done yet, I have located the cause of the inconsistent B4 reporting. It is due to the mode logged as "DG" rather than "FT4". JTAlert would never find FT4 worked B4 QSOs which are logged as "DG". That is not a mode JTAlert is looking for. I note that you have a mixture of "FT4" and "DG" logged for the contest.

   

This looks like a N3FJP setup issue to me.

If "DG" is an acceptable mode for the N3FJP contest loggers then I will have to extend JTAlert to look for that mode when doing B4 checks. I am reluctant to do that at this time since your log has a mix of modes which may be a setup issue or a problem within the logger. I will wait and see.

de Laurie VK3AMA


locked Re: RTTY RU Worked Before Problem - Fault Found

Michael Black
 

Would that be RTTY perhaps?

Mike W9MDB




On Friday, January 14, 2022, 05:11:02 PM CST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


Jeff,

I received your RU log, thanks.

Without any testing done yet, I have located the cause of the inconsistent B4 reporting. It is due to the mode logged as "DG" rather than "FT4". JTAlert would never find FT4 worked B4 QSOs which are logged as "DG". That is not a mode JTAlert is looking for. I note that you have a mixture of "FT4" and "DG" logged for the contest.

   

This looks like a N3FJP setup issue to me.

If "DG" is an acceptable mode for the N3FJP contest loggers then I will have to extend JTAlert to look for that mode when doing B4 checks. I am reluctant to do that at this time since your log has a mix of modes which may be a setup issue or a problem within the logger. I will wait and see.

de Laurie VK3AMA


locked Re: RTTY RU Worked Before Problem - Fault Found

JTAlert Support (VK3AMA)
 

Jeff,

I received your RU log, thanks.

Without any testing done yet, I have located the cause of the inconsistent B4 reporting. It is due to the mode logged as "DG" rather than "FT4". JTAlert would never find FT4 worked B4 QSOs which are logged as "DG". That is not a mode JTAlert is looking for. I note that you have a mixture of "FT4" and "DG" logged for the contest.

   

This looks like a N3FJP setup issue to me.

If "DG" is an acceptable mode for the N3FJP contest loggers then I will have to extend JTAlert to look for that mode when doing B4 checks. I am reluctant to do that at this time since your log has a mix of modes which may be a setup issue or a problem within the logger. I will wait and see.

de Laurie VK3AMA


locked Re: New install not picking old log #HRD

JTAlert Support (VK3AMA)
 

On 15/01/2022 9:36 am, AH0U wrote:
had to get a new computer and installed WSJT, JTAlert and HRD all work fine but now I notice after I did a log scan in JTAlert, it does not pick up the log entries made from the old computer... For example I have 244 confirmed on 12 meters and JTAlert says 27... just those made after I installed the new computer.... correct this???
AH0U

The only way JTAlert will pickup the HRD log QSOs of your old PC is by bringing those old QSOs over to your new HRD install. Did you update your new HRD install with an import of your old log?

de Laurie VK3AMA


locked New install not picking old log #HRD

AH0U
 

I had to get a new computer and installed WSJT, JTAlert and HRD all work fine but now I notice after I did a log scan in JTAlert, it does not pick up the log entries made from the old computer... For example I have 244 confirmed on 12 meters and JTAlert says 27... just those made after I installed the new computer.... correct this???
AH0U

1561 - 1580 of 39945