Date   
Re: Needed not being colored in WSJTX

Dave AA6YQ
 

+ AA6YQ comments below

It is green and it is the only source I am using. All others are Red.

+ Thanks. Please do the following:

1. On the General tab of SpotCollector's Configuration window, check the "Log debugging info" box

2. Terminate SpotCollector

3. Start SpotCollector

4. After SpotCollector has initialized and 3 or 4 new Spot Database Entries have been created with new callsigns reported by WSJT-X,

4a. On the General tab of SpotCollector's Configuration window, check the "Log debugging info" box

4b. Attach the errorlog.txt file from your SpotCollector folder to an email message, and send that message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ

Re: Needed not being colored in WSJTX

Gilbert Baron W0MN
 

It is green and it is the only source I am using. All others are Red.

Outlook Desktop Gil W0MN
Hierro Candente Batir de Repente
44.08226 N 92.51265 W EN34rb

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave AA6YQ
Sent: Wednesday, January 22, 2020 20:15
To: DXLab@groups.io
Subject: Re: [DXLab] Needed not being colored in WSJTX

+ AA6YQ comments below

I can make QSOes and SC is using WSJTX as the spot source so they must be connected.

It is just coloring that is not working.

+ In the "Spot source status" panel at the top of SpotCollector's Main window, what color is the right-most circular indicator?

73,

Dave, AA6YQ







--
W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop

Re: Needed not being colored in WSJTX

Dave AA6YQ
 

+ AA6YQ comments below

I can make QSOes and SC is using WSJTX as the spot source so they must be connected.

It is just coloring that is not working.

+ In the "Spot source status" panel at the top of SpotCollector's Main window, what color is the right-most circular indicator?

73,

Dave, AA6YQ

Re: Needed not being colored in WSJTX

Gilbert Baron W0MN
 

NO, but that is because nothing works there. It is safe mode and it is networking because I can use the browser. Everything is working there. It thinks I am trying to use COM ports rather than Commander. It asks for reconfiguration and I also have 2 monitors and everything is like starting over again. I did do reboot and it still does not do the coloring. Every other thing is working fine.

 

I can make QSOes and SC is using WSJTX as the spot source so they must be connected.

It is just coloring that is not working.

 

I may have to just watch SC to determine who to call and live with that. It is not that big of a feature if I have SC on another screen. In any case clicking on something in SC sets up the messages but it does not enable TX so I have to do two things anyway. I might as well live with just clicking on the messages in the decode monitor.

 

I am confused as to what happened but have spent over 8 hours today playing with it and have not found the answer.

 

Outlook Desktop Gil W0MN

Hierro Candente Batir de Repente

44.08226 N 92.51265 W EN34rb

 

From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave AA6YQ
Sent: Wednesday, January 22, 2020 18:37
To: DXLab@groups.io
Subject: Re: [DXLab] Needed not being colored in WSJTX

 

+ AA6YQ comments below

On Wed, Jan 22, 2020 at 03:22 PM, Gilbert Baron W0MN wrote:

It was working and suddenly it is not.

The needed spots are colored in Spot Collector but even though these spots are displayed in WSJTX and WSJTX was the spot source they remain black on the WSJTX display. I went carefully though the settings called for in the Wiki but it simply is not displaying. Everything else is working. I can make QSOs and can see the needed in SC but not on the WSJTX window.

+ Please reboot Windows into "safe mode with networking", and then start SpotCollector and WSJT-X. Are the callsigns in WSJT-X properly colored?

    73,

          Dave, AA6YQ

 


--

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop

Re: Needed not being colored in WSJTX

Dave AA6YQ
 

+ AA6YQ comments below

On Wed, Jan 22, 2020 at 03:22 PM, Gilbert Baron W0MN wrote:

It was working and suddenly it is not.

The needed spots are colored in Spot Collector but even though these spots are displayed in WSJTX and WSJTX was the spot source they remain black on the WSJTX display. I went carefully though the settings called for in the Wiki but it simply is not displaying. Everything else is working. I can make QSOs and can see the needed in SC but not on the WSJTX window.

+ Please reboot Windows into "safe mode with networking", and then start SpotCollector and WSJT-X. Are the callsigns in WSJT-X properly colored?

    73,

          Dave, AA6YQ

 

Needed not being colored in WSJTX

Gilbert Baron W0MN
 

It was working and suddenly it is not.

The needed spots are colored in Spot Collector but even though these spots are displayed in WSJTX and WSJTX was the spot source they remain black on the WSJTX display. I went carefully though the settings called for in the Wiki but it simply is not displaying. Everything else is working. I can make QSOs and can see the needed in SC but not on the WSJTX window.

 

Outlook Desktop Gil W0MN

Hierro Candente Batir de Repente

44.08226 N 92.51265 W EN34rb

 


--

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop

Re: More Filtering Spot Collector

Dave AA6YQ
 

The information below is now available in

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

73,

Dave, AA6YQ

I was using these examples to make some filters for states. But when looking at the Primary field in SC there are no entries. How
does SC know what state a spotted call is in?

+ DXKeeper's USAP database provides the US State of every callsign
+ issued by the US Federal Communications Commission. If you have
this database installed (check the Databases tab of DXView's Configuration window) , then enabling the "Lookup missing location
info" option in the General panel on the General tab of SpotCollector's Configuration window will cause SpotCollector to query the
USAP database for the state of US callsigns, and populate the Spot Database's Primary field with the resulting information.

Re: More Filtering Spot Collector

Dave AA6YQ
 

+ AA6YQ comments below

I was using these examples to make some filters for states. But when looking at the Primary field in SC there are no entries. How
does SC know what state a spotted call is in?

+ DXKeeper's USAP database provides the US State of every callsign issued by the US Federal Communications Commission. If you have
this database installed (check the Databases tab of DXView's Configuration window) , then enabling the "Lookup missing location
info" option in the General panel on the General tab of SpotCollector's Configuration window will cause SpotCollector to query the
USAP database for the state of US callsigns, and populate the Spot Database's Primary field with the resulting information.

73,

Dave, AA6YQ

Re: More Filtering Spot Collector

Ron KU7Y
 

Hi Dave,

I was using these examples to make some filters for states. But when looking
at the Primary field in SC there are no entries. How does SC know what state
a spotted call is in?

Thanks,

OK, back in my hole,

Ron, KU7Y
Mountain Home, ID DN23dc
CW Ops #1211
SKCC #4904
QRP ARCI #8829
SOC #2
Idaho DX Association
Ron@...

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dave AA6YQ
Sent: Wednesday, January 22, 2020 12:53 PM
To: DXLab@groups.io
Subject: Re: [DXLab] More Filtering Spot Collector

+ AA6YQ comments below

Now,, you sent me the string to filter say vermont

(DXCCPrefix='K') and (Primary='VT')

Now what would i do to make it multiple like for the up coming QSO
parties.

VT, MN, BC,(canada)

+ Use this SQL expression to filter the Spot Database Display:

((DXCCPrefix='K') and (Primary in ('MN','VT'))) or ((DXCCPrefix='VE')
and (Primary='BC'))

+ If you make the Primary field visible in the Spot Database Display,
you'll quickly be able to see each station's state or
province; see

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

73,

Dave, AA6YQ





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

Re: More Filtering Spot Collector

Dave AA6YQ
 

+ AA6YQ comments below

Now,, you sent me the string to filter say vermont

(DXCCPrefix='K') and (Primary='VT')

Now what would i do to make it multiple like for the up coming QSO parties.

VT, MN, BC,(canada)

+ Use this SQL expression to filter the Spot Database Display:

((DXCCPrefix='K') and (Primary in ('MN','VT'))) or ((DXCCPrefix='VE') and (Primary='BC'))

+ If you make the Primary field visible in the Spot Database Display, you'll quickly be able to see each station's state or
province; see

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

73,

Dave, AA6YQ

More Filtering Spot Collector

Joe WB9SBD
 

Subject: Re: [DXLab] More Filtering Spot Collector

YOU ARE AWESOME DAVE!
Now,, you sent me the string to filter say vermont


(DXCCPrefix='K') and (Primary='VT')

Now what would i do to make it multiple like for the up coming QSO parties.

VT, MN, BC,(canada)

Joe

Re: commander and win4icom

Dave AA6YQ
 

+ AA6YQ comments below

How does commander and wsjt cat commands get arbitrated?

+ When the Rig selector is set to "DXLab Suite Commander" on the Radio tab of the WSJT-X Settings window, as described in step 4a of the "Installing and Configuring WSJT-X" section of

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

+ WSJT-X accomplishes transceiver control by sending directives to Commander via TCP.

Might be better to connect wsjt to commander to avoid cat command contention and collisions.

Dave told me a port splitter to connect wsjt and Commander is as an invalid configuration as both try to issue cat commands.

Connecting wsjt to commander calories Commander to issue cat commands on behalf on Commander AND wsjt.

+ Win4Icom is not an unintelligent "port splitter". It internally creates a virtual Icom transceiver for each client application. A separate process keeps the virtual transceivers in sync with the physical transceiver. Implemented correctly, this approach is reliable; Commander's Secondary CAT port works in the same manner, as does the TCP and UDP access Commander provides. As previously noted, Win4Icom does not provide its clients with the ability to track CW speed, or the ability to obtain Spectrum-Waterfall data from the physical transceiver.

+ There is no need to use Win4Icom in order to run WSJT-X with DXLab; Commander's TCP API provides the necessary functionality for reliable interoperation.

73,

Dave, AA6YQ

Re: monitor 60M for new DXCC

Dave AA6YQ
 

+ AA6YQ comments below

So how can some poeple have worked 200 countries ?...

+ I don't know. There are multiple possibilities.

73,

Dave, AA6YQ


Le 17/01/2020 � 08:49, Dave AA6YQ a �crit�:

Summary of 60m band allocations shown in

<https://en.wikipedia.org/wiki/60-meter_band#Band_allocations>

12 countries provide allocations of 50 kHz or more

1 country provides an allocation of 30 kHz

47 countries provide an allocation of 15 kHz

1 country provides an allocation of 12 kHz

73,

Dave, AA6YQ



-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dave AA6YQ
Sent: Friday, January 17, 2020 2:40 AM
To: DXLab@groups.io
Subject: Re: [DXLab] monitor 60M for new DXCC

* more AA6YQ comments below

On Thu, Jan 16, 2020 at 10:43 PM Dave AA6YQ <@AA6YQ> wrote:
+ AA6YQ comments below

On Thu, Jan 16, 2020 at 09:56 PM, Barry Murrell ZS2EZ wrote:

Even here in ZS (which is not known for quick response to allocations and changes) we have long been allocated 5350-5450 for our 60m band. This is sufficient for decent DXing

+ I agree, Barry, 100 kHz is sufficient for DXing.

+ If anyone has (or can point at) "60m amateur frequency allocations by region" information, please post it here. Thanks!
There's this:

https://en.wikipedia.org/wiki/60-meter_band#Band_allocations

Not sure of accuracy, but it looks fairly comprehensive.....

* Thanks, Ian. That article shows 61 countries with band allocations for 60m . Of those 61, only 12 allocate 50 kHz or more:

5060 5450 390 Somalia
5250 5450 200 Bulgaria
5250 5450 200 Denmark
5250 5450 200 Greenland
5250 5450 200 Grenada
5250 5450 200 Samoa
5250 5450 200 Trinidad & Tobago
5275 5450 175 Kenya
5250 5400 150 Barbados
5260 5410 150 Norway
5350 5450 100 South Africa
5250 5310 60 Bangladesh

73,

Dave, AA6YQ





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

Re: commander and win4icom

Dave AA6YQ
 

+ AA6YQ comments below

Yes I am and it works well. The advantages are that with the virtual com ports I can have Commander, Bandmaster, WSJT, FLDigi and MMTY etc all connected at the same time.

+ DXLab interoperates with WSJT, Fldigi (via the free FLDigi-DXLab gateway) and MMTTY without the use of Win4Icom. BandMaster provides a small subset of SpotCollector's and Commander's capabilities.

73,

Dave, AA6YQ

Re: commander and win4icom

Bill Pence
 

How does commander and wsjt  cat commands get arbitrated?
Might be better to connect wsjt to commander to avoid cat command contention and collisions.
Dave told me a port splitter to connect wsjt and Commander is as an invalid configuration as both try to issue cat commands.

Connecting wsjt to commander calories Commander to issue cat commands on behalf on Commander AND wsjt.


On Wed, Jan 22, 2020, 11:46 AM Mark Robinson <markrob@...> wrote:
Yes I am and it works well.  The advantages are that with the virtual com ports I can have Commander, Bandmaster,  WSJT, FLDigi and MMTY etc all connected at the same time.

Mark N1UK

On 21-Jan-20 4:13 PM, Jamie WW3S wrote:
anyone using the 2 together? advantages of running win4icom with commander? 

Re: monitor 60M for new DXCC

Paul F6EXV <f6exv@...>
 

So how can some poeple have worked 200 countries ?...

Le 17/01/2020 à 08:49, Dave AA6YQ a écrit :
Summary of 60m band allocations shown in

<https://en.wikipedia.org/wiki/60-meter_band#Band_allocations>

12 countries provide allocations of 50 kHz or more

1 country provides an allocation of 30 kHz

47 countries provide an allocation of 15 kHz

1 country provides an allocation of 12 kHz

73,

Dave, AA6YQ



-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dave AA6YQ
Sent: Friday, January 17, 2020 2:40 AM
To: DXLab@groups.io
Subject: Re: [DXLab] monitor 60M for new DXCC

* more AA6YQ comments below

On Thu, Jan 16, 2020 at 10:43 PM Dave AA6YQ <@AA6YQ> wrote:
+ AA6YQ comments below

On Thu, Jan 16, 2020 at 09:56 PM, Barry Murrell ZS2EZ wrote:

Even here in ZS (which is not known for quick response to allocations and changes) we have long been allocated 5350-5450 for our 60m band. This is sufficient for decent DXing

+ I agree, Barry, 100 kHz is sufficient for DXing.

+ If anyone has (or can point at) "60m amateur frequency allocations by region" information, please post it here. Thanks!
There's this:

https://en.wikipedia.org/wiki/60-meter_band#Band_allocations

Not sure of accuracy, but it looks fairly comprehensive.....

* Thanks, Ian. That article shows 61 countries with band allocations for 60m . Of those 61, only 12 allocate 50 kHz or more:

5060 5450 390 Somalia
5250 5450 200 Bulgaria
5250 5450 200 Denmark
5250 5450 200 Greenland
5250 5450 200 Grenada
5250 5450 200 Samoa
5250 5450 200 Trinidad & Tobago
5275 5450 175 Kenya
5250 5400 150 Barbados
5260 5410 150 Norway
5350 5450 100 South Africa
5250 5310 60 Bangladesh

73,

Dave, AA6YQ





Re: commander and win4icom

Mark Robinson
 

Yes I am and it works well.  The advantages are that with the virtual com ports I can have Commander, Bandmaster,  WSJT, FLDigi and MMTY etc all connected at the same time.

Mark N1UK

On 21-Jan-20 4:13 PM, Jamie WW3S wrote:
anyone using the 2 together? advantages of running win4icom with commander? 

Re: JARL progress reports

Carlo - IK2RPE
 

Thank you Dave,
Glad for giving you the opportunity to further improve Wiki. 

73

Carlo 

Il mer 22 gen 2020, 03:53 Dave AA6YQ <aa6yq@...> ha scritto:
+ AA6YQ comments below

Thank you so much for the detailed explanation. Everything is now perfectly clear to me.

+ Good! Information from the post below is now available via

<https://www.dxlabsuite.com/dxlabwiki/TrackingJCCJCGAwards.

    73,

            Dave, AA6YQ


-----Messaggio originale-----
Da: DXLab@groups.io <DXLab@groups.io> Per conto di Dave AA6YQ
Inviato: luned� 20 gennaio 2020 19:48
A: DXLab@groups.io
Oggetto: Re: [DXLab] JARL progress reports

+ AA6YQ comments below

I was in the process of controlling/updating my two possible Japanese Awards, JCC and JCG and I have a couple of questions regarding the �JARL progress reports� in DxKeeper.

JCC (for Cities) has references composed by 4 numbers (plus, in few cases, 6 numbers), JCG (for Guns) by 5 numbers (always).

JCC and JCG are not **overlapping** each other and are designating completely **independent** areas.


In �DxKeeper/Log QSOs/Award for Japanese calls� there is a field �prefecture� and another one �city/gun�.

Easy to insert the JCG Guns putting in �prefecture� the first two numbers and then chose in �city/gun� the proper reference.

For JCC how to proceed? Not taking into consideration �prefecture� and only indicate the 4 (or 6) numbers in �city/gun�?

+ If a logged QSO with a Japanese stations specifies a prefecture, the Subdivision selector will be populated with all cities and guns within that prefecture. Choose the one specified by your QSO partner over the air, or on his or her QSL card.


And then the reports are properly extracting, separately, only JCC or JCG?

+ Yes. Cities and Guns are distinguishable by the length of their reference numbers.

Is the algorithm behind the report/extraction working separately for JCC and JCG?

+ Yes.


Furthermore, downloading from Lotw, I have seen that for JCC automatically both fields �prefecture� and �city/gun� are fulfilled, the first one with the 2 numbers of JCC, the second with the full 4 or 6 numbers of JCC. On my view the �prefecture� indication has to be omitted and therefore cancelled.

+ The reference number logged in a Japanese QSO's CNTY item begins with the 2-digit number of its Prefecture. Do not remove the 2-digit Prefecture number from the City or Gun reference number logged in DXKeeper's CNTY item!

+ DXLab follows the ADIF convention of recording both the Primary and Secondary Subdivision information in the Secondary Administrative Subdivision item. For US counties, for example, the Secondary Administrative Subdivision item contains a two-letter State abbreviation, a comma, and then the County name, e.g.

MA,Middlesex

 + DXKeeper's "Sync LoTW QSLs" function correctly populates the Primary Administrative Subdivision and Secondary Administrative Subdivision items in logged QSOs with Japanese stations. No modification of the information obtained from LoTW is required.

+ Here is the ADIF that LoTW returns for my QSO with JA6FIO.

<APP_LoTW_OWNCALL:5>AA6YQ
<STATION_CALLSIGN:5>AA6YQ
<CALL:6>JA6FIO
<BAND:3>20M
<FREQ:8>14.07527
<MODE:3>FT8
<APP_LoTW_MODEGROUP:4>DATA
<QSO_DATE:8>20190705
<TIME_ON:6>105445
<PROP_MODE:2>F2
<QSL_RCVD:1>Y
<QSLRDATE:8>20190708
<DXCC:3>339
<COUNTRY:5>JAPAN
<APP_LoTW_DXCC_ENTITY_STATUS:7>Current
<PFX:3>JA6
<APP_LoTW_2xQSL:1>Y
<IOTA:6>AS-077
<GRIDSQUARE:6>QN13KF
<STATE:2>40 // Fukuoka-ken
<CNTY:4>4001 // Fukuoka-shi
<CQZ:2>25
<ITUZ:2>45
<eor>

+ The QSO's STATE item conveys 40 (Fukuoka Prefecture)

+ The QSO's CNTY item conveys 4001 (Fukuoka City within Fukuoka Prefecture)


Am I correct? I have not found in Wiki answers to my issue.

+ To what "issue" are you referring?


+ The reference documentation for the JCC progress report is here:

<https://www.dxlabsuite.com/dxkeeper/Help/Progress.htm#AP%20JCC>

+ The reference documentation for the JCG progress report is here:

<https://www.dxlabsuite.com/dxkeeper/Help/Progress.htm#AP%20JCG>

+ If while logging or updating a QSO with a Japanese station, you select the Prefecture (by name) and then select the City/Gun (by name) within that Prefecture, the correct reference numbers will be recorded in the QSO. "Sync LoTW QSLs" will update a logged QSO with information submitted to LoTW by your Japanese QSO partners; any discrepancy between information in the logged QSO and information submitted by your QSO partner will be resolved as specified in the "Handling of LoTW QSL detail inconsistencies" panel on the "QSL Configuration" window's LoTW tab.

        73,

                 Dave, AA6YQ











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




Re: JARL progress reports

Dave AA6YQ
 

+ AA6YQ comments below

Thank you so much for the detailed explanation. Everything is now perfectly clear to me.

+ Good! Information from the post below is now available via

<https://www.dxlabsuite.com/dxlabwiki/TrackingJCCJCGAwards.

73,

Dave, AA6YQ


-----Messaggio originale-----
Da: DXLab@groups.io <DXLab@groups.io> Per conto di Dave AA6YQ
Inviato: luned� 20 gennaio 2020 19:48
A: DXLab@groups.io
Oggetto: Re: [DXLab] JARL progress reports

+ AA6YQ comments below

I was in the process of controlling/updating my two possible Japanese Awards, JCC and JCG and I have a couple of questions regarding the �JARL progress reports� in DxKeeper.

JCC (for Cities) has references composed by 4 numbers (plus, in few cases, 6 numbers), JCG (for Guns) by 5 numbers (always).

JCC and JCG are not **overlapping** each other and are designating completely **independent** areas.


In �DxKeeper/Log QSOs/Award for Japanese calls� there is a field �prefecture� and another one �city/gun�.

Easy to insert the JCG Guns putting in �prefecture� the first two numbers and then chose in �city/gun� the proper reference.

For JCC how to proceed? Not taking into consideration �prefecture� and only indicate the 4 (or 6) numbers in �city/gun�?

+ If a logged QSO with a Japanese stations specifies a prefecture, the Subdivision selector will be populated with all cities and guns within that prefecture. Choose the one specified by your QSO partner over the air, or on his or her QSL card.


And then the reports are properly extracting, separately, only JCC or JCG?

+ Yes. Cities and Guns are distinguishable by the length of their reference numbers.

Is the algorithm behind the report/extraction working separately for JCC and JCG?

+ Yes.


Furthermore, downloading from Lotw, I have seen that for JCC automatically both fields �prefecture� and �city/gun� are fulfilled, the first one with the 2 numbers of JCC, the second with the full 4 or 6 numbers of JCC. On my view the �prefecture� indication has to be omitted and therefore cancelled.

+ The reference number logged in a Japanese QSO's CNTY item begins with the 2-digit number of its Prefecture. Do not remove the 2-digit Prefecture number from the City or Gun reference number logged in DXKeeper's CNTY item!

+ DXLab follows the ADIF convention of recording both the Primary and Secondary Subdivision information in the Secondary Administrative Subdivision item. For US counties, for example, the Secondary Administrative Subdivision item contains a two-letter State abbreviation, a comma, and then the County name, e.g.

MA,Middlesex

+ DXKeeper's "Sync LoTW QSLs" function correctly populates the Primary Administrative Subdivision and Secondary Administrative Subdivision items in logged QSOs with Japanese stations. No modification of the information obtained from LoTW is required.

+ Here is the ADIF that LoTW returns for my QSO with JA6FIO.

<APP_LoTW_OWNCALL:5>AA6YQ
<STATION_CALLSIGN:5>AA6YQ
<CALL:6>JA6FIO
<BAND:3>20M
<FREQ:8>14.07527
<MODE:3>FT8
<APP_LoTW_MODEGROUP:4>DATA
<QSO_DATE:8>20190705
<TIME_ON:6>105445
<PROP_MODE:2>F2
<QSL_RCVD:1>Y
<QSLRDATE:8>20190708
<DXCC:3>339
<COUNTRY:5>JAPAN
<APP_LoTW_DXCC_ENTITY_STATUS:7>Current
<PFX:3>JA6
<APP_LoTW_2xQSL:1>Y
<IOTA:6>AS-077
<GRIDSQUARE:6>QN13KF
<STATE:2>40 // Fukuoka-ken
<CNTY:4>4001 // Fukuoka-shi
<CQZ:2>25
<ITUZ:2>45
<eor>

+ The QSO's STATE item conveys 40 (Fukuoka Prefecture)

+ The QSO's CNTY item conveys 4001 (Fukuoka City within Fukuoka Prefecture)


Am I correct? I have not found in Wiki answers to my issue.

+ To what "issue" are you referring?


+ The reference documentation for the JCC progress report is here:

<https://www.dxlabsuite.com/dxkeeper/Help/Progress.htm#AP%20JCC>

+ The reference documentation for the JCG progress report is here:

<https://www.dxlabsuite.com/dxkeeper/Help/Progress.htm#AP%20JCG>

+ If while logging or updating a QSO with a Japanese station, you select the Prefecture (by name) and then select the City/Gun (by name) within that Prefecture, the correct reference numbers will be recorded in the QSO. "Sync LoTW QSLs" will update a logged QSO with information submitted to LoTW by your Japanese QSO partners; any discrepancy between information in the logged QSO and information submitted by your QSO partner will be resolved as specified in the "Handling of LoTW QSL detail inconsistencies" panel on the "QSL Configuration" window's LoTW tab.

73,

Dave, AA6YQ











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

Re: TQSL is looking for my log in my old log program

Dave AA6YQ
 

+ AA6YQ comments below

I am having a devil of a time getting DX Keeper to send my log to LoTW. TQSL says when I sign and upload it says its looking in the old program for the log.Any help would be appreciated.

+ If you're using DXKeeper to interoperate with LoTW, DXKeeper invokes TQSL on your behalf.

+ Have you configured DXKeeper as described step-by-step in

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

+ ?

+ Are you using this procedure to submit QSOs to LoTW?

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

+ ?

73,

Dave, AA6YQ