1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in

Hamlib 3 API

From hamlib

(Difference between revisions)
Jump to: navigation, search
(Created page with '== Hamlib 3 API ideas == In June 2011 [http://thread.gmane.org/gmane.linux.hams.hamlib.devel/3177 there was some some discussion about possible improvements to the current Hamli…')
(Hamlib 3 API ideas)
 
(2 intermediate revisions not shown)
Line 2: Line 2:
In June 2011 [http://thread.gmane.org/gmane.linux.hams.hamlib.devel/3177 there was some some discussion about possible improvements to the current Hamlib 1.2 API] which has been stable for some time.  The following is a list of those ideas gleaned from the mailing list list along with a few others that may be considered.
In June 2011 [http://thread.gmane.org/gmane.linux.hams.hamlib.devel/3177 there was some some discussion about possible improvements to the current Hamlib 1.2 API] which has been stable for some time.  The following is a list of those ideas gleaned from the mailing list list along with a few others that may be considered.
 +
=== Thread Safety ===
=== Thread Safety ===
Line 34: Line 35:
As I (N0NB) understand it, Hamlib is not designed or implemented in such a way as to allow multiple user applications to connect to the same device via the C API.  I have done it and it seems that eventually one or more of the apps will get out of sync with the device.  This topic is ripe for experimentation.
As I (N0NB) understand it, Hamlib is not designed or implemented in such a way as to allow multiple user applications to connect to the same device via the C API.  I have done it and it seems that eventually one or more of the apps will get out of sync with the device.  This topic is ripe for experimentation.
 +
=== rigctld/rotctld cache or ??? ===
=== rigctld/rotctld cache or ??? ===
In a [http://thread.gmane.org/gmane.linux.hams.hamlib.devel/3177 thread from 10 Oct 2011] I (N0NB) posted thoughts for a performance enhancement to rigctld/roctld to handle multiple commands before the hardware device returned a reply using a cache.  Charles AA1VS suggested that a mutex might be a better way to go.  [http://thread.gmane.org/gmane.linux.hams.hamlib.devel/3346 In a series of followups] more discussion came back to the thread safety of Hamlib.
In a [http://thread.gmane.org/gmane.linux.hams.hamlib.devel/3177 thread from 10 Oct 2011] I (N0NB) posted thoughts for a performance enhancement to rigctld/roctld to handle multiple commands before the hardware device returned a reply using a cache.  Charles AA1VS suggested that a mutex might be a better way to go.  [http://thread.gmane.org/gmane.linux.hams.hamlib.devel/3346 In a series of followups] more discussion came back to the thread safety of Hamlib.
 +
 +
[http://article.gmane.org/gmane.linux.hams.hamlib.devel/3513 Another thread in May 2012] the cache idea was brought to the fore.  Stephane [http://article.gmane.org/gmane.linux.hams.hamlib.devel/3599 thought that a library wide cache] could be implemented.  Patches may be forthcoming soon.
This needs more exploration.
This needs more exploration.
 +
 +
 +
=== Abstraction for new rig/PC interfaces ===
 +
 +
There are interfaces to connect radios to computers that multiplex all signals into a single USB device, e.g., the Microkeyer family of devices from microHAM. PTT, FSK and CAT devices, which traditionally have been presented to hamlib as separate serial ports, are now muxed together as one serial port using a vendor specific protocol. Some devices even support multiple radios, antenna switches and rotators. If hamlib is to understand such devices, we need a new abstraction for this kind of device. Radio and rotator backends must send commands to this interface to have them muxed together with other signals. Also, there can be only one such muxer/demuxer per device, which means that it must be reused by all processes accessing the same radio.
 +
 +
This needs more exploration. Maybe new radios with USB or network ports also need a different communication model than the current serial port model?
 +
 +
 +
=== RIT/XIT clear versus turning those functions off ===
 +
 +
Tor, N4OGW, [http://article.gmane.org/gmane.linux.hams.hamlib.devel/3141 requested a way to clear the RIT without turning it off].  This thread probably as much as any led to the idea of an API update.  Regardless, the API should be updated for rigs that can clear the RIT/XIT functions without turning them off.  How this is best implemented is the question.  Should a completely new function be written or should it be done through the rig_set_ext_level() as was done for the K3?

Current revision as of 19:58, 5 July 2012

Contents

Hamlib 3 API ideas

In June 2011 there was some some discussion about possible improvements to the current Hamlib 1.2 API which has been stable for some time. The following is a list of those ideas gleaned from the mailing list list along with a few others that may be considered.


Thread Safety

This is an ongoing issue and with greater use of rigctld and rotctld by multiple applications is probably an area that deserves a lot of discussion and some solutions. Stephane posted the following on 20 Jan 2011:

> > Do you know anything about the thread-safety of hamlib? I currently
> > have the hamlib calls in a separate thread so the GUI thread can
> > update as needed. That works fine with one radio. But I am not sure
> > when I use two radios whether those calls can be in separate threads
> > (easier to program when the poll time is different for the two
> > radios), or if all hamlib calls need to come from one thread?
> 
> So far as I know, Hamlib is not thread safe.  I think that keeping it in
> its own thread is the wise choice.  You might want to ask Stephane,

Indeed, Hamlib is not thread safe within one backend, because we didn't want
to force a lib pthread dependancy on users. Two threads cannot access the
same rig without appropriate locking (or puting the calls in a dedicated thread).
by the end-user program.

However, Hamlib and its backends is multi-rig safe and should be reentrant,
i.e. you can instantiate more than once the same backend or different backends
in the same program. Running multiple rigs in their own thread should
work without locking, with the limitation that the frontend
initialization (rig_init()/rig_cleanup()/..) are not thread-safe.
Maybe this topic needs more investigation and be properly documented.

Indeed this does warrant more thought and discussion.

As I (N0NB) understand it, Hamlib is not designed or implemented in such a way as to allow multiple user applications to connect to the same device via the C API. I have done it and it seems that eventually one or more of the apps will get out of sync with the device. This topic is ripe for experimentation.


rigctld/rotctld cache or ???

In a thread from 10 Oct 2011 I (N0NB) posted thoughts for a performance enhancement to rigctld/roctld to handle multiple commands before the hardware device returned a reply using a cache. Charles AA1VS suggested that a mutex might be a better way to go. In a series of followups more discussion came back to the thread safety of Hamlib.

Another thread in May 2012 the cache idea was brought to the fore. Stephane thought that a library wide cache could be implemented. Patches may be forthcoming soon.

This needs more exploration.


Abstraction for new rig/PC interfaces

There are interfaces to connect radios to computers that multiplex all signals into a single USB device, e.g., the Microkeyer family of devices from microHAM. PTT, FSK and CAT devices, which traditionally have been presented to hamlib as separate serial ports, are now muxed together as one serial port using a vendor specific protocol. Some devices even support multiple radios, antenna switches and rotators. If hamlib is to understand such devices, we need a new abstraction for this kind of device. Radio and rotator backends must send commands to this interface to have them muxed together with other signals. Also, there can be only one such muxer/demuxer per device, which means that it must be reused by all processes accessing the same radio.

This needs more exploration. Maybe new radios with USB or network ports also need a different communication model than the current serial port model?


RIT/XIT clear versus turning those functions off

Tor, N4OGW, requested a way to clear the RIT without turning it off. This thread probably as much as any led to the idea of an API update. Regardless, the API should be updated for rigs that can clear the RIT/XIT functions without turning them off. How this is best implemented is the question. Should a completely new function be written or should it be done through the rig_set_ext_level() as was done for the K3?

Personal tools