Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IC-7300 vfocurr problem #806

Closed
mdblack98 opened this issue Sep 21, 2021 · 0 comments
Closed

IC-7300 vfocurr problem #806

mdblack98 opened this issue Sep 21, 2021 · 0 comments
Labels
bug needs test Patches have been submitted but need testing to close issue
Milestone

Comments

@mdblack98
Copy link
Contributor

[saku@hamtpad ~]$ telnet localhost 4532
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
f currVFO
3750000
m currVFO
CW
800
f VFOA
3750000
m VFOA
CW
800
f VFOB
14220000
m VFOB
USB
800
V VFOB <----so far so good. Setting now VFO B into use (rig display changes to show vfo b values)
RPRT 0
f currVFO <------ currVFO mode an freq as rig display says
14220000
m currVFO
USB
3000
M VFOB AM 0 <----- change to mode AM
RPRT 0
m currVFO <------- currVFO is still OK.
AM
9000
f currVFO
14220000
m VFOB <-----but the VFOB, that is current (in rig's display) shows now VFOA (that is behind) freq and mode via rigctld
CW
500
f VFOB
14220000
m VFOA <------and also VFOA shows values of VFOB when pressing rig's A/B to get VFOA to display it is 3.750 CW, not as rigctld says
AM
9000
f VFOA
3750000

In words:
When rig display shows vfoA and rigctld commands are used to switch first to vfoB (that comes to display) and then change mode then currVFO still shows same mode and freq what rig's display but when asking via VFOA and/or VFOB the contents get mixed upside down.

So it seems that to get always correct mode and frequency with all rigs, including icoms that can not report vfo, only "currVFO" at first parameter can be trusted.
VFOA and VFOB may work with rigs that can report vfo properly (I can not test that here).

@mdblack98 mdblack98 added the bug label Sep 21, 2021
@mdblack98 mdblack98 added this to the 4.4 milestone Sep 21, 2021
@mdblack98 mdblack98 reopened this Sep 23, 2021
mdblack98 added a commit that referenced this issue Sep 26, 2021
Icom rigs that do not have 0x25 or XCHG cannot do this yet which are older Icom rigs
XCHG rigs cannot get_vfo while transmitting but 0x25 rigs can
#806
@mdblack98 mdblack98 added the needs test Patches have been submitted but need testing to close issue label Sep 26, 2021
mdblack98 added a commit that referenced this issue Sep 28, 2021
This means get_vfo will not follow rig button pushes when freqs are equal
#806
mdblack98 added a commit that referenced this issue Sep 29, 2021
…olling

current_vfo is still determined at startup
 #806
wutje pushed a commit to wutje/Hamlib that referenced this issue Oct 13, 2021
wutje pushed a commit to wutje/Hamlib that referenced this issue Oct 13, 2021
wutje pushed a commit to wutje/Hamlib that referenced this issue Oct 13, 2021
Icom rigs that do not have 0x25 or XCHG cannot do this yet which are older Icom rigs
XCHG rigs cannot get_vfo while transmitting but 0x25 rigs can
Hamlib#806
wutje pushed a commit to wutje/Hamlib that referenced this issue Oct 13, 2021
This means get_vfo will not follow rig button pushes when freqs are equal
Hamlib#806
wutje pushed a commit to wutje/Hamlib that referenced this issue Oct 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug needs test Patches have been submitted but need testing to close issue
Projects
None yet
Development

No branches or pull requests

1 participant