Per the suggestion of Greg Troxel, N1DAM, remove the need for the 'makeinfo'
dependency at build time by creating the HTML version of the manual along with
the info version at 'make dist' time. The removes the build dependency on
'makeinfo' that was introduced since the release of 3.1.
(cherry picked from commit 6efb7b64b2)
This is to help with owners of Arduino boards like the ubitx that
emulate an FT-817 but respond badly to a DTR signal glitch which is
inevitable when opening a Linux serial port. The glitch triggers the
Arduino boot-loader which must be allowed to time out before the
FT-817 emulation starts.
(cherry picked from commit 09e6ab6ef1)
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)
Workaround for fldigi
fldigi treats zero frequency as error and disables hamlib.
So if the device rports zero frequency return 1 Hz instead,
so the user can switch to the favored frequency
The TS-711 and TS-811 use an IF10 board just like the TS-140/TS-680/TS-590
and thus share a lot of the same commands with it.
Tested:
* TS-711A
* TS-811E
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
Hi,
on 64 bit distros with /usr/lib64 (e.g Fedora) the hardcoded libdir in
pcconfig is wrong. The attached patch tries to fix it. It also applies
to 3.1
73! Jaroslav, OK2JRQ
Expand variable substituion for hamlib.pc
Further testing showed that 'exec_prefix' and 'includedir' would benefit from
variable substitution by the configure script.
- N0NB
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
Nate Bargmann