[Tlf-devel] tlf segfault
Hi,
Tlf segfaults immediately after start on some machines here if started
with 'tlf -n' and if SPOTLIST is activated in logcfg.dat (as installed by
default as example).
Found the reason in cluster_bg.c where in case of an empty spotlist tlf uses
some negative indexes for array access (around lines 460..490) . Bummer!
The following diff fixes the problem. I hope Rein can integrate the patch soon
and release a fixed version.
73, de Tom DL1JBE
Patch follows here:
--- src/cluster_bg.c.orig 2009-10-03 09:14:28.0 +0200
+++ src/cluster_bg.c2009-10-02 08:25:40.0 +0200
@@ -463,7 +463,10 @@
for (j=15; j < 23; j++)
mvprintw(j,4, " ");
-if (cluster == SPOTS) linepos = i - 8;
+if (cluster == SPOTS){
+ linepos = i - 8;
+ if (linepos < 0) linepos = 0;
+}
else linepos = 0;
--
"Do what is needful!"
Ursula LeGuin: Earthsea
--
___
Tlf-devel mailing list
Tlf-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] tlf segfault
Hi Rein,
On Mon, Oct 05, 2009 at 03:02:18PM +0200, Rein Couperus wrote:
> I will include the patch and release it this week.
>
just wait a little bit with a new release. We just checked with the new
gcc 4.4.1 and glibc 2.10. There are more problems to fix.
I will look for it and keep you informed.
73, de Tom DL1JBE.
>
> > -Ursprüngliche Nachricht-
> > Von: "Thomas Beierlein"
> > Gesendet: 05.10.09 15:00:50
> > An: tlf-devel@nongnu.org
> > Betreff: [Tlf-devel] tlf segfault
>
>
> > Hi,
> >
> > Tlf segfaults immediately after start on some machines here if started
> > with 'tlf -n' and if SPOTLIST is activated in logcfg.dat (as installed by
> > default as example).
> >
> > Found the reason in cluster_bg.c where in case of an empty spotlist tlf
> > uses
> > some negative indexes for array access (around lines 460..490) . Bummer!
> >
> > The following diff fixes the problem. I hope Rein can integrate the patch
> > soon
> > and release a fixed version.
> >
> > 73, de Tom DL1JBE
> >
> > Patch follows here:
> >
> > --- src/cluster_bg.c.orig 2009-10-03 09:14:28.0 +0200
> > +++ src/cluster_bg.c2009-10-02 08:25:40.0 +0200
> > @@ -463,7 +463,10 @@
> > for (j=15; j < 23; j++)
> > mvprintw(j,4, " ");
> >
> > -if (cluster == SPOTS) linepos = i - 8;
> > +if (cluster == SPOTS){
> > + linepos = i - 8;
> > + if (linepos < 0) linepos = 0;
> > +}
> > else linepos = 0;
> >
> >
> > --
> > "Do what is needful!"
> > Ursula LeGuin: Earthsea
> > --
> >
> >
> >
> > ___
> > Tlf-devel mailing list
> > Tlf-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/tlf-devel
> >
>
> --
> http://pa0r.blogspirit.com
--
"Do what is needful!"
Ursula LeGuin: Earthsea
--
___
Tlf-devel mailing list
Tlf-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] tlf segfault
Hi Rein,
during the tests with the new GCC-4.4.1 and GLIBC-2.10 we found two
buffer overflows in string handling. Please see the attached diff for fix.
The first fix does not only fix the buffer overflow but also corrects the
wrong handling of the month variable for muf predictions.
73, de Tom DL1JBE
---
--- src/clear_display.c.orig2007-12-18 16:08:05.0 +0100
+++ src/clear_display.c 2009-10-06 07:25:30.0 +0200
@@ -100,10 +100,7 @@
else
strftime(time_buf, 60, "DIG %d-%b-%y %H:%M ", time_ptr);
-strncat (month, time_buf + 2, 2); /* month for muf calc */
-m = atoi ( month);
-if (m == 0)
- m++;
+ m = time_ptr->tm_mon; /* month for muf calc */
mvprintw(12, 3,time_buf);
--- src/displayit.c.orig2009-10-06 16:27:22.0 +0200
+++ src/displayit.c 2009-10-06 16:45:31.0 +0200
@@ -39,7 +39,7 @@
strncat(term2buf, termbuf, strlen(termbuf) - 1 );
strncat(term2buf, backgrnd_str, 81 - strlen(termbuf)); /*
fill with blanks */
- strcat(term2buf, "\n");
+ term2buf[80] = '\0';
strcpy(terminal1, terminal2);
strcpy(terminal2, terminal3);
strcpy(terminal3, terminal4);
---
On Mon, Oct 05, 2009 at 06:52:02PM +0200, Thomas Beierlein wrote:
> Hi Rein,
>
> On Mon, Oct 05, 2009 at 03:02:18PM +0200, Rein Couperus wrote:
> > I will include the patch and release it this week.
> >
> just wait a little bit with a new release. We just checked with the new
> gcc 4.4.1 and glibc 2.10. There are more problems to fix.
>
> I will look for it and keep you informed.
>
> 73, de Tom DL1JBE.
>
> >
> > > -Ursprüngliche Nachricht-
> > > Von: "Thomas Beierlein"
> > > Gesendet: 05.10.09 15:00:50
> > > An: tlf-devel@nongnu.org
> > > Betreff: [Tlf-devel] tlf segfault
> >
> >
> > > Hi,
> > >
> > > Tlf segfaults immediately after start on some machines here if started
> > > with 'tlf -n' and if SPOTLIST is activated in logcfg.dat (as installed by
> > > default as example).
> > >
> > > Found the reason in cluster_bg.c where in case of an empty spotlist tlf
> > > uses
> > > some negative indexes for array access (around lines 460..490) . Bummer!
> > >
> > > The following diff fixes the problem. I hope Rein can integrate the patch
> > > soon
> > > and release a fixed version.
> > >
> > > 73, de Tom DL1JBE
> > >
> > > Patch follows here:
> > >
> > > --- src/cluster_bg.c.orig 2009-10-03 09:14:28.0 +0200
> > > +++ src/cluster_bg.c 2009-10-02 08:25:40.0 +0200
> > > @@ -463,7 +463,10 @@
> > > for (j=15; j < 23; j++)
> > > mvprintw(j,4, " ");
> > >
> > > -if (cluster == SPOTS) linepos = i - 8;
> > > +if (cluster == SPOTS){
> > > + linepos = i - 8;
> > > + if (linepos < 0) linepos = 0;
> > > +}
> > > else linepos = 0;
> > >
> > >
> > > --
> > > "Do what is needful!"
> > > Ursula LeGuin: Earthsea
> > > --
> > >
> > >
> > >
> > > ___
> > > Tlf-devel mailing list
> > > Tlf-devel@nongnu.org
> > > http://lists.nongnu.org/mailman/listinfo/tlf-devel
> > >
> >
> > --
> > http://pa0r.blogspirit.com
>
> --
> "Do what is needful!"
> Ursula LeGuin: Earthsea
> --
>
>
>
> ___
> Tlf-devel mailing list
> Tlf-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/tlf-devel
--
"Do what is needful!"
Ursula LeGuin: Earthsea
--
___
Tlf-devel mailing list
Tlf-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] tlf segfault
Here comes another buffer overflow. These time from makelogline() routine. The patch below fixes it. 73, de Tom DL1JBE --- src/makelogline.c.orig 2009-10-20 16:46:41.0 + +++ src/makelogline.c 2009-10-20 16:47:49.0 + @@ -387,9 +387,8 @@ strcat (logline4, " "); } -strcat (logline4, "" ); - -logline4[80]='\0'; /* just in case... */ + /* fill rest of line */ + strncat (logline4, "", 80-strlen(logline4)); return (0); } -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Pre-release of TLF-1.0.0
Hi Rein and others, On Sat, Dec 05, 2009 at 12:25:18PM +0100, Rein Couperus wrote: > I did the following to get tlf-1.0.0pre going with hamlib: > > * check if libhamlib-dev is on your system, if not sudo apt-get install > libhamlib-dev > * in the TLF-1.0.0pre directory, do a make clean > * ./configure --enable-hamlib > * make > * sudo make install normally ./configure should complain if called with --enable-hamlib and hamlib not installed. tlf-1.0.0pre works here on 64bit Gentoo without problems. My Ts570D (rigmodel 204) works good. Only problem is I get always the smallest bandwidth (50 Hz) on CW which is a little bit small. I will look into iti if I find time. Some minor quirks: - version should be 1.0.0pre, but that got corrected in SVN in meantime. - From package managers point of view, a lower case naming (tlf-1.0.0) for the tar.gz and also the contained directory would be easier to handle. - The SVN repository contains some files which are part of a normal distribution, but should not be in SVN because they gets automatically i build (e.g. autom4tecache, Makefile, Makefile.in and others). I will have a look to it and clean up the repo, but give a readme how to prepare the package after checkout for distribution (in next few days). 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Pre-release of TLF-1.0.0 fails
Hi Martin, as I cannot reproduce that behaviour, can you please give some more informations. Which contest? How did you start tlf (comamndline)? Which compiler and glibc version, OS,...? 73, de Tom DL1JBE On Thu, Dec 17, 2009 at 12:01:59PM +0100, Martin Kratoska wrote: > The new pre-release of TLF-1.0.0 fails if trying to use initial exchange > file. Program prematurely closes at first attempt to log in a QSO with > exchange filled by the initial exchange routine. > > A nice addition would be accepting spaces in the initial exchange. > > 73, > Martin, OK1RR > > > ___ > Tlf-devel mailing list > Tlf-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/tlf-devel -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Pre-release of TLF-1.0.0 fails
Hi Martin, thanks for the info. I can confirm the problem. It seems to be also a problem for the old 0.9.31.2 version. I will have a look into it and keep you informed. 73, de Tom DL1JBE On Thu, Dec 17, 2009 at 10:28:30PM +0100, Martin Kratoska wrote: > Hi, > > contest: FOC Marathon, BWQP or any other contest with RST initial_exchange, > dxped rules > > start: ./tlf > no arguments > > OS: Ubuntu Karmic 9.10, gcc 4.4 > > 73, > Martin, OK1RR > > Thomas Beierlein napsal(a): >> Hi Martin, >> >> as I cannot reproduce that behaviour, can you please give some more >> informations. >> >> Which contest? >> How did you start tlf (comamndline)? >> Which compiler and glibc version, OS,...? >> >> 73, de Tom DL1JBE >> >> On Thu, Dec 17, 2009 at 12:01:59PM +0100, Martin Kratoska wrote: >>> The new pre-release of TLF-1.0.0 fails if trying to use initial exchange >>> file. Program prematurely closes at first attempt to log in a QSO with >>> exchange filled by the initial exchange routine. >>> >>> A nice addition would be accepting spaces in the initial exchange. >>> >>> 73, >>> Martin, OK1RR >>> >>> >>> ___ >>> Tlf-devel mailing list >>> Tlf-devel@nongnu.org >>> http://lists.nongnu.org/mailman/listinfo/tlf-devel >> -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Pre-release of TLF-1.0.0 fails
Hi Martin,
found the problem. The attached diff showes the needed change. I hope you
can build tlf yourself from sources. Otherwise you have to wait for Rein to
prepare a new release candidate.
I will work in next days on the routine to allow leading and trailing spaces
for callsign and initial exchange.
73, de Tom DL1JBE.
Index: makelogline.c
===
--- makelogline.c (revision 14)
+++ makelogline.c (working copy)
@@ -351,7 +351,7 @@
} else if ((one_point == 1) || (two_point == 1) || (three_point == 1)) {
strncat(logline4, fillspaces, 4);
} else {
- strncat(logline4, fillspaces, 9);
+ strncat(logline4, fillspaces, 4);
}
--
"Do what is needful!"
Ursula LeGuin: Earthsea
--
___
Tlf-devel mailing list
Tlf-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Pre-release of TLF-1.0.0 fails
Season greetings to all! On Wed, Dec 23, 2009 at 01:46:37AM +0100, Martin Kratoska wrote: > Hi Tom, it works! Bravo & many thanks! Good to hear. > Unfortunately I found another long term bug: > > In Log mode with AutoCQ I can't directly enter the call. If trying to type > the callsign of the station calling me, the first character does not appear > in the logging line, ie. if DL1JBE coming back, the D is omitted and the > callsign entry begins with L (ie. L1JBE). To stop the AutoCQ loop I need > first to press ESC, then tlf allows to type the call without eating the > first character. Very annoying in the high-rate situation! Not sure if it really is a bug or an intended feature. But I see your point. I put it on the todo list. > > Another very missed feature is the AutoSend option known from TR-LOG. > TR-LOG can start to send the callsign of a station responding to your CQ > after you have typed a certain number of characters in the callsign of the > calling station. This number of characters is controlled with the AUTO SEND > CHARACTER COUNT command. For example, if you set AUTO SEND CHARACTER COUNT > to 3 and 4U1ITU calls you, the program will start sending the call after > you have typed 4U1. If you enable the AUTO CALL TERMINATE feature, the > program will transmit the CQ EXCHANGE message when it has sent all the > characters you have typed. When the AUTO SEND CHARACTER COUNT is non-zero, > an arrow will appear above the Call Window to indicate the point at which > TR-LOG will begin to transmit the callsign. > Goes also on the wishlist :). But bug fixing will go first. So please be patient, it will take some time. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Pre-release of TLF-1.0.0 fails
Hi Martin, I wish Happy new year to you and all others!
On Wed, Dec 23, 2009 at 01:46:37AM +0100, Martin Kratoska wrote:
> In Log mode with AutoCQ I can't directly enter the call. If trying to type
> the callsign of the station calling me, the first character does not appear
> in the logging line, ie. if DL1JBE coming back, the D is omitted and the
> callsign entry begins with L (ie. L1JBE). To stop the AutoCQ loop I need
> first to press ESC, then tlf allows to type the call without eating the
> first character. Very annoying in the high-rate situation!
Please try the attached diff to callinput.c. It should fix the autoCQ problem.
Reports are welcome.
> Another very missed feature is the AutoSend option known from TR-LOG.
> TR-LOG can start to send the callsign of a station responding to your CQ
> after you have typed a certain number of characters in the callsign of the
> calling station. This number of characters is controlled with the AUTO SEND
> CHARACTER COUNT command. For example, if you set AUTO SEND CHARACTER COUNT
> to 3 and 4U1ITU calls you, the program will start sending the call after
> you have typed 4U1. i
Have you tried the :CHAr comamnd for that (see man page)?
73, de Tom DL1JBE.
> If you enable the AUTO CALL TERMINATE feature, the
> program will transmit the CQ EXCHANGE message when it has sent all the
> characters you have typed. When the AUTO SEND CHARACTER COUNT is non-zero,
> an arrow will appear above the Call Window to indicate the point at which
> TR-LOG will begin to transmit the callsign.
>
> 73,
> Martin, OK1RR
>
>
> Thomas Beierlein napsal(a):
>> Hi Martin,
>>
>> found the problem. The attached diff showes the needed change. I hope you
>> can build tlf yourself from sources. Otherwise you have to wait for Rein to
>> prepare a new release candidate.
>>
>> I will work in next days on the routine to allow leading and trailing
>> spaces for callsign and initial exchange.
>> 73, de Tom DL1JBE.
>>
>> Index: makelogline.c
>> ===
>> --- makelogline.c(revision 14)
>> +++ makelogline.c(working copy)
>> @@ -351,7 +351,7 @@
>> } else if ((one_point == 1) || (two_point == 1) || (three_point == 1)) {
>> strncat(logline4, fillspaces, 4);
>> } else {
>> -strncat(logline4, fillspaces, 9);
>> +strncat(logline4, fillspaces, 4);
>> }
>>
--
"Do what is needful!"
Ursula LeGuin: Earthsea
--
Index: callinput.c
===
--- callinput.c (revision 28)
+++ callinput.c (working copy)
@@ -166,10 +166,11 @@
if (x == '\n' && strlen(hiscall) == 0) {
if (cqmode == CQ) {
if (noautocq != 1)
- auto_cq();
- } else
+ x = auto_cq();
+ } else {
sendspcall();
- break;
+ break;
+ }
}
if (x == 152 || x == 229) { // up-arrow or alt-e
___
Tlf-devel mailing list
Tlf-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Errors
Hi Martin,
as I said before, please check that you have pkg-config installed on your
system.
Afterwards a 'pkg-config --libs hamlib' on the command line should give you the
compiler switches for hamlib: -lhamlib -lm.
If that does not work please try:
autoreconf
./configure --enable-hamlib
I hope that helps.
73, de Tom DL1JBE.
On Tue, Jan 05, 2010 at 02:30:05AM +0100, Martin Kratoska wrote:
> found a problem with configure
>
>
> 4564,4571d4563
> < if test "x${wanthamlib}" != "xfalse"; then
> < hamlib_modules="hamlib >= 1.2.8"
> < PKG_CHECK_MODULES(HAMLIB, $hamlib_modules,
> <,
> 1.2.8 or later not found...])
> <)
> 4629,4638d4620
> < $as_echo "#define WANT_HAMLIB 1" >>confdefs.h
> <
> < echo "enabling hamlib support"
> < else
> <
> < $as_echo "#define WANT_HAMLIB 0" >>confdefs.h
> <
> < echo "disabling hamlib support"
> < fi
> <
>
>
> if removed the above, the compilation is OK. What now?
>
> 73
> Martin, OK1RR
--
"Do what is needful!"
Ursula LeGuin: Earthsea
--
___
Tlf-devel mailing list
Tlf-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Handling of SECTION_MULT?
Hi to all, I just tried to use a MULT_LIST file and SECTION_MULT for a contest (HADX). The contest allows me to work all stations with different points but only HA regions (which are listed in my MULT_LIST) counts as multies. HA stations gives the region as exchange, all other serial number. Unfortunately I could not use that scheme with TLF. SECTION_MULT 'requires' that the exchange contains one of the valid multies from the list. Without one I am not able to log the qso. So no non-HA station could be logged. I would like to change that behaviour for the new tlf-1.0 but wants some feedback from your side beforehand: I see three possible answers. a) Let TLF also log any other station without a section in exchange but give no multi. A warning for the missing section should still be there. b) Like a) but add a configuration switch (e.g. SECTION_REQUIRED) which allows to fall back to old scheme. c) Keep it like it is and look for another way to work that contest. I would prefer a) but am not sure if we have contests, where we need the old behaviour. Feedback welcome, Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] State of the TLF SVN repo
Hello, for some weeks I cannot reach the svn repo for tlf anymore. Has anybody some information about that? 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF Not Working in Ubuntu
Hi Rein, hi Graham, the pre2 version still contains some bugs which are fixed in the SVN repo. Unfortunately it stopeed working again Rein some days after you fixed it. If you agree I will set up a svn repo here at my side. It would be good to have the history so far in that repo too. A svndump of your repo (as soon as you are back home) would be helpful. 73, Tom DL1JBE. On Tue, Jun 15, 2010 at 11:01:27AM +0200, Rein Couperus wrote: > I can run tlf-1.0.0.pre2 in ubuntu-10.04 LTS. > At least it starts normally, no time to test thoroughly... > > The version (0.9.32) from the repo does NOT run. That is no > miracle, as it is a version from 2005, and ubuntu has changed a lot since > then. > The Debian maintainer has dropped the project, and we need a volunteer to > get the new stuff into the distro. > > Unfortunately I cannot help as I am travelling at the moment. > > 73, > > Rein PA0R > > -via pskmail- > > >Email sent on Sunday 13/06/2010 at 09:31:49 > >Hi All, I have been trying to get TLF working in Ubuntu 10.04 It appears > >that it has not worked since Hardy Heron. After switching from the DX > >cluster page at startup or starting with the -n option TLF aborts is > >there a Fix for this? > > > >Graham G1rnz > > > >___ > >Tlf-devel mailing list > >Tlf-devel@nongnu.org > >http://lists.nongnu.org/mailman/listinfo/tlf-devel > > ___ > Tlf-devel mailing list > Tlf-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/tlf-devel -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF Not Working in Ubuntu
Hi Graham, you have to run 'configure --enable-hamlib' before the 'make' even if hamlib is installed. Please check that out. Btw, where did you find the pre2 version? I can no longer access it. 73, de Tom DL1JBE. On Tue, Jun 15, 2010 at 06:01:46PM +0100, Graham Saville wrote: > Hi Tom, Rein, I have Compiled the pre2 version and am still trying it out. > It does not seem to work with Hamlib it complains that it is not installed > even though it is. > > 73 Graham G1RNZ > > On 15/06/10 17:34, Thomas Beierlein wrote: >> Hi Rein, hi Graham, >> >> the pre2 version still contains some bugs which are fixed in the >> SVN repo. Unfortunately it stopeed working again Rein some days >> after you fixed it. >> >> If you agree I will set up a svn repo here at my side. It would >> be good to have the history so far in that repo too. A svndump of >> your repo (as soon as you are back home) would be helpful. >> >> 73, Tom DL1JBE. >> >> On Tue, Jun 15, 2010 at 11:01:27AM +0200, Rein Couperus wrote: >> -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF update?
Hi Olaf, Am Wed, 24 Nov 2010 10:46:52 +0100 schrieb "Olaf Devik" : > My copy of tlf has stopped working on my newly updated kubuntu > machine. I note some discussion on patches, but the last version I > can find is 0.9.30. Is there an updated version somewhere which I can > use? > Yes, actual GCC and Glibc does no longer excuse buffer overflows. So the old tlf version stopped working. There is a new one in (slow) development. I hope that we have fixed most problems. But to be honest no extended tests have been run in SSB mode so far. Please have a look at http://www.staff.hs-mittweida.de/~tb/tlf-1.0.0pre4.tar.gz It is the last version and should work reliable for CW contests. Please anyone who uses that version give feedback how it goes. If no severe problems arise I will prepare a new tlf-1.0.0 in next weeks. 73, de Tom DL1JBE. > Would very much get this in order for the upcoming tests. > > 73 de Olaf LA3RK > > Olaf Devik > Email: olaf.de...@mollefaret.no > Mob: +47 91170849 > > ___ > Tlf-devel mailing list > Tlf-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/tlf-devel -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Fw: [Tlf-devel] TLF update?
Sorry, sent the reply only to Olaf. Here is a copy. Tom DL1JBE Beginn der weitergeleiteten Nachricht: Datum: Wed, 24 Nov 2010 21:13:21 +0100 Von: Thomas Beierlein An: olaf.de...@mollefaret.no Betreff: Re: [Tlf-devel] TLF update? Hi Olaf, let me give some additional informations. Am Wed, 24 Nov 2010 21:02:23 +0100 schrieb Olaf Devik : > I assume your reference to tlf-1.0 refers to what is called xtlf in > Ubuntu repositories, which I installed successfully today to my > station computer. At first try at least the rig interface worked. If > my version is older than this reference I will try out the newer one. > No tlf-1.0.0 is *not* Xtlf-1.0. I understand the confusion about it. As Rein build the Xtlf he called it 1.0.0 and when we started the overhaul of the text based tlf he also called it 1.0 . So the version on the link is in fact a new version of the curses based tlf. > I only do CW so the restriction to CW should not be a major problem. Nice to hear. Please give it a try and come back with some feedback. I plan to make some final changes before christmas and maybe we have a nice shiny new version under the tree :-). > Normal logger is cqrlog, but this is not very suited for tests. The > backup is to setup my Windows computer and use some of the Windows > test loggers, but I try to avoid Windows around my radios. Yep. The same here. > > Thank you for feedback, and I assume your answer means that the > console based tlf will not be developed further. See above. 73, de Tom. DL1JBE. > > 73 de Olaf > > Den 2010-11-24 18:29, skrev Thomas Beierlein: > > Hi Olaf, > > > > Am Wed, 24 Nov 2010 10:46:52 +0100 > > schrieb "Olaf Devik": > > > >> My copy of tlf has stopped working on my newly updated kubuntu > >> machine. I note some discussion on patches, but the last version I > >> can find is 0.9.30. Is there an updated version somewhere which I > >> can use? > >> > > Yes, actual GCC and Glibc does no longer excuse buffer overflows. So > > the old tlf version stopped working. > > > > There is a new one in (slow) development. I hope that we have fixed > > most problems. But to be honest no extended tests have been run in > > SSB mode so far. > > > > Please have a look at > > http://www.staff.hs-mittweida.de/~tb/tlf-1.0.0pre4.tar.gz > > > > It is the last version and should work reliable for CW contests. > > > > Please anyone who uses that version give feedback how it goes. If no > > severe problems arise I will prepare a new tlf-1.0.0 in next weeks. > > > > 73, de Tom DL1JBE. > > > > > >> Would very much get this in order for the upcoming tests. > >> > >> 73 de Olaf LA3RK > >> > >> Olaf Devik > >> Email: olaf.de...@mollefaret.no > >> Mob: +47 91170849 > >> > >> ___ > >> Tlf-devel mailing list > >> Tlf-devel@nongnu.org > >> http://lists.nongnu.org/mailman/listinfo/tlf-devel > > > > -- "Do what is needful!" Ursula LeGuin: Earthsea -- -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF update?
Olaf, On Thu, Nov 25, 2010 at 12:09:19AM +0100, Olaf Devik wrote: > Thomas > > Thanks for input. I now have the correct tlf version up and running on the > station computer, cw keying now works ok and also radio control of my K3. > Nice to hear :-). > The only minor problem is that the cwkeying is not perfect as there is a > small truncation at the the start of every transmission, typically it > sounds like a normal dot being shortened to 2/3 thirds of its normal > length. Cw speed in testing is 25 wpm, not very fast. > Hmm. CW keying is done by cwdaemon program. Your problem sounds as if the PTT line is a little bit late (Or do you use full-BK?). > I am running in an xwindow console and the colours are not as they should > be, a clean console is much better, but I have no idea of how to set my > screen resolution to the size suitable for tlf. Currently when I start tlf > in a Linux console, the log window only covers the upper left part of the > screen. Yes. That is still a problem and maybe fixed in the future. TLF is designed for an 80x25 terminal. Most unix systems uses a higher resolution in console mode nowadays. For colour handling in the X terminal read the man page and look for the discussion of the TERM environment variable. You can experiment a little bit with the other TERN settings and maybe get better results. At the moment a better colour management and a better handling of different terminal sizes are on my long term todo list. > > Plan is to try out this version during the upcoming cqww cw contest this > weekend. So: Good and many DX! 73, de Tom Dl1JBE P.S.: I am on tour the next days and only back on sunday. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF update?
Hi Bob, can you please give some more inforamtion about your problem. Which Linux version do you use? How did you compile the program (which commands)? Am Thu, 2 Dec 2010 19:42:19 -0800 schrieb Bob Nielsen : > I tried to compile it on Debian testing (64-bit) and got hundreds of > "undefined reference" messages followed by : > > collect2: ld returned 1 exit status > make[2]: *** [tlf] Error 1 > make[2]: Leaving directory `/home/n7xy/tlf-1.0.0pre4/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/n7xy/tlf-1.0.0pre4' > make: *** [all] Error 2 > As you get 'undefined references' it seems that you have no header files for some of the needed libraries installed. Please pick some of the 'undefined' messages so that we can have a look at them. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] New TLF-1.0.0pre5
Please find a new prerelease version 5 for TLF-1.0.0 at http://www.staff.hs-mittweida.de/~tb/tlf-1.0.0pre5.tar.gz Changes: * Fixed some sporadic segfaults during write of markerfile for Xplanet (Thanks to Olaf LA3RK for pointing me to the problem). * Fixed handling of MARKERDOTS and MARKERCALL configuration commands (similar to MARKERS but with a slightly different representation in Xplanet). * New 'callmaster' database and 'cty.dat' file (Thanks to Martin OK1RR). As always, test reports and comments are welcome. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] New TLF-1.0.0pre5
Hi Stefan, Am Sat, 4 Dec 2010 16:09:14 +0100 schrieb Stephane Fillod : > Hi Tom, > > Thanks for taking care of tlf. It would be pity to let it rot. :-) > > Please find attached a short patch fixing some cppcheck[1] (v1.44) > warnings. > > [1] http://cppcheck.wiki.sourceforge.net/ Tanks. I will have a look into it in next time. > > BTW, does the current TLF source base is available from a SVN repo? > I can't reach hermes.esrac.ele.tue.nl. Same goes for me. It stopped working sometimes in spring for me. So I decided to use my own local SVN repo for the moment. It would be good to witch to a public one, but atm I have no good idea which to choose. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF 1.0.0. pre4 crashes
Hi Olaf, I just made TLF 1.0.0pre5 available yesterday (same address again) - seems you missed the mail. Please retest your problem with the new version. I hope that I have fixed just that random crash reason which resulted from some buffer overflows in the handling of cluster infos. Please test and report back. Thanks, Tom DL1JBE. Am Sun, 05 Dec 2010 00:04:14 +0100 schrieb Olaf Devik : > Just as a sidenote. I am currently using TLF 1.0.0pre04, compiled on > Ubuntu 10.04. Tlf compiles ok, but at least my version still crashes > from time to time. I am not sure what provokes this, but my last > crash was reported as follows: > *** buffer overflow detected ***: tlf terminated TRX: 7022.2 > ┌─Spots=== Backtrace: = > │ 1813.6 DR4A 2257Z│ /lib/libc.so.6(__fortify_fail+0x50)[0x1f5980]ZZ > 2256Z│ │ 3793.0 LZ/lib/libc.so.6(+0xe487a)[0x1f487a] > │ 1814.8 UR8IDX 2257Z│ /lib/libc.so.6(+0xe3d8e)[0x1f3d8e]│18084.0 > ZL7A 2256Z│ > tlf[0x8063a4f]SM3TLG 2257Z│ > │ tlf[0x8061d4d]│ > │ tlf[0x806206e] > └───┘ /lib/libpthread.so.0(+0x5cc9)[0xaa8cc9] > /lib/libc.so.6(clone+0x5e)[0x1e06ae] > === Memory map: > 0011-00267000 r-xp 08:01 66037 /lib/libc-2.12.1.so > 00267000-00268000 ---p 00157000 08:01 66037 /lib/libc-2.12.1.so > 00268000-0026a000 r--p 00157000 08:01 66037 /lib/libc-2.12.1.so > 0026a000-0026b000 rw-p 00159000 08:01 66037 /lib/libc-2.12.1.so > 0026b000-0026e000 rw-p 00:00 0 > 0026e000-0027 r-xp 08:01 66026 /lib/libdl-2.12.1.so > 0027-00271000 r--p 1000 08:01 66026 /lib/libdl-2.12.1.so > 00271000-00272000 rw-p 2000 08:01 66026 /lib/libdl-2.12.1.so > 00438000-0043e000 r-xp 08:01 65610 /lib/libusb-0.1.so.4.4.4 > 0043e000-0043f000 r--p 5000 08:01 65610 /lib/libusb-0.1.so.4.4.4 > 0043f000-00441000 rw-p 6000 08:01 65610 /lib/libusb-0.1.so.4.4.4 > 00606000-0061e000 r-xp 08:01 > 331467 /usr/lib/hamlib-kenwood.so 0061e000-0061f000 ---p 00018000 > 08:01 331467 /usr/lib/hamlib-kenwood.so 0061f000-0064d000 r--p > 00018000 08:01 331467 /usr/lib/hamlib-kenwood.so 0064d000-0064e000 > rw-p 00046000 08:01 331467 /usr/lib/hamlib-kenwood.so > 007a-007a7000 r-xp 08:01 > 331734 /usr/lib/libltdl.so.7.2.1 007a7000-007a8000 r--p 6000 > 08:01 331734 /usr/lib/libltdl.so.7.2.1 007a8000-007a9000 rw-p > 7000 08:01 331734 /usr/lib/libltdl.so.7.2.1 0083d000-00852000 > r-xp 08:01 331059 /usr/lib/libhamlib.so.2.0.12 > 00852000-00853000 ---p 00015000 08:01 > 331059 /usr/lib/libhamlib.so.2.0.12 00853000-00854000 r--p 00015000 > 08:01 331059 /usr/lib/libhamlib.so.2.0.12 00854000-00855000 rw-p > 00016000 08:01 331059 /usr/lib/libhamlib.so.2.0.12 00a0c000-00a42000 > r-xp 08:01 65803 /lib/libncurses.so.5.7 00a42000-00a44000 > r--p 00035000 08:01 65803 /lib/libncurses.so.5.7 00a44000-00a45000 > rw-p 00037000 08:01 65803 /lib/libncurses.so.5.7 00aa3000-00ab8000 > r-xp 08:01 66038 /lib/libpthread-2.12.1.so 00ab8000-00ab9000 > ---p 00015000 08:01 66038 /lib/libpthread-2.12.1.so 00ab9000-00aba000 > r--p 00015000 08:01 66038 /lib/libpthread-2.12.1.so 00aba000-00abb000 > rw-p 00016000 08:01 66038 /lib/libpthread-2.12.1.so 00abb000-00abd000 > rw-p 00:00 0 00b83000-00b9d000 r-xp 08:01 > 65711 /lib/libgcc_s.so.1 00b9d000-00b9e000 r--p 00019000 08:01 > 65711 /lib/libgcc_s.so.1 00b9e000-00b9f000 rw-p 0001a000 08:01 > 65711 /lib/libgcc_s.so.1 00c2c000-00c5 r-xp 08:01 > 66035 /lib/libm-2.12.1.so 00c5-00c51000 r--p 00023000 08:01 > 66035 /lib/libm-2.12.1.so 00c51000-00c52000 rw-p 00024000 08:01 > 66035 /lib/libm-2.12.1.so 00d8e000-00d8f000 r-xp 00:00 0 > [vdso] 00fbc000-00fd8000 r-xp 08:01 66014 /lib/ld-2.12.1.so > 00fd8000-00fd9000 r--p 0001b000 08:01 66014 /lib/ld-2.12.1.so > 00fd9000-00fda000 rw-p 0001c000 08:01 66014 /lib/ld-2.12.1.so > 08048000-08085000 r-xp 08:01 401435 /usr/local/bin/tlf > 08085000-08086000 r--p 0003c000 08:01 401435 /usr/local/bin/tlf > 08086000-08088000 rw-p 0003d000 08:01 401435 /usr/local/bin/tlf > 08088000-08418000 rw-p 00:00 0 0861c000-0863d000 rw-p > 00:00 0 [heap] b6757000-b6758000 ---p 00:00 0 > b6758000-b6f58000 rw-p 00:00 0 b6f58000-b6f59000 ---p > 00:00 0 b6f59000-b775c000 rw-p 00:00 0 > b7771000-b7773000 rw-p 00:00 0 > bfb41000-bfb56000 rw-p 00:00 0 [stack] > Aborted > > Sorry for the bad formatting, but this is as the crash is reported on > my system at least. > > I am not able to open the list so there may be a later version out > with corrections. > > Just for your info, it is just to restart tlf after a crash and sofar > I have not lost anything in my logs. > > 73 de Olaf LA3RK > > ___ > Tlf-devel mailing list > Tlf-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/tlf-devel -- "Do what is needful!" Ursula LeGuin: Earthsea --
[Tlf-devel] New TLF-1.0.0pre6
Please find a new prerelease version 6 for TLF-1.0.0 at http://www.staff.hs-mittweida.de/~tb/tlf-1.0.0pre6.tar.gz Changes: * Fixed reading CQDELAY from logcfg.dat. Thanks Martin OK1RR for reporting. * Fixed some potential buffer overruns and out of bounds errors reported by Stephane F8FCE. * Changed handling of ESC key for CW mode in call and exchange input field. New behaviour is suggested by Martin OK1RR: - ESC always stops sending any CW as before. - If in exchange field ESC simply drops any exchange data and goes back to call input 'without' deleting the call. You can edit the call and/or press return again to send anew. Only a second ESC empties the call input field. - If you press ESC in call input field the call sign will be deleted only if you did not start sending CW earlier (:CHARS set to a non-0 value or by pressing 'space' key). Otherwise it just stops sending. Please give especially the last feature a thorough test. If there are no serious bugs I will release a TLF-1.0.0 version before christmas (christmas presents are nice ... ). All further problems and enhancements will go in following versions. As always, test reports and comments are welcome. Have a nice time around christmas. Gd DX es 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] TLF-1.0.0 released
While still some work on TLF is needed to fix problems and add new features I think it is time to release a stable TLF-1.0.0 version. Please find the new version at: http://www.staff.hs-mittweida.de/~tb/tlf-1.0.0.tar.gz From the NEWS file: tlf-1.0.0 = Major cleanup release. Fixes lot of buffer overruns in string handling, which stopped old version from working with new GCC and GLIBC. * Better recognition of hamlib install (tnx F8FCE) * Rewrote handling of initial exchange file. It now allows empty and comment lines (#) and spaces around the callsign. Leading space before comment gets ignored. * Changed ESC handling in comemnt and call input field: Does no longer wipe out call and exchange field if you started sending. * New callmaster and cty.dat file (tnx OK1RR). Bugfixes: * Fix input handling of notes. * Fix autocq handling. - First characters gets no longer swallowed. - CQDELAY from logcfg.dat is now handled correct. * fix calculation of sunrise and sunset times * fix calculation of QSO Rate * fix parsing for MARKERDOTS and MARKERCALL keywords in logcfg.dat * make Backspace and Delete-Keys the same to allow some more terminal input encodings Enjoy using TLF and keep me informed about bugs, success stories and suggestions for new features. Merry Christmas es gd DX, Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Happy 2011
Hi Martin, a happy New Year to you too. Many thanks for your kind words. But let us not forget all the testers coming back with bug reports and all package managers for linux distributions around which make TLF available to the majority of users. 73 es hpe to meet u on air, Tom DL1JBE. Am Fri, 31 Dec 2010 14:07:03 +0100 schrieb Martin Kratoska : > Tom, Rein & all tlf developers, > > happy, healthy and prosperous New Year 2011! > > Many thanks for your outstanding work! > > 73 > Martin, OK1RR > > ___ > Tlf-devel mailing list > Tlf-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/tlf-devel -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.0.0 released
Hi Andy, Am Sun, 02 Jan 2011 20:52:18 + schrieb Andy Summers : > Hi Thomas and Happy New Year to all, > > So far so good on Fedora 14! I was thrilled to see my audio message > bugfixes made it into the stable release! I'll see how it goes in an > RSGB contest tomorrow. please let us know how it goes. > Coincidentally I got a Winkeyer USB for Xmas, but it seems I won't be > able to use it without some changes either to TLF or to OK2CQR's > Winkey USB server (thus far I've had no luck with Rein's original > perl version). I wonder if anyone has a good solution? I'll try and > explain the problem... > Congrat.s I will try to get one myself to be able to test how it works. > I have a TT Orion, which doesn't have separate PTT and key inputs. > When in CW mode PTT becomes key. Conventionally, RTS would control > PTT and DTR would be the key. With the Orion you must therefore > wire-OR the two outputs. The standard arrangement with TLF is to use > cwdaemon for CW, and this also provides PTT control during phone > operation. However, cwdaemon also asserts PTT automatically during > the CW message, so wire-OR-ing just gives you constant key-down for > the duration of the CW message. I've gotten round this issue by > hacking cwdaemon so it doesn't automatically assert PTT for a CW > message. > As far as I could see, cwdaemon does not assert PTT if you set the PTT-delay to 0 (at least in 0.9.4). Have you tried that for the Winkey server yet? > Now I have the Winkey I need the ability to turn-off automatic PTT > and assert/deassert PTT by the usual cwdaemon command (i.e. a1). > These features haven't been implemented in OK2CQR's Winkey USB server > yet, but Winkey itself looks like it would support it. > > Alternatively, a possible TLF feature request would be to add an > option for PTT via hamlib command, which is why I mention all this on > this reflector. > I fear that will not be possible. The problem is that we need to know when cwdaemon finishes its keying to know when to turn PTT off. But we get no feedback from cwdaemon back. I know there is some magic implemented but that signals only the point when cwdaemon has put all text into the keying buffer (and not when the last dot has left that buffer). 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] TLF maintenance release 1.0.1
Please find a maintenance version TLF-1.0.1 at: http://www.staff.hs-mittweida.de/~tb/tlf-1.0.1.tar.gz Bug fixes: -- * Fix logfile read error. Last QSO got read in twice. * Fix bug in cty.dat and in the routine which reads in the file Some prefixes from BY were not recognised. * Fix calculation of sun up and down time in MUF prediction window. It is now based on longitude from country description in cty.dat instead of the former timezone difference. That should be more accurate now. 73, de Tom DL1JBE -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Band map
Am Sun, 16 Jan 2011 00:45:44 +0100 schrieb Martin Kratoska : > We need a bigger band map window with more calls, possibly filtered > by mode. > Hi Martin, I know that the band map window is really small. There is not so much vertical space on a text screen. I see some possible solutions. For the moment you can ... 1. Set acceptance filter in the cluster "acc/spots on hf/cw" or so. 2. Scroll the band map window up and down. For the future I can think of 1. Make the band map window 2 lines higher (does not disturb other windows). 2. Show the spots araound your working frequency as default (your frequency is in the middle, above are lower frequency stations, below are stations with higehr frequency. Change that as you tune around the band. 3. In the long term I think of a total rework of the screen handling code. So we could use displays with higher number of columns and rows (also for window terminals on X) and allow the user to place and size the different windows as he likes. Any comments are welcome, Thomas DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF maintenance release 1.0.1
Hi Andy, thanks for the report. Am Sun, 23 Jan 2011 21:05:45 + schrieb Andy Summers : > There's a bug in netkeyer.c since TLF-1.0.0 that I can't figure out. > > Its symptoms are that when in SSB mode and you hit, say, F1 to send > that recorded message, cwdaemon gets a PTT=1 command but gets another > PTT=1 at the end of the message when it should get PTT=0. The effect > is that the rig is permanently keyed after pressing the F-key. > I will look into it. But it will be a busy week here and it is possible that I will find time only the next weekend. In meantime can you please start cwdaemon with a '-n' switch added. Then it will not go to daemon and output debug messages what it is doing. Try the PTT (for the new and old version) and send us the results. That would be helpful. Btw, which version of cwdaemon do you use? 73, de Tom DL1JBE. > I've had a look, but I'm confused because the correct string seems to > be sent to the sendto() system call. Even more confusing is if I edit > callinput.c so it sends PTT=0 at the beginning of the message, it > still asserts PTT! > > If I revert to netkeyer.c from TLF-0.9.31 PTT works OK again, but I > don't see that much is changed in that file. Another weird thing is > that if I go back to the new version, recompile, it stops working > properly, then go back to the old version and it still doesn't work. > If I then do 'touch netkeyer.h' and recompile it's fixed again. > There's no difference between the two .h files. > > My feeling is that sendto() is getting upset somehow, but I'm not > good enough with C to work it out. > > Has anyone else seen this, and/or does anyone have any ideas? For the > time being, I'm using netkeyer.c from TLF-0.9.31. > > 73 Andy, G4KNO. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF maintenance release 1.0.1
Hi Andy, thanks for your analysis so far. Am Tue, 25 Jan 2011 13:14:11 + schrieb Andy Summers : > In meantime can you please start cwdaemon with a '-n' switch added. > > Then it will not go to daemon and output debug messages what it is > > doing. > > > > Yeah, I already did that. cwdaemon just reports 'PTT on' or PTT off'. > There's no output of the string actually received. With the new > version of netkeyer.c you get two successive 'PTT on' reports, but > with the old version you get 'PTT on' followed by 'PTT off', as > expected. Just wondering because it works here as expected. > Btw, which version of cwdaemon do you use? > > > > I'm not at home right now, but I believe it's version 0.9. I have no > reason to believe it's a cwdaemon issue though. Well there is a 0.9.2 and a 0.9.4 version available. I have 0.9.4 here. My idea was that cwdaemon may interpret the strings diffenrently. By I did compare both versions and there are no differences in the relevant parts. > Found it. Here's output from diff for the fix: > > netkeyer.c > 178c178 > < sendto_rc = sendto(socket_descriptor, buf, strlen(buf), > --- > > sendto_rc = sendto(socket_descriptor, buf, strlen(buf)+1, > > At some point in the recent past sizeof() was replaced with strlen(), That was done by me. > which seems a legal thing to do, but it doesn't include the null > terminating character. Evidently sendto() wants the length including > the null character, or you get uncertain behaviour. Reverting to > sizeof() also fixes the problem of course, but isn't as tidy as the > whole of buf[] is then referenced. > I am just wondering because cwdaemon appends a '\0' at the end of the received string. So it should do no harm. But anyway I will switch back to sending an embedded '\0' with the string. I will use your version with 'strlen(buf) + 1'. New version should go out on the weekend. Thanks for the report. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] TLF maintenance release 1.0.2
Please find a new maintenance version TLF-1.0.2 at: http://www.staff.hs-mittweida.de/~tb/tlf-1.0.2.tar.gz Bug fixes: -- * Fixed bug in sending commands to cwdaemon netkeyer introduced in TLF-1.0.0. So PTT handling got sometimes wrong. Thanks for reporting Andy G4KNO. 73, de Tom DL1JBE -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Re: Bug in TLF maintenance release 1.0.2
Hi Martin, thanks for reporting. Am Sat, 05 Feb 2011 00:01:57 +0100 schrieb Martin Kratoska : > There is a bug: a QSO is not counted on the active band resulting in > QSO number -1. The :res comand corrects the score on inactive bands > however it subtract a QSO on the active band. The final QSO count is > correct except the active band where tlf shows always -1 QSO. > I see the problem and have an idea where it comes from. I will go for it. Should be fixed during this week. 73, de Tom DL1JBE. > 73 > Martin, OK1RR > > Dne 31.1.2011 11:45, Thomas Beierlein napsal(a): > > Please find a new maintenance version TLF-1.0.2 at: > > > > http://www.staff.hs-mittweida.de/~tb/tlf-1.0.2.tar.gz > > > > Bug fixes: > > -- > > * Fixed bug in sending commands to cwdaemon netkeyer introduced in > > TLF-1.0.0. So PTT handling got sometimes wrong. > > Thanks for reporting Andy G4KNO. > > > > 73, de Tom DL1JBE > > -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] TLF maintenance release 1.0.2
Please find a new maintenance version TLF-1.0.3 at: http://www.staff.hs-mittweida.de/~tb/tlf-1.0.3.tar.gz Bug fixes: -- * fix buffer overflow in 'send_lan_message' * fix wrong count of points and qso's for last band entry (tnx OK1RR) The last problem results from a double fault in original tlf version. I fixed the main problem in an earlier version but overlooked the correcting patch which I had to remove also. Sorry for that. 73, de Tom DL1JBE -- "Do what is needful!" Ursula LeGuin: Earthsea ___ Tlf-devel mailing list Tlf-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Tlf-1.0.4 maintenance release
Please find a new maintenance version TLF-1.0.4 at: http://www.staff.hs-mittweida.de/~tb/tlf-1.0.4.tar.gz Bug fixes: -- * fix wrong handling of recalled exchange (tnx OK1RR). New policy is a s follows - All calls from initial exchange file will be recognised even if part of a complex call, e.g. DL1CCL in LA/DL1CCL/p - All calls from former QSO's have to be exact including any pre- or postcombination - Now complete exchange will be recalled (not only first word) 73, de Tom DL1JBE -- -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF maintenance release 1.0.2
Hi Andy, thanks for the bug report. Am Wed, 08 Jun 2011 20:48:07 +0100 schrieb Andy Summers : > Bug report: > > TLF can handle this, although some post processing of the Cabrillo is > necessary. There's enough space in the received exchange field, but > when the Cabrillo is generated it truncates that field to 6 chars. > How about making the Cabrillo default to the displayed field width? > I will have a look into it (but not before next week). If Cabrillo standard allows it, I will see to implement your suggestion. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Tlf-1.0.5 maintenance release
Please find a new maintenance version TLF-1.0.5 at: http://www.staff.hs-mittweida.de/~tb/tlf-1.0.5.tar.gz Bug fixes: -- * fixes some nasty racing condition between bandmap code and checkwindow. In result prefix in lower line of checkwindow got displayed wrong, but country was right. Thanks Martin OK1RR for reporting. 73, de Tom DL1JBE -- -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF maintenance release 1.0.2
Hi Andy, thanks for your quick analysis. I come to the same conclusion. It seems that contest makers are very creative at defining new formats for their cabrillo entries. I am not sure if there will be an easy solution from TLF's point of view. Maybe some sort of template or so. I put it on the TODO list. In meantime I would suggest playing around with AWK. It is still possible to simple parse the logfile, extract the needed informations and put in a file with very few lines of awk code (maybe even with one line). Add the cabrillo header to that file and you are ready. I know that is one more tool to learn, but awk has proven useful in some cases for me, so it seems no waste of time :). Fell free to ask for help if you get difficulties with that. 73, de Tom. Am Thu, 09 Jun 2011 21:46:31 +0100 schrieb Andy Summers : > Hi Tom, > > There's no rush. I have until next year, hi! > > I had a quick look at the Cabrillo standard myself just now and can > see why it truncated to 6 chars. I was using the WPX rules and the > Cabrillo output for WPX is 6 chars only. > > Unfortunately, there is no standard length for the exchange field and > different sponsors may require different length fields to deal with > their particular flavour of contest. The RSGB RoPoCo is an example of > this; the postcode field being specified as 11 chars long. The only > way to reliably deal with this is to have individual set-ups for > every contest supported (and I'm guessing RoPoCo won't be one of > them!). As a matter of fact, the field lengths are often wrong for > other RSGB contest entries I make, but the Robot accepts them fine. I > imagine this is because it's looking for the space delimiters rather > than assuming fixed field widths. If this were true for all Robots I > guess increasing the field width wouldn't make any difference, but I > don't think that's necessarily a good idea. > > So, not sure how to tackle this. Maybe a rule file switch? > > 73 Andy, G4KNO. > > On 09/06/11 20:16, Thomas Beierlein wrote: > > Hi Andy, > > > > thanks for the bug report. > > > > Am Wed, 08 Jun 2011 20:48:07 +0100 > > schrieb Andy Summers: > >> Bug report: > >> > >> TLF can handle this, although some post processing of the Cabrillo > >> is necessary. There's enough space in the received exchange field, > >> but when the Cabrillo is generated it truncates that field to 6 > >> chars. How about making the Cabrillo default to the displayed > >> field width? > >> > > I will have a look into it (but not before next week). If Cabrillo > > standard allows it, I will see to implement your suggestion. > > > > 73, de Tom DL1JBE. > > > > -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Anyone using TLF with a Ten-Tec Orion?
Hi, if we have some OMs around using an Ten-Tec Orion together with TLF i would like to know if you are using it via hamlib or with the old native orion interface introduced some years ago. The story behind my question: The old native interface blocks all new rigs supported by hamlib with an rig number >2000. Furthermore the code complicates maintainance. So I would like to drop it in further relaeses if not needed anymore. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Anyone using TLF with a Ten-Tec Orion?
Hi Martin, thanks for the good news. I will prepare a test version without the old code in next time. 73, de Tom DL1JBE Am Sat, 23 Jul 2011 12:29:32 +0200 schrieb Martin Kratoska : > Using Orion with hamlib (rig ID 1608). Works like a champ, no > problems. I assume that the internal Ten-Tec radio control is not > needed anymore and could be removed. > > 73 > Martin, OK1RR > > Dne 23.7.2011 11:38, Thomas Beierlein napsal(a): > > Hi, > > > > if we have some OMs around using an Ten-Tec Orion together with > > TLF i would like to know if you are using it via hamlib or with the > > old native orion interface introduced some years ago. > > > > The story behind my question: > > The old native interface blocks all new rigs supported by hamlib > > with an rig number>2000. Furthermore the code complicates > > maintainance. So I would like to drop it in further relaeses if not > > needed anymore. > > > > 73, de Tom DL1JBE. > > -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Early preview of new bandmap function for TLF-1.1
In last time I did some work to add a new bandmap display to TLF. The existing one is severly limited with only 8 visible entries and the growing use of cluster spots in contests can no longer be met. Please find a very early preview of the new bandmap display at http://www.staff.hs-mittweida.de/~tb/tlf-1.1.0pre1.tar.gz Best try these version with a cluster connection and a connected rig. Building is done as usual. Please read the 'New-Bandmap.txt' file in the main directory to get an idea of the new bandmap and how to use it. At the time being there are still several known problems and limitiations: - Color display works not for every TERM and terminal combination as before (tested with TERM=xterm and KDE terminal as well as TERM=linux and a normal linux text console). - If there are a lot of spots we need a way to scroll the display. - The actual operating frequency should be shown on the map. - The algorithm to check for dupes ignores the working mode and does look only for the band. - The scoring window should be moved out of the way, turn it off with Ctrl-S for the moment. Please test and give some feedback. Bug reports and improvement suggestions are welcome. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF 1.1.0
Hi Fred, back from holiday let me answer your test report. First thanks for the report. Am Mon, 08 Aug 2011 23:11:59 +0200 schrieb Fred Siegmund : > first: I had a very good time in EUHFC with the programme although > coming from a CT-based logger like yfktest > is something new to learn. Especially with "SPACE" to transmit > something is unusal. I don't know which use-case > that is for. I often trx'd my call at the wrong time because I > pressed "SPACE" intuitivly to go to the numbers field. :-) Better use 'ENTER' to switch from one QSO state to the next (including sending). > Bandmap works great. Maybe the combination "CTRL-G" is not the best > choice because the G is so far away > on the keyboard for one hand maybe "CTRL->" and "CTRL-<" to go > downwards in frequency would be a better choice but > thats my personal feeling. I kept CTRL-G as it was used in the former - very limited - bandmap display and did not want to irritate long time TLF users with a new key combination. But CTRL-< sounds like an alternative for the future. > Some more notices: > > - "segmentation fault" > If the number of spots is >200 its likely the programme crashes soon > with this announcement. Thanks for reporting. I will look into this. > > - life time for spots > When using reversebeacon the bandmap is soon very crowded. And > because the skimmers set a new spot every 15min > or so, its not neccessary to keep them for a longer time in the > bandmap then that. > OK. It will be user adaptable in the future. > - exact frequency in cabrillo > More and more contests sponsors require the exact frequency named in > the cabrillo file for extended checking. > I know, but that is a lot of work in TLF as a whole. Thanks for reminding me. > - graphics/terminal related > Beside the known colour problems, in my xterm the complete lower half > is now band map, means "MEM" frequency > display and country information (green bar at the bottom) is gone. > Probably terminal related. > First the colour problem: You can define the 16 colors which xterm uses in your ~/.Xdefault and restart X or 'xrdb .Xdefault', e.g.: *color0: #00 *color8: #555753 ! DarkRed + Red *color1: #ff6565 *color9: #ff8d8d ! DarkGreen + Green *color2: #93d44f *color10: #c8e7a8 Regards 'MEM' display and bottom bar - that is respected for me. Any other station can confirm this? > - .paras file > I changed the messages F1-F6 for my personal needs but if I edit the > write-out in .paras for the top green bar, it doesn't show up in the > programme. > The .paras file is not really used - I do not know if it was ever. Please use the logcfg.dat for setting your messages. But the displayed top bar is a fixed text (as it seems it was from the beginning). Changign that bar according to your CW messages is already on the todo list. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] user update tlf1.1.0
Hi Fred, thanks for the reports. I will try to look into it next days. Am Mon, 22 Aug 2011 21:23:53 +0200 schrieb Fred Siegmund : > Hi all, > > bug: while generating cabrillo file with succsessive numbering (user > is asked to insert "#" for that) > there are only # in the cab file > > bug: segmentation fault while loading a too large MULT file. I tried > to load a file with all russian RDAs > for the RDA contest (ca. 13k) > Can you please send me that file and your logcfg.dat by private mail for testing? 73, de Tom DL1JBE -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF 1.1.0
Hi Fred, let me answer your comments. Am Fri, 02 Sep 2011 10:40:56 + schrieb FS : > > Better use 'ENTER' to switch from one QSO state to the next > > (including sending). > I do! But there are many case where you have to move between the > fields. Most programms I know use to go > from left to right and from right to left. In the last docu > 0.9.9 from Rein it says: "You can go to the exchange field with SPACE > or TAB or ENTER." That would be much better!! > It also says that SPACE in the call field starts early sending of callsign (see second paragraph in COMMAND section of tlf man page). Maybe it is not the best choice, but there is already a large user base for tlf for some years now. I do not want to change well-established practises easily. > > Regards 'MEM' display and bottom bar - that is respected for me. Any > > other station can confirm this? > Regarding the bottom bar, its there but I didnt notice until I > changed terminal settings to vertical 25 lines. Well. I will add a warning if on startup if your terminla has less than 25 lines. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF 1.1.0
Hi Graham, thanks for the report. Let me give some comments. Am Fri, 2 Sep 2011 14:42:17 -0400 schrieb "Collins, Graham" : > I use Ubuntu 10.04lts and initially had problems with TLF 0.9.x and > was never able to run the app but what I read about TLF intrigued me > and I eventually found the fix and the more recent versions 1.x.x. > Well, the TLF 0.9 series got crippled by the fact that newer glibc libraries do not tolerate buffer overflows anymore. That was one of the main reasons to do a TLf 1.0 release. > So far so good. I created a rules file for use in the Ohio QSO party > last weekend and I am quite pleased with TLF and it is suitable > substitute for N1MM for my needs. > > The only issue I had with TLF was when I created the Cabrillo log, > TLF truncated the exchange field. The exchange for the QSO party was > the four letter abbreviation for the county (i.e. LAKE). This filed > was truncated to either two or three characters dependent on one of > the other data fields. The full four characters where in the TLF log > so it looks like it is just a simple truncation issue. I may just > take some time to write a little program to convert the TLF log to > Cabrillo. > One problem are the different cabrillo formats for different contests. TLF supports only one or two basic formats (WPX if I remember correct). For the moment I also would suggest an external conversion (maybe by some AWK magic). If you find a working solution, let us know. I can add it to the next versions so others can benefit from it. > Someone else mentioned that they desired to have the frequency > logged. This is also one of my desires. The data is available through > hamlib and displayed and in QSO mode (i.e. not Contest mode) the > frequency is put in the TLF log (as the last entry on the line I > think). > That is on the TODO list for next time. But it will request a cmplete change of the log file format. In dxcc mode there is room in the 80 character log lines, but not in contest mode. So for that to solve we need to switch to another log format. > I have started to look through the source code to try and get a > better understanding of how the program works and what would be > required to add the frequency to the TLF log in contest mode. > Think also, that you need to reread the data in case you stop and later restart TLF. Let us know if you find some way to do it. 73, de Tom DL1JBE. > Cheers, Graham ve3gtc > > > > -Original Message- > From: tlf-devel-bounces+colling=navcanada...@nongnu.org > [mailto:tlf-devel-bounces+colling=navcanada...@nongnu.org] On Behalf > Of Thomas Beierlein Sent: September 2, 2011 01:09 To: > tlf-devel@nongnu.org Subject: Re: [Tlf-devel] TLF 1.1.0 > > Hi Fred, > > back from holiday let me answer your test report. > > First thanks for the report. > > Am Mon, 08 Aug 2011 23:11:59 +0200 > schrieb Fred Siegmund : > > > first: I had a very good time in EUHFC with the programme although > > coming from a CT-based logger like yfktest > > is something new to learn. Especially with "SPACE" to transmit > > something is unusal. I don't know which use-case > > that is for. I often trx'd my call at the wrong time because I > > pressed "SPACE" intuitivly to go to the numbers field. :-) > > Better use 'ENTER' to switch from one QSO state to the next (including > sending). > > > Bandmap works great. Maybe the combination "CTRL-G" is not the > > best choice because the G is so far away > > on the keyboard for one hand maybe "CTRL->" and "CTRL-<" to go > > downwards in frequency would be a better choice but > > thats my personal feeling. > > I kept CTRL-G as it was used in the former - very limited - bandmap > display and did not want to irritate long time TLF users with a new > key combination. But CTRL-< sounds like an alternative for the future. > > > Some more notices: > > > > - "segmentation fault" > > If the number of spots is >200 its likely the programme crashes > > soon with this announcement. > > Thanks for reporting. I will look into this. > > > > - life time for spots > > When using reversebeacon the bandmap is soon very crowded. And > > because the skimmers set a new spot every 15min > > or so, its not neccessary to keep them for a longer time in the > > bandmap then that. > > > OK. It will be user adaptable in the future. > > > - exact frequency in cabrillo > > More and more contests sponsors require the exact frequency named in > > the cabrillo file for extended checking. > > > I know, but that is a lot of work in TLF as a
Re: [Tlf-devel] TLF 1.1.0
Hi Graham, Am Tue, 6 Sep 2011 13:39:12 -0400 schrieb "Collins, Graham" : > I will be sure to post about anything I develop to work with TLF. > > As to "rules" files; is there a suggestion or want or desire to > collect additional or user created files for inclusion or to place in > some repository for others to access? > I would strongly prefer such a collection. At the moment the only way is to post it here and I will include it in next versions. I am working on a public repo for TLF together with an Wiki were we can add such contributions easily. 73, de Tom DL1JBE. > No sense in re-inventing the wheel if someone already has a solution. > > Cheers, Graham ve3gtc > > > > -Original Message- > From: Thomas Beierlein [mailto:t...@forth-ev.de] > Sent: September 6, 2011 13:32 > To: Collins, Graham; tlf-devel@nongnu.org > Subject: Re: [Tlf-devel] TLF 1.1.0 > > Hi Graham, > > thanks for the report. Let me give some comments. > > Am Fri, 2 Sep 2011 14:42:17 -0400 > schrieb "Collins, Graham" : > > > I use Ubuntu 10.04lts and initially had problems with TLF 0.9.x and > > was never able to run the app but what I read about TLF intrigued me > > and I eventually found the fix and the more recent versions 1.x.x. > > > Well, the TLF 0.9 series got crippled by the fact that newer glibc > libraries do not tolerate buffer overflows anymore. That was one of > the main reasons to do a TLf 1.0 release. > > > So far so good. I created a rules file for use in the Ohio QSO party > > last weekend and I am quite pleased with TLF and it is suitable > > substitute for N1MM for my needs. > > > > The only issue I had with TLF was when I created the Cabrillo log, > > TLF truncated the exchange field. The exchange for the QSO party was > > the four letter abbreviation for the county (i.e. LAKE). This filed > > was truncated to either two or three characters dependent on one of > > the other data fields. The full four characters where in the TLF log > > so it looks like it is just a simple truncation issue. I may just > > take some time to write a little program to convert the TLF log to > > Cabrillo. > > > One problem are the different cabrillo formats for different contests. > TLF supports only one or two basic formats (WPX if I remember > correct). > > For the moment I also would suggest an external conversion (maybe by > some AWK magic). If you find a working solution, let us know. I can > add it to the next versions so others can benefit from it. > > > > Someone else mentioned that they desired to have the frequency > > logged. This is also one of my desires. The data is available > > through hamlib and displayed and in QSO mode (i.e. not Contest > > mode) the frequency is put in the TLF log (as the last entry on the > > line I think). > > > That is on the TODO list for next time. But it will request a cmplete > change of the log file format. In dxcc mode there is room in the 80 > character log lines, but not in contest mode. So for that to solve we > need to switch to another log format. > > > I have started to look through the source code to try and get a > > better understanding of how the program works and what would be > > required to add the frequency to the TLF log in contest mode. > > > Think also, that you need to reread the data in case you stop and > later restart TLF. > > Let us know if you find some way to do it. > > 73, de Tom DL1JBE. > > > > Cheers, Graham ve3gtc > > > > ___ > Tlf-devel mailing list > Tlf-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tlf-devel -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] TLF repository now on github.com
Hi all, in last weeks I did some cleanup of my internal development repository and prepared it for public hosting. After some checks I decided to host it on GitHub. Besides git repositories GitHUb provides - static web pages for projects - some issue tracking system for bug reporting - a Wiki - tools for code review and collaboration of some developers on the repository and some more. I created an account for Tlf at http://github.com/Tlf/tlf Static web pages and Wiki are empty/not existent at the moment. You can always get a copy of all the actual code by either - pressing the Download button in the upper right or - getting a clone of the whole repo with 'git clone git://github.com/Tlf/tlf.git ' You have to run 'autoreconf -i -f' './configure --enable-hamlib' 'make' 'make install' in the root directory of the code (see INSTALL file) if you want to compile the code. If you want to contribute you can send patches or clone/fork the repository as above, make changes and send pull requests. Please have a look and give feedback. 73, de Tom DL1JBE. P.S.: I am not sure if the above mentioned wiki is a good starting point for us, as it requires a GitHub registration if you want to contribute. What do you think? -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] New TLF prelease tlf-1.1pre1
A new prerelease version of TLF is available at: http://www.staff.hs-mittweida.de/~tb/tlf-1.1pre1.tar.gz It fixes some minor problems related to the new bandmap display but the most work was made on the scoring engine for mults. As some of you (esp. Martin OK1RR) pointed out, the scoring of multis was very inconsistent, especially after a restart of tlf or the ':res' command. The new version should work a lot better now and I hope I did not introduce some new problems here. Please try it out for the classic contests support by TLF and also for the WYSIWYG_ONCE and _MULTI modes. If you observe a wrong scoring please let me know and add the logcfg.dat and the rules file to your post. In detail the following changes were made: - drop old unsupported configuration variable MANY_CALLS (was of no use for a long time already) - lists of possible multipliers can have any number of entries now. Comment lines (starting with a '#' in column 0) are allowed. Any trailing white space gets stripped, only the relevant part of a line is remembered. !!! Be aware that not any multiplier scheme is supported at the moment. There has some work to be done - For WYSIWYG multis the whole comment entry is evaluated as multi. Until now it was only the first space delimited word. Please give feedback if that is what you need. - The scoring engine was simplified and reworked. It should now correctly count any recorded multipliers during contest as well as during a ':res' rescore command or a new start of tlf with some entries already in the log. !!! If you delete a QSO you have to manually rescore the log (:res). !!!Please test and give me feedback. Please use it with care in a real contest. It may contain new bugs!!! After getting your ok to that changes I will load them up to the github repo and merge them with the other changes made there. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] New tlf ideas
Hi Martin, that discussion comes right in time. Thanks for bringing it up. Am Sat, 08 Oct 2011 00:28:10 +0200 schrieb Martin Kratoska : > It seems that the real tlf bottleneck is in the predefined contest > templates, still hardwired in the program. Any attempt to define a > contest in 'CQWW like' style is definitely wrong. The 'core' tlf > should be free from this debris code, the whole contest rules should > be in an external ASCII definition file. All must be freely definable > without the potential risk that the values entered into contest rules > will be overwritten with program internal hardwired values. > Well, that can be done. The real challenge is to find a good syntax to allow as much flexibility as needed for specifying the scoring rules for multipliers as well as for points. > Another source of potential problems is the checking routine which > 'checks' if the entered received code has proper syntax and if not, > it prevents the program from QSO logging progress, does not allow to > send the exchange etc. This is the weak point of most contesting > software, actually is only annoying part making useless any attempt > to define user's own contest. Right. And that is one of TLF's darkest corners. I will be very glad if I can drop or replace that section of code. A 'hint' about being right with your exchange may be good for the operator, but it must not forbid you to enter 'any' exchange you like. > We should collect all types of the points distribution for a contact > and all known types of multipliers. I analyzed >160 different contest > rules so I should be able to create a basis of both above mentioned. > Let me know if I should start this work, I assume I would need a week > or two to provide a draft version. I will greatly appreciate your contribution here as I miss a lot of experience with different contests. I would suggest to collect that knowledge base on the wiki (tlf.wikispaces.com) so others can contribute. Another way may be the wiki on our github repo, but it needs any contributor to sign up at github. 73, de Tom DL1JBE -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] MMTTY plugin for TLF?
Am Mon, 10 Oct 2011 02:21:15 + (GMT) schrieb w...@w9wi.com: > > On Oct 9, 2011, Martin Kratoska wrote: > > >BTW a true FSK is a must for RTTY, AFSK or several pseudoFSK options > >are rather annoying. The same was with Windoze until JE3HHT created > >MMTTY. My suggestion is to search for a keen programmer who will be > >able/willing to solve the FSK timing issues and create a true FSK > >program for Linux. One field to look into is a realtime linux system. But I do not know if that is enough. > > I am absolutely NOT that keen programmer(grin)... > > I wonder, might the answer be some kind of external hardware device? > I'm thinking "Winkey for FSK", possibly implemented on Arduino > hardware. Sure that is one possible solution. One drawback of most existing external devices is that they miss some kind of feedback about progress in sending. With that the idea sounds interesting. > Actually, wouldn't that be fairly simple, since the > external device doesn't have to worry about receiving? (that can be > done in DSP on the Linux host) You'd just feed ASCII characters to > the external hardware over a RS-232 or USB port; the hardware (OK, > firmware) would map to Baudot & shift a digital output port up & down > with appropriate timing. > > > ___ > Tlf-devel mailing list > Tlf-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tlf-devel -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] New TLF prelease tlf-1.1pre1
Hi Andy, thanks for your test report. Let me try to answer your questions. Am Mon, 24 Oct 2011 20:25:10 +0100 schrieb Andy Summers : > Thanks for the new bandmap functions. I've been trying it out with a > view to dabbling in CQWW - I'm aware it may not be stable. > I did some work in last weeks to stabilize it and I think pre2 will be much better there. > I've read the New_Bandmap.txt and don't think it works as described > there. If I enter a call, press ctrl-A, I see it added to the > bandmap. I tune somewhere else and do the same thing. I can do this > several times and see the calls added, but when I repeatedly hit > ctrl-g it only picks the most recent spot. You are right, that is what is implemented. My idea behind that was that you normally only have one spot of a station per band and mode. If you filter your bandmap by mode or band Ctrl-g will select the right spot. Are there reasonable scenarios where we have would need to select between more than one spot per band/mode for the same station? Than I should think about a way to handle it. > > Also, I see that a MEM frequency appears under the normal frequency > display, but you don't say how to get the rig back onto that > frequency. Simply switching mode back to Log, doesn't do it. > The memory recall is the same as in normal memory operation. As the man page says hitting '#' records frequency if memory is empty and recalls it if it is set. So after grabing a spot you can switch back to Run mode by '+' and to old frequency by '#'. > It would be quite useful to be able to arrow up/down the spot list > and select the specific spot you want, rather than have to scroll > through the lot to get to the one you want. It's a long time since I > used CT, but it might be worth studying how that worked. I do > remember that you could toggle alt-F4 (or was it F3) to toggle > between the selected spot and the current run frequency. That was > really useful for continuing to CQ, keep your frequency warm and > periodically check back to see if the spot was workable. > I see the point and will think about to implement something similar. But it will be at low priority at the moment. > BTW, the score or frequency window overlaps the new spot mode info > and doesn't look right. > The score window will be in the upper right in next prerelase (just did it yesterday :-) ). As the frequency window is only temporarily visible it may hide the bandmap for that time - should be acceptable. Am Mon, 24 Oct 2011 20:28:04 +0100 schrieb Andy Summers : > I also forgot to mention that if you log a call but then hit minus to > delete the last QSO, that call shows up in the bandmap as a dupe. > Same as for correcting the score after delete, see below... > On 07/10/11 18:54, Thomas Beierlein wrote: > >!!! If you delete a QSO you have to manually rescore the log > > (:res). > > Btw, I plan to release the next prerelease version in next two week. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] New TLF prelease tlf-1.1pre2
A new prerelease version of TLF is available at: http://www.staff.hs-mittweida.de/~tb/tlf-1.1pre2.tar.gz Just in time before CQWW SSB it fixes some problems from last release: In detail the following changes were made: - Fix for the segfault due to raising condition if heavy load on cluster (tnx Fred DH5FS for reporting) - drop old 'SPOTLIST' config parameter. Functionality is now in 'BANDMAP' display. !!Please check your logcfg.dat file!! - move scoring information to upper right corner so it does not hide the bandmap anymore. See if you like it and give feedback! Further fixes will be hopefully done before CQWW CW. 73, de Tom DL1JBE -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Patch for 40 meter band edges
Am Fri, 28 Oct 2011 01:34:05 -0400 schrieb Ben Coleman NJ8J : > I compiled tlf 1.1pre2 earlier today, was testing it out, and found > that when switching to 40 meters, tlf was not changing to 40, even > though the correct frequency was showing. Turns out the 40 meter > frequency I was checking to was between 7200 and 7300 khz, and tlf > wasn't recognizing it as a 40 meter frequency when switching to it > (but it was recognized at startup). Looks like the problem is > incorrect band-edges specified for 40 in gettxinfo.c. Attached is a > patch for this. > > Ben Good catch Ben. Thanks. A similar problem did exist also for upper bounds of 160m band. Fixed in git repo now. 73, de Tom DL1JBE -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] voicekeyer tlf-1.1pre2
Hi Rob, Am Fri, 28 Oct 2011 21:45:04 -0700 schrieb Rob Vance : > I am using tlf on 11.04 (Natty Narwhal). It's working fine except I > am having a problem with the voice keyer. When using either the > auto-keyer or an F-key to send an audio track, I get this string on > the screen. > > amixer: Unable to find simple control 'Mic',0 TLF tries to mute the microfone input on your soundcard. The problem lies in the hardcoded assumption that there is such an input device on your soundcard. > I asked amixer to > give me a list of devices and discovered that there is none called > 'Mic' at all. So apparently tlf is calling a device called 'Mic' and > amixer is telling it there is no such device (?). Exactly. > If so, can someone > advise on a method to change this parameter? > As a quick fix I would suggest to comment out lines 1236 and 1238 in src/callinput.c and recompile. That will drop the amixer invocation. Keep an eye to the possibility to catch additional microfon input signals during sending of one of the F-key audio tracks. 73, de Tom DL1JBE > Hope everyone is enjoying CQ WW. > > 73, > > Rob, N6ROB -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] New TLF prelease tlf-1.1pre1
Hi Fred, hi Andy, just got time to look into it: 1. VKSPR and VKCWR are badly named. THey should be VKSPM (S&P message) and VKCQM (CQ message). I will rename it in next prerelease accordingto the manual. 2. In SSB mode pressing enter log the QSO immediately without any following messages. Before tlf-0.9.23 it sent the VKSPM or VKCQM. That got changed by Rein with that version. I do not know why! But we can revert the change in a very simple way. If you do not define the filename in logcfg.dat it will not send anything. So you can decide on your own how you like it. What do you think? 73, de Tom DL1JBE. Am Wed, 26 Oct 2011 21:24:12 +0100 schrieb Andy Summers : > Hi again Fred, > > I've had a look but I haven't really got to the bottom of it. > According to the most recent manual this recording is VKSPM, not > VKSPR, despite "parse_logcfg.c" apparently looking for VKSPR. > > The auto exchange behaviour is actually contained in "logit.c". In > there you'll see that 'ph_message[12]' is to be played in S+P mode. > That message is recorded via "audio.c" on the 'S' message. > Unfortunately, if you try to record to 'S' there is a problem. > However, I recorded a message on another F-key and manually renamed > it to "vkspm.wav". In the rule file I added > "VKSPM=/home/ags/tlf/vkspm.wav", and this actually worked! I tried > the same with the VKCQM message, but then it all stopped working. In > any case, it looks like CQ mode doesn't send the VKCQM message but > the F3 message anyway. > > If you really want the VKSPM function for the weekend you could try > this work-around. In slow-time we have to work out what's the > underlying problem. > > 73 Andy, G4KNO. > > On 26/10/11 10:16, FS wrote: > > Hi all, > > > > while preparing for WWDX SSB I noticed that the VKSPR message is > > not sent in SP mode after inserting the zone in the numbers field. > > The Call file is sent after inserting the other stations call at > > "call input". Anybody knows why? I saw a lot of g4kno editing in > > the sources there ;-) > > > > 73 Fred > > > > On 10/25/2011 04:32 AM, Thomas Beierlein wrote: > >> Hi Andy, > >> > >> thanks for your test report. Let me try to answer your questions. > >> > >> Am Mon, 24 Oct 2011 20:25:10 +0100 > >> schrieb Andy Summers: > >>> Thanks for the new bandmap functions. I've been trying it out > >>> with a view to dabbling in CQWW - I'm aware it may not be stable. > >>> > >> I did some work in last weeks to stabilize it and I think pre2 > >> will be much better there. > >> > >>> I've read the New_Bandmap.txt and don't think it works as > >>> described there. If I enter a call, press ctrl-A, I see it added > >>> to the bandmap. I tune somewhere else and do the same thing. I > >>> can do this several times and see the calls added, but when I > >>> repeatedly hit ctrl-g it only picks the most recent spot. > >> > >> You are right, that is what is implemented. My idea behind that was > >> that you normally only have one spot of a station per band and > >> mode. If you filter your bandmap by mode or band Ctrl-g will > >> select the right spot. > >> > >> Are there reasonable scenarios where we have would need to select > >> between more than one spot per band/mode for the same station? > >> Than I should think about a way to handle it. > >>> > >>> Also, I see that a MEM frequency appears under the normal > >>> frequency display, but you don't say how to get the rig back onto > >>> that frequency. Simply switching mode back to Log, doesn't do it. > >>> > >> The memory recall is the same as in normal memory operation. As > >> the man page says hitting '#' records frequency if memory is empty > >> and recalls it if it is set. So after grabing a spot you can > >> switch back to Run mode by '+' and to old frequency by '#'. > >> > >>> It would be quite useful to be able to arrow up/down the spot list > >>> and select the specific spot you want, rather than have to scroll > >>> through the lot to get to the one you want. It's a long time > >>> since I used CT, but it might be worth studying how that worked. > >>> I do remember that you could toggle alt-F4 (or was it F3) to > >>> toggle between the selected spot and the current run frequency. > >>> That
Re: [Tlf-devel] voicekeyer tlf-1.1pre2
Am Wed, 2 Nov 2011 11:05:56 -0700 schrieb Rob Vance : > Hi Andy, > > No apology required. Yes, the short answer is that the sound card has > several microphone inputs but the names are different. I'm not at the > machine now but I recall there are "front mic"& "rear mic" of various > types, but none are called just plain "mic". > > I should have reported back to Thomas: Yes, commenting out the lines > solved the problem and the keyer worked as expected without any > complaints from amixer (in my code it was lines 1234 and 1236). It > was a very satisfactory work-around as I don't use other mic inputs > during contesting. Hi Andy and Rob, nice to hear that my suggestion worked. I will change the code in the next days to call one external shell script for playback and provide an example. That shell script has to be adapted by the user and can - mute / unmute the mic, - set the gain, - play the file, - set / drop any external/internal signal it needs to work with your hardware and - do anything else you have to do. So the flexibility is in your hands without playing with the code. What do you think? Just to find some time for it ... (I hope at the weekend). 73, de Tom DL1JBE. > Alternatively I suppose I could have just renamed > the entries in lines 1234/1236 to match my sound card and thus had > the benefit of suppressing other sounds (mic inputs) during the voice > keyer operation; but I have not tried this. > > Thank you so much for the updates to the scoring and bandmap; I am > still playing around with it, but I like it so far. > > I have another question about the operation of the program, but I > will post that separately as it is quite different from this topic. > > 73, > > N6ROB > > On Wed, Nov 2, 2011 at 10:32 AM, Andy Summers > wrote: > > > Hi, > > > > Sorry about that, it was my fault. I just sent my hacks, to get it > > to do what I wanted it to do, over to Rein and they appeared in the > > code. I'm not confident enough to add in a config option for using > > the soundcard mic, so hopefully you might do that Tom? I presume > > that's what's needed? > > > > Can you really get soundcards without a mic input? Or is it just > > called something slightly different on that soundcard? > > > > 73 Andy, G4KNO. > > > > On Sat, Oct 29, 2011 at 7:39 AM, Thomas Beierlein > > wrote: > > > >> Hi Rob, > >> > >> Am Fri, 28 Oct 2011 21:45:04 -0700 > >> schrieb Rob Vance : > >> > I am using tlf on 11.04 (Natty Narwhal). It's working fine > >> > except I am having a problem with the voice keyer. When using > >> > either the auto-keyer or an F-key to send an audio track, I get > >> > this string on the screen. > >> > > >> > amixer: Unable to find simple control 'Mic',0 > >> > >> TLF tries to mute the microfone input on your soundcard. > >> > >> The problem lies in the hardcoded assumption that there is such an > >> input device on your soundcard. > >> > >> > I asked amixer to > >> > give me a list of devices and discovered that there is none > >> > called 'Mic' at all. So apparently tlf is calling a device > >> > called 'Mic' and amixer is telling it there is no such device > >> > (?). > >> > >> Exactly. > >> > >> > If so, can someone > >> > advise on a method to change this parameter? > >> > > >> As a quick fix I would suggest to comment out lines 1236 and 1238 > >> in src/callinput.c and recompile. That will drop the amixer > >> invocation. Keep an eye to the possibility to catch additional > >> microfon input signals during sending of one of the F-key audio > >> tracks. > >> > >> 73, de Tom DL1JBE > >> > >> > Hope everyone is enjoying CQ WW. > >> > > >> > 73, > >> > > >> > Rob, N6ROB > >> > >> > >> > >> -- > >> "Do what is needful!" > >> Ursula LeGuin: Earthsea > >> -- > >> > >> > >> ___ > >> Tlf-devel mailing list > >> Tlf-devel@nongnu.org > >> https://lists.nongnu.org/mailman/listinfo/tlf-devel > >> > > > > > > ___ > > Tlf-devel mailing list > > Tlf-devel@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/tlf-devel > > > > -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] voicekeyer tlf-1.1pre2 and other matters
Hi Andy, hi Fred, thanks for the bug reports. I am working on it. Am Wed, 02 Nov 2011 20:30:24 + schrieb Andy Summers : > When you tab, spacebar or enter to get into the exchange field you > see the caret positioned after the exchange, ready for you to > backspace to correct if necessary. Anything you do after that point > seems to lose the caret marker. In fact it looks like it's positioned > up in the 'worked' window. > The cursor problems got fixed in meantime in commits until d38a6c9b44 in tlf's repo (github.com/Tlf/tlf). > I liked the bandmap, but again, if you've moved on to the exchange > field ctrl-a doesn't work and you have to back-up. Well the idea was to use it for remembering a station you can not work at the moment or to have a second op scanning the bands. That happens normally while you are in the call input field. What do you use Ctrl-a for when you are in in the exchange field? May be I missed something. I am working on the other reports in next days and will have a new preview before CQWW CWW. 73, de Tom DL1JBE -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Missing cursor
Hi Ben, thanks for the report. The cursor problem should be fixed in meantime in one of the last commits at github. I think there will be a new pre releas ein next days. But you can check the github repo in meantime. Tom DL1JBE. Am Wed, 09 Nov 2011 16:03:14 -0500 schrieb Ben Coleman NJ8J : > One more thing - I noted the missing cursor when trying to use the > left and right arrow keys to make corrections (really annoying when > trying to fix the exchange - and responsible for my tendency to put > the serial last - if I have trouble getting someone to come back to > me, I can fill in the prec check and section while listening to him > making other QSOs, then put the serial last where it is easily > corrected with the backspace key when I finally make the QSO). If > the left and right arrow keys are used for making corrections, the > cursor needs to continue showing so we know where we are in the field. > > Ben -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] One more thing
Am Wed, 09 Nov 2011 16:30:36 -0500 schrieb Ben Coleman NJ8J : > (I'm trying to resist donning a Columbo suit) Do not hesitate to do so :-). > > The score window covers over what seems to be a window showing the > remaining Sections (multipliers). One of them needs to be moved. > Right. Fixed in commit c2a31e25 at github.com. There still seems to be a problem in recognition of the ARRL sections. The display should only display the still needed sections but show all atm. Goes top the todo list. 73, de Tom DL1JBE -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Problems noted during Sweepstakes
Hi Ben, Am Wed, 09 Nov 2011 15:56:36 -0500 schrieb Ben Coleman NJ8J : > :rescore seems to have some problems. At one point, I had 100 QSOs > on 80, but noticed after doing a couple of :rescores that it was > showing 98 or 97 (doing another :rescore might change it). I exited > tlf and re-entered, and the 80 meter count was back to 100, so this > doesn't appear to be a loss of QSOs, just that :rescore is missing > some QSOs that aren't missed when tlf is started up. Would be helpful to have your log file and the logcfg.dat for inspection. > > Be nice if we can get fixes before SS Phone. I'll see if I can get > time to look at the code. > I will try, but time is very limited atm. 73, Tom -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Problems noted during Sweepstakes
Hi Ben, thanks for the report for the SS behaviour. Am Wed, 09 Nov 2011 15:56:36 -0500 schrieb Ben Coleman NJ8J : > The Sweepstakes input parsing has some problems. I consistently > noted that a precedence of U would get dropped if the fields were not > entered in order (I often found myself entering in the order Prec > Check Section Serial, as I would fill in Prec Check Section while > listening to QSOs before I was answered, then fill in the serial when > I finally got the QSO). Precs A and B wouldn't be dropped, prec U > was. I suspect the prec code was incompletely updated when U was > added. I just looked into it. You are right. Prec U is not correctly handled. > > I also had a couple or three QSOs where the serial and prec got > dropped. I'm not yet sure what lead to this. I had a look into the code. The automatic recognition rules are not waterproof. Especially Serial and check can be missinterpreted if not entered in a speial order. I would suggest to make that non-ambiguous by the following rules: - Precedent has exactly one letter - Section is any combination of 2 or three letters - Check has always two digits (04 for 2004) - Serial has at least three digits (QSO nr. 1 has to be entered as 001) - precedent and section has to be separated by check or serial or a blank - similar goes for check and serial That would make definite rules for interpreting and allows nearly any order and an use of any number of blanks (>=0) between them: 74B024CT = 024B 74 CT = B 74 CT 024 = ... What do you think? 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Problems noted during Sweepstakes
Hi Ben and others, I did some more work on the Sweepstake exchange handling. I fixed display and some possible segfaults (if you enter a 5 digit serial e.g.) (See repo). Again (as in TLF-0.9.xx series) you will find the recognized Sweepstake input in the lower line of the section check window. Check that all is there before logging the qso. Am Wed, 09 Nov 2011 15:56:36 -0500 schrieb Ben Coleman NJ8J : > The Sweepstakes input parsing has some problems. I consistently > noted that a precedence of U would get dropped Fixed. > if the fields were not > entered in order (I often found myself entering in the order Prec > Check Section Serial, as I would fill in Prec Check Section while > listening to QSOs before I was answered, then fill in the serial when > I finally got the QSO). Normal input is serial, precedent, check and section (try a space after the section if it is not recognized). > :rescore seems to have some problems. At one point, I had 100 QSOs > on 80, but noticed after doing a couple of :rescores that it was > showing 98 or 97 (doing another :rescore might change it). I exited > tlf and re-entered, and the 80 meter count was back to 100, so this > doesn't appear to be a loss of QSOs, just that :rescore is missing > some QSOs that aren't missed when tlf is started up. I hope it got fixed, but could not reproduce your problem. I will see to fix the Voicekeyer problem (amixer call) tomorrow and then do a new prerelease before SS this weekend. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Problems noted during Sweepstakes
Just forgot something! Am Wed, 09 Nov 2011 15:56:36 -0500 schrieb Ben Coleman NJ8J : > I often found myself entering in the order Prec Check Section Serial That can be done, but you have to enter serial with at least 3 digits in that case. 73, Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] New TLF prerelease tlf-1.1pre3
A new prerelease version of TLF is available at:
http://www.staff.hs-mittweida.de/~tb/tlf-1.1pre3.tar.gz
It mainly fixes some problems from last release:
In detail the following changes were made:
- lot of minor bug fixes (see commit logs)
- '+' and 'INS' key respect CTCOMPATIBLE mode now
- fixed keywords for CQ_TU_MSG, VKCQM and VKSPM
according to manual !Fix your contest rules!
- fix cursor problems with the new search and score window positions
- Ctrl-A (add to bandmap) works also in exchange field now
- lot of fixes for ARRL-SS contests ('U' precedent, segfaults, display
problems, ..)
- add forgotten 'contest' rule file and 'usa_canada_states' to
installed files
- use an external, user adaptable, script file for SSB playing
voice key files (see comments in 'play_vk' in /usr/bin
or /usr/local/bin).
Further bug fixes will have to wait as I am on vacation the next two
weeks.
73, de Tom DL1JBE
--
"Do what is needful!"
Ursula LeGuin: Earthsea
--
___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF in CQWW CW
Hi Martin, Am Fri, 02 Dec 2011 10:39:35 +0100 schrieb Martin Kratoska : > Tested tlf-1.1pre3. Made 822 Q's and ~600 k pts. tlf is finally a > mature program! Congrats. I am glad that there were no major problems with tlf in cqww. As I asked for some big contest logs for performance tests before maybe you can send me a copy of your log. Should be a good staarting point. > Only small bug found, if the cty.dat file contains a > call, like > > Martinique: 08: 11: NA: 14.70:61.03: 4.0: > FM: FM,TO3GA,TO5A,TO7A; > > then the TO7A (as well as TO3A and TO3GA) is not properly resolved > when jumping to this call from a spot. When typed manually, all went > OK. I will have to look into it. > Also noticed that some keys (backspace) do not behave as expected in > the exchange field. Editing the exchange field was never implemented. I just saw it in last weeks but got no time to fix it yet. It is on the todo list. > Also very > annoying is the fact that the score/count info became broken if > editing the log in an external editor. Not checked if the log file > contains some unprintable characters, also don't know if there is > something like time stamp causing the broken score info... Which editor do you use? > I find extremely useful the new spot filtering option. It seems that > the documentation should be updated including info how to preset the > filtering options in logcfg.dat. At the moment that feature is still missing. But it is one thing I want to do before a final TLF-1.1.0 will be released. > Anyway I was able to make 6 QSO > within a minute without any unnecessary hurry :-) Great :-). 73, de Tom DL1jbe -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF in CQWW CW
Hi Graham, Am Fri, 2 Dec 2011 09:43:00 -0500 schrieb "Collins, Graham" : > I too used tlf-1.1pre3 in the just past CQWW-CW. I did leave my > building, setting up and initial test til the last minute but > everything worked out just fine. Very goo to hear :-). That is as it should be. > I had no issues and the application works well with my operating > style. My only issue is that the program thinks I am in zone 5 when > in fact I am in zone 4. I couldn't remember how to fix it properly at > the time so I just edit my exchange to be correct and carried. > I will try to look into that and document it somewhere. > Still on my want list is to change the V2 Cabrillo header output to > V3 and logging of actually frequency. Right. That is on my todo list the next big point. > I have identified where I need to make changes for the Cabrillo V2 vs > V3 but I just haven't gotten around to making the changes. > Can you send me the list of changes off list and I will incorporate it into the code. > As to logging actual frequency, it is becoming more of a requirement > from a number of contest sponsors to log actual frequency rather > just band. The main hurdle to do so is the momentarily log file format which has no place to record the frequency. As sending logs in cabrillo format is more common now than the old trlog format I think we can work araound that. I will append the actual frequency from the rig to the end of the logline (will be longer than 80 characters then) and use that in cabrillo output whenever it is available. A simple script should also be able to convert the log back to trlog format then. > Documentation is lagging behind. A good PDF document would be my > choice. Perhaps I can help out in some way. Indeed documentation is a very urgent problem. If you want to contribute you are very welcome. I have thoughed a bit about the problem before and I think we need a good PDF document but also a man page and some web pages. Looking around I found the asciidoc format which would us allow to write one piece of document and easily convert it to pdf or web pages. I did some experiments to prepare a new web site for tlf using asciidoc. Have a look at tlf.github.com/index2.html. In the moment that is just a starting point but we can extend it as we like. You can look for the code of the above mentioned web pages at github.com/Tlf/tlf.github.com. 73 for now, de Tom DL1JBE. > > Cheers, Graham ve3gtc > > -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF in CQWW CW
Hi Andy,
I know some of your comments regarding the bandmap are still
unanswered. Sorry, was a busy time here. So let me try to answer here
and continue the discussion.
Am Wed, 7 Dec 2011 13:24:43 + schrieb
Andy Summers :
> On the new bandmap, I notice that ctrl-g grabs all calls, including
> those you've worked.
It grabs any call which is displayed. If you filter your display by
band, mode or filter out the dupes ctrl-g grabs only the next
*displayed* station up from your working frequency (as documented in
Newbandmap.txt).
> If your S&P rate is high enough you can get into
> a situation where a lot of ctrl-g presses are required to get to the
> spot you're after. I didn't use the Cluster, BTW.
>
> On the one hand, it's useful to have worked calls in the bandmap so
> you know who you've just tuned through and don't wait to listen for
> the call. On the other hand, they get in the way of quickly grabbing
> spots.
Well, it should be simple enough to not select any dupe and skip it
over. Let me experiment.
One feature not documented in the original post is to selectively call
a special spot. Type in some characters of the call you want and press
Alt-g (make sure it works in your terminal) and TLF will grab the first
spot with that characters in the call. Be aware that it will grab the
first spot which matches.
> Traversing the bandmap spots is still inconsistent for me, as I
> explained earlier.
>
I beleive you are speaking about that sentence:
> I think I've figured out what's happening. If you tune the rig just
> below the frequency of a spot then hit ctrl-g it grabs that spot.
> Hitting ctrl-g again without retuning the rig just picks the same
> spot.
> Tune the rig HF a little and then when you hit ctrl-g it goes to the
> next spot. So I imagine you have some logic in there something like:
> for (i = 0, i < noOfSpots) {
> if (currentFreq <= SpotFreq(i)) {
> goto(SpotFreq(i));
>}
>}
No. It is a
if (spotfreq > currentfreq) {
goto spotfrequ;
}
in the case of searching upwards. It also works very stable and well
here.
Maybe let us ask which rig you use? What is the frequency resolution
if you set a frequency and if you read the frequency back from it.
Normally it gets recorded down to 1 Hz resolution. The spots from
cluster are in 100 Hz steps and your own recorded spots (ctrl-a) are as
precise as your rig can report. Maybe there is some discrepancy between
setting frequency and aksing it back.
73, Tom DL1JBE
--
"Do what is needful!"
Ursula LeGuin: Earthsea
--
___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF in CQWW CW
Hi all,
thanks for the feedback and the good ideas.
Here is my plan for the next steps:
1. make bandmap configurable in logcfg.dat
- filtering by band, mode and dupes
- livetime
2. skip dupes while grab ctrl-g (maybe configurable in logcfg.dat)
3. solve andys problems if possible
Following these changes I will make a release 1.1.0
Next steps after that will be fixes for cabrillo and exact frequency in
cabrillo and adif files.
The rest of the good ideas are collected and will be introduced step by
step afterwards.
I think I will be able to do most of the above until the end of year.
73, de Tom DL1JBE.
Am Thu, 08 Dec 2011 09:12:12 +
schrieb FS :
> Hi all,
>
> i dont have Andys Problem as well because i always filter dupes out,
> so that CTRL-G jumps to the next unworked station. Some more things
> that could be interesting regarding bandmap might be (as proposed in
> the sources):
> - have the filter conditions in the logcfg.dat (band, mode, dupes +
> maybe max. life time of spots)
> - sort the spots around the actual working frequency (maybe in
> intervalls to reduce load?)
> - sort for mults (at least for the contests where this info can be
> seen from the call like wwdx or wpx)
>
> 73 Fred
>
>
> On 12/08/2011 06:35 AM, Thomas Beierlein wrote:
> > Hi Andy,
> >
> > I know some of your comments regarding the bandmap are still
> > unanswered. Sorry, was a busy time here. So let me try to answer
> > here and continue the discussion.
> >
> > Am Wed, 7 Dec 2011 13:24:43 + schrieb
> > Andy Summers:
> >> On the new bandmap, I notice that ctrl-g grabs all calls, including
> >> those you've worked.
> >
> > It grabs any call which is displayed. If you filter your display by
> > band, mode or filter out the dupes ctrl-g grabs only the next
> > *displayed* station up from your working frequency (as documented in
> > Newbandmap.txt).
> >
> >> If your S&P rate is high enough you can get into
> >> a situation where a lot of ctrl-g presses are required to get to
> >> the spot you're after. I didn't use the Cluster, BTW.
> >>
> >> On the one hand, it's useful to have worked calls in the bandmap so
> >> you know who you've just tuned through and don't wait to listen for
> >> the call. On the other hand, they get in the way of quickly
> >> grabbing spots.
> >
> > Well, it should be simple enough to not select any dupe and skip it
> > over. Let me experiment.
> >
> > One feature not documented in the original post is to selectively
> > call a special spot. Type in some characters of the call you want
> > and press Alt-g (make sure it works in your terminal) and TLF will
> > grab the first spot with that characters in the call. Be aware that
> > it will grab the first spot which matches.
> >
> >> Traversing the bandmap spots is still inconsistent for me, as I
> >> explained earlier.
> >>
> >
> >
> > I beleive you are speaking about that sentence:
> >
> >> I think I've figured out what's happening. If you tune the rig just
> >> below the frequency of a spot then hit ctrl-g it grabs that spot.
> >> Hitting ctrl-g again without retuning the rig just picks the same
> >> spot.
> >> Tune the rig HF a little and then when you hit ctrl-g it goes to
> >> the next spot. So I imagine you have some logic in there something
> >> like:
> >
> >> for (i = 0, i< noOfSpots) {
> >> if (currentFreq<= SpotFreq(i)) {
> >>goto(SpotFreq(i));
> >> }
> >> }
> >
> > No. It is a
> >
> > if (spotfreq> currentfreq) {
> > goto spotfrequ;
> > }
> >
> > in the case of searching upwards. It also works very stable and well
> > here.
> >
> > Maybe let us ask which rig you use? What is the frequency resolution
> > if you set a frequency and if you read the frequency back from it.
> > Normally it gets recorded down to 1 Hz resolution. The spots from
> > cluster are in 100 Hz steps and your own recorded spots (ctrl-a)
> > are as precise as your rig can report. Maybe there is some
> > discrepancy between setting frequency and aksing it back.
> >
> >
> > 73, Tom DL1JBE
> >
> >
> >
> >
> >
>
> ___
> Tlf-devel mailing list
> Tlf-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tlf-devel
--
"Do what is needful!"
Ursula LeGuin: Earthsea
--
___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Can't get tlf going / Stew Perry
Am Mon, 12 Dec 2011 06:46:29 -0500 schrieb "Collins, Graham" : > > Or, if you didn't want to log into or use the cluster you could start > TLF using the -n switch i.e. $tlf -n Second way to work without cluster connection is to comment out all keywords like 'TELNETHOST', 'TELNETPORT', the whole TNC family and 'FIFO_INTERFACE'. TLF will start without trying to connect to a cluster. 73, de Tom DL1JBE > > That is what I do as I don't use the cluster and operate in contest > un-assisted. > > Cheers, Graham ve3gtc > > > -Original Message- > From: tlf-devel-bounces+colling=navcanada...@nongnu.org > [mailto:tlf-devel-bounces+colling=navcanada...@nongnu.org] On Behalf > Of FS Sent: December 12, 2011 05:02 To: tlf-devel@nongnu.org > Subject: Re: [Tlf-devel] Can't get tlf going / Stew Perry > > Hi Lenny, > > put in your callsign at CLUSTERLOGIN='...' and you will login > automatically. Or press ':' to see tlf screen. > > Pat asked for Stew Perry, TLF cant score it but you can log > it using the WYSIWYG Mult feature. > > 73 Fred > > On 12/11/2011 04:44 PM, len...@comcast.net wrote: > > Hello Rein, > > > > I can't get tlf going. When I run it, instead of the logger screen > > I get a logon request for a telnet cluster. I have my directory > > structure set up similar to what you show with the logcfg.dat in > > the same directory from which I run tlf. I have attached the > > logcfg.dat and also the text tlf generated when I launched it with > > tlf -v. I did tlf -v >./startlog. It is a text file with some > > unreadable character in it. > > > > Maybe you could use these to help me figure out what I'm dong wrong? > > Probably something simple? > > > > Thanks in advance for any help you can give. > > > > 73, > > Lenny W2BVH > > > > > > > > > > ___ > > Tlf-devel mailing list > > Tlf-devel@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/tlf-devel > > ___ > Tlf-devel mailing list > Tlf-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tlf-devel > > ___ > Tlf-devel mailing list > Tlf-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tlf-devel -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF in CQWW CW
Hi Andy,
thanks for the reply.
Am Tue, 13 Dec 2011 22:31:26 +
schrieb Andy Summers :
> Hi Tom,
>
> Sorry for the delay in replying. I chose to upgrade the OS to Fedora
> 16_64-bit and it took me a while to get back to a useful PC - hi!
>
The joy of new systems :-)
> Regarding ctrl-g and the bandmap, I'm using an Orion and
> hamlib-1.2.14-1. Using the hamlib rigctl utility, frequency is
> reported correctly to 1Hz resolution, so certainly that isn't to
> blame. Normally I set the Orion to step in 10Hz steps.
OK. Do we have anyone on list with another Orion to confirm the tests?
> Here's my test:
> Enter G4ABC, hit ctrl-a, is displayed in bandmap to 100Hz resolution.
> Move hf a little, enter G4DEF, hit ctrl-a again.
> Move hf a little, enter G4GHI, hit ctrl-a again.
> Move hf a little, enter G4JKL, hit ctrl-a again.
>
I assume you moved frequency up each time?
>
> So it is definitely getting confused about whether it should be
> moving up or down the band in some situations, e.g. at the limits of
> the stack, when it should turn around.. You ought to be able to
> repeat this test. Let me know.
Sorry. Works like a charme here.
I will prepare a special tlf version which will log your frequency
settings and grabs in next days. You can run it and send me the log
afterwards. Maybe I will understand whats happening.
I just have to think, what I should record to get a good look into it.
> Thinking about bandmaps a bit more... Ideally, I'd like to know if
> some loud station I'm tuning through is a dupe who's been running on
> that frequency for some time. I don't want to wait to hear them give
> their call (especially those who perpetually QRZ?), and I can't
> remember a whole band in my head. On that basis it would be useful to
> see dupes in the bandmap, but it gets in the way of quickly grabbing
> spots. In N1MM logger (and similar), the call in the bandmap is
> automatically put into the exchange field when the rig frequency is
> within a (configurable) tolerance of the spot frequency. Such a
> feature would allow you to set bandmap filtering to exclude dupes and
> yet still give an indication that you're currently tuning through a
> probable dupe.
>
That will go to the 'ideas from others' section for now :-).
73, Tom DL1JBE.
> Keep up the good work!
> 73 Andy, G4KNO
>
> On 12/08/2011 06:35 AM, Thomas Beierlein wrote:
> > Hi Andy,
> >
> > I know some of your comments regarding the bandmap are still
> > unanswered. Sorry, was a busy time here. So let me try to answer
> > here and continue the discussion.
> >
> > Am Wed, 7 Dec 2011 13:24:43 + schrieb
> > Andy Summers:
> >> On the new bandmap, I notice that ctrl-g grabs all calls, including
> >> those you've worked.
> > It grabs any call which is displayed. If you filter your display by
> > band, mode or filter out the dupes ctrl-g grabs only the next
> > *displayed* station up from your working frequency (as documented in
> > Newbandmap.txt).
> >
> >> If your S&P rate is high enough you can get into
> >> a situation where a lot of ctrl-g presses are required to get to
> >> the spot you're after. I didn't use the Cluster, BTW.
> >>
> >> On the one hand, it's useful to have worked calls in the bandmap so
> >> you know who you've just tuned through and don't wait to listen for
> >> the call. On the other hand, they get in the way of quickly
> >> grabbing spots.
> > Well, it should be simple enough to not select any dupe and skip it
> > over. Let me experiment.
> >
> > One feature not documented in the original post is to selectively
> > call a special spot. Type in some characters of the call you want
> > and press Alt-g (make sure it works in your terminal) and TLF will
> > grab the first spot with that characters in the call. Be aware that
> > it will grab the first spot which matches.
> >
> >> Traversing the bandmap spots is still inconsistent for me, as I
> >> explained earlier.
> >>
> >
> > I beleive you are speaking about that sentence:
> >
> >> I think I've figured out what's happening. If you tune the rig just
> >> below the frequency of a spot then hit ctrl-g it grabs that spot.
> >> Hitting ctrl-g again without retuning the rig just picks the same
> >> spot.
> >> Tune the rig HF a little and then when you hit ctrl-g it goes to
> >> the next spot. So I imagine you have some logic in there something
> >> like: for (i = 0, i< noOfSpots) {
> >> if (currentFreq<= SpotFreq(i)) {
Re: [Tlf-devel] Launch tlf and nothing but packet cluster
Hi Lenny, Am Sun, 18 Dec 2011 12:59:38 -0500 schrieb Lenny Wintfeld : > Loaded tlf 0.9.32.3-6 with synaptic package manager in ubuntu 10.04 > LTS. Tried running it from /my home dir/tlf/contests/arrldx. With > what I think is a good logcfg.dat. I launched rxvt from the gnome > terminal and ran tlf in the rxvt window. All I get is a logon to the > packet cluster ( 131.155.152.179) mentioned in the .dat file. No tlf > at all. Typing : doesn't help. Did you hit Enter after the ':'? Should bring you to tlf's main screen. As an alternativ try to run 'tlf -n'. That drop the packet connection but bring you direct to the main screen. Btw, you are running a very old version of tlf here. We are just before releasing tlf-1.1.0. Latest packaged pre release is at http://www.staff.hs-mittweida.de/~tb/tlf-1.1pre3.tar.gz 73, de Tom DL1JBE. > > How do you get tlf to run? > > TIA > > 73, > Lenny W2BVH -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] TLF-1.1.0 release announcement
Just before the holidays let me announce a new major TLF-1.1.0 release. As before it is available at: http://www.staff.hs-mittweida.de/~tb/tlf-1.1.0.tar.gz There was done a lot of work in the last year sincce TLF-1.0.0. Thanks for all the bug reports, comments and ideas I got from you all. The NEWS file summarises the major additions, changes and fixes done so far (see below). You can look up in more detail by reading the changelog and the git log messages itself. >From the NEWS file: tlf-1.1.0 = Major release. Besides a lot of fixed bugs it provides some new features and internal improvements. Thanks to all of you for pointing out bugs, submitting ideas and testing. To name some without any order of ranks: Ben NJ8J, Martin OK1RR, Fred DM3MF,i Andy G4KNO, Rob N6ROB and Graham VE3GTC. New features: - move tlf sources to public github repository (http://github.com/TLF/tlf) - implement a new bandmap function (see doc/New_Bandmap.txt for details) * move score display in upper right corner of display to make room for the bandmap * Ctrl-A adds an observed station as spot to the bandmap and broadcasts it to other stations in the LAN * Drop old SPOTLIST display (superseded by new bandmap) - changes in logcfg.dat handling !Fix your contest rules! * allow >9 points for any point scoring * drop old unneeded keywords (MANY_CALLS, SPOTLIST, FILTER) * fixed keywords for CQ_TU_MSG, VKCQM and VKSPM according to manual * BANDMAP=, allows configuration of the new bandmap display (see man page) - Send VKCQM and VKSPM voice messages after end of QSO in SSB. - Use external user adaptable script 'play_vk' for playing of SSB voice key messages - add list of 'usa_canada' states and general 'contest' rules file to installation files - drop special handling for TenTec ORION (correctly handled by hamlib in meantime) - changed handling of comments for WYSIWYG_ONCE and WYSIWYG_MULTI Old code stopped multi recognition at first space in comment string. Changed to use whole string but strip trailing spaces. Was so back before tlf-0.9.21 - Better handling of lines from external multiplier file * Allow comment lines (starting with '#') * strip leading and trailing whitespace * drop empty lines - New actual cty.dat file (December 2011). Thanks Martin OK1RR. Fixed bugs: - segfaults due to a racing condition if heavy load on cluster - '+' and 'INSERT' keys in call and exchange input field respects CTCOMPATIBLE mode now - Allow edit of old QSO's only if call field is empty - Fix display of section in ARRL_SS and recognition of 'U' precedent - Fix upper boundaries for 160 and 40 meters. - Correct rescoring for WYSIWYG_* methods - keywords in logcfg.dat needs to start at column 0 - correction of spelling errors and drop of old infos from man page - a lot of fixes of old problems: * proper locking to prevent racing conditions * fix bad scoring of multis * correct position of pfx display in bottom line of check window * correct display of 1A stations in info line * wrong return value from searchcallarray * wrong handling of corner cases for some internal array scans Reworked internal structure: - did some modernisation of configure.ac - start to use ncurses panel functions for overlapping windows and glib-2 for effective handling of large data collections - switch cty data handling and mults_possible to growing arrays and therefore allowing unlimited number of entries - simplify and drop unneeded code Enjoy using TLF and its new features and keep me informed about bugs, success stories and suggestions for new features. Merry Christmas es gd DX. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.1.0 release announcement
Hi Andy, a happy new year and much success in all your doing. Am Mon, 02 Jan 2012 20:04:35 + schrieb Andy Summers : > I haven't tried out TLF in SSB mode for a while, but now have. The > play_vk shell script works OK, but the last line needs "un mute" to > be one word: "unmute", or it doesn't work. > Tnx for the bug report. Fixed in the repo tree now. > An FYI, for others: I also had to uninstall "alsa-plugins-pulseaudio" > (Fedora16_64), or otherwise there's a long delay bewteen the end of > a message and PTT dropping back. This has always been the case with > pulseaudio, but I was reminded of it again on my newly installed OS. > Very well. What do you think about a short README.ssb how to configure TLF for SSB mode operation and what do take care for. As I do nearly only CW it is a little bit difficult for me to write :-). I would add it to the distro and also to our new web site. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.1.0 release announcement
Hi Andy, thanks for the feedback. Am Tue, 10 Jan 2012 20:57:46 + schrieb Andy Summers : a) > On a couple of occasions I was in the exchange field having just > copied the received exchange. I accidentally hit F2 (sent exchange) > instead of F1 (CQ) at that point. In panic, I hit to terminate > sending CW, but it keeps going. I hit again and it stops. I > look back at the display and find that I've now lost the exchange I > just copied! I call that station again, but he's already QSY'd. I > can't remember the exchange and I've now got a busted QSO! > The problem comes from using 'cwdaemon' as keyer. If you press ESC (please do it only once) it sends cwdaemon a stop command. But it takes some time before cwdaemon reacts. Btw, which version of cwdaemon do you use. Iirc there was some work to make it react more quickly to a stop request lately. b) > When you're in the exchange field there's no editor function like > there is in the call field. If I didn't get the first digit in a 3 > digit serial I don't want to have to delete the two digits I did copy > to get to the first digit position. TLF can also be used in > non-serial contests, and proper editing functions are really > necessary in this instance. Editing the exchnage field is already on the todo list :-). c) > When you're editing a call (you've arrowed left and changed > something) and you then hit , the partials window background > goes black. Only a cosmetic issue, but it doesn't look good. > Same here. I know the bug, but did not find time to fix yet. > Didn't the score window previously give the number of QSO's and > dupes? I know I worked some dupes but they don't appear. Never seen the number of dupes in the scorewindow. Sorry. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] TLF-1.1.1 release announcement
A minor TLF bugfix release is available at http://www.staff.hs-mittweida.de/~tb/tlf-1.1.1.tar.gz The main new features and bug fixes are: New features: - New doc/README.ssb gives some good hints how to use TLF on SSB contest. Thansk Andy, G4KNO for contributing. Bug fixes: - Fix spelling of unmute command in scripts/play_vk. Tnx G4KNO - Make sure that no packet related functions get called if started with 'tlf -n' - Fix segfault during build of logline if not in contest mode - esp. 'RULES=qso'.THanks for reporting Fred, DH5FS. - Fix display of background for partials when leaving call edit mode 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.1.1 release announcement
Hi Graham, Am Sun, 15 Jan 2012 21:47:11 + schrieb Graham : > Thanks Tom. > > copied, installed, built and working OK. > good to hear :-). > I used TLF in this weekends North American QSO Party. TLF does not > export a nice cabrillo format file for this contest. The exchange was > name and state/province or country. TLF truncates received exchange. Well that code is really old and dates back to the first years of using cabrillo format. It supports only the ARRL standard contests. In menatime some other formats of the QSO lines got added to the standard, but not to tlf :-(. > I had intended to dig into the part of TLF which does the cabrillo > format creation but just haven't gotten around to it. So, I wrote a > simple perl script called tlf2cab.pl to convert the TLF log format to > cabrillo. Very well. I think that may be the best way for postprocessing the log file - to use some external programs. They can be written in ohter languages as C and are more easily extensible. > I can share the script with anyone who wants it or we can place on the > tlf archive someplace. That would be very nice. As a first idea - put it on tlf.wikispaces.com. Better yet, send it to me and I will add it as user contributed script to the distribution. > Cabrillo is a standard but version 2 and version 3 are both commonly > used plus it seems as every contest has their variation on exchanges > and how the details need to be put in the cabrillo log file. See http://www.kkn.net/~trey/Cabrillo_v2/qso-template.html for the official supported formats. Other ones may be also around. > I am very comfortable working in a terminal with command lines and > scripts. I see the task of exporting the tlf log into cabrillo as a > job for a script. Others are not so comfortable and like the ability > built into the application. If needed we could make tlf's ':wri' command to call that external script. That would drop the command line barrier for others. > For now I will use and update my script but will also give some more > thought to what is needed in tlf to do the same thing. > You can find the code for writing the header in src/getsummary.c. The real code for writing the QSO lines are in src/writecabrillo.c. It is not written nice and I am working a little bit on it. Any help and suggestions for improvements are welcome. 73 for now, Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] ARRL Mult files
Hi Fred, thanks for your contribution. You are rigth the 'usa_canada_states' file is dated, but your file seems wrong too. I just checked the official ARRL_DX website http://www.arrl.org/arrl-dx and especially for the VE provinces there are some differences (namely NWT, NF and PEI). Can you clarify again and give feed back. I would like to add the actual (but correct) files to the next release. Btw, the same goes for the ARRL-10m file. 73, de Tom DL1JBE. Am Mon, 20 Feb 2012 14:45:40 + schrieb FS : > As some may have noticed, the file "usa_canada_states" isnt up to date > for the use with the ARRL contests. Please find attached the actual > files for ARRL-DX and ARRL-10m contests. > > 73 Fred -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] ARRL Mult files
Well, I see Very wierd. Thanks anyway. I will add the files to the next TLF release. 73, de Tom DL1JBE. Am Mon, 27 Feb 2012 19:28:32 +0100 schrieb Fred Siegmund : > Ups, interesting enough the rules are different here: > http://www.arrl.org/10-meter > Now the files are according to the website. > > GL next weekend in the ARRL SSB ...I will be on VHF/UHF :-) > > 73 Fred > > Am 27.02.2012 17:55, schrieb Thomas Beierlein: > > Hi Fred, > > > > thanks for your contribution. > > > > You are rigth the 'usa_canada_states' file is dated, but your file > > seems wrong too. > > > > I just checked the official ARRL_DX website > > http://www.arrl.org/arrl-dx and especially for the VE provinces > > there are some differences (namely NWT, NF and PEI). Can you > > clarify again and give feed back. I would like to add the actual > > (but correct) files to the next release. > > > > Btw, the same goes for the ARRL-10m file. > > > > 73, de Tom DL1JBE. > > > > > > Am Mon, 20 Feb 2012 14:45:40 + > > schrieb FS: > > > >> As some may have noticed, the file "usa_canada_states" isnt up to > >> date for the use with the ARRL contests. Please find attached the > >> actual files for ARRL-DX and ARRL-10m contests. > >> > >> 73 Fred > > > > -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] noob question- tlf sound files
Hi Jim, Am Sun, 04 Mar 2012 15:42:14 -0500 (EST) schrieb Jim Bruce : > I upgraded to 1.1.1 so I now have to find out why hamlib isn't > talking to the radio anymore. As first step try that your computer works with hamlib alone. You can use hamlibs 'rigctl' program for that. Second step: Make sure your rig settings (model and baudrate) in logcfg.dat are correct. > It was installed with the enable hamlib > cmd during the ./configure in the instructions. Are all upgrades to > programs that need compiling done this way or is there an upgrade > switch? It is the normal way if you install a program from source. As TLF works on more than linux we can not provide a precompiled image. That is normaly done by the distributions who can specialize for a certain operating system and/or processor family. > I thought I had deleted the tlf directory in /usr/share prior to the > upgrade and the files I was changing there for rules were not > following the changes. I also found a tlf directory > in /usr/local/share where the changes are seen in the program. Has > the install directory changed with 1.1.1 and can the /usr/share/tlf > be deleted? > If you compile an application yourself most build systems place the resulting files automatically in /usr/local/(bin,share). The one coming from your distribution (1.1.0) was installed in /usr/(bin,share) before. You can change the behaviour of your build by an additional switch to ./configure: './configure --enable-hamlib --prefix=/usr' would install the files in the old location, overriding the original files. Be sure to backup any modifications you have made. If you stay with the new /usr/local version you have to delete at least the original /usr/bin/tlf as it comes first in search order if you call the program. Best would be to deinstall the old version with your package manager. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] TLF-1.1.2 release announcement
A minor TLF bugfix release is available at https://github.com/downloads/Tlf/tlf/tlf-1.1.2.tar.gz As it was a busy time here it contains only some minor changes and bug fixes: New features: - Add ARRL 10m Contest rules for DX stations. - Provide more actual multiplier files for arrldx and arrl10m contests. - Add a better recognition of unkown keywords in config file. Bug fixes: - Fix recognition of COUNTRY_LIST keyword. - Fix a segfault problem in exchange handling. Some further information about what is going on here: - I am working on a editable exchange field (similar to call input). - There is some work in progress to enable an early stop of SSB voice keying. - I did some first work to prepare a new web site for TLF, but some points are missing before it should go on line. Please have a look at http:/tlf.github.com/index2.html and give some feedback. If you have suggestions and additions please let me know. Best send some lines of text (maybe unformatted) and I will add it there. Further I would like to rework Reins old help page (see bottom of the web page for a link) in simple asciidoc format. Any help would be greatly appreciated. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Issues while trying to build a Nevada QSO Party rules file
Hi Ben, just let me try to give some hints. Am Mon, 07 May 2012 01:11:35 -0400 schrieb Ben Coleman NJ8J : > Recently, I sat down to start putting together a rules file for the > upcoming Nevada QSO party. I plan to play in a number of QSO Parties > this year(plus things like NAQP), and I had figured on putting > together rules files for them and contributing them back so they > could be included in the TLF package. Do you have a link for the rules? > As I'm sure you're not surprised, some parts of the rules for this > particular contest don't quite fit tlf's rules set up. I'm hoping > that if I point out where the problems are for this, and for other > contests I try to make rules for later, it might point to some bug > fixes and wish list items for future tlf development. I hope to help > make tlf rules flexible enough to handle most any contests, and then > the users can contribute rules sets for contests. > Well, TLF's rule set grow over the time as Rein added contest by contest and also some additional addons. But we still miss a universal rule set which allows us to handle nearly every contest. Martin OK1RR promised last year to come up with some suggestions but I fear he did not find time to do so. > Some of these things might be my misunderstandings. I haven't so far > been able to find documentation on the rules file. If it's out > there, but I've missed it, please point me to it. If it's not, this > seems to me to be a good addition to the TODO list. > As you found in meantime some of the documentation is in the old web page for the 0.9.9 version. But it is dated and not very accurate. Much more actual is the man page and the documentation of the different config and rule parameters disceussed there. I would suggest to use both in combination. > Things I've run into with NVQP: > > 1. I've set up a multiplier file of Nevada counties, used MULT_LIST > and SECTION_MULT. Problem is that when using SECTION_MULT, tlf seems > to assume that multipliers count per band, except for the hard-coded > exception of ARRL Sweepstakes, and NVQP doesn't count multipliers per > band. We need a SECTION_MULT equivalent of WYSIWYG_ONCE. I will look into the code to see if it is possible in next days. > > 2. This is a MIXED contest, and qso points are different for phone > vs CW/Digital (2 for phone, 3, for CW/Digital). Tlf doesn't handle > that. > Did you try to assign 'CWPOINTS=...' and 'SSBPOINTS=...'? Let me know how it goes, maybe add your actual rule file. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] TLF-1.2.0 prerelease 1
Let me announce a first prerelease of the new TLF-1.2.0 version. You can find it at https://github.com/downloads/Tlf/tlf/tlf-1.2.0_pre1.tar.gz Main new features of TLF-1.2 series will be * recording of the worked QRG in the log file and exporting it to ADIF and Cabrillo file and * Fix of the cabrillo file generation problems The first part of that is done and available in these prerelease. The cabrillo problems needs still to be fixed before 1.2.0 release. Please give it a thorough test and report any problems back to the list. !!WARNING!! The new version contains code to migrate your old log files to the new format. But be careful and make backups before using the new version with that files. Some more details about what gots done from the NEWS file: New features: - change log file format to make room for recording of actual working frequency (columns 0..79 - old TR-log format, QRG gets added with one decimal after that) - Better check of log file format on startup. Can migrate old logs to new format. - Record actual working QRG in log if a rig is connected - Write QRG into ADIF and Cabrillo export files - Renamed ADIF and Cabrillo files to .adi and .cbr as suggested by Martin OK1RR - Check for size of Terminal (at least 25x80 is needed). Furthermore a lot of cleanup and internal changes are made to simplify future maintenance, e.g.: - A new scheme for color initialisation and naming - Cleanup of unused variables and comments. - Fix configure-script to abort if no ncurses lib is installed. To be done: - Fix generation of cabrillo files (still broken in this prerelease) - Document log file format - make exchange field editable Be aware, that I will be away for most of this month and will be back in start of august. 73, de Tom DL1JBE -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] K3 and tlf - resets bw when changing bands
Hi Olaf, Am Sat, 11 Aug 2012 08:55:05 +0200 schrieb Olaf Devik : > My K3 combined with tlf/hamlib reads frequency/mode nicely both into > cqrlog and to tlf and if necessary simultaneously by use of rigctld > daemon. Some hassle to set up as I had to compile hamlib from source, > the standard install were not found by tlf unless hamlib was compiled. > > My question is as follows, why do the K3 return to a wide bandwidth > every time I change bands or turn the vfo outside the bandlimits - > this only happens when the k3 is communicating with tlf. There seems > to some builtin logic that overrides the bw and resets the bw to > approx 1000 hz every time I change band. Is there some logic built > into tlf or is this a hamlib issue? > That is done by tlf intentional. Every time you change band it reset the bandwidth to the 'default' value, which is coded inside hamlib (Seems for your K3 that default is set to 1000 Hz). You can overide the default bandwidth setting with 'CWBANDWIDTH=xxx' in logcfg.dat where xxx is one of the supported bandwidth settings of your K3. Wrt to the need to self compile hamlib: Which operating system and hamlib version did you try before? Did you install also the development headers (hamlib-dev packacke or similar) before? Some Linux systems split the headers out from the library package. It would be good if you can try building tlf again without the self compiled hamlib and send me the output of the ./configure command. 73, Tom DL1JBE -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] K3 and tlf - resets bw when changing bands
Am Sat, 11 Aug 2012 20:54:04 +0200
schrieb "Olaf Devik" :
> As to operating system story is as follows:
>
> 1 Had kubuntu 10.10 working with tlf all ok.
> 2 Updated to kubuntu 12.04 after a number of network connection
> issues. Did a clean new install.
> 3 Installed cqrlog which installs the hamlib package and uses both
> cwdaemon and rigctld. All ok.
Right. As that are binary packages they install only the libraries but
not the header files which are needed for compilation of new programs
using hamlib.
> 4 Downloaded tlf 1.2. Compiling with. /configure --enable-hamlib
> failed. Did not find hamlib. Tried autoconf. Did not help.
That is the result from the missing header files. If you install the
hamlib and hamlib-dev packages from your distribution, it should
configure succesfully.
> 9 Checked cwdaemon with nc -u localhost 6789 rig keying ok. Tlf
> claims cwdaemon ok. But no keying neither from macros nor keyboard.
> Keying from cqrlog not ok. Recheck with nc -u does not function
> anymore. Tlf or cwrlog problem?
No idea yet. Works here like a charme. Do you know the version of
cwdaeon you have installed ('sudo cwdaemon -V')? That problem needs
further attention.
> 10 Function keys in tlf do not work eg F1 gives A in input field.
Normally a problem with the settings of your terminal program. Check
your TERM settings ('echo $TERM') and which function keys are catched
by the terminal program. If unsure, try tlf in pure text mode
(Ctrl-Alt-F6) should switch to one of those).
>
> 73 de LA3RK
>
> Mvh
> Olaf Devik
>
> --- Original message ---
> > From: Thomas Beierlein
> > To: olaf.de...@mollefaret.no
> > Cc: tlf-devel@nongnu.org
> > Sent: 11.8.'12, 20:31
> >
> > Hi Olaf,
> >
> > Am Sat, 11 Aug 2012 08:55:05 +0200
> > schrieb Olaf Devik :
> >
> >> My K3 combined with tlf/hamlib reads frequency/mode nicely both
> >> into cqrlog and to tlf and if necessary simultaneously by use of
> >> rigctld daemon. Some hassle to set up as I had to compile hamlib
> >> from source, the standard install were not found by tlf unless
> >> hamlib was compiled.
> >>
> >> My question is as follows, why do the K3 return to a wide bandwidth
> >> every time I change bands or turn the vfo outside the bandlimits -
> >> this only happens when the k3 is communicating with tlf. There
> >> seems to some builtin logic that overrides the bw and resets the
> >> bw to approx 1000 hz every time I change band. Is there some
> >> logic built into tlf or is this a hamlib issue?
> >>
> > That is done by tlf intentional. Every time you change band it reset
> > the bandwidth to the 'default' value, which is coded inside hamlib
> > (Seems for your K3 that default is set to 1000 Hz).
> >
> > You can overide the default bandwidth setting with
> >
> > 'CWBANDWIDTH=xxx'
> >
> > in logcfg.dat where xxx is one of the supported bandwidth settings
> > of your K3.
> >
> >
> > Wrt to the need to self compile hamlib: Which operating system and
> > hamlib version did you try before? Did you install also the
> > development headers (hamlib-dev packacke or similar) before?
> > Some Linux systems split the headers out from the library package.
> >
> > It would be good if you can try building tlf again without the self
> > compiled hamlib and send me the output of the ./configure command.
> >
> >
> > 73, Tom DL1JBE
> >
> >
--
"Do what is needful!"
Ursula LeGuin: Earthsea
--
___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] K3 and tlf - resets bw when changing bands
Hi Graham, nice to hear that I could solve that problem for you :-). Btw, I got your mail after the 1.20_pre1 announcement. Thanks for the nice words. As I see 16 downloads of 1.2.0_pre1 but no feedback let me ask if it works as expected or if you observe some problems. Is the frequency logging working as expected? Did you try to open (and convert) an older log file with it? 73, Tom DL1JBE Am Sat, 11 Aug 2012 19:14:15 + schrieb Graham : > > Thanks Thomas, > > this was happening to me as well ( FT-950 ) but was only a minor > annoyance so had I not until now done anything about it. I have added > the appropriate line to my config file and all is well. > > cheers, Graham ve3gtc > > > > On 12-08-11 06:31 PM, Thomas Beierlein wrote: > > Hi Olaf, > > > > Am Sat, 11 Aug 2012 08:55:05 +0200 > > schrieb Olaf Devik : > > > >> My K3 combined with tlf/hamlib reads frequency/mode nicely both > >> into cqrlog and to tlf and if necessary simultaneously by use of > >> rigctld daemon. Some hassle to set up as I had to compile hamlib > >> from source, the standard install were not found by tlf unless > >> hamlib was compiled. > >> > >> My question is as follows, why do the K3 return to a wide bandwidth > >> every time I change bands or turn the vfo outside the bandlimits - > >> this only happens when the k3 is communicating with tlf. There > >> seems to some builtin logic that overrides the bw and resets the > >> bw to approx 1000 hz every time I change band. Is there some > >> logic built into tlf or is this a hamlib issue? > >> > > That is done by tlf intentional. Every time you change band it reset > > the bandwidth to the 'default' value, which is coded inside hamlib > > (Seems for your K3 that default is set to 1000 Hz). > > > > You can overide the default bandwidth setting with > > > > 'CWBANDWIDTH=xxx' > > > > in logcfg.dat where xxx is one of the supported bandwidth settings > > of your K3. > > > > > > Wrt to the need to self compile hamlib: Which operating system and > > hamlib version did you try before? Did you install also the > > development headers (hamlib-dev packacke or similar) before? > > Some Linux systems split the headers out from the library package. > > > > It would be good if you can try building tlf again without the self > > compiled hamlib and send me the output of the ./configure command. > > > > > > 73, Tom DL1JBE > > > > > > > ___ > Tlf-devel mailing list > Tlf-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tlf-devel -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Tlf 1.2.0 bugs or missed something?
Hi Martin, Am Tue, 14 Aug 2012 20:25:05 +0200 schrieb Martin Kratoska : > Hi, > > while testing the tlf-1.2.0_pre1 I found following: > > - the telnet cluster autologin does not work. A manual login needed > regardless of the fact that > > CLUSTERLOGIN=OK1RR > thanks for reporting. I got that report already just some hours ago from N1EA. I will look into it. > - while tlf initializing a strange message appears: > > Keyword '' not supported. See man page and README. > > man page and/or README does not mention this. This message appears > when some contest rule files used but when using the cqww rules from > the tarball tlf-1.2.0_pre1.tar.gz this message does not appear. It > seems that this message appears with my old contest rules, mostly > these using initial exchange. This message appears sometimes twice. > Right. There were some changes in the rule syntax back in tlf-1.1.0. Please read the NEWS file or the announcement. You have to adapt your rules. Normally tlf names the not recognized keyword between the ' signs. If you can not find it, please send me your logcfg.dat 73, de Tom DL1JBE. > 73 > Martin, OK1RR > > ___ > Tlf-devel mailing list > Tlf-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tlf-devel -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Tlf 1.2.0 do not find hamlib
Hi Fred, Am Mon, 13 Aug 2012 20:23:11 +0200 schrieb Fred Siegmund : > This brings me to the question, when will TLF support QTCs? I would > LOVE it!!! :-) I would love it too :-). So it is on the list but I fear it will take some time. 73 Tom DL1JBE > > 73 Fred DM3F > > Am 11.08.2012 19:02, schrieb Olaf Devik: > > > > Tlf 1.2 more and less up and running for the WAEDC contest. Still > > some other issues, see other posts. > > > > 73 de Olaf - LA3RK > > > ___ > Tlf-devel mailing list > Tlf-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tlf-devel -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] TLF-1.1.3 bugfix release
A new TLF bug fix release is available at https://github.com/downloads/Tlf/tlf/tlf-1.1.3.tar.gz It mainly fixes the not working CLUSTERLOGIN reported by David N1EA and Martin OK1RR. Old tlf-1.1.2 contained a bug in the parsing logic for logcfg.dat and rules files. It failed to recognize some keywords if there was a similar one with the same beginning (e.g. CLUSTERLOGIN got not recognized as there is also a CLUSTER keyword). Furthermore it complained about empty lines in that files with: 'Keyword '' not supported'. Bug fixes: - Implemented new and much more robust parsing logic for keywords. Reworked and rechecked also all parameter handling to allow a better failure handling. - tlf no longer complains about empty lines in config files. - Add support for '~' expansion for '-f' command line switch. (Thanks N1EA). Something like 'tlf -f~/mydir/logcfg.dat' is working now. - Add description of reset of CW bandwidth during band switch and CWBANDWIDTH= keyword to man page. Furthermore a some cleanup and internal changes are made to simplify future maintenance, e.g.: - Cleanup of unused variables and comments. - Fix configure-script to abort if no ncurses lib is installed. - Rename 'configure.in' into 'configure.ac' as former will be no longer accepted by automake-1.13 Please have a thorough check how your logcfg.dat and rule files are accepted. While I did a thorough check that all parameters will be recognized now there may be some subtle changes I did not found yet. Please report back how it goes. 73 es gd DX, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Tlf 1.2.0 bugs or missed something?
Hi Martin, in meantime I fixed both problems - see new tlf-1.2.0_pre2. Btw, do you know if the winkey USB daemon supports all modes from cwdaemon - especially the possibility to get an feedback as soon as the message is played. I would like to use that feature to get a better autosend. 73, de Tom DL1JBE. Am Tue, 14 Aug 2012 20:25:05 +0200 schrieb Martin Kratoska : > Hi, > > while testing the tlf-1.2.0_pre1 I found following: > > - the telnet cluster autologin does not work. A manual login needed > regardless of the fact that > > CLUSTERLOGIN=OK1RR > > used in my logcfg.dat > > - while tlf initializing a strange message appears: > > Keyword '' not supported. See man page and README. > > man page and/or README does not mention this. This message appears > when some contest rule files used but when using the cqww rules from > the tarball tlf-1.2.0_pre1.tar.gz this message does not appear. It > seems that this message appears with my old contest rules, mostly > these using initial exchange. This message appears sometimes twice. > > 73 > Martin, OK1RR > > ___ > Tlf-devel mailing list > Tlf-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tlf-devel -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Fw: bugs in tlf-1.2.0_pre2
Datum: Mon, 10 Sep 2012 14:43:39 +0200 Von: Thomas Beierlein An: ad...@ok1rr.com Betreff: Re: bugs in tlf-1.2.0_pre2 Hi Martin, thanks for the report. Am Mon, 10 Sep 2012 03:19:10 +0200 schrieb Martin Kratoska : > The September CWopen by CWops discovered following bugs in > tlf-1.2.0_pre2: > > Cabrillo files While the information about contests without RST is new to me I know about the problems with writing cabrillo files. That functionality is severly broken for a long time. I am currently working on a solution to fix that. It should fix both of the named problems (drop RST and fix '#' display). For some more information see my second post. > > If WYSIWYG type of multiplier used, there is no mult indicator in > score window (sometimes there IS mult indication, depending on the > contest type used, unfortunately I can't recall which contests must > be in the CONTEST=* to display the mult indicator). Anyway, if > WYSIWYG is chosen, the mult indicator shows correct number of mults > only till restart or :res command. If you restart tlf or try :res > zeros are displayed instead. > Ok. I thoughed we fixed that some time ago. No fun to hear from that problem again. Sigh. As always: Thanks for the feedback. 73, de Tom DL1JBE > 73, > Martin, OK1RR > > P.S. To make things clear. here is an excerpt of the email from the > contest manager AD6E: > > Your QSO format is missing your sent serial number and your sent > name. For example, your first 3 QSOs: > QSO: 21025 CW 2012-09-01 1523 OK1RR 599 # W4DXX 250 ERIC > QSO: 21026 CW 2012-09-01 1524 OK1RR 599 # N3AD 219 ALAN > QSO: 21028 CW 2012-09-01 1525 OK1RR 599 # W5ASP 210 JOE > > I think they should be like this: > QSO: 21025 CW 2012-09-01 1523 OK1RR 1 MARTIN W4DXX 250 ERIC > QSO: 21026 CW 2012-09-01 1524 OK1RR 2 MARTIN N3AD 219 ALAN > QSO: 21028 CW 2012-09-01 1525 OK1RR 3 MARTIN W5ASP 210 JOE -- "Do what is needful!" Ursula LeGuin: Earthsea -- -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] bugs in tlf-1.2.0_pre2
Hi Martin, hi Fred, Am Mon, 10 Sep 2012 11:44:41 +0200 schrieb Martin Kratoska : > Hi Fred, > > although I cannot find it (now) in the source code, I suspect the > intial work of Rein, PA0R, which included some "hardwired" contests. You are quite right. Nearly all contest logic in TLF is hardwired. That goes for counting points and multipliers, what is to be displayed in the summary, the calculation of claimed points, the format of the log and the cabrillo file and much much more. While the code for that contests do mostly work the problems are in the area of self defined contests. Rein did some work to allow giving more or less points to different class of QSO's and also a start of a multiplier logic (WYSIWYG and others). But that always solved problems only for special contests. So by time there were more and more special rules, which do not fit together for modern contests. As Martin said it must be fixed soon. > If tlf should have any future, it must be cleaned from the remnants > of hardwired contests, also it must be freely configurable. Right. But it is a lot of work and time is sparse. The actual work on the 1.2 series is a start in that direction. It will have two main new features: - record actual frequencies from rig as requested by more and more contests (that part is done and can be tested in 1.2.0_pre1 and pre2) and - a complete new routine to write the cabrillo logs. (First as you both pointed out, the actual implementation of write_cabrillo is broken and works only for some special contests. Second we have some new contests which are not covered by the routine at all.) The new implementation will be controlled by a textual description of the cabrillo line which points out what to put in the line, where to put it and how much characters the field should be have (on github you can have a first look at that description syntax in share/cabrillo.fmt). That format description can be extended by each user of tlf so we can easily adapt new contests not covered in tlf's code. I am just on the way to complete the second part. I hope to finish it in the next two weeks. That should fix the wrong cabrillo formats and is a first step to make the whole tlf completely configurable. To make the whole tlf contest logic free configurable there are some more steps to go: - specify rules to give points to qsos and to count multis (What are points given for, how to handle unequal points for different bands, modes, for low power stations and so on. What counts as a multi, which possibilities are needed to have uncommon multi rules) - specify what to display on the summary panel and how to calculate the total score - find an easy way to formulate theses rules in a consistent text file. > The mess can be tracked down in the rule files. Although you define > your own contest, your rule file still needs to begin with a > CONTEST= directive which has ***PROBABLY*** another meaning than > just a contest name. No, in the rules file that information is quite useless. It has only to go to the logcfg.dat. It is just in the rule file to make sure it is the right file. > If you put there CONTEST=cqww you will get a > hardwired (predefined) DXCC and CQZ mults. In other hand, you don't > need to define any mult, the hardwired items are still there. > > My sincere apologies if my conclusions are totally false, actually I > have a mess in my files since tlf 0.9.3 and my programming (un)skills > preventing me from more thorough research of tlf internals. I hope > that some day a tlf expert comes with a deep and thorough explanation > of the tlf mechanics. > Yeah. tlf's internal working is quite a hardcoded mess. It took me nearly a year to understand its working (at least I hope so). The whole logic is scattered around a lot of places which makes it difficult to change a single piece without doing damage on other things. In the last months I did a lot of cleanup to uncouple some of that code and make it more maintainable. but it is far from done. 73, de Tom DL1JBE > 73 > Martin, OK1RR > > Dne 10.9.2012 11:00, FS napsal(a): > > The interesting thing is that, in some contests like CQWW this > > works, in some not. If it works the number is printed with 4 digits. > > > > 73 Fred > > > > On 09/10/2012 01:19 AM, Martin Kratoska wrote: > >> The September CWopen by CWops discovered following bugs in > >> tlf-1.2.0_pre2: > > > >> Another bug - if defining the part of exchange containing the > >> serial number (with #), the serial is actually not put into log, > >> the # character appears instead. > > > > ___ > > Tlf-devel mailing list > > Tlf-devel@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/tlf-devel > > > > > ___ > Tlf-devel mailing list > Tlf-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tlf-devel -- "Do what is needful!" Ursula LeGuin: Earth
[Tlf-devel] Fw: bugs in tlf-1.2.0_pre2
Hi Bob, Am Mon, 10 Sep 2012 07:35:23 -0600 schrieb w9ya : > If you want some ideas on how to do the various things listed below > (including the rig freq. input, flexible cabrillo output defined from > without the in-line program code, point and mult. definition from > without the subroutines, and etc), you can check out another open > source logging program that I have been maintaining the last year or > so: yfktest. > To be honest: yfktest gave me some of the ideas to think about :-). > One feature, the incorporation of coding algorithms from within each > contest's definition file (called a ".def" file and unique to each > contest) was added many years ago as coding feature designed to get > away from hardwired/in-line coding of scoring (sub)routines you > mention below. Well it is a little bit easier to do in yfktest because of the use of perl as programming language. You can easy refer to the variables internally used by their names. In C that names are only accesible at compile time and we need a little bit of interpretation each time we want to name internal variables in such a config file. > This code was authored by ws6z. To be useful it > did/does require a more robust way of combining mults and points, and > much of that work I did more recently. > Nice to know. Last time I had a look (some month ago) there were still some hard coded algorithms for scoring points and multis for some of the contests. I want to give up such algorithms alltogether, but let us see if we can manage to that point. > To wit: I finally got to use this incorporated feature in the two most > recent contests that I added: cwops-open and uba-fd. It works fb and > might be something worth studying. The two contest files for these can > be examined in the svn code base in the "defs" folder. You can begin > by going to my website here: > > < bfinch.net > > bfinch.net > > Anyways, I understand the need for different contest logging programs, > and I am a big supporter of tlf even though I decided to put my > efforts towards another set of code. i.e. I find it nice to have > something like tlf AND yfktest available for a variety of useful > reasons not the least of which is to offer choice and the fruits from > such choice. > > Oh yeah: I hope I haven't offended anyone with the suggestion to code > review the yfktest code for one way towards the feature implementation > you are searching for. It is not my intention to offend but rather to > help. At least not me :). It is always a good idea too look into neighbours garden and see what flowers they grow Thanks for your suggestions, 73 de Tom DL1JBE. > > Thanks for reading this far OM es > > VY 73 de; > > - Bob > w9ya > > > On Mon, Sep 10, 2012 at 6:55 AM, Thomas Beierlein > wrote: > > Hi Martin, hi Fred, > > > > Am Mon, 10 Sep 2012 11:44:41 +0200 > > schrieb Martin Kratoska : > > > >> Hi Fred, > >> > >> although I cannot find it (now) in the source code, I suspect the > >> intial work of Rein, PA0R, which included some "hardwired" > >> contests. > > > > You are quite right. Nearly all contest logic in TLF is hardwired. > > That goes for counting points and multipliers, what is to be > > displayed in the summary, the calculation of claimed points, the > > format of the log and the cabrillo file and much much more. > > > > While the code for that contests do mostly work the problems are in > > the area of self defined contests. Rein did some work to allow > > giving more or less points to different class of QSO's and also a > > start of a multiplier logic (WYSIWYG and others). But that always > > solved problems only for special contests. So by time there were > > more and more special rules, which do not fit together for modern > > contests. As Martin said it must be fixed soon. > > > >> If tlf should have any future, it must be cleaned from the remnants > >> of hardwired contests, also it must be freely configurable. > > > > Right. But it is a lot of work and time is sparse. > > > > The actual work on the 1.2 series is a start in that direction. It > > will have two main new features: > > > > - record actual frequencies from rig as requested by more and more > > contests (that part is done and can be tested in 1.2.0_pre1 and > > pre2) and > > - a complete new routine to write the cabrillo logs. > > > > (First as you both pointed out, the actual implementation of > > write_cabrillo is broken and works only for some special contests. > > Second we have some new contests which are not covered by
tlf-devel@nongnu.org
Hi Fred, sorry for the late reply. I was away for some days. Am Wed, 26 Sep 2012 14:24:15 + schrieb FS : > Hi Tom et al, > > because the CQWW RTTY coming up this weekend i gave TLF and Fldigi a > try again. My findings are: IF gMFSK.log exists, which is needed for > Miniterm funcionality in TLF it goes seg fault. Well, I will have a look into it. Sounds like a classical buffer overflow, which are deadly now. Just wondering that nobody has found it until now. To be honest the miniterm code is mostly the old untouched code from Rein. I have mainly looked into CW and SSB, so maybe that got overlooked. > What remains on the to do list: > - a new MINITERM in TLF (where to put it?, put callmaster somewhere > else?) I think better would be to switch callmaster off when doing RTTY or move the miniterm down over the bandmap. > - short gmfsk_autofile to 1 line + CR/LF, now it is 5 lines (4 are > empty) which causes a lot of scrolling on the RX side I have to llok into the code to understand that. Let me see. The segfault should be fixed in the next version. The other two problems will go to the TODO list. 73, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] TLF-1.1.4 maintenance release
A new TLF bug maintenance release is available at https://github.com/downloads/Tlf/tlf/tlf-1.1.4.tar.gz It is a minor maintenance release which corrects a lot of small annoying problems found by different people in last months (e.g. Fred DH5FS, Pierefrancesco IK5PVX and others). >From the NEWS file: New features: - ask for confirmation about reported problems in config files to give you time to recognize the problems. - Rework of digimode handling together with fldigi. Fix digimode receiove routine 'rx_rtty()', make miniterm output more robust and update miniterm also while the cursor is in the exchange field. Drop some unneeded newlines for each function key macro. - Minor corrections and additions to the man page Bug fixes: - Old version segfaults in 'searchlog' function if a really long callsign filled the input field. - Parsing logic for special characters in own exchange (# ...) do not rely anymore on a trailing NL to the exchange macro. - Fix sidetone control. Recognise CWTONE=0 in logcfg.dat, work around a bug in cwdaemon which does not allow to switch tone back on afterwards. - Stop flickering cursor between input or exchange field and dupe searchwindow. - fix Alt-t (tune) function to switch tuning on for 6 seconds (can be stopped early with any key press). !!Be aware that there are some problems in different cwdaemon versions (no PTT keying, no chance to stop tuning early, ...). Working with the maintainer to fix it. Further ongoing work: - Switch digimode communication to socket or XMLRPC interface which is preferred by FLDIGI - work on new cabrillo output which fixes known bugs and allows better control of log format 73 es gd DX, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] TLF-1.1.5 maintenance release
A new TLF minor maintenance release is available at https://github.com/downloads/Tlf/tlf/tlf-1.1.5.tar.gz It is a minor maintenance release which corrects some small annoying problems found by different people in last months. New features: - Report line number for badly formatted lines in initial exchange file. That makes it easier to find the problem for files with a lot of entries. Thanks Mario DH5YM for reporting the problem. - Allow to set SIDETONE_VOLUME to 0 independent from choosen sidetone device. Due to a bug in cwdaemon-0.9.4 setting SIDETONE to 0 switches off the sidetone but also the keying. So please... !!! Set SIDETONE_VOLUME = 0 to switch off sidetone output !!! Bug fixes: - Fix display of zone and section in searchlog window - Correct handling of function keys to send messages in digimode. Old code allowed function keys only during call input. New code supports them also in exchange field. As always reports about problems (or success) are welcome. 73 es gd DX, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Missed dupes
Hi Bob, Am Mon, 10 Dec 2012 09:53:42 -0800 schrieb Bob Nielsen : > I noticed during the ARRL 10 meter contest that tlf did not > recognize > that I had already worked one station when I entered the call > again > later. I checked several other calls and tlf correctly > recognized > them as dupes. thanks for the report. I have not seen that problem here. Can you give me some more information so I can look into the problem? Which version of tlf did you use? Can you remember the call sign with the problem and maybe can you send me the log file and logcfg.dat by private mail? 73, Tom DL1JBE > I recall seeing this in the past, but not recently > until yesterday. Is this a known issue and are there any thoughts on > how to avoid this? > > 73, Bob N7XY > > > ___ > Tlf-devel mailing list > Tlf-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tlf-devel -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Github dropped download features
I hope you all had a pleasant Xmas. I used the time to prepare a new tlf-1.2.0_pre3 version here (more on that later). Doing so I just had to realize that at start of december Github dropped their download service which allowed us to host packaged distribution archives at their side. The old files are still available for around 90 days (start of march). That means we have to find a new download location for tlf packages. Any suggestions are welcome. 73, Tom Dl1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] TLF-1.2.0_pre3 prerelease
After a busy autumn I found time to prepare a new TLF-1.2.0_pre3 prerelease. This is an experimental version to mainly check the new code to write cabrillo logs. Due to GitHub dropping the upload of packaged distribution ready files it is only available at http://www.hs-mittweida.de/tb/tlf-1.2.0_pre3.tar.gz It extends the features already found in TLF-1.2.0_pre2 (extended log file format and recording of working QRG) and incorporates all the work from tlf-1.1.4 and 1.1.5 (see NEWS file for details). New feature: The main feature is a totally new code to write cabrillo log files. The old code contained a lot of errors and was not easily extendable to new contests with different cabrillo formats. The new routine formats the cabrillo log according to a textual description (Which can be modified and extended by the user) located in /usr/(local/)share/cabrillo.fmt. That way we are easily able to adapt to (hopefully) all new cabrillo formats. Please read doc/README.cabrillo carefully for the details. Make sure to also have a look to the default cabrillo format descriptions provided in share/cabrillo.fmt to give you some examples. Be aware that you have to adapt your existing contest rule files to include the new 'CABRILLO=' statement. Please give the new cabrillo code a thorough test. I am mainly interested in: - Does it work for the standard contests with your old logs? - Is the description of the used 'cabrillo.fmt' file and the way to define new cabrillo formats in 'README.cabrillo' clearly written and understandable? As I am no native english speaker please have a look for corrections of the wording in that text. - As we support a limited set of keywords to describe what to put into the log file (DATE, TIME, QSL-S, ...) please make sure that you can describe all cabrillo formats for all of your contests. Give feedback if more keywords are needed. !ATTENTION! As with all tlf-1.2 version be aware that it will convert your old log files to the new format. So back them up of before trying use the new version. Feedback is highly welcome. 73 es gd DX in 2013, de Tom DL1JBE. -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.2.0_pre3 prerelease
Hi Ed, Am Sun, 30 Dec 2012 17:54:26 -0500 schrieb Ed : > On 12/30/2012 12:19 PM, Thomas Beierlein wrote: > > > - Is the description of the used 'cabrillo.fmt' file and the way to > >define new cabrillo formats in 'README.cabrillo' clearly written > > and understandable? As I am no native english speaker please have a > > look for corrections of the wording in that text. > > Very confusing what is the meaning of the 9 ? > > EXC2,9 > >From the README.cabrillo: "The name of the item has to be followed by a comma ',' and a number specifying the character width of that field in the QSO: line. Items which are to wide will be limited to that width." So the above means: Put the second word of exchange field into the next column and make the column exactly 9 characters wide (by cutting to long entries or by filling with spaces). > > What about the needed Cabrillo headers ? > Switching to Cabrillo v3 and allowing the header to also be configurable is one of the next steps before a final TLF-1.2.0. I put out the current version to get some first feedback early. 73, Tom DL1JBE -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.2.0_pre3 prerelease
Am Mon, 31 Dec 2012 08:22:50 -0500 schrieb Ed : > Thanks, now it makes sense, I should have read the README a little > closer. Maybe I did not write it clearly enough. > > >> What about the needed Cabrillo headers ? > >> > > > > Switching to Cabrillo v3 and allowing the header to also be > > configurable is one of the next steps before a final TLF-1.2.0. > > You might want to look at what Andy has done with Xlog. The needed > header is very user friendly. Also fldigi has a very capable header. > Ok, thanks for the pointers. I will have a look. > Thanks for your work on this project. > yw, 73 Tom > Ed W3NR > -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.2.0_pre3 prerelease
Am Mon, 31 Dec 2012 10:09:41 -0500 schrieb Ed : > Its clear enough, I just didn't fully understand the format. I used a > dummy log and prepared a cabrillo, but it does not look right to me > or I made an error somewhere in the fmt file. > > QSO: 7000 CW 2012-12-31 1434 W3NR 599 0001 W4RR > 599 0010 > > What is the 0 at the end represent ? Seems it uses the UNIVERSAL format and not your newly created one. In UNIVERSAL format there is an entry for the used transmitter (see CQWW contest). > > This is the contents of my fmt file > > QSO=FREQ,5;MODE,2;DATE,10;TIME,4;MYCALL,13;RST_S,3;EXC_S,6;HISCALL,13;RST_R,3;EXCH,6; > > Suggestons ? Please add a line in the format file above your QSO= line to name your new format (has to be in square brackets) [MY_Format] QSO=. and put the following statement in your contest rule file: CABRILLO=MY_Format That tells TLF which format to use for this contest. That should do it. Tom DL1JBE > > Ed W3NR -- "Do what is needful!" Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
