> 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

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

+ 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

+ 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