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.
Because some rigs lock their front panel when opened for CAT it is
helpful to call rig_close() in rigctld when no clients are
connected. This change does that.
A CTRL+C handler is also added to allow rig_close() to be called
during exit.
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.
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
Jeroen Vreeken