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
Now I remember that actually our FD is setup is just like this: using a single USB-serial converter with RX/TX controlling the rig via hamlib and DTR doing keying via cwdaemon. We had no issues with it. The only thing is that at Tlf start-up the key is down for a second. I'll check hamlib config to see if this behaviour can be cured. Thanks Nate for the pointer. 73, Zoli On Fri, Nov 29, 2019 at 12:51:59PM -0600, Nate Bargmann wrote: > That's cool, Olaf. > > It stands to reason that the DTR and RTS lines would explicitly need to > be turned off as I think the kernel automatically enables them when an > application initializes the port. >
Re: pywinkeyerdaemon
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
Does anyone use CTCOMPATIBLE mode?
The reason I am asking this question is because I am comparing the present behavior of Tlf's CT mode to that of my CT ver 9 manual and the two do not match. Tlf does send F5 followed by F2 as described in the CT manual, but the F2 have different definitions between the two programs. If there are no complaints, I will change the code so the correct Tlf F key macro is sent for both and '+'. 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: Using hamlib for CW keying
D'oh! Read the man page, Nate! RIGCONF=rig_configuration_parameters Send rig configuration parameters to Hamlib. e.g. RIGCONF=civaddr=0x40,retry=3,rig_pathname=/dev/ttyS0 I plan to try this. 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: Using hamlib for CW keying
That's cool, Olaf. It stands to reason that the DTR and RTS lines would explicitly need to be turned off as I think the kernel automatically enables them when an application initializes the port. This was a more or less silly idea I had and I'm glad to see it will work! I'll have to try it too. I'll have to look at the Tlf code to see if config parameters can be passed to the library without going through tigctld. 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: Using hamlib for CW keying
I now have my K3 working with keying without any additional boxes like netkeyer, winkeyer or similar. Solution is fairly simple; 1. Install cwdaemon. Standard install uses parallell port for keying so to use eg a serial port you have to modify cwdaemon config file (resided in /etc/default). Had to set ttyS0 instead of parport0. cwdaemon seems to start on boot with the standard debian install. So to get cwdaemon to use serial port you need to restart; sudo service cwdaemon restart 2. Rig is controlled over same serial port. This seems to work fine as the rig communication only uses txd and rxd lines. But there is a catch. My standard install of hamlib triggered both dtr and rts lines and keyed the rig unless rigctld command was changed. To avoid this you need to ask hamlib to clear both the dtr and the rts lines. This can be done by giving rigctld the following options in addition; -C rts_state=OFF -C dtr_state=OFF. 3. On the K3 you need to enter the config menu and set the PTT-KEY entry to OFF-dtr. It seems the cwdaemon keying goes over the dtr line. If you want cwdaemon to control the ptt line, you would probably set this to rts-dtr. Not necessary with a K3 as it provides full break-in. The above works both with tlf and with cqrlog which is used for my main logging. And this solution fully accepts all speed change commands and tx stops from keyboard as it does not utilize the K3 internal keyer. So by this I have no need for tlf (or cqrlog) to use keying via hamlib as long as I use my K3. But my KX3 does not allow for keying via the dtr line so the solution will not work unless the dtr signal is routed via a transistor to the KX3 key input. A solution which can be used for most rigs I assume. So all in all, I do not have to prepare a nanokeyer/winkeyer or similar extra box. Thanks for responses which triggered me into finding a practical solution. PS: Have not tried this on a usb-serial converter, my serial port is a "real" serial port based on an UART 16550. But I note some usb-serial devices has brought out the dtr line, and I would assume that this can be made to work also on these. 73 de Olaf - LA3RK
