HI all, just joined the group new to sdr but an old Ham G4bxc ,Have a FCD and a
High Sierra Microwave H F converter 5-55 mhz ,but when i try to use the bias tee
power  it switch's on and off when i change freq, even when the bios tee box is
ticked ,also i cant seem to turn it off to enable me to use external dc .Help
please.  best  73s Harold G4bxc

What soft are you using???
If you use the right dll together with a winradclone (or simons sdr console)
then the phantom power should work
If you use the fchid frontend then make sure to use the right one
There is a basic frontend and a full frontend with the if saettings i(q
correction etc.)

... did you upgrade the firmware of the new fcd?!?

The newest firmware solves a few things

Basic firmware is just for test in the lab after producing the fcd ... so
upgrading to new firmware is needed!!

Give us some details to better help you

Greetz

Sigi
Dg9bfc (a happy fcd owner *g*)

> -----Ursprüngliche Nachricht-----
> Von: FCDevelopment@...
> [mailto:FCDevelopment@...] Im Auftrag von haroldpearce94
> Gesendet: Samstag, 21. Januar 2012 21:11
> An: FCDevelopment@...
> Betreff: [FCDevelopment] Bias tee
>
>
>
> HI all, just joined the group new to sdr but an old Ham G4bxc ,Have a FCD
> and a High Sierra Microwave H F converter 5-55 mhz ,but when i try to use
> the bias tee power it switch's on and off when i change freq, even when
> the bios tee box is ticked ,also i cant seem to turn it off to enable me
> to use external dc .Help please. best 73s Harold G4bxc
>
>
>
>

Hi Harold,

Perhaps we need some further clarification.

I'm using SDR Console 1.5 Build 879 and when I select the Bias Tee box
it stays checked when I change frequency while it's powering the
FCD-5-55-UC. Unchecking the box does indeed turn off the bias tee
feature. The FCD-5-55-UC also has the external DC feedthru which can be
used to power the converter if the bias tee feature is not available on
the early versions of the FCD.

But be sure that you don't have external DC power applied to the
converter while you try to power it from the FCD.

Regards...Bill - N6GHz

On 1/21/2012 1:10 PM, haroldpearce94 wrote:
> HI all, just joined the group new to sdr but an old Ham G4bxc ,Have a
> FCD and a High Sierra Microwave H F converter 5-55 mhz ,but when i try
> to use the bias tee power it switch's on and off when i change freq,
> even when the bios tee box is ticked ,also i cant seem to turn it off to
> enable me to use external dc .Help please. best 73s Harold G4bxc
>
>

--
Regards...Bill Ress
High Sierra Microwave

Did you upgrade the firmware to 18i???

Dg9bfc
Sigi


> -----Ursprüngliche Nachricht-----
> Von: FCDevelopment@...
> [mailto:FCDevelopment@...] Im Auftrag von Harold Pearce
> Gesendet: Sonntag, 22. Januar 2012 10:38
> An: FCDevelopment@...
> Cc: siegfried.jackstien@...
> Betreff: Re: AW: [FCDevelopment] Bias tee
>
>
>
> Hi Siegfried
>
> Thanks for the swift reply. I am currently using v1.1FCD, v1.5beta build
> 847 software.
>
>
> Thanks again for your very useful reply
>
> Regards
>
> Harold G4BXC
>
> ________________________________
>
> From: siegfried jackstien <siegfried.jackstien@...>
> To: FCDevelopment@...
> Sent: Saturday, 21 January 2012, 21:25
> Subject: AW: [FCDevelopment] Bias tee
>
>
>
> What soft are you using???
> If you use the right dll together with a winradclone (or simons sdr
> console)
> then the phantom power should work
> If you use the fchid frontend then make sure to use the right one
> There is a basic frontend and a full frontend with the if saettings i(q
> correction etc.)
>
> ... did you upgrade the firmware of the new fcd?!?
>
> The newest firmware solves a few things
>
> Basic firmware is just for test in the lab after producing the fcd ... so
> upgrading to new firmware is needed!!
>
> Give us some details to better help you
>
> Greetz
>
> Sigi
> Dg9bfc (a happy fcd owner *g*)
>
> > -----Ursprüngliche Nachricht-----
> > Von: FCDevelopment@...
> <mailto:FCDevelopment%40yahoogroups.co.uk>
> > [mailto:FCDevelopment@...
> <mailto:FCDevelopment%40yahoogroups.co.uk> ] Im Auftrag von haroldpearce94
> > Gesendet: Samstag, 21. Januar 2012 21:11
> > An: FCDevelopment@...
> <mailto:FCDevelopment%40yahoogroups.co.uk>
> > Betreff: [FCDevelopment] Bias tee
> >
> >
> >
> > HI all, just joined the group new to sdr but an old Ham G4bxc ,Have a
> FCD
> > and a High Sierra Microwave H F converter 5-55 mhz ,but when i try to
> use
> > the bias tee power it switch's on and off when i change freq, even when
> > the bios tee box is ticked ,also i cant seem to turn it off to enable me
> > to use external dc .Help please. best 73s Harold G4bxc
> >
> >
> >
> >
>
>
>
>
>
>

Hmm ... as far as i know the newest is not 18.6 (18f) ..
Newest is 18i or 18.9 ....
That solves a few "faults" like wrong filter setting in some frequencies and
"a glitch" that some stations reported caused by a timing fault (I don’t
remember well and can not exactly explain it so other group members maybe
can explain that better)....

So newest is 18 india

Greetz sigi

Dg9bfc


> -----Ursprüngliche Nachricht-----
> Von: FCDevelopment@...
> [mailto:FCDevelopment@...] Im Auftrag von Harold Pearce
> Gesendet: Montag, 23. Januar 2012 13:06
> An: FCDevelopment@...
> Cc: siegfried.jackstien@...
> Betreff: Re: AW: AW: [FCDevelopment] Bias tee
>
>
>
>
>
>
> ________________________________
>
> From: siegfried jackstien <siegfried.jackstien@...>
> To: FCDevelopment@...
> Sent: Sunday, 22 January 2012, 16:11
> Subject: AW: AW: [FCDevelopment] Bias tee
>
>
>
> Did you upgrade the firmware to 18i???
>
> Dg9bfc
> Sigi
>
> HI Sigi ,Idid upgrade to18 6  when Ifirst had the fcd  ,regards H, G4bxc
>
> > -----Ursprüngliche Nachricht-----
> > Von: FCDevelopment@...
> <mailto:FCDevelopment%40yahoogroups.co.uk>
> > [mailto:FCDevelopment@...
> <mailto:FCDevelopment%40yahoogroups.co.uk> ] Im Auftrag von Harold Pearce
> > Gesendet: Sonntag, 22. Januar 2012 10:38
> > An: FCDevelopment@...
> <mailto:FCDevelopment%40yahoogroups.co.uk>
> > Cc: siegfried.jackstien@...
> <mailto:siegfried.jackstien%40freenet.de>
> > Betreff: Re: AW: [FCDevelopment] Bias tee
> >
> >
> >
> > Hi Siegfried
> >
> > Thanks for the swift reply. I am currently using v1.1FCD, v1.5beta build
> > 847 software.
> >
> >
> > Thanks again for your very useful reply
> >
> > Regards
> >
> > Harold G4BXC
> >
> > ________________________________
> >
> > From: siegfried jackstien <siegfried.jackstien@...
> <mailto:siegfried.jackstien%40freenet.de> >
> > To: FCDevelopment@...
> <mailto:FCDevelopment%40yahoogroups.co.uk>
> > Sent: Saturday, 21 January 2012, 21:25
> > Subject: AW: [FCDevelopment] Bias tee
> >
> >
> >
> > What soft are you using???
> > If you use the right dll together with a winradclone (or simons sdr
> > console)
> > then the phantom power should work
> > If you use the fchid frontend then make sure to use the right one
> > There is a basic frontend and a full frontend with the if saettings i(q
> > correction etc.)
> >
> > ... did you upgrade the firmware of the new fcd?!?
> >
> > The newest firmware solves a few things
> >
> > Basic firmware is just for test in the lab after producing the fcd ...
> so
> > upgrading to new firmware is needed!!
> >
> > Give us some details to better help you
> >
> > Greetz
> >
> > Sigi
> > Dg9bfc (a happy fcd owner *g*)
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: FCDevelopment@...
> <mailto:FCDevelopment%40yahoogroups.co.uk>
> > <mailto:FCDevelopment%40yahoogroups.co.uk>
> > > [mailto:FCDevelopment@...
> <mailto:FCDevelopment%40yahoogroups.co.uk>
> > <mailto:FCDevelopment%40yahoogroups.co.uk> ] Im Auftrag von
> haroldpearce94
> > > Gesendet: Samstag, 21. Januar 2012 21:11
> > > An: FCDevelopment@...
> <mailto:FCDevelopment%40yahoogroups.co.uk>
> > <mailto:FCDevelopment%40yahoogroups.co.uk>
> > > Betreff: [FCDevelopment] Bias tee
> > >
> > >
> > >
> > > HI all, just joined the group new to sdr but an old Ham G4bxc ,Have a
> > FCD
> > > and a High Sierra Microwave H F converter 5-55 mhz ,but when i try to
> > use
> > > the bias tee power it switch's on and off when i change freq, even
> when
> > > the bios tee box is ticked ,also i cant seem to turn it off to enable
> me
> > > to use external dc .Help please. best 73s Harold G4bxc
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>

Harold,

I think what Sigi is trying to tell you nicely is that to use bias tee you need
to upgrade to a version of firmware that supports it.

As far as I know 18f does not and you need to upgrade to 18i.

Do that and if it still doesn't work ask another question.

Regards

Simon.
G0FCU.

--- In FCDevelopment@..., "siegfried jackstien"
<siegfried.jackstien@...> wrote:
>
> Hmm ... as far as i know the newest is not 18.6 (18f) ..
> Newest is 18i or 18.9 ....
> That solves a few "faults" like wrong filter setting in some frequencies and
> "a glitch" that some stations reported caused by a timing fault (I don't
> remember well and can not exactly explain it so other group members maybe
> can explain that better)....
>
> So newest is 18 india
>
> Greetz sigi
>
> Dg9bfc
>

Alberto,

You are correct but 18j is shown on the website as being in testing. So only for expert users?

Simon.

Ahh yes ... correct ... i made a mistake there
18.10 is latest :-)

Dg9bfc
Sigi

I should not answer emails before my first coffee :-)

> -----Ursprüngliche Nachricht-----
> Von: FCDevelopment@...
> [mailto:FCDevelopment@...] Im Auftrag von Alberto I2PHD
> Gesendet: Dienstag, 24. Januar 2012 10:57
> An: FCDevelopment@...
> Betreff: Re: AW: [FCDevelopment] Bias tee
>
>
>
> --- In FCDevelopment@...
> <mailto:FCDevelopment%40yahoogroups.co.uk> , "siegfried jackstien"
> <siegfried.jackstien@...> <mailto:siegfried.jackstien@...>  wrote:
> >
> > Hmm ... as far as i know the newest is not 18.6 (18f) ..
> > Newest is 18i or 18.9 ....
>
> Isn't the latest 18j  (18.10) ? Or am I missing something ?
>
> --
> 73 Alberto I2PHD
>
>

I have upgraded the firmware and software , bios tee now working , once again
thanks for your help Bill, Sigi, Sam. Bill I must congratulate you on your HSM
5-55 Mhz Converter ,it is a very good piece of equipment that gives great HF
results with the FCD ,Plus price wise  it is very good value .With great back up
from High Sierra Microwave.
                                         Regards Harold G4bxc

Hello harold
Bias tee DOES work if you use the right software
Either use the full frontend (where is a button for phantom power)

Or use the extio driver dll with phantom power for using fcd with a winrad
clone (there is a driver with and one without phantom power!!)

Dg9bfc
Sigi



> -----Ursprüngliche Nachricht-----
> Von: FCDevelopment@...
> [mailto:FCDevelopment@...] Im Auftrag von haroldpearce94
> Gesendet: Samstag, 28. Januar 2012 07:16
> An: FCDevelopment@...
> Betreff: [FCDevelopment] Bios tee
>
>
>
> I have upgraded the firmware and software , bios tee now working , once
> again thanks for your help Bill, Sigi, Sam. Bill I must congratulate you
> on your HSM 5-55 Mhz Converter ,it is a very good piece of equipment that
> gives great HF results with the FCD ,Plus price wise it is very good value
> .With great back up from High Sierra Microwave.
> Regards Harold G4bxc
>
>
>
>

Hi All,

I am new in this list, I do not own a FunCube myself, but
as the author of Linrad, a fairly general SDR program I am
interested in having the FunCube dongle working well with
my software.

Linrad works with a couple of different ExtIO dll files, but
there are problems with the ExtIO_FCD_G0MJW.dll file for
FunCube.

Sometimes it works, sometimes it does not. It seems to me that
there is a bug in the dll that causes writes outside some
buffer area. I can move the dll load and call to the InitHW
entry to various places in the Linrad code and as it turns out
the result differs in an unexpected way. The original
place (linrad-03.33 and earlier) sometimes works, sometimes not.
By making the load library and InitHW the very first statements
in the Linrad code it seems I can get the FunCube work reliably.

When I move the FC initialization further down the code in
Linrads main routine some places make the dll work, but cause
an error on the exit from Linrad. It seems that placing the
FC stuff first when all data memory is undefined makes writes
outside bounds harmless.

I have searched info about this dll but I found nothing.
In what environment is it built? Can it be built for
Linux and Mac OS X also?

73

Leif / SM5BSZ

It is writtein in Borland BDS2006 and if there is a bug I am not at all
surprised as I am not a programmer. The question is where is the bug?

Porting to a differnt environment would be difficult but not impossible. The
main problem is it is a lot of work if you are not familiar with the new
environment.

Mike

--- In FCDevelopment@..., Leif Asbrink <leif@...> wrote:
>
> Hi All,
>
> I am new in this list, I do not own a FunCube myself, but
> as the author of Linrad, a fairly general SDR program I am
> interested in having the FunCube dongle working well with
> my software.
>
> Linrad works with a couple of different ExtIO dll files, but
> there are problems with the ExtIO_FCD_G0MJW.dll file for
> FunCube.
>
> Sometimes it works, sometimes it does not. It seems to me that
> there is a bug in the dll that causes writes outside some
> buffer area. I can move the dll load and call to the InitHW
> entry to various places in the Linrad code and as it turns out
> the result differs in an unexpected way. The original
> place (linrad-03.33 and earlier) sometimes works, sometimes not.
> By making the load library and InitHW the very first statements
> in the Linrad code it seems I can get the FunCube work reliably.
>
> When I move the FC initialization further down the code in
> Linrads main routine some places make the dll work, but cause
> an error on the exit from Linrad. It seems that placing the
> FC stuff first when all data memory is undefined makes writes
> outside bounds harmless.
>
> I have searched info about this dll but I found nothing.
> In what environment is it built? Can it be built for
> Linux and Mac OS X also?
>
> 73
>
> Leif / SM5BSZ
>

Hello Mike,


> It is writtein in Borland BDS2006 and if there is
> a bug I am not at all surprised as I am not a
> programmer. The question is where is the bug?
Well, hard to say without access to the source code;-)

> Porting to a differnt environment would be difficult
> but not impossible. The main problem is it is a lot
> of work if you are not familiar with the new environment.
I am not familiar to BDS2006 so I have no idea what
specific functions it might supply and to what extent
you are using them. It would however be pretty
straight-forward to run the source code through the latest
version of the gcc compiler.

Error checking is improving over time and today the
gcc compiler will detect a lot of errors that were not
detected by earlier compilers.

Maybe there is an option in BDS2006 to enable a debug
option to do boundary checking. It seems to me that the
problem could be caused by writes outside allocated memory.

73

Leif  /  SM5BSZ


>
> Mike
>
> --- In FCDevelopment@..., Leif Asbrink <leif@...> wrote:
> >
> > Hi All,
> >
> > I am new in this list, I do not own a FunCube myself, but
> > as the author of Linrad, a fairly general SDR program I am
> > interested in having the FunCube dongle working well with
> > my software.
> >
> > Linrad works with a couple of different ExtIO dll files, but
> > there are problems with the ExtIO_FCD_G0MJW.dll file for
> > FunCube.
> >
> > Sometimes it works, sometimes it does not. It seems to me that
> > there is a bug in the dll that causes writes outside some
> > buffer area. I can move the dll load and call to the InitHW
> > entry to various places in the Linrad code and as it turns out
> > the result differs in an unexpected way. The original
> > place (linrad-03.33 and earlier) sometimes works, sometimes not.
> > By making the load library and InitHW the very first statements
> > in the Linrad code it seems I can get the FunCube work reliably.
> >
> > When I move the FC initialization further down the code in
> > Linrads main routine some places make the dll work, but cause
> > an error on the exit from Linrad. It seems that placing the
> > FC stuff first when all data memory is undefined makes writes
> > outside bounds harmless.
> >
> > I have searched info about this dll but I found nothing.
> > In what environment is it built? Can it be built for
> > Linux and Mac OS X also?
> >
> > 73
> >
> > Leif / SM5BSZ
> >
>
>

Hi All,

Noise blankers are sometimes very efficient in reducing man made
noise. It is well known however that strong signals within the
blanker bandwidth often renders the blanker useless.

Today, with SDR technology it is possible to do much better, but
as far as I know not very much work has yet been put into developing
appropriate algorithms.

I write this mail because I want to come in contact with people who
have these specific circumstances in receiver operation:


1) Strong local QRN (preferrably powerline in dry weather that
    disappears in rainy weather.)

2) A conventional noise blanker works well and reduces the
    interference by at least 3 S units (when there is no strong
    signal on an adjacent frequency.)

3) The ability to copy weak signals is completely lost when a
    strong signal is present on an adjacent frequency because
    the blanker will then not work.

4) In case the problems are detected with some conventional
    transceiver, an attempt to resolve it by use of a SDR
    system (borrowed or your own) has not led to a significant
    improvement.


In case you find yourself as a candidate to meet the above
requirements I have a great interest in getting wideband
recordings from a SDR system at your location.

Please respond to leif[[[at]]]sm5bsz.com

Some QRN situations can already be managed quite well with
Linrad and I need good examples to demonstrate how to use
the Linrad noise blankers.

Other QRN situations can not be well managed within Linrad
and I am interested in the wideband recordings to be able
to use them for the developmment of better algorithms.

73

Leif  /  SM5BSZ

http://sm5bsz.com

In developing a library that will be able to handle multiple FUNcube dongles
simultaneously, I have been hampered by the lack of a USB serial number (which
would allow me to uniquely specify which device I would like to access).

I just noticed that the documentation for configuring WRPlus
(http://www.funcubedongle.com/MyImages/WRPlusConfigurationForFCD.pdf) includes a
screenshot showing USB info including a serial number.

Is there some way to access a unique FCD identifier from the host? If not, is
there a chance that a new firmware revision could be created that has the
ability to load a serial string from a currently unused area of flash
(0x7720-0x7e00 in 18j)?

If this functionality were added, I would be more than willing to provide code
for supporting this during firmware upgrades.

If anyone is interested, my current prototype library can be found at
http://github.com/jrcutler/libfcd. It presently has a fully functional command
line firmware update tool that works under Linux and Mac OSX, but it is still
missing a lot of the application mode functionality.

Thanks,

  - Justin

Hi all

This may interest you if you are using qthid on a linux
dual core system and you are getting segfaults.

I am using qthid qit commit 807b3d116...  Sun Jan 29 17:22:19 2012 +0100

I am running linux debian wheezy on a system with a dual core
processor. The software builds fine.

When I run qthid, it crashes within a second or so with a segfault.

However, it I disable one of the two processor cores, I can get
qthid to run for hours at a time without crashing. The command
I use to take one or the cores offline is like this, as root:

   # echo 0 | sudo tee /sys/devices/system/cpu/cpu1/online

With this change, qthid becomes usable for me, whereas without
this change qthid does not work.

Does this suggest where the problem in the source code might be?
I was thinking of some kind of locking/concurrency problem, though
I have no idea how to find it.

 

Hi all

This may interest you if you are using qthid on a linux
dual core system and you are getting segfaults.

I am using qthid qit commit 807b3d116... Sun Jan 29 17:22:19 2012 +0100

I am running linux debian wheezy on a system with a dual core
processor. The software builds fine.

When I run qthid, it crashes within a second or so with a segfault.

However, it I disable one of the two processor cores, I can get
qthid to run for hours at a time without crashing. The command
I use to take one or the cores offline is like this, as root:

# echo 0 | sudo tee /sys/devices/system/cpu/cpu1/online

With this change, qthid becomes usable for me, whereas without
this change qthid does not work.

Does this suggest where the problem in the source code might be?
I was thinking of some kind of locking/concurrency problem, though
I have no idea how to find it.

I've been working with qthid under Ubuntu 11.10 (64-bit), and I have not seen
any multicore-related issues.

The current master branch of qthid does have a crash bug that occurs when
attempting to close the firmware update dialog, but I have not seen any others.

Have you tried the 3.x branch? It has been quite stable for a long time.

  - Justin

--- In FCDevelopment@..., Jesus Martínez <jmtormo@...> wrote:
>
> Samsung R70 Core 2 2.0 GHz dual core, 32 bits Ubuntu 11.10 no problem at
> all.
>
> May be problems are with 64 bits multicore compilations?
>
> Best regards.
>
>
> 2012/3/15 John Melton <john.d.melton@...>
>
> > **
> >
> >
> > Hi,
> >
> > I am running a version of qthid on my Ubuntu 11.10 system which is an
> > Intel i5 with 2 cores and 2 threads per core so it looks like 4 cores and
> > not having any problems with segfaults.
> >
> > However, I am using a version I modified to work with my HPSDR
> > server/client software but I would not have thought that would have made
> > any difference apart from the fact that I am not using the qthid GUI to set
> > the frequency as the remote client is sending commands to do that.
> >
> > I added 2 modules, 1 to accept the TCP connection from the DSP server to
> > send process commands to set the frequency and another to take the I/Q
> > audio stream and send it as a UDP stream to the DSP Server.
> >
> > It would be interesting to build a debug version and run it with gdb to
> > see where the segfault is occurring.
> >
> > Regards,
> >
> > John g0orx/n6lyt
> >
> >
> >
> >
> > On 15/03/12 12:37, rdinngy wrote:
> >
> >
> >
> > Hi all
> >
> > This may interest you if you are using qthid on a linux
> > dual core system and you are getting segfaults.
> >
> > I am using qthid qit commit 807b3d116... Sun Jan 29 17:22:19 2012 +0100
> >
> > I am running linux debian wheezy on a system with a dual core
> > processor. The software builds fine.
> >
> > When I run qthid, it crashes within a second or so with a segfault.
> >
> > However, it I disable one of the two processor cores, I can get
> > qthid to run for hours at a time without crashing. The command
> > I use to take one or the cores offline is like this, as root:
> >
> > # echo 0 | sudo tee /sys/devices/system/cpu/cpu1/online
> >
> > With this change, qthid becomes usable for me, whereas without
> > this change qthid does not work.
> >
> > Does this suggest where the problem in the source code might be?
> > I was thinking of some kind of locking/concurrency problem, though
> > I have no idea how to find it.
> >
> >
> >
> >
>

Thank you for all your responses.

Some more observations regarding the segfaults I am seeing running qthid.
The presence or otherwise of other USB devices seems to affect how qthid runs.
My machine
has three USB connectors. I typically have a Hauppauge WinTV NOVA-T USB2
dongle plugged and run the vdr daemon that records digital TV and radio
programs.

   robbie@debian:~$ lsusb
   Bus 004 Device 002: ID 0402:7675 ALi Corp.
   Bus 003 Device 022: ID 2040:9301 Hauppauge WinTV NOVA-T USB2 (warm)
   Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
   Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
   Bus 003 Device 020: ID 04d8:fb56 Microchip Technology, Inc.
   robbie@debian:~$

If I shutdown the vdr daemon and unplug the Hauppague dongle then
qthid appears to work more reliably, even with both processor
cores enabled.

There also seems to be an element of luck to getting qthid to
fail. When I first tried it, qthid would segfault before it
had even managed to draw a window on the screen. More recently
it has been harder to get it to fail, though I can still make
this happen if I am persistent. It seems to fail quicker if
I am running it under gdb. There doesn't seem to be any rhyme
or reason to how and when it fails.

justin.r.cutler@... wrote:
> Have you tried the 3.x branch? It has been quite stable for a long time.

I tried the 3.x branch in the git tree, and that was also showing
the problem. I could also make the version in debian package
qthid-fcd-controller fail as well.

John Melton <john.d.melton@...> wrote:
> It would be interesting to build a debug version and run it
> with gdb to see where the segfault is occurring.

I tried running the program under gdb and managed to get some
backtraces after the segfault had happened. These are reproduced
below.

I also tried running qthid using strace and ltrace. I could
get it to fail in both cases, but the output was a bit on the
large side (at 5Mb is one case) and I wasn't sure how to
interpret the output. I haven't provided the strace/ltrace
output but I could do that if was useful and I could find a place
to put it where people could download it.

Jesus Martínez <jmtormo@...> wrote:
> May be problems are with 64 bits multicore compilations?

Yes, I should have mentioned that I am running 64bit kernel
and 64bit userspace debian wheezy. My Hardware is an Acer Aspire
one 522 with an AMD C50 processor, one socket, two cores,
one thread per core.

Alexandru Csete <oz9aec@...> wrote:
> As I recall the problem was only observed on debian squeeze
> with Qt 4.7.3 - Installing Qt 4.7.4 solved the problem.

Yes, I have Qt 4.7.4 . I have included details of the versions
of software components I am using below. I hope I haven't
left any out.

From the backtraces, it looked like the libusb library might be
involved. I had a (very) brief look at the libusb documentation
and spotted that it contained a debugging aid whereby you could
set an environment variable (export LIBUSB_DEBUG=3) and libusb
spits out warning/error messages on stderr. I have supplied a
trace below.

robbie@debian:~$ uname -a
Linux debian 3.2.0-1-amd64 #1 SMP Fri Feb 17 05:17:36 UTC 2012 x86_64 GNU/Linux
robbie@debian:~$

robbie@debian:~$ dpkg -l g++ binutils
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                 Version                             
Description
+++-====================================-====================================-==\
================================================================================\
======
ii  binutils                             2.22-5                              
GNU assembler, linker and binary utilities
ii  g++                                  4:4.6.2-4                           
GNU C++ compiler
robbie@debian:~$

robbie@debian:~$ dpkg -l libusb-1.0-0 libqtgui4 libqtcore4 libc6 libstdc++6
libgcc1 libfontconfig1 libaudio2 libglib2.0-0  libpng12-0 zlib1g libfreetype6
libsm6 libice6 libxrender1 libxext6 libx11-6 libexpat1 libxt6 libxau6 libpcre3
libffi5 libuuid1 libxcb1 libxdmcp6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  libaudio2      1.9.3-4        Network Audio System - shared libraries
ii  libc6          2.13-27        Embedded GNU C Library: Shared libraries
ii  libexpat1      2.0.1-7.2      XML parsing C library - runtime library
ii  libffi5        3.0.10-3       Foreign Function Interface library runtime
ii  libfontconfig1 2.8.0-3.1      generic font configuration library - runtime
ii  libfreetype6   2.4.8-1        FreeType 2 font engine, shared library files
ii  libgcc1        1:4.6.3-1      GCC support library
ii  libglib2.0-0   2.30.2-6       GLib library of C routines
ii  libice6        2:1.0.7-2      X11 Inter-Client Exchange library
ii  libpcre3       8.12-4         Perl 5 Compatible Regular Expression Library
ii  libpng12-0     1.2.47-1       PNG library - runtime
ii  libqtcore4     4:4.7.4-2      Qt 4 core module
ii  libqtgui4      4:4.7.4-2      Qt 4 GUI module
ii  libsm6         2:1.2.0-2      X11 Session Management library
ii  libstdc++6     4.6.3-1        GNU Standard C++ Library v3
ii  libusb-1.0-0   2:1.0.9~rc3-3  userspace USB programming library
ii  libuuid1       2.20.1-4       Universally Unique ID library
ii  libx11-6       2:1.4.4-4      X11 client-side library
ii  libxau6        1:1.0.6-4      X11 authorisation library
ii  libxcb1        1.8-2          X C Binding
ii  libxdmcp6      1:1.1.0-4      X11 Display Manager Control Protocol library
ii  libxext6       2:1.3.0-3      X11 miscellaneous extension library
ii  libxrender1    1:0.9.6-2      X Rendering Extension client library
ii  libxt6         1:1.1.1-2      X11 toolkit intrinsics library
ii  zlib1g         1:1.2.6.dfsg-2 compression library - runtime
robbie@debian:~$

robbie@debian:~/qthid$ export LIBUSB_DEBUG=3
robbie@debian:~/qthid$ ./qthid
libusb:error [libusb_cancel_transfer] cancel transfer failed error -5
libusb:error [libusb_cancel_transfer] cancel transfer failed error -5
libusb:error [libusb_cancel_transfer] cancel transfer failed error -5
libusb:error [libusb_cancel_transfer] cancel transfer failed error -5
libusb:error [libusb_cancel_transfer] cancel transfer failed error -5

[snip lots of repeated messages]

libusb:error [libusb_cancel_transfer] cancel transfer failed error -5
libusb:error [do_close] Device handle closed while transfer was still being
processed, but the device is still connected as far as we know
libusb:warning [do_close] A cancellation for an in-flight transfer hasn't
completed but closing the device handle
Segmentation fault
robbie@debian:~/qthid$

Another run ...

robbie@debian:~$ cd qthid
robbie@debian:~/qthid$ gdb qthid
GNU gdb (GDB) 7.4-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/robbie/qthid/qthid...done.
(gdb) run
Starting program: /home/robbie/qthid/qthid
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe9a4b700 (LWP 20182)]
[Thread 0x7fffe9a4b700 (LWP 20182) exited]
[New Thread 0x7fffe9a4b700 (LWP 20183)]
[Thread 0x7fffe9a4b700 (LWP 20183) exited]
[New Thread 0x7fffe9a4b700 (LWP 20184)]
[Thread 0x7fffe9a4b700 (LWP 20184) exited]
[New Thread 0x7fffe9a4b700 (LWP 20185)]
[Thread 0x7fffe9a4b700 (LWP 20185) exited]
[New Thread 0x7fffe9a4b700 (LWP 20186)]
[Thread 0x7fffe9a4b700 (LWP 20186) exited]
[New Thread 0x7fffe9a4b700 (LWP 20187)]
[Thread 0x7fffe9a4b700 (LWP 20187) exited]
[New Thread 0x7fffe9a4b700 (LWP 20188)]
[Thread 0x7fffe9a4b700 (LWP 20188) exited]
[New Thread 0x7fffe9a4b700 (LWP 20189)]
[Thread 0x7fffe9a4b700 (LWP 20189) exited]
[New Thread 0x7fffe9a4b700 (LWP 20190)]
[Thread 0x7fffe9a4b700 (LWP 20190) exited]
[New Thread 0x7fffe9a4b700 (LWP 20191)]
[Thread 0x7fffe9a4b700 (LWP 20191) exited]
[New Thread 0x7fffe9a4b700 (LWP 20192)]
[Thread 0x7fffe9a4b700 (LWP 20192) exited]
[New Thread 0x7fffe9a4b700 (LWP 20193)]
[Thread 0x7fffe9a4b700 (LWP 20193) exited]
[New Thread 0x7fffe9a4b700 (LWP 20194)]
[Thread 0x7fffe9a4b700 (LWP 20194) exited]
[New Thread 0x7fffe9a4b700 (LWP 20195)]
[Thread 0x7fffe9a4b700 (LWP 20195) exited]
[New Thread 0x7fffe9a4b700 (LWP 20196)]
[Thread 0x7fffe9a4b700 (LWP 20196) exited]
[New Thread 0x7fffe9a4b700 (LWP 20197)]
[Thread 0x7fffe9a4b700 (LWP 20197) exited]
[New Thread 0x7fffe9a4b700 (LWP 20198)]
[Thread 0x7fffe9a4b700 (LWP 20198) exited]
[New Thread 0x7fffe9a4b700 (LWP 20199)]
[Thread 0x7fffe9a4b700 (LWP 20199) exited]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bd35a1 in libusb_submit_transfer () from
/lib/x86_64-linux-gnu/libusb-1.0.so.0
(gdb) bt
#0  0x00007ffff7bd35a1 in libusb_submit_transfer () from
/lib/x86_64-linux-gnu/libusb-1.0.so.0
#1  0x00007ffff7bd4ed7 in libusb_control_transfer () from
/lib/x86_64-linux-gnu/libusb-1.0.so.0
#2  0x000000000041c319 in libusb_get_string_descriptor (data=0x7fffffffdda0
"x\336\377\377\377\177", desc_index=0 '\000', length=64, langid=0, dev=0x899770)
     at /usr/include/libusb-1.0/libusb.h:1315
#3  is_language_supported (lang=2057, dev=0x899770) at hid-libusb.c:285
#4  get_usb_string (dev=0x899770, idx=1 '\001') at hid-libusb.c:326
#5  0x000000000041c82e in hid_enumerate (vendor_id=1240, product_id=64342) at
hid-libusb.c:479
#6  0x0000000000411f82 in fcdOpen () at fcd.c:58
#7  0x000000000041315e in fcdAppGetParam (u8Cmd=<optimized out>,
pu8Data=0x7fffffffdfcf "\017\360\341\377\377\377\177", u8len=1 '\001') at
fcd.c:826
#8  0x000000000040b84f in MainWindow::readDevice (this=0x7fffffffe1f0) at
mainwindow.cpp:522
#9  0x000000000040c448 in MainWindow::enableControls (this=0x7fffffffe1f0) at
mainwindow.cpp:661
#10 0x000000000040c9b7 in MainWindow::MainWindow (this=0x7fffffffe1f0,
parent=<optimized out>) at mainwindow.cpp:393
#11 0x000000000040b136 in main (argc=1, argv=<optimized out>) at main.cpp:33
(gdb)


A third run...

robbie@debian:~/qthid$ gdb qthid
GNU gdb (GDB) 7.4-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/robbie/qthid/qthid...done.
(gdb) run
Starting program: /home/robbie/qthid/qthid
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe9a4b700 (LWP 20244)]
[Thread 0x7fffe9a4b700 (LWP 20244) exited]
[New Thread 0x7fffe9a4b700 (LWP 20245)]
[Thread 0x7fffe9a4b700 (LWP 20245) exited]
[New Thread 0x7fffe9a4b700 (LWP 20246)]

[Snip lot of repeat messages]

[Thread 0x7fffe9a4b700 (LWP 20315) exited]
[New Thread 0x7fffe9a4b700 (LWP 20316)]
[Thread 0x7fffe9a4b700 (LWP 20316) exited]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bd3563 in libusb_submit_transfer () from
/lib/x86_64-linux-gnu/libusb-1.0.so.0
(gdb) bt
#0  0x00007ffff7bd3563 in libusb_submit_transfer () from
/lib/x86_64-linux-gnu/libusb-1.0.so.0
#1  0x00007ffff7bd4ed7 in libusb_control_transfer () from
/lib/x86_64-linux-gnu/libusb-1.0.so.0
#2  0x000000000041c319 in libusb_get_string_descriptor (data=0x7fffffffc7a0
"x\310\377\377\377\177", desc_index=0 '\000', length=64, langid=0, dev=0x898420)
     at /usr/include/libusb-1.0/libusb.h:1315
#3  is_language_supported (lang=2057, dev=0x898420) at hid-libusb.c:285
#4  get_usb_string (dev=0x898420, idx=1 '\001') at hid-libusb.c:326
#5  0x000000000041c82e in hid_enumerate (vendor_id=1240, product_id=64342) at
hid-libusb.c:479
#6  0x0000000000411f82 in fcdOpen () at fcd.c:58
#7  0x00000000004125d0 in fcdAppSetFreqkHz (nFreq=50005) at fcd.c:410
#8  0x000000000040bba6 in MainWindow::setNewFrequency (this=0x7fffffffe1f0,
freq=<optimized out>) at mainwindow.cpp:690
#9  0x000000000041c9dd in MainWindow::qt_metacall (this=0x7fffffffe1f0,
_c=QMetaObject::InvokeMetaMethod, _id=<optimized out>, _a=0x7fffffffcb70)
     at moc_mainwindow.cpp:125
#10 0x00007ffff6c13eba in QMetaObject::activate(QObject*, QMetaObject const*,
int, void**) () from /usr/lib/libQtCore.so.4
#11 0x000000000041cd9d in CFreqCtrl::NewFrequency (this=<optimized out>,
_t1=50013000) at moc_freqctrl.cpp:84
#12 0x00000000004142ef in CFreqCtrl::SetFrequency (this=0x7fa560,
freq=<optimized out>) at freqctrl.cpp:238
#13 0x0000000000414d53 in IncFreq (this=0x7fa560) at freqctrl.cpp:715
#14 CFreqCtrl::IncFreq (this=0x7fa560) at freqctrl.cpp:704
#15 0x00007ffff71513ca in QWidget::event(QEvent*) () from /usr/lib/libQtGui.so.4
#16 0x00007ffff74f54d6 in QFrame::event(QEvent*) () from /usr/lib/libQtGui.so.4
#17 0x00007ffff7100c64 in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() from /usr/lib/libQtGui.so.4
#18 0x00007ffff71061e6 in QApplication::notify(QObject*, QEvent*) () from
/usr/lib/libQtGui.so.4
#19 0x00007ffff6c0128c in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
from /usr/lib/libQtCore.so.4
#20 0x00007ffff71a0ef9 in QKeyMapper::sendKeyEvent(QWidget*, bool, QEvent::Type,
int, QFlags<Qt::KeyboardModifier>, QString const&, bool, int, unsigned int,
unsigned int, unsigned int, bool*) () from /usr/lib/libQtGui.so.4
#21 0x00007ffff71a133b in QKeyMapperPrivate::translateKeyEvent(QWidget*, _XEvent
const*, bool) () from /usr/lib/libQtGui.so.4
#22 0x00007ffff717cb04 in QApplication::x11ProcessEvent(_XEvent*) () from
/usr/lib/libQtGui.so.4
#23 0x00007ffff71a5252 in x11EventSourceDispatch(_GSource*, int (*)(void*),
void*) () from /usr/lib/libQtGui.so.4
#24 0x00007ffff545a0cf in g_main_context_dispatch () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x00007ffff545a8c8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#26 0x00007ffff545aa99 in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x00007ffff6c2be2f in
QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /usr/lib/libQtCore.so.4
#28 0x00007ffff71a4eee in
QGuiEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /usr/lib/libQtGui.so.4
#29 0x00007ffff6c00492 in
QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from
/usr/lib/libQtCore.so.4
#30 0x00007ffff6c0068f in
QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from
/usr/lib/libQtCore.so.4
#31 0x00007ffff6c04837 in QCoreApplication::exec() () from
/usr/lib/libQtCore.so.4
#32 0x000000000040b14d in main (argc=1, argv=<optimized out>) at main.cpp:36
(gdb)

Is the FCD always on the same port when you use it; that is you are using a UDEV
rule to force it to always be consistent on the port? (I know this is a
requirement in the instructions at 
http://sourceforge.net/projects/qthid/files/3.0/

Using a UDEV rule for the WinTV as well might help as that appears to be causing
hiccups.

73 - Andy

--- In FCDevelopment@..., "rdinngy" <rdinngy@...> wrote:
>
>
>
> Thank you for all your responses.
>
> Some more observations regarding the segfaults I am seeing running qthid.
> The presence or otherwise of other USB devices seems to affect how qthid runs.
My machine
> has three USB connectors. I typically have a Hauppauge WinTV NOVA-T USB2
> dongle plugged and run the vdr daemon that records digital TV and radio
> programs.

Hello ve3nvk

--- In FCDevelopment@..., "ve3nvk" <andylhart@...> wrote:
>
> Is the FCD always on the same port when you use it; that is you are using a
UDEV rule to force it to always be consistent on the port? (I know this is a
requirement in the instructions at 
http://sourceforge.net/projects/qthid/files/3.0/
>

I don't know about always using the same port but I do have the
added udev rule in place, like so:

robbie@debian:~$ cat /etc/udev/rules.d/20-fcd.rules
SUBSYSTEM=="usb" ATTR{idVendor}=="04d8" ATTR{idProduct}=="fb56" MODE:="0666"
SYMLINK+="FCD"
robbie@debian:~$ ls -l /dev/FCD
lrwxrwxrwx 1 root root 13 Mar 21 10:13 /dev/FCD -> snd/controlC2
robbie@debian:~$ ls -l /dev/snd/by-path/
total 0
lrwxrwxrwx 1 root root 12 Mar 18 08:51 pci-0000:00:01.1 -> ../controlC0
lrwxrwxrwx 1 root root 12 Mar 18 08:51 pci-0000:00:12.0-usb-0:3:1.0 ->
../controlC2
lrwxrwxrwx 1 root root 12 Mar 18 08:51 pci-0000:00:14.2 -> ../controlC1
robbie@debian:~$ ls -l /dev/snd/by-id/
total 0
lrwxrwxrwx 1 root root 12 Mar 18 08:51
usb-Hanlincrest_Ltd._FUNcube_Dongle_V1.0-00 -> ../controlC2
robbie@debian:~$ ls -l /dev/snd/controlC2
crw-rw-rwT+ 1 root audio 116, 10 Mar 18 08:51 /dev/snd/controlC2

> Using a UDEV rule for the WinTV as well might help as that appears to be
causing hiccups.
>

To be honest I can't find the udev rule for the USB DVB adapter.
It must be present somewhere because the entry under /dev/dvb/
automagically appears when I plug the DVB dongle in. I tend to
be grateful when udev makes the entries under /dev appear and
kind of stuck when they don't appear.

I think udev is working fine.

> 73 - Andy
>
> --- In FCDevelopment@..., "rdinngy" <rdinngy@> wrote:
> >
> >
> >
> > Thank you for all your responses.
> >
> > Some more observations regarding the segfaults I am seeing running qthid.
> > The presence or otherwise of other USB devices seems to affect how qthid
runs. My machine
> > has three USB connectors. I typically have a Hauppauge WinTV NOVA-T USB2
> > dongle plugged and run the vdr daemon that records digital TV and radio
> > programs.
>

Greetings,

I am happy to inform all users of Funcube Dongle + GNU Radio, that the
gr-fcd driver is now included in the GNU Radio source tree. You can
read the announcement here:
http://lists.gnu.org/archive/html/discuss-gnuradio/2012-03/msg00442.html

This change will be available in the next GNU Radio release, which I
think will be 3.5.3. If you pull the code from the GNU Radio git
repository the changes are already in your tree. Before you upgrade
please remove any earlier installations of gr-fcd to avoid conflicting
versions of the library.

My repository on Github https://github.com/csete/gr-fcd will no longer
be maintained and any future development of gr-fcd will be done within
the scope of the GNU Radio project. I hope this will ensure better
integration, more maintainers, more testing and easier installation
process.

Have a nice weekend!

Alex
OZ9AEC

Hi...

I'm having a heck of a time trying to get Qt's QAudioInput working with the FCD.

Under Windows. Spectraview reads the thing fine, so I think the FCD is ok with
its sample rate of 96000 and 16 bit data and 2 channels.

But within Qt, I create a QAudioInput with these settings, and cannot get more
than a few buffers full of data before the QAudioInput stops sending data to my
writable QObject.

I copied the example from the Qt docs, modified just slightly (I know what my
data format is, don't need to check for others) and... it just doesn't seem to
do the right thing. I receive about 2 seconds of good data, which demodulates to
proper signal as expected, and then..... nothing.

Am I missing something here? Anyone have any insight into what might be going
wrong?

--Ben
AA7AS