Field Day thoughts
18 views
Skip to first unread message
Nate Bargmann
Jun 25, 2012, 2:04:03 PM6/25/12
to SO2SDR list
Here are my thoughts of using SO2SDR for the first time in a contest.
Not only me but several ops used the program and most found its basic
operation of typing <Enter> for each field to be natural. Myself and
one other op had been used to CT for years, he perhaps moreso than me,
but a bit of a crash course and he was off and running putting close to
500 Qs in our log. I operated in S&P mode and that worked well except
when I hit the <Escape> key while reaching for the VFO knob. D'oh!
What worked well.
The program remained responsive. As we didn't generate a truly huge
log, somewhat less than 700 in the log, this may not be a true test.
Rig control and keyer communication remained constant.
All entries were logged.
Editing log fields worked without complaint.
Rig control kept the ops from having to worry about band/mode tracking.
Had rig control not worked for some reason, we would have been forced to
input things manually hence the mode entry enhancement.
Issues to be worked out.
Mode per band duping. This is a biggie for multi-mode events such as
Field Day, IARU, ARRL 10m, state QSO parties, and perhaps other events.
I worked up a quick hack to test the current CAT mode and use it in the
SQL statement for the band duping from the DB. Thinking on that later,
that was going to cause other issues as a station on a band that may
have been worked on CW would not be a dupe in CWR and so on. So, the
duping logic will need to be split along the lines of CW (CW, CWR),
phone (USB, LSB, AM, FM, DV?), and digital (RTTY, RTTYR, PKTUSB, PKTLSB,
PKTFM, etc.). To work around this I had to turn duping off.
At one point a context menu became stuck over the call entry box and all
efforts to clear it failed. Grab keyboard was activated at the time. I
had to jump to a VT and kill SO2SDR and then back to the GUI to restart
it. The issue did not occur again.
The only other issues I had were hardware related causing me to scrap
the use of a docking station as planned and going with a USB to serial
dongle for rig control and then setting udev rules for consistent device
naming. That's not a fault of the program.
There may be some other enhancements that I'll recall once the fog of FD
lifts. :-D
73, de Nate >>
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://www.n0nb.us
Not only me but several ops used the program and most found its basic
operation of typing <Enter> for each field to be natural. Myself and
one other op had been used to CT for years, he perhaps moreso than me,
but a bit of a crash course and he was off and running putting close to
500 Qs in our log. I operated in S&P mode and that worked well except
when I hit the <Escape> key while reaching for the VFO knob. D'oh!
What worked well.
The program remained responsive. As we didn't generate a truly huge
log, somewhat less than 700 in the log, this may not be a true test.
Rig control and keyer communication remained constant.
All entries were logged.
Editing log fields worked without complaint.
Rig control kept the ops from having to worry about band/mode tracking.
Had rig control not worked for some reason, we would have been forced to
input things manually hence the mode entry enhancement.
Issues to be worked out.
Mode per band duping. This is a biggie for multi-mode events such as
Field Day, IARU, ARRL 10m, state QSO parties, and perhaps other events.
I worked up a quick hack to test the current CAT mode and use it in the
SQL statement for the band duping from the DB. Thinking on that later,
that was going to cause other issues as a station on a band that may
have been worked on CW would not be a dupe in CWR and so on. So, the
duping logic will need to be split along the lines of CW (CW, CWR),
phone (USB, LSB, AM, FM, DV?), and digital (RTTY, RTTYR, PKTUSB, PKTLSB,
PKTFM, etc.). To work around this I had to turn duping off.
At one point a context menu became stuck over the call entry box and all
efforts to clear it failed. Grab keyboard was activated at the time. I
had to jump to a VT and kill SO2SDR and then back to the GUI to restart
it. The issue did not occur again.
The only other issues I had were hardware related causing me to scrap
the use of a docking station as planned and going with a USB to serial
dongle for rig control and then setting udev rules for consistent device
naming. That's not a fault of the program.
There may be some other enhancements that I'll recall once the fog of FD
lifts. :-D
73, de Nate >>
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://www.n0nb.us
R. Torsten Clay
Jun 25, 2012, 2:45:46 PM6/25/12
to so2...@googlegroups.com
Thanks for the report- actually the first I have received from someone else
actually using the program! Comments below...
I have personally tested up to about 2300 qso's (IARU contest). One way to
test larger logs would be to import some cabrillo files from other programs,
for example from http://cqww.com/cwlogs/ This would be a very useful test to try.
The Qt QLineEdit has a bunch of features and control commands. It has
undo (ctrl-z) which I have found useful sometimes in case you want a callsign
back after hitting ESC. A list of these should get added to the manual.
Rig control has been very solid for me with the K2 and K3.
Yes, I was expecting this as I have not made the program multi-mode capable. I will
have to look through the dupe logic and see the best way to implement it.
There are other issues on how to do multi-mode and keep the interface simple:
-how to display the number of qso's for different modes? I would rather not
allocate all the screen space to list every mode. One of my dislikes of some other
Windows contest loggers is that you need to have a bunch of little windows open
just to get basic information (qso's, mults needed, calls needed). I want it all in
one (small) window.
About the only thing I can suggest is to keep the current display of qso totals, and
then have a way to switch what is currently displayed between different modes:
ALL/CW/PHONE/DIGI
-there are similar problems then on how to display needed multipliers. Probably
should switch along with the qso totals.
-similar problems on how to display needed calls. How to show if they are needed
only on one mode? What about the needed qso/mult display just above the callsign
entry window?
There are definitely some issues with grab keyboard that have to be fixed.
For example, you can't open the config dialogs with grab keyboard on.
It is only really needed if you are using the bandmap. Then you have to
be able to click in the bandmap window while keyboard focus remains in
the main window. For simple logging I would leave it off.
Tor
N4OGW
actually using the program! Comments below...
On Mon, Jun 25, 2012 at 1:04 PM, Nate Bargmann <n0...@n0nb.us> wrote:
Here are my thoughts of using SO2SDR for the first time in a contest.
Not only me but several ops used the program and most found its basic
operation of typing <Enter> for each field to be natural. Myself and
one other op had been used to CT for years, he perhaps moreso than me,
but a bit of a crash course and he was off and running putting close to
500 Qs in our log. I operated in S&P mode and that worked well except
when I hit the <Escape> key while reaching for the VFO knob. D'oh!
What worked well.
The program remained responsive. As we didn't generate a truly huge
log, somewhat less than 700 in the log, this may not be a true test.
I have personally tested up to about 2300 qso's (IARU contest). One way to
test larger logs would be to import some cabrillo files from other programs,
for example from http://cqww.com/cwlogs/ This would be a very useful test to try.
Rig control and keyer communication remained constant.
All entries were logged.
Editing log fields worked without complaint.
The Qt QLineEdit has a bunch of features and control commands. It has
undo (ctrl-z) which I have found useful sometimes in case you want a callsign
back after hitting ESC. A list of these should get added to the manual.
Rig control kept the ops from having to worry about band/mode tracking.
Had rig control not worked for some reason, we would have been forced to
input things manually hence the mode entry enhancement.
Rig control has been very solid for me with the K2 and K3.
Issues to be worked out.
Mode per band duping. This is a biggie for multi-mode events such as
Field Day, IARU, ARRL 10m, state QSO parties, and perhaps other events.
I worked up a quick hack to test the current CAT mode and use it in the
SQL statement for the band duping from the DB. Thinking on that later,
that was going to cause other issues as a station on a band that may
have been worked on CW would not be a dupe in CWR and so on. So, the
duping logic will need to be split along the lines of CW (CW, CWR),
phone (USB, LSB, AM, FM, DV?), and digital (RTTY, RTTYR, PKTUSB, PKTLSB,
PKTFM, etc.). To work around this I had to turn duping off.
Yes, I was expecting this as I have not made the program multi-mode capable. I will
have to look through the dupe logic and see the best way to implement it.
There are other issues on how to do multi-mode and keep the interface simple:
-how to display the number of qso's for different modes? I would rather not
allocate all the screen space to list every mode. One of my dislikes of some other
Windows contest loggers is that you need to have a bunch of little windows open
just to get basic information (qso's, mults needed, calls needed). I want it all in
one (small) window.
About the only thing I can suggest is to keep the current display of qso totals, and
then have a way to switch what is currently displayed between different modes:
ALL/CW/PHONE/DIGI
-there are similar problems then on how to display needed multipliers. Probably
should switch along with the qso totals.
-similar problems on how to display needed calls. How to show if they are needed
only on one mode? What about the needed qso/mult display just above the callsign
entry window?
At one point a context menu became stuck over the call entry box and all
efforts to clear it failed. Grab keyboard was activated at the time. I
had to jump to a VT and kill SO2SDR and then back to the GUI to restart
it. The issue did not occur again.
There are definitely some issues with grab keyboard that have to be fixed.
For example, you can't open the config dialogs with grab keyboard on.
It is only really needed if you are using the bandmap. Then you have to
be able to click in the bandmap window while keyboard focus remains in
the main window. For simple logging I would leave it off.
Tor
N4OGW
Nate Bargmann
Jun 25, 2012, 3:57:35 PM6/25/12
to so2...@googlegroups.com
* On 2012 25 Jun 13:47 -0500, R. Torsten Clay wrote:
> Thanks for the report- actually the first I have received from someone else
> actually using the program! Comments below...
I intend to continue advocating SO2SDR even as a simple logger so there
> Thanks for the report- actually the first I have received from someone else
> actually using the program! Comments below...
will hopefully be more reports in the future.
> The Qt QLineEdit has a bunch of features and control commands. It has
> undo (ctrl-z) which I have found useful sometimes in case you want a
> callsign back after hitting ESC. A list of these should get added to
> the manual.
incorporate that into the manual.
> Rig control has been very solid for me with the K2 and K3.
One future enhancement would be for a network socket to rigctld but not
by using the netrigctl model. The reason for a separate socket would be
to communication with a rigctld based on Hamlib 3 while SO2SDR might be
linked against Hamlib 1.2.x. This would be most useful for Hamlib beta
testers using SO2SDR on Windows. This is something I may work on down
the road a bit.
> Yes, I was expecting this as I have not made the program multi-mode
> capable. I will have to look through the dupe logic and see the best
> way to implement it.
>
> There are other issues on how to do multi-mode and keep the interface
> simple:
>
> -how to display the number of qso's for different modes? I would
> rather not allocate all the screen space to list every mode. One of my
> dislikes of some other Windows contest loggers is that you need to
> have a bunch of little windows open just to get basic information
> (qso's, mults needed, calls needed). I want it all in one (small)
> window.
gave the ops confidence to sit right down and use it. Only myself and
Ken, KK0HF, are frequent users of contest loggers. The others only see
it at Field Day.
> About the only thing I can suggest is to keep the current display of
> qso totals, and then have a way to switch what is currently displayed
> between different modes: ALL/CW/PHONE/DIGI
toggle from All to CW/Phone/Digi and back?
> -there are similar problems then on how to display needed multipliers.
> Probably should switch along with the qso totals.
use this capability. Of those IARU would be the most demanding
involving all bands. The KS QSO party, for example, has 105 mults for
those outside Kansas and 50 + 1 (DX) for those of us in Kansas.
> -similar problems on how to display needed calls. How to show if they
> are needed only on one mode? What about the needed qso/mult display
> just above the callsign entry window?
most ornerous, but not as bad as I thought:
8. Multipliers:
8.1. The total number of ITU zones plus IARU member society HQ
stations worked on each band (not mode). IARU officials represent a
maximum of four multipliers per band (AC, R1, R2 and R3).
8.2. IARU member society HQ stations and officials do not
count for zone multipliers.
I would like to get the duping completed solidly first and then work
toward the other stuff.
> There are definitely some issues with grab keyboard that have to be fixed.
> For example, you can't open the config dialogs with grab keyboard on.
>
> It is only really needed if you are using the bandmap. Then you have to
> be able to click in the bandmap window while keyboard focus remains in
> the main window. For simple logging I would leave it off.
Right now I am more interested in logging, however, I would like to try
the bandmap at some point but lack the hardware even though I have a P3.
Softrocks no longer seem to be available so I'm not sure what I should
look for. Any suggestions?
R. Torsten Clay
Jun 25, 2012, 4:50:27 PM6/25/12
to so2...@googlegroups.com
Either a hot key that steps through the display or three hotkeys that
> About the only thing I can suggest is to keep the current display of
> qso totals, and then have a way to switch what is currently displayed
> between different modes: ALL/CW/PHONE/DIGI
toggle from All to CW/Phone/Digi and back?
I will try a single hot key and maybe a spin box. There will probably be a new
config option in the contest config files to list which modes are enabled.
> -there are similar problems then on how to display needed multipliers.For those of us in the USA, IARU, ARRL 10, and state QSO parties would
> Probably should switch along with the qso totals.
use this capability. Of those IARU would be the most demanding
involving all bands. The KS QSO party, for example, has 105 mults for
those outside Kansas and 50 + 1 (DX) for those of us in Kansas.
IARU is currently well under control for a single mode- it is one contest I
usually get to operate seriously every year. Basically, there are two kinds of
mults, zones and HQ's/IARU officials. HQ's and IARU officials get scored
exactly the same way.
I will try working on this as I think I am probably more familiar with the
details of how the dupe/score stuff work.
I would like to get the duping completed solidly first and then work
toward the other stuff.
Are there any multi-mode contests where you can work a station on
any but only one one several modes? I think it is always allowed to work stations
again on multiple modes. If we just allow for the latter, the logic is much easier to
implement.
Right now I am more interested in logging, however, I would like to try
the bandmap at some point but lack the hardware even though I have a P3.
Softrocks no longer seem to be available so I'm not sure what I should
look for. Any suggestions?
I think softrocks are still around, see http://www.kb9yig.com/. You probably
need to email Tony to get the kit availability. I am using the LP-PAN for my K3's
now.
Tor
R. Torsten Clay
Jul 11, 2012, 2:05:42 PM7/11/12
to so2...@googlegroups.com
There is another problem with multi-mode scoring: some radios will be in SSB mode for digital
qsos, so it is not always possible to decide whether the contact is CW/PHONE/DIGI based on
what hamlib returns.
Tor
qsos, so it is not always possible to decide whether the contact is CW/PHONE/DIGI based on
what hamlib returns.
Tor
Nate Bargmann
Jul 13, 2012, 3:29:47 PM7/13/12
to so2...@googlegroups.com
QSOs are processed.
Here is an outline of how digital logging support could work.
For digital modes Fldigi is started. Before actually starting Fldigi
SO2SDR would shutdown its Hamlib threads and prepare to accept logging
data by the methods described at:
http://www.w1hkj.com/FldigiHelp-3.21/LogExports.html
Granted, that first paragraph is short on developer details. I know
that CQRlog accepts log data from Fldigi in this manner.
Fldigi's logger.cxx file contains the exported data function which
appears to be send_IPC_log() starting at line 143:
http://git.berlios.de/cgi-bin/gitweb.cgi?p=fldigi;a=blob;f=src/logger/logger.cxx;h=5243599fbc4c191951d65e7ff50b173769884d3b;hb=HEAD
The message format is from Xlog and is described in Xlog's remote.c
file:
http://cvs.savannah.gnu.org/viewvc/xlog/src/remote.c?revision=1.46&root=xlog&view=markup
Once the Hamlib threads are closed SO2SDR will start Fldigi and simply
accept whatever Fldigi sends it. It will be up to the operator to
assure the log data is valid. SO2SDR can score the log according to the
.cfg file. Fldigi will handle the radio control, if used, and it takes
care of recording the digital mode regardless of the actual rig mode
used.
This is all without getting into the XMLRPC remote control that Fldigi
supports.
Once Fldigi is closed and a non-digital mode is selected, the SO2SDR
opens the rig control threads and goes back to logging CW and phone
QSOs.
How does that sound?
R. Torsten Clay
Jul 16, 2012, 1:10:39 PM7/16/12
to so2...@googlegroups.com
What you are describing might work crudely for digital, but I don't think it is a very good
solution for serious RTTY contesting. If one is forced to use the fldigi logbook
(which I admit I have never looked at) I think that pretty much precludes SO2R operation.
It also might eat up a ton of screen space.
What about using this instead to control fldigi:
http://www.w1hkj.com/FldigiHelp-3.21/xmlrpc-control.html
That seems to allow much more detailed control. It might then be possible to keep hamlib
active only in SO2SDR. Ideally SO2SDR should handle all logging functions, and fldigi
should only be used for receiving/transmitting data. Like what N1MM does with rtty.
Tor
N4OGW
solution for serious RTTY contesting. If one is forced to use the fldigi logbook
(which I admit I have never looked at) I think that pretty much precludes SO2R operation.
It also might eat up a ton of screen space.
What about using this instead to control fldigi:
http://www.w1hkj.com/FldigiHelp-3.21/xmlrpc-control.html
That seems to allow much more detailed control. It might then be possible to keep hamlib
active only in SO2SDR. Ideally SO2SDR should handle all logging functions, and fldigi
should only be used for receiving/transmitting data. Like what N1MM does with rtty.
Tor
N4OGW
Nate Bargmann
Jul 16, 2012, 1:26:27 PM7/16/12
to so2...@googlegroups.com
* On 2012 16 Jul 12:11 -0500, R. Torsten Clay wrote:
> What you are describing might work crudely for digital, but I don't
> think it is a very good solution for serious RTTY contesting. If one
> is forced to use the fldigi logbook (which I admit I have never looked
> at) I think that pretty much precludes SO2R operation.
In the scenario I outlined, yes the data is saved to the Fldigi logbook,
> What you are describing might work crudely for digital, but I don't
> think it is a very good solution for serious RTTY contesting. If one
> is forced to use the fldigi logbook (which I admit I have never looked
> at) I think that pretty much precludes SO2R operation.
but it is also and always sends it to the IPC mechanism.
> It also might eat up a ton of screen space.
> What about using this instead to control fldigi:
>
> http://www.w1hkj.com/FldigiHelp-3.21/xmlrpc-control.html
>
> That seems to allow much more detailed control. It might then be
> possible to keep hamlib active only in SO2SDR. Ideally SO2SDR should
> handle all logging functions, and fldigi should only be used for
> receiving/transmitting data. Like what N1MM does with rtty.
probably the most useful option. Beyond RTTY PSK31 and other mode
support would be useful to me.
Reply all
Reply to author
Forward
0 new messages