K3 KComm PSK D / FSK D Question

[Ian Greenshields]

I'm either missing something or I have a feature request for KComm,
depending on whether I have misunderstood how to use the software!
I've been looking for a contest / general purpose logger for data modes from
the K3 that can make use of the K3's PSK D and FSK D modes for RTTY and
PSK31, i.e. using the K3 to generate the RTTY or PSK signals and not the
computer soundcard. This is something that, at least with my basic PC, the
K3 seems to be much better at as well as eliminating an audio cable from the
PC to the K3. KComm does this very well.

On the receive side, there's a problem. I've read & understand the reasons
why KComm cannot yet use the decoded RX data from the K3 on the serial port
(big shame, BTW). But even so, tuning PSK31 signals is very fiddly using the
K3's CWT & hopeless in a contest situation. I was hoping to be able to use
the PSK engine and the waterfall within KComm to facilitate tuning in
signals and for text decode whilst retaining the excellent FSK/PSK D TX
arrangement that KComm has implemented. However, as soon as the soundcard
option is ticked in the settings, the programme seems to now only allow TX
also via the soundcard.

So to my question: is it possible for KComm to use the PC soundcard for RX
tuning and data decode, whilst retaining the K3's data TX capabilities via
the serial port?

I think even after it hopefully becomes possible to separate the K3's
decoded text and radio responses on the serial port, some form of waterfall
aid to tuning and band monitoring will still be extremely useful within a
logging / control programme, then requiring an input to the soundcard
anyway.

At the moment, I use the MMVARI data engine for RTTY & PSK31 RX, and KComm
for TX. But, they fight for the serial port, they don't fit on the screen,
you can't easily transfer data from an RX to a TX window etc. etc. It seems
to me that KComm does almost all of this already if the above were possible
(OK, the data engine needs to support RTTY too, but that's a next step; the
K3 display will have to do in the interim as it's much better at tuning &
decoding RTTY).

It is possible? Could it be inplemented? Any other thoughts or solutions?

Many thanks & 73,
Ian G4FSU
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

[Joe Subich, W4TV-4]

Ian,

> So to my question: is it possible for KComm to use the PC
> soundcard for RX tuning and data decode, whilst retaining the
> K3's data TX capabilities via the serial port?

Although it might be technically possible for KComm to be
modified to use the PC soundcard for turning and PSK31 decode
and the PSK-D mode for transmit, I do not thick you would like
the results as the transmit and receive frequencies would
quite easily diverge since PSK-D transmits at a fixed 1050 Hz
tone frequency.

"Zero beat" is quite critical with PSK modes.  As little as
10 Hz deviation between transmit and receive frequencies can
result in "walking the band" if AFC/Net are in use or no copy
if the other station is not using AFC.

73,

   ... Joe, W4TV
   

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Ian
> Greenshields
> Sent: Saturday, February 28, 2009 11:39 AM
> To: [hidden email]
> Subject: [Elecraft] K3 KComm PSK D / FSK D Question
>
>
> I'm either missing something or I have a feature request for
> KComm, depending on whether I have misunderstood how to use
> the software! I've been looking for a contest / general
> purpose logger for data modes from the K3 that can make use
> of the K3's PSK D and FSK D modes for RTTY and PSK31, i.e.
> using the K3 to generate the RTTY or PSK signals and not the
> computer soundcard. This is something that, at least with my
> basic PC, the K3 seems to be much better at as well as
> eliminating an audio cable from the PC to the K3. KComm does
> this very well.
>
> On the receive side, there's a problem. I've read &
> understand the reasons why KComm cannot yet use the decoded
> RX data from the K3 on the serial port (big shame, BTW). But
> even so, tuning PSK31 signals is very fiddly using the K3's
> CWT & hopeless in a contest situation. I was hoping to be
> able to use the PSK engine and the waterfall within KComm to
> facilitate tuning in signals and for text decode whilst
> retaining the excellent FSK/PSK D TX arrangement that KComm
> has implemented. However, as soon as the soundcard option is
> ticked in the settings, the programme seems to now only allow
> TX also via the soundcard.
>
> So to my question: is it possible for KComm to use the PC
> soundcard for RX tuning and data decode, whilst retaining the
> K3's data TX capabilities via the serial port?
>
> I think even after it hopefully becomes possible to separate
> the K3's decoded text and radio responses on the serial port,
> some form of waterfall aid to tuning and band monitoring will
> still be extremely useful within a logging / control
> programme, then requiring an input to the soundcard anyway.
>
> At the moment, I use the MMVARI data engine for RTTY & PSK31
> RX, and KComm for TX. But, they fight for the serial port,
> they don't fit on the screen, you can't easily transfer data
> from an RX to a TX window etc. etc. It seems to me that KComm
> does almost all of this already if the above were possible
> (OK, the data engine needs to support RTTY too, but that's a
> next step; the K3 display will have to do in the interim as
> it's much better at tuning & decoding RTTY).
>
> It is possible? Could it be inplemented? Any other thoughts
> or solutions?
>
> Many thanks & 73,
> Ian G4FSU

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

[Ian Greenshields]

I may be missing something, but I think it could work in the same way as
KComm behaves now.

Unlike other soundcard software, which simply decodes in the DSP at whatever
frequency in the waterfall is selected, KComm retunes the K3's VFO so the
signal is centred in the waterfall. Therefore it is always decoding at a
known fixed frequency. There may be an offset from the TX frequency but it
should be predictable and can therefore be compensated for. The quick test
would be to see if the soundcard decoded text coincided with the K3's own
decoded text. Unfortunately it's difficult to check because the K3 PSK31
text decode is disabled in DATA A.

The usual caveats about misuse of AFC and NET would still be relevant.

I can see how it needs to be implemented from a system perspective, but not
being a programmer, I don't know how to do it!

73 Ian G4FSU


2009/2/28 Joe Subich, W4TV <[hidden email]>

>
> Ian,
>
> > So to my question: is it possible for KComm to use the PC
> > soundcard for RX tuning and data decode, whilst retaining the
> > K3's data TX capabilities via the serial port?
>
> Although it might be technically possible for KComm to be
> modified to use the PC soundcard for turning and PSK31 decode
> and the PSK-D mode for transmit, I do not thick you would like
> the results as the transmit and receive frequencies would
> quite easily diverge since PSK-D transmits at a fixed 1050 Hz
> tone frequency.
>
> "Zero beat" is quite critical with PSK modes.  As little as
> 10 Hz deviation between transmit and receive frequencies can
> result in "walking the band" if AFC/Net are in use or no copy
> if the other station is not using AFC.
>
> 73,
>
>   ... Joe, W4TV
>
>
>
> > -----Original Message-----
> > From: [hidden email]
> > [mailto:[hidden email]] On Behalf Of Ian
> > Greenshields
> > Sent: Saturday, February 28, 2009 11:39 AM
> > To: [hidden email]
> > Subject: [Elecraft] K3 KComm PSK D / FSK D Question
> >
> >
> > I'm either missing something or I have a feature request for
> > KComm, depending on whether I have misunderstood how to use
> > the software! I've been looking for a contest / general
> > purpose logger for data modes from the K3 that can make use
> > of the K3's PSK D and FSK D modes for RTTY and PSK31, i.e.
> > using the K3 to generate the RTTY or PSK signals and not the
> > computer soundcard. This is something that, at least with my
> > basic PC, the K3 seems to be much better at as well as
> > eliminating an audio cable from the PC to the K3. KComm does
> > this very well.
> >
> > On the receive side, there's a problem. I've read &
> > understand the reasons why KComm cannot yet use the decoded
> > RX data from the K3 on the serial port (big shame, BTW). But
> > even so, tuning PSK31 signals is very fiddly using the K3's
> > CWT & hopeless in a contest situation. I was hoping to be
> > able to use the PSK engine and the waterfall within KComm to
> > facilitate tuning in signals and for text decode whilst
> > retaining the excellent FSK/PSK D TX arrangement that KComm
> > has implemented. However, as soon as the soundcard option is
> > ticked in the settings, the programme seems to now only allow
> > TX also via the soundcard.
> >
> > So to my question: is it possible for KComm to use the PC
> > soundcard for RX tuning and data decode, whilst retaining the
> > K3's data TX capabilities via the serial port?
> >
> > I think even after it hopefully becomes possible to separate
> > the K3's decoded text and radio responses on the serial port,
> > some form of waterfall aid to tuning and band monitoring will
> > still be extremely useful within a logging / control
> > programme, then requiring an input to the soundcard anyway.
> >
> > At the moment, I use the MMVARI data engine for RTTY & PSK31
> > RX, and KComm for TX. But, they fight for the serial port,
> > they don't fit on the screen, you can't easily transfer data
> > from an RX to a TX window etc. etc. It seems to me that KComm
> > does almost all of this already if the above were possible
> > (OK, the data engine needs to support RTTY too, but that's a
> > next step; the K3 display will have to do in the interim as
> > it's much better at tuning & decoding RTTY).
> >
> > It is possible? Could it be inplemented? Any other thoughts
> > or solutions?
> >
> > Many thanks & 73,
> > Ian G4FSU
>
>
>
>

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

[Julian, G4ILO]

Joe has already provided one reason why there is little point in using the computer soundcard for receive and the K3 DSP for transmit. As he said, it would be much more difficult to ensure that TX and RX are both on precisely the same frequency as if the soundcard was doing both, and they do need to be spot on or the other guy will miss the start of your over while his software locks on to it.

One of the changes I will be implementing in the next version is a waterfall to allow CW signals to be "spotted" by clicking on a waterfall. However, that is useful because a) KComm does not decode CW for itself (I have given up trying to make that work) and b) it is also useful for people who decode CW for ear.

My experience has shown that the computer sound card PSK31 Core DLL does a better job of decoding data when signals are weak than the K3 DSP does. In other words, if you have a computer sound card available it is pointless to use it for just a waterfall and not let it do the decoding as well. If this was not the case then what you are suggesting might be worth implementing.

[Julian, G4ILO]

Ian Greenshields wrote

I think even after it hopefully becomes possible to separate the K3's
decoded text and radio responses on the serial port, some form of waterfall
aid to tuning and band monitoring will still be extremely useful within a
logging / control programme, then requiring an input to the soundcard
anyway.

This might be useful in the Linux version, which does not have a built-in PSK via sound card function. But as I gave up using Linux a while back that will not be a priority.

At the moment, I use the MMVARI data engine for RTTY & PSK31 RX, and KComm
for TX. But, they fight for the serial port, they don't fit on the screen,
you can't easily transfer data from an RX to a TX window etc. etc. It seems
to me that KComm does almost all of this already if the above were possible
(OK, the data engine needs to support RTTY too, but that's a next step; the
K3 display will have to do in the interim as it's much better at tuning &
decoding RTTY).

It is possible? Could it be inplemented? Any other thoughts or solutions?

One of the reasons I am not planning to put much more effort into developing sound card support within KComm is that the next version, 1.6, uses Fldigi as a data modes engine. You can control Fldigi from KComm and the text decoded by Fldigi will appear in the KComm RX window for logging. You can have KComm stay on top of Fldigi and position them so the Fldigi waterfall appears below the bottom of the KComm window.

Unfortunately there is still work to be done before this next version can be released, and time is something I don't have much of at the moment, so I can't say when that will be.

You should be able to resolve the problem of two programs fighting over the serial port by using the free Virtual Serial Port Emulator software. I'm pretty sure this is described on the KComm help pages somewhere if you need links to it, as it is also needed if you want to run CW Skimmer.

[Ian Greenshields]

Hi Julian,

Thanks for the responses:

>Joe has already provided one reason why there is little point in using the
>computer soundcard for receive and the K3 DSP for transmit. As he said, it
>would be much more difficult to ensure that TX and RX are both on precisely
>the same frequency as if the soundcard was doing both, and they do need to
>be spot on or the other guy will miss the start of your over while his
>software locks on to it.

Agreed, this is important. The way I've tried to ensure the RX & TX
frequency is the same is to select the soundcard option in KComm, & manually
switch the K3 back to PSK D. If set up correctly I can then see the same
text decoded via KComm's soundcard DLL on screen & the K3's own text
decoder. I've successfully made contacts this way, so am assuming the TX/RX
frequencies are the same (if not, it's a K3 problem, not a KComm one!). Of
course I loose the KComm's TX window & macro capability doing this so I have
to TX via the K3 macros or the paddle which is awfully clunky.

>My experience has shown that the computer sound card PSK31 Core DLL does a
>better job of decoding data when signals are weak than the K3 DSP does. In
>other words, if you have a computer sound card available it is pointless to
>use it for just a waterfall and not let it do the decoding as well. If this
>was not the case then what you are suggesting might be worth implementing.

Yes, I've also noticed this. The K3 RTTY decoder is very good; the K3 PSK31
decoder falls short of soundcard decoders. The opposite seems to be true on
the TX side where the K3 encoders seem better (lower IMD) than the soundcard
variants. This was the main reason that prompted my question - I was trying
to get the best of both worlds.

>You should be able to resolve the problem of two programs fighting over the
>serial port by using the free Virtual Serial Port Emulator software.

I'll give this a try. Thanks.

I think what I'm really looking for is to use the K3's digital D modes and
to have the K3's own decoded text available within the KComm window, with
the option of a soundcard plug-in to reinforce it. Not as easy as I had
hoped!

Thanks anyway & 73,
Ian G4FSU
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

[Ian Greenshields]

Ironically, your Windows version of KComm running under wine seems to work
perfectly, including the PSK31 DLL, whereas I had much trouble with the
linux version (finger trouble on my part, almost certainly).

73 Ian G4FSU

2009/3/1 Julian, G4ILO <[hidden email]>

>
>
> >
> This might be useful in the Linux version, which does not have a built-in
> PSK via sound card function. But as I gave up using Linux a while back that
> will not be a priority.
>
>
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

[Julian, G4ILO]

Ian Greenshields wrote

Yes, I've also noticed this. The K3 RTTY decoder is very good; the K3 PSK31
decoder falls short of soundcard decoders. The opposite seems to be true on
the TX side where the K3 encoders seem better (lower IMD) than the soundcard
variants. This was the main reason that prompted my question - I was trying
to get the best of both worlds.

Interesting observation. I did some comparisons using my KK7UQ IMD Meter to measure the TX IMD and observed no significant difference.

Ironically, your Windows version of KComm running under wine seems to work perfectly, including the PSK31 DLL, whereas I had much trouble with the linux version (finger trouble on my part, almost certainly).

One of the many reasons I gave up Linux as being too much hassle. I couldn't get Fldigi to run at all on it, since I wasn't using the same distribution the developer used to compile it, which is probably the same reason you had trouble with KComm. Also there is no way to allow two programs to share a serial port in Linux, unlike Windows with the VSPE, so I couldn't use KComm and Fldigi both at the same time, even if I had got it working.