Date   
Re: JJ00aa

Dave AA6YQ
 

+ AA6YQ comments below

Dave commented on this about a week ago. JJ00aa is lat 0 long 0 which is not unreasonable lacking actual locator info.

+ DXKeeper will only do that if the imported ADIF record specifies a latitude of 0 and a longitude of 0, or if configured to perform a callbook lookup and the callbook returns a grid square of JJ00aa.

73,

Dave, AA6YQ

Re: JJ00aa

Dave AA6YQ
 

+ AA6YQ comments below

why, upon ADIF log/QSOs import,
DXKeeper fills missing QRA locator data with false GRIDSQUARE JJ00aa, please?

+ Please attach the ADIF file you imported to an email message, and send the message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ

Re: JJ00aa

Alec SP2EWQ <aleksander.otulak@...>
 

 

 

Joe,

 

have a look at https://sp9wzo.pl/ and QRZ.com table shown in there.

 

Be serious,

it seems to me the disease has been being spread over the major networks

 

The above closes the case for me…

 

Best regards,

Alec

 

 

 

 

-----Original Message-----
From: aleksander.otulak@... <aleksander.otulak@...>
Sent: Wednesday, November 27, 2019 3:34 PM
To: 'DXLab@groups.io' <DXLab@groups.io>
Subject: RE: [DXLab] JJ00aa

 

 

Joe,

thanks for the info and suggestion. I had successfully removed the bad GRIDSQUARE records.

 

However,

even with the 'Deduce missing Items...' and 'Query callbook and DXCC database for missing Items'

in the Import Options unclicked, the JJ00aa is still being added - so it does not obviously work, or it is not the source of that apparent (to me) malfunction.

 

It also means one needs filter and modify the GRIDSQUARE on a constant basis if they cares.

 

Thanks again,

and best regards...

 

Alec

 

 

 

 

 

-----Original Message-----

From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Joe Subich, W4TV

Sent: Wednesday, November 27, 2019 3:11 PM

To: DXLab@groups.io

Subject: Re: [DXLab] JJ00aa

 

 

The alternative explanation is that the user has checked "Query callbook and DXCC database for missing items" on import and the *callbook* is returning lat 0/lon 0 for some/all of the records.

 

In either case, this is not a DXKeeper error it is a case of bad data from an external source (original logging program or callbook).

 

The easiest way to "fix" the current problem is to:

 

1) *BACKUP THE DXKEEPER LOG*

2) Filter the log for GRIDSQUARE = "JJ00aa"

3) Use MODIFY QSOs in Log Page Display to set:

    LAT = <blank>

    LON = <blank>

    GRIDSQUARE = <blank>

    (note: <blank> for "new item value" is simply empty which clears

     the existing data).

 

The long term solution is to modify the original log so it does not emit LAT 0/LON 0 or to clear the "Query callbook and DXCC database for missing items" depending on the original source of the problem.

 

73,

 

    ... Joe, W4TV

 

 

On 2019-11-27 8:45 AM, g4wjs wrote:

> Alec,

>

> read my response again, more carefully this time. I did not imply that

> your ADIF file specifies JJ00aa as a grid square, I suggested it

> specifies a latitude and longitude of zero. DXKeeper would be

> perfectly reasonable if it were to correctly interpret such

> coordinates as being in grid square JJ00aa since that is exactly where they are located.

>

> Why not provide us with an example record from your ADIF file that

> ends up with a grid square JJ00aa?

>

> On 27/11/2019 13:41, Alec SP2EWQ wrote:

>> 

>> *Hi*,

>> 

>> Negative - sorry...

>> 

>> GRIDSQUARE is NOT specified in the import file for those records

>> 

>> AT ALL.

>> 

>> Putting JJ00AA in that place is COMPLETELY UNREASONABLE

>> 

>> and KILLING all the rotating procedures for such records.

>> 

>> Even more,

>> 

>> if such records at a later date are exported outside DXLAB,

>> 

>> the completely INadequate GRIDQUARE information infects

>> 

>> the next software.

>> 

>> Do not tell me it is a positively logical attitude,

>> 

>> please...

>> 

>> *Best regards*,

>> 

>> Alec

>> 

>> -----Original Message-----

>> From: DXLab@groups.io <DXLab@groups.io> On Behalf Of g4wjs

>> Sent: Wednesday, November 27, 2019 1:30 PM

>> To: DXLab@groups.io

>> Subject: Re: [DXLab] JJ00aa

>> 

>> On 27/11/2019 08:18, Alec SP2EWQ wrote:

>> 

>> > Hi,

>> 

>> >

>> 

>> > why, upon ADIF log/QSOs import,

>> 

>> > DXKeeper fills missing QRA locator data with false GRIDSQUARE

>> > JJ00aa,

>> 

>> > please?

>> 

>> >

>> 

>> > Best regards,

>> 

>> > Alec

>> 

>> Hi Alec,

>> 

>> that's the grid square at latitude zero and longitude zero, I suspect

>> your ADIF file is specifying those coordinates which is probably a

>> defect in whatever produced it.

>> 

>> --

>> 

>> 73

>> 

>> Bill

>> 

>> G4WJS.

>> 

>

>

>

>

>

 

 

Re: JJ00aa

Joe Subich, W4TV
 

However, even with the 'Deduce missing Items...' and 'Query callbook and DXCC database for missing Items' in the Import Options unclicked,
the JJ00aa is still being added
That means that your imported ADIF is defective - it contains bad
lat/lon data that should not be present. Contact the developer of
the application that is generating the ADIF file for a fix.

Given Lat/Lon in the ADIF, DXKeeper must treat it as valid. Computing
the grid square from *valid* lat/lon data is not a defect.

It also means one needs filter and modify the GRIDSQUARE on a constant basis if they cares.
No, it means that the user needs to contact the developer of the
application that generates the non-compliant ADIF file.

73,

... Joe, W4TV


On 2019-11-27 9:33 AM, Alec SP2EWQ wrote:
Joe,
thanks for the info and suggestion. I had successfully removed the bad GRIDSQUARE records.
However,
even with the 'Deduce missing Items...' and 'Query callbook and DXCC database for missing Items'
in the Import Options unclicked, the JJ00aa is still being added - so it does not obviously work,
or it is not the source of that apparent (to me) malfunction.
It also means one needs filter and modify the GRIDSQUARE on a constant basis if they cares.
Thanks again,
and best regards...
Alec
-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Joe Subich, W4TV
Sent: Wednesday, November 27, 2019 3:11 PM
To: DXLab@groups.io
Subject: Re: [DXLab] JJ00aa
The alternative explanation is that the user has checked "Query callbook and DXCC database for missing items" on import and the *callbook* is returning lat 0/lon 0 for some/all of the records.
In either case, this is not a DXKeeper error it is a case of bad data from an external source (original logging program or callbook).
The easiest way to "fix" the current problem is to:
1) *BACKUP THE DXKEEPER LOG*
2) Filter the log for GRIDSQUARE = "JJ00aa"
3) Use MODIFY QSOs in Log Page Display to set:
LAT = <blank>
LON = <blank>
GRIDSQUARE = <blank>
(note: <blank> for "new item value" is simply empty which clears
the existing data).
The long term solution is to modify the original log so it does not emit LAT 0/LON 0 or to clear the "Query callbook and DXCC database for missing items" depending on the original source of the problem.
73,
... Joe, W4TV

Re: DX Keeper

ND9G Mike
 

You probably have some missing/invalid data in a field within those panels for a QSO (or multiple QSOs). DXKeeper will automatically display those sub panels and identify the field that has missing/invalid data in red or blue.


 
73,
Mike ND9G


On Wed, Nov 27, 2019 at 9:53 AM Richard Wright <ki4p93@...> wrote:
on Dx keeper in config i have the buttons in the log window for log panels all unchecked, but most of time aux and qsl comes back checked in keeper, what am i missing
Thanks!

DX Keeper

Richard Wright
 

on Dx keeper in config i have the buttons in the log window for log panels all unchecked, but most of time aux and qsl comes back checked in keeper, what am i missing
Thanks!

Re: JJ00aa

Alec SP2EWQ <aleksander.otulak@...>
 

Joe,
thanks for the info and suggestion. I had successfully removed the bad GRIDSQUARE records.

However,
even with the 'Deduce missing Items...' and 'Query callbook and DXCC database for missing Items'
in the Import Options unclicked, the JJ00aa is still being added - so it does not obviously work,
or it is not the source of that apparent (to me) malfunction.

It also means one needs filter and modify the GRIDSQUARE on a constant basis if they cares.

Thanks again,
and best regards...

Alec

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Joe Subich, W4TV
Sent: Wednesday, November 27, 2019 3:11 PM
To: DXLab@groups.io
Subject: Re: [DXLab] JJ00aa


The alternative explanation is that the user has checked "Query callbook and DXCC database for missing items" on import and the *callbook* is returning lat 0/lon 0 for some/all of the records.

In either case, this is not a DXKeeper error it is a case of bad data from an external source (original logging program or callbook).

The easiest way to "fix" the current problem is to:

1) *BACKUP THE DXKEEPER LOG*
2) Filter the log for GRIDSQUARE = "JJ00aa"
3) Use MODIFY QSOs in Log Page Display to set:
LAT = <blank>
LON = <blank>
GRIDSQUARE = <blank>
(note: <blank> for "new item value" is simply empty which clears
the existing data).

The long term solution is to modify the original log so it does not emit LAT 0/LON 0 or to clear the "Query callbook and DXCC database for missing items" depending on the original source of the problem.

73,

... Joe, W4TV


On 2019-11-27 8:45 AM, g4wjs wrote:
Alec,

read my response again, more carefully this time. I did not imply that
your ADIF file specifies JJ00aa as a grid square, I suggested it
specifies a latitude and longitude of zero. DXKeeper would be
perfectly reasonable if it were to correctly interpret such
coordinates as being in grid square JJ00aa since that is exactly where they are located.

Why not provide us with an example record from your ADIF file that
ends up with a grid square JJ00aa?

On 27/11/2019 13:41, Alec SP2EWQ wrote:

*Hi*,

Negative - sorry...

GRIDSQUARE is NOT specified in the import file for those records

AT ALL.

Putting JJ00AA in that place is COMPLETELY UNREASONABLE

and KILLING all the rotating procedures for such records.

Even more,

if such records at a later date are exported outside DXLAB,

the completely INadequate GRIDQUARE information infects

the next software.

Do not tell me it is a positively logical attitude,

please...

*Best regards*,

Alec

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of g4wjs
Sent: Wednesday, November 27, 2019 1:30 PM
To: DXLab@groups.io
Subject: Re: [DXLab] JJ00aa

On 27/11/2019 08:18, Alec SP2EWQ wrote:

Hi,
why, upon ADIF log/QSOs import,
DXKeeper fills missing QRA locator data with false GRIDSQUARE
JJ00aa,
please?
Best regards,
Alec
Hi Alec,

that's the grid square at latitude zero and longitude zero, I suspect
your ADIF file is specifying those coordinates which is probably a
defect in whatever produced it.

--

73

Bill

G4WJS.



Re: JJ00aa

g4wjs
 

On 27/11/2019 14:16, Alec SP2EWQ wrote:
why don’t You just import a QSO record without a GRiDSQUARE into DXKeeper

Alec,

I assume you mean import without filling in a grid square. Well, given that grid squares are necessary for some awards, e.g. VUCC, it seems perfectly reasonable that given a lat/log coordinate, which should be considered accurate if provided and are uniquely attributable to a single grid square; that such a grid square be assigned.

I am still of the opinion that inaccurate coordinates are being provided, either in your ADIF source application, or as Joe, W4TV, suggests from an erroneous callbook service lookup. This is the real problem and your rant about the behaviour of DXKeeper in unwarranted. The adage "Garbage in, garbage out" is appropriate here.


--
73

Bill

G4WJS.

Re: DXK Log not remembering display panels on exit and load

wb6bee
 

I didn't know that you could do that.   Still not sure where you find the province in China.   

Regardless, I have gone through the list.    Most were a period in the County or Country Field.   

Upon completion, as noted herein. DXK is returning only the the panels I have check.

thanks for the input

Don
WB6BEE

Re: JJ00aa

Alec SP2EWQ <aleksander.otulak@...>
 

 

 

 

OK,

why don’t You just import a QSO record without a GRiDSQUARE into DXKeeper

(my suggestion is to use a G callsign for that purpose).

 

Will You be satisfied if Your rotor will point to the Gulf of Guinea

looking for Great Britain over there?

 

Anyway, thanks for sharing Your thoughts…

 

Best regards,

Alec

 

 

 

 

 

 

From: DXLab@groups.io <DXLab@groups.io> On Behalf Of g4wjs
Sent: Wednesday, November 27, 2019 2:46 PM
To: DXLab@groups.io
Subject: Re: [DXLab] JJ00aa

 

Alec,

 

read my response again, more carefully this time. I did not imply that your ADIF file specifies JJ00aa as a grid square, I suggested it specifies a latitude and longitude of zero. DXKeeper would be perfectly reasonable if it were to correctly interpret such coordinates as being in grid square JJ00aa since that is exactly where they are located.

 

Why not provide us with an example record from your ADIF file that ends up with a grid square JJ00aa?

 

On 27/11/2019 13:41, Alec SP2EWQ wrote:

Hi,

 

Negative - sorry...

GRIDSQUARE is NOT specified in the import file for those records

AT ALL.

 

Putting JJ00AA in that place is COMPLETELY UNREASONABLE

and KILLING all the rotating procedures for such records.

 

Even more,

if such records at a later date are exported outside DXLAB,

the completely INadequate GRIDQUARE information infects

the next software.

 

Do not tell me it is a positively logical attitude,

please...

 

 

Best regards,

Alec

 

 

 

 

 

 

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of g4wjs
Sent: Wednesday, November 27, 2019 1:30 PM
To: DXLab@groups.io
Subject: Re: [DXLab] JJ00aa

 

On 27/11/2019 08:18, Alec SP2EWQ wrote:

> Hi,

> why, upon ADIF log/QSOs import,

> DXKeeper fills missing QRA locator data with false GRIDSQUARE JJ00aa,

> please?

> Best regards,

> Alec

 

Hi Alec,

 

that's the grid square at latitude zero and longitude zero, I suspect your ADIF file is specifying those coordinates which is probably a defect in whatever produced it.

 

 

 

--

73

 

Bill

 

G4WJS.

 


--
73

Bill

G4WJS.

Re: DXK Log not remembering display panels on exit and load

g4wjs
 

On 27/11/2019 14:05, wb6bee wrote:
Actually, this is ridiculous.   I have hundreds of Broke QSOs where there is a period or double states in the Country Field.  A field I never put anything in.    This would take hours.

Don
Hi Don,

if you are not interested in the validity of secondary geopolitical entities in DXKeeper you can uncheck the "DXKeeper->Config->Awards->Other Awards->Subdivision validity checking". DXKeeper applies a high premium to the accuracy of logged information but you have option to adapt that to your preferences in cases like this.



--
73

Bill

G4WJS.

Re: JJ00aa

Joe Subich, W4TV
 

The alternative explanation is that the user has checked "Query callbook
and DXCC database for missing items" on import and the *callbook* is
returning lat 0/lon 0 for some/all of the records.

In either case, this is not a DXKeeper error it is a case of bad data
from an external source (original logging program or callbook).

The easiest way to "fix" the current problem is to:

1) *BACKUP THE DXKEEPER LOG*
2) Filter the log for GRIDSQUARE = "JJ00aa"
3) Use MODIFY QSOs in Log Page Display to set:
LAT = <blank>
LON = <blank>
GRIDSQUARE = <blank>
(note: <blank> for "new item value" is simply empty which clears
the existing data).

The long term solution is to modify the original log so it does not
emit LAT 0/LON 0 or to clear the "Query callbook and DXCC database
for missing items" depending on the original source of the problem.

73,

... Joe, W4TV

On 2019-11-27 8:45 AM, g4wjs wrote:
Alec,
read my response again, more carefully this time. I did not imply that your ADIF file specifies JJ00aa as a grid square, I suggested it specifies a latitude and longitude of zero. DXKeeper would be perfectly reasonable if it were to correctly interpret such coordinates as being in grid square JJ00aa since that is exactly where they are located.
Why not provide us with an example record from your ADIF file that ends up with a grid square JJ00aa?
On 27/11/2019 13:41, Alec SP2EWQ wrote:

*Hi*,

Negative - sorry...

GRIDSQUARE is NOT specified in the import file for those records

AT ALL.

Putting JJ00AA in that place is COMPLETELY UNREASONABLE

and KILLING all the rotating procedures for such records.

Even more,

if such records at a later date are exported outside DXLAB,

the completely INadequate GRIDQUARE information infects

the next software.

Do not tell me it is a positively logical attitude,

please...

*Best regards*,

Alec

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of g4wjs
Sent: Wednesday, November 27, 2019 1:30 PM
To: DXLab@groups.io
Subject: Re: [DXLab] JJ00aa

On 27/11/2019 08:18, Alec SP2EWQ wrote:

Hi,
why, upon ADIF log/QSOs import,
DXKeeper fills missing QRA locator data with false GRIDSQUARE JJ00aa,
please?
Best regards,
Alec
Hi Alec,

that's the grid square at latitude zero and longitude zero, I suspect your ADIF file is specifying those coordinates which is probably a defect in whatever produced it.

--

73

Bill

G4WJS.

Re: DXK Log not remembering display panels on exit and load

wb6bee
 

Actually, this is ridiculous.   I have hundreds of Broke QSOs where there is a period or double states in the Country Field.  A field I never put anything in.    This would take hours.

Don

Re: DXK Log not remembering display panels on exit and load

wb6bee
 

Broke seems to fine chinese contacts and the province is blinking.  I have no idea how to find what province they are in.  Plus that is on the AWard panel, not the AUX or QSL panel that seem to reappear.

Don

Re: DXK Log not remembering display panels on exit and load

wb6bee
 

One more oddity.    Using the capture window, I put in a call that I have worked before, hit clear and the log display goes back to the User panel only.   If I put in a call I haven't worked before and hit clear, it self adds the QSL and AUX panel.

I am checking the "broke" fields now.

Don

Re: DXK Log not remembering display panels on exit and load

Rod Greene
 

Forgot to add - To find the Broke record(s) click on the "Broke" log filter button at the bottom of the log display. The Broke record(s) will appear and you can edit them. -Rod

On Wednesday, November 27, 2019, 6:45:22 AM MST, Rod Greene via Groups.Io <w7zrc@...> wrote:


Same thing happened to me. Somewhere there's a Broke Logged QSO in your log that needs one or more fields corrected. A "Broke" QSO record will cause panels to appear so that it may be edited and corrected. When you have zero Broke records those panels will not appear unless they are checked.

GL and 73, Rod/w7zrc
~~~~~~~~~~~~~~~~~~~~~~~~~~
On Wednesday, November 27, 2019, 6:40:47 AM MST, wb6bee <wb6bee@...> wrote:


I set up my DXK log display to show Only the User Defined Panel.    I have only the User Defined Panel checked in the Configuration.    I exit DXK and when it returns, it has the QSL, AUX panel and the User Defined Panel display,   It completely changes the configuration on the monitor.   I check configuration and it has checked the QSL, AUX and the User Panels in Configuration, by itself.

Up until recently, it remembered it's display format and would load in the format that it exited.   

Cannot find the problem

Don
WB6BEE 



Re: DXK Log not remembering display panels on exit and load

DAVID BERNHEISEL
 

Check each of those panels for a flashing blue or red label.  DXK uses this to alert you to missing or invalid values in the field whose label is flashing.  If you find and correct the data, the extra panels will not display automatically.

73

Dave, N2DPF

On 11/27/2019 7:40 AM, wb6bee wrote:
I set up my DXK log display to show Only the User Defined Panel.    I have only the User Defined Panel checked in the Configuration.    I exit DXK and when it returns, it has the QSL, AUX panel and the User Defined Panel display,   It completely changes the configuration on the monitor.   I check configuration and it has checked the QSL, AUX and the User Panels in Configuration, by itself.

Up until recently, it remembered it's display format and would load in the format that it exited.   

Cannot find the problem

Don
WB6BEE 



Re: JJ00aa

g4wjs
 

Alec,

read my response again, more carefully this time. I did not imply that your ADIF file specifies JJ00aa as a grid square, I suggested it specifies a latitude and longitude of zero. DXKeeper would be perfectly reasonable if it were to correctly interpret such coordinates as being in grid square JJ00aa since that is exactly where they are located.

Why not provide us with an example record from your ADIF file that ends up with a grid square JJ00aa?

On 27/11/2019 13:41, Alec SP2EWQ wrote:

Hi,

 

Negative - sorry...

GRIDSQUARE is NOT specified in the import file for those records

AT ALL.

 

Putting JJ00AA in that place is COMPLETELY UNREASONABLE

and KILLING all the rotating procedures for such records.

 

Even more,

if such records at a later date are exported outside DXLAB,

the completely INadequate GRIDQUARE information infects

the next software.

 

Do not tell me it is a positively logical attitude,

please...

 

 

Best regards,

Alec

 

 

 

 

 

 

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of g4wjs
Sent: Wednesday, November 27, 2019 1:30 PM
To: DXLab@groups.io
Subject: Re: [DXLab] JJ00aa

 

On 27/11/2019 08:18, Alec SP2EWQ wrote:

> Hi,

> why, upon ADIF log/QSOs import,

> DXKeeper fills missing QRA locator data with false GRIDSQUARE JJ00aa,

> please?

> Best regards,

> Alec

 

Hi Alec,

 

that's the grid square at latitude zero and longitude zero, I suspect your ADIF file is specifying those coordinates which is probably a defect in whatever produced it.

 

 

 

--

73

 

Bill

 

G4WJS.



--
73

Bill

G4WJS.

Re: DXK Log not remembering display panels on exit and load

Rod Greene
 

Same thing happened to me. Somewhere there's a Broke Logged QSO in your log that needs one or more fields corrected. A "Broke" QSO record will cause panels to appear so that it may be edited and corrected. When you have zero Broke records those panels will not appear unless they are checked.

GL and 73, Rod/w7zrc
~~~~~~~~~~~~~~~~~~~~~~~~~~

On Wednesday, November 27, 2019, 6:40:47 AM MST, wb6bee <wb6bee@...> wrote:


I set up my DXK log display to show Only the User Defined Panel.    I have only the User Defined Panel checked in the Configuration.    I exit DXK and when it returns, it has the QSL, AUX panel and the User Defined Panel display,   It completely changes the configuration on the monitor.   I check configuration and it has checked the QSL, AUX and the User Panels in Configuration, by itself.

Up until recently, it remembered it's display format and would load in the format that it exited.   

Cannot find the problem

Don
WB6BEE 



Re: JJ00aa

Alec SP2EWQ <aleksander.otulak@...>
 

 

 

Hi,

 

Negative - sorry...

GRIDSQUARE is NOT specified in the import file for those records

AT ALL.

 

Putting JJ00AA in that place is COMPLETELY UNREASONABLE

and KILLING all the rotating procedures for such records.

 

Even more,

if such records at a later date are exported outside DXLAB,

the completely INadequate GRIDQUARE information infects

the next software.

 

Do not tell me it is a positively logical attitude,

please...

 

 

Best regards,

Alec

 

 

 

 

 

 

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of g4wjs
Sent: Wednesday, November 27, 2019 1:30 PM
To: DXLab@groups.io
Subject: Re: [DXLab] JJ00aa

 

On 27/11/2019 08:18, Alec SP2EWQ wrote:

> Hi,

> why, upon ADIF log/QSOs import,

> DXKeeper fills missing QRA locator data with false GRIDSQUARE JJ00aa,

> please?

> Best regards,

> Alec

 

Hi Alec,

 

that's the grid square at latitude zero and longitude zero, I suspect your ADIF file is specifying those coordinates which is probably a defect in whatever produced it.

 

 

 

--

73

 

Bill

 

G4WJS.