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