Debian packages?

I’ve reconfigured my ‘embedded’ systems to be based on debian. This
allows me to
update packages fairly easily, and the thought occured to me if there
was a debian
package for GNURadio.

I just installed the latest vlc, video widgetry, and it the debian
package manager updated
about 110 modules which needed to be up to whatever level to match the
latest vlc package…

It may be that with this update I’m ‘close’ to supporting GNURadio on
this platform without
a lot of hand package installation…

Thanks for any info.
John C.

Which embedded system are you working on? What is the CPU? Mostly
just curious.

I’m working on an ARM9 right now running Debain (Sarge I think; I’m
new to Linux, though I know the version is 2.4.26, which is kind of
old), and it’s a royal PITA to get anything either compiled directly
on or cross-compiling to (from either a Linux or OSX box). I would -
love- for a debian GNURadio package for ARM, so that I can
concentrate my efforts in other areas. - MLD

Hello,

I am new to GNUradio, there are some questions regarding GNUradio:

Does it support RDS (http://en.wikipedia.org/wiki/Radio_Data_System),
TMC (http://en.wikipedia.org/wiki/Traffic_Message_Channel), DAB
(http://en.wikipedia.org/wiki/Digital_audio_broadcasting) or DVB-S/T
(http://en.wikipedia.org/wiki/DVB) ? Is that USRP sufficient for
broadband applications like DVB ?

Christian

On Sat, Oct 14, 2006 at 08:47:36AM +0200, Christian Felsing wrote:

Hello,

I am new to GNUradio, there are some questions regarding GNUradio:

Does it support RDS (http://en.wikipedia.org/wiki/Radio_Data_System),

Not currently, though definitely possible. There was some code
written a while ago that started to demod RDS. However, we have yet
to receive the appropriate copyright assignment from the authors and
are thus unable to use the code as a starting point.

If anyone else is working on this, or knows more, please speak up.

TMC (http://en.wikipedia.org/wiki/Traffic_Message_Channel),

Once you’ve got RDS, this is straight forward.

DAB (http://en.wikipedia.org/wiki/Digital_audio_broadcasting) or

Jens E. [email protected] was working on this, not sure of the
status. The work-in-progress is not in the GNU Radio repository.

DVB-S/T (http://en.wikipedia.org/wiki/DVB) ?

Is that USRP sufficient for broadband applications like DVB ?

The USRP could receive the raw signals for DVB-T in the 6 and 7 MHz wide
channel format. The 8 MHz wide version could be somewhat degraded
because of filter rolloff at the edges of the passband of the digital
downconverter in the FPGA. Shifting to 8-bit I&Q would allow the full
8 MHz wide signal to fit across the USB at the expense of dynamic range.

I’m not sure of the bandwidth required for DVB-S and thus can’t comment.

Eric

On Sat, Oct 14, 2006 at 06:49:03AM -0700, Eric B. wrote:

The USRP could receive the raw signals for DVB-T in the 6 and 7 MHz wide
channel format. The 8 MHz wide version could be somewhat degraded
because of filter rolloff at the edges of the passband of the digital
downconverter in the FPGA. Shifting to 8-bit I&Q would allow the full
8 MHz wide signal to fit across the USB at the expense of dynamic range.

I’m not sure of the bandwidth required for DVB-S and thus can’t comment.

DVB-S as used for video is usually upwards of 3 megasymbols/sec

as this kind of data rate is required to support sufficient transport
stream bandwidth for adequate distribution grade video. Many of the
actual signals on satellite, however, are multiplexes of multiple video
and audio streams sent at symbol rates as high as 26 to 29
megasymbols/sec.

Currently almost all signals are QPSK (NOT DQPSK, absolute phase

counts) although the standards permit 8PSK and even 16QAM. 8PSK IS used
for some HDTV feeds (notably the US broadcast networks ABC and NBC and
the Canadian network CBC) and some HDTV backhauls.

Roughly speaking, the actual rf bandwidth required to demodulate

QPSK is perhaps 1.1 to 1.2 times the symbol rate with a higher sampling
rate than that probably necessary to get good results.

This implies that the USRP with a 6 to 8 mhz bandwidth might be

able to successfully demodulate the SCPC DVB-S QPSK video transmissions
at symbol rates like 3.9876 megasymbols/sec (5.5 mbs transport stream at
FEC 3/4) commonly used by satellite trucks for news feeds. Most of
these signals carrying single channel NTSC video (720 by 480 MPEG 2) run
at either 3.9 megasymbols/sec or 4.2 megasymbols/sec.

Making it demodulate the wider band signals used for video

distribution and HDTV is probably not possible, nor for that matter is
the processor bandwidth required to munch the samples any more likely
available than that required to handle ATSC (though demodulating
satellite QPSK on a nice clean linear channel off the satellite should
take MUCH less compute than ATSC with equalization and so forth).

There are a few DVB-S signals that run at unusually low data

rates (hey it’s cheap since satellite charges are based on bandwidth and
power used) down to as little as 1.6 megasymbols/sec. And the same
basic modulation is sometimes used for sending audio streams like Muzak
for stores and restaurants at lower rates. These doubtless could be
demodulated by the USRP.

Obviously the back end compute required to munch sample streams

this fast is not inconsiderable - processing DVB-S requires estimating
and tracking carrier phase and recovering symbol clock and then doing
Vitirbi (k=7 trellis) on the resultant low pass filtered I and Q sample
stream. The only good thing here is that a satellite transponder is a
benign medium with no multipath or amplitude/delay distortion to speak
of, thus elaborate FIR filters with huge numbers of taps are not needed
to compensate for this as they are for ATSC.

As for the underlying data - many signals are in the clear

(almost all satellite truck newsfeeds are for example) and contain
standard MPEG 2 transport streams that can be displayed by existing
open source utilities. Some others, of course, are encrypted (mostly
with DES) and not accessible.


Dave Emery N1PRE, [email protected] DIE Consulting, Weston,
Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
‘For Rent’ sign still vainly flapping outside on the weed encrusted pole

  • in
    celebration of what could have been, but wasn’t and is not to be now
    either."

DAB (http://en.wikipedia.org/wiki/Digital_audio_broadcasting) or

Jens E. [email protected] was working on this, not sure of the
status. The work-in-progress is not in the GNU Radio repository.
It’s not my priority right now, but it (at least some functionality and
my student project report) has to be finished according to my university
guidelines at the end of the year.

Status of the code: I can detect the DAB OFDM signal and demodulate it
in
non-real time. The whole protocol stack is missing. The next step would
be to piece it together from existing GNU Radio projects (channel
decoding, deinterleaving). I hope to get to that soon.

Jens

On Sat, Oct 14, 2006 at 02:06:01PM -0400, Robert McGwier wrote:

David I. Emery wrote:

This implies that the USRP with a 6 to 8 mhz bandwidth might be
able to successfully demodulate the SCPC DVB-S QPSK video transmissions
at symbol rates like 3.9876 megasymbols/sec (5.5 mbs transport stream at
FEC 3/4) commonly used by satellite trucks for news feeds. Most of
these signals carrying single channel NTSC video (720 by 480 MPEG 2) run
at either 3.9 megasymbols/sec or 4.2 megasymbols/sec.

As is typical of many signals of this type (geostationary satellite
signals), it needs very little dynamic range, mostly enough to
accomodate weather and multipath fades but not what would expect to have
to accommodate on a different type of FDM channel where you could see
serious near-far problems. I suspect the 8 bit DDS might work nicely
indeed here.

In fact many of the chip sets used to implement DVB modems (and

other satellite QPSK demodulators) in the early days before highly
integrated mixed signal ASIC stuff took over used actual 6 or 8 bit A/Ds
feeding the digitry - either digitizing IF or I and Q from a
downconversion. If I remember correctly some of the early Stanford
Telecom chips only accepted 6 or even 4 bits of I and Q.

Obviously typical satellite receiver designs which work over an IF

power range from around -65 to -70 dbm to around -30 dbm or so include
AGC - usually controlled by the signal processor digitally to set the
power at the constellation points to a nominal value (in vector space).
And equally obviously, the USRP has the hardware on board to do just
that.

The loop bandwidth for this AGC is uncritical - satellite

carrier powers change slowly with weather fade and antenna motion
(mostly unintended of course) and satellite motion - one needs hundreds
of milliseconds here, not hundreds of hz.

There are some of us looking at using the USRP for making

measurements on, characterizing modulation parameters of, and
demodulating satellite BPSK, QPSK, OQPSK, and 8PSK signals. There are
obviously very many of these, as few other modulations are employed on
the bent pipe repeaters of modern communications satellites. And using
the DBSRX daughter board allows coverage of the IF range of most modern
LNBs - for S, C, X, Ku, and Ka and K bands. And it also directly
covers the 1.5 and 1.6 ghz L band frequencies used for mobile satellite
service (INMARSAT, Iridium, Globalstar).


Dave Emery N1PRE, [email protected] DIE Consulting, Weston,
Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
‘For Rent’ sign still vainly flapping outside on the weed encrusted pole

  • in
    celebration of what could have been, but wasn’t and is not to be now
    either."

John C. wrote:

I’ve reconfigured my ‘embedded’ systems to be based on debian. This
allows me to
update packages fairly easily, and the thought occured to me if there
was a debian
package for GNURadio.
Yes, there are. Bdale has uploaded new packages, which should be
available soon. apt-get install gnuradio should be all you need.

Matt

David I. Emery wrote:

the Canadian network CBC) and some HDTV backhauls.
at either 3.9 megasymbols/sec or 4.2 megasymbols/sec.

— snip ----

As is typical of many signals of this type (geostationary satellite
signals), it needs very little dynamic range, mostly enough to
accomodate weather and multipath fades but not what would expect to have
to accommodate on a different type of FDM channel where you could see
serious near-far problems. I suspect the 8 bit DDS might work nicely
indeed here.

Bob


AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
“You see, wire telegraph is a kind of a very, very long cat.
You pull his tail in New York and his head is meowing in Los
Angeles. Do you understand this? And radio operates exactly
the same way: you send signals here, they receive them there.
The only difference is that there is no cat.” - Einstein

Eric B. wrote:

Yes, there are. Bdale has uploaded new packages, which should be
available soon. apt-get install gnuradio should be all you need.

Note that you’re looking for the 3.0 packages.
I’m not sure exactly what they’re called.

The 3.0 packages have not yet made it through the system and into the
unstable repository. Once they do, as Matt wrote, installing the
meta-package ‘gnuradio’ will pull in the entire binary distribution:

libgnuradio-core0c2a
libgnuradio-core0c2a-dbg
libgnuradio-core0-dev
usrp
usrp-firmware
libusrp0-dev
libusrp0c2a
libusrp0c2a-dbg
python-gnuradio
python-usrp
gnuradio-doc
gnuradio-examples

It will also pull in the correct runtime dependencies, (python, fftw,
etc.)

The packages ‘conflict’ with the existing 2.8 packages, so they will get
uninstalled during the process.

The Debian automated package build system will compile, create, and make
available for installation the above package set for a variety of
architectures.

Assuming the criteria is met, about two weeks later these will
transition from Debian ‘unstable’ into Debian ‘testing’.

Thanks again to Bdale Garbee (and Ramakrishnan Muthukrishnan prior) for
doing all the work to create these. It certainly expands the range of
people who can easily try out GNU Radio.

(Anyone want to volunteer to do the RPM equivalent?)

Johnathan C., AE6HO
[email protected]

On Sat, Oct 14, 2006 at 02:11:10PM -0700, Matt E. wrote:

John C. wrote:

I’ve reconfigured my ‘embedded’ systems to be based on debian. This
allows me to
update packages fairly easily, and the thought occured to me if there
was a debian
package for GNURadio.
Yes, there are. Bdale has uploaded new packages, which should be
available soon. apt-get install gnuradio should be all you need.

Matt

Note that you’re looking for the 3.0 packages.
I’m not sure exactly what they’re called. Perhaps a Debian expert can
tell us.

Eric

On Sat, Oct 14, 2006 at 04:03:25PM -0700, Johnathan C. wrote:

meta-package ‘gnuradio’ will pull in the entire binary distribution:
python-usrp
gnuradio-doc
gnuradio-examples

I’m clueless about Debian packaging. Could someone please explain
the partioning between usrp, usrp-firmware, libusrp* and python-usrp?

Feel free to tell me to RTFM. A link would be most welcome.

Also, how would I know that these correspond to the GNU Radio 3.0
release? If we make a 3.0.1 or 3.1 release, how will the
corresponding packages be named?

Looking for a clue…
Eric

On 10/15/06, Eric B. [email protected] wrote:

python-gnuradio
python-usrp
gnuradio-doc
gnuradio-examples

I’m clueless about Debian packaging. Could someone please explain
the partioning between usrp, usrp-firmware, libusrp* and python-usrp?

Since usrp FPGA code cannot be built without non-free Altera tools
though the FPGA code itself is free, it has to go into the contrib
section of the Debian archive. Debian divides its archive into “main”,
“contrib” and “non-free”. This link explains it well:

http://www.debian.org/doc/debian-policy/ch-archive.html#s-sections

So that explains why usrp-firmware is packaged seperately from the usrp
code.

The library packaging splits the shared libraries and static libraries
and header files seperately. Please see:

http://www.debian.org/doc/debian-policy/ch-sharedlibs.html

Also, how would I know that these correspond to the GNU Radio 3.0
release? If we make a 3.0.1 or 3.1 release, how will the
corresponding packages be named?

The package naming won’t change. Only the versions numbers appended
after the name of the package only would change.

All the Debian Packaging rules, how the OS filesystem and other things
are organised etc are well codified into the Debian Policy. There is
also a Debian Developer’s Reference. Here are the links.

http://www.debian.org/doc/debian-policy/

http://www.debian.org/doc/developers-reference/


Ramakrishnan - VU3RDD

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