headers
Nate Bargmann | 2 Jun 2012 15:11
Picon
Favicon
Gravatar

Please test TS-950 backend (was Re: Kenwood TS950SD users?)

* On 2012 29 Mar 21:05 -0500, Martin Ewing wrote:
> OK.  I think you're right.  My reference is the more recent manual:
> "TS-950series External Control Instruction Manual", which is available from
> the kenwood web site.  It covers all the '950 models.  I had not noticed
> the mode info in the IF command.

I've just committed a patch to the master branch that enables the
get_mode_if function for the TS-950 series.  If possible, this needs
some testing before I cherry-pick it into the 1.2.15 branch for release
in a couple of months.

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 | 2 comments |
headers
Jerry Kaidor | 2 Jun 2012 17:56
Favicon

Intro and problem

Hello,

   My name is Jerry Kaidor.  I was first licensed around 1970.  Ham radio
got me into electronics, and electronics ( and cheap computers ) got me
into programming, and I did real time embedded software development for
a living for 20 years.  Was off the air for many years, and just got
back on a month ago.  Am very happy that the Internet didn't kill off
ham radio!

  Right now, I am trying to get fldigi software working with my new
Kenwood TS-590S.  The current problem may not be the fault of hamlib at
all, but it seems to be the way to get at it.  The Kenwood has a
built-in USB interface ( surely the wave of the future! ) and you cannot
simply stick a terminal
on the serial port like you used to be able with RS-232.

  The version of hamlib in use by fldigi is 1.2.15.1.

  On startup, fldigi tries to get some status out of the Kenwood - find
out which VFO, what frequency etc.  This is unsuccessful.  The Kenwood
simply does not respond, and the request times out.  The initial request
strings are IF; and MD;   I have connected to the Kenwood with minicom,
and these commands work just fine.  The Kenwood immediately responds
with its frequency and a bunch of other stuff.

   After startup, fldigi is able to send commands to the Kenwood.  It can
set the frequency, send PTT commands etc.  The audio stuff works.

   I have compiled both hamlib and fldigi from source.  I have stuck in my
own debug printf's as appropriate to try and find out what's going on.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Nate Bargmann | 2 Jun 2012 18:52
Picon
Favicon
Gravatar

Re: Intro and problem

* On 2012 02 Jun 10:03 -0500, Jerry Kaidor wrote:
> Hello,
> 
>    My name is Jerry Kaidor.  I was first licensed around 1970.  Ham radio
> got me into electronics, and electronics ( and cheap computers ) got me
> into programming, and I did real time embedded software development for
> a living for 20 years.  Was off the air for many years, and just got
> back on a month ago.  Am very happy that the Internet didn't kill off
> ham radio!

Hi Jerry.

Welcome back and no, the 'Net hasn't killed off amateur radio although
it certainly has enabled and forced many changes.  The greatest boon is
the ability to work together to enhance the hobby.

>   Right now, I am trying to get fldigi software working with my new
> Kenwood TS-590S.  The current problem may not be the fault of hamlib at
> all, but it seems to be the way to get at it.  The Kenwood has a
> built-in USB interface ( surely the wave of the future! ) and you cannot
> simply stick a terminal
> on the serial port like you used to be able with RS-232.
> 
>   The version of hamlib in use by fldigi is 1.2.15.1.
> 
>   On startup, fldigi tries to get some status out of the Kenwood - find
> out which VFO, what frequency etc.  This is unsuccessful.  The Kenwood
> simply does not respond, and the request times out.  The initial request
> strings are IF; and MD;   I have connected to the Kenwood with minicom,
> and these commands work just fine.  The Kenwood immediately responds
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jerry Kaidor | 2 Jun 2012 20:54
Favicon

Re: Intro and problem


>
>>    I also tried installing the current development version of hamlib -
>> it
>> simply did not work with fldigi at all.  Has there been a major change
>> in the API?
>
> The ABI version differs in the development version as we do plan some
> API changes.  I would think that if Fldigi were compiled against the dev
> Hamlib that it should still work.  A version of Fldigi compiled against
> the 1.2 Hamlib series will not work.

*** I just built and installed the hamlib-3.0-git. The I went to my fldigi
source and said "make clean;make;sudo make install.  Then I ran fldigi
and it said:

fldigi: error while loading shared libraries: libhamlib.so.3: cannot open
shared object file: No such file or directory

  Interestingly, rigctl gives the same error.

There does exist /usr/local/lib/libhamlib.so.3->libhamlib.so.3.0.0
and... -rwxr-xr-x 1 root root 375993 Jun  2 10:10 libhamlib.so.3.0.0

>
> More debugging info and your change would probably be helpful.
*** Thank you.  It's very simple.  And honestly, it's possibly one of
those things that's a 50-50.  Make data PTT default, and the Mic guys are
unhappy.  And vice versa :).
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nate Bargmann | 2 Jun 2012 23:03
Picon
Favicon
Gravatar

Re: Intro and problem

* On 2012 02 Jun 12:33 -0500, Jerry Kaidor wrote:
> *** I just built and installed the hamlib-3.0-git. The I went to my fldigi
> source and said "make clean;make;sudo make install.  Then I ran fldigi
> and it said:
> 
> 
> fldigi: error while loading shared libraries: libhamlib.so.3: cannot open
> shared object file: No such file or directory
> 
>   Interestingly, rigctl gives the same error.

Did you run 'ldconfig' as root?

> There does exist /usr/local/lib/libhamlib.so.3->libhamlib.so.3.0.0
> and... -rwxr-xr-x 1 root root 375993 Jun  2 10:10 libhamlib.so.3.0.0

I'm guessing the runtime linker doesn't know where to find the
libraries.  Running 'ldconfig' should solve that.

> > More debugging info and your change would probably be helpful.
> *** Thank you.  It's very simple.  And honestly, it's possibly one of
> those things that's a 50-50.  Make data PTT default, and the Mic guys are
> unhappy.  And vice versa :).
> 
>    BTW, yes I absolutely am using Linux.  Ubuntu 12.04 at the moment.  I
> use windows for my business workstations, but would not dream of using
> it for something that's supposed to be fun like ham radio :).

Good attitude, Jerry.  :-D
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rick Kunath | 2 Jun 2012 23:15
Favicon

Re: Intro and problem

Coming in this late I think, but comments inline...

On Saturday, June 02, 2012 04:03:15 PM Nate Bargmann wrote:
> * On 2012 02 Jun 12:33 -0500, Jerry Kaidor wrote:
> > *** I just built and installed the hamlib-3.0-git. The I went to my
> > fldigi source and said "make clean;make;sudo make install.  Then I ran
> > fldigi and it said:

That's:

./configure
(make clean if needed)
make
sudo make install

> > 
> > 
> > fldigi: error while loading shared libraries: libhamlib.so.3: cannot
> > open
> > shared object file: No such file or directory
> > 
> >   Interestingly, rigctl gives the same error.

You have the hamlibs inthe /usr/local tree and the running fldigi is apparently 
looking (as it should) in the /usr tree where binary installed packages go.

> 
> Did you run 'ldconfig' as root?
> 
> > There does exist /usr/local/lib/libhamlib.so.3->libhamlib.so.3.0.0
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Ronan | 4 Jun 2012 17:42
Picon

yfktest/hamlib

Hi,

I started sorting out a laptop for logging for an upcoming field day in 
a few weeks. So I put Ubuntu 12.04 onto my laptop, installed hamlib and 
yfttest. Hamlib is from the distro, not from source, it is version 1.2.14.

Anyway, to test it all with my Elecraft K3 I tormented a few contesters 
Sunday morning with my out-of-practice morse and after making a few  
contacts I left it all running and went for lunch.

When I came back yfktest was hung solid. After some experimentation I 
realised it was rigctld was dying, so I ran it earlier dumping a log 
output and left it.

yfktest is polling about one per second, so the output is quite long and 
I have it here.

http://shack.ei7ig.org/rigctld.txt

Thoughts appreciated.

Regards
John
EI7IG

------------------------------------------------------------------------------
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
(Continue reading)

Permalink | Reply | 12 comments |
headers
Nate Bargmann | 4 Jun 2012 20:58
Picon
Favicon
Gravatar

Re: yfktest/hamlib

* On 2012 04 Jun 10:46 -0500, John Ronan wrote:
> Hi,
> 
> I started sorting out a laptop for logging for an upcoming field day in 
> a few weeks. So I put Ubuntu 12.04 onto my laptop, installed hamlib and 
> yfttest. Hamlib is from the distro, not from source, it is version 1.2.14.
> 
> Anyway, to test it all with my Elecraft K3 I tormented a few contesters 
> Sunday morning with my out-of-practice morse and after making a few  
> contacts I left it all running and went for lunch.
> 
> When I came back yfktest was hung solid. After some experimentation I 
> realised it was rigctld was dying, so I ran it earlier dumping a log 
> output and left it.
> 
> yfktest is polling about one per second, so the output is quite long and 
> I have it here.
> 
> http://shack.ei7ig.org/rigctld.txt
> 
> Thoughts appreciated.

Hi John.

Do you have an estimation on how long things ran before the failure
occured?  Looking at the last part of your output:

rigctl(d): m 'currVFO' '' '' ''
k3_get_mode called
kenwood_get_mode called
(Continue reading)

Permalink | Reply | 11 comments |
headers
John Ronan | 4 Jun 2012 23:03
Picon

Re: yfktest/hamlib


> Hi John.
>
> Do you have an estimation on how long things ran before the failure
> occured?  Looking at the last part of your output:
I'm going to say between 10 and 20 minutes (Who would leave a K3 running 
and doing nothing for that long... but thats a different discussion)

I've made a mod to yfktest to increase the delay between reads slightly, 
and it appears to have solved it. I say appears, in that I went for a 
shower, came back and it was still running.
I'll test it again tomorrow evening.

>
> rigctl(d): m 'currVFO' '' '' ''
> k3_get_mode called
> kenwood_get_mode called
> kenwood_safe_transaction called
> kenwood_transaction called
> kenwood_transaction: cmdstr = MD
> TX 3 bytes
> 0000    4d 44 3b                                            MD;
> RX 1 characters
> 0000    3b                                                  ;
> kenwood_transaction: wrong reply �� for command MD
> TX 3 bytes
> 0000    4d 44 3b                                            MD;
> read_string: timedout without reading a character
> TX 3 bytes
> 0000    4d 44 3b                                            MD;
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Ronan | 5 Jun 2012 22:05
Picon

Re: yfktest/hamlib


Evening,

Right, I left it running when I called over to EI2HIB's QTH earlier.

This is what I got
-- This first bit is from the end of the rigctld log
kenwood_transaction: wrong reply  for command BW
TX 3 bytes
0000    42 57 3b                                            BW;
read_string: timedout without reading a character
TX 3 bytes
0000    42 57 3b                                            BW;
read_string: timedout without reading a character
TX 3 bytes
0000    42 57 3b                                            BW;
read_string: timedout without reading a character
k3_get_mode: Cannot read K3 BW value
fscanf: Success
Connection closed from 127.0.0.1:53729
-- The line above is when I did a Kill -9 of yfktest.

-- I forgot what port rigctld is listening on so checked it before 
trying to connect.
j0n <at> ds9:~/Documents/Source/yfk/yfktest/trunk$ lsof -i
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
rigctld 2095  j0n    4u  IPv4  12813      0t0  TCP *:4532 (LISTEN)
j0n <at> ds9:~/Documents/Source/yfk/yfktest/trunk$ telnet localhost 4532
Trying ::1...
Trying 127.0.0.1...
(Continue reading)

Permalink | Reply | 0 comments |

Gmane