ARRL-DX-CW

[John AC6SL]

I have been looking for a linux substitute for N1MM contest logger.

so2sdr is first linux logger that comes close to providing the desired functionality.

Setup issues (Ubuntu 13.10 on 2-core laptop, Elecraft K3, LP-PAN2):

so2sdr 1.4.0 built & installed OK, but it did not like my Creative X-fi USB soundcard,

i.e. name appeared in list, but with "X", even though that card supports 96k samples/sec.

Fortunately, E-mu 0202 USB soundcard is acceptable to so2sdr.

so2sdr only supports CW keying via Winkey, which I do not have. Elecraft K3 supports

"send Morse" command, I verified it works from rigctl, and then made a simple change

to so2sdr which allows it to use hamlib:rig_send_morse(), at least for one radio.

(Speed control is by the knob on the K3, and interrupt is by hitting paddle.

I do not know if speed change and interrupt functions are accessible via hamlib.)

I set up rigctld for first time, and found so2sdr can be configured to use it.

While trying a simulated ARRL DX contest, it appears that so2sdr will not accept

a valid exchange for US or Canada stations, e.g. "599 CA" sends "AGN?".

My work-around was to work DX only!

I also noticed that File->Export_Cabrillo could not be completed, because the

Cabrillo dialog is slightly too tall, and the "Cancel" and "OK" buttons are off

the bottom edge of the screen. The work-around for Ubuntu Unity is to use the

Workspace Switcher, which provides access to a larger, 2x2 virtual screen.

I have been unable to get the Bandmap spectrum to agree with the frequency

indicator, the frequency scale, and the spotted callsigns. The spectrum

always appears to be inverted around the indicated frequency. I tried

reversing I & Q, changing the code in so2sdr.cpp:2608 "invert spectrum if needed",

and changing the K3 mode to CWR, but did not find a proper solution.

I do notice that when a call is logged, a pink highlight is added to the

Bandmap, and that highlight tracks correctly, i.e. as the radio's VFO is

turned, the white data scrolls opposite direction from the pink highlight.

Config->Bandscope->IF_offset works, but each time the Bandmap window size is

adjusted, the offset appears to need adjustment.

Working the ARRL DX CW contest:

The first time I tried to transmit my call (S&P mode), the K3 powered off!

This problem happened only once. (In initial testing of the hamlib:rig_send_morse()

change, the K3 had got into a funny state, where receive audio was muted, but

that problem never happened during the contest.)

The Help->Help document says "tab to enter S&P", but how to get back? How to "wipe"

a QSO? I finally read the "Function Key" section and found out about Esc.

Even so, the behavior of Esc seems to depend on some state of S&P mode.

Often, the callsign and exchange fields would go blank unexpectedly. I now

suspect that often it was because I was trying to press F1, and hitting

Esc or "1" by accident. My work-around was to use K3 memory keys to complete

the QSO, then put the K3 in "Test" to prevent transmission, and use ^Z to

recover the wiped fields, and re-execute the S&P contact, and then trying

to remember to disable "Test" mode on the K3.

Why is there often a checkmark to the right of the Exchange field? What does

it signify?

The Bandmap display is very useful. When a signal is too faint to see, it is

also too faint to hear. It was very helpful in weeding out domestic signals,

or those that were too close together to be workable. But, the Bandmap often

stalls, i.e. the horizontal scrolling stops. The work-around is to restart it

by hitting Windows->Bandmap_1 twice. Sometimes, this stall happens when a

CW transmission is sent (there is always a slight glitch),

but sometimes it happens when nothing else is

going on. When the Bandmap stalls, the "waterfall illusion" is strong!

Sometimes, I would see that frequency data was not being logged; the field

appeared blank, but when double-clicked, it displayed "150". I was quitting

and restarting so2sdr as a work-around, until I noticed that the frequency

scale on the Bandmap had gone bad. Restarting the hamlib connection with

Config->Radios->OK is the work-around. (On one of the affected QSOs, where

I inserted 21000000, File->Export_ADIF incorrectly produced "<BAND:3>20M",

even though the frequency was "21.000".)

Because of the inverted Bandmap spectrum, and the IF_offset being slightly

off (while I'm using 250Hz audio filter), the ctrl up/down arrows were not

useful, i.e. I had to turn the VFO knob on the K3, in order for signals

to be centered in the 250Hz audio filter.

I saw that if a callsign was corrected, after being annotated on the

Bandmap, it does not get corrected on the Bandmap.

Callsigns for completed QSOs are correctly annotated in the Bandmap,

but when a call is entered, and it is a dupe, it does not become annotated.

I tried using the "-" to annotate a dupe, but it did appear to work.

Instead, I got into a funny state, with only 1 QSO in the log; fortunately,

quit, restart so2sdr, and repopen the contest restored the log.

I noted that "40m" in the Summary is always highlighted, and eventually

realized that it is because Radio 2 is on 40m, even though Radio 2 is

not set up in Config->Radios. I only have Radio 1, so the Radio 2 fields

are superfluous: I would like to be able to hide them.

There is a per Radio "Summary" above Radio 1's fields, but it is not

formatted correctly, i.e. the 10m column is missing, and the bottom edge

of both lines of text is clipped off. Perhaps a font problem?

The DX...@arrl.org robot had 3 complaints about the .cbr log file:

    "LOCATION: CM87..." so2sdr should have put my section there, by default.

    "'ARRL-DX' is not the CONTEST: name I was expecting.  I am setting it to ARRL-DX-CW."

    "No value is found for CATEGORY-BAND:..." should be "ALL", by default.

Summary:

I am favorably impressed with so2sdr, and made 310 Qs in the ARRL DX CW.

The 3 problems that need further investigation:

1. connection to rigctld needs to be more reliable.

2. Bandmap spectrum is inverted.

3. Bandmap stalls.

-John AC6SL

[Eric Tichansky]

John

Sorry to hear you are having so many issues. I've been running 'so2sdr'
here since maybe Oct. of last year and haven't really experienced any of
the issues you are having, running most major contests (CQWW, ARRL160,
CW Sprint, CQ160). Setup is Archlinux, latest GIT checkout of so2sdr,
2xK3s, Microham MK2R, 2xLP-PANs, 2x M-Audiophile 2496 cards.

You may be further ahead to invest in a Winkey based keyer. There
should be some relatively cheap options out there. That would eliminate
some of the workarounds you had to perform to key the K3. I'm guessing
you had to run rigclt to get the CW keying to work? Otherwise, rigctl
shouldn't be required for CAT, maybe I'm missing something?

Yes, ARRL DX is DX only! There is no reason to log domestic QSOs, they
are zero points.

What screen resolution are you using? Regarding the Cabrillo export
(perhaps other dialog boxes), it may be better to keep to a maximum
height and if a particular dialog exceeds that, setup tabs to group
fields. That should satisfy low resolution screens. Tor?

Sounds like you have some strange things going on with the bandmap. Does
the LP-Pan and soundcard combo work in other applications (cringe....
Windows, PowerSDR-IF, NaP3)? Appears you are looking at the image,
which I periodically see when one of my cables needs re-seated. Do you
see any of the primary traces? They should criss-cross the images
around the IF center and following tuning. I haven't had the bandmap
outright stall. This may be an indication of a soundcard, driver, or
other hardware/system issue. Again, maybe Tor would have better insight
on that behavior and the other related bandmap issues you cited.

The problems w/ the K3 behavior, powering off, keying, etc, are all
likely artifacts of using rigctl, could be attributable to Hamlib bugginess.

I've never noticed the IF offset needing adjustment when resizing the
bandmap. The "center" (ie. where your VFO is tuned) needs adjusted, but
just hold-click and drag it back to the middle of the window. The IF
offset should still be fine (at least here).

Regarding 'esc'. Yes, there are several layers of 'esc' behavior. 'esc'
can kill CW, pause auto-CQ, clear currently focused field, clear QSO,
etc. The best way to get familiar with it is to use the program for a
while, but generally, the 'esc' behavior should be "logical". Think of
escape as a layered "abort", based on whatever is going on at the moment.

The callsign/exch fields should never go blank unless 'esc' is pressed
to clear them. F1, etc. should not wipe the fields. I'd be interested
in knowing the exact sequence of keystrokes that caused that behavior.

The checkmark beside the exchange field signifies that what is entered
is valid exchange data. If there is no checkmark, and you press enter
to log the QSO, "AGN?" will be forced to request a repeat of the
information. You can force the QSO to be logged despite invalid data
with CTRL-enter.

Regarding the Summary text being cut off, that may be another thing
caused by a low resolution screen. Are you able to increase the screen
resolution?

73 Eric NO3M

> --
> You received this message because you are subscribed to the Google
> Groups "so2sdr" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to so2sdr+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Howard Hoyt]

Just to second Eric's comments on WK. I actually base SO2R on it.

We also have WKlite for one of our multi positions. VERY cheap, and i
am betting the saved CPU workload/heating allows WK or (SO1R- WK lite)
to pretty much pay for itself.

As Eric already said, ARRLDX is DX only, so that is a non-issue.

73, Howie N4AF
http://n4af.net

[R. Torsten Clay]

Hi John,

Thanks for the report. I was also in ARRL DX a little using so2sdr.
See my comments below:

On Mon, Feb 17, 2014 at 12:34 PM, John AC6SL <jnog...@gmail.com> wrote:
> I have been looking for a linux substitute for N1MM contest logger.
> so2sdr is first linux logger that comes close to providing the desired
> functionality.
>
> Setup issues (Ubuntu 13.10 on 2-core laptop, Elecraft K3, LP-PAN2):
> so2sdr 1.4.0 built & installed OK, but it did not like my Creative X-fi USB
> soundcard,

First, I would strongly suggest trying the git version. I haven't been
very good about updating the
released versions on google code. To use the git version you need to
do the following:

git clone https://github.com/n4ogw/so2sdr.git
cd so2sdr
qmake
make
sudo make install

> i.e. name appeared in list, but with "X", even though that card supports 96k
> samples/sec.
> Fortunately, E-mu 0202 USB soundcard is acceptable to so2sdr.
>

The "X" is a guess, you can still try using one of those devices.

> so2sdr only supports CW keying via Winkey, which I do not have. Elecraft K3
> supports
> "send Morse" command, I verified it works from rigctl, and then made a
> simple change
> to so2sdr which allows it to use hamlib:rig_send_morse(), at least for one
> radio.
> (Speed control is by the knob on the K3, and interrupt is by hitting paddle.
> I do not know if speed change and interrupt functions are accessible via
> hamlib.)
>

I would be curious what changes you made. That should work, but for
two radio use it would
be hard to avoid accidentally transmitting on both radios.

> I set up rigctld for first time, and found so2sdr can be configured to use
> it.
>
> While trying a simulated ARRL DX contest, it appears that so2sdr will not
> accept
> a valid exchange for US or Canada stations, e.g. "599 CA" sends "AGN?".
> My work-around was to work DX only!
>

Yes, see below re the checkmarks

> I also noticed that File->Export_Cabrillo could not be completed, because
> the
> Cabrillo dialog is slightly too tall, and the "Cancel" and "OK" buttons are
> off
> the bottom edge of the screen. The work-around for Ubuntu Unity is to use
> the
> Workspace Switcher, which provides access to a larger, 2x2 virtual screen.
>

I ran into the same problem yesterday. It isn't a problem on my
logging computer, but I then
ran so2sdr on a laptop that didn't have enough vertical resolution. I
should probably add
scroll bars to that dialog.

> I have been unable to get the Bandmap spectrum to agree with the frequency
> indicator, the frequency scale, and the spotted callsigns. The spectrum
> always appears to be inverted around the indicated frequency. I tried
> reversing I & Q, changing the code in so2sdr.cpp:2608 "invert spectrum if
> needed",
> and changing the K3 mode to CWR, but did not find a proper solution.
> I do notice that when a call is logged, a pink highlight is added to the
> Bandmap, and that highlight tracks correctly, i.e. as the radio's VFO is
> turned, the white data scrolls opposite direction from the pink highlight.
>
> Config->Bandscope->IF_offset works, but each time the Bandmap window size is
> adjusted, the offset appears to need adjustment.
>

I use two K3/LP-PAN's in my station. I have the offset set to -1010
for one and -1020 for
the other- there will be a small variation depending on the exact xtal
frequency in the LP-PAN.
I also have earlier model LP-PAN's, but as far as I know, Larry didn't
change the center
frequency in later models. You might have the I or Q channel cables
reversed. You should be
quite close to zero beat by clicking on the black dots.

I also suspect that using rigctld won't work. For the K3, the IF
offset actually depends
on the setting of the filter width. The K3 includes a special serial
command to read the
exact offset; so2sdr uses this to correctly compute the right offset.
It is possible that
rigctld does not pass/understand this command since it is specific to
the K3. When you
change the K3 filter bandwidth, do signals move relative to the center
freq? If so, then
the filter offset command is not working.

> Working the ARRL DX CW contest:
> The first time I tried to transmit my call (S&P mode), the K3 powered off!
> This problem happened only once. (In initial testing of the
> hamlib:rig_send_morse()
> change, the K3 had got into a funny state, where receive audio was muted,
> but
> that problem never happened during the contest.)
>

Maybe hamlib was setting the RTS and/or DTR lines? Did you have those lines
turned on in the K3?

> The Help->Help document says "tab to enter S&P", but how to get back? How to
> "wipe"
> a QSO? I finally read the "Function Key" section and found out about Esc.
> Even so, the behavior of Esc seems to depend on some state of S&P mode.
>

Yes, Esc does a lot of things. The overall behavior is similar to
trlog but might
take some getting used to compared to N1MM. In general, Esc gets you out of
things and resets back to CQ mode, but the number of times you might
have to press it varies. So the first Esc in S&P clears the callsign, then
the second will get you back to CQ mode.

> Often, the callsign and exchange fields would go blank unexpectedly. I now
> suspect that often it was because I was trying to press F1, and hitting
> Esc or "1" by accident. My work-around was to use K3 memory keys to complete
> the QSO, then put the K3 in "Test" to prevent transmission, and use ^Z to
> recover the wiped fields, and re-execute the S&P contact, and then trying
> to remember to disable "Test" mode on the K3.
>
> Why is there often a checkmark to the right of the Exchange field? What does
> it signify?
>

The checkmark means that the qso has passed validation (the received exchange
makes sense) and is included in the log and scoring. There is no way
to delete a qso, but if
you need to remove a qso from the log you can uncheck it. Then it will
not appear
in the cabrillo.

You actually can work US/VE stations in the ARRL DX. They won't pass
the validation,
so you have to "force" log them by pressing Ctrl+Enter instead of just
Enter. They
won't appear in the Cabrillo output.

> The Bandmap display is very useful. When a signal is too faint to see, it is
> also too faint to hear. It was very helpful in weeding out domestic signals,
> or those that were too close together to be workable. But, the Bandmap often
> stalls, i.e. the horizontal scrolling stops. The work-around is to restart
> it
> by hitting Windows->Bandmap_1 twice. Sometimes, this stall happens when a
> CW transmission is sent (there is always a slight glitch),
> but sometimes it happens when nothing else is
> going on. When the Bandmap stalls, the "waterfall illusion" is strong!
>

It shouldn't stall, so something is wrong there. I am not sure what. There is
a lag after logging each qso- I would like to get rid of that.

Here the scrolling is much smoother on my station computer (older 3
GHz Core 2 Duo) than
my laptop (newer i7, more RAM). I suspect it is because the station
computer has a better video card
(Nvidia) rather than the Intel graphics of the laptop.

The bandmap has changed the way I operate a lot (see the NCJ article I
wrote). In most contests (not Sprint) I just click on signals to do S&P.

> Sometimes, I would see that frequency data was not being logged; the field
> appeared blank, but when double-clicked, it displayed "150". I was quitting
> and restarting so2sdr as a work-around, until I noticed that the frequency
> scale on the Bandmap had gone bad. Restarting the hamlib connection with
> Config->Radios->OK is the work-around. (On one of the affected QSOs, where
> I inserted 21000000, File->Export_ADIF incorrectly produced "<BAND:3>20M",
> even though the frequency was "21.000".)
>
> Because of the inverted Bandmap spectrum, and the IF_offset being slightly
> off (while I'm using 250Hz audio filter), the ctrl up/down arrows were not
> useful, i.e. I had to turn the VFO knob on the K3, in order for signals
> to be centered in the 250Hz audio filter.
>

I suspect rigctld is not working properly. That and the way you are sending cw
through the K3 might be what is stalling the bandmap.

> I saw that if a callsign was corrected, after being annotated on the
> Bandmap, it does not get corrected on the Bandmap.
>
> Callsigns for completed QSOs are correctly annotated in the Bandmap,
> but when a call is entered, and it is a dupe, it does not become annotated.
> I tried using the "-" to annotate a dupe, but it did appear to work.
> Instead, I got into a funny state, with only 1 QSO in the log; fortunately,
> quit, restart so2sdr, and repopen the contest restored the log.
>

OK- you have to press space after typing in the callsign in S&P mode
for it to show up on the bandmap. I should probably make an option
to spot all entered calls in S&P mode.

> I noted that "40m" in the Summary is always highlighted, and eventually
> realized that it is because Radio 2 is on 40m, even though Radio 2 is
> not set up in Config->Radios. I only have Radio 1, so the Radio 2 fields
> are superfluous: I would like to be able to hide them.
>

Good point- I almost always have two radios on, I'll have to think of the
best way to handle that.

> There is a per Radio "Summary" above Radio 1's fields, but it is not
> formatted correctly, i.e. the 10m column is missing, and the bottom edge
> of both lines of text is clipped off. Perhaps a font problem?
>

Yes, that is a font issue, somehow the wrong size font is being used.
I'll add that to the list of things to take a look at.

> The DX...@arrl.org robot had 3 complaints about the .cbr log file:
> "LOCATION: CM87..." so2sdr should have put my section there, by default.
> "'ARRL-DX' is not the CONTEST: name I was expecting. I am setting it to
> ARRL-DX-CW."

Yes, the contest name needs fixing there.


Tor
N4OGW

> "No value is found for CATEGORY-BAND:..." should be "ALL", by default.
>
> Summary:
> I am favorably impressed with so2sdr, and made 310 Qs in the ARRL DX CW.
>
> The 3 problems that need further investigation:
> 1. connection to rigctld needs to be more reliable.
> 2. Bandmap spectrum is inverted.
> 3. Bandmap stalls.
>
>
> -John AC6SL
>