At least Fedora updates offer now HamLib version 4.0
With that installed user must change rig model number. It is not same as it was before.
If you use rigctld that starts from crontab or elsewhere (I.E. from command line) change the "- m" number. You get list of models with command :
rigctld -l
For example IC7300 has "-m 373", with HamLib 4.0 it is "-m 3073"
Emulation rigs model "-m" less than 10 have not changed.
If you start rigctld from cqrlog just go to Preferences/TRXControl and reselect your rig model from drop down selector.
When rigctld starts (in command console) it offers:
Recommend using --vfo switch for rigctld if client supports it
rigctl and netrigctl will automatically detect vfo mode
Cqrlog does not support that, so do not use "--vfo". the only change needed is rig model number change.
Hello CQRLOG,
thanks for the hint about Hamlib 4.0 in distribution "Fedora".
I'am not using "Fedora" personally. I like to use "Mint 19.3 Tricia x86_64"
First: be warned! This is not for common distribution users! Just experimental stuff!
Thanks for reading and understanding!
The new thing with Hamlib 4.0 is: use "Device by ID" - no need for udev rules, /dev/ttyUSBxxx stuff etc.!
Okay, "Device by ID" is not new but was limited to 99 letters (Hamlib 3.1 in Mint 19.3 - year 2017).
And of course, a lot of rigs are integrated now and are improved, errors fixed and so on. Some things are fixed after YEARS of waiting!
Whats up with this device-thing?
/dev/tty/USBxxx is changed every reboot, "Device by ID" is unique!
Have a closer look:
Normally you start CQRLOG with rigctld (out of cqrlog or using a script before starting CQRLOG).
The main problem was to guess the rig and the serial port.
For example: Icom 9700. (It is the same with Elecraft Serial-USB-Adapters). Let's check the serial port:
ls -la /dev/serial/by-id/usb-Silicon_Labs_CP2102*
lrwxrwxrwx 1 root root 13 Mai 3 16:40 /dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_IC-9700_00000000_A-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Mai 3 16:40 /dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_IC-9700_00000000_B-if00-port0 -> ../../ttyUSB2
Count the letters of the device! >99 chars. Not Possible with Hamlib <4.x !!
And also CW using Hamlib 4.0 is now working without timing issues anymore. Great!
Therefore you have an unique ID out of the system (working as normal user!) and no other stuff is needed anymore.
Also errors are fixed (for older and newer rigs!)
Please use "/dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_IC-9700_00000000_A-if00-port0" instead of "/dev/ttyUSB1" or any static udev-rules etc.
Many thanks Saku for this small hint.
Hopefully other distribution maintainers also understand this and implement a stable Hamlib 4.x version into there distribution.
Just my 2ct.
73 de Martin, DL1MTG
--
73 de Martin, DL1MTG
@dl1mtg, Thans for hint, very useful. In my Ubuntu 18.04 /dev/ttyUSB0 in time to time chages to /dev/ttyUSB0. This solution resolve my problem.
Thanks Martin !
Device by id removes the need of making udev rule that has been the way tho ignore problems with ttyUSB# number changes.
How ever udev rule has worked very well making /dev/cwkeyer, /dev/rig and /dev/icom7300 always available without worry about ttyUSB numbers.
Ilttle bit same system has been used with Arduino IDE (and some other programs) for some time. Problem with them is that they find devices by them self and are ignoring user made symlinks like /dev/Arduino. Everything would be ok, but if you use cheap Chinese products they all have same device id and same device serial. Maybe some of device parameters have a little difference and using that user symlinking is posible to use to separate devices.
With only device IDs it sometiems fails when using several devices based to same (cloned) chips. I hope this does not happen with main brands of rigs.
I did not study v 4.0 more, just tested that it runs with cqrlog (is backward compatible). Maybe there are also other new useful features.
RTFM should be done when time permits , hi :-)
--
Saku
OH1KH
Hi Saku,
one big thing in Hamlib 4.0 is that Mike implement a lot of command for the ic9700 (and the icom family) and i was testing this the last year with him, so with the new hamlib now gpredict (linux satellite programm) works fine with ic910, ic9100 and ic9700.
only automatic switch from split to non-split modes is not working, but this is somethine which have to be corrected in gpredict and not in hamlib.
gpredict and the old hamlib, too works fine with ic9100 or ic9700, but you have to to some manual changes in the sourcecode of gpredict or hamlib or have to use some pythonscript which you could insert via TCP between hamlib and gpredict, so they can speak correct which each other.
there are still some backword compatible errors at the moment in hamlib 4.0. so wsjtx is not working anymore with "hamlib Netrig control" here with ic7300 and ic9700. but there is workaround, when you want to use it that way by using the rigctld-wsjtx.
73 de DL7OAP, Andreas
Hi Andreas !
Nice to hear about you!
I hope everything is ok within these virus times!
Yes. I reporeted about the problem with wsjt-x 2.2.0rc1 and rig model #2 Net Hamlib rigctld to wsjtx-devel list.
Mike replied that it should be fixed in future, and actually yesterday I was cloning the WSJT Git and made compile and now it works again with that snapshot!
So no worries about that any more. It will be ok in GA release of 2.2.0
I noticed that new 3 stage decoding needs little fine tuning in cqrlog. As now decodes start a bit earlier as before I decreased HI-LOW speed limit of CQ monitor by one second.
I also touched the period timer (that grays the CQ monitor lines), but later found that it was not needed. Anyway it has also now a bit shorter time.
It just feels so funny that new lines are dropping to CQ-monitor while period is still going on and you can still hear whistle on band.
And when you pic up a early decoded call from CQ-monitor it feels like system is broken because the reply starts TX after few seconds gap that was not there before.
--
Saku
OH1KH
Hello Linux-Users,
also a great thank you to the cqrlog developers and supporters!
Be warned:
This script cannot debug serial device and rig setup problems in detail!
It is only able to help you to find what might be wrong - you have to check on your own what might be the root cause!
Lets start now:
Due to some setup problems of some linux hams and also some problems with HamLib version 3 and now HamLib 4,
i tried to write a bash script to help these guys to gather all needed informations and get "the point" what has to be done to get rigctld and cqrlog working.
This script was just a test and in my case I use it to start and stop the rigctld processes. The debug- and help-part was added - you might find it useful.
Please keep in mind, this script is not cqrlog related!
You can use it to setup, start, stop and debug rigctld to share your serial device!!
I need some hams to test and improve this script!
My working condition @home: linux mint 19.3 64bit, elecraft K3, Icom IC-7100 and IC-9700
I installed HamLib 4 by hand due to old HamLib 3 included in linux mint: 3.1-7build1.
My test was successful with HamLib 3 and also with HamLib 4.
This script takes care of HamLib 4 oder 3 - please use the HamLib wiki to identify your rig model and parameter! These changed from version 3 to 4 !!
Please download the script, rename it to "rigcontrol.sh", configure it or just go on and make it executeable
-> chmod +x rigcontrol.sh
then execute
-> rigcontrol.sh
The help is displayed.
Try "rigcontrol.sh help" and then "rigcontrol.sh setup"
I installed it in my home-directory: /home/martin/bin
And this script is started when I login to the system.
I think, its a bit overloaded, but hopefully useful.
Let me know what you think about it.
Last words: I'am not a programmer but try to do my very best :-)
Helpful comments are welcome ^_^
73 de Martin, DL1MTG
File:
--
73 de Martin, DL1MTG