This found tons of errors in rig_debug statements
So this patch cleans up all the files that were producing warnings or errors
This should fix a few segfaults when running with debug turned on
Before altering the serial port settings, make a copy of the settings
and track it by the fd. On serial port close, restore the original
settings for that port.
On Mac OS the Prolific PL2032 kernel driver locks up if closing without
first restoring the options. When this happens, further usage of the port
is impossible until computer is rebooted, which cannot even be done
without a hard power-off.
With this fix, a clean close make sure we can re-open the port again.
* Change magic numbers in icom_set|get_ctcss|dcs_sql|code functions to
constants defined in src/tones.h
* fix a minor bug in icom_get_dcs_code (now ignoring polarity instead of
reporting invalid DCS code when sending reverse pol. DCS code)
* introduce DCS codes to IC-R8600 rig backend
73,
Ekki, DF4OR
I have an potential initial release of a backend for iOptron alt-az mounts.
I have tested it and it appears to work well both from the command line and
driven by Gpredict with my iEQ45Pro. I ran the source through astyle and I
think that it's OK. Compiling and testing was done under Unbuntu 18.
Bob KD8CGH
On Debian Buster gcc ((Debian 8.2.0-8) 8.2.0) was throwing the following
warning:
CC network.lo
../../hamlib/src/network.c: In function ‘network_open’:
../../hamlib/src/network.c:245:46: warning: ‘%s’ directive output may be truncated writing up to 511 bytes into a region of size 139 [-Wformat-truncation=]
snprintf(msg,sizeof(msg),"connect to %s failed, (trying next interface)",rp->pathname);
^~
../../hamlib/src/network.c:245:9: note: ‘snprintf’ output between 44 and 555 bytes into a destination of size 150
snprintf(msg,sizeof(msg),"connect to %s failed, (trying next interface)",rp->pathname);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Raising the size of the msg buffer to 1024 quelled the warning.
* Added new rotor module (18) for Meade telescope rotors
* Implemented all needed rotor functions
* Added README.md
* Tested with DS-2000 Rotor with Autostar 494 and 506 serial cable
* Tested on Linux (Debian) with rotctl and gpredict
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 patch changes rig_list_foreach such that the called function may
call rig_unregister without having to access freed memory. This avoids
a valgrind MemCheck and makes it possible to clean up teh rig_list
database.
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.
Some distributions--Debian and Alpine tested--put libusb.h under the
libusb-1.0 directory. Test for its presence and if found define
HAVE_LIBUSB_1_0_LIBUSB_H. Also test for HAVE_LIBUSB or
HAVE_LIBUSB_1_0_LIBUSB_H and conditionally include the correct header
file in the sources.
As Hamlib now restores the rig auto information state (AI) on exit
there is now a need to disable that functionality so that rigctl can
be used to set/reset AI mode on the rig explicitly.
A new public API function 'rig_no_restore_ai()' is also added that
allows any client to disable this auto AI restore functionality if
required. Most clients should do nothing as restoring AI state is a
good thing.
This means that rigctl & rigctld now work with default arguments on a
modern Windows machine with dual stack and localhost being [::1] as
the first interface returned by getaddrinfo().
Try all the interfaces return by DNS lookups to establish a connection
or listening port. Handle Windows network errors correctly so that
meaningful messages are printed.
The rigctl program now accepts IPv6 numeric addresses in the portname
field like [<addr>}:<port> for example the IPv6 loopback on port 4531
would be [::1]:4531.
Michael Black