Hi Pat,

Then I think you just need to reduce your "Tail" setting, and increase
"Paddle Hang".

GL/73,

~iain / N6ML


On Sun, Aug 5, 2012 at 1:48 PM, f6gcp <f6gcp@...> wrote:

Hi Ian,

thanks on information. I have checked running Winkey2 software, and it
shows firmware 2.3.
A <winkeycmd:> could be nice, for advanced settings (Up to now, I don't
know what I can do with this but spot CW... later may be...)

73 - Pat

--- In dxlab@..., iain macdonnell - N6ML <ar@> wrote:

On Sun, Aug 5, 2012 at 2:45 AM, f6gcp <f6gcp@> wrote:

Hi,
Winkey is set with a "tail" time of 500ms and PTT asserted, which is
quite
ok for CW operation using the keyer, and to avoid trcv to go to
receive (of
course, I should say the amplifier!)
Using macro command is nice to run in a pile up, however, the tail, as
set
to 500ms is a too long (the pile_up "TU" to confirm qso could be
missed!).

Hi Pat,

What version of WinKeyer do you have? There was a change between v2.2
and v2.3 that significantly helps with this situation. From
http://k1el.tripod.com/files/Winkey23changes.pdf :

"Hang mode is now independent of tail delay: Hang Time applies only to
CW sent by paddle. Tail
delay applies only to CW sent by the host or by standalone message. It
is no longer necessary to
disable Hang Time setting controls in the GUI when Tail is set to a
non-zero value. This is because
the settings are independent now. (Side note: A long Tail time can be
truncated early by appending
a `PTT off' buffered command /U0 to the message stream)"

It's worth upgrading (requires chip replacement) if you are
experiencing this problem, IMO.

Using the opcode "stop" (while running the winkey test software), the
PTT
is immediatly released whatever the tail set time.
In a macro, is is possible, while <stop> command is used, to
immedialty
return to RX (assuming VOX is not used!) or to create a command
<stop_immediat> (or similar) for such purpose?

That may be possible to implement (using the "/U0" command mentioned
above). Only Dave can say. Actually, it may be better to implement a
"<winkeycmd: ...>" so arbitrary commands could be sent.....

73,

~iain / N6ML

AA6YQ comments below

-----Original Message-----
From: dxlab@... [mailto:dxlab@...]On Behalf Of
f6gcp
Sent: Sunday, August 05, 2012 5:45 AM
To: dxlab@...
Subject: [dxlab] Winkey and <stop>


Hi,
Winkey is set with a "tail" time of 500ms and PTT asserted, which is quite
ok for CW operation using the keyer, and to avoid trcv to go to receive (of
course, I should say the amplifier!)
Using macro command is nice to run in a pile up, however, the tail, as set
to 500ms is a too long (the pile_up "TU" to confirm qso could be missed!).
Using the opcode "stop" (while running the winkey test software), the PTT is
immediatly released whatever the tail set time.
In a macro, is is possible, while <stop> command is used, to immedialty
return to RX (assuming VOX is not used!) or to create a command
<stop_immediat> (or similar) for such purpose?

What commands are sent to the WinKey when the "WinKey Test Software" is

directed to "stop"?

73,

Dave, AA6YQ

AA6YQ comments below

-----Original Message-----
From: dxlab@... [mailto:dxlab@...]On Behalf Of
alanswinger
Sent: Sunday, August 05, 2012 12:00 PM
To: dxlab@...
Subject: [dxlab] Re: LOTW/DXKeeper Station Location match


Dave - I did follow the LoTW Certif transfer insts, and had TQSL and TQSL
Cert saved on a DVD after I renewed them last yr. I also checked the
station_data files on both PCs and they were the same except for unique
computer user names. So, I Edited the Station Location file in TQSL Cert on
the new PC to make it is the same as the Old PC and the Station File, and
also made sure Keeper reflected the edit.
I uploaded all QSOs in Keeper since I put the new PC on line (7/5-8/5/12) to
LoTW this morning. LoTW confirmed receipt so I snch'd QSOs and QSLs, and got
the following message:
- LOTW OPerations: 4 QSLs processed; 4 Log entries updated, 0 errors. No new
confirmations of previously unconfirmed entity-bands or entity-modes.

I expected nothing new, so the message is correct from that aspect, and
appears that the upload and responses are correct. Also checked the LoTW
Sent Boxes and all show a Y and today's date.

Therefore, it appears that all is working properly. Other than receiving a
LoTW QSO confirmation, is there anything else to check?

That all sounds good, Alan, but the proof of the pudding will be when one

of the QSOs logged and uploaded from your new laptop gets confirmed via
LotW.

73,

Dave, AA6YQ

Hi Ian,

thanks on information. I have checked running Winkey2 software, and it
shows firmware 2.3.
A <winkeycmd:> could be nice, for advanced settings (Up to now, I don't
know what I can do with this but spot CW... later may be...)

73 - Pat

--- In dxlab@..., iain macdonnell - N6ML <ar@...> wrote:

On Sun, Aug 5, 2012 at 2:45 AM, f6gcp <f6gcp@...> wrote:

Hi,
Winkey is set with a "tail" time of 500ms and PTT asserted, which is
quite
ok for CW operation using the keyer, and to avoid trcv to go to
receive (of
course, I should say the amplifier!)
Using macro command is nice to run in a pile up, however, the tail, as
set
to 500ms is a too long (the pile_up "TU" to confirm qso could be
missed!).

Hi Pat,

What version of WinKeyer do you have? There was a change between v2.2
and v2.3 that significantly helps with this situation. From
http://k1el.tripod.com/files/Winkey23changes.pdf :

"Hang mode is now independent of tail delay: Hang Time applies only to
CW sent by paddle. Tail
delay applies only to CW sent by the host or by standalone message. It
is no longer necessary to
disable Hang Time setting controls in the GUI when Tail is set to a
non-zero value. This is because
the settings are independent now. (Side note: A long Tail time can be
truncated early by appending
a `PTT off' buffered command /U0 to the message stream)"

It's worth upgrading (requires chip replacement) if you are
experiencing this problem, IMO.

Using the opcode "stop" (while running the winkey test software), the
PTT
is immediatly released whatever the tail set time.
In a macro, is is possible, while <stop> command is used, to
immedialty
return to RX (assuming VOX is not used!) or to create a command
<stop_immediat> (or similar) for such purpose?

That may be possible to implement (using the "/U0" command mentioned
above). Only Dave can say. Actually, it may be better to implement a
"<winkeycmd: ...>" so arbitrary commands could be sent.....

73,

~iain / N6ML

AA6YQ comments below

-----Original Message-----
From: dxlab@... [mailto:dxlab@...]On Behalf Of
Rich - W3ZJ
Sent: Sunday, August 05, 2012 11:24 AM
To: DXLab
Subject: [dxlab] Clublog


Two of my last three QSO's (D3AA on 15M CW and UN/UA4WHX on 17M CW) were
rejected by Clublog as Duplicates. I have never worked either of those
stations before on those bands/modes. I later did a manual upload to
Clublog and those were accepted as two "new" QSO's:

Dear W3ZJ,

Congratulations - your ADIF file has been imported without warnings. A total of 2 new QSOs have been uploaded.

* Software: DXKEEPER
* File name: ClubLogUpload.ADI (488 B)
* New QSOs: 2

I saw this once a couple of days ago also but didn't report it. Who is
messing up here DXLab or Clublog?

If there are no previous QSOs in your log and the ClubLogUpload.ADI file created by DXKeeper doesn't contain duplicates, then I don't see how it can be a DXKeeper problem.

73,

Dave, AA6YQ

AA6YQ comments below

-----Original Message-----
From: dxlab@... [mailto:dxlab@...]On Behalf Of
iain macdonnell - N6ML
Sent: Saturday, August 04, 2012 3:27 PM
To: dxlab@...
Subject: Re: [dxlab] Re: request: special callsign in SC

snip<

Dave, I wonder if there's a case for a built-in "SpecialNeed" tag that
gets
included in the "stock" <NEEDFILTER> ?

I don't yet understand what you're suggesting, Iain. Please elaborate.

On Sun, Aug 5, 2012 at 2:45 AM, f6gcp <f6gcp@...> wrote:

Hi,
Winkey is set with a "tail" time of 500ms and PTT asserted, which is quite
ok for CW operation using the keyer, and to avoid trcv to go to receive (of
course, I should say the amplifier!)
Using macro command is nice to run in a pile up, however, the tail, as set
to 500ms is a too long (the pile_up "TU" to confirm qso could be missed!).

Hi Pat,

What version of WinKeyer do you have? There was a change between v2.2
and v2.3 that significantly helps with this situation. From
http://k1el.tripod.com/files/Winkey23changes.pdf :

"Hang mode is now independent of tail delay: Hang Time applies only to
CW sent by paddle. Tail
delay applies only to CW sent by the host or by standalone message. It
is no longer necessary to
disable Hang Time setting controls in the GUI when Tail is set to a
non-zero value. This is because
the settings are independent now. (Side note: A long Tail time can be
truncated early by appending
a `PTT off' buffered command /U0 to the message stream)"

It's worth upgrading (requires chip replacement) if you are
experiencing this problem, IMO.

Using the opcode "stop" (while running the winkey test software), the PTT
is immediatly released whatever the tail set time.
In a macro, is is possible, while <stop> command is used, to immedialty
return to RX (assuming VOX is not used!) or to create a command
<stop_immediat> (or similar) for such purpose?

That may be possible to implement (using the "/U0" command mentioned
above). Only Dave can say. Actually, it may be better to implement a
"<winkeycmd: ...>" so arbitrary commands could be sent.....

73,

~iain / N6ML

**

AA6YQ comments below

-----Original Message-----
From: dxlab@... [mailto:dxlab@...]On Behalf Of
Chuck Chandler
Sent: Sunday, August 05, 2012 9:59 AM
To: dxlab@...
Subject: [dxlab] DXKeeper 10.3.7 won't launch

Via Launcher it times out at 180 seconds, followed by the windows error

'DXKeeper has encountered an error and needs to close'. After that I
re-booted the PC, same behavior.

Double-clicking the DXKeeper.exe from Windows Explorer brings only the

error box.

Double-clicking the 1037 version from Windows Explorer brings only the

error box.

Double-clicking the 1032 version launches normally.

Also, sometimes the error box reads "Google Chrome has encountered an
error..." although Chrome is not running.

That is in addition to the DXKeeper error, not in place of.

For now, I've pointed the Launcher to version 10.3.2, and all is well.

If there's an errorlog.txt file in your Launcher and/or DXKeeper

please attach them to an email message and send them to

aa6yq (at) ambersoft.com

The most likely possibility is that your antivirus or firewall is

preventing DXKeeper 10.3.7 from starting; make sure these applications
consider DXKeeper "safe".

If that's not it, then in your DXKeeper folder,

1. delete DXKeeper1037.exe

2. make a copy of the file DXKeeper1032.exe and name this copy

(if you haven't done this already)

3. start the Launcher, and direct it to upgrade DXKeeper again

73,

Dave, AA6YQ