Date   

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


locked Re: RTTY RU Worked Before Problem

JTAlert Support (VK3AMA)
 

On 14/01/2022 8:19 am, Jeff Young wrote:
Yes. I receive a confirmation from JTAert that the contest was logged and the logged QSO shows up immediately in the N3FJP log on my second screen. 

Also, there was no restart of JTAlert during the contest. What would happen if the software is restarted?

Thanks 
Jeff KB3HF 

Jeff,

If JTAlert is confirming the QSO was logged, which involves a direct read of the physical log file, then the B4 checks which are performed against the physical log file should also be accurate. I don't have an explanation at this time why the B4 status is lost on a band change, it appears that something is not working correctly. It may be in the JTAlert code in relation to the changes necessary to utilize one of the N3FJP contest loggers rather than ACLog.

I will need to reinstall my N3FJP software and setup a contest test environment to run some tests and hopefully can replicate the issue. If you don't mind, it would be helpful if I could get a zipped copy of your N3FJP RU contest log. It is best if I can test against real log data rather than artificial data.
Please send it to me direct if you can. to VK3AMA.Ham.Apps [at] gmail.com

Regarding my question about JTAlert restarts, that would only have been an issue if the wrong log file was being referenced and the internal B4 status cache being cleared on restarts. You can ignore the question since you were getting logging confirmations indicating the correct log was set.

de Laurie VK3AMA


locked Re: accented international characters

Barry VA7GEM
 

On Fri, Jan 7, 2022 at 02:09 PM, HamApps Support (VK3AMA) wrote:
On 8/01/2022 6:18 am, Barry VA7GEM via groups.io wrote:
Mike from HRD picked this up and has a developer working on fixing it.

de Barry
Tnx for the update Barry.

de Laurie VK3AMA
For those following this threead.
Quote from Mike
"But I have this and we'll tackle it. (That said - 100% of the dev hours right now are going into the current feature release. We'll need to get that out first.)"
Will see how long this takes to fix.
cheers de Barry



locked Re: Add option to only Read HRD Database #HRD

Ferry PD9FER
 
Edited

Yes. The callsign lookup in HRD Logbook runs when the QSO goes into HRD Logbook using the UDP "QSO Forwarding" method.

The callsign lookup does not function with the "TCP logging" that was put in-place "long before the QSO Forwarding interface."

Because of this, HRD users who wish to use the data in their log to populate lookup information (previous Comments; more detailed location information that may be in their logs in previous QSOs with that station) are unable to do so using the "TCP logging" method "from long ago."

We realize that there's not much information on this TCP logging method. Now that most applications support the UDP (QSO Forwarding) method, it's likely that the TCP logging method will be depreciated in time.

We would like to prepare for this now by asking if there's a way that JTAlert can connect to the log to load the data necessary to build the B4 and "wanted" items... but use the UDP QSO Forwarding method for sending QSOs to the log.

As Mike (WA9PIE) tells me, "We fully embrace JTAlert. We don't want anything to break in JTAlert as we move HRD forward." With that in mind, is there a solution possible?

 

73,

Ferry PD9FER


locked Re: RTTY RU Worked Before Problem

Jeff Young
 

In previous email, contest logged should be contact logged. Darn auto correct.
Jeff

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

On 13/01/2022 9:49 am, Jeff Young wrote:

My problem was the Worked Before (B4) function did not find/show contacts worked before in the contest if I started on 20m for instance, then changed bands to 40m for a while and then later changed back to the 20m band. B4 worked on the initial start of the both 20m and 40m bands, but when I returned to 20m from 40m a later point, the B4 function did not find/show B4 decoded stations from the first session in the 20m band resulting in me working dupes.

 

The actual logging of a contact to the N3FJP software worked fine but for some reason, it appears that JTAlert was not reading the entire database log for same band in different sessions during the contest.


Was there a JTAlert restart between your initial 20m activity and when you went back to 20m after working other bands?

Did JTAlert confirm that the QSO was correctly logged? If you had confirmations turned off, it may be a case of JTAlert not reading the correct log file and you never seeing the warning.

What you describe suggests to me that you don't have the correct logfile selected in the manual configuration, A JTAlert logging confirmation success or failure popup will answer that question for me.

de Laurie VK3AMA


locked Re: RTTY RU Worked Before Problem

Jeff Young
 

Laurie,

Yes. I receive a confirmation from JTAert that the contest was logged and the logged QSO shows up immediately in the N3FJP log on my second screen. 

Also, there was no restart of JTAlert during the contest. What would happen if the software is restarted?

Thanks 
Jeff KB3HF 

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

On 13/01/2022 9:49 am, Jeff Young wrote:

My problem was the Worked Before (B4) function did not find/show contacts worked before in the contest if I started on 20m for instance, then changed bands to 40m for a while and then later changed back to the 20m band. B4 worked on the initial start of the both 20m and 40m bands, but when I returned to 20m from 40m a later point, the B4 function did not find/show B4 decoded stations from the first session in the 20m band resulting in me working dupes.

 

The actual logging of a contact to the N3FJP software worked fine but for some reason, it appears that JTAlert was not reading the entire database log for same band in different sessions during the contest.


Was there a JTAlert restart between your initial 20m activity and when you went back to 20m after working other bands?

Did JTAlert confirm that the QSO was correctly logged? If you had confirmations turned off, it may be a case of JTAlert not reading the correct log file and you never seeing the warning.

What you describe suggests to me that you don't have the correct logfile selected in the manual configuration, A JTAlert logging confirmation success or failure popup will answer that question for me.

de Laurie VK3AMA

1441 - 1460 of 39820