Re: ToDo item: switch logfile to database
I was ignoring the utility of SQL/RDBMS operations. (Am I misremembering or are there libs to do that with flat text "table" data structures already?) I like that sqlite "how to corrupt" article. It does point out very well that data safety isn't simply application level question/architecture/solution. Leaves me curious about some of the filesystem solutions vs database solutions; again, something I need to read more about. Maybe robustness/safety isn't a high priority for a contest logger, but I contest 99% of the time portable with portable power. A laptop with a good battery does have effectively a built-in UPS, but I like to use other compute solutions like RPis. (Maybe time to add battery UPS-like to my RPi setups?) tangent: Variable length fields are handled easily with line separators delimiting records and space, comma, tab delimiting fields in a record. It may be the UI (especially a TUI) where expected max field length may have value. For example, what's the maximum length callsign I might expect to encounter in a contest or operating event where I'd use tlf? Is there a safe maximum length to use for callsign length? Prefixes and suffixes and some of those special event callsigns make me wonder. Does ITU have anything to say, or is there no upper bound to possible callsign length? tangent: Internationalization... unicode text file for log certainly would work. ASCII would suffice for the contests I participate in including CQ WW. However, if not difficult, internationalization may be a nice to have for folks who would want it, but perhaps not high priority. Just checked the ITU international morse document; that does not have european diacritics or umlauts or anything extra. But there are of course wabun and cryllic and all sorts of internationalization variants to morse. Does anyone contest or do operating events with any of these extended morse character sets? Drew n7da
Re: ToDo item: switch logfile to database
Would a database store offer any useful utility? Journaling or ? for robustness? Power loss during portable contesting with a laptop or desktop or Pi or ? ... would be nice if no data loss and simple resumption after power is restored. Or is the choice of HW/OS/filesystem more useful for that sort of robustness? Or is KISS the best answer? Does it implement whatever is needed for multi-logging computer contesting? Knowing the answers to questions like that for me is a homework task as it gets into topics I haven't studied, yet. Drew n7da On Thu, Dec 28, 2023 at 2:57 PM Alan Dove wrote: > > Hey, folks: > > I'm opposed to having TLF rely on a database. It adds complexity and > failure points, and shouldn't be necessary for any forseeable contest > log. > > Users who want a tool to collect QSOs from multiple contests for > analysis, DXCC tracking, and so forth should use a separate > application. CQRLog does all that and more, and also exemplifies the > kinds of support problems a database can add - just browse through the > CQRLog forums for tales of woe from users who can't get the database > connection working properly. > > Networking should definitely be a higher priority. > > -- > --Alan > > Alan Dove, Ph.D. > alandove.com > 917.273.0544 > > >
Re: Few questions about tlf code
Another vote for 80 columns. I like to run tlf in an 80x25 or 80x24 console/monitor. If I want to edit on the same platform... Tabs vs spaces is always an interesting question. I guess so long as the tabs are all meant to be 8 char (or 4 or whatever the convention is for the project). Best regards, Drew n7da On Thu, Jul 6, 2023 at 11:45 AM Ervin Hegedüs wrote: > > 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: not1mm
I routinely write SW that runs on Windows and Unix. Python provides the portability that Java promised. :-) He does get a -1 for requiring one minor rev newer version of python than debian stable (at the moment.) :-O On Wed, May 17, 2023 at 12:18 PM Nate Bargmann wrote: > > * On 2023 16 May 09:07 -0500, Drew Arnett wrote: > > In the world of open source contest loggers, just saw this posted on > > reddit: https://github.com/mbridak/not1mm > > I do like his sense of humor, especially the Men Without Hats reference! > > > Cross platform for networked logging is definitely one thing I'm interested > > in. > > He does say that if on MS Windows, run away. > > 73, Nate > > -- > "The optimist proclaims that we live in the best of all > possible worlds. The pessimist fears this is true." > Web: https://www.n0nb.us > Projects: https://github.com/N0NB > GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 >
not1mm
In the world of open source contest loggers, just saw this posted on reddit: https://github.com/mbridak/not1mm Cross platform for networked logging is definitely one thing I'm interested in. Best regards, Drew n7da
Re: TLF - feature request
Interesting. I"ve used call history files (sometimes shared for various events on the N1MM files website). Nice to type in a callsign and have exchange fields prefilled using the call history, though I listen really closely to see that the information this year is the same or if something changed. (Some events seems to have a lot more changes vs past years in the exchange than others.) Definitely a fun feature to have in a contest logger. I hadn't thought about what you proposed, but it sounds like a great idea. Type in some uniquely identifying part of the exchange and then using a reverse lookup from the call history data have the callsign field prefilled. Nice. And I like the idea of showing multiple possibles just like SCP does when a partial callsign has been entered. +1 for trying out new ideas and innovations. Drew n7da On Thu, Mar 16, 2023 at 1:09 PM Martin Kratoska wrote: > > Hi Tom & al, > > a nice addition to the tlf would be the reverse call lookup. Assumed > that a Club contest where a part of exchange is the membership number > and the user has an initial exchage file, the membership number preceded > with a dedicated character (# in this example) written into Call field > will cause the Call field will be filled with the Call and the initial > exchange will appear as a prefill in the exchange field. > > It may seem unclear and complicated, better would be an example: > FOC Marathon (exchange is RST and Membership number), there is also an > initial exchange (present in the directory) like this: > ... > LA3FL,1480 > N2UU,1483 > SM6BGA,1484 > G4BUO,1486 > N4UB,1490 > VK6LW,1492 > OQ3R,1493 > K2SG,1494 > KN0V,1496 > ... > > When I hear exchange with membership number 1492 I can write #1492 into > Call field (# is the dedicated character), the text #1492 will be > replaced with call VK6LW when the dupe check is performed (with spacebar > or so). > > This can save sometimes a lot of time, namely when the contestant takes > the event more like a party than a contest, ie. his QSO is longer > because he gives out something more than a bare exchange. > > If more callsigns are assigned to a particular member (here VK6LW can be > also VK6T,1492) the first call (as ordered in the initial exchage file) > appears in the Call field and other (alternative) calls should appear in > the SCP list. > > Of course, a number WITHOUT the dedicated character should be > interpreted as frequency to that the radio should be tuned. Example: > 1833 typed into Call field should tune the radio to 1833 kHz, #1833 will > NOT tune but DJ4KW will appear in the Call field. > > Any ideas? > > 73, > Martin, OK1RR >
TLF publicity
I was delighted to see TLF in the California QSO Party results video. https://youtu.be/5OkXZqPYd_4?t=752 Drew n7da
TLF, open source contest logging SW, and contest logging SW future
I think asking what is in the future is a great question. Is it continued innovation and features for the top contesters? You know, the ones who need 2 or more radios to keep from getting bored during a contest and are doing 400+ QSOs/hour. Is there room for innovation for more average contesters like me? Is it some specific new feature or modification to tlf? I think it would be very interesting, and perhaps challenging, to try to compile a document describing all of the features everyone would want, even when those conflict. (It's software, and, within reason, I think it is good to accommodate different preferences different people have. Sometimes this can be done well in a single program; sometimes this means having several different programs. The open source ecosystem is a good example.) Writing a second product specification document from that would be interesting as well. Not going to tackle this myself, but would be fascinating reading. For me, the future of contest logging software is having an open interoperability specification for networking contest loggers. I think this is the highest priority. If we had it, then when operators get together for multi-op contesting (from Field Day or CQ WW), everyone can bring their own SW to use with whatever customization it has that suits their preferences. And can bring whatever operating system compute device as well. The src directory for tlf (in debian stable) looks to be about 35 KLOC (kilo lines of code). I wanted to find out how much python it would take to write a (like tlf) TUI contest logger. (And I wanted a vehicle for experimentation.) 1 KLOC was enough and not a lot of hours were required, either. This did *not* have assistance (spotting network), live score tabulation, mults needed, bandmap (that is no realtime analysis or guidance). This did have cwdaemon and rigctld client capability, serial number generation, highlighting when fields have valid content, country file, super partial, and call history support, dupe checking, macros, and enter-send-mode. The TUI API is so similar to a GUI API that porting to a GUI like Qt5 would be easy. And the TUI and python code should run cross platform as is. Yes, a large portion of the code is UI and UX. I think the only limitation is imagination or that requirements gathering and product specification exercise. (Networking is the only feature missing to either have my friends use my software or for my software to interoperate with N1MM or whatever they use when we get together for multi-multi contesting several times a year.) But still, I'd like to see an open interoperability specification for networking contest loggers even before an elaborate specifications doc. I'd be very interested to read what others think about the future for tlf and contest loggers in general on a large or small scale. And I"d find it very interesting to read about features and functionality people want or just want to try out. Fun stuff. Drew n7da
Re: What is the tlf future?
The error message told you exactly what was wrong. That the library rich was not installed. Don't worry; this is a common Python newcomer topic. rich isn't part of the standard library that comes with Python, so needs to be installed. (pypi.org is a large, but not exhaustive catalog of 3rd party libraries.) The ecosystem of 3rd party libraries are part of the magic of Python. A major rev of python 3.x will have a separate installation. Part of that installation is site-packages, a special location where 3rd party libraries are installed. (That is, anything not part of the python standard library. https://docs.python.org/3/library/index.html) pip, also a 3rd party library, is a great tool for installing them. If you're using a linux distro, the distro may have packages some of the 3rd party libs, so you can install them with a package manager or so that programs can require or recommend them. apt-get install python3-serial for example is something I'd do on any Debian box I use, because that is on a list of about 20 3rd party libraries I use almost every day for work and hobby. To make things more complicated for new Python folks, there are also virtual environments to hold 3rd party libraries in addition to site-packages. These are useful if you have version conflicts or a need to have specific versions (for pre-production release testing for example.) Learn the idea of site-packages first, then virtualenv. Many libraries are pure Python (written only in Python). Usually those are not a fuss. Other libraries have C/C++ code. It is challenging to write code as portable as Python, so this may or may not cause fun for portability. Library authors can publish pre-compiled libraries if you don't want to use the compilation portion of the installation tools. But, if there is a brand new major rev (3.x), it might be a few days or weeks before your favorite packages have binaries published. For those users who don't want to compile, may need to wait a bit after a major rev. I have been using Python for all things electrical engineering for 20 years now. It's still the most productive application programming language I've seen. (If you find one better, please let me know; I've been looking a long time.) And it dovetails with C/C++, systems programming languages, in several quite nifty ways if you need to drop down to that level for performance. There are some interesting possible new contenders for systems programming languages (2 that I can think of), but haven't seen one for application programming, yet. In 1995, Java promised several things. One was portability. Python actually has that level of portability folks hoped to see in Java. It's quite nice. I write software that folks can and do use on Mac, Windows, Linux, RPis, etc., without recompiling. The original direction of this thread I find quite interesting. It's not a simple little thing doing a serious contest logger. Fun stuff. Drew n7da On Mon, Oct 17, 2022 at 11:26 AM Ervin Hegedüs wrote: > > 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: How to add a contest?
Assuming you don't need TLF to calculate a score on the fly nor track multipliers worked or needed, can TLF work for you for these contests? Rather than trying to modify TLF to score or track multipliers worked or needed, I'd suggest writing a small second program to do that by watching/reading the log file. That'd be the least work overall I think. Best regards, Drew n7da On Sat, Oct 8, 2022 at 3:52 AM Martin Kratoska wrote: > > Some contests can't be added simply by modifying the GENERAL QSO > configuration. There are two as an example: > > Memorial OK1WC (MWC) - a very fast, 1 hour CW event which is highly > popular here in EU. It uses mults last character of worked station call > suffix. > > FOC MARATHON - no mults but a bonus based on bands where the station was > worked. > > How and where can be these contests added? > > 73, > Martin, OK1RR > > > > > == > > Detailed rules > > == > Memorial OK1WC (MWC) > > Mode:CW > Bands:80, 40m > Classes:Single Op All Band (QRP/Low) > Single Op Single Band (QRP/Low) > Max power:LP: 100 watts > QRP: 5 watts > Exchange:RST + Serial No. > Work stations:Once per band > QSO Points:1 point per QSO > Multipliers: Each last character of worked station call suffix once per > band > Score Calculation:Total score = total QSO points x total mults > > == > FOC MARATHON > > BANDS: 160, 80, 40, 20, 15, 10m. > > SECTIONS: > > QRO Open: Full licenced power on all bands with no antenna restrictions. > Low Restricted: Output power limited to 100w, simple wire and vertical > antenna only (no beams). > QRP Open: Output power limited to 5w with no antenna restrictions. > QRP Restricted: Output power limited to 5w with simple wire and > vertical antennas only (no beams). > > EXCHANGE: RST and membership number. > > CONTACTS: One QSO point for each member worked per band. > > NO MULTIPLIERS! > > BONUS POINTS: > > Five points for the first contact with each continent - AF, AS, EU, OC, > NA, SA. (30 max) > Two points for the first contact with each country (DXCC). > Ten points for contacts on five bands with a member. > Five additional points for a contact on a sixth band with that member. > The UK based HQ station - G4FOC (GM4FOC, GD4FOC etc.) or an alternative > notified call, scores double points for contacts and five/six band bonus > points. > > TOTAL SCORE = > > Total members worked plus... > Total entities worked X 2 plus... > Total continents worked X 5 plus... > Total 5 band contacts X 10 > Total 6 band contacts X 5 >
Re: Winkeydaemon Help
More details, please. :-) Maybe enough for someone to reproduce or at least figure out what is going on? Which winkeydaemon? (I know of at least 3 different programs to provide a cwdaemon interface to WinKeyer.) It should be possible for muting to work, in theory at least. My implementation works with the WInKeyer sidetone turned on or off. Best regards, Drew n7da On Mon, Aug 29, 2022 at 3:36 PM Ed wrote: > > My winkeyer is version 3. > > The -s switch has no effect on the speed, so using the pot is not > possible. > > The -m switch works as far as muting the speaker sidetone. but results > in sending pure jibbersh. Without the switch the speaker is back on and > keying is normal. > > Any work arounds or suggestions ? > > Ed W3NR >
Re: winkeydaemon
So, what hardware device are you trying to use? A USB serial adapter? Something else? (Non-USB serial ports won't have USB in the device filename.) Regardless, should show up in dmesg during boot time. On Mon, Aug 8, 2022 at 7:33 PM Ed wrote: > > I got the file packaged and made it executable.Not that hard to > copy/paste. > > But: > > stty: /dev/ttyUSB0: No such file or directory > Died at /home/ed/bin/winkeydaemon line 242. > > I found no /dev/ttyUSB0 which is hard to believe. > > Ed W3NR >
Re: winkeydaemon
How did you install that? With your distro's package manager or some other way? If some other way, what was it? If you have the file tool installed (https://manpages.debian.org/stretch/file/file.1.en.html), what does 'file /home/ed/bin/winkeydaemon' say? Best regards, Drew n7da On Mon, Aug 8, 2022 at 2:08 PM Ed wrote: > > On Mon, 8 Aug 2022 03:43:16 -0500 > Nate Bargmann wrote: > > > > Hi Ed, > > > > Then the ./ is not required. In essence, the ./ tells the shell to > > run the command that is found in the current directory and to look > > nowhere else. > > > Hope that helps. > > > > 73, Nate > > I put the winkey daemon in /home/ed/bin, this is the output: > > /home/ed/bin/winkeydaemon: line 8: syntax error near unexpected token > `newline' > /home/ed/bin/winkeydaemon: line 8: `' > > Ed >
Re: Mint 21
Try running it not at boot, not as a daemon, but run it in the foreground launching it by hand instead to see if any of the debugging messages help. I've never seen tlf fail to send to cwdaemon; perhaps share the uncommented line(s) you have for netkeyer in your tlf config? Could try one of the other cwdaemon client programs just to double check to see if the problem is cwdaemon or client config. You could use netcat to send a udp packet to cwdaemon. https://github.com/acerion/cwdaemon/blob/master/README#L227 And when you say cwdaemon doesn't talk to tlf, can you be very specific on the symptoms you see? Good luck! Drew n7da On Sat, Aug 6, 2022 at 6:47 PM Ed wrote: > > I have everything set so far. Except for one problem,cwdaemon does not > talk to tlf. Nothing. Also have the same on Fedora36. > > So any ideas. I have cwdaemon starting at boot. > > Works fine on Mint 20.3 > > Thanks > > Ed W3NR >
Re: CWdaemon
/dev/ttyUSB0 maybe? Check the device file. dmesg will tell you if nothing else. Does cwdaemon have a verbose flag to turn on debugging messages? On Thu, Jul 14, 2022 at 10:44 PM Ed wrote: > > New install of Fedora36, I used the repository for TLF and cwdaemon. > > I copied my TLF contests from my backup. > > Now I cannot get cwdaemon to work, I use this to start it:: > > cwdaemon -d ttyUSB0 -x n > > Suggestions or ideas ? > > Thanks > > Ed W3NR >
TXDELAY used?
Hi, I was looking at the cwdaemon 'd' command which controls delay for PTT. Looks like TLF only uses at startup to configure this with a config file entry: TXDELAY (Turn On Delay) control for cwdaemon. The value of TOD from logcfg.dat is sent to the keyer at startup. Value range is 0 ... 50 ms (0 switches PTT off completely) Does anyone use this? Seems like this is better as a cwdaemon configuration item rather than something I'd be inclined to do through cwdaemon clients. Note: I am not asking for any changes to tlf. Was just considering whether or not to implement 'd' in my own cwdaemon implementation. (Up to now, I do not, but do provide warning that client tried to use.) I checked a couple of other loggers available in debian and looks like they do not use the 'd' command. Thanks and best regards, Drew n7da
Re: why 25 rows?
Thanks, gang! Drew n7da On Thu, Feb 25, 2021 at 4:48 PM Thomas Beierlein wrote: > > Hi Drew, hi Christoph, > > Am Thu, 25 Feb 2021 17:04:52 +0100 > schrieb Christoph Berg : > > > Re: Drew Arnett > > > Dumb question: why 25 rows? Sorry for asking first, before > > > examining code. > > > > I think you can start with more rows and then resize to 20 rows and it > > still works. The restriction seems to remain from the time where > > resizing the window wasn't supported. (With less rows things start to > > overwrite each other.) > > > > Christoph > > > > Totally correct. Old display code was optimized for a fixed 25 line > layout. You would loose the bottom line with a 24 line display. > > For a year or so we support vertical resizing and the bottom line is > always shown. So the warning about 25 lines should go in next release. > > At the moment the only negative point with less than 25 lines is the > smaller space for the bandmap. > > 73, de Tom > > > -- > "Do what is needful!" > Ursula LeGuin: Earthsea > -- >
why 25 rows?
Hi, Dumb question: why 25 rows? Sorry for asking first, before examining code. Is there a design to the screen layout? Why I bring up the question... The official Raspberry Pi 7" screen with the closest linux console font that I found (didn't search for more options) ends up at 24 rows instead of 25. Old video terminals were often 24 rows. The old IBM PCs were 25 rows. I recall terminal emulator SW on those providing 24 rows for terminal use and a 25th row for menu. I love TUI for contest logging. I love turning off the GUI desktop (X, wayland, whatever) for it, too. So, linux console I think is great. Maybe I should review the linux console fonts bundled with debian to make sure I didn't miss something or look to see if it is possible to install additional ones. Thanks and best regards, Drew n7da
Re: IC-7610
Thanks. Wasn't clear to me from this thread. Yet another cwdaemon compatible interface for WinKeyer USB in python: https://github.com/drewarnett/pywinkeyerdaemon I use that with tlf for CW keying and just plain vanilla hamlib that's bundled with my linux distro, debian, for CAT for tlf. Drew n7da On Mon, Jan 11, 2021 at 2:27 PM Hegedüs Ervin wrote: > > Hi Drew, > > On Mon, Jan 11, 2021 at 02:15:00PM +, Drew Arnett wrote: > > Does hamlib support keying through the CAT serial port device? > > yes, take a look to this (especially in case of Python3): > > https://github.com/Hamlib/Hamlib/blob/master/bindings/py3test.py#L88 > > or you can use it through "rigctl" with "-b" (if the RIG supports > it, of course) > > > Does TLF support that, too? > > not - but I think that's why Juanjo uses winkeyerd. > > > 73, Ervin > HA2OS >
Re: IC-7610
How is this supposed to work when it is all setup and running? Does hamlib support keying through the CAT serial port device? Does TLF support that, too? On Mon, Jan 11, 2021 at 11:28 AM 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. > = == > > Otherwise, with $ sudo apt install python-libhamlib2 runs without problem. > > I have made a new video, you can see that things are the same. > https://youtu.be/-IElZwiiYJE > > Best regards, > Juanjo > > El lun, 11 ene 2021 a las 10:55, Ervin Hegedüs () escribió: >> >> 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: IC-7610
Are you trying to key the 7610 directly via its USB? Or do you have a USB keyer adapter you are using between the PC and the 7610? (something like the K1EL WinKeyer USB or one of the others) Drew n7da On Sun, Jan 10, 2021 at 8:49 PM Juanjo EA8BGO wrote: > > 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: TLF and Hamlib 4 - things to look for
Dumb question: Can some of this be avoided by running rigctld and then pointing tlf to the daemon? They didn't change the network protocol for rigctld, did they? Best regards, Drew n7da On Wed, Dec 16, 2020 at 5:48 AM Thomas Beierlein wrote: > > Hi all, > > if you want to play with the new Hamlib 4 release candidates for > TLF there are some points to remember: > > 1. Hamlib 4 has changed the scheme for rig numbers to make room for more > new rigs. Please have a look with 'rigctl -l', find your new rig > number and adapt logcfg.dat accordingly. > > 2. IMPORTANT! Hamlib 4 has a different program API than the versions > before. So any time you switch from Hamlib 3 to 4 (or maybe back) you > have to recompile TLF to adapt to the other API. > > Afterwards TLF should be able to work with your rig as before. > > 73, de Tom DL1JBE > > -- > "Do what is needful!" > Ursula LeGuin: Earthsea > -- > >
Re: tlf comments after CQP
Hi Jim, Too bad I didn't work you during the contest. (QRP, 9 hours, I didn't log that many QSOs.) Yes, I also didn't get it to score mults, but that was OK by me. Would have been simple to whip up something to do that if I needed. If you're interested, I have a tiny program that will calculate your score for this test from the tlf raw log. Nice thing is tlf got the points scoring correct for ssb, cw, and dupes if I had cwpoints and ssbpoints set to 3 and 2. For SO2R, you had two instances of TLF running. Did you network the two? Did each instance run it's own sequence of serial numbers or did they manage to work together? (Not sure what CQP allows or requires in this regard.) I haven't tried SO2R, yet, myself. Best regards, Drew n7da On Mon, Oct 5, 2020 at 1:01 PM jim smith wrote: > > Hi Drew, > > Thanks for your input. I also had questions about how to get tlf set > up for this contest. In the end, I made a multiplier file with all the > counties, and added a format line to cabrillo.fmt line. It wouldn't > score the mults during the contest, but wrote them correctly in the > cabrillo file, which is all I was really concerned with. > > I love tlf, and am woking on using it for SO2R. Basically, I'll have a > computer hooked up to each radio, but send the xterm of one to the > other so they're both on the same monitor. > > 73, Jim KK0U > > On Sun, 4 Oct 2020 23:23:24 + > Drew Arnett wrote: > > > Hi, > > > > I used TLF for the CQP (California QSO Party) yesterday from San Diego > > county. (Debian stable tlf package version 1.3.2-1) > > > > Worked fairly well. Would be nice to have 2 entry boxes to tab > > between for serial and qth (mult) instead of one, but it was workable. > > > > I used an initial file which held QTH (mult) as well as super partial. > > The only thing that wasn't so hot was that when I'd enter the serial > > (and made sure QTH sent matched the initial), sometimes it would > > revert the serial to blank or to the serial it had prefilled from > > earlier QSO when I used ESM to finish the Q. Not sure on the details > > of how and why, yet. Haven't played with it at home after the event > > to better understand. > > > > So, that's the feedback. > > > > I love TLF. Love using it from linux console. I was running QRP off > > of battery all day long. I didn't want to run a laptop off the > > battery as well at 40 or 80 W. That just seems like a mismatch. So, > > setup a Raspberry Pi 2 B which was the lowest power consumption model > > from what I could find. Used the official Pi display & case. > > > > Peripherals were: > > Elecraft's USB serial adapter for CAT > > Winkeyer USB > > generic USB to PS/2 adapter with old IBM model M keyboard > > NO MOUSE! :-) > > > > 12 to 5V was using Powerwerx USB Buddy. (I hoped it would be RFI > > free.) > > > > On the bench, this drew 0.4 A off of a bench 13.8 V supply. Wow, nice > > match with a 5 W QRP rig! > > > > Linux console, default font, and a cardboard box for a sunshield. > > Glare wasn't bad unless my light t-shirt was lit up by the sun. (I > > was trying to stay in the shade.) > > > > And, the model M with it's curly PS/2 cable, still is prone to RF on > > 40m. I had to use a snap on ferrite choke for 40m even QRP. > > > > I actually prepped a folder with tlf config files and database files > > and pywinkeyerdaemon ahead of time on a regular PC. Checked it out, > > make a git repot, and then copied onto the Pi. Nice. > > > > Best regards, > > > > Drew > > n7da > > > >
tlf comments after CQP
Hi, I used TLF for the CQP (California QSO Party) yesterday from San Diego county. (Debian stable tlf package version 1.3.2-1) Worked fairly well. Would be nice to have 2 entry boxes to tab between for serial and qth (mult) instead of one, but it was workable. I used an initial file which held QTH (mult) as well as super partial. The only thing that wasn't so hot was that when I'd enter the serial (and made sure QTH sent matched the initial), sometimes it would revert the serial to blank or to the serial it had prefilled from earlier QSO when I used ESM to finish the Q. Not sure on the details of how and why, yet. Haven't played with it at home after the event to better understand. So, that's the feedback. I love TLF. Love using it from linux console. I was running QRP off of battery all day long. I didn't want to run a laptop off the battery as well at 40 or 80 W. That just seems like a mismatch. So, setup a Raspberry Pi 2 B which was the lowest power consumption model from what I could find. Used the official Pi display & case. Peripherals were: Elecraft's USB serial adapter for CAT Winkeyer USB generic USB to PS/2 adapter with old IBM model M keyboard NO MOUSE! :-) 12 to 5V was using Powerwerx USB Buddy. (I hoped it would be RFI free.) On the bench, this drew 0.4 A off of a bench 13.8 V supply. Wow, nice match with a 5 W QRP rig! Linux console, default font, and a cardboard box for a sunshield. Glare wasn't bad unless my light t-shirt was lit up by the sun. (I was trying to stay in the shade.) And, the model M with it's curly PS/2 cable, still is prone to RF on 40m. I had to use a snap on ferrite choke for 40m even QRP. I actually prepped a folder with tlf config files and database files and pywinkeyerdaemon ahead of time on a regular PC. Checked it out, make a git repot, and then copied onto the Pi. Nice. Best regards, Drew n7da
Re: can we benefit from N1MM's UDC files?
Conceptually interesting idea. I'd suggest a separate project/tool/application. One that could fetch the UDC content (it's on the net afterall) and output appropriate TLF config file(s) or appropriate TLF config file(s) template(s). Would want to see if the UDC stuff is under the same or different license than N1MM itself. IIRC, N1MM is open source, no? And piggybacking is a great force multiplier in open source. Drew n7da On Thu, Dec 19, 2019 at 9:45 AM Joop Stakenborg wrote: > > N1MM has a large collection of so called UDC (User Defined Contest) > files, see: > > https://n1mmwp.hamdocs.com/mmfiles/categories/userdefinedcontests > > They are packed into a zip file which contains a udc file with a > description of the contest, but there are also member lists and other > stuff. The udc files contains contest and scoring information. I have > looked into it quickly and at first it seems complicated but I am sure > it is well documented and there also seems to be a dedicated editor for > udc files (in exe format of course). > > We could benefit from this large library, although I don't know what the > licensing issues might be when including them with tlf. > > > Just a thought, > > 73 de Joop PG4I > >
Re: pywinkeyerdaemon
I removed the echo test, too. There is an option in K3NG keyer, OPTION_WINKEY_STRICT_HOST_OPEN that tripped up the echo test I had in the wrong part of the sequence. Arguably, K3NG with that option behaves the way I would expect based on the K1EL documentation. The winkeyer I have (which returns version code 30) apparently isn't strict. I dug out my old homebrew K3NG keyer shield and programmed an Arduino. Yes, I was able to reproduce the problem Joop reported. Looks like K3NG flushes the buffer on a 'cancel buffered speed change' command. I need to read K3NG source to understand the details of why it is implemented this way. winkeyer doesn't. Which is correct? Who am I to say? Understanding the root cause, now, I can modify the pywinkeyerdaemon source to workaround this K3NG keyer bug. Better to do that or to write a patch for K3NG or both? Workaround involves using the 'buffered speed command' indefinitely. I had thought that would be appropriate to use for just a single message. Maybe not. Hmm. Best regards, Drew n7da On Sun, Dec 8, 2019 at 4:30 PM Drew Arnett wrote: > > Two issues: > 1. I expanded prosigns after inserting the +++ --- speed control > statements. Whoops. Fixed that. > 2. I had an echo test after host open. Not sure why I did that, > other than I must have been in a hurry. Haven't changed that yet, but > commenting it out in the code helped Joop during some early > troubleshooting, so I may make that change after reviewing the > winkeyer documentation. This is likely keyer implementation specific. > (I've been testing with an hamcrafters winkeyer USB, but should dig > out my old Arduino K3NG implementation.) > > I suspect between the two, Joop's problem should be fixed. Will > continue to follow up per his test report. I especially need to do > something about #2 above. > > Besides +++ --- and a complete cwdaemon compatible prosign > implementation, I added tune capability as well to pywinkeyerdaemon, > so ALT-T works from tlf now. Looks like tlf does a 6 second timeout > for tune, cwdaemon supports 0 to 10 seconds, and winkeyer 0 to 99. I > guess how long is too long varies wildly depending on the situation! > :-O :-) ALT-T would have been great to have yesterday when I was > dealing with a fussy autotuner. > > Best regards > > Drew > n7da > > On Sat, Nov 30, 2019 at 4:29 AM Drew Arnett wrote: > > > > I'll trouble shoot this with Joop off list. Shouldn't be related to > > the type of serial port, but we will see. First step was a better > > assertion statement that would provide the value that failed to match. > > Good sign that the code got that far before throwing an error. Will > > be looking at K1EL docs, as that test came from there IIRC. > > > > Drew > > n7da > > > > On Fri, Nov 29, 2019 at 8:18 PM Joop Stakenborg > > wrote: > > > > > > Hi Drew, > > > > > > > > > is pywinkerdaemon intended to work with USB ports? I get: > > > > > > $ ./pywinkeyerdaemon.py -d /dev/ttyUSB1 -p 6788 > > > Traceback (most recent call last): > > >File "./pywinkeyerdaemon.py", line 310, in > > > winkeyer = Winkeyer(args.device) > > >File "./pywinkeyerdaemon.py", line 43, in __init__ > > > self.host_open() > > >File "./pywinkeyerdaemon.py", line 57, in host_open > > > assert self.port.read(1).decode() == test_char > > > AssertionError > > > > > > > > > Joop PG4I > > > > > > Op 26-11-19 om 00:44 schreef Drew Arnett: > > > > Finally knocked off some todos including porting to python3. (still > > > > runs on 2 as well) > > > > > > > > Also, finally added in message +/- controls (tested with TLF) and > > > > support for cwdaemon prosigns. (I hadn't been using these sorts of > > > > things, so hadn't missed them personally, but they've > > > > been on the TODO list too long.) > > > > > > > > +++TEST--- doesn't work unless there's a setspeed first. (I didn't > > > > find that function in the winkeyer interface.) In testing, I found > > > > that tlf sends a setspeed command at startup, so no problems. > > > > > > > > https://github.com/drewarnett/pywinkeyerdaemon > > > > > > > > Best regards, > > > > > > > > Drew > > > > n7da > > > > > > >
Re: ARRL 160m
Tabbing back to the callsign field to ESM my call (S) or resend their exchange info (run) seems fine to me. Enter in the exchange field logging it and all even before exchange is sent and confirmed (S) is a bit optimistic maybe, but in S, not a big penalty to delete that logged entry if the band dropped out or QRM or something meant the QSO didn't get completed. Don't need to do that most of the time. Drew n7da On Sun, Dec 8, 2019 at 5:48 PM Nate Bargmann wrote: > > * On 2019 08 Dec 10:07 -0600, Drew Arnett wrote: > > I played for a couple of hours with the 160m contest as well from a > > very noisy location, so not very many QSOs. Worked a big gun east of > > the Mississippi, but no KG4 for me. :-) Didn't consult with Nate for > > rules or config file. Just grabbed the distributed arrl160m_usa rules > > and merged a bit from my own files from the last contest. > > Like I noted, this KG4 was a 2x1 in VA so no GITMO for me either. > > > I worked a couple of stations during auto CQ, and the rest in S > > Messages and ESM both worked great. I guest operated at another > > station for a bit during CQ WW. They weren't using ESM. Wasn't bad > > using the function keys, but I missed ESM as someone how can touch > > type. > > For me, using ESM in S is a bit disconcerting as when Enter is pressed > after receiving the running stations exchange, the QSO is logged before > my exchange is even sent, let alone confirmed. This is why I did a bit > of work so that in CT mode the Enter key only logs the QSO when both > fields have something it them. > > My S sequence was as follows: > > :CFG and uncomment CTCOMPATIBLE in logcfg.dat, Tlf reloads and resets > the configuration. > > Type in the running station's call. > > Press F6 to send my call. > > Type in his exchange, if DX only a signal report is sent so type a space > character in the exchange field, otherwise ARRL section is typed. > > Press Alt-1 which is set to "TU +5NN- KS" (I left F3 set to "@ +5NN- KS". > > Press Enter once he sends TU or CFM or whatever. > > > > Out of that sequence, what I would consider changing would be if the > exchange field is empty that Enter sends mycall (F6), similar to ESM. > > I would also consider changing Insert to send the S_TU_MSG macro > instead of F3. To go along with this would be enabling a notion of CQ > and S in CT mode so the messages sent would be mostly the same as ESM, > but with different keystrokes and with Enter logging when there are > characters in each field. > > Also, in S, having the + key send "TU" then log was awkward as > convention seems to prefer the S station to send "TU exchange" these > days. > > > I've noticed that clear the call field behavior of the ESC key as > > well. If there is an alternate behavior that makes sense and doesn't > > make ESM worse, I'd love to consider it. It is slightly annoying, but > > I didn't fret over it too much, as I figured it was good practice for > > short term callsign memory. If getting a fill is taking time, it > > might push the limits of my short term memory, though. > > My short term memory is working hard enough being two to three > characters behind his sending! Losing the callsign just because he > decided to start sending his call again a few milliseconds after I fired > the exchange macro and wanting to stop it to get back in sync with him > is annoying. > > I could imagine ESC working like this: > > If the callsign and exchange fields have characters in them, ESC works > just as now but stopping the TX and successively clearing the fields on > additional presses. > > If the callsign field has characters and the exchange field is empty > with the cursor in either, then ESC stops TX. The second press would > clear the callsign and make sure the cursor is in the callsign field. > > The tricky part is, what if there is no TX, I think the current behavior > is to clear the fields immediately, exchange then callsign on successive > presses. > > Since this would be new behavior, it's likely that it should be disabled > by default and enabled with a keyword command as many are probably used > to the current behavior. > > 73, Nate > > -- > > "The optimist proclaims that we live in the best of all > possible worlds. The pessimist fears this is true." > > Web: https://www.n0nb.us > Projects: https://github.com/N0NB > GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 >
Re: pywinkeyerdaemon
Two issues: 1. I expanded prosigns after inserting the +++ --- speed control statements. Whoops. Fixed that. 2. I had an echo test after host open. Not sure why I did that, other than I must have been in a hurry. Haven't changed that yet, but commenting it out in the code helped Joop during some early troubleshooting, so I may make that change after reviewing the winkeyer documentation. This is likely keyer implementation specific. (I've been testing with an hamcrafters winkeyer USB, but should dig out my old Arduino K3NG implementation.) I suspect between the two, Joop's problem should be fixed. Will continue to follow up per his test report. I especially need to do something about #2 above. Besides +++ --- and a complete cwdaemon compatible prosign implementation, I added tune capability as well to pywinkeyerdaemon, so ALT-T works from tlf now. Looks like tlf does a 6 second timeout for tune, cwdaemon supports 0 to 10 seconds, and winkeyer 0 to 99. I guess how long is too long varies wildly depending on the situation! :-O :-) ALT-T would have been great to have yesterday when I was dealing with a fussy autotuner. Best regards Drew n7da On Sat, Nov 30, 2019 at 4:29 AM Drew Arnett wrote: > > I'll trouble shoot this with Joop off list. Shouldn't be related to > the type of serial port, but we will see. First step was a better > assertion statement that would provide the value that failed to match. > Good sign that the code got that far before throwing an error. Will > be looking at K1EL docs, as that test came from there IIRC. > > Drew > n7da > > On Fri, Nov 29, 2019 at 8:18 PM Joop Stakenborg > wrote: > > > > Hi Drew, > > > > > > is pywinkerdaemon intended to work with USB ports? I get: > > > > $ ./pywinkeyerdaemon.py -d /dev/ttyUSB1 -p 6788 > > Traceback (most recent call last): > >File "./pywinkeyerdaemon.py", line 310, in > > winkeyer = Winkeyer(args.device) > >File "./pywinkeyerdaemon.py", line 43, in __init__ > > self.host_open() > >File "./pywinkeyerdaemon.py", line 57, in host_open > > assert self.port.read(1).decode() == test_char > > AssertionError > > > > > > Joop PG4I > > > > Op 26-11-19 om 00:44 schreef Drew Arnett: > > > Finally knocked off some todos including porting to python3. (still > > > runs on 2 as well) > > > > > > Also, finally added in message +/- controls (tested with TLF) and > > > support for cwdaemon prosigns. (I hadn't been using these sorts of > > > things, so hadn't missed them personally, but they've > > > been on the TODO list too long.) > > > > > > +++TEST--- doesn't work unless there's a setspeed first. (I didn't > > > find that function in the winkeyer interface.) In testing, I found > > > that tlf sends a setspeed command at startup, so no problems. > > > > > > https://github.com/drewarnett/pywinkeyerdaemon > > > > > > Best regards, > > > > > > Drew > > > n7da > > > > >
Re: ARRL 160m
I played for a couple of hours with the 160m contest as well from a very noisy location, so not very many QSOs. Worked a big gun east of the Mississippi, but no KG4 for me. :-) Didn't consult with Nate for rules or config file. Just grabbed the distributed arrl160m_usa rules and merged a bit from my own files from the last contest. I worked a couple of stations during auto CQ, and the rest in S Messages and ESM both worked great. I guest operated at another station for a bit during CQ WW. They weren't using ESM. Wasn't bad using the function keys, but I missed ESM as someone how can touch type. I've noticed that clear the call field behavior of the ESC key as well. If there is an alternate behavior that makes sense and doesn't make ESM worse, I'd love to consider it. It is slightly annoying, but I didn't fret over it too much, as I figured it was good practice for short term callsign memory. If getting a fill is taking time, it might push the limits of my short term memory, though. Best regards, Drew n7da On Sun, Dec 8, 2019 at 3:35 PM Nate Bargmann wrote: > > Well, first off, the use of cwdaemon and Tlf via Hamlib on the same > serial port (real motherboard port) worked perfectly without a problem > throughout my operating time. I missed Saturday evening due to having > aggravated my hip yesterday and had to lay down. I was up around 0830z > this AM and worked a bit over an hour and had to lay down for a while > and then again from about 1140z to 1420z or thereabouts. The hip is > feeling batter! > > My CT changes didn't get used much as I saw I had Alt-1 set for the > exchange I wanted to send in S mode so that I didn't have to edit the > F3 message all the time. Making sure that Enter didn't log an > incomplete contact did prove useful in the wee hours... > > ESM mode for running worked perfectly. > > Combining Escape to halt the CW message and clearing the input fields is > a double edged sword. When there is text in the call and exchange > fields and the cursor is in the exchange field and a CW message is in > progress, the first ESC stops the TX and the second clears the exchange > field and the third clears the call field. This is fine so far as it > goes. When the call field has characters in it and the cursor is in the > call field and the exchange field is empty, a single ESC stops the TX > AND clears the call field! That led to several ARGH! moments. I think > that a better algorithm could be worked out. > > Scoring is completely wrong but ARRL 160 is difficult to score. Tlf > several times counted an incorrect multiplier. For one I worked a KG4 > in VA and Tlf scored it as the KG4 mult when it should have determined > that the VA meant it was conus. Another time or two I fat fingered an > exchange and removed the text from the mult column but even a :RES > command had no apparent effect. Also, it seemed as though coming back > from an :EDI command resulted in Tlf forgetting any previous dupes even > though they're marked as zero points. > > In the end, the main thing is that the Cabrillo file is correct and ARRL > will take care of the scoring. > > Overall, I enjoyed using Tlf again. > > 73, Nate > > -- > > "The optimist proclaims that we live in the best of all > possible worlds. The pessimist fears this is true." > > Web: https://www.n0nb.us > Projects: https://github.com/N0NB > GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 >
padding in cwdaemon packets
Doing some debugging and cleanup of my pywinkerdaemon implementation of cwdaemon. (I introduced some bugs with recent feature introduction.) A few years ago, I looked at the UDP packets several different cwdaemon clients sent. Some, like TLF, send a single trailing null character which is not needed. Some sent quite a lot. (Allocated a max UDP data structure, wrote nulls, then wrote the message to the beginning. Still, should have not bothered transmitting all that padding.) Looking at tlf as included in debian 10.2 today, I see it also has a \n (0x0a) character between the end of the CW message and the single null character. I recommend that tlf doesn't transmit either the 0x0a or the 0x00 trailing characters. Unless this would break other independent cwdaemon implementations. Anybody know? Best regards, Drew n7da
Re: pywinkeyerdaemon
I'll trouble shoot this with Joop off list. Shouldn't be related to the type of serial port, but we will see. First step was a better assertion statement that would provide the value that failed to match. Good sign that the code got that far before throwing an error. Will be looking at K1EL docs, as that test came from there IIRC. Drew n7da On Fri, Nov 29, 2019 at 8:18 PM Joop Stakenborg wrote: > > Hi Drew, > > > is pywinkerdaemon intended to work with USB ports? I get: > > $ ./pywinkeyerdaemon.py -d /dev/ttyUSB1 -p 6788 > Traceback (most recent call last): >File "./pywinkeyerdaemon.py", line 310, in > winkeyer = Winkeyer(args.device) >File "./pywinkeyerdaemon.py", line 43, in __init__ > self.host_open() >File "./pywinkeyerdaemon.py", line 57, in host_open > assert self.port.read(1).decode() == test_char > AssertionError > > > Joop PG4I > > Op 26-11-19 om 00:44 schreef Drew Arnett: > > Finally knocked off some todos including porting to python3. (still > > runs on 2 as well) > > > > Also, finally added in message +/- controls (tested with TLF) and > > support for cwdaemon prosigns. (I hadn't been using these sorts of > > things, so hadn't missed them personally, but they've > > been on the TODO list too long.) > > > > +++TEST--- doesn't work unless there's a setspeed first. (I didn't > > find that function in the winkeyer interface.) In testing, I found > > that tlf sends a setspeed command at startup, so no problems. > > > > https://github.com/drewarnett/pywinkeyerdaemon > > > > Best regards, > > > > Drew > > n7da > > >
Re: Using hamlib for CW keying
Hamlib is great and really achieved a lot. Very neat what clients can do with that library for sure. But, all in one solutions sometimes get, um, interesting. cwdaemon defined a protocol. So, anyone can write a replacement, that tlf and others, can use. And they have. cwdaemon itself doesn't support every type of keying hardware. Nor did some of the alternatives that implemented the protocol. On my todo list is to read the hamlib rigctld protocol to see if it is a candidate for the same approach. No, I don't think hamlib should go away or anything like that. But, to do something custom, like have an application listed to the cwdaemon and rigctld ports and wring what it can from the KX3 or K3 CAT protocol might be interesting. Or something along those lines. Sounds like someone has already tried something along these lines. Interesting stuff. Drew n7da ps. A couple of years ago, when I looked at the cwdaemon protocol, I also looked at the packets generated by several different client applications. Some send more data than the protocol requires, and cwdaemon doesn't complain. IIRC, all had trailing nulls, some a single null byte and some several. So, I reported that in debug mode: https://github.com/drewarnett/pywinkeyerdaemon/blob/master/pywinkeyerdaemon.py#L126 On Wed, Nov 27, 2019 at 8:45 AM Nate Bargmann wrote: > > Thanks for that, Olaf. > > Here is a crazy idea I had that someone might like to experiment with. > I thought of using a serial port multiplexer, assuming such a thing > exists and I found https://github.com/danielinux/ttybus as one of the > first hits, to have Hamlib and cwdaemon share the same port. For the K3 > and other radios that don't use hardware handshaking, this may work > well. cwdaemon keys CW via the DTR pin and the K3 can be configured to > key CW via DTR or RTS. In theory, since Hamlib and cwdaemon use > different pins, this should work. > > Another idea is to not bother with a multiplexer and just direct Hamlib > and cwdaemon to the same port and see what happens! So far I've not > tried this hare-brained idea myself... > > 73, Nate > > -- > > "The optimist proclaims that we live in the best of all > possible worlds. The pessimist fears this is true." > > Web: https://www.n0nb.us > Projects: https://github.com/N0NB > GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 >
pywinkeyerdaemon
Finally knocked off some todos including porting to python3. (still runs on 2 as well) Also, finally added in message +/- controls (tested with TLF) and support for cwdaemon prosigns. (I hadn't been using these sorts of things, so hadn't missed them personally, but they've been on the TODO list too long.) +++TEST--- doesn't work unless there's a setspeed first. (I didn't find that function in the winkeyer interface.) In testing, I found that tlf sends a setspeed command at startup, so no problems. https://github.com/drewarnett/pywinkeyerdaemon Best regards, Drew n7da
Re: TLF-1.4.0 release
Agreed. I wouldn't enforce any more minimum than now. Warning makes sense. But, I can't anticipate someone doesn't have a use case where they want to use a smaller terminal. On Mon, Nov 25, 2019 at 7:16 PM Thomas Beierlein wrote: > > Am Sat, 23 Nov 2019 18:30:01 -0600 > schrieb Nate Bargmann : > > > * On 2019 23 Nov 08:14 -0600, Drew Arnett wrote: > > > Resize is fine, but please continue to support 80x25 long term. I > > > don't see classic TUI losing value anytime soon. > > > > Do you mean that Tlf should enforce a minimum 80x25 terminal size as > > it has in the past? Personally, I've no problem with that. > > 'Enforcing' is a little bit difficult as (as far as I know) we can not > force a minimum size on any xwindow. But I will leave the warning in > place that you should have at least 25 lines in your terminal. > > > > > What about a 2nd application, tlf-config or easy-tlf-config, which > > > would have the pulldown menus etc for setting up config files. Keep > > > the pulldown menus out of tlf. Once you add menus, you'll add a > > > bunch of hotkeys. One of the nice things about TLF is that there > > > aren't a bunch of live keys, especially if run out of a console or > > > terminal rather than a windows manager. > > > > That's actually a very good idea, Drew. If such a program were to > > gain good enough coverage then the :SET and :CFG commands could just > > call it instead of an editor. As for hot keys, Tlf does have quite a > > few assigned already. > > > Ok, I really like these idea. I will add it as an alternative to > the ToDo entry for the configuration menu. > > 73, de Tom > > > > -- > "Do what is needful!" > Ursula LeGuin: Earthsea > -- >
Re: Support for K3NG Arduino keyer
What Tom said should work fine. I wrote a third implementation myself: https://github.com/drewarnett/pywinkeyerdaemon (On my TODO list for this week is to publish a python3 update!) I used it with a K3NG keyer originally. I moved later to a K1EL WinKeyer. To use any of these, just configure TLF to use cwdaemon, start one of these up instead of cwdaemon, and start TLF. (Yes, starting it by hand maybe isn't a real daemon.) It works great. Ask if you have any questions or problems. Best regards, Drew n7da On Sun, Nov 24, 2019 at 3:50 PM Thomas Beierlein wrote: > > Hi Andy, > > there are some UDP clients controlling K1EL like keyers (and also the > K3NG). See the mailing archive from just last week. There was a > discussion about it. > > From memory: > > - There is Winkeydaemon at Nate's N0NB github account > https://github.com/N0NB/winkeydaemon and > > - a second one is the Winkeyer USB server (see > https://www.cqrlog.com/node/149) > > I have a K3NG like nanoKeyer myself and use it with Winkeydaemon. > > 73, de Tom DL1JBE > > Am Sun, 24 Nov 2019 20:33:13 +0500 > schrieb Andy : > > > Hi everyone, > > > > Can I configure TLF to use K3NG Arduino keyer or cwdaemon is only > > available cw keying device? > > > > Thanks, > > > > 73, > > > > Andy 9a3jh > > > > On 11/23/19 10:00 PM, tlf-devel-requ...@nongnu.org wrote: > > > Send Tlf-devel mailing list submissions to > > > tlf-devel@nongnu.org > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > https://lists.nongnu.org/mailman/listinfo/tlf-devel > > > or, via email, send a message with subject or body 'help' to > > > tlf-devel-requ...@nongnu.org > > > > > > You can reach the person managing the list at > > > tlf-devel-ow...@nongnu.org > > > > > > When replying, please edit your Subject line so it is more specific > > > than "Re: Contents of Tlf-devel digest..." > > > > > > > > > Today's Topics: > > > > > > 1. Re: tlf and the nano editor (Drew Arnett) > > > > > > > > > -- > > > > > > Message: 1 > > > Date: Sat, 23 Nov 2019 14:32:53 + > > > From: Drew Arnett > > > To: tlf-devel@nongnu.org > > > Subject: Re: tlf and the nano editor > > > Message-ID: > > > > > > Content-Type: text/plain; charset="UTF-8" > > > > > > Zoli's idea is the first thing I thought of, too. But the suggested > > > method of using EDITOR from tlf config as first priority, then > > > falling back on the shell environmental variable as 2nd priority I > > > think would be better. I could image someone preferring some > > > editor for most of their usual work, but wanting a different one > > > for use from tlf. For example, I might usually use gvim, but want > > > to use vim from tlf. So, EDITOR=gvim in the shell, and EDITOR=vim > > > in the tlf config file. > > > > > > Best regards, > > > > > > Drew > > > n7da > > > > > > On Sat, Nov 23, 2019 at 2:30 PM Nate Bargmann > > > wrote: > > >> * On 2019 23 Nov 01:18 -0600, Csahok Zoltan wrote: > > >>> My 2c: try with "export EDITOR=..." > > >> Hi Zoli, > > >> > > >> This is the setting in log_cfg.dat that I am testing with Tom's new > > >> patch to allow specifying any editor, not a shell variable. > > >> > > >> 73, Nate > > >> > > >> -- > > >> > > >> "The optimist proclaims that we live in the best of all > > >> possible worlds. The pessimist fears this is true." > > >> > > >> Web: https://www.n0nb.us > > >> Projects: https://github.com/N0NB > > >> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 > > >> > > > > > > > > > -- > > > > > > Subject: Digest Footer > > > > > > ___ > > > Tlf-devel mailing list > > > Tlf-devel@nongnu.org > > > https://lists.nongnu.org/mailman/listinfo/tlf-devel > > > > > > > > > -- > > > > > > End of Tlf-devel Digest, Vol 188, Issue 25 > > > ** > > > > -- > "Do what is needful!" > Ursula LeGuin: Earthsea > -- > >
Re: tlf and the nano editor
Zoli's idea is the first thing I thought of, too. But the suggested method of using EDITOR from tlf config as first priority, then falling back on the shell environmental variable as 2nd priority I think would be better. I could image someone preferring some editor for most of their usual work, but wanting a different one for use from tlf. For example, I might usually use gvim, but want to use vim from tlf. So, EDITOR=gvim in the shell, and EDITOR=vim in the tlf config file. Best regards, Drew n7da On Sat, Nov 23, 2019 at 2:30 PM Nate Bargmann wrote: > > * On 2019 23 Nov 01:18 -0600, Csahok Zoltan wrote: > > My 2c: try with "export EDITOR=..." > > Hi Zoli, > > This is the setting in log_cfg.dat that I am testing with Tom's new > patch to allow specifying any editor, not a shell variable. > > 73, Nate > > -- > > "The optimist proclaims that we live in the best of all > possible worlds. The pessimist fears this is true." > > Web: https://www.n0nb.us > Projects: https://github.com/N0NB > GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 >
Re: Using hamlib for CW keying
Portable is good. So I'd ask if hamlib found it possible to support speed changes. KX3 is only 3 wire serial CAT interface, so no RTS/DTR style keying possible. In that case, I suppose a Y cable could be fabricated that fans out RTS/DTR to a separate key plug. That's a bit tidier perhaps. Another difference between rigs. Some have a jack for paddles and a jack for key. KX3 doesn't, so I like using the external WinKeyer box to let logging software and paddles key the rig. Using the WinKeyer box means I'll have a common solution regardless of which rig I end up using. (Operating at home, operating at someone else's station, FD and other situations where the gear is an assortment from all the participants, etc.) Another bonus using a WinKer (or equivalent) is that the paddle input then pauses any sending, too. However, recently during contests, I've been better about using CTRL-K to do fills instead of reaching for the paddles. I'm still too green to know which method of keying for fills I will ultimately end up preferring. Best regards, Drew n7da On Fri, Nov 22, 2019 at 10:19 PM Nate Bargmann wrote: > > * On 2019 22 Nov 14:31 -0600, Csahok Zoltan wrote: > > Hi Christian, > > > > Yes, keying does work with the script. But as far I can see > > there are two issues with hamlib keying: > > > > - in-band speed changes are not supported. one can't send "+++TEST---" > > > > - sending a large message could block rig interface until it gets queued. > > > > Given the rig protocol (KY command) and the way hamlib supports it > > I see no option to circumvent these. > > > > WinKeyer on the other hand offers in-band speed change and winkeyerdaemon > > provides the buffering for a cwdaemon compatible UDP interface. > > > > Correct me if I'm wrong here. > > You may well be correct, Zoli. As I recall, a speed change would > require sending the proper CAT command each time the change is made. > It's possible this could be done in a manner that doesn't mess up the > timing of the sent Morse, I think it would likely be very rig specific. > > One thing the K3 and the later models can do is be keyed via the RTS/DTR > line and N1MM+ takes full advantage of that, speed changes and all. > Problem is whether more rigs support that and whether Hamlib supports > it. Even though I've been a part of the Hamlib project for quite some > time, I'm not sure! There may be some provision but probably needs some > debugging. Again, this is a feature that is rig specific. > > 73, Nate > > -- > > "The optimist proclaims that we live in the best of all > possible worlds. The pessimist fears this is true." > > Web: https://www.n0nb.us > Projects: https://github.com/N0NB > GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 >
Re: TLF-1.4.0 release
Resize is fine, but please continue to support 80x25 long term. I don't see classic TUI losing value anytime soon. What about a 2nd application, tlf-config or easy-tlf-config, which would have the pulldown menus etc for setting up config files. Keep the pulldown menus out of tlf. Once you add menus, you'll add a bunch of hotkeys. One of the nice things about TLF is that there aren't a bunch of live keys, especially if run out of a console or terminal rather than a windows manager. Best regards, Drew n7da On Fri, Nov 22, 2019 at 2:17 AM Nate Bargmann wrote: > > Some items to add to your list, Tom. > > - Send Morse via Hamlib for radios that support it. > > - Rework the voice keyer so that Esc could stop the voice keyer. This >is another feature that I found in N1MM+ that is welcome. At the >moment the voice file is passed to a script so once that happens Tlf >loses control. Perhaps even something as simple as getting the PID >of the script, if possible, and killing it directly. This may have >unintended side effects so would require much testing. Another >thought is to deliver the file to ALSA or Pulse Audio directly and be >able to stop playback at will. > > - WISHLIST: Incorporate some method of pull-down menus for >configuration. Doing so might encourage more use of Tlf? I don't >know if that amount of work would be productive or not. I'm certain >it can probably generate a lot of discussion. ;-) > > - WISHLIST: Along with the above, move away from log_cfg.dat and the >rules files toward configuration through the UI and a common config >file that doesn't require hand editing. > > - WISHLIST: Rework the curses UI to avoid the 80x25 hard coded screen >size. I've looked into this a time or two and doing this won't be >easy but is probably required for enough screen estate if menus are >to be implemented. At the least, more vertical screen space could >show more log lines or DX spots, for example. > >Given that Tlf is likely to be used on a later distribution under X >or Wayland with a terminal emulator, an 80x25 limit is a bit >restrictive. OTOH, I set up an Xterm such that it is 80x25 with a >nice big font that works well. Even modern distributions use a frame >buffer on the console that is larger than 80x25. > > The last three items are "down the road", likely a 2.0 release or even > later. There is plenty of time for discussion on these. > > 73, Nate > > -- > > "The optimist proclaims that we live in the best of all > possible worlds. The pessimist fears this is true." > > Web: https://www.n0nb.us > Projects: https://github.com/N0NB > GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 >
Re: Using hamlib for CW keying
When you ask for keying by hamlib, you are asking for keying via CAT, correct? (I would have to look to see if hamlib supports anything besides the CAT port on rigs, like the key line.) I wrote a python application that acts like cwdaemon listening on a network socket, and drives a USB to key adapter (K1EL WinKeyer USB). I need to push a python3 version of that to github. (I plan to do over next week's holiday.) That works great, but I have been thinking about trying keying from the CAT port. It might work great functionally. Reducing cabling would be a benefit. But, I'll probably keep the ability to use a key line interface for playing with HB or old rigs. On my todo list was to look at the hamlib server mode. It will talk to a network server version of itself, no? So, that might be an interesting way for me to insert my own application. Would still need to have TLF modified to use hamlib for keying, though. Alternatively, for fun, my application could use CAT for keying, but it could present both a hamlib socket interface for CAT and a cwdaemon interface for keying. This could work with existing TLF. Please point me to Ervin's Python 2 script or send me a copy. Chances are good that I can port it to Python 3 for you. (I routinely deal with the socket and pyserial issues that 2to3 doesn't automagically fix.) Best regards, Drew n7da On Thu, Nov 21, 2019 at 11:31 AM Christian Treldal wrote: > > Hi guys > > First I want to thanks the developers for the new ver. 1.4.0 > > A year or something ago Ervin wrote a quick Python2 script for keying > via hamlib. It has n > > 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. > > > 73 de OZ1GNN > > -- > Med venlig hilsen > > > Christian Treldal > "Remember Darwin; building a better mousetrap merely results in smarter mice." > >
Re: log edit
Very good! Thanks. Drew n7da On Sun, Nov 10, 2019 at 6:48 PM Thomas Beierlein wrote: > > Hi Drew, > > thanks for the bug report. > > I can confirm the problem. I got already fixed in last autumn, but as > it seems there was no official bug fix release afterwards. > > So either pick up the actual sources from github and compile it > yourself or wait for the shortly coming TLF-1.4.0 version. > > 83, de Tom DL1JBE > > > Am Sun, 10 Nov > 2019 17:34:51 + schrieb Drew Arnett : > > > The recent discussion reminded me of an issue I hadn't reported, yet. > > > > Not sure when, but recent versions of tlf using plain vanilla Debian > > stable fail to return to tlf after a ':edit'. It does take me out to > > the editor, but when I exit the editor, it give me the following error > > message as it crashes out: > > > > tlf: background_process.c:88: start_background_process: Assertion > > `stop_backgrnd_process == 1' failed. > > > > It was not and is not a high priority for me, as I just start up tlf > > again. It's fairly infrequent I need to go back to the log and > > correct something after I've logged it. If I had to do it every 10 > > QSOs, then, yes, it would be more of a hassle. > > > > I haven't submitted a ticket to the issue tracker; I can if you would > > like. I also haven't dug in to try to debug, either, because, again, > > it hasn't been a big problem. > > > > I didn't work a huge number of QSOs, but tlf did great for me, as > > always, with the recent ARRL SS CW contest. > > > > Best regards, > > > > Drew Arnett > > n7da > > > > -- > "Do what is needful!" > Ursula LeGuin: Earthsea > -- >
log edit
The recent discussion reminded me of an issue I hadn't reported, yet. Not sure when, but recent versions of tlf using plain vanilla Debian stable fail to return to tlf after a ':edit'. It does take me out to the editor, but when I exit the editor, it give me the following error message as it crashes out: tlf: background_process.c:88: start_background_process: Assertion `stop_backgrnd_process == 1' failed. It was not and is not a high priority for me, as I just start up tlf again. It's fairly infrequent I need to go back to the log and correct something after I've logged it. If I had to do it every 10 QSOs, then, yes, it would be more of a hassle. I haven't submitted a ticket to the issue tracker; I can if you would like. I also haven't dug in to try to debug, either, because, again, it hasn't been a big problem. I didn't work a huge number of QSOs, but tlf did great for me, as always, with the recent ARRL SS CW contest. Best regards, Drew Arnett n7da
Re: [Tlf-devel] TLF run mode problem
PBKAC as I suspected. (Why would I be the only one with a problem
with such basic functionality.)
The indicator in the upper left hand corner is 'Log' for run mode and
'S' for search and pounce. OK. The source code made that obvious.
Ugh. For some reason I was thinking 'Log' was a 3rd mode. My bad.
Of course, something that obvious I wasn't going to figure out during
the contest. :-O Modified my F3, exchange, message to be '@ 5NN 6'
instead of '5NN 6'. Enter send mode works fine then for S and run
mode.
So, I think I'm good (enough) for the NAQP CW test this weekend. I
may setup one of the blank F-keys to be a report without @, but should
be fine.
I could nitpick a tiny detail here or there, but patches/pull requests
would probably be more of interest. :-) As is, works good enough.
Bonus points for tlf being packaged in debian and being a TUI (text
user interface) program with no mouse input! :-)
Thanks for your patience and help.
Best regards,
Drew
kb9fko
On Thu, Aug 1, 2019 at 7:08 PM Ervin Hegedüs wrote:
>
> 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
Thanks for digging in, Ervin. I will look at that pull request. Another difference in my case is that I'm using my pywinkeyerdaemon with a K1EL (www.hamcrafters.com) 'WinKeyer USB'. https://github.com/drewarnett/pywinkeyerdaemon (One diff though, as I need to update it for the later python-serial lib; timeout is now set by attribute, not method. I also need to publish a python3 version!) Interrupting auto_cq to respond would involve sending a message to NETKEYER/cwdaemon. Maybe my implementation has a subtle, problem causing difference? I'll either examine my code versus what cwdaemon does or just install the standard cwdaemon and see if there is any difference. I've also finished the experiment where I installed buster on the hard disk and tlf and my config files. The problem still exists. So, maybe that confirms that it is not the same problem pull 84 fixed. I will pursue my idea regarding NETKEYER/cwdaemon/pywinkeyerdaemon both by experiment and by reviewing cwdaemon and pywinkeyerdaemon source. I would be interested in hypothesis or suggestions for what I may try. Thanks and best regards, Drew kb9fko On Thu, Aug 1, 2019 at 6:38 AM Ervin Hegedüs wrote: > > 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
I just tried a fairly new desktop hard disk (less than a year old) with an older USB 2.0 to SATA adapter. I put my local working directory there (logcfg.dat, rules, cty, partials, log), and the same bad behavior persists. Will install buster to hard disk (not via USB adapter) and see how that behaves. Thanks and best regards, Drew kb9fko On Thu, Aug 1, 2019 at 1:26 AM Drew Arnett wrote: > > I just subscribed to the tlf-devel list, so I should get those emails > in my mailbox now. (I was using the archive web page.) > > I will respond to Ervin and Tom's emails. Tom's first. > > Yes, your assumption is correct. I am using CW. NETKEYER works great! > > Yes, the bad behavior is reproducible. > > I tried CQWW (see below), but maybe if someone can provide config > files, I can try that. > > Now, Ervin's. > > Yes, I'm running with live on RAMDISK which should be faster than SSD. > I can install buster on a rotating disk drive and try that out to see > if it makes a difference. What specifically is being accessed on disk > that might cause a race condition? If it is something in the working > directory where I have my config files and log file, I could get that > onto a rotating disk drive without spending as much time and try that. > But, if it is say /tmp or the file system with the binary or > libraries, then I'll have to do the OS install. I will try both and > let you know. And, when I used TLF late last winter, I may have been > running off of a rotating hard disk, but I don't remember for sure. > > To try CQWW, I modified the files I provided earlier in this way: > - > cp -R iaru2019 blah > vi blah/rules/iaru > diff --recursive blah/rules/iaru iaru2019/rules/iaru > 1,2c1,2 > < CONTEST=cqww > < LOGFILE=cqwwlog.txt > --- > > CONTEST=iaru > > LOGFILE=iarulog.txt > - > and have the same problem behavior unfortunately. Do you have config > files that I could try? > > I also reproduced Ervin's use of a dummy rig. I used 'rigctld -m 1' > to provide a rigctl daemon serving a dummy rig. I used used 'rigctl > -m 2' and 'F 14002000' and exited that client to set the VFO on the > dummy rig. I then modified logcfg.dat to change RIGMODEL=2 and > RIGPORT=localhost. When I started tlf, it connected to the dummy rig > as evidenced by the different VFO value. Unfortunately, still the > same bad behavior. > > More details on the package installed per your request: > - > user@debian:~$ apt-cache show tlf > Package: tlf > Version: 1.3.2-1 > Installed-Size: 945 > Maintainer: Debian Hamradio Maintainers > Architecture: amd64 > Depends: libc6 (>= 2.15), libglib2.0-0 (>= 2.35.9), libhamlib2, > libncursesw6 (>= 6), libtinfo6 (>= 6), libxmlrpc-core-c3 > Recommends: sox, xplanet > Description-en: console based ham radio contest logger > Tlf is a console (ncurses) mode general purpose CW/VOICE keyer, logging and > contest program for hamradio. > It supports the CQWW, the WPX, the ARRL-DX , the ARRL-FD, the PACC and the > EU SPRINT contests (single operator) as well as a LOT MORE basic contests, > general QSO and DXpedition mode. > It interfaces with a morse code generator, your sound card, a number of > radios, > and with a DX Cluster. > Tlf can project cluster data into the excellent Xplanet program, written by > Hari Nair. > Contest operation mimics the popular TR-Log program for DOS, the output file > is TR- as well as CABRILLO compatible. The user interface was designed with > over 30 years of experience in CW contesting. > The program was written for console mode on purpose, to make it run also on > smaller machines, or remotely via a modem link. > This version of Tlf supports the new native Fldigi interface for digital > modes. > Description-md5: 4b4480a32b343c7aeca3161e12ba7877 > Homepage: http://tlf.github.io/ > Tag: uitoolkit::ncurses > Section: hamradio > Priority: optional > Filename: pool/main/t/tlf/tlf_1.3.2-1_amd64.deb > Size: 357000 > MD5sum: 229818b440314c79bba5a7a30349ce8f > SHA256: 6682f1694d1f060f7d8265c484468a88903efdcc45caad6ae7108eef92ad96bd > > user@debian:~$ apt-cache showpkg tlf > Package: tlf > Versions: > 1.3.2-1 > (/var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-amd64_Packages) > (/var/lib/dpkg/status) > Description Language: > File: > /var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-amd64_Packages > MD5: 4b4480a32b343c7aeca3161e12ba7877 > Description Language: en > File: > /var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_i18n_Translation-en > MD5: 4b4480a32b343c7aeca3161e12ba7877 > > > Reverse Depends
Re: [Tlf-devel] TLF run mode problem
and best regards,
Drew
kb9fko
On Wed, Jul 31, 2019 at 8:18 PM Ervin Hegedüs wrote:
>
> 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
[Tlf-devel] TLF run mode problem
Hi, I tried using the tlf packaged with Debian buster for the IARU HF contest. I had a problem with trying to operate in run mode. I've used TLF and been very happy with it in the past. Love the leanness. Love the keyboard only operation. I think I've used run mode before, but not much I think. I could not get it to work this time. Observed behavior: S works fine. Enter send message works as expected. Type in his callsign in the callsign box and then hit enter and TLF sends my callsign. Type in his exchange and hit enter in the exchange box and TLF sends TU and my exchange and logs the QSO. Great! Run mode has problems. Start auto CQ which works fine. As soon as I start typing in a callsign, the auto CQ stops and the "AUTO_CQ" marker in the upper left corner changes to "S". (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. Am I doing something wrong? Do I have something misconfigured? Is it a bug in the SW? Or if this should work, and it was a mistake in debian packaging deltas, should I file a debian bug? My setup... OS: debian buster live 10.0.0 xfce TLF (and hamlib) - user@debian:~$ dpkg --list | grep tlf ii tlf1.3.2-1 amd64console based ham radio contest logger user@debian:~$ dpkg --list | grep hamlib ii libhamlib2:amd64 3.3-5 amd64Run-time library to control radio transceivers and receivers - Debian packaging info: https://packages.debian.org/buster/tlf https://packages.debian.org/buster/libhamlib2 I have a directory I'm running tlf from (no command line options). - $ ls -lR .: total 548 -rw-r--r-- 1 user user 191309 Jul 13 12:28 8316241.gif -rw-r--r-- 1 user user 264631 Jul 11 02:05 callmaster -rw-r--r-- 1 user user 79308 Jun 30 23:52 cty.dat -rw-r--r-- 1 user user176 Jul 13 14:33 iarulog.txt -rw-r--r-- 1 user user 4010 Jul 13 14:15 logcfg.dat -rw-r--r-- 1 user user 7926 Jul 13 12:13 pywinkeyerdaemon.py drwxr-xr-x 2 user user 80 Jul 13 14:19 rules -rw-r--r-- 1 user user101 Jul 13 14:39 tlfmarkers ./rules: total 4 -rw-r--r-- 1 user user 2136 Jul 13 14:18 iaru - Descriptions of files: .gif is downloaded ITU zones and regions map callmaster is downloaded partials cty.dat is downloaded dxcc iarulog.txt is my logfile logcfg.dat attached pywinkeyerdaemon.py is my cwdaemon server rules/iaru attached tlfmarkers tlf temp file for bandmap if I understand correctly I've attached logcfg.dat and rules/iaru but here they are inline. logcfg.dat - RULES=iaru EDITOR=vim CALL=KB9FKO TIME_OFFSET=0 NETKEYER NETKEYERPORT=6789 NETKEYERHOST=127.0.0.1 CWSPEED=20 CQDELAY=3 RADIO_CONTROL RIGMODEL=229 RIGSPEED=38400 RIGPORT=/dev/ttyS0 BANDMAP=S,900 # skipdupes, 900s livetime SCOREWINDOW CHECKWINDOW PARTIALS SUNSPOTS=30 SFI=100 NOB4 MARKERS=tlfmarkers - rules/iaru - CONTEST=iaru LOGFILE=iarulog.txt CONTEST_MODE F1=CQ DE % TEST F2=% F3=5NN 6 F4=TU F5=@ F6=% F7= F8=AGN F9=? F10=QRZ? F11= F12=CQ DE % TEST # CQ_TU_MSG=TU % S_TU_MSG=TU 5NN 6 ITUMULT RECALL_MULTS - Thanks you and best regards, Drew Arnett kb9fko logcfg.dat Description: Binary data iaru Description: Binary data ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
