First, yes, rig 2 behaves the similarly. However, being unaware of split support, and having never used it, I had never looked at "I" or "i" commands with respect to rigctl. Here's a sequence where quisk started with 3903000 on its display:
rigctl -m 2
?
Rig command: F 7150000
?
Rig command: f
Frequency: 7145000
?
Rig command: i
TX Frequency: 7150000
?
Quisk's display correctly responded to the F command by displaying 7150000. The follow-up response to "f" seems wrong by 5khz. Then the "i" returns "TX Frequency" 7150000, which matches what was set with the initial "F" command. The fact that "i" returns what we set with "F" seems reasonable, if we do not intend to operate split; i.e., the intended receive frequency (F) actually should be the same as transmit(i). But, I don't understand the response to "f". If "F" sets the rx frequency, shouldn't "f" return the rx frequency??Incidentally, the "RIT" button shows "0", if that matters.
I have only one piece of hardware plugged in to the pi. So, hardware-wise at least, there is only one receiver. Your question causes me to wonder if there might be some piece of software detritus lingering from a previous quisk or rigctl installation, and it is making trouble.
The original installation used repository binaries. A concern is the updates were built from the latest releases on the respective websites for quisk and hamlib. I would like to say I removed the repository versions before doing anything else, but too much time has passed. Even if I did remove the packages, was something left behind anyway? I do vaguely recall an issue recently, during these various experiments, where some fragment of something (the wsjtx package?) had to be removed to clear an error flag.?
I definitely did retain config files through the updates. Could that cause trouble when moving from one version to another? I guess I have some homework to do...
A clean install, starting with the OS, may still be the fix, though 64 bit may not be required.
Bruce ag5gt
Nick Abramenko RA3PKJ
