View Revisions: Issue #1479

Summary 0001479: CW QSK Support of MFJ 495 keyer
Revision 2014-02-02 14:11 by WA9PIE
Description Thanks for your response, Tim!

No, this has not been resolved yet.

My call sign is KY8C
The HRD version is Release 6 (purchased about one month ago).
The PC is an HP, AMD 6 Core running Win7 64 bit OS with all the latest patches
The rig is on Com 10 and the Keyer is on Com 5

Please let me restate my question to better clarify...

The rig is a Ten Tec Eagle Model 599 running latest patch set 1.825. The rig is
interfaced to the computer via a Ten Tec Sound card USB interface and also via a USB A/B cable.
The MFJ 495 Keyer is interfaced to the computer with an RS323 to USB conversion
cable. My objective is to be able to run full QSK CW - not MCW or any other
semi-break in method (see below).

When I set HRD to CW (WinKey) and connect to WinKey, it sends a test string that
keys the MFJ keyer which in turn keys the Eagle in perfect QSK CW. At the end of
the test string, HRD returns to copying received CW signals perfectly. This
situation would indicate to me that all of the electrical/data connections are
in place and working properly? The problem arises when I then try to send CW
with the computer keyboard via HRD. With QSK set or not set, the CW is sent
through the keyer which keys the Eagle in perfect QSK but then HRD refuses to
copy anything received further after that initial transmission. I've tried the
escape key, manually siwtching to receive in HRD and killing WinKey and
everything else that I can think of but HRD remains locked in transmit after
that first transmission and will not copy again. The only reliable way I've
found to get out this condition is to kill HRD and DM and then restart them.

Let me state that I am very pleased with every other aspect of HRD which is why
I purchased a licensed copy. If I can get it to do full QSK as described above,
it would be 100% 'perfect' in my book but if not, I'll continue to use the
keyboard connected directly to the MFJ keyer to send with. The problem with this
approach is that I cannot see the type ahead buffer and cannot correct typos..
and I make a lot of typos. I REALLY do not want to have to buy another interface
to make this work and will just stick with the work around if that turns out to
be the only solution. Even so, it would seem logical that since the test string
works that full QSK with auto return to receive should also work. Everything
seems to be in place?

Again, this is not a show stopper but it sure would be terrific if we could
resolve this one, single issue. A lot of high speed CW ops settle for nothing
less than full QSK and I am one of that group. IMHO, semi-break in (MCW) is no
better than PTT voice or digital modes and such operations are monologs. They
are not in the same league as a true back and forth, interactive full QSK CW
QSO. Bottom Line: I would much rather use my current work around and not have
the ability to correct the type ahead buffer than lose QSK capabilities.

I hope my wordy explanation helps avoid the need to spend excessive effort in
determining whether this can or can't be done.

BTW, I used to be able to do what I'm describing more than 25 years ago using a
Ten Tec Corsair, a Vic 20 and a Kantronic interface. Obviously, that was pretty
primitive technology...

Thanks again!

Gary Roseberry/KY8C
Mon, Apr 15 2013 3:27am - staff

Can you post your problem on Mantis?
Here we keep Bugs and such.

This way the developer's can see the issues and take note of them.

I will close this ticket.

Ferry PD9FER
Revision 2013-12-23 21:44 by Support
Description Data lost