I have been trying to get my system up and running again. I just installed Mint Linux 12. The install and etc has gone well. So fart I like Mint Linux.
On to the issue. I have a Hamgadgets MasterKeyer MK-1. This unit emulates the WinKey. I have tested this in Windows and works fine. I have also followed the documentation on testing it in Linux.
Here is what they have you do:
1.) Open a Terminal window.
2.) Type the command: screen /dev/ttyxxxx 9600 (use the serial port name you discovered earlier).
3.) Hit ENTER; you should see a command prompt ( ?: )from the MK-1. If you type a question mark and hit ENTER, you should get the command menu.
4.) To exit the screen program, type Ctrl-A followed by a backslash (\).
This seems to work just fine.
Under CQRLOG, Here is what I did:
Open CQRLOG
Preferences
CW Tab
Select WinKey
Set port (/dev/ttyUSB1 is my setup)
test... No response
Suggestions?
Hi Will,
cqrlog uses 1200bd as serial speed to talk with WinKyer. Maybe this is the problem. I have no idea if MK-1 has any option to set serial port speed. If not, please let me know and I'll add option to cqrlog.
73 Petr, OK2CQR
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
No, the Master Keyer has no provision to set the baud rate but does auto-sense it. I've had no problems with using the MK-1 with CQRlog unless something accessed the serial port (using cutecom to set keyer memories while CQRlog is running. Oops!) and got things out of sync. In that case I restarted CQRlog and normal operation was restored. There should be no need to use screen as I prefer cutecom for MK1 access, although I need to remember to shut down CQRlog first.
Perhaps screen is not actually releasing the port or some other oddity? I would try it again after a reboot, verify the port name as with two or more ports plugged in, udev can name them in either order. One way to work around this is to switch off the MK1 until the system is started and turn it on just before starting CQRlog. I solved this through the use of udev rules to give unique names to the port the MK1 is on and the port the K3 is on based on the device (I have a Prolific converter feeding the K3 and the MK1 is an FTDI device). I can post my udev rules if anyone is interested.
Hi Nate,
I will look at Cutecom. I have not messed with this stuff much over the last couple of years. I am just getting back into it. I am not looked at udev rules. I am not familar with it. Can you shed some light on it? Also, what OS are you running?
TNX Will
Hi Will,
I am running Debian Sid (unstable) on the machine I use CQRlog on. Here are my rules:
$ cat /etc/udev/rules.d/00-local-usb-serial.rules
# local rules file for USB to serial converters
SUBSYSTEM=="tty", ATTRS{idVendor}=="0557", ATTRS{idProduct}=="2008", SYMLINK+="iogear"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0557", ATTRS{idProduct}=="2008", SYMLINK+="rig"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="mk1"
These rules can only differentiate between the Prolific (first two lines) and the FTDI (last line). If you have two of the same chipset, then a set of rules will need to be written that look at other differences--on board serial numbers (not all devices have them, the Prolific above doesn't) or port/hub the device is plugged into. There are many pages out there that discuss udev rules. All these rules do is create symbolic links to /dev/ttyUSB0 and /dev/ttyUSB1:
$ ls -l /dev/iogear
lrwxrwxrwx 1 root root 7 Feb 1 22:06 /dev/iogear -> ttyUSB0
$ ls -l /dev/rig
lrwxrwxrwx 1 root root 7 Feb 1 22:06 /dev/rig -> ttyUSB0
$ ls -l /dev/mk1
lrwxrwxrwx 1 root root 7 Feb 1 22:06 /dev/mk1 -> ttyUSB1
On some future system restart it may happen that the FTDI becomes /dev/ttyUSB0 and the Prolific becomes /dev/ttyUSB1. No matter as the rig/iogear and mk1 symlinks will point to the correct device. Thus rigctld is set to use /dev/rig and CQRlog is set to use /dev/mk1 for the CW port.
HTH, Nate >>
Hi Petr,
At least from what I have read, the MK-1 uses 9600. I was not sure what version of Linux Nate is using. I have only two devices on the /dev/ttyUSB*. USB0 is a FTDI cabled device and USB1 is the keyer. I am not sure if a port setting speed would help or not. As I had mentioned, I was able to access it with screen. I will look at cutecom and see what it says... I have not tried to program the keyer yet.
TNX Will WC2L
hello-- I too just got a master keyer, connected it today worked first try with CQRlog. using Ubuntu 10.04, CQRLog 1.3.0
but then it quit, so had to power cycle keyer, and reload cqrlog.
I think bringing up window/cw fx keys maybe breaks connection.
that window seems to do nothing, f keys wont work, until I quit window, they f keys work again.
Dan
Dan KC2STA