headers
Nate Bargmann | 16 Jun 2012 01:50
Picon
Favicon
Gravatar

K2 backend changes need testing

I've committed a minor pair of changes to the K2 backend that I would
like to see tested from an actual K2 owner.

The first is a minor change that simply tests if the filter bandwidth is
negative and uses the absolute value for the width.  This should solve
any cases where this happens.

The second tests width for the value of RIG_PASSBAND_NORMAL and sets
width to the value returned by rig_passband_normal() which *should* be
correct for the mode, but my K3 doesn't seem to select the CW or RTTY
"normal" filter width of 500 Hz.  Testing on a real K <at>  would be much
appreciated.

Look for hamlib-1.2.15.2~rc2-20120615.tar.gz at
http://n0nb.users.sourceforge.net/ and give a try.  I am interested in
feedback on this before the 1.2.15.2 release around August 1.

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions
(Continue reading)

Permalink | Reply |
headers
chris bryant | 23 Jun 2012 15:26
Picon

Re: K2 backend changes need testing

Hi Nate,

On Fri, 2012-06-15 at 18:50 -0500, Nate Bargmann wrote:

> The first is a minor change that simply tests if the filter bandwidth is
> negative and uses the absolute value for the width.  This should solve
> any cases where this happens.

With apologies for delay (and unwanted line wrapping on some of the
output), here's results with my K2 in CW mode.

My filter widths in CW are OP1, 1.33, 950, 470.
rigctl with -ve bandwidth:

Rig command: M CW -400
Mode: Passband: k2_set_mode called
kenwood_set_mode called
rmode2kenwood called
kenwood_safe_transaction called
kenwood_transaction called
kenwood_transaction: cmdstr = MD3
write_block(): TX 4 bytes
0000    4d 44 33 3b
MD3;            
kenwood_safe_transaction called
kenwood_transaction called
kenwood_transaction: cmdstr = K22
write_block(): TX 4 bytes
0000    4b 32 32 3b
K22;
(Continue reading)

Permalink | Reply |
headers
Nate Bargmann | 23 Jun 2012 15:39
Picon
Favicon
Gravatar

Re: K2 backend changes need testing

* On 2012 23 Jun 08:25 -0500, chris bryant wrote:
> Hi Nate,
> 
> 
> On Fri, 2012-06-15 at 18:50 -0500, Nate Bargmann wrote:
> 
> > The first is a minor change that simply tests if the filter bandwidth is
> > negative and uses the absolute value for the width.  This should solve
> > any cases where this happens.
> 
> With apologies for delay (and unwanted line wrapping on some of the
> output), here's results with my K2 in CW mode.
> 
> My filter widths in CW are OP1, 1.33, 950, 470.

I'm heading out the door for ARRL Field Day, but want to reply.  Thanks
for the test, Chris.  Is this the behavior you expect/desire?  I'll look
at it more carefully later tomorrow or when I'm rested.

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

------------------------------------------------------------------------------
Live Security Virtual Conference
(Continue reading)

Permalink | Reply |
headers
chris bryant | 23 Jun 2012 20:57
Picon

Re: K2 backend changes need testing

On Sat, 2012-06-23 at 08:39 -0500, Nate Bargmann wrote:

> I'm heading out the door for ARRL Field Day, but want to reply.  Thanks
> for the test, Chris.  Is this the behavior you expect/desire?  I'll look
> at it more carefully later tomorrow or when I'm rested.

The CW mode request with M CW 0 returns 950 because my narrowest filter
bandwidth is 470 and, as I recall, the logic says to pick the equal or
next value up in bandwidth. So yes, it's expected. As to whether it's
desired, many folk may use a narrowest bandwidth of less than 500Hz. I
think the Elecraft recommendations when setting the filters up first is
for the narrowest to be 150Hz. Is this an argument for making CW normal
a value less than all likely bandwidths, say 100Hz, so M CW 0  always
sets up the narrowest?

73 
Chris G3WIE

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Permalink | Reply |
headers
Nate Bargmann | 24 Jun 2012 02:56
Picon
Favicon
Gravatar

Re: K2 backend changes need testing

* On 2012 23 Jun 13:57 -0500, chris bryant wrote:
> On Sat, 2012-06-23 at 08:39 -0500, Nate Bargmann wrote:
> 
> > I'm heading out the door for ARRL Field Day, but want to reply.  Thanks
> > for the test, Chris.  Is this the behavior you expect/desire?  I'll look
> > at it more carefully later tomorrow or when I'm rested.
> 
> The CW mode request with M CW 0 returns 950 because my narrowest filter
> bandwidth is 470 and, as I recall, the logic says to pick the equal or
> next value up in bandwidth. So yes, it's expected. As to whether it's
> desired, many folk may use a narrowest bandwidth of less than 500Hz. I
> think the Elecraft recommendations when setting the filters up first is
> for the narrowest to be 150Hz. Is this an argument for making CW normal
> a value less than all likely bandwidths, say 100Hz, so M CW 0  always
> sets up the narrowest?

I would say no, but I determine "normal" as being comfortable for casual
operation.  M CW 0 is the same as RIG_PASSBAND_NORMAL so if one wants
100 Hz, it needs to specified, IMO.  ;-)

Keep in mind that for a lot of rigs the "normal" CW position is through
the SSB filter, sometimes with a low pass filter afterward to roll off
the high frequencies and a different BFO offset.  On the K3 I'm setting
1000 Hz for CW normal.  This is probably a personal preference but it
needs to be set to *something*.  Hopefully something somewhat sensible
for most everyone.

Anyway, thanks much for the testing, Chris.

73, de Nate >>
(Continue reading)

Permalink | Reply |
headers
chris bryant | 24 Jun 2012 12:20
Picon

Re: K2 backend changes need testing

On Sat, 2012-06-23 at 19:56 -0500, Nate Bargmann wrote:
> * On 2012 23 Jun 13:57 -0500, chris bryant wrote:
>  Is this an argument for making CW normal
> > a value less than all likely bandwidths, say 100Hz, so M CW 0  always
> > sets up the narrowest?
> 
> I would say no, but I determine "normal" as being comfortable for casual
> operation.  M CW 0 is the same as RIG_PASSBAND_NORMAL so if one wants
> 100 Hz, it needs to specified, IMO.  ;-)
> 
> Keep in mind that for a lot of rigs the "normal" CW position is through
> the SSB filter, sometimes with a low pass filter afterward to roll off
> the high frequencies and a different BFO offset.  On the K3 I'm setting
> 1000 Hz for CW normal.  This is probably a personal preference but it
> needs to be set to *something*.  Hopefully something somewhat sensible
> for most everyone.

Sounds a very sensible approach, Nate

Is there any other K2 testing you'd like me to do?

Chris

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
(Continue reading)

Permalink | Reply |
headers
Nate Bargmann | 24 Jun 2012 21:47
Picon
Favicon
Gravatar

Re: K2 backend changes need testing

* On 2012 24 Jun 05:35 -0500, chris bryant wrote:
> Is there any other K2 testing you'd like me to do?

At this time I can't think of anything specific.  That is the only
recent change to the K2 backend.

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Permalink | Reply |

Gmane