fldigi crashes hamlib_init not working rig not responding

 [root <at> localhost W8JSA]# fldigi --cpu-speed-test
I: main: CPU speed factor=86.217943: setting slowcpu=false,
sample_converter="Medium Sinc Interpolator"
I: testCommPorts: Found serial port /dev/ttyS0
I: testCommPorts: Found serial port /dev/ttyS1
I: testCommPorts: Found serial port /dev/ttyS2
I: testCommPorts: Found serial port /dev/ttyS3
I: testCommPorts: Found serial port /dev/ttyUSB0
E: show_error: hamlib_init: Rig not responding
E: show_error: hamlib_init: Rig not responding
E: show_error: hamlib_init: Rig not responding
E: show_error: hamlib_init: Rig not responding
E: show_error: hamlib_init: Rig not responding
E: show_error: hamlib_init: Rig not responding
E: show_error: hamlib_init: Rig not responding
E: show_error: hamlib_init: Rig not responding

Caught signal 11
Aborting fldigi due to a fatal error.
Please report this to:   fldigi-devel <at> lists.berlios.de
or file a bug report at: https://fedorahosted.org/fldigi/newticket

****** Stack trace:
fldigi[0x4e5930]
/lib64/libpthread.so.0[0x330160f440]
fldigi[0x511735]
fldigi[0x51468e]
fldigi[0x51490b]
fldigi[0x539e80]
fldigi[0x53b4c5]

Re: fldigi crashes hamlib_init not working rig not responding

* On 2010 02 Oct 07:20 -0500, JS Austin W8JSA wrote:
> ****** Version information:
> fldigi 3.20.20

Hi Jeff.

Do you get the same error with Fldigi 3.20.28?  There should not be a
problem with a newer Hamlib and an older Fldigi, but one never quite
knows for certain until a problem crops up.

Also, what radio are you using?  What are the serial parameters, or
can't you even get that far?

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://n0nb.us/index.html

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

[CORRECTED COPY] Re: fldigi crashes hamlib_init not working rig not responding

 On 02/10/10 08:44 AM, Nate Bargmann wrote:
> * On 2010 02 Oct 07:20 -0500, JS Austin W8JSA wrote:
>> ****** Version information:
>> fldigi 3.20.20
> Hi Jeff.
>
> Do you get the same error with Fldigi 3.20.28?  There should not be a
> problem with a newer Hamlib and an older Fldigi, but one never quite
> knows for certain until a problem crops up.
>
> Also, what radio are you using?  What are the serial parameters, or
> can't you even get that far?
>
> 73, de Nate >>
>
Nate,
I'm running 3.20.20 as that is latest *.rpm available and the version of
HamLib is 1.2.12-1. I had a IC-781 running but due to problems with the
radio itself I put my backup rig, IC-765, in its place. The sound card
is a HDA NVidia with the Realtek chip ALC1200. The version of ALSA is
1.0.23-1. I was working with a Ham in the UK, don't remember his call,
and had tried to work him on 30m. If I can't hear them can work them.
Fldigi doesn't recognize the 765 but did the 781.

I know that the 781 is unstable while the 765 is stable. I did get a
waterfall and copy a short QSO. Then fldigi started becoming unstable
again and then crashed. Only once did debug info come up so I could send
a bug report.

I'm a firefighter and not a code hacker. Got in ham radio in '92 as a

Re: [CORRECTED COPY] Re: fldigi crashes hamlib_init not working rig not responding

* On 2010 02 Oct 16:03 -0500, JS Austin W8JSA wrote:
> I'm a firefighter and not a code hacker. Got in ham radio in '92 as a
> stress reliever. Right now up stress level is going up because I don't
> know what I'm doing wrong. I have gone threw all the help files and have
> even erased and reinstalled fldigi, hamlib, alsa among a couple of
> others. I'm beginning to think that maybe I don't know what I'm doing
> period.

I'm a hobbyist coder myself so I understand where you're coming from.
Don't despair.  If need be, use Fldigi's RigCAT until we get your issue
sorted out.  

When you get the chance, could you test your rig model with the rigctl
utility?  Be sure to add the -vvvvv option as that will help diagnose
issues.  If your distribution includes it, Hamlib's README.betatester
file will have info to help you test and send this information to the
mailing list.

> Forgot to mention that I'm running Fedora 13 with the latest upgrades
> and on the hardware side the RIGblaster P-n-P

Is the rig control done through the P-n-P?  If so, I presume that is not
the issue as you were probably using your '781 with it.

73, de Nate >>

--

-- 

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

Re: Omni VII testing

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

_______________________________________________
Hamlib-developer mailing list
Hamlib-developer <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hamlib-developer

kenwood_open: wrong driver selected (220 instead of 219)

 Hello all, Im trying my hand at controlling my Kenwood TH-F6A but am
running into issues starting 'rigctld' after version 1.2.10 of hamlib.
The following is the verbose cli output from various versions. I am
using a usb to serial if thats worth anything also.

This is 'media-libs/hamlib-1.2.10' found in portage.

#rigctld -vvvvv -m 220 -r
/dev/ttyUSB0                                                                                                                            

rigctld, Hamlib version 1.2.10
Report bugs to <hamlib-developer <at> lists.sourceforge.net>

rig:rig_init called
rig: loading backend kenwood
kenwood: _init called
rig_register (213)
rig_register (201)
rig_register (225)
rig_register (203)
rig_register (204)
rig_register (216)
rig_register (224)
rig_register (205)
rig_register (207)
rig_register (209)
rig_register (210)
rig_register (222)
rig_register (214)
rig_register (230)
rig_register (221)
rig_register (229)
rig_register (202)
rig_register (211)
rig_register (206)
rig_register (208)
rig_register (215)
rig_register (226)
rig_register (217)
rig_register (220)
rig_register (223)
rig_register (227)
rig_register (228)
kenwood_init
kenwood_init: if_len = 38
rig:rig_open called
thf7_get_vfo: called
kenwood_transaction: BC
TX 3 bytes
0000     42 43 0d       BC.
RX 5 characters
0000     42 43 20 30 0d BC 0.
kenwood_transaction: VMC 0
TX 6 bytes
0000     56 4d 43 20 30 0d      VMC 0.
RX 8 characters
0000     56 4d 43 20 30 2c 30 0d        VMC 0,0.
Opened rig model 220, 'TH-F7E'
Backend version: 0.3, Status: Beta
^C

This is 'media-libs/hamlib-1.2.11' found in portage, 1.2.12 results in
the same 'error' as well as the latest version I checked out earlier today.

#rigctld, Hamlib
1.2.11                                                                                                                                              

Report bugs to <hamlib-developer <at> lists.sourceforge.net>

rig:rig_init called
rig: loading backend kenwood
kenwood: _init called
rig_register (213)
rig_register (201)
rig_register (225)
rig_register (203)
rig_register (204)
rig_register (216)
rig_register (224)
rig_register (205)
rig_register (207)
rig_register (209)
rig_register (210)
rig_register (222)
rig_register (214)
rig_register (230)
rig_register (221)
rig_register (229)
rig_register (202)
rig_register (211)
rig_register (206)
rig_register (208)
rig_register (215)
rig_register (226)
rig_register (217)
rig_register (220)
rig_register (223)
rig_register (227)
rig_register (228)
kenwood_init
kenwood_init: if_len = 38
rig:rig_open called
kenwood_open
kenwood_transaction: ID
TX 3 bytes
0000    49 44 0d                                           ID.
RX 9 characters
0000    49 44 20 54 48 2d 46 36 0d                         ID TH-F6.
kenwood_open: found match TH-F6
kenwood_open: wrong driver selected (220 instead of 219)
rig_open: error = Invalid parameter
#

/usr/local/bin/rigctld -vvvvv -m 219 -r
/dev/ttyUSB0                                                                                                          

rigctld, Hamlib
1.2.13svn                                                                                                                                           

Report bugs to <hamlib-developer <at> lists.sourceforge.net>

rig:rig_init called
rig: loading backend kenwood
kenwood: _init called
rig_register (213)
rig_register (201)
rig_register (225)
rig_register (203)
rig_register (204)
rig_register (216)
rig_register (224)
rig_register (205)
rig_register (207)
rig_register (209)
rig_register (210)
rig_register (222)
rig_register (214)
rig_register (230)
rig_register (221)
rig_register (229)
rig_register (202)
rig_register (211)
rig_register (206)
rig_register (208)
rig_register (215)
rig_register (226)
rig_register (217)
rig_register (220)
rig_register (223)
rig_register (227)
rig_register (228)
Unknown rig num 219, or initialization error.
Please check with --list option.

There are no drivers listed as 219.

Im sorry Im unable to supply a patch.

Please let me know if more information is needed or wanted.
Thanks to all the devs and testers.
Take care,

KC9QEN
Scott

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

Re: kenwood_open: wrong driver selected (220 instead of 219)

* On 2010 02 Oct 19:30 -0500, Scott Martin wrote:
>  Hello all, Im trying my hand at controlling my Kenwood TH-F6A but am
> running into issues starting 'rigctld' after version 1.2.10 of hamlib.
> The following is the verbose cli output from various versions. I am
> using a usb to serial if thats worth anything also.
> This is 'media-libs/hamlib-1.2.10' found in portage.
> 
> #rigctld -vvvvv -m 220 -r

Hi Scott.

The tf-h6a is model number 219 so I'm curious why you chose 220

> Opened rig model 220, 'TH-F7E'
> Backend version: 0.3, Status: Beta

which Hamlib confirms here?

> This is 'media-libs/hamlib-1.2.11' found in portage, 1.2.12 results in
> the same 'error' as well as the latest version I checked out earlier today.
> 
> #rigctld, Hamlib
> 1.2.11                                                                                                                                              
> kenwood_open
> kenwood_transaction: ID
> TX 3 bytes
> 0000    49 44 0d                                           ID.
> RX 9 characters
> 0000    49 44 20 54 48 2d 46 36 0d                         ID TH-F6.
> kenwood_open: found match TH-F6
> kenwood_open: wrong driver selected (220 instead of 219)
> rig_open: error = Invalid parameter

So the backend is at least identifying the radio correctly and then
saying that the incorrect model number was chosen.  Good.

> /usr/local/bin/rigctld -vvvvv -m 219 -r
> /dev/ttyUSB0                                                                                                          
> 
> rigctld, Hamlib
> 1.2.13svn                                                                                                                                           
> Unknown rig num 219, or initialization error.
> Please check with --list option.
> 
> There are no drivers listed as 219.

There was a reorganization of the backend libraries recently.  Please be
sure that you uninstall all prior versions of Hamlib, in fact,
uninstalling all versions waon't hurt.  Then install 1.2.13svn again and
afterward you will probably need to run `ldconfig' as root so the linker
can find the backend libraries in their new location.

> Im sorry Im unable to supply a patch.

At this time I don't think a patch is necessary.

> Please let me know if more information is needed or wanted.

Please let us know if you can get things going with the SVN snapshot.
Also, if you want to use rigctld, version 1.2.11 is really the first
version where it became more or less usable.  There are likely still a
few bugs to be found.  

> Thanks to all the devs and testers.

You're welcome.

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://n0nb.us/index.html

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

Re: kenwood_open: wrong driver selected (220 instead of 219)

 Im in the processes of setting up a 'clean' chroot to see if I can
isolate this further.

On 10/02/2010 09:15 PM, Nate Bargmann wrote:
> * On 2010 02 Oct 19:30 -0500, Scott Martin wrote:
>>  Hello all, Im trying my hand at controlling my Kenwood TH-F6A but am
>> running into issues starting 'rigctld' after version 1.2.10 of hamlib.
>> The following is the verbose cli output from various versions. I am
>> using a usb to serial if thats worth anything also.
>> This is 'media-libs/hamlib-1.2.10' found in portage.
>>
>> #rigctld -vvvvv -m 220 -r
> Hi Scott.
>
> The tf-h6a is model number 219 so I'm curious why you chose 220
220 'worked' prior to the back end rework using the F7E backend.
>> Opened rig model 220, 'TH-F7E'
>> Backend version: 0.3, Status: Beta
> which Hamlib confirms here?
This was from 1.2.10 that worked more.
>> This is 'media-libs/hamlib-1.2.11' found in portage, 1.2.12 results in
>> the same 'error' as well as the latest version I checked out earlier today.
>>
>> #rigctld, Hamlib
>> 1.2.11                                                                                                                                              
>> kenwood_open
>> kenwood_transaction: ID
>> TX 3 bytes
>> 0000    49 44 0d                                           ID.
>> RX 9 characters
>> 0000    49 44 20 54 48 2d 46 36 0d                         ID TH-F6.
>> kenwood_open: found match TH-F6
>> kenwood_open: wrong driver selected (220 instead of 219)
>> rig_open: error = Invalid parameter
> So the backend is at least identifying the radio correctly and then
> saying that the incorrect model number was chosen.  Good.
I was trying to find the commit from BC (byte code Im guessing) to ID.
That im gathering the issue is somewhere in there.
>> /usr/local/bin/rigctld -vvvvv -m 219 -r
>> /dev/ttyUSB0                                                                                                          
>>
>> rigctld, Hamlib
>> 1.2.13svn                                                                                                                                           
>> Unknown rig num 219, or initialization error.
>> Please check with --list option.
>>
>> There are no drivers listed as 219.
If you see here I did try with rig switch 219 to no avail.
> There was a reorganization of the backend libraries recently.  Please be
> sure that you uninstall all prior versions of Hamlib, in fact,
> uninstalling all versions waon't hurt.  Then install 1.2.13svn again and
> afterward you will probably need to run `ldconfig' as root so the linker
> can find the backend libraries in their new location.
I am very confident I have removed the previous versions so no conflict
would have occurred there, ldconfig was ran as well to update the linker
prior to running.
>> Im sorry Im unable to supply a patch.
> At this time I don't think a patch is necessary.
>
>> Please let me know if more information is needed or wanted.
> Please let us know if you can get things going with the SVN snapshot.
> Also, if you want to use rigctld, version 1.2.11 is really the first
> version where it became more or less usable.  There are likely still a
> few bugs to be found.  
>
>> Thanks to all the devs and testers.
> You're welcome.
>
> 73, de NAte >>
>

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

Re: kenwood_open: wrong driver selected (220 instead of 219)

* On 2010 02 Oct 21:54 -0500, Scott Martin wrote:
>  Im in the processes of setting up a 'clean' chroot to see if I can
> isolate this further.

I am seeing the same error with model 219 as you are so there is
definitely a bug.  I'm not too familiar with the Kenwood backend so I
don't even know where or if the thf6a was defined at any point in time.
I guess it's time for the Kenwood experts to chime in.

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://n0nb.us/index.html

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

Re: [linuxham] fldigi and hamlib's rigctld

* On 2010 16 Sep 16:46 -0500, Pierfrancesco Caci wrote:
> [pse Cc when replying, I'm not subscribed to hamlib-dev]

I've not forgotten about this, just busy.

> Please see:
> http://snoopy.tippete.net/~ik5pvx/tlf/rigctld+fldigi.txt.gz

There seems to be a number of errors between the backend and your radio.
I think we need one of the Kenwood experts to help you with this.

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://n0nb.us/index.html

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev