-
Notifications
You must be signed in to change notification settings - Fork 201
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
Labels
Milestone
Comments
mdblack98
added a commit
that referenced
this issue
Sep 21, 2021
mdblack98
added a commit
that referenced
this issue
Sep 22, 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
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 28, 2021
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
wutje
pushed a commit
to wutje/Hamlib
that referenced
this issue
Oct 13, 2021
…olling current_vfo is still determined at startup Hamlib#806
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
[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).
The text was updated successfully, but these errors were encountered: