TLF run mode problem

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

TLF run mode problem

Drew Arnett
Hi,

I tried using the tlf packaged with Debian buster for the IARU HF
contest.  I had a problem with trying to operate in run mode.

I've used TLF and been very happy with it in the past.  Love the
leanness.  Love the keyboard only operation.

I think I've used run mode before, but not much I think.  I could not
get it to work this time.  Observed behavior:

S&P works fine.  Enter send message works as expected.  Type in his
callsign in the callsign box and then hit enter and TLF sends my
callsign.  Type in his exchange and hit enter in the exchange box and
TLF sends TU and my exchange and logs the QSO.  Great!

Run mode has problems.  Start auto CQ which works fine.  As soon as I
start typing in a callsign, the auto CQ stops and the "AUTO_CQ" marker
in the upper left corner changes to "S&P".  (Is this a clue?)  I type
in his callsign and hit enter in the callsign box.  TLF sends mycall.
Wrong behavior.  I'm expecting it to send his call and my exchange.  I
enter his exchange and hit enter in the exchange box and it sends TU
and my exchange.  Also wrong behavior.  In both cases, it sends the
correct thing for S&P, but not the correct thing for run mode.

Am I doing something wrong?  Do I have something misconfigured?  Is it
a bug in the SW?  Or if this should work, and it was a mistake in
debian packaging deltas, should I file a debian bug?

My setup...

OS:  debian buster live 10.0.0 xfce

TLF (and hamlib)
-----
user@debian:~$ dpkg --list | grep tlf
ii  tlf                                    1.3.2-1
    amd64        console based ham radio contest logger
user@debian:~$ dpkg --list | grep hamlib
ii  libhamlib2:amd64                       3.3-5
    amd64        Run-time library to control radio transceivers and
receivers
-----

Debian packaging info:
     https://packages.debian.org/buster/tlf
     https://packages.debian.org/buster/libhamlib2

I have a directory I'm running tlf from (no command line options).
-----
$ ls -lR
.:
total 548
-rw-r--r-- 1 user user 191309 Jul 13 12:28 8316241.gif
-rw-r--r-- 1 user user 264631 Jul 11 02:05 callmaster
-rw-r--r-- 1 user user  79308 Jun 30 23:52 cty.dat
-rw-r--r-- 1 user user    176 Jul 13 14:33 iarulog.txt
-rw-r--r-- 1 user user   4010 Jul 13 14:15 logcfg.dat
-rw-r--r-- 1 user user   7926 Jul 13 12:13 pywinkeyerdaemon.py
drwxr-xr-x 2 user user     80 Jul 13 14:19 rules
-rw-r--r-- 1 user user    101 Jul 13 14:39 tlfmarkers

./rules:
total 4
-rw-r--r-- 1 user user 2136 Jul 13 14:18 iaru
-----

Descriptions of files:
     .gif is downloaded ITU zones and regions map
     callmaster is downloaded partials
     cty.dat is downloaded dxcc
     iarulog.txt is my logfile
     logcfg.dat attached
     pywinkeyerdaemon.py is my cwdaemon server
     rules/iaru attached
     tlfmarkers tlf temp file for bandmap if I understand correctly

I've attached logcfg.dat and rules/iaru but here they are inline.
logcfg.dat
-----
RULES=iaru
EDITOR=vim
CALL=KB9FKO
TIME_OFFSET=0
NETKEYER
NETKEYERPORT=6789
NETKEYERHOST=127.0.0.1
CWSPEED=20
CQDELAY=3
RADIO_CONTROL
RIGMODEL=229
RIGSPEED=38400
RIGPORT=/dev/ttyS0
BANDMAP=S,900  # skipdupes, 900s livetime
SCOREWINDOW
CHECKWINDOW
PARTIALS
SUNSPOTS=30
SFI=100
NOB4
MARKERS=tlfmarkers
-----

rules/iaru
-----
CONTEST=iaru
LOGFILE=iarulog.txt
CONTEST_MODE
F1=CQ DE % TEST
F2=%
F3=5NN 6
F4=TU
F5=@
F6=%
F7=
F8=AGN
F9=?
F10=QRZ?
F11=
F12=CQ DE % TEST
#
CQ_TU_MSG=TU %
S&P_TU_MSG=TU 5NN 6
ITUMULT
RECALL_MULTS
-----

Thanks you and best regards,

Drew Arnett
kb9fko

_______________________________________________
Tlf-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tlf-devel

logcfg.dat (410 bytes) Download Attachment
iaru (270 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TLF run mode problem

Thomas Beierlein-4
Hi Drew,

welcome to the list and thanks for the report.

Am Tue, 30 Jul 2019 14:26:25 +0000
schrieb Drew Arnett <[hidden email]>:
> Hi,
...
> I think I've used run mode before, but not much I think.  I could not
> get it to work this time.  Observed behavior:
...
> Run mode has problems.  Start auto CQ which works fine.  As soon as I
> start typing in a callsign, the auto CQ stops and the "AUTO_CQ" marker
> in the upper left corner changes to "S&P".  (Is this a clue?)  I type
> in his callsign and hit enter in the callsign box.  TLF sends mycall.
> Wrong behavior.  I'm expecting it to send his call and my exchange.  I
> enter his exchange and hit enter in the exchange box and it sends TU
> and my exchange.  Also wrong behavior.  In both cases, it sends the
> correct thing for S&P, but not the correct thing for run mode.
>
As you are using auto CQ I assume you work CW.
The change to "S&P" in upper left corner shows the problem.
Somehow TLF switched to S&P mode and the wrong behavior is to be
expected afterwards. But it should not change to S&P from auto CQ.

I tested tlf-1.3.2 (compiled from the sources here) with your
provided settings (Thanks) and it worked as expected - staying in RUN
mode after stopping auto CQ by inserting a call.

> Am I doing something wrong?  Do I have something misconfigured?  Is it
> a bug in the SW?  Or if this should work, and it was a mistake in
> debian packaging deltas, should I file a debian bug?
>
Seems we can drop 'misconfiguration' from the list (see my tests above).
I had a short look into the code and normally your problem should not
happen - you can switch to auto CQ only in RUN mode and switch to S&P
only AFTER you leave auto CQ. Maybe I need to dig into that further.

Can someone from Debian please check tlf-1.3.2-1 for the problem
(Ervin?). At a first look there seems to be no particularities.

Maybe you can give a little bit more information on some points:

- Is the bad behavior reproducible or did it only happens once?
- If reproducible can you check with a different contest (e.g. CQWW)?

73, de Tom DL1JBE

>
> Thanks you and best regards,
>
> Drew Arnett
> kb9fko



--
"Do what is needful!"
Ursula LeGuin: Earthsea
--


_______________________________________________
Tlf-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Reply | Threaded
Open this post in threaded view
|

Re: TLF run mode problem

Ervin Hegedüs - HA2OS
Hi all,

On Wed, Jul 31, 2019 at 07:57:31AM +0200, Thomas Beierlein wrote:
> Am Tue, 30 Jul 2019 14:26:25 +0000
> schrieb Drew Arnett <[hidden email]>:
>
> I tested tlf-1.3.2 (compiled from the sources here) with your
> provided settings (Thanks) and it worked as expected - staying in RUN
> mode after stopping auto CQ by inserting a call.
>
[...]
 
> Can someone from Debian please check tlf-1.3.2-1 for the problem
> (Ervin?). At a first look there seems to be no particularities.

sure, I'll check out soon.



73, Ervin
 

_______________________________________________
Tlf-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Reply | Threaded
Open this post in threaded view
|

Re: TLF run mode problem

Ervin Hegedüs - HA2OS
In reply to this post by Drew Arnett
Drew, Thomas, and all,

On Tue, Jul 30, 2019 at 02:26:25PM +0000, Drew Arnett wrote:

I don't have Debian Buster actually, but have a Debian SID - it's
not so far from Buster :), and all related components are same as
your side:

# dpkg -l tlf *hamlib* | grep ^ii
ii  libhamlib++-dev:amd64 3.3-5+b1     amd64        Development C++ library to control radio transceivers and receivers
ii  libhamlib-dev:amd64   3.3-5+b1     amd64        Development library to control radio transceivers and receivers
ii  libhamlib-utils       3.3-5+b1     amd64        Utilities to support the hamlib radio control library
ii  libhamlib2:amd64      3.3-5+b1     amd64        Run-time library to control radio transceivers and receivers
ii  libhamlib2++c2:amd64  3.3-5+b1     amd64        Run-time C++ library to control radio transceivers and receivers
ii  libhamlib2-tcl        3.3-5+b1     amd64        Run-time Tcl library to control radio transceivers and receivers
ii  tlf                   1.3.2-1      amd64        console based ham radio contest logger

On that machine, I don't have a phisycal connect with RIG, so
I've used `rigctld -m 1`, set up the "virtual" rig on another
terminal ("rigctl -m 2; F 14002000"), and started Tlf with Drew's
config.

> Run mode has problems.  Start auto CQ which works fine.  As soon as I
> start typing in a callsign, the auto CQ stops and the "AUTO_CQ" marker
> in the upper left corner changes to "S&P".

I can't reproduce this issue. When AUTO_CQ sent the CQ, and I
typed a foreign call, it switched to "LOG". I finished the
callsign, pressed TAB, entered the zone, pressed ENTER, then Tlf
sent "TU KB9FKO", and stayed in LOG mode.

I pressed F12, Tlf switched to AUTO_CQ, and started to sent the
CQ again.

> (Is this a clue?)  I type
> in his callsign and hit enter in the callsign box.  TLF sends mycall.
> Wrong behavior.  I'm expecting it to send his call and my exchange.  I
> enter his exchange and hit enter in the exchange box and it sends TU
> and my exchange.  Also wrong behavior.  In both cases, it sends the
> correct thing for S&P, but not the correct thing for run mode.

sorry, I have no idea, what happened.
 
> Am I doing something wrong?  Do I have something misconfigured?  Is it
> a bug in the SW?  Or if this should work, and it was a mistake in
> debian packaging deltas, should I file a debian bug?

I don't know how many user uses Tlf from the Debian repository.
There is a popularity contest, but the number of users is under
100:

https://qa.debian.org/popcon.php?package=tlf

but I think this issue would occured with these users.
 
> My setup...
>
> OS:  debian buster live 10.0.0 xfce

could you show me these outputs?

apt-cache show tlf
apt-cache showpkg tlf

Could you try it with another setup, eg CQWW (as Thomas proposed
too).


Just my 2cents: there was a similar issue at my side few years
ago, when I switched from SATA disk to SSD. I've worked on some
sprint contest (DARC Oestercontest...?), and the two modes
switched "too fastly", and sometimes it switched twice, so I got
back the original mode.

As you wrote, you're using Debian Buster Live - em I right that
this uses RAMDISK? Which is faster than an SSD...?

Do you have any permanent installed Debian? It should be in any
virtual system (VirtualBox, VMWare, ...). If yes, could you try
there?



Thanks,


Ervin
HA2OS
 

_______________________________________________
Tlf-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Reply | Threaded
Open this post in threaded view
|

Re: TLF run mode problem

Drew Arnett
I just subscribed to the tlf-devel list, so I should get those emails
in my mailbox now.  (I was using the archive web page.)

I will respond to Ervin and Tom's emails.  Tom's first.

Yes, your assumption is correct.  I am using CW.  NETKEYER works great!

Yes, the bad behavior is reproducible.

I tried CQWW (see below), but maybe if someone can provide config
files, I can try that.

Now, Ervin's.

Yes, I'm running with live on RAMDISK which should be faster than SSD.
I can install buster on a rotating disk drive and try that out to see
if it makes a difference.  What specifically is being accessed on disk
that might cause a race condition?  If it is something in the working
directory where I have my config files and log file, I could get that
onto a rotating disk drive without spending as much time and try that.
But, if it is say /tmp or the file system with the binary or
libraries, then I'll have to do the OS install.  I will try both and
let you know.  And, when I used TLF late last winter, I may have been
running off of a rotating hard disk, but I don't remember for sure.

To try CQWW, I modified the files I provided earlier in this way:
-----
cp -R iaru2019 blah
vi blah/rules/iaru
diff --recursive blah/rules/iaru iaru2019/rules/iaru
1,2c1,2
< CONTEST=cqww
< LOGFILE=cqwwlog.txt
---
> CONTEST=iaru
> LOGFILE=iarulog.txt
-----
and have the same problem behavior unfortunately.  Do you have config
files that I could try?

I also reproduced Ervin's use of a dummy rig.  I used 'rigctld -m 1'
to provide a rigctl daemon serving a dummy rig.  I used used 'rigctl
-m 2' and 'F 14002000' and exited that client to set the VFO on the
dummy rig.  I then modified logcfg.dat to change RIGMODEL=2 and
RIGPORT=localhost.  When I started tlf, it connected to the dummy rig
as evidenced by the different VFO value.  Unfortunately, still the
same bad behavior.

More details on the package installed per your request:
-----
user@debian:~$ apt-cache show tlf
Package: tlf
Version: 1.3.2-1
Installed-Size: 945
Maintainer: Debian Hamradio Maintainers <[hidden email]>
Architecture: amd64
Depends: libc6 (>= 2.15), libglib2.0-0 (>= 2.35.9), libhamlib2,
libncursesw6 (>= 6), libtinfo6 (>= 6), libxmlrpc-core-c3
Recommends: sox, xplanet
Description-en: console based ham radio contest logger
 Tlf is a console (ncurses) mode general purpose CW/VOICE keyer, logging and
 contest program for hamradio.
 It supports the CQWW, the WPX, the ARRL-DX , the ARRL-FD, the PACC and the
 EU SPRINT contests (single operator) as well as a LOT MORE basic contests,
 general QSO and DXpedition mode.
 It interfaces with a morse code generator, your sound card, a number of radios,
 and with a DX Cluster.
 Tlf can project cluster data into the excellent Xplanet program, written by
 Hari Nair.
 Contest operation mimics the popular TR-Log program for DOS, the output file
 is TR- as well as CABRILLO compatible. The user interface was designed with
 over 30 years of experience in CW contesting.
 The program was written for console mode on purpose, to make it run also on
 smaller machines, or remotely via a modem link.
 This version of Tlf supports the new native Fldigi interface for digital modes.
Description-md5: 4b4480a32b343c7aeca3161e12ba7877
Homepage: http://tlf.github.io/
Tag: uitoolkit::ncurses
Section: hamradio
Priority: optional
Filename: pool/main/t/tlf/tlf_1.3.2-1_amd64.deb
Size: 357000
MD5sum: 229818b440314c79bba5a7a30349ce8f
SHA256: 6682f1694d1f060f7d8265c484468a88903efdcc45caad6ae7108eef92ad96bd

user@debian:~$ apt-cache showpkg tlf
Package: tlf
Versions:
1.3.2-1 (/var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-amd64_Packages)
(/var/lib/dpkg/status)
 Description Language:
                 File:
/var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-amd64_Packages
                  MD5: 4b4480a32b343c7aeca3161e12ba7877
 Description Language: en
                 File:
/var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_i18n_Translation-en
                  MD5: 4b4480a32b343c7aeca3161e12ba7877


Reverse Depends:
  hamradio-logging,tlf
Dependencies:
1.3.2-1 - libc6 (2 2.15) libglib2.0-0 (2 2.35.9) libhamlib2 (0 (null))
libncursesw6 (2 6) libtinfo6 (2 6) libxmlrpc-core-c3 (0 (null)) sox (0
(null)) xplanet (0 (null))
Provides:
1.3.2-1 -
Reverse Provides:
user@debian:~$
-----

To wrap up, sounds like one hypothesis is a race condition.  I will
try putting just my local working directory (with logcfg.dat, rules,
log file, cty and partials) on a disk drive to see if there is any
change.  If not, then I will do a buster install on a disk drive and
see if that makes a difference.

No, I haven't looked at the source code, yet, myself.  More than happy
to work on trouble shooting with you and leaning on your existing
familiarity with the source code.  I could dig into the source
eventually if need be.  No problem to patch and build from source to
try out potential bugfixes.  I am quite literate in C and git.

Thanks and best regards,

Drew
kb9fko

On Wed, Jul 31, 2019 at 8:18 PM Ervin Hegedüs <[hidden email]> wrote:

>
> Drew, Thomas, and all,
>
> On Tue, Jul 30, 2019 at 02:26:25PM +0000, Drew Arnett wrote:
>
> I don't have Debian Buster actually, but have a Debian SID - it's
> not so far from Buster :), and all related components are same as
> your side:
>
> # dpkg -l tlf *hamlib* | grep ^ii
> ii  libhamlib++-dev:amd64 3.3-5+b1     amd64        Development C++ library to control radio transceivers and receivers
> ii  libhamlib-dev:amd64   3.3-5+b1     amd64        Development library to control radio transceivers and receivers
> ii  libhamlib-utils       3.3-5+b1     amd64        Utilities to support the hamlib radio control library
> ii  libhamlib2:amd64      3.3-5+b1     amd64        Run-time library to control radio transceivers and receivers
> ii  libhamlib2++c2:amd64  3.3-5+b1     amd64        Run-time C++ library to control radio transceivers and receivers
> ii  libhamlib2-tcl        3.3-5+b1     amd64        Run-time Tcl library to control radio transceivers and receivers
> ii  tlf                   1.3.2-1      amd64        console based ham radio contest logger
>
> On that machine, I don't have a phisycal connect with RIG, so
> I've used `rigctld -m 1`, set up the "virtual" rig on another
> terminal ("rigctl -m 2; F 14002000"), and started Tlf with Drew's
> config.
>
> > Run mode has problems.  Start auto CQ which works fine.  As soon as I
> > start typing in a callsign, the auto CQ stops and the "AUTO_CQ" marker
> > in the upper left corner changes to "S&P".
>
> I can't reproduce this issue. When AUTO_CQ sent the CQ, and I
> typed a foreign call, it switched to "LOG". I finished the
> callsign, pressed TAB, entered the zone, pressed ENTER, then Tlf
> sent "TU KB9FKO", and stayed in LOG mode.
>
> I pressed F12, Tlf switched to AUTO_CQ, and started to sent the
> CQ again.
>
> > (Is this a clue?)  I type
> > in his callsign and hit enter in the callsign box.  TLF sends mycall.
> > Wrong behavior.  I'm expecting it to send his call and my exchange.  I
> > enter his exchange and hit enter in the exchange box and it sends TU
> > and my exchange.  Also wrong behavior.  In both cases, it sends the
> > correct thing for S&P, but not the correct thing for run mode.
>
> sorry, I have no idea, what happened.
>
> > Am I doing something wrong?  Do I have something misconfigured?  Is it
> > a bug in the SW?  Or if this should work, and it was a mistake in
> > debian packaging deltas, should I file a debian bug?
>
> I don't know how many user uses Tlf from the Debian repository.
> There is a popularity contest, but the number of users is under
> 100:
>
> https://qa.debian.org/popcon.php?package=tlf
>
> but I think this issue would occured with these users.
>
> > My setup...
> >
> > OS:  debian buster live 10.0.0 xfce
>
> could you show me these outputs?
>
> apt-cache show tlf
> apt-cache showpkg tlf
>
> Could you try it with another setup, eg CQWW (as Thomas proposed
> too).
>
>
> Just my 2cents: there was a similar issue at my side few years
> ago, when I switched from SATA disk to SSD. I've worked on some
> sprint contest (DARC Oestercontest...?), and the two modes
> switched "too fastly", and sometimes it switched twice, so I got
> back the original mode.
>
> As you wrote, you're using Debian Buster Live - em I right that
> this uses RAMDISK? Which is faster than an SSD...?
>
> Do you have any permanent installed Debian? It should be in any
> virtual system (VirtualBox, VMWare, ...). If yes, could you try
> there?
>
>
>
> Thanks,
>
>
> Ervin
> HA2OS
>

_______________________________________________
Tlf-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Reply | Threaded
Open this post in threaded view
|

Re: TLF run mode problem

Drew Arnett
I just tried a fairly new desktop hard disk (less than a year old)
with an older USB 2.0 to SATA adapter.  I put my local working
directory there (logcfg.dat, rules, cty, partials, log), and the same
bad behavior persists.  Will install buster to hard disk (not via USB
adapter) and see how that behaves.

Thanks and best regards,

Drew
kb9fko

On Thu, Aug 1, 2019 at 1:26 AM Drew Arnett <[hidden email]> wrote:

>
> I just subscribed to the tlf-devel list, so I should get those emails
> in my mailbox now.  (I was using the archive web page.)
>
> I will respond to Ervin and Tom's emails.  Tom's first.
>
> Yes, your assumption is correct.  I am using CW.  NETKEYER works great!
>
> Yes, the bad behavior is reproducible.
>
> I tried CQWW (see below), but maybe if someone can provide config
> files, I can try that.
>
> Now, Ervin's.
>
> Yes, I'm running with live on RAMDISK which should be faster than SSD.
> I can install buster on a rotating disk drive and try that out to see
> if it makes a difference.  What specifically is being accessed on disk
> that might cause a race condition?  If it is something in the working
> directory where I have my config files and log file, I could get that
> onto a rotating disk drive without spending as much time and try that.
> But, if it is say /tmp or the file system with the binary or
> libraries, then I'll have to do the OS install.  I will try both and
> let you know.  And, when I used TLF late last winter, I may have been
> running off of a rotating hard disk, but I don't remember for sure.
>
> To try CQWW, I modified the files I provided earlier in this way:
> -----
> cp -R iaru2019 blah
> vi blah/rules/iaru
> diff --recursive blah/rules/iaru iaru2019/rules/iaru
> 1,2c1,2
> < CONTEST=cqww
> < LOGFILE=cqwwlog.txt
> ---
> > CONTEST=iaru
> > LOGFILE=iarulog.txt
> -----
> and have the same problem behavior unfortunately.  Do you have config
> files that I could try?
>
> I also reproduced Ervin's use of a dummy rig.  I used 'rigctld -m 1'
> to provide a rigctl daemon serving a dummy rig.  I used used 'rigctl
> -m 2' and 'F 14002000' and exited that client to set the VFO on the
> dummy rig.  I then modified logcfg.dat to change RIGMODEL=2 and
> RIGPORT=localhost.  When I started tlf, it connected to the dummy rig
> as evidenced by the different VFO value.  Unfortunately, still the
> same bad behavior.
>
> More details on the package installed per your request:
> -----
> user@debian:~$ apt-cache show tlf
> Package: tlf
> Version: 1.3.2-1
> Installed-Size: 945
> Maintainer: Debian Hamradio Maintainers <[hidden email]>
> Architecture: amd64
> Depends: libc6 (>= 2.15), libglib2.0-0 (>= 2.35.9), libhamlib2,
> libncursesw6 (>= 6), libtinfo6 (>= 6), libxmlrpc-core-c3
> Recommends: sox, xplanet
> Description-en: console based ham radio contest logger
>  Tlf is a console (ncurses) mode general purpose CW/VOICE keyer, logging and
>  contest program for hamradio.
>  It supports the CQWW, the WPX, the ARRL-DX , the ARRL-FD, the PACC and the
>  EU SPRINT contests (single operator) as well as a LOT MORE basic contests,
>  general QSO and DXpedition mode.
>  It interfaces with a morse code generator, your sound card, a number of radios,
>  and with a DX Cluster.
>  Tlf can project cluster data into the excellent Xplanet program, written by
>  Hari Nair.
>  Contest operation mimics the popular TR-Log program for DOS, the output file
>  is TR- as well as CABRILLO compatible. The user interface was designed with
>  over 30 years of experience in CW contesting.
>  The program was written for console mode on purpose, to make it run also on
>  smaller machines, or remotely via a modem link.
>  This version of Tlf supports the new native Fldigi interface for digital modes.
> Description-md5: 4b4480a32b343c7aeca3161e12ba7877
> Homepage: http://tlf.github.io/
> Tag: uitoolkit::ncurses
> Section: hamradio
> Priority: optional
> Filename: pool/main/t/tlf/tlf_1.3.2-1_amd64.deb
> Size: 357000
> MD5sum: 229818b440314c79bba5a7a30349ce8f
> SHA256: 6682f1694d1f060f7d8265c484468a88903efdcc45caad6ae7108eef92ad96bd
>
> user@debian:~$ apt-cache showpkg tlf
> Package: tlf
> Versions:
> 1.3.2-1 (/var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-amd64_Packages)
> (/var/lib/dpkg/status)
>  Description Language:
>                  File:
> /var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-amd64_Packages
>                   MD5: 4b4480a32b343c7aeca3161e12ba7877
>  Description Language: en
>                  File:
> /var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_i18n_Translation-en
>                   MD5: 4b4480a32b343c7aeca3161e12ba7877
>
>
> Reverse Depends:
>   hamradio-logging,tlf
> Dependencies:
> 1.3.2-1 - libc6 (2 2.15) libglib2.0-0 (2 2.35.9) libhamlib2 (0 (null))
> libncursesw6 (2 6) libtinfo6 (2 6) libxmlrpc-core-c3 (0 (null)) sox (0
> (null)) xplanet (0 (null))
> Provides:
> 1.3.2-1 -
> Reverse Provides:
> user@debian:~$
> -----
>
> To wrap up, sounds like one hypothesis is a race condition.  I will
> try putting just my local working directory (with logcfg.dat, rules,
> log file, cty and partials) on a disk drive to see if there is any
> change.  If not, then I will do a buster install on a disk drive and
> see if that makes a difference.
>
> No, I haven't looked at the source code, yet, myself.  More than happy
> to work on trouble shooting with you and leaning on your existing
> familiarity with the source code.  I could dig into the source
> eventually if need be.  No problem to patch and build from source to
> try out potential bugfixes.  I am quite literate in C and git.
>
> Thanks and best regards,
>
> Drew
> kb9fko
>
> On Wed, Jul 31, 2019 at 8:18 PM Ervin Hegedüs <[hidden email]> wrote:
> >
> > Drew, Thomas, and all,
> >
> > On Tue, Jul 30, 2019 at 02:26:25PM +0000, Drew Arnett wrote:
> >
> > I don't have Debian Buster actually, but have a Debian SID - it's
> > not so far from Buster :), and all related components are same as
> > your side:
> >
> > # dpkg -l tlf *hamlib* | grep ^ii
> > ii  libhamlib++-dev:amd64 3.3-5+b1     amd64        Development C++ library to control radio transceivers and receivers
> > ii  libhamlib-dev:amd64   3.3-5+b1     amd64        Development library to control radio transceivers and receivers
> > ii  libhamlib-utils       3.3-5+b1     amd64        Utilities to support the hamlib radio control library
> > ii  libhamlib2:amd64      3.3-5+b1     amd64        Run-time library to control radio transceivers and receivers
> > ii  libhamlib2++c2:amd64  3.3-5+b1     amd64        Run-time C++ library to control radio transceivers and receivers
> > ii  libhamlib2-tcl        3.3-5+b1     amd64        Run-time Tcl library to control radio transceivers and receivers
> > ii  tlf                   1.3.2-1      amd64        console based ham radio contest logger
> >
> > On that machine, I don't have a phisycal connect with RIG, so
> > I've used `rigctld -m 1`, set up the "virtual" rig on another
> > terminal ("rigctl -m 2; F 14002000"), and started Tlf with Drew's
> > config.
> >
> > > Run mode has problems.  Start auto CQ which works fine.  As soon as I
> > > start typing in a callsign, the auto CQ stops and the "AUTO_CQ" marker
> > > in the upper left corner changes to "S&P".
> >
> > I can't reproduce this issue. When AUTO_CQ sent the CQ, and I
> > typed a foreign call, it switched to "LOG". I finished the
> > callsign, pressed TAB, entered the zone, pressed ENTER, then Tlf
> > sent "TU KB9FKO", and stayed in LOG mode.
> >
> > I pressed F12, Tlf switched to AUTO_CQ, and started to sent the
> > CQ again.
> >
> > > (Is this a clue?)  I type
> > > in his callsign and hit enter in the callsign box.  TLF sends mycall.
> > > Wrong behavior.  I'm expecting it to send his call and my exchange.  I
> > > enter his exchange and hit enter in the exchange box and it sends TU
> > > and my exchange.  Also wrong behavior.  In both cases, it sends the
> > > correct thing for S&P, but not the correct thing for run mode.
> >
> > sorry, I have no idea, what happened.
> >
> > > Am I doing something wrong?  Do I have something misconfigured?  Is it
> > > a bug in the SW?  Or if this should work, and it was a mistake in
> > > debian packaging deltas, should I file a debian bug?
> >
> > I don't know how many user uses Tlf from the Debian repository.
> > There is a popularity contest, but the number of users is under
> > 100:
> >
> > https://qa.debian.org/popcon.php?package=tlf
> >
> > but I think this issue would occured with these users.
> >
> > > My setup...
> > >
> > > OS:  debian buster live 10.0.0 xfce
> >
> > could you show me these outputs?
> >
> > apt-cache show tlf
> > apt-cache showpkg tlf
> >
> > Could you try it with another setup, eg CQWW (as Thomas proposed
> > too).
> >
> >
> > Just my 2cents: there was a similar issue at my side few years
> > ago, when I switched from SATA disk to SSD. I've worked on some
> > sprint contest (DARC Oestercontest...?), and the two modes
> > switched "too fastly", and sometimes it switched twice, so I got
> > back the original mode.
> >
> > As you wrote, you're using Debian Buster Live - em I right that
> > this uses RAMDISK? Which is faster than an SSD...?
> >
> > Do you have any permanent installed Debian? It should be in any
> > virtual system (VirtualBox, VMWare, ...). If yes, could you try
> > there?
> >
> >
> >
> > Thanks,
> >
> >
> > Ervin
> > HA2OS
> >

_______________________________________________
Tlf-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Reply | Threaded
Open this post in threaded view
|

Re: TLF run mode problem

Ervin Hegedüs - HA2OS
Hi Drew,

On Thu, Aug 01, 2019 at 02:17:13AM +0000, Drew Arnett wrote:
> I just tried a fairly new desktop hard disk (less than a year old)
> with an older USB 2.0 to SATA adapter.  I put my local working
> directory there (logcfg.dat, rules, cty, partials, log), and the same
> bad behavior persists.  Will install buster to hard disk (not via USB
> adapter) and see how that behaves.
>
meanwhile I searched our discussion with Thomas, it was in
January of 2018.

The problem was not in the mode switching, but in the
backgroud_process() - the cleanup() function called faster than
the netkeyer sent the message to keyer.

And that bug was fixed:

https://github.com/Tlf/tlf/pull/84


After read this mail from you, I'm sure in this case the problem
is totally different, but currently I don't have any idea.

Reflect to your apt-cache outputs: looks like this package is
what I pushed to Debian (compared the hashes), not the another
build. And the source of package is equals with the upstream reelase.


To any other users: could someone check this version?



Let's keep in touch,


73, Ervin


_______________________________________________
Tlf-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Reply | Threaded
Open this post in threaded view
|

Re: TLF run mode problem

Drew Arnett
Thanks for digging in, Ervin.

I will look at that pull request.  Another difference in my case is
that I'm using my pywinkeyerdaemon with a K1EL (www.hamcrafters.com)
'WinKeyer USB'.  https://github.com/drewarnett/pywinkeyerdaemon  (One
diff though, as I need to update it for the later python-serial lib;
timeout is now set by attribute, not method.  I also need to publish a
python3 version!)  Interrupting auto_cq to respond would involve
sending a message to NETKEYER/cwdaemon.  Maybe my implementation has a
subtle, problem causing difference?  I'll either examine my code
versus what cwdaemon does or just install the standard cwdaemon and
see if there is any difference.

I've also finished the experiment where I installed buster on the hard
disk and tlf and my config files.  The problem still exists.  So,
maybe that confirms that it is not the same problem pull 84 fixed.

I will pursue my idea regarding NETKEYER/cwdaemon/pywinkeyerdaemon
both by experiment and by reviewing cwdaemon and pywinkeyerdaemon
source.  I would be interested in hypothesis or suggestions for what I
may try.

Thanks and best regards,

Drew
kb9fko


On Thu, Aug 1, 2019 at 6:38 AM Ervin Hegedüs <[hidden email]> wrote:

>
> Hi Drew,
>
> On Thu, Aug 01, 2019 at 02:17:13AM +0000, Drew Arnett wrote:
> > I just tried a fairly new desktop hard disk (less than a year old)
> > with an older USB 2.0 to SATA adapter.  I put my local working
> > directory there (logcfg.dat, rules, cty, partials, log), and the same
> > bad behavior persists.  Will install buster to hard disk (not via USB
> > adapter) and see how that behaves.
> >
> meanwhile I searched our discussion with Thomas, it was in
> January of 2018.
>
> The problem was not in the mode switching, but in the
> backgroud_process() - the cleanup() function called faster than
> the netkeyer sent the message to keyer.
>
> And that bug was fixed:
>
> https://github.com/Tlf/tlf/pull/84
>
>
> After read this mail from you, I'm sure in this case the problem
> is totally different, but currently I don't have any idea.
>
> Reflect to your apt-cache outputs: looks like this package is
> what I pushed to Debian (compared the hashes), not the another
> build. And the source of package is equals with the upstream reelase.
>
>
> To any other users: could someone check this version?
>
>
>
> Let's keep in touch,
>
>
> 73, Ervin
>

_______________________________________________
Tlf-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Reply | Threaded
Open this post in threaded view
|

Re: TLF run mode problem

Ervin Hegedüs - HA2OS
Hi Drew,

On Thu, Aug 01, 2019 at 02:42:23PM +0000, Drew Arnett wrote:
> Thanks for digging in, Ervin.
>
> I will look at that pull request.  Another difference in my case is
> that I'm using my pywinkeyerdaemon with a K1EL (www.hamcrafters.com)
> 'WinKeyer USB'.  https://github.com/drewarnett/pywinkeyerdaemon  (One
> diff though, as I need to update it for the later python-serial lib;
> timeout is now set by attribute, not method.  I also need to publish a
> python3 version!)  

I don't think that this could be the problem.

> Interrupting auto_cq to respond would involve
> sending a message to NETKEYER/cwdaemon.

but this is an important thing - I just started to review your
first e-mail, and try to eplore the relevant parts of the code.

You wrote in your first mail:

"Start auto CQ which works fine.  As soon as I start typing in a
callsign, the auto CQ stops and the "AUTO_CQ" marker in the upper
left corner changes to "S&P".  (Is this a clue?)  I type in his
callsign and hit enter in the callsign box.  TLF sends mycall."

So, I interpret that when you typed the other station CALL, then
Tlf switched to another mode (CQ -> S_P), and _this_ is why after
the ENTER it sent _your_ call, not the other station call. I mean
the reason can't be the NETKEYER, it occures by the type,
_before_ the netkeyer code starts to send the message.

I found this part, which would be relevant:

https://github.com/Tlf/tlf/blob/tlf-1.3.2/src/callinput.c#L263

(note, that this is not the current master state, it's the 1.3.2,
this file had modified meanwhile; but the 1.3.2 is what in
Debian)

Based on the code, I just can think about your keyboard layout,
or some terminal settings - eg. you're using some strange TERM
environment, which grab the '+' in every key pressing...

So now I'ld try to check the terminal settings, eg:

export TERM=linux

or

export TERM=xterm

and start Tlf, check the issue.


Hope that we can solve your issue soon :).


Another note to Thomas/Zoli HA5CQZ: do you know about this line?

https://github.com/Tlf/tlf/blob/tlf-1.3.2/src/callinput.c#L648

  if (atoi(hiscall) < 1800) {

this will always 0, and less than 1800 - or em I wrong? :)


73, Ervin
HA2OS



_______________________________________________
Tlf-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Reply | Threaded
Open this post in threaded view
|

Re: atoi hiscall

Csahok Zoltan
Hi Ervin,

Yes: if you enter a frequency in kHz as callsign, then the rig switches to it.
A nice but maybe undocumented feature.

73,
Zoli

> Another note to Thomas/Zoli HA5CQZ: do you know about this line?
>
> https://github.com/Tlf/tlf/blob/tlf-1.3.2/src/callinput.c#L648
>
>   if (atoi(hiscall) < 1800) {
>
> this will always 0, and less than 1800 - or em I wrong? :)
>
>
> 73, Ervin
> HA2OS
>
>

_______________________________________________
Tlf-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Reply | Threaded
Open this post in threaded view
|

Re: atoi hiscall

Ervin Hegedüs - HA2OS
Hi Zoli,


On Thu, Aug 01, 2019 at 09:32:00PM +0200, Csahok Zoltan wrote:
> Hi Ervin,
>
> Yes: if you enter a frequency in kHz as callsign, then the rig switches to it.
> A nice but maybe undocumented feature.

well, awesome idea, congrats!

And thanks for clarification :).


73, Ervin
 

_______________________________________________
Tlf-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Reply | Threaded
Open this post in threaded view
|

Re: TLF run mode problem

Drew Arnett
In reply to this post by Ervin Hegedüs - HA2OS
PBKAC as I suspected.  (Why would I be the only one with a problem
with such basic functionality.)

The indicator in the upper left hand corner is 'Log' for run mode and
'S&P' for search and pounce.  OK.  The source code made that obvious.
Ugh.  For some reason I was thinking 'Log' was a 3rd mode.  My bad.
Of course, something that obvious I wasn't going to figure out during
the contest.  :-O  Modified my F3, exchange, message to be '@ 5NN 6'
instead of '5NN 6'.  Enter send mode works fine then for S&P and run
mode.

So, I think I'm good (enough) for the NAQP CW test this weekend.  I
may setup one of the blank F-keys to be a report without @, but should
be fine.

I could nitpick a tiny detail here or there, but patches/pull requests
would probably be more of interest.  :-)  As is, works good enough.
Bonus points for tlf being packaged in debian and being a TUI (text
user interface) program with no mouse input!  :-)

Thanks for your patience and help.

Best regards,

Drew
kb9fko

On Thu, Aug 1, 2019 at 7:08 PM Ervin Hegedüs <[hidden email]> wrote:

>
> Hi Drew,
>
> On Thu, Aug 01, 2019 at 02:42:23PM +0000, Drew Arnett wrote:
> > Thanks for digging in, Ervin.
> >
> > I will look at that pull request.  Another difference in my case is
> > that I'm using my pywinkeyerdaemon with a K1EL (www.hamcrafters.com)
> > 'WinKeyer USB'.  https://github.com/drewarnett/pywinkeyerdaemon  (One
> > diff though, as I need to update it for the later python-serial lib;
> > timeout is now set by attribute, not method.  I also need to publish a
> > python3 version!)
>
> I don't think that this could be the problem.
>
> > Interrupting auto_cq to respond would involve
> > sending a message to NETKEYER/cwdaemon.
>
> but this is an important thing - I just started to review your
> first e-mail, and try to eplore the relevant parts of the code.
>
> You wrote in your first mail:
>
> "Start auto CQ which works fine.  As soon as I start typing in a
> callsign, the auto CQ stops and the "AUTO_CQ" marker in the upper
> left corner changes to "S&P".  (Is this a clue?)  I type in his
> callsign and hit enter in the callsign box.  TLF sends mycall."
>
> So, I interpret that when you typed the other station CALL, then
> Tlf switched to another mode (CQ -> S_P), and _this_ is why after
> the ENTER it sent _your_ call, not the other station call. I mean
> the reason can't be the NETKEYER, it occures by the type,
> _before_ the netkeyer code starts to send the message.
>
> I found this part, which would be relevant:
>
> https://github.com/Tlf/tlf/blob/tlf-1.3.2/src/callinput.c#L263
>
> (note, that this is not the current master state, it's the 1.3.2,
> this file had modified meanwhile; but the 1.3.2 is what in
> Debian)
>
> Based on the code, I just can think about your keyboard layout,
> or some terminal settings - eg. you're using some strange TERM
> environment, which grab the '+' in every key pressing...
>
> So now I'ld try to check the terminal settings, eg:
>
> export TERM=linux
>
> or
>
> export TERM=xterm
>
> and start Tlf, check the issue.
>
>
> Hope that we can solve your issue soon :).
>
>
> Another note to Thomas/Zoli HA5CQZ: do you know about this line?
>
> https://github.com/Tlf/tlf/blob/tlf-1.3.2/src/callinput.c#L648
>
>   if (atoi(hiscall) < 1800) {
>
> this will always 0, and less than 1800 - or em I wrong? :)
>
>
> 73, Ervin
> HA2OS
>
>

_______________________________________________
Tlf-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Reply | Threaded
Open this post in threaded view
|

Re: TLF run mode problem

Thomas Beierlein-4
Hi all,

good to hear you could fix the problem at your side Drew.

I am a bit late with answering as I am just two days away from holiday
and there are quite some things to finish before.

I did some double check on the code in meantime and there are only 3
places where the run mode is changed:

- on empty callsign field with '+'
- during a grab of an announced station from cluster (but only if you
  are already in S&P)
- after each QSO in sprint mode.

If running auto CQ no one of the above could be happen. So I was
already thinking about stray RF from your TX, bad projection of moon
gravity field or some aliens coming in :-).

So good luck for the coming NAQP CW contest.

73, de Tom DL1JBE

@Ervin and @Zoli: As told above I will be away the next two and a half
week starting tomorrow or Sunday.

Am Fri, 2 Aug 2019
00:51:23 +0000 schrieb Drew Arnett <[hidden email]>:

> PBKAC as I suspected.  (Why would I be the only one with a problem
> with such basic functionality.)
>
> The indicator in the upper left hand corner is 'Log' for run mode and
> 'S&P' for search and pounce.  OK.  The source code made that obvious.
> Ugh.  For some reason I was thinking 'Log' was a 3rd mode.  My bad.
> Of course, something that obvious I wasn't going to figure out during
> the contest.  :-O  Modified my F3, exchange, message to be '@ 5NN 6'
> instead of '5NN 6'.  Enter send mode works fine then for S&P and run
> mode.
>
> So, I think I'm good (enough) for the NAQP CW test this weekend.  I
> may setup one of the blank F-keys to be a report without @, but should
> be fine.
>
> I could nitpick a tiny detail here or there, but patches/pull requests
> would probably be more of interest.  :-)  As is, works good enough.
> Bonus points for tlf being packaged in debian and being a TUI (text
> user interface) program with no mouse input!  :-)
>
> Thanks for your patience and help.
>
> Best regards,
>
> Drew
> kb9fko
>
> On Thu, Aug 1, 2019 at 7:08 PM Ervin Hegedüs <[hidden email]>
> wrote:
> >
> > Hi Drew,
> >
> > On Thu, Aug 01, 2019 at 02:42:23PM +0000, Drew Arnett wrote:  
> > > Thanks for digging in, Ervin.
> > >
> > > I will look at that pull request.  Another difference in my case
> > > is that I'm using my pywinkeyerdaemon with a K1EL
> > > (www.hamcrafters.com) 'WinKeyer USB'.
> > > https://github.com/drewarnett/pywinkeyerdaemon  (One diff though,
> > > as I need to update it for the later python-serial lib; timeout
> > > is now set by attribute, not method.  I also need to publish a
> > > python3 version!)  
> >
> > I don't think that this could be the problem.
> >  
> > > Interrupting auto_cq to respond would involve
> > > sending a message to NETKEYER/cwdaemon.  
> >
> > but this is an important thing - I just started to review your
> > first e-mail, and try to eplore the relevant parts of the code.
> >
> > You wrote in your first mail:
> >
> > "Start auto CQ which works fine.  As soon as I start typing in a
> > callsign, the auto CQ stops and the "AUTO_CQ" marker in the upper
> > left corner changes to "S&P".  (Is this a clue?)  I type in his
> > callsign and hit enter in the callsign box.  TLF sends mycall."
> >
> > So, I interpret that when you typed the other station CALL, then
> > Tlf switched to another mode (CQ -> S_P), and _this_ is why after
> > the ENTER it sent _your_ call, not the other station call. I mean
> > the reason can't be the NETKEYER, it occures by the type,
> > _before_ the netkeyer code starts to send the message.
> >
> > I found this part, which would be relevant:
> >
> > https://github.com/Tlf/tlf/blob/tlf-1.3.2/src/callinput.c#L263
> >
> > (note, that this is not the current master state, it's the 1.3.2,
> > this file had modified meanwhile; but the 1.3.2 is what in
> > Debian)
> >
> > Based on the code, I just can think about your keyboard layout,
> > or some terminal settings - eg. you're using some strange TERM
> > environment, which grab the '+' in every key pressing...
> >
> > So now I'ld try to check the terminal settings, eg:
> >
> > export TERM=linux
> >
> > or
> >
> > export TERM=xterm
> >
> > and start Tlf, check the issue.
> >
> >
> > Hope that we can solve your issue soon :).
> >
> >
> > Another note to Thomas/Zoli HA5CQZ: do you know about this line?
> >
> > https://github.com/Tlf/tlf/blob/tlf-1.3.2/src/callinput.c#L648
> >
> >   if (atoi(hiscall) < 1800) {
> >
> > this will always 0, and less than 1800 - or em I wrong? :)
> >
> >
> > 73, Ervin
> > HA2OS
> >
> >  
>
> _______________________________________________
> Tlf-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/tlf-devel



--
"Do what is needful!"
Ursula LeGuin: Earthsea
--


_______________________________________________
Tlf-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tlf-devel