Describe the bug
When configuring JS8Call to use rig split, it apparently will always use split mode, and which split frequency it uses depends not only on the audio frequency of the present transmission, but also on the audio frequency of the previous transmission.
To Reproduce
Steps to reproduce the behavior:
- Use a rig that allows CAT. (I used one controlled by
rigctld and had JS8Call talk to that.)
- Configure JS8Call to use rig split mode (see screenshot)
- Go 28078 kHz on the rig.
- Select audio frequency offset between 2600 and 2700 Hz. Hit tune. The rig goes to 28079 kHz (So the actual audio used hopefully is between 1600 and 1700 Hz.)
- Now, go to some frequency offset between 1500 and 1600 Hz and hit tune. The rig splits to 28079 kHz again. If the math is done correctly by JS8Call, the audio is now between 500 and 600 Hz. This defeats a purpose of split, namely, to keep the audio actually used above 1500 Hz so its harmonics are above 3000 and above 4500 Hz.
- Now go to some audio frequency offset between 1100 and 1200 Hz. Hit "tune". The rig jumps to 28077.5 kHz, so the actual audio used is between 1600 and 1700 Hz.l
- No, return to the 1500-1600 area. Hit tune. The rig again jumps to 28077.5 kHz. So this time, the audio actually used is between 2000 and 2100 Hz.
Expected behavior
- The audio frequency actually used should always sit in the same 500 Hz slot. (Open for debate, I would use 1700-2200 Hz.)
- Which split frequency is used to transmit a certain desired radio frequency should only depend on that desired radio frequency, not on history of previously transmitted frequencies.
- When the audio frequency offset as requested by the user is already in the 500 Hz slot the program wants to use anyway, split functionality should not be used.
Desktop (please complete the following information):
Additional context
In some way, this is a follow-up of #16 .
Describe the bug
When configuring JS8Call to use rig split, it apparently will always use split mode, and which split frequency it uses depends not only on the audio frequency of the present transmission, but also on the audio frequency of the previous transmission.
To Reproduce
Steps to reproduce the behavior:
rigctldand had JS8Call talk to that.)Expected behavior
Desktop (please complete the following information):
rigctldfrom Debian'slibhamlib-utilsat Version: 4.6.2-1+b1Additional context
In some way, this is a follow-up of #16 .