Date   
Re: After LOTW download by DXkeeper new DXCC confirmations not identified

Joe Subich, W4TV
 

Where would you suggest where I start to look?
With your "goals" in DXKeeper-> Config -> Awards.

Which awards, bands, modes are you pursuing?

73,

... Joe, W4TV


On 2019-12-06 10:35 AM, Ed wrote:
Hello,
Recently I've had this problem. For instance a new DXCC contact on 30M with Cypress was not indicated in the download summary. Where would you suggest where I start to look?
73,
Ed W2GHD

Re: Z6 to YU

Dave AA6YQ
 

+ AA6YQ comments below

You say that as referred to the example below ‘the recompute function made it consistent’?


Call Date Band Mode DXCC ID DXCC Entity Error, or Action

Z66DH 2018-12-17 0841 40M CW 296 Serbia Action: changed DXCC prefix from Z6 to YU

+ Exactly right. A DXCC Country Code of 296 specifies Serbia. Z6 is not the correct DXCC Prefix for Serbia. Changing the DXCC Prefix to YU makes the DXCC entity information in the QSO consistent.



OK, LOL, I do not care – let it be…

+ Lets review what happened, since you evidently still do not understand:

1. you have several QSOs in your log with Z66DH made after Kosovo became a DXCC entity

2. you ran the FIX-EU script, which prompted you to backup your log before proceeding

3. the FIX-EU script contains two defects with respect to QSOs with Z6 stations:

a. the script was not updated after Kosovo was became a DXCC entity; it changes a Z6 QSO's DXCC Country Code to 296 (Serbia), and marks it invalid for DXCC

b. the script changes a Z6 QSO's DXCC Country Code to 296 (Serbia), but does not change its DXCC Prefix to YU; this defect is what made your Z6 QSOs inconsistent as to DXCC entity

4. you invoked DXKeeper's Recompute function, which identified and corrected the inconsistencies in your logged Z6 QSOs, and notified you of its action


+ You have two options for correcting this situation:

A. revert to the log backup you created in step 2, and wait for Joe W4TV to release a corrected FIX-EU script

B. filter the Log Page Display to contain only your Z6 QSOs, and use the "Modify QSOs" panel to change their DXCC entity to Kosovo "en masse", as I've already suggested.

73,

Dave, AA6YQ

Re: Synchro revisited

Dave AA6YQ
 

+ AA6YQ comments below


the synchro error message quoted below refers to 'mode: MFSK' 'submode: FT4' QSOs

which (all of them) are in my DXKeeper log. Why the error message then?

+ The error message means that there is not an exact match between those 4 QSOs and any QSOs in your log.


Which of them carries priority - 'MODE' or 'SUBMODE' in case of eQSL synchronization?

+ An exact mode match is required. If a QSO partner reports MFSK for an FT4 QSO, that's not considered a match.

73,

Dave, AA6YQ


ADIF 3 Export from eQSL.cc

Received eQSLs for SP2EWQ QTH Nickname: Czersk-EWQ

for QSOs between 21-Jul-2008 and 01-Jan-2020 and uploaded on or after 05-Dec-2019 08:13Z

Generated on Friday, December 6, 2019 at 07:33:35 AM UTC

<PROGRAMID:21>eQSL.cc DownloadInBox

<ADIF_Ver:5>3.1.0



Date Time Call Band Mode Submode RST Error



2019-12-05 09:10 DG3YKW 40M MFSK -07 no QSO matching callsign, band, and mode

2019-12-05 09:39 EA3GIL 40M MFSK -09 no QSO matching callsign, band, and mode

2019-12-05 09:50 DL0FAF 40M MFSK +08 no QSO matching callsign, band, and mode

2019-12-05 16:38 F4EHB 40M MFSK 02 no QSO matching callsign, band, and mode





Best regards,

Alec








<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.
www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

Re: TS-480 Menu 17 and Spot Collector

Dave AA6YQ
 

+ AA6YQ comments below

After some experimentation with the TS-480 and how it works with Dxlabs, I found an interesting interaction. Menu item 17 permits the user to set an automatic mode depending on frequency. The default setting is LSB on frequencies below 9.5 MHz and USB above that frequency. The default for Menu 17 is OFF. Turning it on will override any mode command sent to the radio by Spot Collector. While the parameters for automatic mode can be changed by the user, with Menu 17 set to On, those settings will override the Spot Collector command to the rig. For those using the TS-480 with Spot Collector it is recommended leaving Menu 17 OFF.

+ Thanks, Don!

73,

Dave, AA6YQ

TS-480 Menu 17 and Spot Collector

Don Inbody AD0K
 

After some experimentation with the TS-480 and how it works with Dxlabs, I found an interesting interaction. Menu item 17 permits the user to set an automatic mode depending on frequency. The default setting is LSB on frequencies below 9.5 MHz and USB above that frequency. The default for Menu 17 is OFF. Turning it on will override any mode command sent to the radio by Spot Collector. While the parameters for automatic mode can be changed by the user, with Menu 17 set to On, those settings will override the Spot Collector command to the rig. For those using the TS-480 with Spot Collector it is recommended leaving Menu 17 OFF.

Re: Gerochron 4K

W0MU
 

Sorry for the necro.........gaming reference to bring back an old post.

I just got one of these for myself for Xmas 2019.  They are closing out the current model and coming out with a new version which the folks at the radio store feel is inferior or cheaper.  I would love to be able to show dx spots too.  Yes I understand that there are better tools for Dxing or contesting but this is a decorator piece.  $299 right now at HRO while they still have them.  I found a 50 inch toshiba on Amazon for around $250 with Fire and all the apps etc.  I would love to find a mechanical one for 50 bucks!  They are really cool. 

Re: auto logging from JT Alert

Bart AA7VA
 

James - as Dave says - it works perfectly. I suggest using JT Alert for its many benefits.  I just re-installed after a HD crash, and it worked perfect the first try, even checking the DX Keeper logs for previous contacts, which surprised me how fast it was with a SSD rather than the old tech spinning disk.

After LOTW download by DXkeeper new DXCC confirmations not identified

Ed
 

Hello,

Recently I've had this problem. For instance a new DXCC contact on 30M with Cypress was not indicated in the download summary. Where would you suggest where I start to look?

73,

Ed W2GHD

Re: Z6 to YU

Alec SP2EWQ <aleksander.otulak@...>
 

 

 

Dave,

 

You say that as referred to the example below ‘the recompute function made it consistent’?

 

Call              Date              Band     Mode        DXCC ID  DXCC Entity                        Error, or Action

Z66DH             2018-12-17 0841   40M      CW          296      Serbia                             Action: changed DXCC prefix from Z6 to YU

 

OK, LOL, I do not care – let it be…

The best I can do is unsubscribe, I do not want to participate in that anymore. Definitely…

 

Best regards,

Alec

 

 

 

 

 

From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave AA6YQ
Sent: Friday, December 6, 2019 10:55 AM
To: DXLab@groups.io
Subject: Re: [DXLab] Z6 to YU

 

+ AA6YQ comments below

On Fri, Dec 6, 2019 at 01:50 AM, Alec SP2EWQ wrote:

All these contacts are officially confirmed by LoTW as REPUBLIC of KOSOVO as

Z6 maps to REPUBLIC OF KOSOVO, using country code 522, with a start date of 2018-01-21 00:00:00’

Take the first callsign as an example (snippet from LoTW):

+ Correct - because they were all conducted after 2018-01-21.

+ Your Z6 QSOs were erroneously changed to a Country Code of 296 by the FIX-EU script that you ran. The script left them in an inconsistent state. The Recompute function correctly made them consistent.

               73,

                       Dave, AA6YQ

Re: Z6 to YU

Dave AA6YQ
 

+ AA6YQ comments below

On Fri, Dec 6, 2019 at 01:50 AM, Alec SP2EWQ wrote:

All these contacts are officially confirmed by LoTW as REPUBLIC of KOSOVO as

Z6 maps to REPUBLIC OF KOSOVO, using country code 522, with a start date of 2018-01-21 00:00:00’

Take the first callsign as an example (snippet from LoTW):

+ Correct - because they were all conducted after 2018-01-21.

+ Your Z6 QSOs were erroneously changed to a Country Code of 296 by the FIX-EU script that you ran. The script left them in an inconsistent state. The Recompute function correctly made them consistent.

               73,

                       Dave, AA6YQ

Re: Z6 to YU

Alec SP2EWQ <aleksander.otulak@...>
 

 

 

Dave,

 

All these contacts are officially confirmed by LoTW as REPUBLIC of KOSOVO as

Z6 maps to REPUBLIC OF KOSOVO, using country code 522, with a start date of 2018-01-21 00:00:00’

Take the first callsign as an example (snippet from LoTW):

 

 

SP2EWQ Recompute Actions Report 05-gru-2019

Call              Date              Band     Mode        DXCC ID  DXCC Entity                        Error, or Action

Z66DH             2018-12-17 0841   40M      CW          296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z66DH             2018-12-17 1048   30M      CW          296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z66DH             2018-12-17 0946   20M      SSB         296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z66DH             2018-12-18 0850   20M      SSB         296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z66DH             2018-12-18 0728   40M      SSB         296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z66DH             2018-12-17 2130   80M      SSB         296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z66DH             2018-12-18 1740   80M      CW          296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z66DH             2018-12-16 2238   160M     CW          296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z66DH             2018-12-11 1402   40M      FT8         296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z66DH             2018-12-19 1320   15M      SSB         296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z66DH             2018-12-19 1232   15M      CW          296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z66DH             2018-12-19 2128   160M     SSB         296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z66DH             2018-12-19 2042   20M      CW          296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z66X              2019-01-25 1536   80M      CW          296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z66X              2019-01-25 1533   160M     CW          296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z66X              2019-01-25 2317   160M     CW          296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z66X              2019-01-25 0807   30M      CW          296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z68M              2019-02-01 2042   80M      CW          296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z68M              2019-01-27 1906   160M     CW          296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z68M              2019-01-28 2246   160M     FT8         296      Serbia                             Action: changed DXCC prefix from Z6 to YU

Z68M              2019-01-28 0934   30M      CW          296      Serbia                             Action: changed DXCC prefix from Z6 to YU

 

 

AGAIN,

DXKeeper recomputation facility is ABSOLUTELY FAULTY in this respect.

 

Best regards,

Alec

 

 

 

 

 

From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave AA6YQ
Sent: Friday, December 6, 2019 9:01 AM
To: DXLab@groups.io
Subject: Re: [DXLab] Z6 to YU

 

+ AA6YQ comments below

On Thu, Dec 5, 2019 at 11:44 PM, Alec SP2EWQ wrote:

be serious, man - Z6 was NEVER Serbia.
Z6 has been either 'NOT VALID FOR DXCC' or 'KOSOVO'.

Read that
http://www.arrl.org/news/assigning-kosovo-z6-call-signs-unauthorized-and-illegal-itu-secretary-general-says
Quote
' “ITU has not allocated call sign series Z6 to any of its member states,” Houlin Zhou said. “Consequently, the utilization of call signs series Z6 by any entity without a formal allocation and consent of the ITU represents an unauthorized and illegal usage of this international numbering resource.”
Unquote

Repair that recomputing facility,
please...

+ Z6 callsigns used prior to January 21, 2018 were located in the Kosovo region of the DXCC entity of Serbia. Contacts made with Z6 callsigns prior to January 21, 2018 are not valid for DXCC; it is your responsibility to set the "QSL Rcvd" items of such callsigns to 'I'. Note that contacts with such callsigns prior to January 21, 2018 do count as the Kosovo region of Serbia for CQ awards.

+ A logged QSO that specifies a DXCC Country Code of 296 (Serbia) and a DXCC Prefix of Z6 is inconsistent, and therefore erroneous. DXKeeper's Recompute function will correctly repair such an inconsistency by changing the QSO's DXCC Prefix to be consistent with its Country Code - in this case, by setting the QSO's DXCC Prefix to YU (Serbia). Again, it is your responsibility to set the "QSL Rcvd" items of such callsigns to 'I', since they are invalid for DXCC.

       73,
  
                 Dave, AA6YQ

 

 

 

Synchro revisited

Alec SP2EWQ <aleksander.otulak@...>
 

 

 

Hi,

 

the synchro error message quoted below refers to ‘mode: MFSK’ ‘submode: FT4’ QSOs

which (all of them) are in my DXKeeper log. Why the error message then?

Which of them carries priority - ‘MODE’ or ‘SUBMODE’ in case of eQSL synchronization?

 

ADIF 3 Export from eQSL.cc

Received eQSLs for SP2EWQ  QTH Nickname: Czersk-EWQ

for QSOs between 21-Jul-2008 and 01-Jan-2020 and uploaded on or after 05-Dec-2019 08:13Z

Generated on Friday, December 6, 2019 at 07:33:35 AM UTC

<PROGRAMID:21>eQSL.cc DownloadInBox

<ADIF_Ver:5>3.1.0

 

        Date      Time           Call    Band      Mode           Submode           RST    Error

 

  2019-12-05  09:10            DG3YKW     40M      MFSK                             -07    no QSO matching callsign, band, and mode

  2019-12-05  09:39            EA3GIL     40M      MFSK                             -09    no QSO matching callsign, band, and mode

  2019-12-05  09:50            DL0FAF     40M      MFSK                             +08    no QSO matching callsign, band, and mode

  2019-12-05  16:38             F4EHB     40M      MFSK                              02    no QSO matching callsign, band, and mode

 

 

Best regards,

Alec

 

 

 

Re: Z6 to YU

Dave AA6YQ
 

+ AA6YQ comments below

On Thu, Dec 5, 2019 at 11:44 PM, Alec SP2EWQ wrote:
be serious, man - Z6 was NEVER Serbia.
Z6 has been either 'NOT VALID FOR DXCC' or 'KOSOVO'.

Read that
http://www.arrl.org/news/assigning-kosovo-z6-call-signs-unauthorized-and-illegal-itu-secretary-general-says
Quote
' “ITU has not allocated call sign series Z6 to any of its member states,” Houlin Zhou said. “Consequently, the utilization of call signs series Z6 by any entity without a formal allocation and consent of the ITU represents an unauthorized and illegal usage of this international numbering resource.”
Unquote

Repair that recomputing facility,
please...

+ Z6 callsigns used prior to January 21, 2018 were located in the Kosovo region of the DXCC entity of Serbia. Contacts made with Z6 callsigns prior to January 21, 2018 are not valid for DXCC; it is your responsibility to set the "QSL Rcvd" items of such callsigns to 'I'. Note that contacts with such callsigns prior to January 21, 2018 do count as the Kosovo region of Serbia for CQ awards.

+ A logged QSO that specifies a DXCC Country Code of 296 (Serbia) and a DXCC Prefix of Z6 is inconsistent, and therefore erroneous. DXKeeper's Recompute function will correctly repair such an inconsistency by changing the QSO's DXCC Prefix to be consistent with its Country Code - in this case, by setting the QSO's DXCC Prefix to YU (Serbia). Again, it is your responsibility to set the "QSL Rcvd" items of such callsigns to 'I', since they are invalid for DXCC.

       73,
  
                 Dave, AA6YQ

 

 

 

Re: Z6 to YU

Alec SP2EWQ <aleksander.otulak@...>
 

Dave,

be serious, man - Z6 was NEVER Serbia.
Z6 has been either 'NOT VALID FOR DXCC' or 'KOSOVO'.

Read that
http://www.arrl.org/news/assigning-kosovo-z6-call-signs-unauthorized-and-illegal-itu-secretary-general-says
Quote
' “ITU has not allocated call sign series Z6 to any of its member states,” Houlin Zhou said. “Consequently, the utilization of call signs series Z6 by any entity without a formal allocation and consent of the ITU represents an unauthorized and illegal usage of this international numbering resource.”
Unquote

Repair that recomputing facility,
please...

Best regards,
Alec

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave AA6YQ
Sent: Friday, December 6, 2019 12:34 AM
To: DXLab@groups.io
Subject: Re: [DXLab] Z6 to YU

The Recompute function's after action report is clear, Alec:

--------------------
Z66DH 2018-12-17 0841 40M CW 296 Serbia

Action: changed DXCC prefix from Z6 to YU
--------------------

DXCC Country Code is 296

DXCC Prefix was Z6

It looks like the root cause lies in the FIX-EU script, which was evidently not updated after Kosovo became a DXCC entity. Here's the relevant excerpt:

filter (QSO_Begin between #01-Sept-2012# and #31-Dec-3000#) and call like 'Z6*'
modify DXCCid 296
modify QSL_RCVD='I'
modify APP_DXKeeper_REGION='YU8'
modify QTH='Kosovo - NOT VALID FOR DXCC'

Note that this set of commands does not modify the QSO's "DXCC Prefix", so it's reasonable to expect it was Z6 -- as the Recompute report shows.

To confirm this diagnosis, check the QTH item in your Z66DH QSOs; is it set to

'Kosovo - NOT VALID FOR DXCC'

?

73,

Dave, AA6YQ

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Alec SP2EWQ
Sent: Thursday, December 05, 2019 6:03 PM
To: DXLab@groups.io
Subject: Re: [DXLab] Z6 to YU


Dave,

Negative to the presented logic.
I have first run the scripts checking/correcting possible DXCC inconsistencies.
Which of those four scripts corrected that to Z6 I cannot say.

Later on, recomputing changed it to Serbia. Of course the latter was wrong.
Those stations operated from Kosovo.

Best regards,
Alec




-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave AA6YQ
Sent: Thursday, December 5, 2019 11:01 PM
To: DXLab@groups.io
Subject: Re: [DXLab] Z6 to YU

+ AA6YQ comments below

after recomputing, I got such an action summary as below.
Is that action correct, please?

+ The QSOs listed below were logged with a DXCC Country Code of 296 (Serbia), but with a DXCC Prefix of Z6 (Kosovo). Those are inconsistent.

+ DXKeeper's Recompute function resolved these inconsistencies by changing the DXCC Prefix to match the Country Code. Why? Because DXCC Prefixes can change, but DXCC Country Codes are immutable.

+ IF Z66DH was operating from Kosovo rather than Serbia, then you should change each Z66DH QSO's DXCC Prefix to Z6, which will automatically change each Z66DH QSO's DXCC Country Code to 522. You can make this change "en masse" by filtering the Log Page Display to contain only your Z66DH QSOs, and then using the "Modify QSOs" panel at the bottom of the "Advanced Sorts, Filters, and Modifiers" window:

<https://www.dxlabsuite.com/dxlabwiki/QSOModifying>

+ Be sure to backup your log first, as recommended in the above instructions.

73,

Dave, AA6YQ




SP2EWQ Recompute Actions Report 05-gru-2019
Call Date Band Mode DXCC ID DXCC
Entity Error, or Action
Z66DH 2018-12-17 0841 40M CW 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z66DH 2018-12-17 1048 30M CW 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z66DH 2018-12-17 0946 20M SSB 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z66DH 2018-12-18 0850 20M SSB 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z66DH 2018-12-18 0728 40M SSB 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z66DH 2018-12-17 2130 80M SSB 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z66DH 2018-12-18 1740 80M CW 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z66DH 2018-12-16 2238 160M CW 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z66DH 2018-12-11 1402 40M FT8 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z66DH 2018-12-19 1320 15M SSB 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z66DH 2018-12-19 1232 15M CW 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z66DH 2018-12-19 2128 160M SSB 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z66DH 2018-12-19 2042 20M CW 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z66X 2019-01-25 1536 80M CW 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z66X 2019-01-25 1533 160M CW 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z66X 2019-01-25 2317 160M CW 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z66X 2019-01-25 0807 30M CW 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z68M 2019-02-01 2042 80M CW 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z68M 2019-01-27 1906 160M CW 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z68M 2019-01-28 2246 160M FT8 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Z68M 2019-01-28 0934 30M CW 296 Serbia
Action: changed DXCC prefix from Z6 to YU
Best regards,
Alec





<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>












--
This email has been checked for viruses by AVG.
https://www.avg.com

Re: SC Propagation Monitor Email Issue

Russ Ravella
 

Hi Dave,

Ok, that explains it. Thanks as always.

Russ, KR6W

On Dec 5, 2019, at 11:30 PM, Dave AA6YQ <@AA6YQ> wrote:

+ AA6YQ comments below

I put a test call in there that had not been spotted but has a strong FT8 signal here (K6AMS). I think I misunderstood that any call could be entered in anticipation of a possible QSO. Is it the case that the email reports the propagation of an entered call only if and when it is spotted? Otherwise blank?

+ SC's Propagation Monitor enables you to monitor actual propagation between a specified callsign and 8 regions of the world by reporting spots of that station every 30 minutes. If the callsign you specify isn't spotted during the past 30 minutes, the email message you receive will correctly be empty.

73,

Dave, AA6YQ




Re: SC Propagation Monitor Email Issue

Dave AA6YQ
 

+ AA6YQ comments below

I put a test call in there that had not been spotted but has a strong FT8 signal here (K6AMS). I think I misunderstood that any call could be entered in anticipation of a possible QSO. Is it the case that the email reports the propagation of an entered call only if and when it is spotted? Otherwise blank?

+ SC's Propagation Monitor enables you to monitor actual propagation between a specified callsign and 8 regions of the world by reporting spots of that station every 30 minutes. If the callsign you specify isn't spotted during the past 30 minutes, the email message you receive will correctly be empty.

73,

Dave, AA6YQ

Re: SC Propagation Monitor Email Issue

Russ Ravella
 

I put a test call in there that had not been spotted but has a strong FT8 signal here (K6AMS). I think I misunderstood that any call could be entered in anticipation of a possible QSO. Is it the case that the email reports the propagation of an entered call only if and when it is spotted? Otherwise blank?

Thanks, KR6W

On Dec 5, 2019, at 11:00 PM, Dave AA6YQ <@AA6YQ> wrote:

+ AA6YQ comments below

I'm trying SC's Station Propagation Monitor Email service. I successfully receive emails every 1/2 hour but the table area in them is blank. The row and column headers appear but there is nothing where the actual numbers should be, not even zeros.

I am able to obtain propagation predicts from PV no problem and every related function I can think of works perfectly, just no table in the email. I've tried my own call and others in the SC>Config>Email Alarm>Station Propagation Monitor panel "email" box to no avail. The panel is enabled. This is the first time I've tried to use this function so I have no previous history to report but everything else in DXL is humming along like a top as usual.

Might I have missed a setting somewhere? I've read the documentation before posting but I've certainly missed things before.

+ In the "Station Propagation Monitor" panel on the "Email Alarm" panel of SpotCollector's Configuration window, what Callsign have you specified? Has that Callsign been spotted?

73,

Dave, AA6YQ



Re: SC Propagation Monitor Email Issue

Dave AA6YQ
 

+ AA6YQ comments below

I'm trying SC's Station Propagation Monitor Email service. I successfully receive emails every 1/2 hour but the table area in them is blank. The row and column headers appear but there is nothing where the actual numbers should be, not even zeros.

I am able to obtain propagation predicts from PV no problem and every related function I can think of works perfectly, just no table in the email. I've tried my own call and others in the SC>Config>Email Alarm>Station Propagation Monitor panel "email" box to no avail. The panel is enabled. This is the first time I've tried to use this function so I have no previous history to report but everything else in DXL is humming along like a top as usual.

Might I have missed a setting somewhere? I've read the documentation before posting but I've certainly missed things before.

+ In the "Station Propagation Monitor" panel on the "Email Alarm" panel of SpotCollector's Configuration window, what Callsign have you specified? Has that Callsign been spotted?

73,

Dave, AA6YQ

SC Propagation Monitor Email Issue

Russ Ravella
 

Hi Dave,

I'm trying SC's Station Propagation Monitor Email service.  I successfully receive emails every 1/2 hour but the table area in them is blank.  The row and column headers appear but there is nothing where the actual numbers should be, not even zeros.

I am able to obtain propagation predicts from PV no problem and every related function I can think of works perfectly, just no table in the email.  I've tried my own call and others in the SC>Config>Email Alarm>Station Propagation Monitor panel "email" box to no avail.  The panel is enabled.  This is the first time I've tried to use this function so I have no previous history to report but everything else in DXL is humming along like a top as usual.

Might I have missed a setting somewhere?  I've read the documentation before posting but I've certainly missed things before.
Thanks,
Russ, KR6W

Re: FTDX101MP Commander Won't change rig frequency (Solved)

WZ6W
 

Thanks Dave and Igor!