+ AA6YQ comments below

My point is that DXView is providing beam heading and distance for callsigns with an override but no grid specified. Obviously using an approximate location.

I don't see the harm in using the same exact mechanics also for sunset/sunrise information.

Currently the Sun information panel is blank if a grid is not explicitly specified.

+ Bj?rn, I've sent you a new version of DXView that determines the location of a callsign whose override doesn't specify a grid square by using the DXCC entity specified in the override to query the USAP and DXCC databases. This change does not alter the way SpotCollector determines an active station's grid square.

+ Please let me know how it goes.

? ? ? ? 73,

? ? ? ? ? ? ? Dave, AA6YQ

I would suggest you start here:
That gives you some common culprits to slow operation of the DX Labs applications. There are also some good steps to take to locate the issue.
73,
Mike ND9G
On Thu, Feb 27, 2020 at 4:18 PM Bob Main <bobmain1@... <mailto:bobmain1@...>> wrote:
I finally got the nerve and moved to Windows 10 from Windows 7 back
in January.? The changeover with more smoothly than I expected, but
I had some issues, mostly between the ears, concerning how Windows
10 worked.? It took a couple days but all is working.? The only
thing that I am finding are the programs are taking a while to
start, at least longer than with Windows 7.? For example DXView is
taking 35 seconds and I don’t think it took that long before.? I
know this has been discussed before and there is also probably
something in the DXLAb help file, but I am not getting any hits from
my searches.? I know this has something to do with the search
criteria that I am entering and discovered over the years that
without proper terminology the search produces nothing.? I have
already looked at the two articles that come up when I do a search
for “Windows 10” and followed those directions right after the
install.? Can anybody give me some clues how to do the search so
that I can get on the right track?____
__ __
For what it is worth I have been using DXLabs for the last 14 years,
only big problem I have ever had was when I attempted to install the
programs to use F8 with WinWarbler.? I followed the directions in
the help file Never had any luck and found that those two programs
“broke” what I actually had working in WinWarbler and finally
deleted those programs and when I couldn’t figure out what was
messed up in WinWarbler I deleted that too.? What was so bad was
that I used to be able to do RTTY and PSK and using it and had
finally gotten everything working again.? Then I installed the two
programs and everything went south, but that is another problem. Looking at the Windows 10 thing first.____
__ __
Thanks in advance.____
__ __
73, Bob KB4CL____

?

I finally got the nerve and moved to Windows 10 from Windows 7 back in January.? The changeover with more smoothly than I expected, but I had some issues, mostly between the ears, concerning how Windows 10 worked.? It took a couple days but all is working.? The only thing that I am finding are the programs are taking a while to start, at least longer than with Windows 7.? For example DXView is taking 35 seconds and I don’t think it took that long before. ?I know this has been discussed before and there is also probably something in the DXLAb help file, but I am not getting any hits from my searches.? I know this has something to do with the search criteria that I am entering and discovered over the years that without proper terminology the search produces nothing.? I have already looked at the two articles that come up when I do a search for “Windows 10” and followed those directions right after the install.? Can anybody give me some clues how to do the search so that I can get on the right track?

?

For what it is worth I have been using DXLabs for the last 14 years, only big problem I have ever had was when I attempted to install the programs to use F8 with WinWarbler. ?I followed the directions in the help file Never had any luck and found that those two programs “broke” what I actually had working in WinWarbler and finally deleted those programs and when I couldn’t figure out what was messed up in WinWarbler I deleted that too.? What was so bad was that I used to be able to do RTTY and PSK and using it and had finally gotten everything working again.? Then I installed the two programs and everything went south, but that is another problem.? Looking at the Windows 10 thing first.

?

Thanks in advance.

?

73, Bob KB4CL

From: [email protected] [mailto:[email protected]] On Behalf Of ND9G Mike
Sent: Thursday, February 27, 2020 5:42 PM
To: [email protected]
Subject: Re: [DXLab] Slow Startup of Apps in Windows 10

?

?

From: [email protected] [mailto:[email protected]] On Behalf Of Chuck, WS1L
Sent: Thursday, February 27, 2020 5:36 PM
To: [email protected]
Subject: Re: [DXLab] Slow Startup of Apps in Windows 10

?

?

--

> 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?
Again, DXView provides an approximate location which is used for
beam headings, sunrise/sunset, Lat/Lon for each entry in the DXCC
Database.? By creating an override, you are explicitly telling
DXView that the information in the DXCC Database is not accurate
for the callsign being overridden.

Once you tell DXView that the DXCC Database information is not to be
used, it is up to you to provide the information you want to use.
Make your decision ... if beam heading and SR/SS are important to
you, provide an approximate grid square when you create the override.
VP8PJ has the information on their home page:? IOTA AN-008, Grid:
GC79eh.? It takes a minute to find that on the web and less time than
that to enter into (update) the override.

73,

? ? ... Joe, W4TV


On 2020-02-27 12:52 PM, Bj?rn Ekelund, SM7IUN wrote:
> 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
>>

+ 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

From the MMTTY Help file (on the log page)

Export the Log

Use the mouse cursor to select a subset of the log, then click File |
Export selected range to save the outlined entries in text, ADIF,
Log200, TurboHAMLOG formats, or Cabrillo formats. The ADIF format is
widely used to exchange data among contest and log programs.

73,

... Joe, W4TV


On 2020-02-27 1:03 PM, Russell Blair wrote:

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: [email protected]
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