Re: Inport non-ADIF to DxKeeper
Dave, Thanks I found it after I looker longer thanks for the help.
Russell NC5O.
__________________________________
Sent from eM Client | www.emclient.com <>
toggle quoted message
Show quoted text
------ Original Message ------ From: "Russell Blair via Groups.Io" <nc5opsk@...> To: DXLab@groups.io Sent: 2/27/2020 12:03:06 PM Subject: Re: [DXLab] Inport non-ADIF to DxKeeper Thanks Dave, I have looked in the program and didn't see any option to send file to ADIF for mat. ?
Russell NC5O
__________________________________
Sent from eM Client | www.emclient.com <>
------ Original Message ------
From: "Dave AA6YQ" <aa6yq@...>
To: DXLab@groups.io
Sent: 2/27/2020 11:43:25 AM
Subject: Re: [DXLab] Inport non-ADIF to DxKeeper
+ AA6YQ comments below
I use to MMTTY to do my RTTY contesting it's log non-ADIF for mat, so for me to use dxkeeper, how can I convert the log from mmtty to a log formt that will load in dxkeeper.?
+ MMTTY can be directed to export its log in ADIF format, which you can then import into DXKeeper. None of the other formats to which MMTTY can export are importable by DXKeeper.
73,
Dave, AA6YQ
|
Re: Inport non-ADIF to DxKeeper
Thanks Dave, I have looked in the program and didn't see any option to send file to ADIF for mat. ?
Russell NC5O
__________________________________
Sent from eM Client | www.emclient.com <>
toggle quoted message
Show quoted text
------ Original Message ------ From: "Dave AA6YQ" <aa6yq@...> To: DXLab@groups.io Sent: 2/27/2020 11:43:25 AM Subject: Re: [DXLab] Inport non-ADIF to DxKeeper + AA6YQ comments below
I use to MMTTY to do my RTTY contesting it's log non-ADIF for mat, so for me to use dxkeeper, how can I convert the log from mmtty to a log formt that will load in dxkeeper.?
+ MMTTY can be directed to export its log in ADIF format, which you can then import into DXKeeper. None of the other formats to which MMTTY can export are importable by DXKeeper.
73,
Dave, AA6YQ
|
Re: DXView's ""Populate override content from entity"
Thanks Dave,
very clear. Now I understand the background of the current mechanics.? I have honestly never noticed the grid source panel in SpotCollector's config? and not at all realized its all-or-nothing effect.
I also realize it is SpotCollector and not DXView that determines the reliability of a grid locator.? Thank you.
All this also makes me realize I was barking up the wrong tree. (Not the first time.)
What I found inconvenient was really the lack of sunset/sunrise data, not the lack of a grid locator.
So, starting over:?
Since DView generously provides approximated geographical distance and beam headings? for callsigns having an override but lacking a grid locator, would it be possible to also provide equally? approximate sunset/sunrise information when an override lacks exact geographical data?
Bj?rn SM7IUN
Den tors 27 feb. 2020 kl 02:59 skrev Dave AA6YQ < aa6yq@...>:
+ AA6YQ comments below
Although I understand what you are saying I struggle with the logic.
If I enter a random Swedish call in DXView, I get the grid locator of central Stockholm which of course is very wrong for e.g. my call. But close enough for all practical purposes (beam heading, sun info, spot plot) except of course VUCC. I believe everyone prefers this before getting an empty grid.
+ Correct.
If I enter a callsign which is in the override list and the override lacks a grid. I get an empty grid.
What is wrong with using the DXCC database lookup grid when the override lacks a grid, just as with random calls? Why is this a bad idea?
+ The long-standing description of an override's Grid field, dating back to the days of 16 fixed overrides, is
"the Maidenhead Grid Square from which the station is operating"
<>
+ Each Spot Database Entry contains a DXGridSource field that contains one of the following values
L - the gridsquare associated with the Latitude and Longitude specified in the Operator location panel
O - the gridsquare specified by an Override
S - a gridsquare extracted from a spot note or information appended to the spot by a Spot Source
U - the gridsquare determined by a USAP Database lookup
D - the gridsquare determined by a DXCC Database lookup
<>
+ Originally, a Spot Database Entry's "Grid Square" field was only considered valid for VUCC if the Entry's DXGridSource contained the letters L, O, or S.
+ At some point in the past, discussion here led me provide user control of this by adding the "Grid Sources for VUCC" panel to the General tab of SpotCollector's Configuration window. This panel provides you with the ability to determine whether Spot Database Entries whose DXGridSource fields contain O, S, or U should be considered reliable enough for VUCC need determination.
+ Note that these options are "all or nothing": if you uncheck the L box in the "Grid Sources for VUCC" panel because some of your overrides specify inaccurate grid squares, then all grid squares specified in Overrides will be ignored for VUCC need determination.
+ If you're pursuing VUCC, then each override of a station QRV on VHF or UHF should specify an accurate grid square so you can keep the "Grid Sources for VUCC" panel's Override box checked.
+ If you're not pursuing VUCC then you can uncheck the "Grid Sources for VUCC" panel's Override box; in this case, there's no reason to not populate an Override's grid square with an approximate location.
? ? ? ?73,
? ? ? ? ? ? ? ?Dave, AA6YQ
|
Re: Inport non-ADIF to DxKeeper
+ AA6YQ comments below
I use to MMTTY to do my RTTY contesting it's log non-ADIF for mat, so for me to use dxkeeper, how can I convert the log from mmtty to a log formt that will load in dxkeeper.?
+ MMTTY can be directed to export its log in ADIF format, which you can then import into DXKeeper. None of the other formats to which MMTTY can export are importable by DXKeeper.
73,
Dave, AA6YQ
|
Inport non-ADIF to DxKeeper
I use to MMTTY to do my RTTY contesting it's log non-ADIF for mat, so for me to use dxkeeper, how can I convert the log from mmtty to a log formt that will load in dxkeeper.?
Russell NC5O
__________________________________
Sent from eM Client | www.emclient.com <>
|
+ AA6YQ comments below
Where does that column get populated from? I'm doing direct cards, and I'm not checking the box direct, yet in the qsl que, they are all set to qsl direct? Thats a good thing, I think, so when the log gets updated, does that sent via get checked to a D? When I move to buro cards, what tells the que thats its sent via buro?
+ Every logged QSO includes a "Sent Via" item. This item is accessible in the QSL panel on the Main window's "Log QSOs" tab.
+ On the "QSL Configuration" window's General tab,
- the "Add Needed" panel provides checkboxes that set the "Sent Via" items of all QSOs added to the QSL Queue by the "Add Needed" function to B, D, or E
- the "Add Requested" panel provides checkboxes that set the "Sent Via" items of all QSOs added to the QSL Queue by the "Add Requested" function to B, D, or E
73,
Dave, AA6YQ
|
Where does that column get populated from? I'm doing direct cards, and I'm not checking the box direct, yet in the qsl que, they are all set to qsl direct? Thats a good thing, I think, so when the log gets updated, does that sent via get checked to a D? When I move to buro cards, what tells the que thats its sent via buro??
|
+ AA6YQ comments below
In my experience the spots are of no value.?? They don't spot active DX or they are complaining about the fact that the DX station is not there.?? I have an 11K badsource file and the majority of them are -@ call signs.?? If the options is there it would save the trouble of expanding the badsource file and if one choose not to use it there is no change to the current situation.
+ Thanks, George. Each new option added increases the perceived complexity for new users traversing the learning curve, but your and Iain N6ML's explanations justify adding the requested new option.
+ I have extended the next version of SpotCollector to provide a "Discard spots from spotting stations callsigns ending in -@" option on the Configuration window's "Special Callsign" tab, and sent it to you and Iain. Please let me know how it goes...
73,
Dave, AA6YQ
|
Re: DXKeeper Error Message on Startup
You have an obsolete CQWAE.txt file in your DXKeeper folder. I have emailed you a replacement.
73,
Dave, AA6YQ
toggle quoted message
Show quoted text
-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Hasan Schiers N0AN
Sent: Thursday, February 27, 2020 10:34 AM
To: DXLab@groups.io
Subject: [DXLab] DXKeeper Error Message on Startup
this is a *.png of the error message I'm getting.
Dave, (or anyone), please see this link to my google drive. It has a picture of the error screen that shows up every time I start DXKeeper.
"CQ-WAE award file (path snipped) contains an entry that does not specify the region's continent."
The reference file: CQWAE.txt contains:
1,206,4U1V,ITU Vienna,CQ,WAE
2,248,IG9/IH9,African Italy,CQ,NoWAE
3,248,IT9,Sicily,CQ,WAE
4,259,JW/B, Bear Island,CQ,WAE
5,279,GM/S,Shetland Islands,CQ,WAE
6,390,TA1,European Turkey,CQ,WAE
7,296,YU8,Kosovo,CQ,WAE
I did not (to my knowledge) edit this file or make any config changes to WAE. I haven't played with awards at all.
I'd attach it, but know you don't want attachments.
73, N0AN
Hasan
<> Virus-free. www.avg.com <>
|
DXKeeper Error Message on Startup
this is a *.png of the error message I'm getting.
Dave, (or anyone), please see this link to my google drive. It has a picture of the error screen that shows up every time I start DXKeeper.
"CQ-WAE award file (path snipped) contains an entry that does not specify the region's continent."
The reference file: CQWAE.txt contains:
1,206,4U1V,ITU Vienna,CQ,WAE
2,248,IG9/IH9,African Italy,CQ,NoWAE
3,248,IT9,Sicily,CQ,WAE
4,259,JW/B, Bear Island,CQ,WAE
5,279,GM/S,Shetland Islands,CQ,WAE
6,390,TA1,European Turkey,CQ,WAE
7,296,YU8,Kosovo,CQ,WAE
I did not (to my knowledge) edit this file or make any config changes to WAE.? I haven't played with awards at all.
I'd attach it, but know you don't want attachments. 73, N0AN
|
Re: Problem in downloading eQSL images
+ AA6YQ comments below
I (just) recently experienced problem in dowloading (just few, 5/6) eQSL images.
The following warning appears: "from eQSL.cc: PROCESSOR OVERLOAD - THROTTLING INVOKED -->"
I have the latest DxK (v. 15.4.3)
Something changed in the 15 second interval? Can i intervene (where ??) to extend the 15 seconds to lets say to 20?
+ The rate at eQSL images are downloaded from eQSL is as specified by eQSL. If this eQSL announces that this rate should be changed, I will change it.
73,
Dave, AA6YQ
|
Re: DXKeeper SFI, A, K logging and JTAlert issue
+ AA6YQ comments below
SFI data comes into JTAlert as part of the Band Activity data downloaded from HamSpots.net. The Band Activity display needs to be
enabled for SFI data to be automatically downloaded and to be available for logging
+ Thanks, Laurie!
+ The above information has been added as step 2.d in the JTAlert section of
<>
73,
Dave, AA6YQ
|
In my experience the spots are of no value.?? They don't spot active DX or they are complaining about the fact that the DX station is not there.?? I have an 11K badsource file and the majority of them are -@ call signs.?? If the options is there it would save the trouble of expanding the badsource file and if one choose not to use it there is no change to the current situation.
73, George
W2GS
toggle quoted message
Show quoted text
On 2/26/2020 7:17 PM, Dave AA6YQ wrote: + AA6YQ comments below
Can you do a global exclusion for all -@ calls like you do for -#?
+ What's the rationale for ignoring spots from DX Summit?
+ Skimmers generate spots in high volume; that's why the option to ignore them was provided.
73,
Dave, AA6YQ
|
Problem in downloading eQSL images
Hallo,
I (just) recently experienced problem in dowloading (just few, 5/6) eQSL images.
The following warning appears:?"from eQSL.cc: PROCESSOR OVERLOAD - THROTTLING INVOKED -->"
I have the latest DxK (v. 15.4.3)?
Something changed in the 15 second interval? Can i intervene (where ??) to extend the 15 seconds to lets say to 20?
Thanks
Carlo? IK2RPE
|
On Wed, Feb 26, 2020 at 5:17 PM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below
Can you do a global exclusion for all -@ calls like you do for -#?
+ What's the rationale for ignoring spots from DX Summit?
+ Skimmers generate spots in high volume; that's why the option to ignore them was provided.
Perhaps that spots submitted through a web interface are more likely to be illegitimate, since it's perceived to take less effort than setting up a cluster connection with a fake source callsign. 73, ~iain / N6ML
|
Re: Commander <-> Acom 2000S
Thanks Dave for your prompt reply.
Will continue to switch between the loops of the quad manually… but it’s a pity because Acom HW it’s very good.
?
73. A.Ma.
|
Re: DXKeeper SFI, A, K logging and JTAlert issue
? Under Alerts, there is the Quick Enable / Disable on alerts,? The Band Activity Display is checked, with a Green ON beside it.?? Not getting any SFI info with? logging.?? I've had 4 heart attacks, the first a widowmaker.? It's often weeks between when I get a reply, and am able to act on it.?? Really liked it working for the first few months, couple years ago.??? Back then JTAlert said we had to have the latest version of Fratework? file, but it would always abort when I tried updating it.? Recently able to get it to update, but still no SFI data.? Thank you for the note.
On 27/02/2020 2:37 pm, Stephen
Budensiek wrote:
I tried the JTAlert support group, they sent me
here.? Guess I'll keep filling it manually, I like to have that
data with qso in log.? 73's
There have been no recent posts on the HamApps
group regarding SFI data not being logged.
There are no messages waiting moderator approval.
I don't know where you posted your question, it definitely wasn't
on the HamApps group.
Who was it (name?, callsign?) that told you to come back here
without providing you an answer.
If you had posted to the HamApps group you would have gotten the
following authoritative answer...
SFI data comes into
JTAlert as part of the Band Activity data downloaded from
HamSpots.net. The Band Activity display needs to be enabled
for SFI data to be automatically downloaded and to be
available for logging
de Laurie VK3AMA
|
Re: DXKeeper SFI, A, K logging and JTAlert issue
On 27/02/2020 2:37 pm, Stephen
Budensiek wrote:
I tried the JTAlert support group, they sent me
here.? Guess I'll keep filling it manually, I like to have that
data with qso in log.? 73's
There have been no recent posts on the HamApps
group regarding SFI data not being logged.
There are no messages waiting moderator approval.
I don't know where you posted your question, it definitely wasn't
on the HamApps group.
Who was it (name?, callsign?) that told you to come back here
without providing you an answer.
If you had posted to the HamApps group you would have gotten the
following authoritative answer...
SFI data comes into
JTAlert as part of the Band Activity data downloaded from
HamSpots.net. The Band Activity display needs to be enabled
for SFI data to be automatically downloaded and to be
available for logging
de Laurie VK3AMA
|
Re: DXKeeper SFI, A, K logging and JTAlert issue
Dave, I tried the JTAlert support group, they sent me here.? Guess I'll keep filling it manually, I like to have that data with qso in log.? 73's
On Wed, Feb 26, 2020 at 3:22 PM Dave AA6YQ < aa6yq@...> wrote: + AA6YQ comments below
Hello all.? I use WSJT-X 2.1.2 and JTAlert 2.15.10 for FT8.? I have the box checked in JTAlert, Logging to fill the SFI, A, and K boxes in DXKeeper 15.4.3.? When I first started this a couple years ago, it would fill in automatically.? With one of the upgrades of JTAlert, it quit doing so.? I have the latest updates for WSJT-X, JTAlert, the current Netframe edition 4.7.2, and am running Win7 Professional 32 bit, all updates.? Does this feature not work anymore, or what am I missing?
+ Unless someone more familiar with JTAlert than me responds here, I suggest that you post your question on the JTAlert Support group:
<>
? ? ? ? ?73,
? ? ? ? ? ? ? ?Dave, AA6YQ
|
Re: DXView's ""Populate override content from entity"
+ AA6YQ comments below
Although I understand what you are saying I struggle with the logic.
If I enter a random Swedish call in DXView, I get the grid locator of central Stockholm which of course is very wrong for e.g. my call. But close enough for all practical purposes (beam heading, sun info, spot plot) except of course VUCC. I believe everyone prefers this before getting an empty grid.
+ Correct.
If I enter a callsign which is in the override list and the override lacks a grid. I get an empty grid.
What is wrong with using the DXCC database lookup grid when the override lacks a grid, just as with random calls? Why is this a bad idea?
+ The long-standing description of an override's Grid field, dating back to the days of 16 fixed overrides, is
"the Maidenhead Grid Square from which the station is operating"
<>
+ Each Spot Database Entry contains a DXGridSource field that contains one of the following values
L - the gridsquare associated with the Latitude and Longitude specified in the Operator location panel
O - the gridsquare specified by an Override
S - a gridsquare extracted from a spot note or information appended to the spot by a Spot Source
U - the gridsquare determined by a USAP Database lookup
D - the gridsquare determined by a DXCC Database lookup
<>
+ Originally, a Spot Database Entry's "Grid Square" field was only considered valid for VUCC if the Entry's DXGridSource contained the letters L, O, or S.
+ At some point in the past, discussion here led me provide user control of this by adding the "Grid Sources for VUCC" panel to the General tab of SpotCollector's Configuration window. This panel provides you with the ability to determine whether Spot Database Entries whose DXGridSource fields contain O, S, or U should be considered reliable enough for VUCC need determination.
+ Note that these options are "all or nothing": if you uncheck the L box in the "Grid Sources for VUCC" panel because some of your overrides specify inaccurate grid squares, then all grid squares specified in Overrides will be ignored for VUCC need determination.
+ If you're pursuing VUCC, then each override of a station QRV on VHF or UHF should specify an accurate grid square so you can keep the "Grid Sources for VUCC" panel's Override box checked.
+ If you're not pursuing VUCC then you can uncheck the "Grid Sources for VUCC" panel's Override box; in this case, there's no reason to not populate an Override's grid square with an approximate location.
73,
Dave, AA6YQ
|
Bj?rn SM7IUN
iain macdonnell