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

RIT/XIT Offset #26

Closed
dl2ki opened this issue Apr 8, 2022 · 9 comments
Closed

RIT/XIT Offset #26

dl2ki opened this issue Apr 8, 2022 · 9 comments
Labels
bug Something isn't working

Comments

@dl2ki
Copy link

dl2ki commented Apr 8, 2022

After turning on RIT or XIT on the tranceiver, both offsets are displayed in the Rig window if they are set <> 0 on the TRX.
However, the displayed offsets are always the same for RIT and XIT, even if only RIT or only XIT are switched on.

@foldynl
Copy link
Owner

foldynl commented Apr 9, 2022

that's what I was afraid of. For my ic7300, RIT / XIT is always the same number. That's why I couldn't properly test it. So I have to look at the hamlib code

@dl2ki
Copy link
Author

dl2ki commented Apr 9, 2022

Yes, I am also wondering.

As I just tried, with rigctl, "j" or "z" also same values are displayed. K3 and K2. So could be a problem with hamlib.

@foldynl
Copy link
Owner

foldynl commented Apr 9, 2022

I will try to look at the Hamlib source code. Unfortunately Hamlib is not a well-documented library, so it is better to look directly to the source code. Please, let me know a result of Rigctl for K2/3. In case of IC7300 it looks that it is also a hardware limitation, that XIT/RIT have the same.

@dl2ki
Copy link
Author

dl2ki commented Apr 9, 2022

Hi,

rigctl uses the "IF (Transceiver Information; GET only)" command to read RIT/XIT. K3 and K2.

Rig command: j
rigctl_parse: input_line: j
rigctl_parse: vfo_opt=0
rig_get_rit called
kenwood_get_rit called
kenwood_get_if called
kenwood_safe_transaction called
kenwood_transaction called
elapsed_ms: start = 1649530101,802242177
elapsed_ms: elapsed_msecs=128068
kenwood_transaction: cmdstr = IF
rig_flush: called for serial device
serial_flush called
tcflush
write_block called
write_block(): TX 3 bytes
0000    49 46 3b                                            IF;             
read_string called, rxmax=128
read_string(): RX 38 characters
0000    49 46 30 30 30 30 33 35 36 37 30 30 30 20 20 20     IF00003567000   
0010    20 20 2b 30 32 30 30 31 30 20 30 30 30 33 30 30       +020010 000300
0020    30 30 30 31 20 3b                                   0001 ;          
kenwood_transaction: read_string(len=38)='IF00003567000     +020010 0003000001 ;'
kenwood_transaction: returning RIG_OK, retval=0
elapsed_ms: start = 0,0
elapsed_ms: after gettime, start = 1649530229,919209893
kenwood_transaction: returning retval=0
RIT: 200
rigctl_parse: vfo_opt=0
rigctl_parse: retcode=0
rigctl_parse: called, interactive=1

Rig command: 

This string contains information about whether RIT and / or XIT is switched on. Therefore you have to read out both values to get the correct assignment. However, these two bits are apparently not evaluated for "j" and "z". Therefore, the same values are displayed for RIT and XIT.

Here is an excerpt from the "ELECRAFT K3S /K3/KX3/KX2 PROGRAMMER'S REFERENCE"

grafik

I cannot check here how this is read out by other manufacturers.

@dl2ki
Copy link
Author

dl2ki commented Apr 9, 2022

This is the same with the Kenwood TS590SG:

grafik

See "Kenwood TS-590SG PC CONTROL COMMAND Reference Guide"

@dl2ki
Copy link
Author

dl2ki commented Apr 9, 2022

If the programming effort here is high, I think you can also leave out the RIT/XIT display for the time being, since the information is also available on the rig itself. In this form, the display is also only limited usable.

Perhaps a solution to the problem will arise at a later time.

@foldynl
Copy link
Owner

foldynl commented Apr 10, 2022

Thank you, Wolfgang. I dived it into the Hamlib source code and found out many interesting things.

  1. If application gets a XIT/RIT offset via rit_get_rit(xit) then it is not possible to obtain status of RIT/XIT (on or off) - the statuses as you wrote above, are ignored
  2. hamlib implements GET_FUNCTIONS where you can obtain an additional information. For my Icom and your k3 (or k2x), there is implementation of "GET RIT STATUS" function.

I will not describe much detail here, only that there is a difference if the rig implements the "Get RIT / XIT offset" function and if it has implemented the "GET RIT / XIT Status". These things are two different functions and unfortunately for some rigs "GET RIT / XIT Offset" can be implmented but "Get RIT / XIT Status" is missing (example for pure K2, K2X has implemented both functions)

Maybe I would ask you for a test that I did successfully with my IC7300.

Via rigctl, call following sequence:

Turn off XIT / RIT on your rig
call u XIT and u RIT via rigctl - both commands should return 0
turn on XIT on your rig
call u XIT and u RIT - only XIT returns 1, RIT returns 0
turn on RIT
both command should return 1.

My test

u ?
NB COMP VOX TONE TSQL SBKIN FBKIN ANF NR MON MN LOCK RIT SCOPE TUNER XIT TRANSCEIVE SPECTRUM SPECTRUM_HOLD 

XIT/RIT off

u XIT
0

XIT on

u XIT
1
u RIT
0
u RIT
0

RIT on

u RIT
1
u RIT
1
j
500
u RIT
1
u XIT
1
j
480
z
480

I found out that for u XIT and u RIT hamlib calls different commands (RT and XT) than for j/z (GET RIT / XIT offset).

@dl2ki
Copy link
Author

dl2ki commented Apr 10, 2022

Hi,

here my protocol. Looks like it works like yours.

Rig command: u ?
NB VOX APF LOCK RIT XIT DUAL_WATCH DIVERSITY 

K3: XIT/RIT off

Rig command: u XIT
Func Status: 0

K3: XIT on

Rig command: u XIT
Func Status: 1

Rig command: u RIT
Func Status: 0

Rig command: u RIT
Func Status: 0

K3: RIT on

Rig command: u RIT
Func Status: 1

Rig command: u RIT
Func Status: 1

Rig command: j
RIT: 500

Rig command: u RIT
Func Status: 1

Rig command: u XIT
Func Status: 1

Rig command: j
RIT: 500

Rig command: z
XIT: 500

K3: Change RIT, XIT from 500Hz to 480Hz

Rig command: j
RIT: 480

Rig command: z
XIT: 480

Rig command: 

@foldynl
Copy link
Owner

foldynl commented Apr 10, 2022

Many thanks for your confirmation. I will implement it in the next release.

@foldynl foldynl added bug Something isn't working and removed need more info labels Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants