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

Neil, KN3ILZ

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 

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 

Would that be RTTY perhaps?

Mike W9MDB

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.

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

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 

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

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