Re: ToDo item: switch logfile to database
Hi, On Thu, Dec 28, 2023 at 03:53:14PM +, Marcin SP6MI wrote: > Hi, > Shared database is wrong idea on my opinion, but syncing multiple database or > tables should be easier, I'm not sure about that. * it is completely outside the user-controlled area (from the view of Tlf) * building a synchronized database cluster is definitely not an easy task > safer and faster than textfiles. That's true. But it's not easier at all. > In the future maybe whole configuration + log per contest can be stored in > one database file. yes, if the majority can approve this, we can start to work on it. 73, Ervin HA2OS
Re: ToDo item: switch logfile to database
hi all, On Thu, Dec 28, 2023 at 09:56:44AM -0500, Alan Dove wrote: > Hey, folks: > > I'm opposed to having TLF rely on a database. to _RELY_ on a database, yes, I don't support that. > Users who want a tool to collect QSOs from multiple contests for > analysis, DXCC tracking, and so forth should use a separate > application. and what if Tlf would have a separated "application", which would be able to load the logs? And what if this application would be optional, and not mandatory? > CQRLog does all that and more, yes, but - for example - I want to use Tlf, and not CQRLog :) 73, Ervin HA2OS
Re: ToDo item: switch logfile to database
Hi all, On Thu, Dec 28, 2023 at 12:10:43PM +, Csahok Zoltan wrote: > Hi, > > I see currently no issue that introducing a DB backend would solve. > Technically for 1k records and holding it in memory no DB is required. it's not an issue - my idea was to collect all of my QSO's from each logs into a single database where I can see all of them and make several statistics, eg. DXCC status per BAND/MODE/etc. > One thing, on the other hand, that is now seriously broken is the networking > support. I requires a careful rework, including probably a redesign > as it apparently was created only with "simple" contests like CQWW in mind. > A shared DB could be an option here, but other loggers also typically use > distributed logkeeping for a reason. I would avoid to store QSO's in any external database (than our LOG), but as I explained, after the contest/periodically in a year it would be fine to make a summary. And if the code is done, is someone wants to store the data in DB, why not? I'm goinf to look up my previously code and try to help Marcin. 73, Ervin ps: HNY to all
Re: ToDo item: switch logfile to database
Hi OM's, On Wed, Dec 27, 2023 at 10:06:13PM +0100, Thomas Beierlein wrote: > Hi Marcin, > > the move to a database representation of the log file was discussed > some month ago. It got some pro and con arguments. > > Therefore there was no final decision to implement it. For the time > being we will stay with the actual log file format. @Marcin: this task was on my list, but not in that form as you descibed. @Thomas: I don't remember that discussion that you mentioned, and after a quick search I was not able to find it. But it could be my fault. Nevermind. I can imagine a feature when the operator can import the log into the database. The key fields are: date-time-band-mode-callsign, in case if you want to store all QSO's in same table. If you want to store the logs in separated tables, then you can use the serial. @Marcin: I have some working code, which parses the logs and builds a db structure in memory. If that's help you, I can share with you somewhere. I think that would be a usefull feature, and can be optional part of Tlf (eg. create a "configure" argument before user compiles Tlf). Any ideas? 73, Ervin HA2OS
Re: Few questions about tlf code
Hi Marcin, On Thu, Jul 06, 2023 at 11:00:51AM +, Marcin SP6MI wrote: > I've got two additional question regarding astyle. Why tabs not spaces? I don't know... Perhaps... just... because :) > And why line lenght is set to 80 characters, even when all modern editors > (even vim and emacs) supports and displays more characters in single line and > eventually they can wrap lines? Switching to 120 or something around could > simplify some if conditions and make them in one line :) as I know Zoltan uses vim (and as I remember he uses 80x25 terminal - but he will fix me :)), but it's just one example. The format was created by Thomas, and before that there was some discussion about that: https://lists.nongnu.org/archive/html/tlf-devel/2018-01/msg6.html Btw: you can use your own astylerc, but don't forget to reformat the modified files before you commit them. Perhaps you should take a look to git hooks (man 5 githooks). > Just asking and thinking. feel free to send a PR, and devs will decide your ideas can be approved or not. :) 73, Ervin
Re: Few questions about tlf code
hi guys, On Wed, Jul 05, 2023 at 05:28:23PM +, Marcin SP6MI wrote: > About formating, as example almost all if/else blocks in parse_logcfg.c file > (maybe rules for that astylerc needs to be fixed). yes, unfortunately using of astyle has became less important, but there was an intention: https://github.com/Tlf/tlf/pull/89 Now I checked few files, and most of them are not formatted. You can check it for eg.: $ cd src/github/tlf $ astyle --options="tools/.astylerc.orig" src/main.c 73, Ervin HA2OS
Re: TLF and CQ WW WPX Contest ...?
Hi, On Wed, May 24, 2023 at 06:18:05AM +0200, Martin Kratoska wrote: > Would be possible to enter CQ WW WPX Contest in other way than general > logger? How to do this? yes, CONTEST=wpx LOGFILE=wpx.log CONTEST_MODE CABRILLO=UNIVERSAL put these lines into rules/wpx, and set up it as rules in logcfg.dat: RULES=wpx Tlf knows WPX as hardcoded contest. See man tlf: "Tlf is a console (ncurses) mode general purpose CW keyer, logging and contest program for amateur radio operators. It supports the CQWW, WPX,..." 73, Ervin HA2OS
Re: What is the tlf future?
Hi Martin, On Mon, Oct 17, 2022 at 12:12:03PM +0200, Martin Kratoska wrote: [...] > while trying to check the CQRlog country files with my checker (made by > OK2CQR, attached) which worked perfectly with ver. 3.9. > The only change was upgrade from 3.9 to 3.10. "Only"? You've jumped a main version and you call it as "only"? As I see in your attached source tree, this software uses pipenv. If you upgraded your Python (and with this, you upgraded the full of your environment), you MUST upgrade your pipenv too. And then - as the README.md contains - run again the command pipenv install because your new version does not contain it. > P.S. This is the reason why I HATE Python! what advice could you give to a person who does not understand CW signals? Hate it or learn it? 73, Ervin
Re: Bandmap
Hi Ed, it depends on what you want. Btw. I think the apostrophes are not necessary, so the correct form is something like this: BANDMAP=BM,300 My 2 cents: 300 secs is a bit small, it means after 5 mins the spot will disappear from your bandmap. 73, Ervin HA2OS On Thu, Jul 28, 2022 at 3:30 PM Ed wrote: > > Is this correct ? > > BANDMAP='B''M',300 > > Ed W3NR > >
Re: Rig Control
Hi Ed,
On Wed, May 25, 2022 at 02:07:28PM -0400, Ed wrote:
> I use a ic-7300 and have it set to use USB0, but I get no rig control.
>
> Not sure how to correct this, the 7300 uses a symlink to USB0, so how
> do I get this to work ?
>
> /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge
> +_Controller_IC-7300_02038316-if00-port0
this is how I use my USB-serial converter.
I have an udev rule:
$ cat /etc/udev/rules.d/21-persistent-local.rules
ATTRS{manufacturer}=="Prolific Technology Inc.", ATTRS{idVendor}=="0557",
ATTRS{idProduct}=="2008", SYMLINK+="rig0"
so when I attached the converter (or boot my system), udev
creates a device with name /dev/rig0.
After that, I can use it in config:
RADIO_CONTROL
RIGMODEL=2009
RIGSPEED=4800
RIGPORT=/dev/rig0
You have to create your own udev rule for your device.
73, Ervin
Re: tlf & hammlib
Hi Ed, On Mon, May 23, 2022 at 07:46:01PM -0400, Ed wrote: > tlf version 1.4 tells me my icom 7300 is not supported. Hamlib says rig > # is 3073. can you show us your relevant config? 73, Ervin
Re: Any Way to Include WARC Bands?
Hi Alan, On Thu, Mar 10, 2022 at 01:06:29PM -0500, Alan Dove wrote: > I'm interested in using TLF to log some portable operations for Parks > on the Air. However, the band display and band switching only seem to > cover the contest bands. Is there any way to include the non-contest > bands such as 17m and 30m? I tried disabling Contest mode, but that > doesn't seem to do it. I'm using these settings for regular QSO's: CONTEST=qso LOGFILE=qso.log in rules/qso, and that's it. (Of course, the F-keys settings are there too) In this case, I see the WARC bands too. 73, Ervin HA2OS
Re: TLF logger, countrylist file format?
Hi Guys, On Tue, Mar 08, 2022 at 08:26:14PM +0100, Csahok Zoltan wrote: > Hi Gerard, > > The fix is available as a pull request. May I ask you to check if it > solves the issue? just fyi: I tested it with the given configuration (before the test I reproduced the segfault with the unpatched version), and it works as well. 73, Ervin
Opinion poll on a new feature
Hi Tlf OM's, yesterday I sent a new pull request for Tlf, which implement the "RESENDCALL" feature. You can see the details here: https://github.com/Tlf/tlf/pull/322#issue-1162010462 As N0NB Nate suggested below there, I'd like to ask what do you think about the logic of this feature. (Perhaps not everybody is subscribed on Tlf repository, nor not member of Github, but I hope many users read the mailing list.) I very welcome any suggestion, opinion for this feature. 73, Ervin HA2OS
Re: TLF logger, countrylist file format?
Hi Gerard, On Mon, Mar 07, 2022 at 07:09:36AM +, Gerard van Antwerpen wrote: > Thanks for your time to help. > First of all I installed originally using the easy way, using apt install tlf. > Then, after your reply, used the git clone method, which failed for some > reason (I'm not a Linux wizz, so probably operator error!). > Then used the tar ball, and that worked, and I'm now seeing Version 1.4.1. > However I'm still getting the error on the buffer overflow: > ++ > Welcome to tlf-1.4.1 by PA0R!! > > Reading country data > Reading configuration data > Reading config file: logcfg.dat > Reading contest rules file: rules/beru*** buffer overflow detected ***: > terminated > Aborted > +++ okay, I could reproduce the issue, that was my mistake. I just copied your configs, and didn't realize that the rules/benu contained this line: COUNTRYLIST=beru:zl1,zl2,zl3,zl4,vk,ve instead of COUNTRYLIST=berucountries With this, I got the same result. Meanwhile - perhaps you already saw - Zoli has opened an issue on GH: https://github.com/Tlf/tlf/issues/319 So I assume Zoli is working on it :). 73, Ervin
Re: TLF logger, countrylist file format?
Hi Gerard, On Mon, Mar 07, 2022 at 07:09:36AM +, Gerard van Antwerpen wrote: > Thanks for your time to help. you're welcome, > First of all I installed originally using the easy way, using apt install tlf. > Then, after your reply, used the git clone method, which failed for some > reason (I'm not a Linux wizz, so probably operator error!). > Then used the tar ball, and that worked, and I'm now seeing Version 1.4.1. no worries, it's good to see that you're using the last stable version. > However I'm still getting the error on the buffer overflow: > ++ > Welcome to tlf-1.4.1 by PA0R!! > > Reading country data > Reading configuration data > Reading config file: logcfg.dat > Reading contest rules file: rules/beru*** buffer overflow detected ***: > terminated > Aborted > +++ > I tried this in a virtual terminal as well, with the same results. > If you feel this is something to do with my local setup here, which would be > hard to check for you, please let it be and I'll get by without a countylist. as Zoli HA5CQZ mentioned previously, triggering the buffer overflow is not easy. Which OS do you use? An `lsb-release -a` output would be fine. 73, Ervin HA2OS
Re: TLF logger, countrylist file format?
Hi Gerard, On Fri, Mar 04, 2022 at 07:02:21AM +, Gerard van Antwerpen wrote: > I tried to add the beru: to the start of the file, and it gets read now (I > also think it needs to be in the main contest directory, not the one with the > rules in it), however I am getting the following error message: > > +++ >Welcome to tlf-1.4.0 by PA0R!! > > Reading country data > Reading configuration data > Reading config file: logcfg.dat > Reading contest rules file: rules/beru*** buffer overflow detected ***: > terminated > Aborted > +++ > > It is a long list of countries, but trimming it back doesn't help. > Putting a short country list in the rules file does get read, but doesn't > seem to affect scoring, all contacts are given 5 points (as I set with > CWPOINTS=5), and also points for my call area while I set MY_COUNTRY_POINTS=0 > > Attached my config files. thanks, I've checked your setup, but couldn't reproduce the issue. Tlf started and worked like a charm. Note, that I'm using the (nearly) latest git version of Tlf: $ git describe tlf-1.4.1-249-gebe9341 (which shows 1.5~git at the startup). Could you try the lates git version? And my 2cents: 44 # 45 # # 46 # Time offset from UTC # 47 # # 48 # 49 # 50 TIME_OFFSET=-13 (this is your logcfg.dat). Don't touch TIME_OFFSET, keep is as is. TIME_OFFSET=0 unless your workstation's time is not where you are. For more info, please check the manual. 73, Ervin HA2OS
Re: Documentation Updating
Hi guys, On Thu, Feb 24, 2022 at 06:57:41PM +0100, Thomas Beierlein wrote: > Maybe we should think about how to keep man page and manual.md in sync > in the long run. as I know, it is possible to make a man page from MD file. 73, Ervin
Re: Documentation Updating
Hi guys, On Wed, Feb 23, 2022 at 10:16:24PM +0100, Thomas Beierlein wrote: > Seems the ball is rolling :-). Fine. :) > Having the main documentation distributed with TLf in the main repo > seems sensible. agree, > Regards Ervins idea of an additional repo I would recommend the > existing tlf.github.io for any web page related documents. These > documents are easily rendered as GH pages by github. sure, it's a good idea! > While the discussion at the moment goes in the direction of using > markdown I learned that asciidoc is an alternative which has a little > bit more features which may be helpful. It can just as easily converted > to text, PDF files or html pages (and can even be used to produce man > pages :-) ). See for instance the WSJT-X suite - they generate their > whole documentation that way. > > Just my 2 c. But anyway, I am fine with both. using MD is also a good idea, we are using that in other projects too, and personally I like to use MD eg. generating static webpages. As you mentioned, maybe we can replace or renew the tlf.github.io page. 73, Ervin
Re: Documentation Updating
Hi all, On Wed, Feb 23, 2022 at 03:12:58PM -0500, Alan Dove wrote: > > Ervin, I can't read a word of Hungarian, but I'll trust that you've > done fine work there. I don't favor splitting the documentation into a > separate project. sorry, parhaps I was misunderstood - I don't want to split the documentation. > Let's keep it in the main Github repository and try > to stick with (or move things into) Markdown for the reasons already > outlined. I'm fine with keeping the man pages separate from the > Markdown documentation, as it does make some sense to expect people to > use the two types of references differently. sure, this documentation would be good for Tlf as "package". I thought we can start a new page for beginners. Or as Thomas mentioned we should replace the page tlf.github.io. As I see it's a bit outdated. > My focus so far has been to consolidate as much of the information as > possible into as few files as seems sensible. I've overhauled the main > README.md and INSTALL.md, and have now created doc/Manual.md, where > I've pasted the text from the separate files that used to be in that > directory. I'll hold off filing a pull request until I've done at least > one more editing pass through everything. thanks for clarification, now I see. Btw, I thought in the presence of such a "large number of volunteers" :) we can start to make/continue one of my previous idea. Btw it's a simple experience: few times I showed Tlf for other OM's, who used N1MM or other loggers. They didn't understand the UI, the logic... Then I thought we have to make a friendly page for these people. I'm not sure the current tlf.github.io, or any other page is able to presents Tlf from this point. Hope now it's clear what I suggest :). 73, Ervin
Re: Documentation Updating
hi there, On Wed, Feb 23, 2022 at 08:33:33PM +0100, Ervin Hegedüs wrote: Just one more thing, > The zipped file is available here: > > https://www.dropbox.com/s/i9bq4ixinh7cm23/tlfdoc.zip if somebody was curious and checked the doc, and didn't realized the effects, just move the mouse over the image :). 73, Ervin
Re: Documentation Updating
Hi all, On Wed, Feb 23, 2022 at 04:53:42PM +0100, Thomas Beierlein wrote: > Maybe I should give some starters from my point of view: > [...] I can add few more things. Few years ago I started to work on a documentation about Tlf for dummies. I mean for real "dummies", who never saw any Linux, and other terminal based tool. It's actually was made for older friends here, in HA. And because of this, I started to write it on Hungarian. :) I've never liked the raw and dry documentation. Tlf is a bit like vi - it's easy to use, but hard to learn. When I started, I wanted to make some friendly documentation. Now it's very good to see that there are some volunteers, who *wants* to work on this :). I can offer that working copy. As I wrote, that was made on Hungarian, but I'm sure if somebody used Tlf, then he can replace the texts as well. If not, Zoli or me can help. The zipped file is available here: https://www.dropbox.com/s/i9bq4ixinh7cm23/tlfdoc.zip May be we can make a new repository on GH under Tlf organization, eg. tlfdoc. Please review that, any feedback are welcome. > Maybe that can serve as some starting points. Feel free to ask here. > Zoli, Nate and Ervin as well as others can surely give additional > information. sure, let me know if I can help anything. 73, Ervin HA2OS
Re: DX Cluster Setup Help
Hi Alan, On Thu, Feb 17, 2022 at 11:21:30AM -0500, Alan Dove wrote: > Having recently switched to Linux (from Mac) for my ham computing, I'm > setting up TLF and really liking it. This weekend's ARRL DX CW contest > should provide a good test run of it. I think I've got everything > working except the DX Cluster. I've tried putting a few different > telnet cluster addresses that I know work (I can telnet into them from > another terminal window) in my logcfg.dat file, but none of the spots > seem to show up. The :pac and : commands do nothing, and > :cluster brings up a frame with nothing in it. you should try press "." (dot) and then the "O". Is there any changes? > Can someone provide a snippet of a known good logcfg.dat file, with > cluster configuration parameters that definitely work? I'm on Ubuntu > 20.04, by the way. I'm using dx.hu with these settings: TELNETHOST=dx.hu TELNETPORT=9000 Feel free to replace the host and the port. I must work. Regards, Ervin HA2OS
Re: error CAT IC-7610
Hi Juanjo, On Sat, Jan 30, 2021 at 02:07:17PM +, Juanjo EA8BGO wrote: > Dear Friends. > > I cannot configure the CAT of my IC-7610. I know that the hamlib works > since in the CAT of the CQRLog I have no problem, I do not have a > configuration problem in the FLRig either. > > ## > #RADIO CONTROL > RIGMODEL=378 > RIGSPEED=9600 > RIGPORT=/dev/ttyUSB0 > ## which Hamlib version are you using? If it's the 4.0 then you have to replace RIGMODEL=378 by RIGMODEL=3078 The other settings are same in Flrig and/or CQRLog? 73, Ervin HA2OS
Re: Trying to figure out a cppcheck warning
Hi Nate,
On Sat, Jan 23, 2021 at 08:43:59PM -0600, Nate Bargmann wrote:
> I've been working through the code base with the cppcheck GUI
> program--remarkably few issues, actually--and have hit one in qtc_log.c
> that has me a bit stumped. For reference start at line 198, the
> definition of the store_qtc() function:
[...]
First let me explain how QTC mechanism works on WAE. Now only the
CW/SSB contests count, the RTTY is a special case.
During the contest a DX station can send to EU stations data
from previous QSO's (except the current CALL): time (hour and
minutes), call and serial. The DX stations can send maximum 10
QCT, but they can send 1 per block, or max 10 in one block.
All previous QSO can only be sent once, so we MUST to mark the
QSO's which had sent. So if you sent me the QSO's above, you
can't send them anymore to anyone.
The `logline` in the code is the formatted QTC line. Consider you
participate on contest, you have one or more QSO, and made a
contact with me. I'll ask you, do you have QTC, you will answer
yes, and you will send me two QTC's:
01/02
0001 DL1A002
0001 DL2A003
The first line is the QTC header (serial and nr. of QTC's in
block), then the two QTC lines. The fields in the lines:
* 0001 means 00:01 was the time
* DL1A was the call
* 002 was the serial what _HE_ sent you
The attached code snippet responsible to mark the QSO's what
you've sent to avoid send them again.
A formatted log line looks like this:
40CW 0004 0001 24-Jan-21 08:48 HA2OS 0001 0004 0001 DL1A
002 7010.0
0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
^ ^
I've put the indexes the next line, and two markers what this
code uses.
The first occurrence of getting the substring in line 216, and as
the comment shows, it gets the number of the QTC block, whixh is
1 in this case - but it doesn't count here.
The second occurrence is the problematic place what cppcheck
showed in line in 225.
This value (0001 at position 12) tell us YOUR serial of that QSO.
You have to mark this QSO you can't send anymore. This is your
first QSO (serial 001) which stored in 0. index, so you get value
(after atoi()) is 1.
But the next line (226) this value decremented by 1, because in
the list of array is 0 base indexed (first QSO stored in 0.
index).
> Now, it's quite possible that cppcheck is getting tripped up in some
> manner. That said, I do think the array index and assignment on line
> 225 should be protected to assure the array index does not exceed
> MAX_QSOS, i.e. tempi be tested after its assignment by atoi().
no, I think the protection is not just that we never reach the
2 QSO (in line 225) :).
MAX_QSOS value is 2, so you can store 2 items in the
list, on index 0..1. If you can't store more QSO than 2,
then this value won't bigger than 1.
I think cppcheck is getting tripped here.
I think the problem is that there isn't any check which looks the
number of current QSO's: if we reach the MAX_QSOS number, we can
continue the QSO's (which is not true, perhaps there will be a
segfault - but it's independent from QTC's).
>
> Here is the relevant part of the function:
>
> 214 if (direction == SEND) {
> 215 /* find maximum sent QTC block serial */
> 216 g_strlcpy(temps, loglineptr + 50, 5); // get serial of qtc block
> 217 tempi = atoi(temps);
> 218 if (tempi > nr_qtcsent) {
> 219 nr_qtcsent = tempi;
> 220 }
> 221
> 222 /* mark corresponding qso line as used for QTC */
> 223 g_strlcpy(temps, loglineptr + 12, 5); // qso nr in qso list
> 224 tempi = atoi(temps) - 1;
> 225 qsoflags_for_qtc[tempi] = 1;
> 226
> 227 /* find first unused QSO number for QTCs */
> 228 if (tempi == next_qtc_qso && tempi < MAX_QSOS) {
> 229 while (qsoflags_for_qtc[tempi++] == 1) {
> 230 if (tempi == MAX_QSOS)
> 231 break;
> 232 next_qtc_qso = tempi;
> 233 }
> 234 }
> 235 }
>
Hope that's a bit more clear now :).
Thanks again,
73, Ervin
HA2OS
Re: Anyone else compiling with GCC 10.2 on Debian Testing?
ahm, sorry, that was my mistake - I didn't realize the g_random_int_range()... Using the constant value the output will be the same. Sorry again :). 73, Ervin >
Re: Anyone else compiling with GCC 10.2 on Debian Testing?
hi Nate, On Fri, Jan 22, 2021 at 08:42:24AM -0600, Nate Bargmann wrote: > > I've attached a short C program that now compiles clean with clang > and gcc with a modification to the format string and the arguments. but this result of this is different from that GCC: $ clang -Wall -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include trial_nate.c -lglib-2.0 $ ./a.out ---W0GCJ+++ $ gcc -Wall -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include trial_nate.c -lglib-2.0 $ ./a.out -W0GCJ+ $ clang -v Debian clang version 11.0.0-5+b1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10 Candidate multilib: .;@m64 Selected multilib: .;@m64 $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-gcn/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.1 20210110 (Debian 10.2.1-6) 73, Ervin HA2OS
Re: IC-7610
Hi Juanjo,
On Mon, Jan 11, 2021 at 11:28:34AM +, Juanjo EA8BGO wrote:
> Hamlib 3.3 I installed it from source.
>
> With $ ./configure --with-python-binding it gives me error:
> hecking python extra linking flags ... -Xlinker -export-dynamic -Wl, -O1
> -Wl, -Bsymbolic-functions
> checking consistency of all components of python development environment
> ... no
> configure: error: in `/home/juanjo/hamlib-3.3 ':
> configure: error:
> Could not link test program to Python. Maybe the main Python library has
> been
> installed in some non-standard library path. If so, pass it to configure,
> via the LIBS environment variable.
> Example: ./configure LIBS = "- L / usr / non-standard-path / python / lib"
> ===
>ERROR!
>You probably have to install the development version of the Python package
>for your distribution. The exact name of this package varies among them.
> ===
that's why I wrote you may have to install the
python3-dev|python-dev package to your system.
> Otherwise, with $ sudo apt install python-libhamlib2 runs without problem.
hmm...
I should rebuild the python module from source, than mixing the
source/package versions. Eg. IMHO python-libhamlib2 depends on
Hamlib, so I assume now you have two libhamlib.so on your
system...
> I have made a new video, you can see that things are the same.
> https://youtu.be/-IElZwiiYJE
first, clean this situation - only one hamlib can be on your
system, and the Python module must be depends only that.
What is the result of this command?
find /usr/ -iname "_Hamlib.so" -exec ldd {} \; | grep hamlib
73, Ervin
Re: IC-7610
Hi Juanjo, On Mon, Jan 11, 2021 at 10:28:09AM +, Juanjo EA8BGO wrote: > Chris > > $ python rigkeyer.py > Traceback (most recent call last): > File "rigkeyer.py", line 11, in > import Hamlib > how did you installed Hamlib? From source, or through apt? If you compiled Hamlib for yourself, perhaps you've missed to configure the Python binding, so step into your Hamlib source directory, and recompile the source: $ ./configure --with-python-binding ... make sudo make install This will install the Hamlib module for python. Note, for Python binding you need to install python3-dev package. If you used the package manager, then you can also install Python's hamlib binding: $ sudo apt install python3-libhamlib2 or $ sudo apt install python-libhamlib2 (guess you're using hamlib3, because Hamlib v4 isn't in stable repositories) The package name depends on your Ubuntu version. Here is the site of that package: https://packages.ubuntu.com/groovy/python3-libhamlib2 or: https://packages.ubuntu.com/bionic/python-libhamlib2 Hope this helps, 73: Ervin HA2OS > > El lun, 11 ene 2021 a las 10:15, Juanjo EA8BGO () > escribió: > > > Hello Chris > > > > Thanks for your help. > > > > So, the steps to follow follow the following? > > > > 1. launch the TLF > > 2. Run rigkeyer.py > > > > With cwdaemon what happens to me is this that appears in the video. > > https://youtu.be/fDaa7zdj37c > > > > Windows tell me that I have to configure the DTR and RTS. I don't have > > those options in cwdaemon (neither in winkeydaemon). > > > > Best regards, > > Juanjo > > EA8BGO > > > > El lun, 11 ene 2021 a las 9:32, Christian Treldal (< > > christian.trel...@gmail.com>) escribió: > > > >> Hi Juanjo > >> > >> The rigkeyer.py is a simple parser whitch listen to port 6790 (cwdaemon) > >> and retransmit on port 4532. Hamlib is listening on 4532 and sends it to > >> the radio. It is the same method used in Cqrlog and it works as a charm. > >> I've used it with the 7610 and my KX3; but it should be good with any rig, > >> where morse is supported in Hamlib. Just start rigctrld an then > >> rigkeyer.py, and off you go. It don't support speedchange +++ & --- ; but > >> that should be possible to fix. > >> > >> 73 de OZ1GNN > >> Chris > >> > >> Den søn. 10. jan. 2021 kl. 21.49 skrev Juanjo EA8BGO : > >> > >>> Dear Friends > >>> > >>> I have recently purchased an IC-7610 and I find the problem that when > >>> connecting the keyer via USB with the PC, the Cwdaemon does not recognize > >>> it. The only solution I have found is in the CQRLog using the Hamlib > >>> option. But I see that it is not the most successful solution for the > >>> TLFLogger > >>> > >>> I have seen in the forum a program written in Python (rigkeyer.py) that > >>> was originally written for K3. > >>> > >>> Does anyone know how to get the TLFLogger to work with my IC-7610 > >>> without having to use the old TTL adapter? > >>> > >>> Best regards, > >>> Juanjo > >>> EA8BGO > >>> > >>
Re: Rules file for SAC contest
Hi Pontus, On Sat, Aug 29, 2020 at 03:16:36PM +0200, Pontus Falk wrote: > Hi, > > I will try to use tlf in Scandinavian Activity Contest. > > To understand how to make the rule file for both Scandinavian stations > as well as for non-Scandinavians I would like to know if there are a > place where all the keywords for the rule files are explained? could you try these configs? https://gist.github.com/airween/7db7d08d7a81f2f98baf 73, Ervin HA2OS
Re: Error CAT TLFLogger 1.4.1
Hi Juanjo, On Sat, May 30, 2020 at 08:17:00PM +0100, Juanjo EA8BGO wrote: > Hello Zoltan. > > How do I make it work then? Because with the new version I can't get CAT to > work. as Zoltan wrote, the library is mandatory, which means the autoconfig tool will search automatically. You don't need (and you can't) enable/disable it. Just simply type: ./configure (or if you want to set your path just do it, or add --enable-fldigi-xmlrpx option - it's optional) and see what happens. You will see: ... checking for HAMLIB... yes checking for rig_open in -lhamlib... yes checking hamlib/rig.h usability... yes checking hamlib/rig.h presence... yes checking for hamlib/rig.h... yes ... That's it. 73, Ervin
Re: 1.5 release plan
Hi Thomas, On Sun, Apr 19, 2020 at 06:28:01PM +0200, Thomas Beierlein wrote: > Am Sat, 18 Apr 2020 20:59:20 +0200 > schrieb Ervin Hegedüs : > > > Hi there, > > > > is there any plan to release the version 1.5? > > > I think an 1.5 is not quite ready. But besides the GCC-10 fixes there > are some useful things in the actual code. > > I think best would be a tlf-1.4.1 version with the actual code. > That should be doable in the coming one or two weeks. ah - sorry, I just checked the current master version, and I saw it's 1.5-git. It doesn't count the exact version number :). > Would that fit in Debian time frame? I think that would - I'll write to reporter. 73, Ervin
1.5 release plan
Hi there, is there any plan to release the version 1.5? The Debian has an ftbfs (fails to build from source) issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957876 I checked the build log, but looks like all affected part of code had fixed in current master, so the version 1.5 builds as well with gcc10. If the new version will come, we don't need to make any backport patch (this affects only the Debian Sid, if the new version will released, we can upload it and problem will solved). Thanks, 73: Ervin
Re: WARC Bands
Hi Austin, On Sat, Feb 22, 2020 at 07:28:15PM -0500, Austin Seraphin, KA3TTT wrote: > Sorry to ask an obvious question, but how do you enable WARC bands while > logging? On a related note, I don't quite understand the difference that > enabling contest mode makes. Does it change the behavior of the enter > key, or does it have other effects? I wondered if disabling it would > enable the WARC bands, but it didn't. if you put the option "CONTEST_MODE" into your rules/contest file (or your logcfg.dat), then Tlf will operate in contesting mode, and will *not* use WARC bands. If this option missing, or exists but you're using the CONTEST as "dxped", Tlf will use WARC bands too, eg. you will see them in your Worked window, see the spots in cluster from those bands, and Tlf will includes them if you switch the bands (eg. pressing LEFT or RIGHT cursor). > I ask because I belong to the SKCC. It has sprints which use the > standard non-WARC contest bands, but it also has awards which can use > any band. The sprints count towards the awards. How should I best > configure tlf for this case? I'll contribute the rules once I have > something working if it would help. I'm using Tlf for logging the "regular", daily QSO's too, not just for contest. I just simple removed the CONTEST_MODE, and I always see everywhere the WARC bands. (Note, I don't have ANT for WARC bands, so I'm not using them.) 73, Ervin HA2OS
Re: HA-DX Contest
Hi all, On Thu, Jan 16, 2020 at 02:28:23PM +0100, Csahok Zoltan wrote: > Hi Slav, > > At least you can use the provided initial exchange file: > http://www.ha-dx.com/hadx_file/n1mm_p/HADX.zip Zoli, the sent gist contains the prepared initial exchange file (for Tlf): https://gist.github.com/airween/78a1b8872150c649e31e5a6e695d2556#file-initial_exchange :) 73, Ervin
Re: HA-DX Contest
Hi Slav and others, I've made the rules, but I think the point of scoring that's not perfect. HA-DX has a special multiplier mechanism: the multis are the DXCC entities AND the WAE entities AND the HA counties. The DXCC and WAE is very similar, there are only few unique WAE entries, which not the DXCC entry, eg. the GM is Scotland in DXCC and WAE, but GM/S is a unique entity in WAE, but not in DXCC. For the full list, see this list: https://www.darc.de/en/der-club/referate/committee-dx/diplome/wae-award/wae-country-list/ Another example: JW and JW/B. But I think these aren't relevant. The bigger problem is that Tlf can handle only one multi set IMHO. If we set the the COUNTRY_LIST (which means the DXCC entries are the multis), then the HA counties will not multis. And reverse too. The rules and connected files are here: https://gist.github.com/airween/78a1b8872150c649e31e5a6e695d2556 Any ideas are welcome. 73, Ervin On Thu, Jan 09, 2020 at 12:23:46PM +, SP3RXO wrote: > That's fine Ervin, I'll wait. I checked your previous rules file on > github as well but it looks that the contest rules was changed from this > time. > > Thanks, > > 73! de > Slav, SP3RXO & EI2IDB > FISTS #19019 > SOC #1251 > SP CW Club > > W dniu 09.01.2020 o 11:39, Ervin Hegedüs pisze: > > Hi Slav, > > > > On Thu, Jan 09, 2020 at 11:11:58AM +, SP3RXO wrote: > >> HI all, > >> Tried to make rules file for HA-DXC and my every idea simply working bad > >> or in other words is not working at all. > >> Anyone has any idea how to do one for non-HA station? Link to contest's > >> rules: http://www.ha-dx.com/en/contest-rules > > > > there is a task on my list to make the complete config for HA-DX > > for Tlf - please give me few days, I'll create them soon :). > > > > > > > > 73, Ervin > > > > > > > pub 4096R/70F8F900 2019-08-18 ei2idb (pojecia nie mam co robie) > > sub 4096R/896555BF 2019-08-18 [expires: 2020-08-12]
Re: HA-DX Contest
Hi Slav, On Thu, Jan 09, 2020 at 11:11:58AM +, SP3RXO wrote: > HI all, > Tried to make rules file for HA-DXC and my every idea simply working bad > or in other words is not working at all. > Anyone has any idea how to do one for non-HA station? Link to contest's > rules: http://www.ha-dx.com/en/contest-rules there is a task on my list to make the complete config for HA-DX for Tlf - please give me few days, I'll create them soon :). 73, Ervin
Re: Using hamlib for CW keying
hi Christian, On Fri, Nov 22, 2019 at 12:19:29PM +0100, Christian Treldal wrote: > Hi Ervin > > Den 22.11.2019 kl. 09.49 skrev Ervin Hegedüs: > > > > >ohh... :) > > > >I found it in my Dropbox :P > A memoryleak;-) perfect description :) > >Note, that I've tested now with both Python version (2 and 3). My > >TRX doesn't support the CW keying via Hamlib (TS850 still), but I > >could test it with the DUMMY RIG. Now it works as well, there > >were an another necessary modification in line 25 (in old code). > > > I just made a quick test with my KX3 and we are back in business good to read :) > Again thanks a lot Ervin, see you in the test you're welcome, I'll participate from our club station with call HG5C - see you there! :) 73, Ervin
Re: Using hamlib for CW keying
Hi Christian,
On Fri, Nov 22, 2019 at 12:18:18AM +0100, Christian Treldal wrote:
>
> Den 21.11.2019 kl. 14.58 skrev Ervin Hegedüs:
> >Hi Christian,
> >
> >On Thu, Nov 21, 2019 at 12:29:38PM +0100, Christian Treldal wrote:
> >>A year or something ago Ervin wrote a quick Python2 script for keying via
> >>hamlib. It has n
> >I MADE A PYTHON SCRIPT? :D
> >
> >Could share with me/us? :)
> >
> Yes Ervin AND THE EVIDENCE!!!
>
> https://www.dropbox.com/s/ofn5p482dsf49tv/rigkeyer.py
ohh... :)
I found it in my Dropbox :P
> I've been trying to convert it to Py3 , no capitals in socketserver and
> remove .decode("utf8") and is seems to run; but it don't send anything to
> the radio.
hmm, sounds interesting.
Anyway, I modified the code, it's avaliable here:
https://www.dropbox.com/s/4jiqdsesomcccio/rigkeyer.py
(the old link redirects to the rigkeyer2.py)
Note, that I've tested now with both Python version (2 and 3). My
TRX doesn't support the CW keying via Hamlib (TS850 still), but I
could test it with the DUMMY RIG. Now it works as well, there
were an another necessary modification in line 25 (in old code).
> >you mean aboue like K3? Once I started to review how does it
> >works, but IMHO it's too difficult. We discussed about this topic with
> >Zoli HA5CQZ, but now I don't remember the results.
>
> I've been using it with my KX3 and no problems. In the beginning there was a
> buffer overflow in hamlib; but it seems to be ok now
sure, then I assume you successfully installed the Hamlib Pythons
module for Python 3.
> I tested today $echo "+\send_morse'test'" | nc -w 1 localhost 4532 to a
> IC-7610 and it cw happily
please check it again with this new version above!
Anybody can use it with this way:
python2 rigkeyer.py
or
python3 rigkeyer.py
HTH,
73, Ervin
HA2OS
Re: feature request: cabrillo template
Hi all, On Sun, Nov 17, 2019 at 10:32:16AM +0100, Joop Stakenborg wrote: > It would be nice to have a cabrillo template. If present, all the questions > when exporting to cabrillo can be skipped. a few days ago I reviewed the possibilities, now I'ld like to discuss them here. 1. the most simple way when we add new keywords to the config files, eg. CABRILLO_CONTEST, CABRILLO_CALLSIGN, ... therefore you can use these keywords both in logcfg.dat and contest rule files PRO: easy to make it CON: you have to add the keywords everytime when you prepare a new contest 2. read the new keywords from separated file; there are two sub-solution in this case a. this file could contains only the CABRILLO related options PRO: clear and elegant solution CON: hard to implement, makes the code logic more complicated and horrible b: this fie could any keyword, we just "call it" as "CABRILLO" file PRO: *could* be clear, easy to implement CON: can lead to chaos (user can mix the options and can't see the reason of the different bevaiour) Let's start to discuss :). I prefer 2/b. 73, Ervin HA2OS
Re: getting ready for the CQWW CW
Hi Joop, On Thu, Nov 21, 2019 at 10:30:35PM +0100, Joop Stakenborg wrote: > Hello girls and boys, > > > I can't seem to get the correct rules file for the CQWWCW this weekend. In > the CQWW both the CQ zone and the country count as a multiplier. I have: > > MY_COUNTRY_POINTS=0 > MY_CONTINENT_POINTS=1 > DX_POINTS=3 > MULT_LIST=zones.txt > DX_&_SECTIONS > > > Looks good okay? just fyi, Tlf supports CQ-WW "out-of-box", this contest is "hardcoded". >From the man tlf: It supports the CQWW, WPX, ARRL-DX, ARRL-FD, STEWPERRY, PACC and EU SPRINT contests as well as a lot more basic contests, ... so this is enough: CONTEST=cqww LOGFILE=cqww.log CONTEST_MODE ... F1=+++TEST ---% +++TEST--- F2=% ... (note: of course, you can put more "+" to the begin of the TEST... :)) > The first QSO I make with DL1AA in zone 14: 1 point, 1 multiplier for > country (should be 2, one for country and one for section) > > The second QSO with W2GD in zone 5: 3 points, 1 mutiplier for section > (should be 2, one for country and one for section) > > > Is my setup okay? I think just try that one above. 73, Ervin HA2OS
Re: Using hamlib for CW keying
Hi Christian, On Thu, Nov 21, 2019 at 12:29:38PM +0100, Christian Treldal wrote: > > A year or something ago Ervin wrote a quick Python2 script for keying via > hamlib. It has n I MADE A PYTHON SCRIPT? :D Could share with me/us? :) > been working flawlessly until now. I've upgraded to Fedora31 and Python2 has > been depreciated. I am trying to convert it to python3; > > But I think it is a good time for a humble feature request for Tlf 1.x.x. A > build in hamlib keyer, so at least I can avoid stressfull expiriences like > this. > > All modern rigs have keying via hamlib. you mean aboue like K3? Once I started to review how does it works, but IMHO it's too difficult. We discussed about this topic with Zoli HA5CQZ, but now I don't remember the results. 73, Ervin HA2OS
Re: feature request: cabrillo template
Hi all, On Mon, Nov 18, 2019 at 07:01:53PM +0100, Thomas Beierlein wrote: > Hi Ervin, > > sounds good so far. If there are no other suggestions from Joop or > others just go ahead. thanks - right, I'll start to make it soon. 73, Ervin
Re: feature request: cabrillo template
Hi all, On Sun, Nov 17, 2019 at 06:00:41PM +0100, Thomas Beierlein wrote: > Hi Joop, > > I assume you are talking about the contest and operator related > informations gathered when you want to write a new cabrillo file. > > Can you please elaborate some more about what you have in mind here. > The head part of the cabrillo file is not independent of the contest. > So one template for all seems not to fit. But I see that at least the > operator related part could be common between contests. > > Any comments or suggestions? I don't want to answer for Joop, but I thought about this feature earlier. I imagined like this: logcfg.dat: CABRILLO_DATA=/home/airween/.tlf/HA2OS_general.cab CABRILLO_CONTEST=CQ-WW-CW ... /home/airween/.tlf/HA2OS_general.cab CABROLLO_CALLSIGN: HA2OS CABRILLO_LOCATION: DX CABRILLO_CATEGORY-OPERATOR: SINGLE-OP CABRILLO_CATEGORY-ASSISTED: NON-ASSISTED CABRILLO_CATEGORY-BAND: ALL CABRILLO_CATEGORY-POWER: LOW CABRILLO_CATEGORY-MODE: CW CABRILLO_CATEGORY-TRANSMITTER: ONE CABRILLO_CATEGORY-OVERLAY: CABRILLO_CONTEST= I wrote deribelately the CABRILLO_CONTEST field at two places (logcfg.dat and general data file): the second occurrance of field overwrites the first, so therefore we can replace the values at every contest, but can use a basic data. When user types a ":w" in callsign field (start to export the log to CABRILLO), then the fields which has values (by set them the fields above) will filled in dialogues. If you like this way, I can start to implement it soon. 73, Ervin HA2OS
Re: scoring the HSC contest with tlf
Hi Joop, On Mon, Nov 04, 2019 at 09:23:25AM +0100, Joop Stakenborg wrote: > Op 03-11-19 om 19:56 schreef Ervin Hegedüs: > >Hi Joop, > > > >On Sun, Nov 03, 2019 at 05:41:26PM +0100, Joop Stakenborg wrote: > >>I have been using tlf 2 times today: during the ukrainian DX contest and the > >>HSC CW contest. I have managed to write a rules file for the ukrainian, but > >>not for the HSC. > >> > >>Does anyone know how to do this? Multiplier is easy enough with COUNTRY_MULT > >>but how do you score points? It is 5 points for member, who send their > >>member number and 1 point for non-members, who send 'NM'. > >I'm afraid actually you can't do that. > > > >There are so much possibilities to control the scoring, but not > >for this. > > So, what would it take to have this added to tlf? > > We already have ONEPOINT, TWOPOINTS and THREEPOINTS, can we also have > FIVEPOINTS? this is a good question :). I think there is some historical reason (as many other things in Tlf :)), but of course, we can change it. The first part of your ideas are simple (POINTS=n). > Even better, how about adding points depending on the exchange, > something like POINTS="NM",1. Using POINTS= would make configuration of > scoring easier. We could use POINTS=1, POINTS=2, POINTS=3, POINTS=5 instead > of ONEPOINT, TWOPOINTS and THREEPOINTS or even FIVEPOINTS. Of course > multiple POINTS= lines would have to be possible. For example: > > POINTS=5 > > POINTS="NM",1 I think that something like this could be a solution, but what about the other patterns? What if you can describe the pattern only with some regex? > >>Also, is there a way for tlf to automatically fill in the member number in > >>the exchange field, like yfktest does? > >yes, I think that could work - see INITIAL_EXCHANGE directive > >(where you're one example :)) > > > > Thanks, I will have a look. I am still using yfktest in the CWOPS mini CWT > contest, but would like to migrate to tlf completely because development of > yfktest has stopped. ahm, sorry to hear that. :( 73, Ervin
Re: OK/OM DX Contest
Hi all, On Mon, Nov 04, 2019 at 05:16:12PM +, SP3RXO wrote: > The OK / OM competition will take place over the weekend, Saturday > 12:00UTC - Sunday 12:00UTC. I made a rules file for non OK/OM stations > (nothing complicated this time, hi), the most important part is: here are the rules for two contests: OK-OM and Ukranian DX. Both of them are tested (and used :)). https://www.dropbox.com/sh/5rgp03jehlb11ro/AAANn7u2dgUnB_IyoQa9vo6Sa Hope that this will helps you too, 73, Ervin HA2OS
Re: scoring the HSC contest with tlf
Hi Joop, On Sun, Nov 03, 2019 at 05:41:26PM +0100, Joop Stakenborg wrote: > > I have been using tlf 2 times today: during the ukrainian DX contest and the > HSC CW contest. I have managed to write a rules file for the ukrainian, but > not for the HSC. > > Does anyone know how to do this? Multiplier is easy enough with COUNTRY_MULT > but how do you score points? It is 5 points for member, who send their > member number and 1 point for non-members, who send 'NM'. I'm afraid actually you can't do that. There are so much possibilities to control the scoring, but not for this. > Also, is there a way for tlf to automatically fill in the member number in > the exchange field, like yfktest does? yes, I think that could work - see INITIAL_EXCHANGE directive (where you're one example :)) 73, Ervin HA2OS
Re: [Tlf-devel] Error Fldigi with TLFLogger.
Hi Juanjo,
On Sat, Sep 28, 2019 at 10:43:53AM +0100, Juanjo EA8BGO wrote:
> Hi
>
> I can't read the FLDigi files on the TLFLogger. I do not know what I'm
> doing wrong. But the most curious thing is that the RTTYLog file does
> record activity. In the TLFLogger nothing appears on your screen.
sorry for the late answer, meantime I reviewed your issue again,
and looks like I have some bugs.
The first is that the Tlf -> Fldigi direction (sending text, read
carrier from Fldigi, set RIG mode to Fldigi, ...) doesn't work.
This patch is fix that, but I'm not sure that this is the final
version:
==
diff --git a/src/gettxinfo.c b/src/gettxinfo.c
index 5da2ce3..71fe7ca 100644
--- a/src/gettxinfo.c
+++ b/src/gettxinfo.c
@@ -120,6 +120,7 @@ void gettxinfo(void) {
static int oldbandinx;
static int fldigi_carrier;
static int fldigi_shift_freq;
+int t_trxmode = trxmode;
if (!trx_control)
return;
@@ -168,6 +169,7 @@ void gettxinfo(void) {
if (trxmode == DIGIMODE && (digikeyer == GMFSK || digikeyer ==
FLDIGI)
&& retval == RIG_OK) {
retvalmode = rig_get_mode(my_rig, RIG_VFO_CURR, (rmode_t
*), );
+ trxmode = t_trxmode;
if (retvalmode != RIG_OK) {
rigmode = RIG_MODE_NONE;
}
==
But looks like there are some other synchronicity problem, eg.
changed the DELAY (":CQD" command), and then the mode after the
band switched to CW...)
Please try this, and report your experience.
73, Ervin
HA2OS
___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] WAE CW at this weekend
Hi all, at this weekend there will be the WAEDC CW contest: https://www.darc.de/der-club/referate/referat-conteste/worked-all-europe-dx-contest/en/ As you know, Tlf supports the both side: DX and EU stations too. It would be good that somebody from the DX side could run on the contest, and - if it possible - make some videos. Here are some videos from my contest in 2017: https://vimeo.com/ha2os If you have any question, just let me know! 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] EUHFC
Hi Slav, On Thu, Aug 01, 2019 at 09:12:12PM +0100, SP3RXO via Tlf-devel wrote: > Hi all, > > Could anyone share rules file for upcoming Slovenian EUHFC contest? sure: https://gist.github.com/airween/168a5fdb4368208e47ef35fe135a6c06 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] atoi hiscall
Hi Zoli, On Thu, Aug 01, 2019 at 09:32:00PM +0200, Csahok Zoltan wrote: > Hi Ervin, > > Yes: if you enter a frequency in kHz as callsign, then the rig switches to it. > A nice but maybe undocumented feature. well, awesome idea, congrats! And thanks for clarification :). 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF run mode problem
Hi Drew,
On Thu, Aug 01, 2019 at 02:42:23PM +, Drew Arnett wrote:
> Thanks for digging in, Ervin.
>
> I will look at that pull request. Another difference in my case is
> that I'm using my pywinkeyerdaemon with a K1EL (www.hamcrafters.com)
> 'WinKeyer USB'. https://github.com/drewarnett/pywinkeyerdaemon (One
> diff though, as I need to update it for the later python-serial lib;
> timeout is now set by attribute, not method. I also need to publish a
> python3 version!)
I don't think that this could be the problem.
> Interrupting auto_cq to respond would involve
> sending a message to NETKEYER/cwdaemon.
but this is an important thing - I just started to review your
first e-mail, and try to eplore the relevant parts of the code.
You wrote in your first mail:
"Start auto CQ which works fine. As soon as I start typing in a
callsign, the auto CQ stops and the "AUTO_CQ" marker in the upper
left corner changes to "S". (Is this a clue?) I type in his
callsign and hit enter in the callsign box. TLF sends mycall."
So, I interpret that when you typed the other station CALL, then
Tlf switched to another mode (CQ -> S_P), and _this_ is why after
the ENTER it sent _your_ call, not the other station call. I mean
the reason can't be the NETKEYER, it occures by the type,
_before_ the netkeyer code starts to send the message.
I found this part, which would be relevant:
https://github.com/Tlf/tlf/blob/tlf-1.3.2/src/callinput.c#L263
(note, that this is not the current master state, it's the 1.3.2,
this file had modified meanwhile; but the 1.3.2 is what in
Debian)
Based on the code, I just can think about your keyboard layout,
or some terminal settings - eg. you're using some strange TERM
environment, which grab the '+' in every key pressing...
So now I'ld try to check the terminal settings, eg:
export TERM=linux
or
export TERM=xterm
and start Tlf, check the issue.
Hope that we can solve your issue soon :).
Another note to Thomas/Zoli HA5CQZ: do you know about this line?
https://github.com/Tlf/tlf/blob/tlf-1.3.2/src/callinput.c#L648
if (atoi(hiscall) < 1800) {
this will always 0, and less than 1800 - or em I wrong? :)
73, Ervin
HA2OS
___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF run mode problem
Hi Drew, On Thu, Aug 01, 2019 at 02:17:13AM +, Drew Arnett wrote: > I just tried a fairly new desktop hard disk (less than a year old) > with an older USB 2.0 to SATA adapter. I put my local working > directory there (logcfg.dat, rules, cty, partials, log), and the same > bad behavior persists. Will install buster to hard disk (not via USB > adapter) and see how that behaves. > meanwhile I searched our discussion with Thomas, it was in January of 2018. The problem was not in the mode switching, but in the backgroud_process() - the cleanup() function called faster than the netkeyer sent the message to keyer. And that bug was fixed: https://github.com/Tlf/tlf/pull/84 After read this mail from you, I'm sure in this case the problem is totally different, but currently I don't have any idea. Reflect to your apt-cache outputs: looks like this package is what I pushed to Debian (compared the hashes), not the another build. And the source of package is equals with the upstream reelase. To any other users: could someone check this version? Let's keep in touch, 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF run mode problem
Drew, Thomas, and all,
On Tue, Jul 30, 2019 at 02:26:25PM +, Drew Arnett wrote:
I don't have Debian Buster actually, but have a Debian SID - it's
not so far from Buster :), and all related components are same as
your side:
# dpkg -l tlf *hamlib* | grep ^ii
ii libhamlib++-dev:amd64 3.3-5+b1 amd64Development C++ library to
control radio transceivers and receivers
ii libhamlib-dev:amd64 3.3-5+b1 amd64Development library to
control radio transceivers and receivers
ii libhamlib-utils 3.3-5+b1 amd64Utilities to support the
hamlib radio control library
ii libhamlib2:amd64 3.3-5+b1 amd64Run-time library to control
radio transceivers and receivers
ii libhamlib2++c2:amd64 3.3-5+b1 amd64Run-time C++ library to
control radio transceivers and receivers
ii libhamlib2-tcl3.3-5+b1 amd64Run-time Tcl library to
control radio transceivers and receivers
ii tlf 1.3.2-1 amd64console based ham radio
contest logger
On that machine, I don't have a phisycal connect with RIG, so
I've used `rigctld -m 1`, set up the "virtual" rig on another
terminal ("rigctl -m 2; F 14002000"), and started Tlf with Drew's
config.
> Run mode has problems. Start auto CQ which works fine. As soon as I
> start typing in a callsign, the auto CQ stops and the "AUTO_CQ" marker
> in the upper left corner changes to "S".
I can't reproduce this issue. When AUTO_CQ sent the CQ, and I
typed a foreign call, it switched to "LOG". I finished the
callsign, pressed TAB, entered the zone, pressed ENTER, then Tlf
sent "TU KB9FKO", and stayed in LOG mode.
I pressed F12, Tlf switched to AUTO_CQ, and started to sent the
CQ again.
> (Is this a clue?) I type
> in his callsign and hit enter in the callsign box. TLF sends mycall.
> Wrong behavior. I'm expecting it to send his call and my exchange. I
> enter his exchange and hit enter in the exchange box and it sends TU
> and my exchange. Also wrong behavior. In both cases, it sends the
> correct thing for S, but not the correct thing for run mode.
sorry, I have no idea, what happened.
> Am I doing something wrong? Do I have something misconfigured? Is it
> a bug in the SW? Or if this should work, and it was a mistake in
> debian packaging deltas, should I file a debian bug?
I don't know how many user uses Tlf from the Debian repository.
There is a popularity contest, but the number of users is under
100:
https://qa.debian.org/popcon.php?package=tlf
but I think this issue would occured with these users.
> My setup...
>
> OS: debian buster live 10.0.0 xfce
could you show me these outputs?
apt-cache show tlf
apt-cache showpkg tlf
Could you try it with another setup, eg CQWW (as Thomas proposed
too).
Just my 2cents: there was a similar issue at my side few years
ago, when I switched from SATA disk to SSD. I've worked on some
sprint contest (DARC Oestercontest...?), and the two modes
switched "too fastly", and sometimes it switched twice, so I got
back the original mode.
As you wrote, you're using Debian Buster Live - em I right that
this uses RAMDISK? Which is faster than an SSD...?
Do you have any permanent installed Debian? It should be in any
virtual system (VirtualBox, VMWare, ...). If yes, could you try
there?
Thanks,
Ervin
HA2OS
___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF run mode problem
Hi all, On Wed, Jul 31, 2019 at 07:57:31AM +0200, Thomas Beierlein wrote: > Am Tue, 30 Jul 2019 14:26:25 + > schrieb Drew Arnett : > > I tested tlf-1.3.2 (compiled from the sources here) with your > provided settings (Thanks) and it worked as expected - staying in RUN > mode after stopping auto CQ by inserting a call. > [...] > Can someone from Debian please check tlf-1.3.2-1 for the problem > (Ervin?). At a first look there seems to be no particularities. sure, I'll check out soon. 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Rules and mult for Russian DX Contest.
Hi there, I think the attached rule file is better, 73, Ervin HA2OS ## # HA DX Contest # ## # CONTEST=rdx LOGFILE=russiantest.log CONTEST_MODE # MULT_LIST=russiandx_mults COUNTRYLIST=rdx:R,RA,RB #COUNTRYLIST=RDX COUNTRY_LIST_POINTS=10 DX_POINTS=5 MY_COUNTRY_POINTS=2 MY_CONTINENT_POINTS=3 SERIAL+SECTION SECTION_MULT #RECALL_MULTS INITIAL_EXCHANGE=rcalls.txt SERIAL_OR_SECTION ## # # # Messages F1= to F12= # # Message CW_TU_MSG= # # Message S_TU_MSG= # # # # % = call # # @ = hiscall # # # = serial # # [ = RST # # + = increase cw speed # # - = decrease cw speed # # (works only with parport # # interface) # # # ## # F1=++CQ TEST-- % ++TEST-- F2=% F3=@ +++TU 5NN--- # F4=TU 73 F5= @ F6=% F7=@ SRI QSO B4 GL F8=AGN F9= ? F10= QRZ? F11= PSE K F12=+++CQ TEST--- % % +++TEST--- # CQ_TU_MSG=++TU-- % +++TEST--- S_TU_MSG=++TU-- 5NN # ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Rules and mult for Russian DX Contest.
Hi Juanjo, On Fri, Mar 15, 2019 at 09:35:24PM +, Juanjo EA8BGO wrote: > I have created a Rules file and a multipliers file for the Russian DX > contest. > > I hope it is useful for the user community of TLF Logger many thanks for you work - just one note: I think the CONTEST value would be better as "russian_dx" instead of "arrl_dx", so the final version is in rule file: CONTEST=russian_dx Hope that helps - and we will meet on contest! :) 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] debian test failure
Hi all, On Sun, Dec 16, 2018 at 05:24:21PM -0600, Nate Bargmann wrote: > * On 2018 16 Dec 13:18 -0600, Pontus Falk wrote: > > Hi, > > > > Is there a repository to add? Can't see it available in Ubuntu and > > derivates yet. > > I just did an update in aptitude on Testing and Tlf is still at version > 1.3.1. According to the debian-hams mailing list Tlf 1.3.2 was accepted > into Unstable on 14 Dec. As it usually takes about ten days for > packages to flow into Testing, it will probably arrive on the 24th or > 25th as a Christmas present. as I know, the time between migrate from SID to TESTING is 6 days. And as I see, today Tlf had been migrated to testing: https://tracker.debian.org/news/1012656/tlf-132-1-migrated-to-testing/ Note, that Hamlib also: https://tracker.debian.org/news/1012545/hamlib-33-1-migrated-to-testing/ :) 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] debian test failure
Hi all, just inform to you, Tlf successfully builded on all architecture in Debian: https://buildd.debian.org/status/logs.php?pkg=tlf Thanks Zoli, 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] cw via hamlib
Hi all, On Tue, Nov 20, 2018 at 05:40:49PM +0100, Thomas Beierlein wrote: > Hi Chris, > > Am Thu, 15 Nov 2018 23:28:57 +0100 > schrieb Christian Treldal : > > > Hi guys > > > > In 2015 there was some discussions about cw via hamlib at this list. > > Nate discovered that his K3 could be keyed via hamlib. > > > > Did this effort result in any improvement to tlf. If yes, then it is > > not very well documented how to setup cw via hamlib. > > > sorry, there is no news wrt keying via hamlib. Still only cwdaemon and > winkeydaemon are supported. what I started to plan and make: * create a cwdaemon-like daemon, which works similar as cwdaemon from point of Tlf, but uses hamlib API * start a rigctld which handles RIG, and servers clients through network * cwdaemon-like daemon sends the message to rigctld * Tlf uses RIG through rigctld too But looks like I ran a bug in Hamlib netrigctl interface :). If it works, then we can integrate it to Tlf. > > Hope to get ready to the CQWW > > Have fun. I hope to be back on sunday to be able to attend at least for > some hours. Cool, I'll operate from HG5C! 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] debian test failure
Hi Zoli, On Sat, Nov 03, 2018 at 09:25:49PM +0100, Csahok Zoltan wrote: > Managed to install a Sparc64 system and reproduce the issue. > > It is a test-only error due to only storing a pointer instead of > saving the actual message string during the tests. > Some of these strings are generated in local variables > that may "disappear" before it comes to actually check them. > > It's interesting that this issue didn't surface before. These > architectures (hppa, sparc64, alpha) seem to have a different > stack handling that zeroes new frames and thus overwrites previous > locals. > > Preparing a PR with the fix. congratulation! And thanks :). 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] v1.4 topics
On Fri, Nov 02, 2018 at 11:21:57PM -0500, Nate Bargmann wrote: > * On 2018 02 Nov 12:30 -0500, Thomas Beierlein wrote: > > P.S.: The 'todo' list now: > > > Consider requiring a key press on the first screens when Tlf is started > without a log file. They often close too quickly to read all the > details. Subsequent runs can be as it is now. An alternative might be > to have an option keyword (yet another!) in logcfg.dat specifying a > timeout in seconds for each screen where 0 would require a key press and > negative would disable them. > > Thoughts? a quick note for your last idea - that's very good! :) That'ld be a useful feature. 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] debian test failure
Hi Zoli, On Thu, Nov 01, 2018 at 02:44:20PM +0100, Csahok Zoltan wrote: > Hi Ervin, > > Thanks for the info. The failing test tries to read a line > with an empty callsign field and expects an error message. > It uses strchr+strtok for parsing, i.e. quite basic libc stuff that > should be platform independent. yes, that should be it. > I wanted to reproduce the failure on a VM but > according to this https://www.debian.org/ports/index > alpha and hppa are "discontinued", sparc64 is "in progress". > > Not too promising. Anyway will try set up a sparc64 system. thanks for your check - but I guess it's interesting only for us :), or if you'll find something, you can send a bugreport to libc maintainers :). (I don't think that the test cases have any bugs...) The 1.3.1 is uploaded to SID, soon will be part of testing: https://packages.debian.org/sid/tlf 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Preparation for tlf-1.3.1
Hi folks, On Thu, Sep 13, 2018 at 07:02:26AM +0200, Thomas Beierlein wrote: > Hi Zoli and others, > > very well. Maybe we should have a list of things to do for the coming > 1.4 version. At the moment I see the following: > > * make hamlib mandatory > * allow vertical resizing of tlf (more room for cluster messages) > * drop 'scan' menu with noise bridge, panorama scan and smeter display > (It did not work for a long time and I think no one is using it) > > If there are additional ideas please add to the above list and send > back. just a quick info: Tlf 1.3.1 will part of Debian Testing soon: https://tracker.debian.org/news/999705/accepted-tlf-131-1-source-into-unstable/ Anyway, the build flows on different architectures runs, and looks like some of them has failed: https://buildd.debian.org/status/package.php?p=tlf Especially: alpha: https://buildd.debian.org/status/fetch.php?pkg=tlf=alpha=1.3.1-1=1541010733=0 hppa: https://buildd.debian.org/status/fetch.php?pkg=tlf=hppa=1.3.1-1=1541010778=0 sparc64: https://buildd.debian.org/status/fetch.php?pkg=tlf=sparc64=1.3.1-1=1541010531=0 I think that's not so big problem, but may be it would be good to check the tests, specially the run_initial_exchange.c and test_initial_exchange.c. May be there is a workaround to avoid this bug on these arch's. This is not relevant - just let you know. 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.3.1 early pre release
Hi Thomas, On Fri, Oct 19, 2018 at 06:23:39AM +0200, Thomas Beierlein wrote: > Hi Ervin, > > finally I find time to answer. Sorry for the delay. no problem :) > Am Sat, 13 Oct 2018 18:15:22 +0200 > > ok - what should we do? After first and quick review I thought we > > can make a new function in callinput.c, called sethiscall(), > > which waits a string, and sets the hiscall. All other function in > > different threads collects the callsign in a local buffer, and > > call this function. This new function should rentrant and thread > > safe... any idea? > > > I think there is a better way. Copy the call in fldigi_get_log_call() > into an intermediate buffer and set a flag. During callinput() we pick > that up and bring it to hiscall. The access to the buffer can be > protected by a mutex and so made thread safe. > > The advantage in these scheme is that we have control when we change > hiscall. Otherwise it may be possible that fldigi_get_log_call() does > change it during some unrelated operation (e.g. writing the last QSO to > disk or similar). thanks - I think I understand it, and will try to made as soon. As I reviewed the code, we have to modify the getexchange() function as similar mode with "comment" variable. 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.3.1 release
Hi Slav, On Mon, Oct 15, 2018 at 09:28:32PM +0100, SP3RXO wrote: > Big TU for new TLF. > > But I have problem with compile new TLF on Ubuntu 18.04 > > ./configure passed without any errors, but make generating these: it's interesting, > ... > CC addarea.o > gcc: error: GLIB_CFLAGS@: No such file or directory > Makefile:577: recipe for target 'addarea.o' failed > make[2]: *** [addarea.o] Error 1 are you sure you have installed the libglib2.0-dev package? What is the output of "dpkg -l libglib2.0-dev" command? The configure script needs to report, if you don't have it, that's why I wrote above it's interesting... Thanks / 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.3.1 early pre release
Hi Thomas, On Sat, Oct 13, 2018 at 09:11:32AM +0200, Thomas Beierlein wrote: > I just found time to add your last changes to TLF. Thanks for finding > the problem. > > There is still one problem with your solution which you should sort out: > fldigi_get_log_call() is called from background_process which runs as a > separate thread parallel to the logging front end function logit(). > That may be ok for just polling fldigi and displaying the > received text in the rtty window. But for manipulating hiscall and > displaying the according country information it may result in problems > as both - your function and callinput() may manipulate the same data. yes, it's clear for me (now...). > Furthermore neither getctydata() nor searchlog() are checked to be > threadsafe, so calling it from the background thread may be > problematic. as I see, both function called from different threads - without fldigi_get_log_call(), so we have to review anyway. > I have added the code as is to get forward with the 1.3.1 release but > you should sort out the problems in next time. ok - what should we do? After first and quick review I thought we can make a new function in callinput.c, called sethiscall(), which waits a string, and sets the hiscall. All other function in different threads collects the callsign in a local buffer, and call this function. This new function should rentrant and thread safe... any idea? > And just another wish: Please do not add every global variable into > main.c (there are already much to much there). Put it where it > logically belongs (see my last commit). ok, thanks for notification. 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF add lan port PR
Hi Eric, On Thu, Oct 11, 2018 at 03:10:19PM -0400, Eric Tamme wrote: > Hey all I put together a PR that is NOT YET WORKING - I apologize > for that, but I wanted to get feedback on how to get it working > and I figured a PR was the best way to go about that based on > previous feedback here. not the PR is the best way, but I think that's no problem :) > As I said in the PR, the goal is to be able to allow multiple > networked TLF instances to run on the same computer, binding to > the same IP, but to different ports. > > > I dont believe my case is getting hit b/c I am setting > lan_enable=1, however unless I add a host via config, I do not > get any socket binding. This is after adding a "LAN_PORT=9988" > directive to my config. I've made a fix: https://github.com/airween/tlf/commit/902dd1d8afe41929e41054f7d41395913bb693d0 the diff: https://github.com/etamme/tlf/compare/master...airween:etamme/master?expand=1 as you can see, the problem was that in line 574 in parse_logcfg.c the closed comma missed. Then your new keyword was at pos 262, not the 263. HTH, 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] first time user F1-F3 questions
Hi Eric, On Mon, Oct 01, 2018 at 02:09:18PM -0400, Eric Tamme wrote: > Is this just current master, or is there a branch or tag yet for this release? as you can see, the master branch of Tlf/tlf repo contains Stephen's related commit: https://github.com/Tlf/tlf/commit/a280f99a6b079c53ed883603245b3875f54ebc1a here are all commits of master branch: https://github.com/Tlf/tlf/commits/master 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] error cabrillo CQ WW RTTY
Hi Juanjo, On Mon, Oct 01, 2018 at 07:38:55AM +0100, Juanjo EA8BGO wrote: > Yes, it does. so now you can sent your log successfully? 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] error cabrillo CQ WW RTTY
Hi Juanjo, On Mon, Oct 01, 2018 at 06:35:06AM +0100, Juanjo EA8BGO wrote: > > Am Sun, 30 Sep 2018 23:08:53 +0100 schrieb Juanjo EA8BGO : > > > > > The cache generated generates errors in the CQ-WW-RTTY server. > > > > > > In Rules CQWW I have the following: > > > > > > > > > # # > > > # CQWW CONTEST # > > > # # > > > > > > # > > > CONTEST = cqww > > > LOGFILE = cqww.log > > > CONTEST_MODE > > > CABRILLO = CQWW > > > # > > Your settings seems to be ok. Can you please provide us with the error > > reporting you got from the server? That would be helpful. as Thomas wrote, looks like all settings are right, but when you type :write in callsign field, and CABRILLO dialog opens, the first question is "Your exchange (eg. State, province, age etc... (# if serial number)):" - then you have to type "33 DX" instead of just simple "33". Hope this helps. 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.3.1 early pre release
On Mon, Oct 01, 2018 at 06:32:54AM +0200, Thomas Beierlein wrote: > Am Sat, 29 Sep 2018 23:17:55 +0200 schrieb Ervin Hegedüs : > > > Hi Thomas, > ... > > I just sat down to RIG since one hour ago, and tried to made some > > RTTY QSO's, testing the new version. > > > > * when the callsign filled from Fldigi, the COUNTRY and ZONE in > > bottom border or Worked window is wrong; that shows always > > the last QSO info > > * sometimes the CQ zone filled with _that_ value, not the CQ zone > > of current CALL > > * the BMAUTOADD doesn't works; I moved away with click in Fldigi > > waterfall to the next signal, Tlf calculates the new FREQ, and > > tune VFO, may be it defines... > > > Hmm, that sounds not so good after all. > > The first two problems may be connected to the change from Stephen to > enable the use of the cty.dat files from CT9. I checked it working, but > must admit only for CW. I think I've found source of all problems, and doesn't connect to Stephan's patch. The Fldigi fills the callsign, and there missed some extra function call in first two issues. The third issue occured because the bmautoadd worked only when user types the callsign, the Fldigi callsign set was ignored. I've fixed it too. There is a plus minor issue: in fldigixmlrpc.c Tlf sets the RIG's VFO based on its mode and the Fldigi's carrier. Those values are differs, eg: when OP uses USB or LSB, we need to calculate as other way the accurate freq. I didn't know about RTTY-REV, so I've wrote the code that calculate freq as same way than LSB/USB. At this weekend I could work with a K3 in FSK mode, and checked RTTY-REV mode, but the calc was wrong: always tune the VFO to another direction. The first commit fixes this issue. > I will look into the patches you provided in meantime. right, thanks. > P.S. Please note that I will be away most of the week, so responses > from me may be late. thanks for info, 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.3.1 early pre release
Hi Thomas, On Sat, Sep 29, 2018 at 11:17:55PM +0200, Ervin Hegedüs wrote: > Hi Thomas, > > > On Thu, Sep 27, 2018 at 08:40:16PM +0200, Thomas Beierlein wrote: > > Hi all, > > > > an early pre release for TLF-1.3.1 is available under > > > > http://www.hs-mittweida.de/tb/tlf-1.3.1pre.tar.gz > > I just sat down to RIG since one hour ago, and tried to made some > RTTY QSO's, testing the new version. > > Now I'm very tired, so I can't investigate these experiences, may > be I'm wrong, but they came again and again... > > * when the callsign filled from Fldigi, the COUNTRY and ZONE in > bottom border or Worked window is wrong; that shows always > the last QSO info > * sometimes the CQ zone filled with _that_ value, not the CQ zone > of current CALL these two issues had fixed here (and one more other): https://github.com/Tlf/tlf/compare/master...airween:fixups_1.3.1?expand=1 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.3.1 early pre release
Hi Thomas, On Thu, Sep 27, 2018 at 08:40:16PM +0200, Thomas Beierlein wrote: > Hi all, > > an early pre release for TLF-1.3.1 is available under > > http://www.hs-mittweida.de/tb/tlf-1.3.1pre.tar.gz I just sat down to RIG since one hour ago, and tried to made some RTTY QSO's, testing the new version. Now I'm very tired, so I can't investigate these experiences, may be I'm wrong, but they came again and again... * when the callsign filled from Fldigi, the COUNTRY and ZONE in bottom border or Worked window is wrong; that shows always the last QSO info * sometimes the CQ zone filled with _that_ value, not the CQ zone of current CALL * the BMAUTOADD doesn't works; I moved away with click in Fldigi waterfall to the next signal, Tlf calculates the new FREQ, and tune VFO, may be it defines... Note, that all of them can reproduce with Fldigi. I can try it tomorrow, and try to see the source at next week. 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] change ip addres tlf binds to?
Hi Eric, On Wed, Sep 26, 2018 at 01:40:05PM -0400, Eric Tamme wrote: > I've done a quick change which I think will add the ability to > configure the IP via a config directive. Can you guys eyeball > the diff and see if it makes sense, or if I have missed anything > major? > > > https://gist.github.com/etamme/5fab0f3c13717322b3abb85e8acea28f just my 2cents: I see you've Github account, with several repos. Why don't you fork the Tlf from https://github.com/Tlf/tlf, create a new branch, apply the patch, and send a PR? :) 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Cabrillo export truncating exchange (comment) after first space
hi folks, On Wed, Sep 26, 2018 at 04:27:29PM +0200, Thomas Beierlein wrote: > Am Wed, 26 Sep 2018 08:54:34 +0200 schrieb Ervin Hegedüs : > > > when do you want to release the new version? > > As soon as possible. I plan to release a preview version today or > tommorow. sounds good, > There may be some things missing but I would like to get some > feedback before preparing the final one. of course, the preview would be good for this, > Depending on the feddback I think the final release can be in > 10..14 days. ok, as I wrote I just ask you for the preview - the next contest is good for testing (for everyone :)) 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Cabrillo export truncating exchange (comment) after first space
Hi Thomas, and folks, On Tue, Sep 25, 2018 at 08:39:49PM +0200, Thomas Beierlein wrote: > Hi Nate, > > while preparing for a new tlf-1.3.1 release when do you want to release the new version? Will be there beta version? I just ask you, because at this weeken will be the CQ-WW-RTTY contest, if anybody interesting and would help to test the new version, then can be grab it before we emit the final release. https://www.cqwwrtty.com/ There are few affected (RTTY) patch... 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] CWOps CWT Contest
Hi Eric, On Tue, Sep 25, 2018 at 12:54:26PM -0400, Eric Tamme wrote: > The exchange is Name and CWOps number. Is there a way for me to > setup a prefill file that includes the CALL, as well as NAME and > NUMBER - then have the name and number populate in the exchange > field after I type in the call? see man 1 tlf, search for "INITIAL_EXCHANGE" keyword. You have to create a file with name as you want, filled by line by line: CALL1;NAME1 NR1 CALL2;NAME2 NR2 then in your rules/contest config file: INITIAL_EXCHANGE=name_as_you_want Note, that I've never tested it with two arguments - please refer about it. > The manual says that using "+" switches between S and Run > modes, but I cant see any visual indicator to let me know what > mode I am in, or that anything is different after hitting +. just see the top of the window, "line 1" Couple of years ago I've started to make a better documentation, but it was made in hungarian (I've edited it for my OM friends in club). Here is a small snipet from that: http://ha2os.ha5kkc.com/Tlfdoc/ move mouse over the picture, especially to "Log" text - that's what indicates the current mode. > I see in the bottom right "bands: all, modes: all, dupes: yes" .. > I would like to change some of these settings, I looked in the > template config and can not find anything related to band, mode > or dupe configuration for a given contest file. which settings want you change? Anyway, in CALL field, just press ".", then you will see this at bottom of field: "Toggle and, ode, upes or nly multi filter | any other - leave" so you can filter the current band with B, mode with M, ... these characters switches the filter to on/off. > Scoring is basically 1 point per callsign and each unique call > sign is a mult - different bands do not count as an extra mult. > I am guessing the scoring I want is WYSIWYG_ONCE, is that > correct? I think that's not correct. For this rule see UNIQUE_CALL_MULTI keyword. > I think that is all my questions ... for now ;) hope this helps, 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] first time user F1-F3 questions
Hi Eric, On Tue, Sep 25, 2018 at 10:53:51AM -0400, Eric Tamme wrote: > I just tested using Xterm, and the issue does not occur. I would > like to be able to use gnome-terminal if possible though. Have > you got any suggestions on how I might go about getting that > figured out? okay, I've installed gnome-terminal, and can reproduce your problem. You can prevent this issue with this way: $ export TERM=xterm $ tlf ... but (after few seconds of testing) don't forget to set up your shortkeys - on my side the F1 opens the help window of Gnome-terminal... you can disable it at this way: edit -> settings -> shortkeys (2nd tab from left) -> scroll to "Help", there is the "F1" -> click to "F1" -> F1 changed to "New shortcut" -> press "BACKSPACE" -> shortcut changed to "Disabled" Hope this helps - I'm using hungarian labels :). 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] first time user F1-F3 questions
Hi Eric, On Tue, Sep 25, 2018 at 10:23:46AM -0400, Eric Tamme wrote: > Im a first time TLF user, looking for a console based logger for > contesting on a linux machine. Welcome in out club! :) > I've got things set up, but it seems that my function keys F1, > F2, and F3 do not ... do what they should be doing. > > > My Top bar has "1=CQ 2=DE 3=RST 4=73 ... " but the only Function > keys that appear to map correctly are F6-F9, which send my call, > the dupe message, AGN, and ? respectively. which version are you using? (tlf -V) what you get when you type this command in terminal? $ echo $TERM My result: $ echo $TERM xterm > If I could get some guidance on how to get my Function keys > working properly, I think I could get TLF working well for my > uses. Fn keys are mapped for correct messages, but you can modify them of course - but I think your problem is not that, guess some terminal settings. Which terminal emulator do you have? 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Fwd: tlf
Hi Jaap, On Sun, Sep 23, 2018 at 12:35:33PM +0200, Jaap van oosten wrote: > > sudden WiFi connection adapter was lost / hangup? > deja vue Ubuntu had the same problem lost wifi after some time need reboot > that was on on other PC with other Wlan adapter sounds like some HW problem on your client side, or AP (access point) trouble. I'm using Linux Mint on my company laptop, always using WiFI, but never had any problem. > and also the complete ! mail conversation is gone in gmail > lost email address og ??? ha that's why it better to post to mailing list instead of private. You can find the archive here: http://lists.nongnu.org/archive/html/tlf-devel/ anyway: I don't think that a connection error removes all e-mails in any provider... :) 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] install TLF
Hi Jaap, On Sat, Sep 22, 2018 at 09:08:52PM +0200, Jaap van oosten wrote: > hallo > i did download and unzip ant cd tlf-master > and the tricky .. spelled > autoreconf --install if you get the tarball, you don't need to run the autoreconf (which generates the configure script). Just type: ./configure > but i have the same error with GLIB_2_0 missing i guess > thanks for your time, you're welcome :) > let me be the dummy tester guess you really don't think what a big help these feedbacks... :) 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] install TLF
Hi, On Sat, Sep 22, 2018 at 11:20:50AM +0100, Slav, SP3RXO wrote: > HI Japp, > Do what dh5fs and ha2os said or patiently wait for TLF new version. Should > be soon, I hope. I think Jaap would like to use Tlf from now. :) If the relases will come later (next after next), he can upgrade the newest version. Just let him to start to use - I guess he will have many other question... :). 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] install TLF
Hi Jaap, On Sat, Sep 22, 2018 at 09:28:03AM +0200, Jaap van oosten wrote: > hi > I would gladly like to test TLF logger > i am a long time user of N1MM Windows contest logger > and before that DOS CT hope you will enjoy Tlf :), > But these simple install instructions do not work for me > I understand the project has to be compiled on the target PC. > But just by typing ... > > Easiest way to install tlf from source is by typing: > > cd > ./configure > make > make install > > anywhere? > > must be in a terminal window > in the ?? yes, > i tried a few things > but simply type instruction > Is missing essential information that I as an interested but relative > fresh user of linux / mint does not automatically have > > please help me out right, please try to follow these steps: * open a terminal; you will be stay at your home directory * create a directory for the source: mkdir -p ~/src/tlf * and step it there cd ~/src/tlf * be sure you have all build dependencies: dpkg -l libglib2.0-dev libhamlib-dev libncurses5-dev libtinfo-dev libxmlrpc-core-c3 if one of these isn't marked as installed (ii flag at begining of line), you have to install it, eg: sudo apt install libhamlib-dev libtinfo-dev note, that the libxmlrpc-core-c3 need only if you want to use Tlf with Fldigi. * be sure you have all runtime dependencies: dpkg -l libglib2.0-0 libhamlib2 libncursesw5 libtinfo5 libxmlrpc-core-c3 sox xplanet note, that the last two packages are optional, but they will help you * grab the source: wget http://download.savannah.gnu.org/releases/tlf/tlf-1.3.0.tar.gz * then you can start to build flow: tar -xzvf tlf-1.3.0.tar.gz ./configure --enable-hamlib --enable-fldigi-xmlrpc note, that --enable-fldigi-xmlrpc needs only if you want to use Fldigi, --enable-hamlib needs only if you want to use RIG controll from Tlf. * if every dependencies are satisfied, the configure script will generate the Makefile(s), you can type: make sudo make install * now you can start to use Tlf I'm also use Tlf (of course :)), and I have a special directory in my $HOME, called ".tlf". Before every contest I created a contest subdirectory, copy files to there, step to that directory, and start Tlf, eg: ls -la ~/.tlf/wpx total 112 drwxrwxr-x 3 airween airween 4096 may 28 20:51 . drwxrwxr-x 29 airween airween 4096 sept 15 14:32 .. -rw-rw-r-- 1 airween airween11 may 27 22:50 .bmdata.dat -rw-rw-r-- 1 airween airween 37190 may 28 20:52 HA2OS.cbr -rw-rw-r-- 1 airween airween 4028 may 26 03:37 logcfg.dat -rw-rw-r-- 1 airween airween 523 may 28 20:52 .paras drwxrwxr-x 2 airween airween 4096 may 26 03:36 rules -rw-rw-r-- 1 airween airween26 may 28 20:52 tlfmarkers -rw-rw-r-- 1 airween airween 40480 may 27 22:50 wpx.log Hope this helps. If you have any other question, just let me know. 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Handling multiplier aliases?
Hi Nate, On Mon, Jun 11, 2018 at 01:22:04PM -0500, Nate Bargmann wrote: > * On 2018 11 Jun 12:07 -0500, Ervin Hegedüs wrote: > > Hi Ervin! > > > and you should pass this file to Tlf through parse_logcfg.c? > > > > brrr > > > > :) > > It's been a while since I followed the logic. Maybe that's why I sent > the email first. ;-) I'm sorry, that would be just a joke :) > > How many contest could we use this feature? > > I think it would be useful for a lot of US QSO parties. Not every state > has its own party so there are far less than 50 as some states do one > party as a group. Also, this probably only affects in-state > participants. How many Tlf users would this impact immediately, well, > me, for one. :-D good to read it :) (Anyway, that's sad but true, I didn't found any stat about the used loggers at biggest contests (CQWW/WPX, ARRL-DX). The only one stat is the Debian popcorn: https://qa.debian.org/popcon.php?package=tlf, which is - I think - not so bad!) > > Once upon I proposed that we sould start to a new direction in > > config file/rules parsing. I'm still thinking that the best way > > would be implement some external scripting language, as module, > > eg. Python and/or Lua. With one of those, everyone can make a > > more sophisticate rule for every contests. > > > > Here is my original opinion: > > > > http://lists.nongnu.org/archive/html/tlf-devel/2014-01/msg00101.html > > Thanks for the pointer back into that thread. I tossed a number of > lofty ideas out there! This post from Tom is apropos to this thread: > > http://lists.nongnu.org/archive/html/tlf-devel/2014-01/msg00104.html yes, I've also re-read that thread, and I think now I put myself together, and start to implement the Python config :) 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Handling multiplier aliases?
Hi all, On Mon, Jun 11, 2018 at 08:18:11AM -0500, Nate Bargmann wrote: > One thought I had would be to create a parallel mults file definition > using GKeyFile as the means for setting groups for mults, alias, and > alias_mults. I am thinking along the lines of: > > [Mults] > AL > AK > AZ > . > . > . > WV > WY > > [Alias] > KS > > [AliasMults] > (County abbreviations) > > > Then the code could look for the Mults group and if found process it and > if not, then revert to the current mults file style. > > In this format, any AliasMult entered would be applied as the Alias. > > Thoughts? and you should pass this file to Tlf through parse_logcfg.c? brrr :) I think the codebase of Tlf is already very complex. How many contest could we use this feature? Once upon I proposed that we sould start to a new direction in config file/rules parsing. I'm still thinking that the best way would be implement some external scripting language, as module, eg. Python and/or Lua. With one of those, everyone can make a more sophisticate rule for every contests. Here is my original opinion: http://lists.nongnu.org/archive/html/tlf-devel/2014-01/msg00101.html 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Trying to add the ARI-DX contest to TLF
Hi Koos, On Fri, May 04, 2018 at 11:12:14AM +0200, Koos van den Hout PE4KH wrote: > > Next weekend is the ARI DX contest > http://www.ari.it/index.php?option=com_content=article=5167%3Aari-international-dx-contest-2018=250%3Aari-international=270=en [...] > # all forms of italy > MULT_LIST=arimults > COUNTRYLIST=It:I,IS0,IT9 > EXCLUDE_MULTILIST=COUNTRYLIST the EXCLUDE_MULTILIST will exclude the argument list from multipliers, don't use it. > #SECTION_MULT > DX_&_SECTIONS after a quick look, I'm afraid the DX_&_SECTIONS is a right choose, but it works only in some special cases, eg. you're from W/VE country. Sorry. Anyway, I've tested your config, and only the first QSO occured what you wrote (you needed to type the exchange twice), after it accepted first time. Hope this helped. 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] Serial number exchange in tlf
Hi Heiko, On Thu, Apr 19, 2018 at 10:26:45PM +0200, hvoigt wrote: > Hi, > > is there a way to automatically fill in the serial number in the > exchange field? based on your e-mail, my question is: which exchange field did you mean? > Or is the field in front of the callsign supposed to be > that field? that's _your_ exchange, which you (need) to send. The "received" exchange field is right to the callsign field. Tlf fills it automatically in some cases (eg. CQWW, other contest where the exchange is some zone), but you can make an initial_exchange list, which you can pass to Tlf. If Tlf found a callsign in that list, then fills the exchange field, eg. DARC XMAS, DARC Easter-egg, ARRL-DX, IARU HF champ, and so many others. > In that case what should the effect of LONG_SERIAL and > SHORT_SERIAL be? It seems that it does not have any effect. SHORT_SERIAL will send the shortest form of numbers, eg. 9 -> N, 0 -> T, ... 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] ARRL DX initial exchange files
Hi there, at this weekend there will be the ARRL DX CW contest. A few weeks ago I've asked the logs from some top stations in last year. I've merged, collected and paired the W/VE callsigns with their state/provinces, and now the DX stations (outside of US/CAN) can use at this contest. Databases are avaliables here: Tlf: http://ha2os.ha5kkc.com/arrl_initial.txt WinTest: http://ha2os.ha5kkc.com/ARRL-USVE.DTB N1MM: http://ha2os.ha5kkc.com/N1MM_ARRL_history.txt general CSV file: http://ha2os.ha5kkc.com/ARRL_initial.csv I've discussed with Kresimir (Chris) 9A5K, the main developer of DXLog, who said, it can uses the csv, N1MM, or WinTest format, but he will make a file for next contest. Thanks for these guys, whom helped me (in alphabetical order): D4C DL1A HG5C P40W TI5W Please let me know, if you can use it, or have some problem! 73 on CONTEST, Ervin - HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TravisCI
Hi Thomas, On Thu, Jan 25, 2018 at 07:31:00PM +0100, Thomas Beierlein wrote: > Hi all, > > just for testing I set up a copy of TLF's code at > https://github.com/dl1jbe/test-travis . > > Atm it has a very simple setup: configure and build TLF without hamlib > support. You can check it out, provide a pull request and see > what happens. thanks - actually, I don't have any planned and not agreed code. I have the fltiny FSK integration branch, but it needs the xmlrpc-c library... 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] code indenting?
Hi Nate, On Thu, Jan 25, 2018 at 06:21:56AM -0600, Nate Bargmann wrote: > * On 2018 24 Jan 23:34 -0600, Thomas Beierlein wrote: > > I recommend astyle only for the fact that it can do some things GNU > indent does not. It works well for getting the variety of coding styles > found in the Hamlib code base somewhat close to what I want. I still go > through and hand massage the files a bit more. what's the "astyle"? Is it an another formatter, like GNU indent? > > - I further had a look into the Travis CI which integrates neatly with > > the github working flow. Maybe we should use it to do common checks > > on the code automatically. > > I'd not heard of this. More info, Tom? (I don't want to reply instead of Tom - I just near to my machine :)) https://travis-ci.org/getting_started https://github.com/marketplace/travis-ci You can set up in your any repository, that when a PR arrives, a hook will start a build flow (and/or a test list) before you merge the code. 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] code indenting?
Hi Zoli, On Wed, Jan 24, 2018 at 09:33:43PM +0100, Csahok Zoltan wrote: > Hi, > > Another topic: as the code has grown over the time and many authors > contributed to it the formatting is inherently not consistent. > > GNU indent is a powerful tool for C source formatting and present in any > modern Linux distro. We could define a common style simply by setting up > an .indent.pro file. > see http://www.gnu.org/software/indent/manual/indent.html#SEC4 > > I have no particular formatting preferences provided that tab size is 4. > Any suggestions? I know (superficially) the indent, and support to use it. I agree the 4 for tab size. I preference the -br (if I interpret it as right way), and no other expectation. Anyway, could be review the all possible options, and made a project file as you describe, with different setup. Then reformat the source tree with that, and compare the new format with the old one. The minimal difference wins. :) I'll try to do this at next days - but I'll wait Thomas's opinion. 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] tlf without hamlib?
Hi Zoli, On Wed, Jan 24, 2018 at 09:19:45PM +0100, Csahok Zoltan wrote: > Hi Ervin, hi Tom, > > Thanks for your replies. So, if there are no further objections > then I put making hamlib mandatory on the top of my list. > > In fact it seems that even xmlrpc is compiled in the packaged versions. > But that I would not touch now. the xmlrpc related code was my work - it necessary for the Fldigi interface (that's the Fldigi's "official" interface to communicate with external applications). I guess the most Tlf user compiles the binary from source, instead of use the packaged version of current distro. The Hamlib is - as you wrote - the de-facto RIG interface on Linux, so it should be a strict part of Tlf, I think not so much user wants to ignore it. But also I guess, the most user doesn't want to use the xmlrpc, so I'ld keep it as it now exists - just for your info. 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] tlf without hamlib?
Hi Zoli, On Tue, Jan 23, 2018 at 06:52:33PM +0100, Csahok Zoltan wrote: > Hi, > > Currently tlf has an optional hamlib support. I guess it's optional due > to historical reasons: hamlib may have been not always available or unstable > in the past. > Now hamlib is the de-facto standard rig control library for Linux. > A quick check of official debian tlf packages shows that in all versions > hamlib support is compiled in. it's just one distribution. There are several others, which contains Tlf, eg. Gentoo (maintainer is Thomas), SuSE, Slackware, Arch, and many others. > The question: could we make hamlib support mandatory? Interesting idea, and I don't know any other reason to do that, just what if there is a distro, which doesn't distribute the Tlf with hamlib. (After a quick search, in case of most distros I didn't find Tlf, or if the distro contains, that is a very old version of Tlf, eg. 1.1.3...) > The advantage of this change is that all code parts not using hamlib > could be disposed of (incl. #ifdef's). Functionally there should be no > drawbacks, > as rig control can be disabled with the -r option. Note, that you should disable the RIG control if you place a comment sig to the lines in logcfg.dat, before the RIG_ options. > What do you think? Is there a use case for tlf compiled without hamlib? I think we should do - but I'm curious about the opinions of other users. 73, Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] Was: CBR/adif import
Hi folks,
that wasn't an easy work... :) but looks like it works as well
now for QSO's.
There is an initial version of Cabrillo import:
https://github.com/airween/tlf/tree/readcabrillo
or
https://github.com/airween/tlf/archive/readcabrillo.zip
That works as very simple way at this time: you have to place the
CAB file to contest directory with your callsign, and ".cbr"
extension, eg:
HA2OS.cbr
Then you have to type:
tlf -c
(-c means "convert")
Be pation, after few seconds (it depends the number of QSO's) Tlf
will exit (give back the prompt), and you can find a new file in
the directory: IMPORT_contest.log, where the "contest" is the
name of logfile in your logcfg.dat.
I've tested with several contests, and it works as well with all
cases.
The feature has some limitations:
* because CAB format stores the freq value only in kHz, but Tlf
stores it 100Hz, it can't convert back the original QRG, eg.
the original was 7001.5, that in CAB file will 7001, and after
the import it will also 7001.0
* there isn't any feedback from Tlf till it works on files; I'll
make some interactive messages, which indicates that Tlf works
This test version only works for QSO (and X-QSO) cabrillo lines.
I will continue the work, and hope I can make it that QTC lines
also would be converted.
Please help me as you tests it with many contests as possible.
First, you have to make an import (start Tlf (*), type ":write"
to callsign field, ...), and import back, then compare the
results. Make a copy from your original logs, and copy the IMPORT
file as your log, and start Tlf - you have to see the original
points and multipliers.
*: you don't need to modify the logcfg.dat, if the RIG or cluster
has set up, just type:
tlf -r -n
then Tlf will neglect the RIG (-r) and cluster (-n / net).
Note, that you can check the differences with this way:
awk '{print substr($0,0,80)}' yourlog.log > origlog
awk '{print substr($0,0,80)}' IMPORT_yourlog.log > importlog
diff origlog importlog
Any feedback are welcome!
73,
Ervin
--
I � UTF-8
___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] CBR/adif import
Hi Fred, that was just a quick finger excercise :), and there is a "small" problem with the idea, but you can grab a small script to convert cabrillo format logs to Tlf format: https://github.com/airween/cbr2tlf/ This is a Python script, just run from anywhere, and pass the cabrillo PATH as argument. The script will save the converted format log to near the cabrillo. Eg. if your cabrillo is /home/fred/tlf/path/to/DH5FS.cbr then you have to run $ /path/to/cbr2tlf /home/fred/tlf/path/to/DH5FS.cbr and the result will be /home/fred/tlf/path/to/DH5FS.log. The "small" problem is the scoring. Anyway, the cabrillo doesn't stores the point(s) and multipliers, so the ideal solution would be convert program reads the rules, and sets the correct points and the multipliers. I think that we can't skip the Tlf, so I'll integrate this feature in the future. Now this script sets the points as 1 for all QSO, and ignores the multis. Hope that helps. 73, Ervin On Sat, May 27, 2017 at 10:28:38AM +0200, FS wrote: > No doubt, it would be .CBR We have a contest logger! I would like to use it > to switch logs between several programms. > > 73 Fred > > > Am 27.05.2017 10:00 vorm. schrieb Ervin Hegedüs <airw...@gmail.com>: > > > > Hi Fred, > > > > On Fri, May 26, 2017 at 09:46:29PM +0200, FS wrote: > > > Hi guys, is there any way to import a .CBR or .adif file? I never missed > > > it, but now.. > > > > I'm afraid that currently no such feature - but it's not so big > > work to implement. Which one would be better, CBR or ADI? > > > > > > 73, Ervin > > > > > > -- > > I � UTF-8 > > -- I � UTF-8 ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] CBR/adif import
Hi Fred, On Fri, May 26, 2017 at 09:46:29PM +0200, FS wrote: > Hi guys, is there any way to import a .CBR or .adif file? I never missed it, > but now.. I'm afraid that currently no such feature - but it's not so big work to implement. Which one would be better, CBR or ADI? 73, Ervin -- I � UTF-8 ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.3.0 major release
Hi Thomas, On Thu, Mar 30, 2017 at 07:15:21AM +0200, Thomas Beierlein wrote: > Hi all, > > just some progress report about the Savannah project site. > > In meantime we got a confirmation from Rein to hand over the site to > our group. Details how to do it are sorted out at the moment. > > I will report back, as soon as it is done. thanks for the info, 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.3.0 major release
Hi Thomas, On Sun, Mar 12, 2017 at 07:29:11PM +0100, Thomas Beierlein wrote: > > It would be nice if the nongnu site could be used since there is a > > project page there already to host the release tarballs. I wonder if > > the administrators would allow Tom to take over from Rein as > > administrator for the Savannah page. > > That is quite true, especially as it would also give us control about > the mailing list. And furthermore it would allow us to update the > describing page. Some years ago I asked Rein if he could hand it over to > us, but got no answer. > > So it seems we should try a direct contact to the nongnu people and ask > if and how it could be done. I you'll try, may be you'ld ask more person for admin (eg. Nate and/or me). 73, Ervin ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF-1.3.0 major release
Hi OM's, On Sun, Mar 12, 2017 at 08:54:25AM -0500, Nate Bargmann wrote: > * On 2017 08 Feb 00:02 -0600, Thomas Beierlein wrote: > > After a lot of work by all people contributing to TLF I would like to > > announce the release of the new TLF-1.3.0 version. > > > > You can find it at > > > > http://www.hs-mittweida.de/tb/tlf-1.3.0.tar.gz > > Tom, is this a permanent location that will be valid through future > releases? if yes, probably it would be good to enable the directory listing. I've made the Debian package, but I had to remove the watch file (which helps to checks the version checker the new release of an upstream source), because it needs to read all available versions. 73, Ervin -- I � UTF-8 ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
