Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Stephane Fillod <f8cfe <at> free.fr>
Subject: Re: hamlib
Newsgroups: gmane.linux.hams.hamlib.devel
Date: Thursday 20th January 2011 18:59:04 UTC (over 6 years ago)
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


------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
 
CD: 4ms