I have a small patch to correct the install location of the python
bindings.
Since it's not a pure python extension is belongs in pyexecdir instead
of pythondir, which for multilib systems like Fedora will get installed
into /usr/lib64/python{ver}/site-packages on 64bit systems.
This is consistent with the automake documentation:
http://www.gnu.org/software/automake/manual/html_node/Python.html
(Patch adjusted by n0nb for Hamlib 3.0 bindings/Makefile.am)
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
I am making a Haskell binding to hamlib and this anonymous struct was
creating some issues for me. I am not a C-coder by day, but I think this
is harmless to add here.
Signed-off-by: Ricky Elrod <ricky@elrod.me>
This allows repeatable regression testing where a command has a finite
"settling" time. This will probably be of most use in the related
rotctl command set.
In order to write regression tests before making disruptive changes to
back ends I have added a new command to the rigctl parser which is '-'
that causes it to read commands from stdin until they are exhausted.
The commands must be white space separated and can include comments
from a '#' character until the end of the current line.
I wrote first support for new version of FUNcube Dongle. Differences
against original FCD are changed USB PID and wider frequency range.
73 Lada, OK1ZIA
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
Added option to not use VFO XCHG command when setting split
parameters.
Merge branch 'change_icom_sub_access' of git://git.code.sf.net/u/bsomervi/hamlib
The NET_LIBS configuration variable was not being exapanded in the
pkgpconfig template file. This caused static builds against hamlib to
fail on Windows because the WinSock library was not referenced.
The YACK() macro generates a message of variable length due the
__FILE__ string and a message returned by MS FormatMessage() being
inserted into a fixed length string buffer. I have increased the
buffer length to 1024 bytes and used snprintf to avoid overflows.
It looks like the whole YACK() macro should do nothing unless DEBUG is
defined so there is probably a small performance gain to be had by
doing that also. I have left that to the experts to decide.
With Icom rigs that use MAIN?SUB VFOs there is a trade off when
setting the mode or frequency of the "other" VFO. Untill now Hamlib
uses the XCHG VFO command to address the "other" VFO. This has some
advantages, particularly it preserves the selected VFO and it
preserves memory mode of either VFO. The disadvantage is that any
split command causes the Rx to glitch when the VFO/MEMs are exchanged.
I have added a config parameter for Icom rigs called "no_xchg" which
forces the direct addressing of VFOs to set split mode/frequency. It
is a boolean option with a default of "0" (false) which equates to
prior behaviour. Setting it to "1" (true) will make the backend use
change VFO commands to set the "other" VFO. This means that TX on
"SUB" in split is assumed, that both are in VFO mode (not MEM), and
set/get split functions will leave the MAIN VFO selected.
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.
The get mode function was not taking account of the extra mode bit in
the IF passband status byte. Also the set mode function was not
supporting the full set of available rig modes.
Added tuning step and bandwidth data for the newly supported modes.
The K3 supports AFSK & FSK sub-modes and for the D versions it also
has an internal RTTY and PSK31 decoder. The decoder sub-modes are
reported as FSK (RTTY) and the AFSK sub-modes are reported as PKT(USB
& LSB). LSB modes are assumed to be RTTY and USB modes are assumed to
be PKT(PSK, WS modes etc.).
For mode set the data sub-modes are set as follows:
RTTY -> FSK D normal (LSB) VFO shows MARK QRG
RTTYR -> FSK D reversed (USB) VFO shows MARK QRG
PKTUSB -> DATA A normal (USB) VFO shows suppressed carrier QRG
PKTLSB -> AFSK A normal (LSB) optimised for RTTY VFO shows MARK QRG
Not all data sub-mode combinations are possible but the above mapping
seems most likely to cover the user requirements.
Two patches:
The first adds support for the Flex 6K series of SDR radios. These
radios have a CAT application that runs on a windows machine, and
exposes a network socket that can be opened for CAT commands. This back
end connects to that network socket and provides an interface. I've
tested pretty thoroughly using a Flex 6700 but I don't have the other
models available (6500 and 6700R). CAT support on these models is
evolving with frequent updates from Flex, and this back end does not
reflect the latest features to be added. I hope to get to them soon.
The second patch makes the easycomm interface more robust by flushing
the serial port and clearing the buffer.
Steve, AI4QR
Merge branch 'for-upstream' of https://github.com/sconklin/hamlib into sconklin-for-upstream
The "1A 06" command to get the data mode returns 2 bytes rather than
the one byte documented in the user manual.
Fix indexing error, collect data mode from correct reply byte.
It turns out that either VFO can be incorrectly set in split mode when
the VFO is the TX VFO. The logic has been changed to send an IF; query
and read and set the other VFO if the VFO just set in set_freq is the
TX VFO and the rig is in split.
The Kenwood IF command, which is used to get the current VFO, returns
the TX VFO in transmit mode. The get_vfo function needs to return the
RX VFO to be consistent and useful elsewhere. The implementation now
swaps the returned VFO if the rig is in split mode and transmitting at
the time of the query.
The TS590s with firmware revision 1.07 or earlier fails to set VFO B
frequency properly when the rig is in split mode and the TX VFO is VFO
B. The symptom is, subsequent TX is on the wrong frequency (the
previous frequency) or there is no output at all. The fix is to read
VFO A and then immediately set VFO A to the read frequency. This
effectively null sequence has the side effect of setting VFO B
properly.
Defects in the TS590s f/w can be addressed selectively according to
revision.
Enable kenwood_open function for TS590s.
For some reason the TS590s did not use the kenwood_open function, as
fetching the firmware revision may be required for this rig and it is
done in that function; it has been enabled.
The TS590s has a DA command to set USB, LSB or, FM data
submodes. Support for get and set of these sub-modes has been
added. Mapped from RIG_MODE_PKTUSB, RIG_MODE_PKTLSB and,
RIG_MODE_PKTFM respectively.
The TS-870s has no width set for SSB and AM, instead the bandwidth is
set via a high and low pass fiter setting. The backend now sets these
to try and achieve the requested bandwidth. The HPF setting is assumed
to be the default.
The bandwidth query reads both the HPF and the LPF and returns the
difference.
The value of RIG_BANDWIDTH_NORMAL skips bandwidth adjustements.
The get and set_split operations have been enabled.
The TS50S has the old FN and SP commands rather than the newer FR/FT
commands, added code to support these commands allowing split
operation to be commanded on the TS50S.
The TS480 had no split VFO functions enabled, added normal modern
Kenwood split VFO and mode handing functions.
The API calls to set split frequency and split mode were missing, I
have set them to the preexisting Kenwood functions and they seem to
work as expected. I'm not sure why they were not already enabled.
Richard Shaw