DXLab@groups.io | Messages

Re: USSR and the former Eastern Bloc

Abie Alexander

#196765

Thanks a million, Joe!

I have about 500 USSR QSOs and was dreading to do the fixes manually.

73,

Abie/AB1F

Show quoted text

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Joe Subich, W4TV
Sent: Wednesday, October 14, 2020 22:21
To: DXLab@groups.io
Subject: Re: [DXLab] USSR and the former Eastern Bloc

I had the entities logged correctly in my previous self-created log.
How did they get changed to the post USSR entities?The ADIF file exported by your previous logger failed to contain the
"country number".   DXKeeper imports any QSO without the "country
number" using the current callsign rules.

 > How can I change them back?

1) BACKUP YOUR LOG!
2) click the "~" button in the lower right until you see a button
    labeled "Scripts"
3) Click the "Scripts" button and select/run "FIX_USSR"

That script will reassign country to callsigns from the former USSR for roughly 1970 - 1989.

You may have issues with Eastern European QSOs in the same time period (1970's - 2000 +/-). The "FIX_EU" script will repair those issues.  FIX_KH will fix "old" US possessions in the Pacific (and Canal Zone).  FIX_MISC will fix issues in Asia, Indian Ocean and the Caribbean in the same time frame.

73,

    ... Joe, W4TV

On 2020-10-14 12:26 PM, Abie Alexander wrote:
Hi,

My imports of nearly 16K QSOs into DXKeeper seemed to be working beautifully, until I uploaded an ADIF export file into Club Log.

Club Log came up with long list of error messages relating to former republics of the USSR and to countries of the Eastern Bloc.

I had the entities logged correctly in my previous self-created log. How did they get changed to the post USSR entities? How can I change them back? Or is it something that has to be done manually for each entry? All affected QSOs are pre-1989.

Is there anything in the Config. settings to prevent such automatic resettings?

Will I have to make changes to the LoTW and eQSL.cc logs as well?

Thanks for any help you can provide.

73,

Abie/AB1F

Re: USSR and the former Eastern Bloc

Abie Alexander

#196764

Many thanks, Dave!

73,

Abie/AB1F.

Show quoted text

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave AA6YQ
Sent: Wednesday, October 14, 2020 23:11
To: DXLab@groups.io
Subject: Re: [DXLab] USSR and the former Eastern Bloc

My imports of nearly 16K QSOs into DXKeeper seemed to be working beautifully, until I uploaded an ADIF export file into Club Log.

Club Log came up with long list of error messages relating to former republics of the USSR and to countries of the Eastern Bloc.

I had the entities logged correctly in my previous self-created log. How did they get changed to the post USSR entities? How can I change them back? Or is it something that has to be done manually for each entry? All affected QSOs are pre-1989.

+ Without seeing the ADIF QSO records you submitted, I can't say for 
+ sure. However, if an imported QSO record specifies a DXCC field
(which specifies a country code), DXKeeper will respect it. If a DXCC field is not present, then DXKeeper will deduce the DXCC entity from the callsign using current callsign-to-DXCC mapping rules -- which won't be correct for older QSOs. 

+ This issue and its resolution are described in the "Recovering each 
+ QSO's DXCC entity" section of

<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dxlabsuite.com%2Fdxlabwiki%2FQSOImport&;data=02%7C01%7C%7C7c4861f7dde04592957c08d870684952%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637382940493736295&amp;sdata=uZGGPMzICYDMjCqmuDyoJ1EOKKZroY1aNJE7y%2FgtIrA%3D&amp;reserved=0>

+ Be sure to backup your log before running any script.

Is there anything in the Config. settings to prevent such automatic resettings? 

+ If my "no DXCC fields in imported QSOs" guess is correct, there was no 
+ "automatic resetting"; DXKeeper was forced to determine the
DXCC entity from the callsign because no DXCC entity was specified.

Will I have to make changes to the LoTW and eQSL.cc logs as well? 

+ No.

           73,

                  Dave, AA6YQ

Re: Default Mode in Capture Window

Dave AA6YQ

#196763

+ AA6YQ comments AA6YQ

I think it should be for JT65 EME only, if anything. MS and Tropo these days would be using modes that do not use that form of shorthand (MSK144, etc).

+ My DXing has been limited to the F2, ES, and BS propagation modes, which is why I'm seeking guidance.

Where does this "default" come into play anyway? 

+ In his original post, Fred AB1OC stated that he is using MAP65 (a version of WSJT) for 2m EME QSOs, and that "The MAP65 program does not have a direct logging interface so using JTalert to interface to DXkeeper is not an option."

<https://groups.io/g/DXLab/message/196716>

+ I assume that he is using DXKeeper's Capture window to record these QSOs.

I missed that part of the thread. Are we talking about manually entered QSOs (e.g. capture window), or imports that don't specify signal reports, or... ?

+ the SENT and RCVD items are populated with default signal reports when

     - you have the "Initialize RST items to 59/599" option enabled on the Configuration window's General tab

     - you have Contest mode enabled on the Configuration window's Contest tab

     - you double-click the SENT or RCVD item in the QSO panel on the Main window's "Log QSOs" tab

+ There is no option to include default signal reports in imported QSOs.

         73,

              Dave, AA6YQ

Re: LOTW upload first time

Dave AA6YQ

#196762

+ AA6YQ comments below

Hi Dave and Ian, Just submitted my second batch of logs using my second call VE3TJB (540 Qsos) Upload was perfect again. After sync lotw qsos I now got message 626 Qsos processed (How come that many?) 

+ "Sync LoTW QSOs" reports all QSO reported by LoTW as "accepted" since the last time you invoked "Sync LoTW QSOs".

And 539 log entries updated and 88 errors.

I have 1 duplicate qso in log (my fault!)..the rest all from the VE3NKZ group (first group I submitted yesterday) And they all say "no matching QSO in log".....this error is not listed in the link page you gave me to read So not sure what this means...can you please explain and let me know how I fix it.

+ "No matching QSO in log" is an error reported by DXKeeper, not LotW. DXKeeper expects that the information reported by LoTW for a QSO exact matches that QSO's information in your log; any discrepancy produces this error message. For example, if you submit a QSO to LoTW whose start time is 00:00:00 Z, then modified the logged QSO's start time to 00:00:01Z, and the invoke "Sync LoTW QSOs", the result will be "no matching QSO in log".

Should I fix these 88 errors and resubmit before hitting the sync lotw qsls button??

+ You should understand why LoTW is reporting information that doesn’t match your logged QSOs before proceeding. Pick one mismatch, and get to the bottom of it. That will likely explain the other 87.

        73,

               Dave, AA6YQ

Re: LOTW upload first time

Ted Boerkamp

#196761

Hi Dave and Ian, Just submitted my second batch of logs using my second call VE3TJB (540 Qsos)
Upload was perfect again. After sync lotw qsos I now got message 626 Qsos processed (How come that many?)
And 539 log entries updated and 88 errors.
I have 1 duplicate qso in log (my fault!)..the rest all from the VE3NKZ group (first group I submitted yesterday)
And they all say "no matching QSO in log".....this error is not listed in the link page you gave me to read
So not sure what this means...can you please explain and let me know how I fix it.
Should I fix these 88 errors and resubmit before hitting the sync lotw qsls button??
Thanks again

Ted VE3SS

Show quoted text

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dave AA6YQ
Sent: Wednesday, October 14, 2020 5:47 PM
To: DXLab@groups.io
Subject: Re: [DXLab] LOTW upload first time

+ AA6YQ comments below

Hi Ian.....This batch was the oldest of 3 batches based on my first callsign VE3NKZ and based on its specific myqthid. The year range is old covering contacts from 1981 to early 1990.

I had hand entered all of this batch and converted local time to UTC where needed.
After the sync lotw qsl button push, I got only 7 log entries updated and 0 errors!!!

+ A very low LoTW QSL rate for QSOs made from 1981 to 1990 is not a definitive indicator of problems, especially if they were all submitted with the same "Station Calsign".

I got no notice of any mismatched times etc. 

+ LoTW does not report "mismatched times". The errors that can be reported when you submit QSOs to LoTW are documented here:

<https://lotw.arrl.org/lotw-help/submitting-qsos/#tqsl-errors>

Maybe this is legit and they are just too old?

+ Given the information you've provided above, that's quite possible. Of the 1783 QSOs I made during 1991 (my first year as a ham), only 90 have been confirmed via LoTW; that's 5%.

    73,

            Dave, AA6YQ

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

Re: Default Mode in Capture Window

g4wjs

#196760

Joe,

WSJT-X supports short-codes and in modes like JT65 they are not merely historical artefacts, they are a very efficient mechanism of passing a 3-bit binary piece of information (RO, RRR, or 73), i.e. a confirmation of receipt or signoff. Short-codes are detected by the decoder with enhanced sensitivity, not just used visually on the waterfall, although as they have no FEC other than repetition, they may be interpreted visually by the operator even if the decoder fails to recognize them. To that end markers are drawn on the waterfall to aid visual detection, each short-code consists of an alternating tone between the lowest sync tone and another frequency denoting which short-code it is.

A QSO might go like this (repetition and message averaging elided), meanings of messages exchanged appended:

CQ G4WJS IO91                  # G4WJS makes a general call
         G4WJS K1JT FN20       # K1JT replies
K1JT G4WJS OOO                 # G4WJS acknowledges the K1JT call
         RO                    # K1JT acknowledges (short-code)
RRR                            # G4WJS acknowledges (short code
         73                    # K1JT signs off (short-code)

Note that even though 'OOO' is printed nothing is sent in the message meaning 'OOO', instead any message of the form "<DX-call> <DE-call> <grid-square>" (where <grid-square> is optional) is simply printed, when short-codes are enabled, as an 'OOO' message. I.e. the 'OOO' is not a short-code message, it is just a decoration at the Rx end on a normal 72-bit payload JT65 message.

MSK144, commonly used for meteor-scatter QSOs below 2m, uses a different type of short-codes which are full fledged messages which are shortened by various reduced sensitivity encoding techniques in order to increase the message repeat rate. The intent is to utilize shorter duration meteor trails to complete a QSO in progress quickly, with some sacrifice of sensitivity and decoding robustness. These are not human readable other than that there is a clear audible difference between a normal MSK144 message and a MSK144 short-code message, determining which particular short-code message has been received requires systematic decoding by software.

73
Bill
G4WJS.

Show quoted text

On 14/10/2020 23:23, Joe Subich, W4TV wrote:

> # Any objections to this proposed enhancement to DXKeeper?

The "shorthand" reports are becoming less frequently used as
more users adopt WSJTX to replace the older WSJT due to the
automation built into WSJT. As Bill points out the shorthand
reports are an artifact of CW (where they were easier to
recognize by ear) and the original WSJT (where they were easy
to "see" in the waterfall). The shorthand reports have little
if any advantage given the improved decoding in the most recent
versions of WSJTX. Logging the actual receive levels is just
as common as the shorthand reports.

I don't see the need for unique defaults - at least for those
using WSJTX or WSJTX/JTAlert given their integration with
DXLab Suite. The bigger issue with WSJTX/JTAlert is entering
propagation mode on a QSO by QSO basis - particularly if one
is running the K1JT modes on a second rig not controlled by
Commander at the same time as "traditional modes" on a rig
connected to Commander.

73,

   ... Joe, W4TV

On 2020-10-14 6:00 PM, Dave AA6YQ wrote:

# even more AA6YQ comments below

    * more AA6YQ comments below

            + Are "OOO and RO" appropriate for JT65 in all cases, or only when
            the propagation mode is set to EME?

        Only for EME

    * Thanks, Joe. With the propagation mode set to EME, are "OOO and RO" appropriate as default signal reports for all K1JT modes, or just JT65?

    * 000 is the default "RST sent" and "R0" is the default "RST Rcvd" - correct?

those types of reports are optional even in JT65 mode. In general they are used when fixed dual alternating tones are used instead of encoded messages for the acknowledgement and sign off stages of QSOs. These so-called short codes have increased sensitivity allowing QSOs to be completed with marginal propagation and station equipment. They hark back to CW EME operating where repeated single charcters or pairs of characters are sent for a complete period, i.e. OOOOOOO..., RORORORO..., RRRRRRR..., 737373737373... . They are used, by prior agreement, after callsigns are exchanged using regular messages.

# Thanks Bill! Based on your comments above and the "EME QSOs" section of the document Iain N6ML recommended:

<http://www.arrl.org/files/file/18JT65.pdf>

# it would seem appropriate for DXKeeper to use OOO and RO as the default signal reports when the Propagation Mode implies very weak signals: EME, Meteor Scatter (MS), and Tropospheric Ducting (TR).

# Any objections to this proposed enhancement to DXKeeper?

             73,

                     Dave, AA6YQ

--
73

Bill

G4WJS.

Re: LOTW upload first time

Gilbert Baron W0MN

#196759

Be sure the date pf the certificate you are using covers the dates of the QSOes being uploaded.

Outlook Laptop Gil W0MN
Hierro candente, batir de repente
44.08226N 92.51265W EN34rb

Show quoted text

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Ted Boerkamp
Sent: Wednesday, October 14, 2020 16:31
To: DXLab@groups.io
Subject: Re: [DXLab] LOTW upload first time

Hi Ian.....This batch was the oldest of 3 batches based on my first callsign VE3NKZ and based on its specific myqthid. The year range is old covering contacts from 1981 to early 1990.
I had hand entered all of this batch and converted local time to UTC where needed.
After the sync lotw qsl button push, I got only 7 log entries updated and 0 errors!!!
I got no notice of any mismatched times etc. Maybe this is legit and they are just too old?
I am not sure what else I can do yet. I am going to read the links that Dave has Suggested and I may go ahead and try batch 2 to see if the match rate gets better.
My next batch will use a different call and covers years from Mar 90 to Oct 94.
My third batch will use my current call and covers Nov 94 to present day.
All three batches have different myqthids as well.
73  Ted VE3SS

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of iain macdonnell - N6ML
Sent: Tuesday, October 13, 2020 10:44 PM
To: DXLab@groups.io
Subject: Re: [DXLab] LOTW upload first time

If it was a case of LotW not having processed the entire upload yet, I think that the result of the "Sync LotW QSOs" operation would not have shown all 554 processed (as reported in the original post). To be sure, the OP might check the LotW web interface under "Your Account"
-> "Your Activity", and examine the "Result" of his upload.

It sounds like there's some sort of issue with the uploaded QSOs that's causing failure to match. Assuming that the QSOs are not very old (like decades old), I would expect a match rate closer to 50%. As a total guess, perhaps the QSOs were logged with local time instead of UTC. Without more history, there's not a lot to go on here.

73,

    ~iain / N6ML

On Tue, Oct 13, 2020 at 7:09 PM Mike Flowers <mike.flowers@gmail.com> wrote:

Hi Ted,

On the LotW page that shows your QSOs, there is a button to show you your most recent QSOs that you have uploaded.

When you see all your uploaded QSOs there, you will get the desired result when you click Sync QSOs in DXKeeper.

When that is completed, Sync QSLs will update DXKeeper with those QSLs from LoTW.

-- 73 de Mike Flowers, K6MKF, NCDXC - "It's about DX!"

On Oct 13, 2020, at 6:53 PM, Ted Boerkamp <tboerkamp@cogeco.ca> wrote:

﻿

Hello all....I have just made my first batch upload of 554 contacts to LOTW.

After pressing the sync lotw qsos button , I got message that all 554 were processed, 0 errors.

All good so far...

This is where I am confused....what is the difference between sync lotw qso’s and sync lotw qsl’s??

I pressed that button next and I got back 7 qsl’s processed only!!! 7 log entries updated, 0 errors.

What just happened here? It only matched 7 of 554 Qs I submitted??

Does this mean the other 547 calls never submitted to LOTW to match my submissions?

I am seeing that the 7 entries had both their rcvd and sent status updated to Y.

Do I still have to hit the Update from LOTW button at this point? And what does that do?

I have 2 more batches of logs to submit under other calls and 
myqthid’s so I want to

understand whats going on.

Any help or quick explanation is most welcome.

Thanks   Ted VE3SS

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

-- 
W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop

Re: Default Mode in Capture Window

Joe Subich, W4TV

#196758

# Any objections to this proposed enhancement to DXKeeper?The "shorthand" reports are becoming less frequently used as
more users adopt WSJTX to replace the older WSJT due to the
automation built into WSJT.  As Bill points out the shorthand
reports are an artifact of CW (where they were easier to
recognize by ear) and the original WSJT (where they were easy
to "see" in the waterfall).  The shorthand reports have little
if any advantage given the improved decoding in the most recent
versions of WSJTX.  Logging the actual receive levels is just
as common as the shorthand reports.

I don't see the need for unique defaults - at least for those
using WSJTX or WSJTX/JTAlert given their integration with
DXLab Suite.  The bigger issue with WSJTX/JTAlert is entering
propagation mode on a QSO by QSO basis - particularly if one
is running the K1JT modes on a second rig not controlled by
Commander at the same time as "traditional modes" on a rig
connected to Commander.

73,

   ... Joe, W4TV


On 2020-10-14 6:00 PM, Dave AA6YQ wrote:
# even more AA6YQ comments below
	* more AA6YQ comments below
	
			+ Are "OOO and RO" appropriate for JT65 in all cases, or only when
			the propagation mode is set to EME?
		Only for EME
	* Thanks, Joe. With the propagation mode set to EME, are "OOO and RO" appropriate as default signal reports for all K1JT modes, or just JT65?
	* 000 is the default "RST sent" and "R0" is the default "RST Rcvd" - correct?
those types of reports are optional even in JT65 mode. In general they are used when fixed dual alternating tones are used instead of encoded messages for the acknowledgement and sign off stages of QSOs. These so-called short codes have increased sensitivity allowing QSOs to be completed with marginal propagation and station equipment. They hark back to CW EME operating where repeated single charcters or pairs of characters are sent for a complete period, i.e. OOOOOOO..., RORORORO..., RRRRRRR..., 737373737373... . They are used, by prior agreement, after callsigns are exchanged using regular messages.
# Thanks Bill! Based on your comments above and the "EME QSOs" section of the document Iain N6ML recommended:
<http://www.arrl.org/files/file/18JT65.pdf>
# it would seem appropriate for DXKeeper to use OOO and RO as the default signal reports when the Propagation Mode implies very weak signals: EME,  Meteor Scatter (MS), and Tropospheric Ducting (TR).
# Any objections to this proposed enhancement to DXKeeper?
73,
Dave, AA6YQ

Re: Default Mode in Capture Window

iain macdonnell - N6ML

#196757

On Wed, Oct 14, 2020 at 3:00 PM Dave AA6YQ <aa6yq@ambersoft.com> wrote:

# even more AA6YQ comments below

        * more AA6YQ comments below

                        + Are "OOO and RO" appropriate for JT65 in all cases, or only when
                        the propagation mode is set to EME?

                Only for EME

        * Thanks, Joe. With the propagation mode set to EME, are "OOO and RO" appropriate as default signal reports for all K1JT modes, or just JT65?

        * 000 is the default "RST sent" and "R0" is the default "RST Rcvd" - correct?

those types of reports are optional even in JT65 mode. In general they are used when fixed dual alternating tones are used instead of encoded messages for the acknowledgement and sign off stages of QSOs. These so-called short codes have increased sensitivity allowing QSOs to be completed with marginal propagation and station equipment. They hark back to CW EME operating where repeated single charcters or pairs of characters are sent for a complete period, i.e. OOOOOOO..., RORORORO..., RRRRRRR..., 737373737373... . They are used, by prior agreement, after callsigns are exchanged using regular messages.

# Thanks Bill! Based on your comments above and the "EME QSOs" section of the document Iain N6ML recommended:

<http://www.arrl.org/files/file/18JT65.pdf>

# it would seem appropriate for DXKeeper to use OOO and RO as the default signal reports when the Propagation Mode implies very weak signals: EME,  Meteor Scatter (MS), and Tropospheric Ducting (TR).

# Any objections to this proposed enhancement to DXKeeper?I think it should be for JT65 EME only, if anything. MS and Tropo
these days would be using modes that do not use that form of shorthand
(MSK144, etc).

Where does this "default" come into play anyway? I missed that part of
the thread. Are we talking about manually entered QSOs (e.g. capture
window), or imports that don't specify signal reports, or... ?

73,

    ~iain / N6ML

Re: Default Mode in Capture Window

g4wjs

#196756

On 14/10/2020 23:00, Dave AA6YQ wrote:
# even more AA6YQ comments below

	* more AA6YQ comments below
	
			+ Are "OOO and RO" appropriate for JT65 in all cases, or only when
			the propagation mode is set to EME?

		Only for EME

	* Thanks, Joe. With the propagation mode set to EME, are "OOO and RO" appropriate as default signal reports for all K1JT modes, or just JT65?

	* 000 is the default "RST sent" and "R0" is the default "RST Rcvd" - correct?

those types of reports are optional even in JT65 mode. In general they are used when fixed dual alternating tones are used instead of encoded messages for the acknowledgement and sign off stages of QSOs. These so-called short codes have increased sensitivity allowing QSOs to be completed with marginal propagation and station equipment. They hark back to CW EME operating where repeated single charcters or pairs of characters are sent for a complete period, i.e. OOOOOOO..., RORORORO..., RRRRRRR..., 737373737373... . They are used, by prior agreement, after callsigns are exchanged using regular messages.

# Thanks Bill! Based on your comments above and the "EME QSOs" section of the document Iain N6ML recommended:

<http://www.arrl.org/files/file/18JT65.pdf>

# it would seem appropriate for DXKeeper to use OOO and RO as the default signal reports when the Propagation Mode implies very weak signals: EME,  Meteor Scatter (MS), and Tropospheric Ducting (TR).

# Any objections to this proposed enhancement to DXKeeper?

             73,

                     Dave, AA6YQHi Dave,

I am not convinced, short codes do get used for EME on some bands but I would not necessarily say it is the default position.

Also the only report is O, there is no report of RO as that is a combination of "roger I have your report, and my report is O", so you would no more log RO as a report than you would log R-13 as a report, i.e. you would log -13 only.

I think that all that is necessary is to be able to log 'O' or 'OOO' as a report, either sent or received. It hardly seems worth logging such reports anyway as merely logging the QSO is evidence that the operator has confirmed that a QSO was completed, i.e. callsigns and one other QSO specific piece of information (gridsquares) have been sent *and* acknowledged both ways.

73
Bill
G4WJS.

-- 
73

Bill

G4WJS.

Re: Default Mode in Capture Window

Dave AA6YQ

#196755

# even more AA6YQ comments below

	* more AA6YQ comments below
	
			+ Are "OOO and RO" appropriate for JT65 in all cases, or only when
			the propagation mode is set to EME?

		Only for EME

	* Thanks, Joe. With the propagation mode set to EME, are "OOO and RO" appropriate as default signal reports for all K1JT modes, or just JT65?

	* 000 is the default "RST sent" and "R0" is the default "RST Rcvd" - correct?

those types of reports are optional even in JT65 mode. In general they are used when fixed dual alternating tones are used instead of encoded messages for the acknowledgement and sign off stages of QSOs. These so-called short codes have increased sensitivity allowing QSOs to be completed with marginal propagation and station equipment. They hark back to CW EME operating where repeated single charcters or pairs of characters are sent for a complete period, i.e. OOOOOOO..., RORORORO..., RRRRRRR..., 737373737373... . They are used, by prior agreement, after callsigns are exchanged using regular messages.

# Thanks Bill! Based on your comments above and the "EME QSOs" section of the document Iain N6ML recommended:

<http://www.arrl.org/files/file/18JT65.pdf>

# it would seem appropriate for DXKeeper to use OOO and RO as the default signal reports when the Propagation Mode implies very weak signals: EME,  Meteor Scatter (MS), and Tropospheric Ducting (TR).  

# Any objections to this proposed enhancement to DXKeeper?

            73,

                    Dave, AA6YQ

Re: LOTW upload first time

Dave AA6YQ

#196754

+ AA6YQ comments below

Hi Ian.....This batch was the oldest of 3 batches based on my first callsign VE3NKZ and based on its specific myqthid. The year range is old covering contacts from 1981 to early 1990.

I had hand entered all of this batch and converted local time to UTC where needed.
After the sync lotw qsl button push, I got only 7 log entries updated and 0 errors!!!

+ A very low LoTW QSL rate for QSOs made from 1981 to 1990 is not a definitive indicator of problems, especially if they were all submitted with the same "Station Calsign".

I got no notice of any mismatched times etc. 

+ LoTW does not report "mismatched times". The errors that can be reported when you submit QSOs to LoTW are documented here:

<https://lotw.arrl.org/lotw-help/submitting-qsos/#tqsl-errors>

Maybe this is legit and they are just too old?

+ Given the information you've provided above, that's quite possible. Of the 1783 QSOs I made during 1991 (my first year as a ham), only 90 have been confirmed via LoTW; that's 5%.

    73,

            Dave, AA6YQ

Re: LOTW upload first time

Ted Boerkamp

#196753

Hi Ian.....This batch was the oldest of 3 batches based on my first callsign VE3NKZ and
based on its specific myqthid. The year range is old covering contacts from 1981 to early 1990.
I had hand entered all of this batch and converted local time to UTC where needed.
After the sync lotw qsl button push, I got only 7 log entries updated and 0 errors!!!
I got no notice of any mismatched times etc. Maybe this is legit and they are just too old?
I am not sure what else I can do yet. I am going to read the links that Dave has
Suggested and I may go ahead and try batch 2 to see if the match rate gets better.
My next batch will use a different call and covers years from Mar 90 to Oct 94.
My third batch will use my current call and covers Nov 94 to present day.
All three batches have different myqthids as well.
73  Ted VE3SS

Show quoted text

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of iain macdonnell - N6ML
Sent: Tuesday, October 13, 2020 10:44 PM
To: DXLab@groups.io
Subject: Re: [DXLab] LOTW upload first time

If it was a case of LotW not having processed the entire upload yet, I
think that the result of the "Sync LotW QSOs" operation would not have
shown all 554 processed (as reported in the original post). To be
sure, the OP might check the LotW web interface under "Your Account"
-> "Your Activity", and examine the "Result" of his upload.

It sounds like there's some sort of issue with the uploaded QSOs
that's causing failure to match. Assuming that the QSOs are not very
old (like decades old), I would expect a match rate closer to 50%. As
a total guess, perhaps the QSOs were logged with local time instead of
UTC. Without more history, there's not a lot to go on here.

73,

    ~iain / N6ML

On Tue, Oct 13, 2020 at 7:09 PM Mike Flowers <mike.flowers@gmail.com> wrote:

Hi Ted,

On the LotW page that shows your QSOs, there is a button to show you your most recent QSOs that you have uploaded.

When you see all your uploaded QSOs there, you will get the desired result when you click Sync QSOs in DXKeeper.

When that is completed, Sync QSLs will update DXKeeper with those QSLs from LoTW.

-- 73 de Mike Flowers, K6MKF, NCDXC - "It's about DX!"

On Oct 13, 2020, at 6:53 PM, Ted Boerkamp <tboerkamp@cogeco.ca> wrote:

﻿

Hello all....I have just made my first batch upload of 554 contacts to LOTW.

After pressing the sync lotw qsos button , I got message that all 554 were processed, 0 errors.

All good so far...

This is where I am confused....what is the difference between sync lotw qso’s and sync lotw qsl’s??

I pressed that button next and I got back 7 qsl’s processed only!!! 7 log entries updated, 0 errors.

What just happened here? It only matched 7 of 554 Qs I submitted??

Does this mean the other 547 calls never submitted to LOTW to match my submissions?

I am seeing that the 7 entries had both their rcvd and sent status updated to Y.

Do I still have to hit the Update from LOTW button at this point? And what does that do?

I have 2 more batches of logs to submit under other calls and myqthid’s so I want to

understand whats going on.

Any help or quick explanation is most welcome.

Thanks   Ted VE3SS

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

Re: Default Mode in Capture Window

g4wjs

#196752

On 14/10/2020 21:12, Dave AA6YQ wrote:

* more AA6YQ comments below

+ Are "OOO and RO" appropriate for JT65 in all cases, or only when
the propagation mode is set to EME?
Only for EME

* Thanks, Joe. With the propagation mode set to EME, are "OOO and RO" appropriate as default signal reports for all K1JT modes, or just JT65?

* 000 is the default "RST sent" and "R0" is the default "RST Rcvd" - correct?

73,

Dave, AA6YQ

Hi Dave,

those types of reports are optional even in JT65 mode. In general they are used when fixed dual alternating tones are used instead of encoded messages for the acknowledgement and sign off stages of QSOs. These so-called short codes have increased sensitivity allowing QSOs to be completed with marginal propagation and station equipment. They hark back to CW EME operating where repeated single charcters or pairs of characters are sent for a complete period, i.e. OOOOOOO..., RORORORO..., RRRRRRR..., 737373737373... . They are used, by prior agreement, after callsigns are exchanged using regular messages.

73
Bill
G4WJS.

--
73

Bill

G4WJS.

Re: Default Mode in Capture Window

Dave AA6YQ

#196751

# AA6YQ comments below

On Wed, Oct 14, 2020 at 1:13 PM Dave AA6YQ <aa6yq@ambersoft.com> wrote:

* more AA6YQ comments below

+ Are "OOO and RO" appropriate for JT65 in all cases, or only when
the propagation mode is set to EME?

Only for EME

* Thanks, Joe. With the propagation mode set to EME, are "OOO and RO" appropriate as default signal reports for all K1JT modes, or just JT65?

* 000 is the default "RST sent" and "R0" is the default "RST Rcvd" - correct?It's OOO (Oscar's), not 000 (zeroes) (similarly RO, not R0). Somewhat described here:

http://www.arrl.org/files/file/18JT65.pdf

# Thanks, Iain!

      73,

              Dave, AA6YQ

Re: Default Mode in Capture Window

iain macdonnell - N6ML

#196750

On Wed, Oct 14, 2020 at 1:13 PM Dave AA6YQ <aa6yq@ambersoft.com> wrote:

* more AA6YQ comments below

+ Are "OOO and RO" appropriate for JT65 in all cases, or only when
the propagation mode is set to EME?

Only for EME

* Thanks, Joe. With the propagation mode set to EME, are "OOO and RO" appropriate as default signal reports for all K1JT modes, or just JT65?

* 000 is the default "RST sent" and "R0" is the default "RST Rcvd" - correct?It's OOO (Oscar's), not 000 (zeroes) (similarly RO, not R0). Somewhat
described here:

http://www.arrl.org/files/file/18JT65.pdf

73,

    ~iain / N6ML

Re: Default Mode in Capture Window

Dave AA6YQ

#196749

* more AA6YQ comments below

+ Are "OOO and RO" appropriate for JT65 in all cases, or only when
the propagation mode is set to EME?
Only for EME

* Thanks, Joe. With the propagation mode set to EME, are "OOO and RO" appropriate as default signal reports for all K1JT modes, or just JT65?

* 000 is the default "RST sent" and "R0" is the default "RST Rcvd" - correct?

73,

Dave, AA6YQ

Re: can i do a spectrum display with my IC7600?

Jon Gefaell

#196748

Looks like 7600 isn’t supported. I think it’s just the SDR rigs.

https://www.dxlabsuite.com/dxlabwiki/SpectrumWaterfallIcom

Show quoted text

On Oct 14, 2020, at 14:52, Norm <norman@...> wrote:

and if so link to info.

--
Norm WA4ZXV EM73vw

Re: can i do a spectrum display with my IC7600?

Dave AA6YQ

#196747

+ AA6YQ comments below

and if so link to info.

+ The IC-7600 cannot report spectrum data via its CI-V bus, and so is not supported by Commander's Spectrum-Waterfall window. To use this window, you need an IC-705, IC-7300, IC-7610, IC-7850, IC-7851, or IC-9700:

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

73,

Dave, AA6YQ

Re: Default Mode in Capture Window

Joe Subich, W4TV

#196746

+ Are "OOO and RO" appropriate for JT65 in all cases, or only when
the propagation mode is set to EME?Only for EME

+ What about all the other K1JT modes; should DXKeeper provide
different default signal reports for them?K1JT modes are very resistant to default signal reports as the
typical report is a signal level between MDS for the submode
and somewhere up to +20 (representing the signal to noise level
in a 2500 Hz passband).  When using WSJTX direct or with JTAlert
the signal report is transferred automatically eliminating the
need for default(s) - or using the Capture window.

73,

   ... Joe, W4TV


On 2020-10-14 1:53 PM, Dave AA6YQ wrote:
+ AA6YQ comments below
One more item. The default signal reports (599) for JT65x don't make any sense. It would be great if the defaults could be changed to OOO and RO. is there a way to do this with either DXkeeper or Commander? This would make logging much less error prone for EME contacts.
+ At present, DXKeeper defaults the signal report to 599 unless the mode is SSB, FM, AM, or DIGIVOICE>
+ Are "OOO and RO" appropriate for JT65 in all cases, or only when the propagation mode is set to EME?
+ What about all the other K1JT modes; should DXKeeper provide different default signal reports for them?
73,
Dave, AA6YQ