I am using JTDX, JTAlert & Log4OM. I switched to JTDX about 1 month ago and have Log4om configured to receive logging info from JTAlert. When Log4om receives QSO info from a compound callsign ex: kp2/nk4dx that I just worked. Log4om logs it as United States instead of US Virgin Islands. It does this on all compound calls worked. It only started this after I configured JTDX & JTAlert. I had no issue with WSJT-X & JTAlert, Log4om.
So I'm not sure where the issue might be. I looked over all 3 apps and saw nothing that I could change.

Thanks,
Dave
k4em

On 2021-02-19 6:52 AM, Dave wrote:

When Log4om receives QSO info from a compound callsign ex: kp2/nk4dx
that I just worked. Log4om logs it as United States instead of US
Virgin Islands.

I think I can remove Log4OM and JTDX from the issue. I saw the same
incorrect entity when logging ZA/IN3PPH from WSJTX 2.4.0-rc1 to
DXKeeper (DXLab Suite) via JT-Alert.

73,

... Joe, W4TV


On 2021-02-19 6:52 AM, Dave wrote:

I am using JTDX, JTAlert & Log4OM. I switched to JTDX about 1 month ago and have Log4om configured to receive logging info from JTAlert. When Log4om receives QSO info from a compound callsign ex: kp2/nk4dx that I just worked. Log4om logs it as United States instead of US Virgin Islands. It does this on all compound calls worked. It only started this after I configured JTDX & JTAlert. I had no issue with WSJT-X & JTAlert, Log4om.
So I'm not sure where the issue might be. I looked over all 3 apps and saw nothing that I could change.
Thanks,
Dave
k4em

In my case ZA/IN3PPH logged as ITALY. There were no previous
QSOs with either ZA/IN3PPH, IN3PPH or */IN3PPH.

73,

... Joe, W4TV

I am using JTDX, JTAlert & Log4OM. I switched to JTDX about 1 month ago and have Log4om configured to receive logging info from JTAlert. When Log4om receives QSO info from a compound callsign ex: kp2/nk4dx that I just worked. Log4om logs it as United States instead of US Virgin Islands. It does this on all compound calls worked. It only started this after I configured JTDX & JTAlert. I had no issue with WSJT-X & JTAlert, Log4om.
So I'm not sure where the issue might be. I looked over all 3 apps and saw nothing that I could change.

Thanks,
Dave
k4em

_._,_._,_

---

Dave,

I did a test log to Log4OM using WSJT-X 2.3.0  and JTAlert 2,16.17, and kp2/nk4dx logged correctly as US Virgin Islands. I then deleted that QSO from Log4OM and did the same test, except I used JTDX 2.2.0-rc153, with the same results. Both times the QSO loged correctly.

73,

Jim N6VH

On 2021-02-19 9:49 AM, OM Marlon via groups.io wrote:

Log4OM sees this as Albania here,I supposed it will be logged that way
once we have a QSO

DXKeeper (DXLab Suite) also sees ZA/IN3PPH as Albania if I enter it
directly. However, it logged as Italy when worked in WSJTX 3.4.0
and logged by JTAlert 2.16.17.

73,

... Joe, W4TV


On 2021-02-19 9:49 AM, OM Marlon via groups.io wrote:

Hi Joe,
Log4OM sees this as Albania here,I supposed it will be logged that way once we have a QSO
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
*From: *Joe Subich, W4TV <mailto:lists@subich.com>
*Sent: *Friday, 19 February 2021 10:03 pm
*To: *Support@HamApps.groups.io <mailto:Support@HamApps.groups.io>
*Subject: *Re: [HamApps] Not logging compound call signs in Log4om. using JTDX, JTalert, Log4om
In my case ZA/IN3PPH logged as ITALY.  There were no previous
QSOs with either ZA/IN3PPH, IN3PPH or */IN3PPH.
73,
    ... Joe, W4TV
On 2021-02-19 8:55 AM, Michael Black via groups.io wrote:

> Check your log for a previous QSO where it's logged as U.S.

>

> Mike W9MDB

>

>

>

>

> On Friday, February 19, 2021, 07:42:48 AM CST, Joe Subich, W4TV

> <lists@subich.com> wrote:

>

>

> On 2021-02-19 6:52 AM, Dave wrote:

>  > When Log4om receives QSO info from a compound callsign ex: kp2/nk4dx

>  > that I just worked. Log4om logs it as United States instead of US

>  > Virgin Islands.

> I think I can remove Log4OM and JTDX from the issue.  I saw the same

> incorrect entity when logging ZA/IN3PPH from WSJTX 2.4.0-rc1 to

> DXKeeper (DXLab Suite) via JT-Alert.

>

> 73,

>

>      ... Joe, W4TV

>

>

> On 2021-02-19 6:52 AM, Dave wrote:

>  > I am using JTDX, JTAlert & Log4OM. I switched to JTDX about 1
month ago

>  > and have Log4om configured to receive logging info from JTAlert. When

>  > Log4om receives QSO info from a compound callsign ex: kp2/nk4dx that I

>  > just worked. Log4om logs it as United States instead of US Virgin

>  > Islands. It does this on all compound calls worked. It only
started this

>  > after I configured JTDX & JTAlert. I had no issue with WSJT-X &
JTAlert,

>  > Log4om.

>  > So I'm not sure where the issue might be. I looked over all 3 apps and

>  > saw nothing that I could change.

>  >

>  > Thanks,

>  > Dave

>  > k4em

On 2021-02-19 9:53 AM, Michael Black via groups.io wrote:

JTAlert gets it correct too. This would be a successful QRZ lookup.

OK, I've gotten to the bottom of this. The issue is JTAlert ...

1) I'm using the free "Ham QTH" XML lookup in JTAlert
2) both ZA/IN3PPH and KP2/NK4DX return *HOME ADDRESS* when
Ham QTH is used for the lookup.
3) JT Alert apparently parses the XML lookup for country rather
that the callsign thus the TCP "log" directive to DXKeeper
(DXLab Suite) contains the country of the home address, not
the country indicated by the (compound) callsign used for the
QSO.

If I were willing to pay for QRZcom's XML service, things might
be different but I have no way of testing that thesis. However,
both ZA/IN3PPH and KP2/NK4DX are logged with an incorrect (home)
country when using the HamQTH XML lookup (apparently because JTAlert
relies on the XML rather than parse the call directly and DXKeeper
uses the ADIF number supplied in the "Log" directive from JTAlert).

73,

... Joe, W4TV


On 2021-02-19 9:53 AM, Michael Black via groups.io wrote:

JTAlert gets it correct too.  This would be a successful QRZ lookup.
Mike W9MDB
Inline image
On Friday, February 19, 2021, 08:49:37 AM CST, OM Marlon via groups.io <du3cwm=yahoo.ca@groups.io> wrote:
Hi Joe,
Log4OM sees this as Albania here,I supposed it will be logged that way once we have a QSO
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
*From: *Joe Subich, W4TV <mailto:lists@subich.com>
*Sent: *Friday, 19 February 2021 10:03 pm
*To: *Support@HamApps.groups.io <mailto:Support@HamApps.groups.io>
*Subject: *Re: [HamApps] Not logging compound call signs in Log4om. using JTDX, JTalert, Log4om
In my case ZA/IN3PPH logged as ITALY.  There were no previous
QSOs with either ZA/IN3PPH, IN3PPH or */IN3PPH.
73,
    ... Joe, W4TV
On 2021-02-19 8:55 AM, Michael Black via groups.io wrote:

> Check your log for a previous QSO where it's logged as U.S.

>

> Mike W9MDB

>

>

>

>

> On Friday, February 19, 2021, 07:42:48 AM CST, Joe Subich, W4TV

> <lists@subich.com> wrote:

>

>

> On 2021-02-19 6:52 AM, Dave wrote:

>  > When Log4om receives QSO info from a compound callsign ex: kp2/nk4dx

>  > that I just worked. Log4om logs it as United States instead of US

>  > Virgin Islands.

> I think I can remove Log4OM and JTDX from the issue.  I saw the same

> incorrect entity when logging ZA/IN3PPH from WSJTX 2.4.0-rc1 to

> DXKeeper (DXLab Suite) via JT-Alert.

>

> 73,

>

>      ... Joe, W4TV

>

>

> On 2021-02-19 6:52 AM, Dave wrote:

>  > I am using JTDX, JTAlert & Log4OM. I switched to JTDX about 1
month ago

>  > and have Log4om configured to receive logging info from JTAlert. When

>  > Log4om receives QSO info from a compound callsign ex: kp2/nk4dx that I

>  > just worked. Log4om logs it as United States instead of US Virgin

>  > Islands. It does this on all compound calls worked. It only
started this

>  > after I configured JTDX & JTAlert. I had no issue with WSJT-X &
JTAlert,

>  > Log4om.

>  > So I'm not sure where the issue might be. I looked over all 3 apps and

>  > saw nothing that I could change.

>  >

>  > Thanks,

>  > Dave

>  > k4em

2) both ZA/IN3PPH and KP2/NK4DX return *HOME ADDRESS* when
   Ham QTH is used for the lookup.
3) JT Alert apparently parses the XML lookup for country rather
   that the callsign thus the TCP "log" directive to DXKeeper
   (DXLab Suite) contains the country of the home address, not
   the country indicated by the (compound) callsign used for the
   QSO.

Wrong!

JTAlert DOES NOT parse any sort of address returned from an XML lookup to determine correct dxcc. It never has and never will. It uses the unambiguous dxcc field returned in the XML lookup.

JTAlert correctly identifies both ZA/IN3PPH and KP2/NK4DX as Albania and VI respectively prior to an XML lookup. The XML lookups for both returned correct dxcc.
eg both these images after the XML lookup (note the filling in of the name & qth & 6 char grid indicating these values came from an external source)





The XML results (from QRZ) both correctly identify the correct DXCC...

<?xml version="1.0" encoding="utf-8" ?>
<QRZDatabase version="1.34" xmlns="http://xmldata.qrz.com">
<Callsign>
<call>KP2/NK4DX</call>
<dxcc>285</dxcc>
<attn>EZ PRADO SR.</attn>

<?xml version="1.0" encoding="utf-8" ?>
<QRZDatabase version="1.34" xmlns="http://xmldata.qrz.com">
<Callsign>
<call>ZA/IN3PPH</call>
<dxcc>7</dxcc>
<fname>Sandro</fname>

If you free XML service is known to produce incorrect results than you as the operator should take extra care that data is correct before logging. The Log Fields area of JTAlert allows for user modification and any changes made will be reflected in the logged QSO.

de Laurie VK3AMA

(apparently because JTAlert
relies on the XML rather than parse the call directly and DXKeeper
uses the ADIF number supplied in the "Log" directive from JTAlert).

JTAlert does parse the Callsign to determine country of origin and if an XML lookup returns a result it will use that data from that. With the large number of special event callsigns that abound plus lid operators who use the incorrect prefix/suffix parsing of the Callsign alone can be problematic. JTAlert assumes that the XML data is correct as it will any previous QSOs in the log.

de Laurie VK3AMA

I did a test log to Log4OM using WSJT-X 2.3.0  and JTAlert 2,16.17, and kp2/nk4dx logged correctly as US Virgin Islands. I then deleted that QSO from Log4OM and did the same test, except I used JTDX 2.2.0-rc153, with the same results. Both times the QSO loged correctly.

73,

Jim N6VH

Jim,

I get the same correct results in my tests.

The fault lies in using the free HamQTH XML service returning incorrect results. The QRZ xml service returns the correct results.

de Laurie VK3AMA

On 20/02/2021 3:22 am, Jim N6VH wrote:

I did a test log to Log4OM using WSJT-X 2.3.0  and JTAlert 2,16.17, and kp2/nk4dx logged correctly as US Virgin Islands. I then deleted that QSO from Log4OM and did the same test, except I used JTDX 2.2.0-rc153, with the same results. Both times the QSO loged correctly.

73,

Jim N6VH

Jim,

I get the same correct results in my tests.

The fault lies in using the free HamQTH XML service returning incorrect results. The QRZ xml service returns the correct results.

de Laurie VK3AMA

_

Laurie,

Yes, very true. The chance of incorrect data is the main reason I don't normally use lookups. I prefer to trust the data sent from JTAlert.

73,

Jim N6VH

._,_._,_

JTAlert is certainly changing the "country" as a result of the XML
lookup. The country is correct without XML lookup:
<za-in3pph-za.jpg>
but is incorrect when XML lookup is enabled via HamQTH:
<za-in3pph-i.jpg>

1) I do not display log fields as I am severely "screen constrained."
At the very least, those fields should be displayed in the pop-up
prior to logging particularly if the XML results do not agree with
the callsign.

2) It seems to me that the results of the XML lookup *SHOULD NOT*
change the Country (DXCC/ADIF ID) reported to a logging program
as that would be determined entirely *BY THE CALLSIGN* (presumably
with the assistance of a reference like AD1C's CTY list) except
for the (rare) ambiguous prefix like FO, TO, 3D2, GB, etc. that
might not appear in the reference.

73,

... Joe, W4TV

I updated all the call sign databases in log4om.
On 20m FT8 I clicked on DL/OK3RIC and pressed the JTDX Log QSO button to manually log the call. It was logged as Germany in Log4om. I then worked, W2/JR1AQN and it was automatically logged as JAPAN not USA.

I went through and looked at a few settings.
In JTAlert under Web Services; I do not have xml for QRZ or HAMQTH enabled. In Log4om 'Info providers' I do have QRZ xml (primary) set & HAMQTH (secondary) set; I have disabled HAMQTH.
In JTDX; File, settings, near the top of page; there is a setting for Compound callsigns; 'Message generation for type 2 compound callsign holders'. Mine was set for 'Full call in TX3'. I changed it to 'Full call in TX5 only'. I have no idea if this is the issue or not, there are few compound callsigns on FT8 right now.
I will try and work as many compound calls and see what happens.

Thanks so much for all the responses,
Dave
k4em