Hi All,
Has anybody tried the FUNCube USB dongle?
http://www.funcubedongle.com/
How tricky would it be to add GNU Radio support for it?
Patrik
On Sat, Feb 19, 2011 at 4:58 PM, Patrik T. [email protected]
wrote:
Hi All,
Has anybody tried the FUNCube USB dongle?
http://www.funcubedongle.com/How tricky would it be to add GNU Radio support for it?
Hi Patrik,
The FCD works as is with GNU Radio since it is an audio source. I used
GNU Radio for my initial tests:
Changing frequency can be done using the qthid control application.
The one on the website is known to crash and freeze. I have since
forked it and applied the necessary fixes to make it run stable. It is
available here: GitHub - csete/qthid: An evolution of the Qt-based Funcube Dongle HID controller. although not quite 100%
stable unless FCD is running the 18f firmware.
Once I’m done with this I will implement the remaining API for setting
gains and filters and eventually there will be a “libfcd” which can be
included in a GNU Radio block.
I’m not sure if it makes sense to create a GNU Radio block for this
since the FCD is already an audio source and a block is not necessary
for setting frequency and such. I guess it would still be useful for
using it in GRC applications.
Alex
On Sat, Feb 19, 2011 at 08:46, Alexandru C. [email protected] wrote:
I’m not sure if it makes sense to create a GNU Radio block for this
since the FCD is already an audio source and a block is not necessary
for setting frequency and such. I guess it would still be useful for
using it in GRC applications.
It would be useful to create a C++ hierarchical block that encapsulates
an
audio source and exposes accessor methods to manipulate the gains and
filters. See the pattern for the gr_channel_model block in the
gnuradio-core/src/lib/hier directory. This would allow use from C++,
Python, and GRC apps.
Johnathan
On Sat, Feb 19, 2011 at 6:08 PM, Johnathan C.
[email protected] wrote:
filters. See the pattern for the gr_channel_model block in the
gnuradio-core/src/lib/hier directory. This would allow use from C++,
Python, and GRC apps.
I see, yes, this makes sense! This block would also take care of
mapping left/right channels to I/Q in a complex output stream.
Alex
Hi Alexandu,
Oh yes, by plugging it into an audio source it will work as is with GR.
We wonder how to rip the I and Q’s and pass them further to GR for
(de)modulation
We need to study the dongle and its ICs more
Thanks,
Patrik
----- Original Message -----
From: “Alexandru C.” [email protected]
To: “Patrik T.” [email protected]
Cc: [email protected]; “Jerry Martes” [email protected]
Sent: Saturday, February 19, 2011 18:46
Subject: Re: [Discuss-gnuradio] FUNCube dongle
Thanks,
We’ll see if we’ll get one and make an attempt
Patrik
----- Original Message -----
From: Johnathan C.
To: Alexandru C.
Cc: [email protected]
Sent: Saturday, February 19, 2011 19:08
Subject: Re: [Discuss-gnuradio] FUNCube dongle
On Sat, Feb 19, 2011 at 08:46, Alexandru C. [email protected]
wrote:
I'm not sure if it makes sense to create a GNU Radio block for this
since the FCD is already an audio source and a block is not
necessary
for setting frequency and such. I guess it would still be useful for
using it in GRC applications.
It would be useful to create a C++ hierarchical block that
encapsulates an audio source and exposes accessor methods to manipulate
the gains and filters. See the pattern for the gr_channel_model block
in the gnuradio-core/src/lib/hier directory. This would allow use from
C++, Python, and GRC apps.
Johnathan
On Sun, Feb 20, 2011 at 10:50 AM, Patrik T. [email protected]
wrote:
Hi Alexandu,
Oh yes, by plugging it into an audio source it will work as is with GR.
We wonder how to rip the I and Q’s and pass them further to GR for
(de)modulation
We need to study the dongle and its ICs more
Not necessary, because we know that one channel contains the I samples
and the other channel contains the Q samples. In GNU Radio it can be
converted to a complex stream using gr_float_to_complex() see attached
screenshot. The complex stream can then be used the same was as you
would use a stream from USRP, except the the sample rate is 96 kHz.
Alex
Oh yeah! That will be the way to do it
Thanks,
Patrik
----- Original Message -----
From: “Alexandru C.” [email protected]
To: “Patrik T.” [email protected]
Cc: [email protected]; “Jerry Martes” [email protected]
Sent: Sunday, February 20, 2011 12:13
Subject: Re: [Discuss-gnuradio] FUNCube dongle
It might more tricky to actually get one!
They sell out in less than a minute.
Yeah, we’ve neen luring on them for some time and seen the batches end
QUICKLY
Thanks all for the GR hints, we’ll try if we get one
Patrik
----- Original Message -----
From: Jeff Kelly
To: Patrik T.
Sent: Saturday, February 19, 2011 18:19
Subject: Re: [Discuss-gnuradio] FUNCube dongle
It might more tricky to actually get one!
They sell out in less than a minute.
From: Patrik T.
Sent: Saturday, February 19, 2011 10:58 AM
To: [email protected]
Cc: Jerry Martes
Subject: [Discuss-gnuradio] FUNCube dongle
Hi All,
Has anybody tried the FUNCube USB dongle?
http://www.funcubedongle.com/
How tricky would it be to add GNU Radio support for it?
Patrik
On 22/02/2011 9:26 AM, Patrick S. wrote:
I think this would be of great use. The FCB is based on the Softrock DDS
design, which evolved to a family of different solutions, with the
common factor of a stereo sound interface and a HID interface for
control like frequency, source multiplexer switch and filter banks.
AFAIK the HID commands are the same in most of these designs. Treating
the system as a single interface much like a USRP would get users rid of
extra programs and doing things every time over again.Patrick
I agree–having a slick UHD/USRP-like interface would be very cool, so
that you can control it entirely from
within a GR flow-graph.
schrieb Alexandru C. am 2011-02-19 17:46:
for setting frequency and such. I guess it would still be useful for
using it in GRC applications.
I think this would be of great use. The FCB is based on the Softrock DDS
design, which evolved to a family of different solutions, with the
common factor of a stereo sound interface and a HID interface for
control like frequency, source multiplexer switch and filter banks.
AFAIK the HID commands are the same in most of these designs. Treating
the system as a single interface much like a USRP would get users rid of
extra programs and doing things every time over again.
Patrick
Engineers motto: cheap, good, fast: choose any two
Patrick S.
Student of Telemati_cs_, Techn. University Graz, Austria
On Tue, Feb 22, 2011 at 9:57 PM, Marcus D. Leech [email protected]
wrote:
Patrick
I agree–having a slick UHD/USRP-like interface would be very cool, so that
you can control it entirely from
within a GR flow-graph.
Well, implementing it as UHD device seems a bit overkill from a
programming
point of view because one would have to implement the “audio source”,
which
is readily available in GNU Radio. So a GNU Radio source just like the
old
pre-UHD USRP drivers seems to be most feasible.
I don’t know much about the Softrock series, but I doubt they have much
in
common with the FCD. Maybe the USB idea and the protocol structure,
which
for the FCD is really trivial and simple streams of 1-4 bytes per
command.
Most of the commands and parameters for the FCD map directly to the
tuner
chip, which I assume is not present in the Softrocks - see attached
screenshot of the windows controller.
Alex
On Tue, Feb 22, 2011 at 15:36, Marcus D. Leech [email protected]
wrote:
On 02/22/2011 06:24 PM, Alexandru C. wrote:
Well, implementing it as UHD device seems a bit overkill from a programming
point of view because one would have to implement the “audio source”, which
is readily available in GNU Radio. So a GNU Radio source just like the old
pre-UHD USRP drivers seems to be most feasible.
If implemented as a C++ hierarchical block, then you can encapsulate an
audio source and the float to complex transformation blocks internally.
You’d hold an instance of the libfcd library and expose an external set
of
accessors that resolve internally into the calls to the libfcd instance.
This is not that much coding, and makes something that works “just like”
a
native GNU Radio block. It would be able to be used in pure C++ GNU
Radio
apps, in Python GNU Radio apps, or instantiated and controlled entirely
from
within a GRC flowgraph.
Johnathan
On 02/22/2011 06:24 PM, Alexandru C. wrote:
O
Well, implementing it as UHD device seems a bit overkill from a
programming point of view because one would have to implement the
“audio source”, which is readily available in GNU Radio. So a GNU
Radio source just like the old pre-UHD USRP drivers seems to be most
feasible.
Yes, I agree–a UHD driver might be too complicated to do, but maybe
not. Maybe we just have to buy Josh an FCD 
I don’t know much about the Softrock series, but I doubt they have
much in common with the FCD. Maybe the USB idea and the protocol
structure, which for the FCD is really trivial and simple streams of
1-4 bytes per command. Most of the commands and parameters for the FCD
map directly to the tuner chip, which I assume is not present in the
Softrocks - see attached screenshot of the windows controller.Alex
The SDR-Widget uses a similar approach–a standard UAC2 audio system,
and HID for setting transceiver-specific “stuff”.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On 02/22/2011 07:00 PM, Johnathan C. wrote:
Johnathan
So, you have it implemented then, Jonathan?
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On Tue, Feb 22, 2011 at 16:09, Marcus D. Leech [email protected]
wrote:
within a GRC flowgraph.
Johnathan
So, you have it implemented then, Jonathan?
Send me the hardware
Johnathan
On Wed, Feb 23, 2011 at 1:00 AM, Johnathan C. <
[email protected]> wrote:
If implemented as a C++ hierarchical block, then you can encapsulate an
audio source and the float to complex transformation blocks internally.
You’d hold an instance of the libfcd library and expose an external set of
accessors that resolve internally into the calls to the libfcd instance.
This is not that much coding, and makes something that works “just like” a
native GNU Radio block. It would be able to be used in pure C++ GNU Radio
apps, in Python GNU Radio apps, or instantiated and controlled entirely from
within a GRC flowgraph.
Yes, I agree with this. With the “overkill” I meant a pure UHD device
that
does not use existing GNU Radio blocks.
Alex
On Tue, Feb 22, 2011 at 16:28, Marcus D. Leech [email protected]
wrote:
Having been unemployed for the last 7 months, and just starting a new job,
anything more expensive than
Ramen noodles is a “luxury item” for me
Congratulations, by the way. Hope your new situation still affords you
time
to work on the odd GNU Radio block now and then.
Johnathan
On 02/22/2011 07:11 PM, Johnathan C. wrote:
Send me the hardware
Johnathan
I don’t have one, but you may have a good case for getting a freebie to
do the Gnu Radio support for it.
Having been unemployed for the last 7 months, and just starting a new
job, anything more expensive than
Ramen noodles is a “luxury item” for me
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
schrieb Alexandru C. am 2011-02-23 00:24:
Well, implementing it as UHD device seems a bit overkill from a
programming point of view because one would have to implement the “audio
source”, which is readily available in GNU Radio. So a GNU Radio source
just like the old pre-UHD USRP drivers seems to be most feasible.
Wasn’t there a plan do have some abstract hardware block, that can be
configured to use whatever hardware interface that is available, much
like the audio interface? It’s quite painful to have code bound to some
hardware, when all you need is to rename the instantiated hardware block
to use other hardware.
AFIR some interface was proposed to reflect the capabilities of the
interface (tuning characteristics, gain, subdevice selection), which
could be set at runtime or from the config files. And of course some
logic to automatically select the available device - or the best
available device if more than one connected. I think they call it
“convention over configuration” and “configuration over code”.
Just my 2