Message: 3
Subject: [Discuss-gnuradio] selecting the USRP antenna port in GRC
I?m using an USRP-2 with a WBX daughterboard (Gnuradio 3.5.0), and I
want to
use the RX2 port as the receiver and the TX/RX port as the transmitter.
In
the GNU Radio companion flowgraph, I enter RX2 in the ?antenna?-field
for
the receiver UHD::USRP source block and TX/RX in the ?antenna?-field for
the
transmitter UHD::USRP sink block.
When transmitting, I deliberately provoke underflows at the transmitter
side
(I transmit packets, and stop transmitting in between). When connecting
a
scope at the receiver end, I seem to observe that during these underflow
periods, the receiver still switches back to the TX/RX port. When
transmitting, it switches to the RX2 port. This is despite the fact that
I
specify that the receiver has to use the RX2 port, which it should use
all
the time.
Any advice on this?
Fran?ois Quitin, Ph.D
Hi Francois, I will suggest you to attach the GRC flowgraph you created.
It will be easier to discuss the issue.
Dominique Ingala
Regards.
— En date de: Jeu 26.4.12, [email protected]
[email protected] a crit:
De: [email protected] [email protected]
Objet: Discuss-gnuradio Digest, Vol 113, Issue 30
: [email protected]
Date: Jeudi 26 avril 2012, 18h00
Send Discuss-gnuradio mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
Discuss-gnuradio Info Page
or, via email, send a message with subject or body ‘help’ to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than “Re: Contents of Discuss-gnuradio digest…”
Today’s Topics:
- Re: burst timestamps not being respected (Nowlan, Sean)
- Re: Question about USRP2 Tx procedure (Josh B.)
- selecting the USRP antenna port in GRC (Francois Quitin)
- Re: Question about USRP2 Tx procedure ([email protected])
- Re: Transmit and receive suing GMSK (wayne roberts)
- Porting new hardware to GNURadio (Getz, Robin)
- Re g: usrp_fft.py (sumitstop)
- Re: Question about USRP2 Tx procedure (Josh B.)
- Re: Re g: usrp_fft.py (Marcus D. Leech)
- Re: selecting the USRP antenna port in GRC (Josh B.)
- Re: Transmit and receive suing GMSK (Jamie Wo)
- Re: Transmit and receive suing GMSK (Jamie Wo)
- Re: Transmit and receive suing GMSK (Jamie Wo)
- Re: Porting new hardware to GNURadio (Martin B.)
- benchmark_tx.py BPSK Signal Details
(Sebastian =?iso-8859-1?Q?D=F6ring?=) - CMake build problem ([email protected])
- Re: Porting new hardware to GNURadio (Getz, Robin)
- Re: Porting new hardware to GNURadio (Johnathan C.)
- Post-facto waterfall plots (Marcus D. Leech)
- Re: benchmark_tx.py BPSK Signal Details (Alick Z.)
- Re: Porting new hardware to GNURadio (Getz, Robin)
- Re: Transmit and receive suing GMSK (wayne roberts)
- Re: USRP: is performance degradation of PSK OK? (Alick Z.)
Message: 1
Date: Wed, 25 Apr 2012 16:20:04 +0000
From: “Nowlan, Sean” [email protected]
To: “[email protected]” [email protected],
“[email protected]” [email protected]
Cc: “[email protected]” [email protected]
Subject: Re: [Discuss-gnuradio] burst timestamps not being respected
Message-ID: 195933287DC65748BA7AE867BA8E430B6218B125@apatlisdmbx02
Content-Type: text/plain; charset=“iso-8859-1”
Thanks for clarifying that. I ran a few tests and things look good. I’m
glad this turned out to be an easy fix!
Sean
From: [email protected] [[email protected]]
Sent: Wednesday, April 25, 2012 11:43 AM
To: Nowlan, Sean
Cc: [email protected]
Subject: RE: [Discuss-gnuradio] burst timestamps not being respected
No.
The only time you need to do that is when you reconfigure the topology
of a flow-graph. Parameters on individual blocks can be changed on the
fly without calling lock().
Although not all parameters on all blocks can be changed on the fly,
those that can be don’t require lock(). The constant on a multiply_const
definitely is changeable on the
fly, and most definitely doesn’t require lock()/unlock() around it.
On Wed, 25 Apr 2012 15:39:19 +0000, Nowlan, Sean wrote:
It was my understanding that this was necessary before reconfiguring a
flowgraph. Is that not the case?
From: discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid] on behalf
of [email protected] [[email protected]]
Sent: Wednesday, April 25, 2012 11:34 AM
To: [email protected]
Subject: Re: [Discuss-gnuradio] burst timestamps not being respected
On Wed, 25 Apr 2012 15:28:09 +0000, Nowlan, Sean wrote:
Hi all,
** Warning: this is rather a Josh question, but anyone’s comments are
welcome 
**
I’m running some flowgraphs in Python that transmit timed bursts. I
implemented a burst_tagger block whose work(…) function is very
similar to that of the stream tags demo in gr-uhd/examples. I also need
to be able to dynamically reconfigure the transmit power, which I’m
controlling with a gr_multiply_const_ff block. Calling lock() →
mult.set_k(k) → unlock() does this.
My biggest problem is that I’m observing that calls to lock (and/or
unlock) are emptying the USRP buffer prematurely, causing a burst to be
transmitted out-of-sync. I confirmed that the “tx_time” tag has the
right absolute time on it, but it’s not being respected by the USRP.
At first I thought it could be a USRP problem, but then I looked at the
implementation of gr_top_block and found that unlock() makes a call to
restart(), which in turn calls stop(). The implementation of
gr_uhd_usrp_sink overrides the stop() method to send an end-of-burst
packet to the USRP. I’m wondering if this is what’s clearing my buffer
and forcing it to be transmitted without respecting the time_spec in the
metadata. I haven’t dug through UHD code but I imagine end-of-burst
packets get higher priority than start-of-burst packets or time_specs.
On a sort-of related topic, I don’t like that the “tx_eob” tag affixed
by the burst tagger uses one sample; it causes an ugly spike to be
transmitted. I have two thoughts - I could write 0 to this sample, or I
could find a way to send a tag without a sample. I’m not sure if the
latter method is even possible. I’m guessing it’s not and that I’d have
to implement message passing.
Respectfully,
Sean Nowlan
So, why are you calling lock() around setting a simple constant for a
multiplier block?
-------------- next part --------------
An HTML attachment was scrubbed…
URL:
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120425/5ad23d13/attachment.html
Message: 2
Date: Wed, 25 Apr 2012 11:33:34 -0700
From: Josh B. [email protected]
To: baobaonanpo D [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Question about USRP2 Tx procedure
Message-ID: [email protected]
Content-Type: text/plain; charset=ISO-8859-1
If so, why we use half the time, that is the time changed from 0.65s
to 0.32s when we set the bitrate from 1M to 2M? the data proceed in
PC should be fixed and unrelated to the transmission rate, and much
lower than the transmission rate, so the time processing the same
amount data which stored in gnuradio’s FIFO must be still 0.65s, is
it?
If I am understanding correctly:
- Gnuradio creates a fixed amount of buffering
- The data source produces data faster than USRP consumes
- The buffering in gnuradio becomes filled 100% with samples
- The USRP consumes samples from this buffer at a fixed rate
So I think it makes logical sense that when you increase sample rate
(USRP consumes faster), the time to drain the buffer decreases.
Also, I want to point out:
There is a hook to control the size of these buffers in gnuradio
(presumably to reduce flow graph latency). You may be interested in
modifying this number and experimenting:
void start(int max_noutput_items=100000);
http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr_top_block.h#n63
-Josh
Message: 3
Date: Wed, 25 Apr 2012 11:38:57 -0700
From: “Francois Quitin” [email protected]
To: [email protected]
Subject: [Discuss-gnuradio] selecting the USRP antenna port in GRC
Message-ID: [email protected]
Content-Type: text/plain; charset=“iso-8859-1”
Dear mailing list,
I have a small question:
I?m using an USRP-2 with a WBX daughterboard (Gnuradio 3.5.0), and I
want to
use the RX2 port as the receiver and the TX/RX port as the transmitter.
In
the GNU Radio companion flowgraph, I enter RX2 in the ?antenna?-field
for
the receiver UHD::USRP source block and TX/RX in the ?antenna?-field for
the
transmitter UHD::USRP sink block.
When transmitting, I deliberately provoke underflows at the transmitter
side
(I transmit packets, and stop transmitting in between). When connecting
a
scope at the receiver end, I seem to observe that during these underflow
periods, the receiver still switches back to the TX/RX port. When
transmitting, it switches to the RX2 port. This is despite the fact that
I
specify that the receiver has to use the RX2 port, which it should use
all
the time.
Any advice on this?
Fran?ois Quitin, Ph.D.
BAEF Post-doctoral research fellow
Electrical & Computer Engineering Dept.
University of California
Santa Barbara, CA 93106-9560
Phone: +1-805-883-8599
Email: [email protected]
Home: www.ece.ucsb.edu/~fquitin
-------------- next part --------------
An HTML attachment was scrubbed…
URL:
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120425/74052629/attachment.html
Message: 4
Date: Wed, 25 Apr 2012 14:53:49 -0400
From: [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] Question about USRP2 Tx procedure
Message-ID: [email protected]
Content-Type: text/plain; charset=“utf-8”
Oooh, is there a configurable parameter for that in GRC yet?
On
Wed, 25 Apr 2012 11:33:34 -0700, Josh B. wrote:
Also, I want to
point out:
There is a hook to control the size of these buffers in
gnuradio
(presumably to reduce flow graph latency). You may be
interested in
modifying this number and experimenting:void
start(int max_noutput_items=100000);
http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr_top_block.h#n63
[1]
-Josh
Links:
[1]
http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr_top_block.h#n63
-------------- next part --------------
An HTML attachment was scrubbed…
URL:
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120425/234b6b34/attachment.html
Message: 5
Date: Wed, 25 Apr 2012 12:12:54 -0700
From: wayne roberts [email protected]
To: Jamie Wo [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Transmit and receive suing GMSK
Message-ID:
[email protected]
Content-Type: text/plain; charset=“iso-8859-1”
I was messing with the same thing myself.
First off, i’m not sure the packet decoder outputs in a real-time
fashion
to drive an audio sink. Try a scope sink to see how often the packet
decoder output updates: is there a better way?
On the GMSK demodulator side, I would think its best to observe the
signal
going into the demodulator, from uhd rx source. To see it in time
domain,
you can use Quadrature Demod → throttle → scope sink, making sure
signal
is centered at 0 and is reasonable distortion free. To be sure what its
supposed to look like, you can put on the transmitter side Quadrature
Demod
→ throttle → scope sink on the output of GMSK modulator.
And of course you can put an FFT sink right on the UHD source to see it
in
frequency domain. On the transmitter side, to UHD sink, I have found the
GMSK modulator outputs signal level near the maximum, meaning some
transient peaks could cause clipping on USRP transmitter, so it might be
prudent to put a multiply const (with 0.99 or so) just before going to
UHD
sink.
On Wed, Apr 25, 2012 at 1:41 AM, Jamie Wo [email protected]
wrote:
Data in file source can be received by the receiver. However, I am not
the data may be correctly received. However, after I tried this, the sound
To do what I want, is there any other blocks that need to be added in the
[email protected]
Discuss-gnuradio Info Page
-------------- next part --------------
An HTML attachment was scrubbed…
URL:
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120425/eecaeb44/attachment.html
Message: 6
Date: Wed, 25 Apr 2012 17:37:16 -0400
From: “Getz, Robin” [email protected]
To: [email protected]
Cc: “Hennerich, Michael” [email protected]
Subject: [Discuss-gnuradio] Porting new hardware to GNURadio
Message-ID: [email protected]
Content-Type: text/plain; charset=“us-ascii”
Hi.
Sorry for what might appear as a commercial at first - but I do have
some real
questions at the end - I’ll try to the description short.
We have developed a new RF learning platform [1] on a standard FMC card
[2]
(meets the electrical requirements, not the mechanical - it’s too long)
which can connect to nearly any recent Xilinx development system, that
we
started showing at X-Fest[3] yesterday.
The advantage of this, vs some existing platforms is bandwidth. The DAC
is a
16-Bit, 1200 MSPS (limited on this platform to 1GSPS, due to the clock
chip
we used), and the ADC is 14-Bit, 250 MSPS. The RF side includes a 400
MHz to
6 GHz Quadrature Modulator/Demodulator, separate Tx and Rx LO
Synthesisers
(35MHz to 4400MHz), and fixed gain on the Tx side, and a Variable Gain
on the
Rx Side. It’s clocking can handle multiple boards attached to the same
FPGA
(for MIMO), and can sync to a 1 pps (from GPS, or IEEE 1588) to sync
many,
many, many boards together.
The demo we are showing at X-Fest is the FMComms board, attached to a
Xilinx
ML605 FPGA, which runs Linux on Microblaze - playing a tone (Xilinx DDS)
out
the DAC, modulating that up to 2.4 GHz, sending it out the antenna,
receiving
it on the same board, demodulating it (at 2.4GHz), passing it through
the
VGA, to the ADC, were we capture the samples (into DDR), passing the
data to
GNU plot to create a png, and then passing the png to a web server, so
it can
be displayed on an external client across the network.
We have ported this to the Series 7 platforms - KC705, and others, and
are in
process finishing the port to Zynq[4] - for the standard Xilinx ZC702
platform [5] and the newly announced Zed[6]. This (I think) is where
things
get a little interesting. Microblaze running Linux is a little pokey -
Zynq
on the otherhand - is a dual ARM Cortex A9, running at 800MHz each, plus
FPGA
fabric - which allows some serious horsepower. This is a kit
(Zynq+FMComms)
that Avnet plans on selling [7].
Which brings me to the question:
We already have Linux IIO drivers[8] for all the parts on the board
(including
the ADCs[9] and DACs[10]), and are just trying to determine how (if at
all)
this fits within the GNU Radio framework.
When I looked at things (which wasn’t very long) - I didn’t see much in
terms
of native / real time connections to a platform which was running Linux
(PCIe, other other bus). Did I miss something?
Thanks in advance
-Robin
Just to be fair - others have done the same type of FMC Card [11] - the
advantage we have is gobs of channel bandwidth - enough to sample all of
bluetooth without doing any hopping at all.
[1] AD-FMCOMMS1-EBZ HDL Reference Design [Analog Devices Wiki]
[2] http://www.vita.com/fmc.html
[3] https://www.weboom.com/avnet2012/
[4]
Zynq 7000 SoC
[5] Boards
[6] http://www.zedboard.org/
[7]
http://www.em.avnet.com/en-us/design/drc/Pages/Analog-Devices-Zynq-Software-Defined-Radio-Kit.aspx
[8] Linux Industrial I/O Subsystem [Analog Devices Wiki]
[9]
https://github.com/mhennerich/linux/blob/fa8fc592243c82c0ddaa43f51be10e2123e1fa9b/drivers/staging/iio/adc/cf_ad9467_core.c
[10]
https://github.com/mhennerich/linux/blob/fa8fc592243c82c0ddaa43f51be10e2123e1fa9b/drivers/staging/iio/frequency/ad9122.c
[11] http://www.4dsp.com/FMC30RF.php
Message: 7
Date: Wed, 25 Apr 2012 15:28:51 -0700 (PDT)
From: sumitstop [email protected]
To: [email protected]
Subject: [Discuss-gnuradio] Re g: usrp_fft.py
Message-ID: [email protected]
Content-Type: text/plain; charset=us-ascii
While running usrp_fft.py in gnuradio 3.4.0 I am getting the following
error.
I installed in many system but only in single system this error is
coming.
Any clue 
oalec@ubuntu:/usr/local/bin$ ./usrp_fft.py -h
Traceback (most recent call last):
File “./usrp_fft.py”, line 27, in
from gnuradio.wxgui import stdgui2, fftsink2, waterfallsink2,
scopesink2, form, slider
File
“/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/fftsink2.py”,
line 31, in
from fftsink_gl import fft_sink_f, fft_sink_c
File
“/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/fftsink_gl.py”,
line
27, in
import fft_window
File
“/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/fft_window.py”,
line
33, in
import forms
File
“/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/forms/init.py”,
line 29, in
from converters import
File
“/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/forms/converters.py”,
line 118, in
class float_converter(abstract_converter):
File
“/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/forms/converters.py”,
line 119, in float_converter
def init(self, formatter=eng_notation.num_to_str):
AttributeError: ‘module’ object has no attribute ‘num_to_str’
Sumit Kr.
Research Assistant
Communication Research center
IIIT Hyderabad
India
View this message in context:
http://old.nabble.com/Reg%3A-usrp_fft.py-tp33750042p33750042.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Message: 8
Date: Wed, 25 Apr 2012 15:29:20 -0700
From: Josh B. [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] Question about USRP2 Tx procedure
Message-ID: [email protected]
Content-Type: text/plain; charset=ISO-8859-1
On 04/25/2012 11:53 AM, [email protected] wrote:
Oooh, is there a configurable parameter for that in GRC yet?
Not yet. It would fit well in the options block. Pretty easy to add, but
it would be a little more change to get the parameter into the WX gui
top block class. Qtgui and nogui mode both directly call the flow graph
start/run method, so the code change is purely in the generator.
-josh
[1]
http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr_top_block.h#n63
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
Message: 9
Date: Wed, 25 Apr 2012 18:42:15 -0400
From: “Marcus D. Leech” [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] Re g: usrp_fft.py
Message-ID: [email protected]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 04/25/2012 06:28 PM, sumitstop wrote:
scopesink2, form, slider
import forms
line 119, in float_converter
def init(self, formatter=eng_notation.num_to_str):
AttributeError: ‘module’ object has no attribute ‘num_to_str’
Sumit Kr.
Research Assistant
Communication Research center
IIIT Hyderabad
India
Well, if there is a bug, that version of Gnu Radio is no longer
fashionable, and more particularly, the entire “USRP classic” API has
been
deprecated, for a long time.
In “modern” Gnu Radio, you use the UHD API to talk to Ettus’ hardware,
and the corresponding application is uhd_fft.py
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Message: 10
Date: Wed, 25 Apr 2012 16:08:16 -0700
From: Josh B. [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] selecting the USRP antenna port in GRC
Message-ID: [email protected]
Content-Type: text/plain; charset=ISO-8859-1
Any advice on this?
This seems to be the opposite behaviour of what I would expect. From the
description above, I would guess that the source block has the antenna
set to TX/RX.
When you transmit, the receive antenna is forced to RX2.
When not transmitting, the receive antenna is .
http://files.ettus.com/uhd_docs/manual/html/dboards.html#wbx-series
You can confirm the behaviour with a test signal on RX2 and calling
uhd_fft -A RX2. uhd_fft -A TX/RX should show only leakage
-josh
Message: 11
Date: Thu, 26 Apr 2012 14:08:24 +1000
From: Jamie Wo [email protected]
To: wayne roberts [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Transmit and receive suing GMSK
Message-ID:
CABS7YrgM35rH-V57WX6cekkFEUDYQEtYhe=pOm9YoVr=removed_email_address@domain.invalid
Content-Type: text/plain; charset=“iso-8859-1”
On Thu, Apr 26, 2012 at 5:12 AM, wayne roberts
[email protected]wrote:
Hi Wayne,
Thanks for your reply. My responses are:
I was messing with the same thing myself.
First off, i’m not sure the packet decoder outputs in a real-time fashion
to drive an audio sink. Try a scope sink to see how often the packet
decoder output updates: is there a better way?
I am not sure the real-time fashion to drive an audio sink either, but
there should be a way to support it, I guess. I ran the flow graph and
saw
the update time interval from a scope sink is 3 - 5s . Is this too long?
Do you know what does this update time mean?
On the GMSK demodulator side, I would think its best to observe the
signal
prudent to put a multiply const (with 0.99 or so) just before going to UHD
sink.
I used Quadrature Demod → throttle → scope sink on the receiver side
to
see the signal going into the GSMK demod after uhd source. Also I
used Quadrature Demod → throttle → scope sink after the output of GMSK
mod. The time and frequency domain outputs are attached. Theoretically,
these two output should be similar or the same, However, they are quite
different after travelling over the air. Can you see any problems from
the
figures?
Thanks,
Jamie
The receiver side: UHD source → GMSK Demod → Packet decoder → File
The receiver side: UHD source → GMSK Demod → Packet decoder → Audio
decoder → audio sink.(samp_rate 48K), it works very well.Jamie
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
-------------- next part --------------
An HTML attachment was scrubbed…
URL:
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/22c86d42/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed…
Name: Transmit_frequency.png
Type: image/png
Size: 15836 bytes
Desc: not available
URL:
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/22c86d42/attachment.png
-------------- next part --------------
A non-text attachment was scrubbed…
Name: Tramsmit_time.png
Type: image/png
Size: 14351 bytes
Desc: not available
URL:
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/22c86d42/attachment-0001.png
-------------- next part --------------
A non-text attachment was scrubbed…
Name: Receiver_time.png
Type: image/png
Size: 15332 bytes
Desc: not available
URL:
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/22c86d42/attachment-0002.png
-------------- next part --------------
A non-text attachment was scrubbed…
Name: Receiver_frequency.png
Type: image/png
Size: 15574 bytes
Desc: not available
URL:
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/22c86d42/attachment-0003.png
Message: 12
Date: Thu, 26 Apr 2012 14:18:08 +1000
From: Jamie Wo [email protected]
To: Huzaifa Zafar [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Transmit and receive suing GMSK
Message-ID:
[email protected]
Content-Type: text/plain; charset=“iso-8859-1”
Hi Huzaifa,
I increased the sampling rate, but the problem is still there. Can you
give
me some details on what you have done to solve this problem?
Thanks!
Jamie
On Thu, Apr 26, 2012 at 12:05 AM, Huzaifa Zafar
[email protected]wrote:
The transmit side: File source → Packet encoder → GMSK Mod → UHD
The transmit side: Wav source → Packet encoder → GMSK Mod → UHD
this:–
Huzaifa Zafar
-------------- next part --------------
An HTML attachment was scrubbed…
URL:
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/af63d0cb/attachment.html
Message: 13
Date: Thu, 26 Apr 2012 14:32:47 +1000
From: Jamie Wo [email protected]
To: Javier S. [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Transmit and receive suing GMSK
Message-ID:
[email protected]
Content-Type: text/plain; charset=“iso-8859-1”
Hi Javier,
The sample rate of the UHD is 240KHz (uhd source and sink),
the samples/symbol is 2(Packet encoder and Decode) and the bits/symbol
is
1(Packet Encoder). Other parameters are set by default.
The sample of the audio sink is 48KHz as the wav file is sampled at
48Khz.
So I added rational resampler on both sides. I also tired to set the
sample rate at 48Khz without changing it during the process.
Any ideas?
Thanks,
Jamie
My parameters setting
On Thu, Apr 26, 2012 at 12:06 AM, Javier S. [email protected]
wrote:
-------------- next part --------------
An HTML attachment was scrubbed…
URL:
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/6a14574d/attachment.html
Message: 14
Date: Thu, 26 Apr 2012 09:19:20 +0200
From: Martin B. [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] Porting new hardware to GNURadio
Message-ID: [email protected]
Content-Type: text/plain; charset=“utf-8”
On Wed, Apr 25, 2012 at 05:37:16PM -0400, Getz, Robin wrote:
Which brings me to the question:
We already have Linux IIO drivers[8] for all the parts on the board (including
the ADCs[9] and DACs[10]), and are just trying to determine how (if at all)
this fits within the GNU Radio framework.
Hi Robin,
if you have the drivers, it should be a cakewalk to add sink/source
blocks.
When I looked at things (which wasn’t very long) - I didn’t see much in terms
of native / real time connections to a platform which was running Linux
(PCIe, other other bus). Did I miss something?
What exactly do you mean? The standard GNU Radio source comes with (real
time capable) drivers for all the Ettus stuff (via UHD), Funcube Dongle,
soundcards and more (see also
http://gnuradio.org/redmine/projects/gnuradio/wiki/Hardware), plus
there’s
3rd-party stuff like Balint’s drivers for RTL2832 TV tuners available on
the
webs. These things connect to the PC via USB or GigE.
I’m not sure if that’s what you were looking for, though.
MB
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin B.
Research Associate
Kaiserstra?e 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT – University of the State of Baden-W?rttemberg and
National Laboratory of the Helmholtz Association
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/b6aa70fe/attachment.pgp
Message: 15
Date: Thu, 26 Apr 2012 10:05:41 +0200
From: “Sebastian =?iso-8859-1?Q?D=F6ring?=” [email protected]
To: [email protected]
Subject: [Discuss-gnuradio] benchmark_tx.py BPSK Signal Details
Message-ID: [email protected]
Content-Type: text/plain;charset=iso-8859-1; format=“flowed”
Hello all,
I want to know how I could possibly find out the complete
details about the BPSK-Signal generated by the
benchmark_tx.py GNU Radio script.
Should I look at the code and at which file respectively?
Thanks in advance.
-Sebastian-
Message: 16
Date: Thu, 26 Apr 2012 12:30:51 +0100
From: [email protected]
To: [email protected]
Subject: [Discuss-gnuradio] CMake build problem
Message-ID: [email protected]
Content-Type: text/plain; charset=us-ascii
Hi,
I’m running debian unstable on a AMD64 platform and am running into a
problem which starts right at the top of the build process for a newly
checkout gnuradio version from git.
Below is output from running cmake:
[snip]
– Performing Test HAVE_WARN_ALL
– Performing Test HAVE_WARN_ALL - Success
– Performing Test HAVE_WARN_NO_UNINITIALIZED
– Performing Test HAVE_WARN_NO_UNINITIALIZED - Success
– Found PythonLibs:
optimized;/usr/lib/python3.2/config/libpython3.2.so;debug;/usr/lib/python3.2/config/libpython3.2.so
(found version “2.7.3rc2”)
– Found SWIG: /usr/bin/swig2.0 (found version “2.0.4”)
[snip]
So it found that /usr/bin/python is version 2.7.3rc2, but it decides
to use version 3.2 to link against. This makes the build process
rather sad later on! (Lots of link failures)
To get around this I changed in CMakeLists.txt
find_package(PythonLibs)
to be
find_package(PythonLibs 2.7.3)
But obviously that’ll only work for people running 2.7.3! (I’ve not
played with cmake before now, so there might be a simple way to fix
it)
I’m running cmake version 2.8.7.
However the build process goes further this time, but now breaks with:
[ 49%] Built target _runtime_swig_doc_tag
[ 49%] Generating doxygen xml for runtime_swig_doc docs
[ 49%] Generating runtime_swig_doc.i
[ 49%] Generating doxygen xml for general_swig_doc docs
[ 49%] Generating general_swig_doc.i
[ 49%] Generating doxygen xml for gengen_swig_doc docs
[ 49%] Generating gengen_swig_doc.i
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing error with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i.
giving up.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing error with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i.
giving up.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing error with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i.
giving up.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing problem with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i,
retrying.
XML parsing error with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i.
giving up.
XML parsing error with file
/home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i.
giving up.
Traceback (most recent call last):
File “/home/matt/gnuradio/docs/doxygen/swig_doc.py”, line 294, in
make_swig_interface_file(di, swigdocfilename,
custom_output=custom_output)
File “/home/matt/gnuradio/docs/doxygen/swig_doc.py”, line 222, in
make_swig_interface_file
make_func = di.get_member(make_name(block.name()), DoxyFunction)
File “/home/matt/gnuradio/docs/doxygen/doxyxml/base.py”, line 157, in
get_member
raise member()
doxyxml.base.Duplicate
make[2]: *** [gnuradio-core/src/lib/swig/gengen_swig_doc.i] Error 1
make[1]: ***
[gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all]
Error 2
make: *** [all] Error 2
Which I don’t know where to start to fix! However I can tell you that
the file its looking for, /home/…/swig/gengen_swig_doc.i doesn’t
exist, but I don’t know what should have created it.
Thanks,
Matt
Message: 17
Date: Thu, 26 Apr 2012 10:38:20 -0400
From: “Getz, Robin” [email protected]
To: [email protected]
Cc: “Hennerich, Michael” [email protected]
Subject: Re: [Discuss-gnuradio] Porting new hardware to GNURadio
Message-ID: [email protected]
Content-Type: text/plain; charset=“utf-8”
On Thu 26 Apr 2012 03:19, Martin B. pondered:
blocks.
Are there pointers for doing that?
Looks like:
http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide
?
Is there a “golden” reference to look at? (I assume
gr-howto-write-a-block-3.6.0.tar.gz
should have everything we need?)
When I looked at things (which wasn’t very long) - I didn’t see much in
terms of native / real time connections to a platform which was running
Linux (PCIe, other other bus). Did I miss something?What exactly do you mean? The standard GNU Radio source comes with (real
time capable) drivers for all the Ettus stuff (via UHD), Funcube Dongle,
soundcards and more (see also
http://gnuradio.org/redmine/projects/gnuradio/wiki/Hardware),
Yeah, that’s what I was missing. If it supports Comedi - it should
support IIO
without many issues.
SLOC Directory SLOC-by-Language (Sorted)
387 gr-comedi cpp=376,python=11
If that’s all that’s necessary - it shouldn’t take much time at all…
plus there’s
3rd-party stuff like Balint’s drivers for RTL2832 TV tuners available on
the webs. These things connect to the PC via USB or GigE.I’m not sure if that’s what you were looking for, though.
Close - although it appears we need to extend our FSF copyright
assignments
before we get too busy.
Thanks
-Robin
Message: 18
Date: Thu, 26 Apr 2012 07:58:01 -0700
From: Johnathan C. [email protected]
To: “Getz, Robin” [email protected]
Cc: “Hennerich, Michael” [email protected],
[email protected]
Subject: Re: [Discuss-gnuradio] Porting new hardware to GNURadio
Message-ID:
[email protected]
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Apr 26, 2012 at 07:38, Getz, Robin [email protected]
wrote:
Is there a “golden” reference to look at? (I assume
gr-howto-write-a-block-3.6.0.tar.gz
should have everything we need?)
This will give you the “canonical” format for writing your own
out-of-tree installable GNU Radio blocks.
A hardware source block would have no input ports, one or more output
ports for whatever streams your device generates, and a work function
that wraps calls to your existing sample-based I/O library for your
device. The main purpose of the work function would be to retrieve
samples from the device and put them into the block output buffer, and
some housekeeping to tell the GNU Radio runtime what you’ve done.
You’d also need write any needed setter/getter functions to perform
configuration of your source block either at initialization or during
runtime.
…although it appears we need to extend our FSF copyright assignments
before we get too busy.
This isn’t needed to develop your own distributed GNU Radio blocks;
you only need comply with the GPLv3 license terms of GNU Radio.
Johnathan
Message: 19
Date: Thu, 26 Apr 2012 10:58:23 -0400
From: “Marcus D. Leech” [email protected]
To: “[email protected]” [email protected]
Subject: [Discuss-gnuradio] Post-facto waterfall plots
Message-ID: [email protected]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Does anyone have any gnuplot scripts or Octave macros for producing a
waterfall plot from pre-recorded complex-float data?
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Message: 20
Date: Thu, 26 Apr 2012 23:04:01 +0800
From: Alick Z. [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] benchmark_tx.py BPSK Signal Details
Message-ID: [email protected]
Content-Type: text/plain; charset=UTF-8
On Thu, 26 Apr 2012 10:05:41 +0200, Sebastian D?ring wrote:
Hello all,
I want to know how I could possibly find out the complete details about
the BPSK-Signal generated by the benchmark_tx.py GNU Radio script.
Should I look at the code and at which file respectively?Thanks in advance.
-Sebastian-
I assume you are talking about the benchmark_tx.py under narrowband/
directory. With my (limited) experience with it, I can tell that it
depends on code in transmit_path.py under the same directory. The
packets related function can be found at gr-digital/python/{pkt.py and
packet_utils.py}. As with the modulation, it utilizes the code in
gr-digital/python/generic_mod_demod.py. So have a look at these files
you will get some more information about how the blocks are connected.
When you want to know the implementation/algorithm of blocks, you will
need to look into the C++ code (under lib/ and include/ directory).
Besides, the benchmark_tx.py script has a option ‘–log’, which can be
used to dump the output data of some blocks into files. You can then use
Octave/Matlab to read these data files and play with them(by plotting,
etc). To read the data files into Octave vectors you can use functions
described here.[1]
[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Octave
–
alick
Fedora 16 (Verne) user
https://fedoraproject.org/wiki/User:Alick
Message: 21
Date: Thu, 26 Apr 2012 11:31:40 -0400
From: “Getz, Robin” [email protected]
To: Johnathan C. [email protected]
Cc: “Hennerich, Michael” [email protected],
“[email protected]” [email protected]
Subject: Re: [Discuss-gnuradio] Porting new hardware to GNURadio
Message-ID: [email protected]
Content-Type: text/plain; charset=“iso-8859-1”
On Thu 26 Apr 2012 10:58, Johnathan C. pondered:
On Thu, Apr 26, 2012 at 07:38, Getz, Robin [email protected] wrote:
Is there a “golden” reference to look at? (I assume
gr-howto-write-a-block-3.6.0.tar.gz
should have everything we need?)This will give you the “canonical” format for writing your own
out-of-tree installable GNU Radio blocks.
And what is preferred? I always think in-tree is better - but that’s
just me.
A hardware source block would have no input ports, one or more output
ports for whatever streams your device generates, and a work function
that wraps calls to your existing sample-based I/O library for your
device. The main purpose of the work function would be to retrieve
samples from the device and put them into the block output buffer, and
some housekeeping to tell the GNU Radio runtime what you’ve done.
What is the widest band device (MSPS) that GNURadio can keep up with in
real
time? With this card - we are limited in memory bandwidth (vs a
desktop), and
Cortex A9 isn’t bad - but it’s no Intel CPU in terms of floating point
performance…
Who actually manages the location of the buffer? If GNURadio mmaps the
location (rather than malloc), it will save a memcpy in the work
function.
What’s the format that GNURadio wants (16-bit fixed? float? other?) We
can
make the format converter in the HDL, to decrease the load on the
processor.
You’d also need write any needed setter/getter functions to perform
configuration of your source block either at initialization or during
runtime.
There are lots of potential settings (Tx/Rx modulator frequencies,
ADC/DAC
sample rates, sync, MIMO config, etc) - I’m assuming some of those
configuration knobs are exposed to the python interface in a standard
manner
across hardware?
…although it appears we need to extend our FSF copyright assignments
before we get too busy.This isn’t needed to develop your own distributed GNU Radio blocks;
you only need comply with the GPLv3 license terms of GNU Radio.
Right - but I would think that it would be better to have things in
tree?
With all the FSF packages that we have contributed to in the past (gcc,
binutils, gdb, etc) without a FSF copyright assignment - the package
maintainer would not accept patches. I believe that is what is indicated
here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Whats-this-Copyright-Assignment
Thanks
-Robin
Message: 22
Date: Thu, 26 Apr 2012 08:48:29 -0700
From: wayne roberts [email protected]
To: Jamie Wo [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Transmit and receive suing GMSK
Message-ID:
[email protected]
Content-Type: text/plain; charset=“iso-8859-1”
You should use FFT sink with complex input, so its direct from uhd
source
with only throttle in between.
But the FFT you attached seems to indicate you have no signal into the
receiver.
Make sure they’re on the same RF frequency, and adjust gains appropriate
for the path loss between transmitter and receiver.
I am sure the packet encoder/decoder has some overhead, because its
adding
preamble, access_code, and crc.
It means the thruput should be less than your actual over-the-air
bitrate.
If you are sending audio, then you might be better served by one of the
audio encoders, such as the stuff under Vocoders category.
On Wed, Apr 25, 2012 at 9:08 PM, Jamie Wo [email protected]
wrote:
I was messing with the same thing myself.
Do you know what does this update time mean?
in frequency domain. On the transmitter side, to UHD sink, I have found
these two output should be similar or the same, However, they are quiteData in file source can be received by the receiver. However, I am not
I think if the sound received on the receiver is the same as the wav
test how to receive correctly right?
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
-------------- next part --------------
An HTML attachment was scrubbed…
URL:
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120426/33c21263/attachment.html
Message: 23
Date: Thu, 26 Apr 2012 23:52:19 +0800
From: Alick Z. [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] USRP: is performance degradation of
PSK OK?
Message-ID: [email protected]
Content-Type: text/plain; charset=UTF-8
On Wed, 25 Apr 2012 12:01:33 +0800, Alick Z. wrote:
bounds and being handled appropriately. Verify that clock recovery is
keeping a lock on the incoming data.–n
I also make some plots with the logged data. I can see that consecutive
1000 points of data after freq_recov or time_recov are distributed
around the unit circle. I think the freq/time recovery may not work
well. Given static indoor environment, the coherence time should be
long. I’d expect that the constellation points after timing recovery
should stay around two certain points for some thousands of samples. Is
it so?
If the problem is with the recovery loop, I wonder how I can adjust the
parameters of the loop. I have read Tom’s post about loop gain
values[1]. It seems that damping factor (0.707) should not be changed,
and loop bw is somewhere around pi/100 to 2*pi/100. So I find little
change can be done.
By plotting data directly output by usrp source I find that the
constellation points are disperse too. But I think it is due to lack of
synchronization between tx/rx. Am I wrong about this?
[1] Control Loop Gain Values — Rondeau Research
–
alick
Fedora 16 (Verne) user
https://fedoraproject.org/wiki/User:Alick
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
End of Discuss-gnuradio Digest, Vol 113, Issue 30