Re: [Hamlib-developer] hamlib

[Stephane F. <f8...@fr...>]

If you don't mind, I'm going to Cc: the hamlib-dev mailing-list.

Wed, Jan 19, 2011, Nate Bargmann skribis:
> * On 2011 19 Jan 14:05 -0600, RT Clay wrote:
> > Nate,
> > 
> > I've got hamlib working with my code now (at least in a first test).
> > The dll seems to work ok in Windows when linked against MS VC code as
> > well.
> 
> That's good to hear it's working for you.

Good stuff indeed.
Clay, feel free to share any insight that may help other hamlib users
on the hamlib-developer mailing list or the forums.

> > I noticed you did some more work on the K3 backend. When you get a
> > chance I would really like the "FI" command...the IF offset varies
> > with filter on the K3, and that one is essential to keeping the
> > panadapter offset correct.
> 
> I will look into that.  While the Hamlib API may not support that
> directly, I think we can reach that function through a specific
> get/set_level call.  I will look into it.

I don't have the kenwood manual at hand, but the name of the RIG_LEVEL
to use can be RIG_LEVEL_IF or RIG_LEVEL_CWPITCH, both somewhat ambigous.
RIG_LEVEL_IF deals with the "IF shift", while RIG_LEVEL_CWPITCH
is in fact the BFO. The latter is probably what you're looking for.

> > 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.

73
-- 
Stephane - F8CFE