[Lac] Fw: GNURadio Wiki / Digital Communications Conference

[Diego Saravia]

por ahi les interesa


GNURadio Wiki:
> http://comsec.com/wiki

GNURadio Frequently Asked Questions:
> http://comsec.com/wiki?GnuRadioFaq

GNURadio at Digital Communications Conference:
> http://comsec.com/wiki?DigitalCommunicationsConference

---

> http://comsec.com/wiki

Welcome to GnuRadioWiki!

GnuRadioWiki is a collaborative attempt to explore, document and
expand the use and development of GnuRadio. A "wiki" is a website
that is collaboratively edited by its users, including the
ability to change text written by other users (see WhatIsaWiki).

This wiki is for discussions of GnuRadio, SoftwareRadio, and
related topics.

Some useful starting points include:

GnuRadioFaq (http://comsec.com/wiki?GnuRadioFaq)
SuggestedReading (http://comsec.com/wiki?SuggestedReading)
HowToFM (How to receive and record FM radio)
(http://comsec.com/wiki?HowToFM)
HowtoHdTv (How to receive and record HDTV)
(http://comsec.com/wiki?HowtoHdTv)
SdR1000 Progress (http://comsec.com/wiki?SdR1000)
CategoryHowto (a list of HOWTO entries)
(http://comsec.com/wiki?CategoryHowto)
CategoryCategory (a list of topics)
(http://comsec.com/wiki?CategoryCategory)
QuadratureDemodulator
(http://comsec.com/wiki?QuadratureDemodulator)
UniversalSoftwareRadioPeripheral
(http://comsec.com/wiki?UniversalSoftwareRadioPeripheral)
SuggestedProjects -- Things to do
(http://comsec.com/wiki?SuggestedProjects)
DigitalCommunicationsConference (the annual ARRL and TAPR DCC)
(http://comsec.com/wiki?DigitalCommunicationsConference)

---

(Selected and Arranged FAQs  -- Seth)

> http://comsec.com/wiki?GnuRadioFaq

This is the GNU Radio FAQ. Here you'll find the most frequently
asked questions and answers about GnuRadio. This FAQ is actually
a Wiki, a user editable web site. See WhatIsaWiki for background.
The bottom line is that this web page is editable by you. If
you've got a question, add it at the bottom. Likewise, if you've
got an answer, please feel free to add it, or to enhance what
others have already written.

Q: What's the point of GnuRadio?

It does signal processing in free software. This means you can
learn from it, and modify it to do new things. The big idea is to
give ordinary software people easy access to 'hack' the
electromagnetic spectrum, that is, to understand the radio
spectrum and think of clever ways to use it.

[the ideological stuff aside, what is the point of GnuRadio? what
does it offer that ordinary hardware radio doesn't? and what is
really the difference?]

GnuRadio offers reconfigurability. Spending $1000 on a piece of
radio hardware buys you access to whatever that particular radio
is configured for. If you have adequate generic GnuRadioHardware,
the radio processing can be done in software. Currently only a
few forms of radio are duplicated in GnuRadioSoftware, but if you
understand the math of a radio transmission system, you can
reconfigure your GnuRadio to receive it.

Q: How do I receive HdTv with GnuRadio?
For all the gory details, please see HowtoHdTv.

Q: What can I do with GnuRadio?
...anything that can be done with a radio. And more.

The neat aspect of software receivers is that new modes of
reception can be tried without resorting to altering the receiver
hardware. If you know the maths of the signal, it becomes an
exercise in decoding rather than soldering.

Q: What interesting hardware is in development to use with
GNURadio?
Check out the UniversalSoftwareRadioPeripheral

Q: When can I buy/build/compile a software based radio scanner,
as a complete package?
??

Q: What's the BroadcastFlag?
http://comsec.com/wiki?BroadcastFlag

Q: What's all the excitement about MeshNetworks?
http://comsec.com/wiki?MeshNetworks

Q: Does GnuRadio do transmitting yet?
It could. We've got a 420-450 MHz daughterboard for the USRP in
the works (along with a bunch more described at
UniversalSoftwareRadioPeripheral). There's nothing stopping
anyone from coding them up now. In fact, you could code one or
two now! Transmitters on some of our short lists include WBFM,
NBFM and FSK, followed by QPSK and friends.

We've got a digital TV modulator (atsc_tx) but don't plan on
putting it on the air (although pirate TV broadcasts are an
interesting idea!). It makes it easier to debug receiver code if
you build transmitter code that creates nice clean data streams,
which you can feed to the receiver as you debug it. Then once the
code demodulates nice clean signals, you can try receiving messy,
distorted, noisy, real-world signals.

There is a curious experiment that allows you transmitting AM
radio signals using no special hardware than a CRT display
http://www.erikyyy.de/tempest/

Q: How fast of a CPU do you need to receive FM or HDTV in real
time?
HowToFM works in real time with GnuRadioHardware, but HowtoHdTv
is at least 10:1 slower than realtime on current hardware.

Q: What hardware do I need to use GnuRadio?
GnuRadio runs on Linux machines. It's currently only tested on
x86. It tends to like a lot of CPU speed because it does a lot of
math. RAM is less important than CPU speed.

As for GnuRadioHardware, you'll need two things: an RfFrontEnd
and an AnalogToDigitalConverter (A/D). Together, these items
allow you to build a receiver. To build a transmitter, a
DigitalToAnalogConverter? (D/A) is required, along with a
PowerAmplifier? (PA). The exact design of these things depends on
the particular kind of radio you want to mess around with.

In HowtoHdTv, you will find details on GnuRadioHardware used for
HdTv reception, which should also work for almost anything else.

On a receiver, the RfFrontEnd performs the frequency translation
(DownConversion) of the RF frequencies of interest to an
IntermediateFrequency that's within the sampling range of the
AnalogToDigitalConverter (A/D).

The faster the sampling rate of the A/D, the wider slice of the
spectrum you can processes at once. There are tradeoffs regarding
i/o bandwidth, A/D dynamic range, MIPS required to processes the
signal, etc.

Q: What about hardware and software for amateur radio?
Here is a partial list of projects. Please add any others that
you know about.

GeraldYoungblood, AC5OG, Software Defined Radio for the Masses.
http://www.flex-radio.com. He is now taking orders for the
SDR-1000 transceiver. Looks pretty good. It uses a sound card for
analog i/o to the PC. We'll be building a GNU Radio application
to utilize it. 
Bob Larkin, W7PUA, DSP-10 2 meter transceiver
http://www.arrl.org/tis/info/dsp.html. TAPR has kits available
for order at http://www.tapr.org/tapr/html/dsp10.html.
Integrating the DSP-10 hardware with GNU Radio would be a good
project for someone. Leave out the Analog Devices EZ-KIT, and
connect to PC soundcard and GNU Radio software. 
Leif Asbrink, SM5BSZ, Linrad project.
http://antennspecialisten.se/~sm5bsz/linuxdsp/linrad.htm 
StephaneFillod, F8CFE, integrates GnuRadio with
GeraldYoungblood's SDR-1000 radio and others (DSP-10, etc.) in
Hamlib http://hamlib.org. See also
http://hamlib.org/gnuradio.html for a layout of the 3 layer
approach (tuner/DSP/UI).

Q. Are there any known projects aimed at receiving DirecTV?
satellite signals?
None that we know of. Feel free to start one, or merely build a
Wiki page that describes the frequencies, modulation parameters,
and kinds of radio equipment (e.g. aimable antennas? Dishes?)
needed. Links to primary technical sources of info would be
great. My suspicion is that most of what comes down is encrypted
-- but hey, part of the point of GNU Radio is to enable us to
"see for ourselves" what is out there in the spectrum around us.

After much research on the issue, I am reasonably certain that
they are only mpeg streams. The propagnda/sleight of hand, about
encyption only concerns the data stored on or streamed to/from
the smart card. This info sets the "tier" of channels one is
authorised to decode. When a new channel is selected, the
processor asks the smart card for permission to decode the mpeg
stream. But, I could be mistaken?

The MPEG-2 standard allows for the stream payload/data to be
"scrambled" in a user defined manner, while certain MPEG headers
stay in the clear. The standard also appears to provide a way to
distribute the access control data/commands. From what I have
read, my guess would be that the "scrambling" is relatively
simplistic but changes often based on encrypted data/commands
processed by the smart card.

Here are some interesting links: 
http://www.dtg.org.uk/reference/tutorial/mpeg.htm 
http://www.cs.nmt.edu/~cs489/mpegIP.pdf

---

GNURadio at Digital Communications Conference:

> http://comsec.com/wiki?DigitalCommunicationsConference

The 23rd Annual ARRL [1] and TAPR Digital Communications
Conference was held in Des Moines, Iowa September 10-12, 2004.
More information about past and upcoming DCC's can be found at
http://www.tapr.org/dcc/.

For more information about TAPR see http://www.tapr.org

Friday -- Matt, N2MJI, and Eric busy in the Demonstration Room.

http://www.tapr.org/dcc/2004/photos/matt.and.eric.sm2.jpg
http://www.tapr.org/dcc/2004/photos/matt.ettus.n2mji.sm2.jpg
http://www.tapr.org/dcc/2004/photos/demo.room.02.sm2.jpg

The USRP

http://www.tapr.org/dcc/2004/photos/usrp.sm2.jpg

Later Friday night, Matt and Eric pull and all nighter to get the
demo ready for Saturday's presentation.

http://www.tapr.org/dcc/2004/photos/matt.eric.work.1.sm2.jpg
http://www.tapr.org/dcc/2004/photos/matt.eric.work.2.sm2.jpg
http://www.tapr.org/dcc/2004/photos/matt.eric.work.3.sm2.jpg

And this is what happens Saturday morning :-)

http://www.tapr.org/dcc/2004/photos/eric.sleeps.sm2.jpg

The presentation Saturday afternoon went very well. Appologies
for no photos of the presentation, my camera was lost! Argh!

Here's Eric's assessment [paraphrased] of the DCC as posted to
the GNU Radio list on 2004-09-17:

Matt and I attended the TAPR Digital Communications Conference at
the end of last week. We worked like maniacs putting together a
couple of demos. There are pictures around somewhere of our hotel
room strewn with minicircuits parts, random cables, USRPs, test
equipment and laptops. It was a sight to behold.

In the end we demo'ed a 4 simultaneous channel FM transmitter,
where we were running 4 narrow band FM transmitters spaced about
50 kHz apart (could have been further apart without a problem).
In addition we demo'ed a parameterizable FSK transmitter and
receiver. We were hoping for 1 Mbit/sec, but in the few hours we
had to work on it, got it up to 100 kbit/sec. The system used a
simple packet framer that added a barker code to the beginning
for synchronization, converted bytes to bits to +/-1 symbols,
interpolated them (with our new fast interpolating FIR filter
code) and then ran them into the same frequency modulator block
used for the FM modulator. The demodulator was the inverse,
feeding an 8x oversampled proto-symbol stream into a correlator
that watched for the barker code. The output of the correlator
was a properly bit and packet aligned stream of bytes.

I met a lot of interesting folks and saw a few good papers
presented.

We also got to spend some time with a few folks working on
"Eagle" [2] -- one of the next amateur satellites. We
brainstormed possible ways to build a relatively wide-bandwidth
digital repeater on the satellite as opposed to the basic "bent
pipe".

The discussion centered around using up and down links in the 5
GHz range with, say 50 channels of FDMA uplink using BPSK and a
single 1 Mbit downlink using QPSK. Both links would incorporate
contemporary FEC which should allow the use of simple antennas.
With any luck, a patch antenna would work for the ground segment
-- no dishes required. TDMA was ruled out because of the high
peak power requirement for the ground station. The satellite
would receive the 50 channels of uplink with a single RF front
end and use SDR techniques to demod the 50 separate channels.
Actually, we thought about splitting the 50 channels into two
banks, using two RF front ends and SDRs for redundancy. The
digital repeater would allow the ground based stations to run
less power and lower antenna gain. The downlink would contain all
of the repeated uplinks plus additional information such as usage
history on all the uplinks and received bit error rates. You'd
monitor the downlink, then pick an uplink that hadn't been used
for a while. The up and downlinks would be 5 MHz apart, so you'd
be able to talk and listen at the same time. Uplinks could
contain digital data, digital voice, or a combination of the two.

Definitely worth the trip!

Eric
------- End of Forwarded Message -------


-- 
Diego Saravia 
dsa at unsa.edu.ar