Re: padding in cwdaemon packets
Hi Drew and Zoli, Am Sun, 8 Dec 2019 17:51:12 +0100 schrieb Csahok Zoltan : > Hi Drew, > > Trailing zero and newline have most likely historical origin. > > The zero was introduced abt 9 years ago in this commit: > https://github.com/Tlf/tlf/commit/5a2be34d01b296bc8b8d8b362407cc3077e3c6d8#diff-8be0c8c50997da170641d3392ba81b5a At that time it was unclear if cwdaemon needed a the send message as a zero terminated string or not, so I added it to be sure. Actual it seems that it is not needed. We can revert that commit. 73, de Tom > Apparently cwdaemon needed it. Now it does not for sure, neither any > newline. It actually removes NL: > https://github.com/acerion/cwdaemon/blob/master/src/cwdaemon.c > (line 1140) > > winkeydaemon as a defensive measure silently ignores non-processable > characters. Probably cwdaemon (libcw) does the same. > > Technically the trailing NL is a result of not chopping it after > fgets(). While for CW it is irrelevant, it might make sense for > digital modes. Not sure, though, as digital keyer code could add NL > on its own. > > So all in all I think we could get rid of both trailing chars without > issues. > > 73, > Zoli > > > On Sat, Dec 07, 2019 at 04:35:28PM +, Drew Arnett wrote: > > 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 -- "Do what is needful!" Ursula LeGuin: Earthsea --
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: ARRL 160m
* 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 signature.asc Description: PGP signature
Re: padding in cwdaemon packets
Hi Drew, Trailing zero and newline have most likely historical origin. The zero was introduced abt 9 years ago in this commit: https://github.com/Tlf/tlf/commit/5a2be34d01b296bc8b8d8b362407cc3077e3c6d8#diff-8be0c8c50997da170641d3392ba81b5a Apparently cwdaemon needed it. Now it does not for sure, neither any newline. It actually removes NL: https://github.com/acerion/cwdaemon/blob/master/src/cwdaemon.c (line 1140) winkeydaemon as a defensive measure silently ignores non-processable characters. Probably cwdaemon (libcw) does the same. Technically the trailing NL is a result of not chopping it after fgets(). While for CW it is irrelevant, it might make sense for digital modes. Not sure, though, as digital keyer code could add NL on its own. So all in all I think we could get rid of both trailing chars without issues. 73, Zoli On Sat, Dec 07, 2019 at 04:35:28PM +, Drew Arnett wrote: > 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
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 >
ARRL 160m
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 signature.asc Description: PGP signature
