FUNCube dongle

Patrik_T · February 23, 2011, 2:27am

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

Congratulations, by the way. Hope your new situation still affords
you time to work on the odd GNU Radio block now and then.

Johnathan

New job seems a very 9-to-5 kinda place, unlike the previous engagement,
which was 14 hours/day, 6
or 7 days a week

–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

Patrik_T · February 24, 2011, 12:36am

On 22.02.2011 15:26, 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.

Not exactly. The FCB is not passing the IQ to the analog sound
interface.
ADC is done within the dongle and the digital samples are transmitted
via USB
to an emulated “virtual” sound card.

However, for the application it’s just another “sound card”.

Patrik_T · February 24, 2011, 3:50pm

schrieb Moeller am 2011-02-24 00:33:

On 22.02.2011 15:26, Patrick S. wrote:

Not exactly. The FCB is not passing the IQ to the analog sound interface.
ADC is done within the dongle and the digital samples are transmitted via USB
to an emulated “virtual” sound card.

However, for the application it’s just another “sound card”.

Just like every USB sound interface it does not matter where the signal
comes, where it is going and how things behind the interface work. It
makes no difference to your application if you connect a converter via
cable to your sound interface in your computer or if you have the sound
interface built into your converter.
If it implements the USB Audio Class, its a USB Audio device. A headset
works the same. That’s the nice thing about abstract interfaces.

Patrick

Engineers motto: cheap, good, fast: choose any two
Patrick S.
Student of Telemati_cs_, Techn. University Graz, Austria

Patrik_T · February 25, 2011, 6:46pm

On Fri, Feb 25, 2011 at 5:36 PM, Moeller [email protected] wrote:

And I suppose in audio you have a spectral gap in the audio bass/LF region,
a gap near the baseband center frequency. This is far more than just a
single
FFT bin (DC offset) in direct conversion receivers.

There is still an audio codec - the difference is that it is in the
Funcube
Dongle rather than in the host computer. Moreover, the IQ imbalance is
not
only due to audio hardware but also due to the qudrature demodulator, so
DC
offset and phase error is pretty much a “feature” of all direct
conversion
type receivers (and transmitters) where you process the I and Q channels
in
separate hardware chains. The USRP & daughterboards have it and the
Funcube
Dongle has it too.

I believe there is one exception, namely when not using a hardware IQ
demodulator but doing the demodulation in software, e.g. on an FPGA.

The audio codec used in the Funcube Dongle is TLV320AIC3104:

If it implements the USB Audio Class, its a USB Audio device. A headset
works the same. That’s the nice thing about abstract interfaces.

Yes, I think it’s a nice abstract interface.
Do you know the theoretical limits for the sample rate?
Can it fill the full USB bandwidth or does it only accept
“standard audio” sample rates?

If you ask about the Funcube Dongle then it has a fixed sample rate of
96
kHz. It uses signed 16 bit samples, so the required USB bandwidth is ~ 3
Mbps. It can actually work on USB 1.1 hosts, though I don’t know who may
have such things lying around today.

Alex

Patrik_T · February 25, 2011, 8:39pm

On 25.02.2011 18:45, Alexandru C. wrote:

There is still an audio codec - the difference is that it is in the Funcube
Dongle rather than in the host computer. Moreover, the IQ imbalance is not
only due to audio hardware but also due to the qudrature demodulator, so DC
offset and phase error is pretty much a “feature” of all direct conversion
type receivers (and transmitters) where you process the I and Q channels in
separate hardware chains. The USRP & daughterboards have it and the
Funcube Dongle has it too.

It’s just an ADC sampler. I didn’t say anything against the audio ADC.
But the audio transmission line is much more: 2 audio jacks with analog
contact
imperfactions (IQ imbalance), lots of “digital noise” within the PC,
amplifiers, analog filters, audio mixers etc.
The frequency response of the overall analog part is not linear.
I think the sub bass region <20Hz is critical, not so important for the
human ear, but a very relevant region in the digital baseband spectrum.

Yes, I think it's a nice abstract interface.
Do you know the theoretical limits for the sample rate?
If you ask about the Funcube Dongle then it has a fixed sample rate of 96 kHz.
It uses signed 16 bit samples, so the required USB bandwidth is ~ 3
Mbps. It can actually work on USB 1.1 hosts, though I don’t know who may have
such things lying around today.

I know, the Funcube Dongle has a low sample rate.
But maybe this virtual sound interface could be “misused” for higher
rates in future
low-cost SDR designs. If there is no limit in the interface
specification.

Patrik_T · February 25, 2011, 5:37pm

On 24.02.2011 15:46, Patrick S. wrote:

Just like every USB sound interface it does not matter where the signal
comes, where it is going and how things behind the interface work. It
makes no difference to your application if you connect a converter via
cable to your sound interface in your computer or if you have the sound
interface built into your converter.

But I think it’s a big difference in signal quality.
There’s no IQ imbalance due to L/R audio channel differences,
no disturbed analog audio frequency response between dongle and PC.
And I suppose in audio you have a spectral gap in the audio bass/LF
region,
a gap near the baseband center frequency. This is far more than just a
single
FFT bin (DC offset) in direct conversion receivers.

If it implements the USB Audio Class, its a USB Audio device. A headset
works the same. That’s the nice thing about abstract interfaces.

Yes, I think it’s a nice abstract interface.
Do you know the theoretical limits for the sample rate?
Can it fill the full USB bandwidth or does it only accept
“standard audio” sample rates?

Moeller

Patrik_T · February 26, 2011, 11:38am

schrieb Moeller on 2011-02-25 17:36:

On 24.02.2011 15:46, Patrick S. wrote:

Just like every USB sound interface it does not matter where the signal
comes, where it is going and how things behind the interface work. It
makes no difference to your application if you connect a converter via
cable to your sound interface in your computer or if you have the sound
interface built into your converter.

But I think it’s a big difference in signal quality.

For sure. You ged rid of the quality decrease from all the long analog
lines.

Moreover it frees your computer audio interface for AF input and output.
Most computers are not shipped with two audio interfaces.

Do you know the theoretical limits for the sample rate?

Common USB Audio adheres to USB Audio Class 1, which was specified for
USB 1.1. The data structures allow sample rates to over 4MHz, but USB
1.1 is the limiting factor with its bandwidth:
(12MiBit/second)/(16bit/Sample)/(2 Channels)=384kiSPS. That is without
protocol overhead, so you can theoretical expect 16bit 192kSPS stereo as
maximum. It turns out that not every OS driver supports this data rate,
rather 96kiSPS. Moreover you have to deal with different clock speeds
and other subtleties.
Just putting USB Audio Class 1 on USB 2.0 would not work, because blocks
are structured different between 1.1 and 2.0.

But back in 2005 USB Audio Class 2 (UAC2) was adopted, offering notably
higher sampling rates and bit depths. Apple introduced a UAC2 in Mac OSX
10.6, And Linux has good support since 2.6.34 or .35. Microsoft promised
to implement a UAC2 driver for its upcoming Windows incarnations, but
nothing on the horizon until now.

The SDR widget people sounded every possible combination for the
mentioned OSes, with lots of tricks to get the very best out of every
driver (especially Windows UAC1). They have different firmware for UAC1
and UAC2.

I just read some articles from the SDR widget list and had a
conversation with the Linux driver author, maybe I got some details
wrong.

Can it fill the full USB bandwidth or does it only accept
“standard audio” sample rates?

You can set every integer sampling rate you like withing the capacity
limit, but most drivers expect the common sampling rates. The drivers
are the limiting factor.
And still synchronization of clocks is a big problem.

Patrick

Engineers motto: cheap, good, fast: choose any two
Patrick S.
Student of Telematik, Techn. University Graz, Austria

Patrik_T · February 26, 2011, 1:12pm

On 26.02.2011 11:36, Patrick S. wrote:

Just putting USB Audio Class 1 on USB 2.0 would not work, because blocks
are structured different between 1.1 and 2.0.

That was my hope, but I didn’t check the specs if it would be possible.

But back in 2005 USB Audio Class 2 (UAC2) was adopted, offering notably
higher sampling rates and bit depths. Apple introduced a UAC2 in Mac OSX
…
The SDR widget people sounded every possible combination for the
mentioned OSes, with lots of tricks to get the very best out of every
driver (especially Windows UAC1). They have different firmware for UAC1
and UAC2.

UAC2 with USB3 would be a good combination. With the “usb3” “uac2”
keywords in Google you find some developments for a “USB Super Speed
patch”
in USB3 audio drivers. I think it’s realistic because UAC2 is supported
in Linux and USB3 is now common in modern PC. With about 5 Gbit/s
it allows broadband SDR solutions, hopefully also low-cost ones.

You can set every integer sampling rate you like withing the capacity
limit, but most drivers expect the common sampling rates. The drivers
are the limiting factor.

At least in Linux you can tune the drivers if you want.

And still synchronization of clocks is a big problem.

Sync problems? I thought, the “audio” devices implement
a fixed sampling clock and the USB transmission is buffered to
achieve a continuous stream without gaps or clock variations.
Only the PC audio output has a different clock, but that problem
occurs with other external sources too, like the USRPs.

Patrik_T · February 25, 2011, 8:51pm

On 25/02/2011 2:38 PM, Moeller wrote:

I know, the Funcube Dongle has a low sample rate.
But maybe this virtual sound interface could be “misused” for higher rates in
future
low-cost SDR designs. If there is no limit in the interface specification.

I believe that FCD uses the UAC1.1 specification, which doesn’t
contemplate arbitrary sample rates, but
UAC2 pretty-much allows much higher sample rates (up to several
Msps), but of course that would
also require much-different hardware on the FCD.

Patrik_T · February 27, 2011, 2:25pm

schrieb Moeller on 2011-02-26 13:11:

Sync problems? I thought, the “audio” devices implement
a fixed sampling clock and the USB transmission is buffered to
achieve a continuous stream without gaps or clock variations.
Only the PC audio output has a different clock, but that problem
occurs with other external sources too, like the USRPs.

The problem arises between system clock and audio clock. While the Audio
clock is most probably a free running clock in the device, the computer
may have a slightly different time base. Now who is right about the
sampling rate? One thing you can do is accept occasional resyncs with
small hickups or clicks, that is some lost samples or some extra
samples. Or you can resample the stream, which is computational
intensive and decreases quality. Or you manage to synchronize the
clocks, which is possible with USB. But the USB clock has probably too
much jitter for high quality signal sampling…

No easy task. Anyway, refer to SDR widget, they have thought of every
possible problem and solution.

Patrick

Engineers motto: cheap, good, fast: choose any two
Patrick S.
Student of Telematik, Techn. University Graz, Austria