Add vfo_fixup function. We should be able to do all vfo corrections in rig.c instead of backends. So we're migrating that way....
https://github.com/Hamlib/Hamlib/issues/269
https://github.com/Hamlib/Hamlib/issues/259
set_vfo_opt can now dynamically change vfo mode on rigctld
So this example now works...does some non-vfo stuff then switches to vfo mode
rigctl -m 2 F 14074000 V VFOB F 14076000 V VFOA f V VFOB f set_vfo_opt 1 f VFOA
rigctl commands v,V and S have been changed to not require VFO arguments
New API function rig_set_vfo_opt -- only implemented for Net rigctl as it doesn't apply to any other rigs
This could be changed to automatically selecting a valid VFO so
VFOA=Main or Main=VFOA for example but not sure if we want to do this.
This is already being done for the IC-9700 for example since satmode
only has Main/Sub where non-satmode has MainA/MainB/SubA/SubB
So the question is do we emulate VFOA/B and Main/Sub for all rigs?
Another step in migration of rigs to separate model numbers for variations in models
We default to using range_list1 now and eventually there will only be 1 range_list per model
We have enough room in the model numbers now to expand...so for example we will have
5 models for the IC-9700
IC-9700 USA
IC-9700 EUR
IC-9700 ITR
IC-9700 TPE
IC-9700 KOR
In the case of gpredict there are times when one has to adjust the
VFO to dial in a frequency while gpredict is tracking.
We now detect this situation and have a 3-second delay every time
VFO twiddling is detected. set_freq and set_vfo calls will be
ignored during this delay.
May make this a settable value if needed.
This logic needs to be overhauled as Icom (and probably others) are putting out
rigs with no way to tell what model you have from CAT control.
So we may end up having to explicitly list all rig models which is more user friendly anyways
and will work with WSJT-X and other user-space programs.
So, e.g., IC-9700 would be listed as 5 models: IC-9700-USA, IC_9700-EUR, IC_9700-ITR, IC-9700-TPE, IC-9700-KOR
Put a looplimit on icom_get_ant_count trying to get autodetect to work
Changes to icom_get_ant_count to try and get this working
Added dummy antenna # args to rigs that don't care i.e. only have 1 antenna
Fix declarations after statements
Remove some !rig checks...we either don't need them or need them everywhere with a new error code
If you pass a NULL rig you get what you deserve :-)
I tried to control my "FUNcube Dongle Pro" SDR with Hamlib. At first it
worked fine, but when I tried to correct the frequency divergence with
the vfo_comp parameter, I found a bug in the software.
Example:
$ ./rigctl -m 2513 -C vfo_comp=0.01
Rig command: F 100000000
Rig command: f
Frequency: 102010000
The correction must toke place when setting the frequency and when it
is read back. But one time the correction must work in on direction,
the other time quite opposite.
I found the code in the file rig.c and could see, that both times the
same calculation is used.
The simplest way to correct this is to go to the “rig_get_freq(“
subroutine and change it in the line 1188 from “+=” to “-=” , even that
is mathematically not correct.
Result:
$ ./rigctl -m 2513 -C vfo_comp=0.01
Rig command: F 100000000
Rig command: f
Frequency: 99990000
$ ./rigctl -m 2513 -C vfo_comp=0.000022
Rig command: F 100000000
Rig command: f
Frequency: 99999999
You can see, that the result is quite good for small divergences of
some ppm, but there is still an error for bigger divergences. So I
changed the line 1188 to the form I hope it is the mathematically
correct one:
*freq = (freq_t)(*freq/(1.0+(double)rig->state.vfo_comp));
Result:
$ ./rigctl -m 2513 -C vfo_comp=0.01
Rig command: F 100000000
Rig command: f
Frequency: 100000000
$ ./rigctl -m 2513 -C vfo_comp=0.000022
Rig command: F 100000000
Rig command: f
Frequency: 100000000
Now the result looks good for small and for bigger divergences.
Best regards
Dieter Röver (DK6OV)
Hi,
I had trouble with CTS serial port squelch (on microHAM USB Interface III).
It seems there is a bug in the hamlib code and I think the similar thing
should be done as has been done for the pttport, i.e. if the dcdport is
the same as the rigport, do not reopen it. Otherwise the serial port will
be reset to its default and it will key the radio PTT forever (because
the RTS line is reset on the port reopen). Patch attached
73! Jaroslav, OK2JRQ
This flag can be used by back ends that need to take special action
while the rig is transmitting e.g. the FT-747GX and similar that do
not process CAT commands while transmitting.
The flag is also used as a default answer to rig_get_ptt if nothing
better is available.
Deal with inaccurate CAT query for Rx/Tx on the Yaesu FT-847
This rig doesn't set the Rx/Tx status flag when PTT is asserted via
the PTT pin on the rear PACKET socket so we need to override which we
can do if we known we have asserted PTT via rig_set_ptt().
Adjust style and fix set PTT defects
Fix a warning from a declaration of a deleted function definition
When the PTT serial port is not the control port the intention is to
free the port when PTT is reset so that other applications can share
it. This logic was faulty with attempts to call port functions on an
unopened port when repeatedly calling the rig_set_ptt API.
Thanks to Christoph van Wullen, DL1YCF, for finding and analyzing this
defect.
When using separate serial port for PTT via RTS pr DTR it is
convienent to close the port when the PTT line is not asserted. This
allows other applications to share the PTT serial port.
This has been achieved by ensuring that file descriptor for the port
is set to -1 when the port is closed, this then allows the invalid FD
to be used as a PTT surrogate for the rig_get_ptt API when the port is
only being used for PTT.
This change allows the set_mode functions to leave the rig passband
unchanged if required. For the few rigs that do not have explcit
passband width control either current state is read and rewritten or a
"normal" width is chosen e.g. select a normal width when there is a
choice like CW and CW-NARROW.
CAT protocols that don't allow direct addressing of VFOs require that
the "other" VFO be queried or set via a select then get/set then
select back to original or swap then get/set then swap again. When
both frequncy and mode need to be set the sequences can be optimized
if a single funciton is avaiable.
This enhancement adds those single functions rig_set_split_freq_mode()
and rig_get_split_freq_mode() with a default impelementation that
calls the individual rig_{get,set}_split_{freq,mode}() functions. Back
ends can choose to implement an optimized version which is used
instead of the default if present.
Using these functions when an optimized implementation is available
allows the TX VFO's frequency and mode to be set in a single operation
with only one VFO exchange or selection either side of the
operation. Many CAT protocols are very efficient when getting or
setting both frequency and mode and some even combine the two in a
single command.
The letters 'K' and 'k' are used for the rigctl short command name for
these functions.
The previous commit introduced a regression that masks any error
return from opening the serial port used for PTT when that port is
different from the CAT serial port.
Before this change only the line used for PTT was being lowered on
open. It is necessary for platforms other than Windows to avoid
issues with other uses of the line not used for PTT such as interfaces
that wire-or RTS and DTR together or use it for CW or FSK keying. This
is because platforms other than Windows raise both DTR and RTS on
serial port opening.
Also changed code that opens CAT port to lower RTS or DTR if it is
used for PTT. In this case there is no need to lower the other line of
DTR or RTS as there is already a config parameter to control it
(dtr_state or rts_state). This change is necessary to maintain current
functionality.
The serial port line control functions take a boolean argument not a
ptt_t argument. Changed usage in rig_open() to use a explicit zero
instead of RIG_PTT_OFF value which only coincidentally happens to be
zero.
Many APIs emulate direct VFO addressing by using caps->set_vfo() or
caps->vfo_op(..., RIG_OP_TOGGLE) to simulate direct addressing of a
non-current VFO. The mirrored function call to revert back to the
original current VFO was not checking for errors. This is not
unreasonable but it turns out that some rigs can arbitarily fail doing
VFO changes or swaps (e.g. Yaesu FT-450).
I have added checks to these calls but only fail with the error if the
API call being wrapped does not fail itself. This allows the mirroring
VFO operation to be completed, if possible, even if the wrapped
function could not be completed, hence as before, making every effort
not to change the rig state unnecessarily.
When a serial control line (DTR or RTS) is used for PTT control the
rig_open() function clears the PTT control line after opening the
port. This is necessary on Linux because opening the port sets them
both as part of the normal RS-232 protocol. The lines were not being
cleared when the PTT port was the same port as the CAT control port.
The Icom IC-7100 back end added this enum instead of using the extant
RIG_PTT_RIG enum. Also the rig_get_ptt() implementation didn't handle
it and errored out.
Note: RIG_PTT_SERIAL_CAT was added in commit
e9ee671149 - N0NB
MinGW was issuing the following warning:
CC rig.lo
rig.c: In function 'rig_init':
rig.c:330:36: warning: assignment makes integer from pointer without a cast [enabled by default]
rs->rigport.parm.cm108.ptt_bitnum = DEFAULT_CM108_PTT_BITNUM;
^
The constant DEFAULT_CM108_PTT_BITNUM was being defined as a string on
non-linux platforms. Now defined to an integer on these platforms. The
actual value may need to be corrected at some point in the future when
CM108 support is completed for those platforms.
From Martin, CT1IQI:
"Several programs under Linux rely on Hamlib for control. I wanted to
try WSJT-X (digital modes like JT65) and found that my new IC-7100 was
not yet supported, also after having compiled the current git version of
Hamlib and having compiled WSJT-X against that.
So I added a IC-7100 by taking the ic-7200 and 7420 rig files as
example, be it without going (yet) through all of the very many commands
the ic-7100 supports.
This produced the situation where there was communication, e.g. setting
and reading frequencies, but the PTT control did not work. I debugged
that to actually the lack of a PTT mode in Hamlib that uses serial and
CAT at the same time; currently PTT per 'serial' seems equivalent to
toggling certain RS232 pins but not to any serial command level. So I
added a RIG_PTT_SERIAL_CAT mode for PTT control. Now the wsjt-x program
works nicely with the ic-7100 and controls both frequency and PTT via
the single USB cable."
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
rig_open was giving RIG_DEBUG_ERR messsages if PTT or DCD
port was unavailable but the function was not returning an
error status.
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
Hi,
patch attached to enable the above which was partially coded but not
quite working.
73
Bill
G4WJS.
>From 9dab3a250dfad7203772df91aadf79d38c108f04 Mon Sep 17 00:00:00 2001
From: Bill Somerville <bill@classdesign.com>
Date: Fri, 6 Sep 2013 01:13:34 +0100
Subject: [PATCH] Fix using same serail port for PTT and CAT
src/rig.c was coded to allow the same serial port for PTT and
CAT but them tried to open the port twice. I have added code
to share the file descriptor in this situation.
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
Various strncpy operations could result in a port pathname that is not a
NULL terminated string as the allowed string length is the same size as
the buffer per the strncpy manual page. This is corrected by assuring
that the allowed length is FILPATHLEN - 1.
to set_split_vfo/get_split_vfo, and take an extra transmit vfo arg.
Ascending compatibility is retained at the API frontend level.
NOTE: only function name has changed. The backends do not implement
necessarily the new semantic (the extra tx vfo is just ignored).
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@1425 7ae35d74-ebe9-4afe-98af-79ac388436b8
- rig_set_channel and rig_get_channel can now target VFO, besides memories
- emulation of set_channel and get_channel has been kept in generic routines.
Added in these routines the support for ext_levels.
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@1113 7ae35d74-ebe9-4afe-98af-79ac388436b8
* added support for XIT
* misc updates
* started work on rig_save_channel/rig_restore_channel
to emulate rig_get_channel/rig_set_channel. Seems to work on my IC706MkIIG.
see tests/dumpmem.
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@478 7ae35d74-ebe9-4afe-98af-79ac388436b8
* new fields in caps: vfo_list, priv
* shadowed tuning_steps
* coded in rig_passband_normal,rig_passband_narrow and rig_passband_wide
as examples. Not activated yet.
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@407 7ae35d74-ebe9-4afe-98af-79ac388436b8
* reworked serial/parallel PTT handling. Split functions so it'll be
easier to add support for different architectures.
This has been tested, and it works at least with my IC706 and
PTT signaling on parallel port (using Data/Packet connector)
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@357 7ae35d74-ebe9-4afe-98af-79ac388436b8
RIG_PTT_SERIAL is no more, it is replaced by RIG_PTT_SERIAL_RTS and
RIG_PTT_SERIAL_DTR.
* added comments for rig_get_level and RIG_LEVEL_STRENGTH
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@331 7ae35d74-ebe9-4afe-98af-79ac388436b8
This is a major change in the library interface, and the implementation
is not complete yet (especially in the backends), but the API should
be fine. Anyway, at this stage of developement, interface design
experimenting matters more than completeness.
* added new shortfreq_t type for frequencies on 31bits (up to 2GHz)
for use by offset/shifts/etc.
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@285 7ae35d74-ebe9-4afe-98af-79ac388436b8
includes the passband, since most rigs tie these parameters together
quite often. For exemple, WFM is (RIG_MODE_FM,RIG_PASSBAND_WIDE) in Hamlib.
Another set of functions will be needed to fine tune aditional
frequency response/filters.
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@280 7ae35d74-ebe9-4afe-98af-79ac388436b8
See doc/ subdirectory for more info. The work is still in progress,
the current comments are pretty shallow rigth now, they're still
lacking the valuable information like semantics, side effects,
special cases, error definitions, etc. that makes a good API documention.
Please help commenting, fixing typos and mispellings!
* renamed rig_*_rpt_* functions to rig_*_rptr_* to be more uniform
* made use of setting_t type in *_has_* functions
* removed set_volume, get_volume, set_squelch, get_squelch,
get_squelch_status, set_ant, get_ant, int et_att, get_att,
set_preamp, get_preamp, set_power, and get_power
in favor of set_level/get_level.
* set_func takes one more arg for the status (activate or desactivate)
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@234 7ae35d74-ebe9-4afe-98af-79ac388436b8
* Added rig_[sg]et_rpt_offs to set/get repeater offset
* Added rig_split functions: rig_[sg]et_split_freq (set RX and TX freq) and rig_[sg]et_split to activate split mode
* Added rig_[gs]et_level, however rig_set_preamp/rig_set_att/rig_set_ant et al. will be removed very soon.
* Added Memory/VFO handling routines (actually wrappers, like the rest)
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@219 7ae35d74-ebe9-4afe-98af-79ac388436b8
* keep track of opened rigs (add_opened_rig/remove_opened_rig/foreach_opened_rig),
* misunderstanding on RIG_ENIMPL, this is RIG_ENAVAIL in most cases,
* added support for file buffered access (opt.),
* added rig_set_trn to turn on/off transceive support
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@196 7ae35d74-ebe9-4afe-98af-79ac388436b8
Michael Black W9MDB