Many of the serial device drivers do not deal well with the device being turned off and can cause hangs. In my experience they often do not recover if power is restored to the device. This may be device/driver specific. The port (USB?) isn’t shutting down the power for you is it? There is a configuration to suppress the power off when the computer goes to sleep.

73, Larry W6NWS

From: KD7YZ Bob
Sent: Friday, April 05, 2013 3:46 PM
To: dxlab group
Cc: Dave AA6YQ
Subject: [dxlab] Commander not-responding


Hi dxlab (group):
I have asked about this a half-dozen times, or more. Also I haven't been
able to find a prime cause for Dave.

Other than Dave, who already knows this happens to me, has anyone else
had Commander go TU? Non-Responding? Crashed, frozen .. in a position
where nothing, save a reboot, will make the frozen Commander go away.

To make it happen, I have two methods, none of which are predictable in
amount of time needed to see that Commander is frozen.

One, I can start DX-Lab suite with the radio turned off. At some point,
be it 5 minutes or an hour, I will have to reboot the computer. A
sub-set of this is to accidently suite the rig off, or XYL gets tired of
hearing CW somewhere and shuts it off .

The second method is to have the rig on, start DX-Lab suit then go do
chores. Or do other things on the computer.

Eventually, measured in hours likely, Commander is non-responding and
the computer needs to be restarted. This happens every day.

--
73,
Bob KD7YZ
www.denstarfarm.us/LGD

[Non-text portions of this message have been removed]

Thanks Joe and Dave!

Tom - W4BQF

Hi dxlab (group):
I have asked about this a half-dozen times, or more. Also I haven't been
able to find a prime cause for Dave.

Other than Dave, who already knows this happens to me, has anyone else
had Commander go TU? Non-Responding? Crashed, frozen .. in a position
where nothing, save a reboot, will make the frozen Commander go away.

To make it happen, I have two methods, none of which are predictable in
amount of time needed to see that Commander is frozen.


One, I can start DX-Lab suite with the radio turned off. At some point,
be it 5 minutes or an hour, I will have to reboot the computer. A
sub-set of this is to accidently suite the rig off, or XYL gets tired of
hearing CW somewhere and shuts it off .

The second method is to have the rig on, start DX-Lab suit then go do
chores. Or do other things on the computer.

Eventually, measured in hours likely, Commander is non-responding and
the computer needs to be restarted. This happens every day.


--
73,
Bob KD7YZ
www.denstarfarm.us/LGD

AA6YQ comments below

-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of Tommy Alderman
Sent: Friday, April 05, 2013 12:32 PM
To: dxlab@yahoogroups.com
Subject: [dxlab] Keyboard CW and WW

In message #118365 (May 17),a question was posed about keying a K3 with
RTS/DTR in the com port used by ww for communications with the K3, Dave
answered:

">>>There's not, John. However, you can configure WinWarbler to provide
keyboard CW by having Commander send CAT commands to your K3: on the CW tab
of WinWarbler's Configuration window, set Keying panel to "Xcvr Ctrl App".

Does this answer mean ww will never be able to key a K3 using either RTS or
DTR? Or does it mean some changes are in progress to enable keyboard keying
via this means? Being new to dxlabs, if this RTS/DTR will not be
implemented, how can a K3 be keyed?

The K3, KX3, and a growing number of Flex, Icom, Kenwood, and Yaesu transceivers, accept CAT commands to transmit CW. The timing

of the CW in this manner is rock solid. In comparison, the timing of CW generated by WinWarbler via a serial port's RTS or DTR
signal can vary as a function of the load on your PC's CPU.

To generate CW in this way, set the Keying panel on the CW tab of WinWarbler's Configuration window to "Xcvr Ctrl App";

WinWarbler will then convey text to be transmitted as CW to Commander, which will in turn convey it to your transceiver via the
serial port used for CAT control.

73,

Dave, AA6YQ

AA6YQ comments below

-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of Joe
Sent: Friday, April 05, 2013 1:41 PM
To: dxlab@yahoogroups.com
Subject: [dxlab] UP-Date

Ok I have so far in DXK 855 QSO's

All are uploded to LOTW, EQsl, etc .
Now I do the sync buttons on LOTW with no errors.

Now if i click on the button that says Up-Date from LOTW
a box pops up asking about only 109 QSO's as seen here.

http://i49.tinypic.com/289hdah.jpg

What does this mean?

It means that there are 109 QSOs in your Log Page Display, and that DXKeeper is seeking confirmation that you want it to query

LotW for the status of each one of them.

73,

Dave, AA6YQ

On Fri, Apr 5, 2013 at 11:25 AM, Salvatore Besso
<salvatore.besso@alice.it> wrote:

Have you worked all of those 277 entities on ALL bands 10 though 160?
Any entity that you have not worked on ALL bands (that you are
pursuing) is still considered "unworked" (on some band).

no, of course. I don't know (I'd have to look) if I have even only one
entity worked on all bands 160-10. As I've said,
I'm pursuing the mixed DXCC, and an option to see unworked entities, I
mean entities never worked on any band, would be
useful.

I understand, but I don't think there's any way to do that.

I actually was partially wrong before - it's the bands that are
selected on the "Plot Settings" tab of DXView Configuration that
matter - not those that you are pursuing for DXCC. I don't see any way
to plot entities that are unworked for mixed DXCC, but I may be
missing something.

73.

~iain / N6ML

On 4/5/2013 12:32 PM, Tommy Alderman wrote:

Does this answer mean ww will never be able to key a K3 using either RTS or
DTR? Or does it mean some changes are in progress to enable keyboard keying
via this means? Being new to dxlabs, if this RTS/DTR will not be
implemented, how can a K3 be keyed?

This means that Commander will never be able to provide on/off keyed CW
on DTR. This was tried some time ago with WinWarbler providing key down
(DTR ON) and Key Up (DTR OFF) commands to Commander and the resulting
stutter was too bad due to delays in Windows.

A K3 can be keyed via the "key" jack using WinKey or a simple level
shifting circuit (resistor/transistor or optical isolator) from a
second serial or USB port or using the "XCVR Ctrl App" option which
sends the "KY" commands to the K3 over the K3's CAT interface.

73,

... Joe, W4TV

Have you worked all of those 277 entities on ALL bands 10 though 160?
Any entity that you have not worked on ALL bands (that you are
pursuing) is still considered "unworked" (on some band).

no, of course. I don't know (I'd have to look) if I have even only one entity worked on all bands 160-10. As I've said, I'm pursuing the mixed DXCC, and an option to see unworked entities, I mean entities never worked on any band, would be useful.

--
73 de
Salvatore (I4FYV)

Typing error below: May 17 should have been March 17.



From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of
Tommy Alderman
Sent: Friday, April 05, 2013 12:32 PM
To: dxlab@yahoogroups.com
Subject: [dxlab] Keyboard CW and WW





In message #118365 (May 17),a question was posed about keying a K3 with
RTS/DTR in the com port used by ww for communications with the K3, Dave
answered:

">>>There's not, John. However, you can configure WinWarbler to provide
keyboard CW by having Commander send CAT commands to your K3: on the CW tab
of WinWarbler's Configuration window, set Keying panel to "Xcvr Ctrl App".

Does this answer mean ww will never be able to key a K3 using either RTS or
DTR? Or does it mean some changes are in progress to enable keyboard keying
via this means? Being new to dxlabs, if this RTS/DTR will not be
implemented, how can a K3 be keyed?

Thanks and 73,

Tom - W4BQF

Dave,

Did you then click the Plot button on DXKeeper's Main window
to plot all logged QSOs in the Log Page Display?

I have just tried. Clicking on Plot in DXKeeper moves the radio button in the map from DXCC entities to Log and no red dots appear, the map remains empty.

Again, what I want to see are *unworked* *DXCC entities*, that's why this radio button is selected, but when it is selected all entities are shown as dots.

But there is the possibility that I have not understood map's working. Selecting the "DXCC entities" button and checking "Unworked", what would I obtain?

Thank you.

--
73 de
Salvatore (I4FYV)

--- In dxlab@yahoogroups.com, "Dave AA6YQ" <aa6yq@...> wrote:

AA6YQ comments below

-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of g4wjs
Sent: Friday, April 05, 2013 5:40 AM
To: dxlab@yahoogroups.com
Subject: [dxlab] Re: SC split spot



--- In dxlab@yahoogroups.com, "g4wjs" <bill.8@> wrote:

Hi

just clicked a spot for VK9CZ on 28012.5 that had been splitting sensibly but when the spot:

2013-04-04 11:06 de YO6HSU (EU) : up 28.015,27 599

got added to the pile the split went to 28040.5.

Obviously the the mix of digit separators has confused SC but I believe it should have made a better stab at this one or ignored

it.

I've just seen another that could perhaps be better. 5W0M spotted on 28028 with the following note:

2013-04-05 09:20 de UA4PCM (EU) : +3 around

but SC doesn't determine a split operation.

SpotCollector thought that was a WX report.

Oh, ok. I can imagine the code to decode random comments gives somewhat fuzzy results. I suppose that is credible in UA4 in early April, also the spot was busted anyway since the DX was on 28026 UP 3 ;)

How about the first one, the number given is a well formatted frequency in kHz in any country that uses ',' as a DP and '.' as a 000's separator.

73,

Dave, AA6YQ

73
Bill.

On Fri, Apr 5, 2013 at 11:06 AM, Salvatore Besso
<salvatore.besso@alice.it> wrote:

look again, I have checked only "Unworked", so there would be no more than
64 dots on the map. I'm pursuing mixed DXCC
160-10 and at today I have worked 277 entities, so I want to see the
remaining 64 or so dots (are 340 or 341 the total
entities? I don't remember now).

Have you worked all of those 277 entities on ALL bands 10 though 160?
Any entity that you have not worked on ALL bands (that you are
pursuing) is still considered "unworked" (on some band).

73,

~iain / N6ML

Iain,

look again, I have checked only "Unworked", so there would be no more than 64 dots on the map. I'm pursuing mixed DXCC 160-10 and at today I have worked 277 entities, so I want to see the remaining 64 or so dots (are 340 or 341 the total entities? I don't remember now).

--
73 de
Salvatore (I4FYV)

Ok I have so far in DXK 855 QSO's

All are uploded to LOTW, EQsl, etc .
Now I do the sync buttons on LOTW with no errors.

Now if i click on the button that says Up-Date from LOTW
a box pops up asking about only 109 QSO's as seen here.

http://i49.tinypic.com/289hdah.jpg

What does this mean?

joe WB9SBD
--
Sig
The Original Rolling Ball Clock
Idle Tyme
Idle-Tyme.com
http://www.idle-tyme.com

AA6YQ comments below

-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of g4wjs
Sent: Friday, April 05, 2013 5:40 AM
To: dxlab@yahoogroups.com
Subject: [dxlab] Re: SC split spot



--- In dxlab@yahoogroups.com, "g4wjs" <bill.8@...> wrote:

Hi

just clicked a spot for VK9CZ on 28012.5 that had been splitting sensibly but when the spot:

2013-04-04 11:06 de YO6HSU (EU) : up 28.015,27 599

got added to the pile the split went to 28040.5.

Obviously the the mix of digit separators has confused SC but I believe it should have made a better stab at this one or ignored

it.

I've just seen another that could perhaps be better. 5W0M spotted on 28028 with the following note:

2013-04-05 09:20 de UA4PCM (EU) : +3 around

but SC doesn't determine a split operation.

SpotCollector thought that was a WX report.

73,

Dave, AA6YQ

When you have a logged QSO whose address does not print correctly, please

1. create an email message that specifies the QSO's callsign, date, and time

2. place your log file in a zip archive

3. attach zip archive to the email message you created in step 1

4. send the email message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ

AA6YQ comments below

-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of Mike34230
Sent: Friday, April 05, 2013 12:02 PM
To: dxlab@yahoogroups.com
Subject: [dxlab] Problem with DXKeeper using new version of tQSL

The new version of tQSL has been working fine for the last few days except for the last QSO I tried to upload.

From DXKeeper's Log QSOs screen, I right clicked on an entry and chose "Upload to LotW". The window that popped up told me that the
upload was unsuccessful, LOTW was unavailable, please try later.

I tried again and it said, "no qsos uploaded".

In the DXKeeper QSL Configuration screen, I unchecked "Permit uploading of QSOs already uploaded to Lotw", and tried to upload
again. It went through fine this time.

It seems that either DXKeeper or the new tQSL had mismarked the unsuccessfully uploaded QSO as uploaded, and prevented it from
uploading again.

That's correct behavior, Mike.

DXKeeper directed TQSL to digitally sign the QSO; TQSL did so, and added the data from the QSO to the information it uses to

identify duplicates.

DXKeeper then uploaded the digitally signed QSO to LotW, only to discover that LotW was "down"; as a result, DXKeeper did not

mark the QSO as uploaded to LotW.

When you later tried to upload the QSO, TQSL objected because that QSO had already been digitally signed, and there'd been no

changes to that QSO's key data (callsign, band, mode, date, time, satellite, station callsign) or to the "Station Callsign" used to
digitally sign the QSO.

Enabling "Permit uploading of QSOs already uploaded to LotW" and then re-uploading was exactly the right step to take.

This scenario could be simplified by extending DXKeeper to direct TQSL to upload the digitally signed QSO(s) to LotW if TQSL 1.14

or later is present; then a failed upload (because LotW is "down") would not result in the QSO's data being entered into TQSL's
duplicate detector, and it would not be necessary to enable "Permit uploading of QSOs already uploaded to LotW" before later
re-uploading.

73,

Dave, AA6YQ

If you employ DXKeeper's DXCC submission generator, the first thing you'll do is deselect LotW's "proposal" and then select the QSOs
identified by DXKeeper.

LotW's "proposal" is notoriously suboptimal in terms of the minimum set of confirmed QSOs required to achieve the maximum increase
in DXCC credit.

73,

Dave, AA6YQ

AA6YQ comments below

-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of Salvatore Besso
Sent: Friday, April 05, 2013 7:32 AM
To: Lista DXLab
Subject: [dxlab] DXView world map question

hello all,

all DXLab apps running. I go to DXView and I click the World button to show the map. Settings are as follows:

Map settings:
-------------
Countries: selected
Auroral zones: unchecked

DX settings:
------------
Spots: NOT selected
QSOs: unchecked

Log of I4FYV settings:
----------------------
QSOs: NOT selected
DXCC entities: selected
Unworked: checked
Unconfirmed: unchecked
Confirmed: unchecked
Verified: unchecked

DXView insists to plot red dots for EVERY DXCC entity, even those worked, confirmed, etc. (so I think that 340 dots are
plotted, hi). Is this a defect or have I done something wrong?

Did you then click the Plot button on DXKeeper's Main window to plot all logged QSOs in the Log Page Display?

73,

Dave, AA6YQ

AA6YQ comment sbelow

-----Original Message-----
From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] On Behalf Of Salvatore Besso
Sent: Friday, April 05, 2013 5:09 AM
To: Lista DXLab
Subject: [dxlab] Another question about DXKeeper qsl management

hello all,

I have noticed the following behaviour when logging a qso (the qso is logged from WinWarbler):

- QSL_SENT is set to (R)equested [paper card still to be printed]

- QSL_RCVD is left NULL (empty) [paper card not received yet, of course]

After the LoTW upload/sync phase has been completed I have:

- LOTW_QSL_SENT is set to (Y)es

- LOTW_QSL_RCVD is set to (R)equested

Ok, this could be logical because I have requested a qsl card to the contacted station, but why not leave it empty like
QSL_RCVD?

Because by uploading an LotW QSO, you have requested an LotW confirmation.

Or, turning the question upside-down: Why not setting QSL_RCVD (paper) to (R)equested too?

Because until you send an outgoing QSL card requesting a QSL card in return, you have not requested a QSL card confirmation.

Another thing: I have imported my log that was coming from Ham Radio Deluxe and all LOTW_QSL_RCVD fields for not
received confirmations were all set to (N)o. Is it correct by DXKeeper point of view or do I have to bulk-edit them to
another value? If yes, what value, (R)equested or empty?

DXKeeper imports the values exported by HRD. If HRD failed to export the correct values for "LotW QSL Rcvd", that's a defect in

HRD.

I suggest that you direct DXKeeper to update your log to reflect acceptances and confirmations of uploaded QSOs by following the

instructions in

<http://www.dxlabsuite.com/dxlabwiki/QSOsAlreadyUploadedLotW>

73,

Dave, AA6YQ