headers
Nate Bargmann | 3 Jun 2011 23:37
Picon
Favicon
Gravatar

Re: Elecraft's RVM command

* On 2011 28 May 09:23 -0500, Alexander Sack wrote:
> git patch attached, what do you think?  I plan to extend this
> depending on P3 support.  I just want an initial reaction.

Hi Alexander.

I've tested your patch locally and it works well.  I have created a test
branch, n0nb_k3, for the moment before merging it into the master
branch.  You can clone a tree from:

git clone -b n0nb_k3 git://hamlib.git.sourceforge.net/gitroot/hamlib/hamlib

I also changed the rig_debug output levels so that most of the messages
will be printed at a level of VERBOSE (rigctl -vvvv) with a couple at
ERR and a couple more at WARN in elecraft.c, k2.c and k3.c.  Let me know
what you think.  This should allow checking variables without having to
dig through the TRACE output.

73, de Nate >>

--

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexander Sack | 4 Jun 2011 01:48
Picon
Gravatar

Re: Elecraft's RVM command

On Fri, Jun 3, 2011 at 5:37 PM, Nate Bargmann <n0nb <at> n0nb.us> wrote:
> * On 2011 28 May 09:23 -0500, Alexander Sack wrote:
>> git patch attached, what do you think?  I plan to extend this
>> depending on P3 support.  I just want an initial reaction.
>
> Hi Alexander.
>
> I've tested your patch locally and it works well.  I have created a test
> branch, n0nb_k3, for the moment before merging it into the master
> branch.  You can clone a tree from:
>
> git clone -b n0nb_k3 git://hamlib.git.sourceforge.net/gitroot/hamlib/hamlib
>
> I also changed the rig_debug output levels so that most of the messages
> will be printed at a level of VERBOSE (rigctl -vvvv) with a couple at
> ERR and a couple more at WARN in elecraft.c, k2.c and k3.c.  Let me know
> what you think.  This should allow checking variables without having to
> dig through the TRACE output.

Nate, will do and thanks!  With the holiday and then work commitments
I have had not a lot of time to play.  Next week should be much
different!  :-)

I will clone and take a look soon.

-aps

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Petr Hlozek | 7 Jun 2011 08:56

Re: hamlib and microHAM interfaces

Hi,

any progress about microham support? A lot of people have this device
and it would be great to have support for it in hamlib.

73 Petr, OK2CQR

2011/5/6 Nate Bargmann <n0nb <at> n0nb.us>:
> * On 2011 05 May 16:22 -0500, Artem Prilutskiy wrote:
>> Hi there!
>>
>> I think you know what interfaces microHAM stand out, if we are talking about connecting the transceiver
to the computer. These interfaces have a great feature, well-made and have their own proprietary
protocol for data transmission.
>> Not so long ago acquired MK2 and the Station Master, I attended to provide support for Mac OS X. There is one
amateur who has implemented a solution (uH Router), implements the interaction with Mac OS X.
>> He pursued his goal, but I they are somewhat different. Thus at the moment I have some documentation and
inputs to work with interfaces microHAM.
>> If you are interested in support microHAM hamlib, I am ready to give you the source code, documentation,
carry out some development and testing.
>
> Hi Artem.  Welcome to Hamlib.
>
> It sounds like you could provide us with a nice addition to Hamlib.  We
> ask that all contributions to the libraries be licensed under the LGPL.
> You are free to implement the backend as you see fit, but anything that
> touches the frontend code (Rig API and files under src/) require mailing
> list discussion.  Most questions are answered in the README.betatester
> and README.developer files.
>
(Continue reading)

Permalink | Reply | 8 comments |
headers
Nate Bargmann | 7 Jun 2011 15:24
Picon
Favicon
Gravatar

Re: Rationalizing the Elecraft P3

* On 2011 28 May 09:16 -0500, Alexander Sack wrote:
> Hello Folks:

Hi Alexander.

> Alright I have a P3 sitting in front of me connected to my beloved K3.
>  If you are unfamiliar with the P3 its is a self-contained panadapter
> accessory for the K3:
> 
> http://www.elecraft.com/P3/p3.htm

You're going to get me to buy one, huh?  ;)

> The way I see it, even though the P3 can be used with other rigs, 99%
> of its use is with a K3.  As a result, I'd like to think of P3 as an
> extension to the K3 (and probably the KX3 given it comes with I/Q out
> from the get go).  I agree this is debatable.

Even though it is probably going to be most used with the K3, it is its
own device so it should probably be treated separately.

> If you grok the P3 programmer's manual, Elecraft even gives you
> discovery protocol to determine if you have just a K3 vs just a P3 vs
> both via serial passthrough.
> 
> [Note:  I discovered a new RVM command (see patch in next email) which
> is applicable to the K3 and I think useful, patch in next email]

Applied and in the n0nb_k3 branch in Git.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nate Bargmann | 7 Jun 2011 15:49
Picon
Favicon
Gravatar

Re: [Fwd: Re: K3 (and K2?) RIT clear in hamlib]

* On 2011 27 May 13:42 -0500, RT Clay wrote:
> Note that I would also be happy with just adding a new rig_rit_clear (or similar) that clears the RIT offset
but doesn't turn it on/off. The rest of the API could then be left as-is.

Could we implement it as an ext_parm for the time being as we did with
the FI command?  I agree that at some point the addition of a
rig_rit_clear/rig_xit_clear set of functions to the API would be a good
idea.  

73, de Nate >>

--

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
Permalink | Reply | 6 comments |
headers
RT Clay | 7 Jun 2011 19:21

Re: [Fwd: Re: K3 (and K2?) RIT clear in hamlib]

Yes, I think using set_ext_parm would work.

Tor
N4OGW

--- On Tue, 6/7/11, Nate Bargmann <n0nb <at> n0nb.us> wrote:

> From: Nate Bargmann <n0nb <at> n0nb.us>
> Subject: Re: [Hamlib-developer] [Fwd: Re: K3 (and K2?) RIT clear in hamlib]
> To: hamlib-developer <at> lists.sourceforge.net
> Cc: "RT Clay" <rt_clay <at> bellsouth.net>
> Date: Tuesday, June 7, 2011, 8:49 AM
> * On 2011 27 May 13:42 -0500, RT Clay
> wrote:
> > Note that I would also be happy with just adding a new
> rig_rit_clear (or similar) that clears the RIT offset but
> doesn't turn it on/off. The rest of the API could then be
> left as-is.
> 
> Could we implement it as an ext_parm for the time being as
> we did with
> the FI command?  I agree that at some point the
> addition of a
> rig_rit_clear/rig_xit_clear set of functions to the API
> would be a good
> idea.  
> 
> 73, de Nate >>
> 
> --
(Continue reading)

Permalink | Reply | 5 comments |
headers
Nate Bargmann | 8 Jun 2011 01:17
Picon
Favicon
Gravatar

Re: [Fwd: Re: K3 (and K2?) RIT clear in hamlib]

* On 2011 07 Jun 12:22 -0500, RT Clay wrote:
> Yes, I think using set_ext_parm would work.

I actually used rig_set_ext_level with a token name of 'ritclr' and the
value parameter is ignored.  

At the moment the changes are in the n0nb_k3 branch of the Git
repository.  I can make a custom tarball if you'd like to test from that.

74, de Nate >>

--

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
Permalink | Reply | 4 comments |
headers
Nate Bargmann | 8 Jun 2011 01:49
Picon
Favicon
Gravatar

RFC--Toward API version 3

Without trying to hint that API version 2 may be getting a bit long in
the tooth, I think it is remarkable that our API and ABI have been
unchanged since February 16, 2004!  In theory, a program linked against
1.2.0 *should* work with 1.2,13.1 without a recompile/relink.  That is
remarkable.

In every endeavor there is always room for improvement and Hamlib is no
exception.  The past few weeks have seen requests for additional API
interfaces to support advanced features of the Elecraft K3.  I have no
doubt that there are other rigs presented to the marketplace over the
past seven years that we could better support with a few tweaks.

While I am thinking of a set of rig_rit_clear() and rig_xit_clear()
prototypes, there is also the idea I presented in another thread about a
specific API for panadapters, similar in concept to the rotor API.
There are surely more ideas for additional functionality and API tweaks.

Also, are there higher level functions API 3 could support that are
now missing?  What could be improved from an application programmer's
perspective?

My immediate idea is to create an API_3 Git branch where these ideas
could be incubated.  It would make sense to merge various changes from
master (current API 2) into it to keep backend commits and such in sync.
I'm guessing this could be a long-lived branch and that we will see
1.2.15 and perhaps even 1.2.16 released before 1.3.0 which means a year
from now or even early 2013 for the earliest possible API 3 release.

Comments please!
(Continue reading)

Permalink | Reply | 5 comments |
headers
Stephane Fillod | 8 Jun 2011 13:59
Picon
Favicon

Re: RFC--Toward API version 3

Tue, Jun 07, 2011, Nate Bargmann skribis:
> Without trying to hint that API version 2 may be getting a bit long in
> the tooth, I think it is remarkable that our API and ABI have been
> unchanged since February 16, 2004!  In theory, a program linked against
> 1.2.0 *should* work with 1.2,13.1 without a recompile/relink.  That is
> remarkable.

Blame me for the long-term stability, also blame me for some of
the interface inertia :-/

> In every endeavor there is always room for improvement and Hamlib is no
> exception.  The past few weeks have seen requests for additional API
> interfaces to support advanced features of the Elecraft K3.  I have no
> doubt that there are other rigs presented to the marketplace over the
> past seven years that we could better support with a few tweaks.
> 
> While I am thinking of a set of rig_rit_clear() and rig_xit_clear()
> prototypes, there is also the idea I presented in another thread about a
> specific API for panadapters, similar in concept to the rotor API.
> There are surely more ideas for additional functionality and API tweaks.
> 
> Also, are there higher level functions API 3 could support that are
> now missing?  What could be improved from an application programmer's
> perspective?

I am also in favor of API3. Let's allow us to break the ABI, at the
frontend and at the backend level.
However, as far as possible, do not break the frontend API source-wise,
in order to prevent the burden on end-user programs. Adding new calls
like rig_rit_clear() and rig_xit_clear() is fine, since they extend API 2.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jeff Steinkamp | 8 Jun 2011 15:10

Yaesu FT-450

Have there been reported issues with the FT-450 backend?  I've got a 
couple of users reporting that hamlib is completely unstable using this 
backend, in my PropNET software and FLDigi.

--

-- 
Jeff K. Steinkamp N7YG
Tucson, AZ
SCUD Missile Coordinates:
N032-13-55.02  W110-55-52.79
Registered Linux User: 420428
------------------------------------------------------

STU Star Trek Universe

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
Permalink | Reply | 6 comments |

Gmane