SDR Dongle "bandwidth" - rtlsdr-airband

[Adam Nielsen]

Found an interesting program RTLSDR-Airband
https://github.com/microtony/RTLSDR-Airband
Which allows up to 8 channels to monitored and fed to Icecast
servers...

Oh looks nice! I will investigate, hopefully this is easier than
manually clicking around trying to listen to active channels as you
visually spot a transmission.

The setup requires a center frequency to be used and then the
channels monitored need to be withing some "bandwidth" of the SDR
device used...
*BUT*
What is this max bandwidth allowed???

Depends on what you set it to. As you'll see one of the first specs
listed for any SDR device is the maximum bandwidth possible, and for
RTL2832 devices it's generally around 2MHz, but you can go over 3MHz if
you don't mind the odd bit of signal loss here and there.

This means you can decode say 2MHz of the RF spectrum at a time.
Where is up to you - you could choose to decode from 120MHz to 122MHz,
or from 121MHz to 123MHz, and so on. But two of the channels you list
(120.65 and 124.5) are more than 2MHz apart, so you wouldn't be able to
listen to these two at the same time.

The centre frequency is just the middle of the two extremes, so tuning
to 120MHz with a bandwidth of 2MHz will get you 119.0 through to
121.0. Note that an actual broadcast at 119.0 will go below 119.0 a
little, so you should consider any channel at the extreme of the range
unavailable for decoding.

Is this within in the "Max Bandwidth" of these E4K and RTL283U
devicess???

As above, generally you will have to stick to 2-3MHz so not all of
those channels are within range. You will need a second device, or
a different device with larger bandwidth, to receive them all at the
same time.

The README never seems to outline what this, how I would find it,
etc...

Don't take this the wrong way, but it's such a basic specification when
you select your SDR device that it's taken for granted you know what it
means :-)

Is this within the bandwidth of these SDR units??? Or something
narrower??? And thus 2-3 dongles are needed??? I could narrow this
121.500
124.500
122.950
121.400

This spread is 3.1MHz which is so close to the upper limit of 3.2MHz you
may just be able to scrape through, but you will definitely experience
some packet loss.

But the prime two targets 124.500 and 121.4 with their ~ 3MHz
separation I see being a problem..

Yes, you might just be able to get these two but you will likely get
some interruptions as USB packets are dropped due to limitations of the
RTL2832 chip. You might be better off getting a second device.

Cheers,
Adam.

[Douglas Hall]

Generally you can get up to a sample rate of ~2.4e6 samples per second
before packet loss, which gives 2.4MHz bandwidth. Remember the output of an
rtl-sdr are IQ samples, interleaved in-phase and quadrature, this allows
you to distinguish between positive and negative frequencies so you'll
receive 1.2MHz on both sides of the center frequency for a total of 2.4MHz.

-Doug

Post by Adam Nielsen

Found an interesting program RTLSDR-Airband
https://github.com/microtony/RTLSDR-Airband
Which allows up to 8 channels to monitored and fed to Icecast
servers...

Oh looks nice! I will investigate, hopefully this is easier than
manually clicking around trying to listen to active channels as you
visually spot a transmission.

The setup requires a center frequency to be used and then the
channels monitored need to be withing some "bandwidth" of the SDR
device used...
*BUT*
What is this max bandwidth allowed???

Depends on what you set it to. As you'll see one of the first specs
listed for any SDR device is the maximum bandwidth possible, and for
RTL2832 devices it's generally around 2MHz, but you can go over 3MHz if
you don't mind the odd bit of signal loss here and there.
This means you can decode say 2MHz of the RF spectrum at a time.
Where is up to you - you could choose to decode from 120MHz to 122MHz,
or from 121MHz to 123MHz, and so on. But two of the channels you list
(120.65 and 124.5) are more than 2MHz apart, so you wouldn't be able to
listen to these two at the same time.
The centre frequency is just the middle of the two extremes, so tuning
to 120MHz with a bandwidth of 2MHz will get you 119.0 through to
121.0. Note that an actual broadcast at 119.0 will go below 119.0 a
little, so you should consider any channel at the extreme of the range
unavailable for decoding.

Is this within in the "Max Bandwidth" of these E4K and RTL283U
devicess???

As above, generally you will have to stick to 2-3MHz so not all of
those channels are within range. You will need a second device, or
a different device with larger bandwidth, to receive them all at the
same time.

The README never seems to outline what this, how I would find it,
etc...

Don't take this the wrong way, but it's such a basic specification when
you select your SDR device that it's taken for granted you know what it
means :-)

Is this within the bandwidth of these SDR units??? Or something
narrower??? And thus 2-3 dongles are needed??? I could narrow this
121.500
124.500
122.950
121.400

This spread is 3.1MHz which is so close to the upper limit of 3.2MHz you
may just be able to scrape through, but you will definitely experience
some packet loss.

But the prime two targets 124.500 and 121.4 with their ~ 3MHz
separation I see being a problem..

Yes, you might just be able to get these two but you will likely get
some interruptions as USB packets are dropped due to limitations of the
RTL2832 chip. You might be better off getting a second device.
Cheers,
Adam.

[Oliver Jowett]

What I am not getting is clear info on these devices..
Is it +- 2MHz at 2mb/s rate etc...

+/- 1MHz at 2M complex samples/s.
Nyquist would like to have words with you about capturing 4MHz
bandwidth with 2M samples/sec!

Post by Adam Nielsen
This spread is 3.1MHz which is so close to the upper limit of 3.2MHz you
may just be able to scrape through, but you will definitely experience
some packet loss.

Here is a "limit of 3.2." Where is this coming from ? ? ? I am not
getting answers on specs.. except that some where some one already knows
these.... some how. Obviously some one has access to the NDA'd data
sheets on the chips inside that us mere mortals do not have. I really
liked things better when I could go to TI, Motorola etc. and purchase big
honking data books. :)

Aye, there's the rub. It would be great to have proper specs. For the
most part we don't have them. Without proper specs, most of these
limits etc are just empirical limits found through trial and error.
I don't think there's a secret NDA cartel (if there is, how do I join?
;-)), what you see is the end result of lots of reverse-engineering
and experimentation.

Oliver

[Nick Foster]

It's important to remember these devices weren't even intended to operate
in this fashion, and they almost certainly were never specified to support
any given bandwidth. The ~2.4MHz sample rate is just an anecdotal number
arrived at through experimentation.

--n

Post by Oliver Jowett

What I am not getting is clear info on these devices..
Is it +- 2MHz at 2mb/s rate etc...

+/- 1MHz at 2M complex samples/s.
Nyquist would like to have words with you about capturing 4MHz
bandwidth with 2M samples/sec!

Post by Adam Nielsen
This spread is 3.1MHz which is so close to the upper limit of 3.2MHz you
may just be able to scrape through, but you will definitely experience
some packet loss.

Here is a "limit of 3.2." Where is this coming from ? ? ? I am not
getting answers on specs.. except that some where some one already knows
these.... some how. Obviously some one has access to the NDA'd data
sheets on the chips inside that us mere mortals do not have. I really
liked things better when I could go to TI, Motorola etc. and purchase big
honking data books. :)

Aye, there's the rub. It would be great to have proper specs. For the
most part we don't have them. Without proper specs, most of these
limits etc are just empirical limits found through trial and error.
I don't think there's a secret NDA cartel (if there is, how do I join?
;-)), what you see is the end result of lots of reverse-engineering
and experimentation.
Oliver

[Ralph A. Schmid, dk5ras]

How do they manage receiving DVB-x, with 7 or 8 MHz bandwidth? Hardware decoding engine on-chip? Or is there no interleaving among the single TV-stations on one carrier, and it is enough to decode a small portion of the spectrum for being able to watch one station?



Ralph.



From: osmocom-sdr-***@lists.osmocom.org [mailto:osmocom-sdr-***@lists.osmocom.org] On Behalf Of Nick Foster
Sent: Monday, September 15, 2014 4:24 PM
To: Oliver Jowett
Cc: Dean Sauer; sdrrtl
Subject: Re: SDR Dongle "bandwidth" - rtlsdr-airband



It's important to remember these devices weren't even intended to operate in this fashion, and they almost certainly were never specified to support any given bandwidth. The ~2.4MHz sample rate is just an anecdotal number arrived at through experimentation.

--n

What I am not getting is clear info on these devices..
Is it +- 2MHz at 2mb/s rate etc...

+/- 1MHz at 2M complex samples/s.
Nyquist would like to have words with you about capturing 4MHz
bandwidth with 2M samples/sec!

Post by Adam Nielsen
This spread is 3.1MHz which is so close to the upper limit of 3.2MHz you
may just be able to scrape through, but you will definitely experience
some packet loss.

Here is a "limit of 3.2." Where is this coming from ? ? ? I am not
getting answers on specs.. except that some where some one already knows
these.... some how. Obviously some one has access to the NDA'd data
sheets on the chips inside that us mere mortals do not have. I really
liked things better when I could go to TI, Motorola etc. and purchase big
honking data books. :)

Aye, there's the rub. It would be great to have proper specs. For the
most part we don't have them. Without proper specs, most of these
limits etc are just empirical limits found through trial and error.
I don't think there's a secret NDA cartel (if there is, how do I join?
;-)), what you see is the end result of lots of reverse-engineering
and experimentation.

Oliver

[Alexander Kurpiers]

Hi Ralph,

Post by Ralph A. Schmid, dk5ras
How do they manage receiving DVB-x, with 7 or 8 MHz bandwidth?
Hardware decoding engine on-chip? Or is there no interleaving among
the single TV-stations on one carrier, and it is enough to decode a
small portion of the spectrum for being able to watch one station?

The "SDR" feature is just an add-on, DVB-T they do using a hardware
engine indeed.
There are newer chipsets from Mirics (http://www.mirics.com/node/6) that
also do the DVB-T decoding in software. But that is still "something"
even on modern PCs. Unfortunately they are difficult to get and more
expensive.

73' Alexander DL8AAU

[Alexandru Csete]

what you see is the end result of lots of reverse-engineering and
experimentation.

Well that is fine... share the info on the experimentation, please! I
just want a straight answer. I hate BS. And lack of clear documentation
on programs is one that really sets me off.

Is this clear enough:

"The RTL2832U outputs 8-bit I/Q-samples, and the highest theoretically
possible sample-rate is 3.2 MS/s, however, the highest sample-rate
without lost samples that has been tested so far is 2.56 MS/s."

This is quoted from the second paragraph of what I would consider *the
web page* for rtl-sdr:
http://sdr.osmocom.org/trac/wiki/rtl-sdr

Alex

[Oliver Jowett]

what you see is the end result of lots of reverse-engineering and
experimentation.

Well that is fine... share the info on the experimentation, please! I
just want a straight answer. I hate BS. And lack of clear documentation
on programs is one that really sets me off.

My experimentation ends up on github: https://github.com/mutability/rtl-sdr

I'm happy to take documentation patches if you have some for me.
(& I'm sure upstream would be happy too!)

Oliver

[Adam Nielsen]

Which the author of this software failed to include in their README,
and while maybe it is known to those using these SDR's..

To be fair, SDR on PCs is still a field in its infancy. We have only
had affordable devices that can do SDR for a couple of years now, which
is only just opening up the field to increasing numbers of people. This
has been barely enough time to write the first generation of software,
let alone extensive documentation. Going back to your complaint about
companies no longer publishing databooks, this field is so young that
the "databooks" are only just being written now, as people figure
things out by experimentation.

Michael Ossmann is doing a great job of this, and his tutorials while
only having been out for a few weeks, are receiving a lot of good
feedback:

http://greatscottgadgets.com/sdr/1/

If you're after detailed guides and chip-level specifications, you're
much too early - this won't come for another few years at least. On
the other hand, if you want to get involved in a very new field, this
is a great opportunity but it will involve doing a lot of your own
research and experimentation with not enough information available.

And don't forget, almost all the people here who write this software all
do it in their spare time. So you can forgive them for working on the
most interesting bits first, and leaving the detailed documentation for
later. As Oliver hinted, there's nothing stopping you from being the
one to write the documentation! But if you're not interesting in being
the one to write all the instructions then you can hardly blame the
programmers for feeling the same way :-)

Cheers,
Adam.

[Alexandru Csete]

Post by Adam Nielsen
To be fair, SDR on PCs is still a field in its infancy. We have only
had affordable devices that can do SDR for a couple of years now, which
is only just opening up the field to increasing numbers of people.

Hi Adam,

While it is true that there has been a significant boost in the area
of PC-based SDR hardware and software over the last few years, the
technology has existed and been practiced for as I remember.

I have run my first soundcard based SDR on a DOS PC in the mid 1990's.
Others have built their own ADC/DAC boards to plug into an ISA slot in
the PC even before that.

Of course, it was nothing like SDR is today and most of the software
from then is neither available nor particularly usable today. However,
according to Wikipedia even GNU Radio has been around since 2001 and
it was born as a fork of an already existing project.

If I should guess why there aren't so many mature SDR applications out
there I would say that it is because SDR spans over so many
engineering disciplines. Writing a good SDR application requires
understanding of RF, analog, digital, DSP and last but not least,
software engineering.

Yeah, it's a life long learning.

Alex

[j***@earthlink.net]

And sound card MODEMS have preceded the sound card SDR by an easy decade and
more. I did a Morse decoder back in the mid 70s on a Processor Technology SOL PC
board. And I was not the first. I used ideas written up by somebody else.

On the other paw, a lot of the potential for SDRs is still unrealized. And a lot
of pitfalls on the analog side of the picture are still being filled in. (A
small software thinko can generate impressively wide bands of annoying noise for
others. FSK without shaping the envelope at least a little is WIDE.)

{^_^} Joanne

Post by Alexandru Csete

Post by Adam Nielsen
To be fair, SDR on PCs is still a field in its infancy. We have only
had affordable devices that can do SDR for a couple of years now, which
is only just opening up the field to increasing numbers of people.

Hi Adam,
While it is true that there has been a significant boost in the area
of PC-based SDR hardware and software over the last few years, the
technology has existed and been practiced for as I remember.
I have run my first soundcard based SDR on a DOS PC in the mid 1990's.
Others have built their own ADC/DAC boards to plug into an ISA slot in
the PC even before that.
Of course, it was nothing like SDR is today and most of the software
from then is neither available nor particularly usable today. However,
according to Wikipedia even GNU Radio has been around since 2001 and
it was born as a fork of an already existing project.
If I should guess why there aren't so many mature SDR applications out
there I would say that it is because SDR spans over so many
engineering disciplines. Writing a good SDR application requires
understanding of RF, analog, digital, DSP and last but not least,
software engineering.
Yeah, it's a life long learning.
Alex

[Adam Nielsen]

Post by Alexandru Csete
While it is true that there has been a significant boost in the area
of PC-based SDR hardware and software over the last few years, the
technology has existed and been practiced for as I remember.

Oh sure. Sorry, to be clear I didn't mean that the field was new, just
that for a long time the barriers to entry were quite high. You either
needed very expensive hardware, or the knowledge to build your own
antenna to connect to a sound card. This was either beyond most
people's ability, or they just didn't know it was possible because it
wasn't well known about outside enthusiast circles.

But once people started hearing about all the things you could do with
a $20 USB device with few other skills required, that's when so many
new people were drawn to the field because it became so much simpler to
get involved. I'm sure there are many programmers out there who are
not very handy with a screwdriver or soldering iron, but now they too
can contribute to SDR. I think that's going to be where the biggest
change will happen. The more people involved, the more innovations
we'll get.

Post by Alexandru Csete
If I should guess why there aren't so many mature SDR applications out
there I would say that it is because SDR spans over so many
engineering disciplines. Writing a good SDR application requires
understanding of RF, analog, digital, DSP and last but not least,
software engineering.

That's very true. And hopefully now that many more software engineers
can get into the field very easily, we will see even more great
applications.

I would also add mathematics to your list, because although it is
covered in those fields, I have a basic understanding of most of them
but it's the gap in my knowledge of maths that is my current stumbling
block.

Post by Alexandru Csete
Yeah, it's a life long learning.

Definitely :-)

Cheers,
Adam.

[Adam Nielsen]

Post by Adam Nielsen
Oh looks nice! I will investigate, hopefully this is easier than
manually clicking around trying to listen to active channels as you
visually spot a transmission.

Yeah.. now if it only did NBFM I would be all over that.

Indeed. As it turns out it doesn't use a standard build system so you
have to choose between Windows support or Raspberry Pi support.
Doesn't seem to work on standard Linux, since the Linux build assumes
you are using the Pi's GPGPU for FFT calculations and then complains
because it can't find the Broadcom header files.

Does anyone else know if there are any other options for decoding
multiple AM/NBFM channels from a single RF chunk received by one dongle?

Cheers,
Adam.

[Adam Nielsen]

Post by Adam Nielsen
Indeed. As it turns out it doesn't use a standard build system so
you have to choose between Windows support

I have X11... :) ;) Yes I know what you mean/meant... but the line..
from a movie comes to mind..
I don't think that means what you think it does. You say windows,
and that is just a form of a GUI to me, run by X11. :) ;)

I know this is splitting hairs and you're joking, but to be fair, I
didn't say "windows", I said "Windows". With a capital W it's the name
of a popular software product, not a generic term :-) You'll never
find X11 referred to as "Windows" with a capital W!

Cheers,
Adam.

[Adam Nielsen]

http://lukeberndt.com/2013/using-a-hackrf-to-capture-an-entire-radio-system/
Perhaps can be adapted to work with the smaller BW of the rtl-sdr.

Oh nice, thanks for the link! For a long time I've wanted something
that will actually queue up transmissions and play them one after the
other, even if they are broadcast simultaneously, and it looks like
this can do it! Either way using the browser as the interface is a
very interesting idea.

Luckily for me a HackRF arrived two weeks ago so I won't have to change
that part :-)

Cheers,
Adam.