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 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:
http://www.youtube.com/watch?v=daY-fkMYN_M

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: https://github.com/csete/qthid 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]in.invalid
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 :slight_smile:

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
http://www.sbrac.org

On 02/22/2011 07:00 PM, Johnathan C. wrote:

Johnathan
So, you have it implemented then, Jonathan? :slight_smile: :slight_smile:


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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? :slight_smile: :slight_smile:

Send me the hardware :slight_smile:

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 :slight_smile:

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 :slight_smile:

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 :slight_smile:


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs