Send Discuss-gnuradio mailing list submissions to
address@hiddenTo subscribe or unsubscribe
via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradioor, via email, send a message with subject or body 'help' to
address@hiddenYou can reach the person managing the list at
address@hiddenWhen replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. Re: burst timestamps not being respected (Nowlan, Sean)
2. Re: Question about USRP2 Tx procedure (Josh
Blum)
3. selecting the USRP antenna port in GRC (Francois Quitin)
4. Re: Question about USRP2 Tx procedure (
address@hidden)
5. Re: Transmit and receive suing GMSK (wayne roberts)
6. Porting new hardware to GNURadio (Getz, Robin)
7. Re g: usrp_fft.py (sumitstop)
8. Re: Question about USRP2 Tx procedure (Josh Blum)
9. Re: Re g: usrp_fft.py (Marcus D. Leech)
10. Re: selecting the USRP antenna port in GRC (Josh Blum)
11. Re: Transmit and receive suing GMSK (Jamie Wo)
12. Re: Transmit and receive suing GMSK (Jamie Wo)
13. Re: Transmit and receive suing GMSK (Jamie Wo)
14. Re: Porting new hardware to GNURadio (Martin Braun)
15. benchmark_tx.py BPSK Signal Details
(Sebastian =?iso-8859-1?Q?D=F6ring?=)
16. CMake build problem (
address@hidden)
17. Re: Porting new hardware to GNURadio (Getz, Robin)
18. Re: Porting new hardware to GNURadio (Johnathan Corgan)
19. Post-facto waterfall plots (Marcus D. Leech)
20. Re: benchmark_tx.py BPSK Signal Details (Alick Zhao)
21. Re: Porting new hardware to GNURadio (Getz, Robin)
22. Re: Transmit and receive suing GMSK (wayne roberts)
23. Re: USRP: is performance degradation of PSK OK? (Alick Zhao)
----------------------------------------------------------------------
Message: 1
Date: Wed, 25 Apr 2012 16:20:04 +0000
From: "Nowlan, Sean" <
address@hidden>
To: "
address@hidden" <
address@hidden>,
"
address@hidden" <
address@hidden>
Cc: "
address@hidden" <
address@hidden>
Subject: Re: [Discuss-gnuradio] burst timestamps not being
respected
Message-ID: <address@hidden>
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:
address@hidden [
address@hidden]
Sent: Wednesday, April 25, 2012 11:43 AM
To: Nowlan, Sean
Cc:
address@hiddenSubject: 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=
address@hidden [discuss-gnuradio-bounces+sean.nowlan=
address@hidden] on behalf of
address@hidden
[
address@hidden]
Sent: Wednesday, April 25, 2012 11:34 AM
To:
address@hiddenSubject: 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 :-P **
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 Blum <
address@hidden>
To: baobaonanpo D <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] Question about USRP2 Tx procedure
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
> Dear josh,
>
> Thanks for your help very much!
>
> But I still have puzzles about the extra time such as 0.65s when
> I set the bit rate to 1M. we set the program to send 4s, and use
> wireshark and find the data through the network card continued for
> 4.65s, it indicates that the data be sent the last 0.65s is still in
> PC, in GNU-Radio's FIFO, not in USRP's buffer. Is it?
>
> 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:
1) Gnuradio creates a fixed amount of buffering
2) The data source produces data faster than USRP consumes
3) The buffering in gnuradio becomes filled 100% with samples
4) 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" <
address@hidden>
To: <
address@hidden>
Subject: [Discuss-gnuradio] selecting the USRP antenna port in GRC
Message-ID: <address@hidden>
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:
address@hiddenHome: 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:
address@hiddenTo: <
address@hidden>
Subject: Re: [Discuss-gnuradio] Question about USRP2 Tx procedure
Message-ID: <
address@hidden>
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 Blum 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 <
address@hidden>
To: Jamie Wo <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] Transmit and receive suing GMSK
Message-ID:
<CA+VqsrLrFAi5XDkUiQNbPhCMJaT+qQYqiNVzGJbBWLX+
address@hidden>
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 <
address@hidden> wrote:
> Hi all,
>
> I am currently working on tranmiting and receiving data using 2 USRPN210s.
> I got some ideas from here and did this task using GMSK in GRC.
>
> The transmit side: File source --> Packet encoder --> GMSK Mod --> UHD
> sink.
> The receiver side: UHD source --> GMSK Demod --> Packet decoder --> File
> sink.
>
> Data in file source can be received by the receiver. However, I am not
> sure whether the data has been received correctly. Does anyone know how to
> test it ?
>
> My method is to use wav source and audio sink like this:
>
> The transmit side: Wav source --> Packet encoder --> GMSK Mod --> UHD sink.
> The receiver side: UHD source --> GMSK Demod --> Packet
decoder --> Audio
> sink. (samp_rate 48K).
>
> I think if the sound received on the receiver is the same as the wav file,
> the data may be correctly received. However, after I tried this, the sound
> received was disjointedly, not as smooth as the wav source, and "audio
> underrun" happened sometimes.
>
> However, when I put all the blocks in one flow graph without UHD like this:
> wav source --> Packet encoder --> GMSK Mod --> GMSK Demod --> packet
> decoder --> audio sink.(samp_rate 48K), it works very well.
>
> Does anyone meet the same problem or know how to solve it? Is my way to
> test how to receive correctly right?
>
> To do what I want, is there any other blocks that need to be added in the
> GRC?
>
> Please give me some guidance.
>
> Thanks in advance.
>
>
Jamie
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
-------------- 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" <
address@hidden>
To: <
address@hidden>
Cc: "Hennerich, Michael" <
address@hidden>
Subject: [Discuss-gnuradio] Porting new hardware to GNURadio
Message-ID: <
address@hidden>
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]
http://wiki.analog.com/resources/fpga/xilinx/fmc/ad-fmcomms1-ebz[2]
http://www.vita.com/fmc.html[3]
https://www.weboom.com/avnet2012/[4]
http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm[5]
http://www.xilinx.com/products/boards-and-kits/EK-Z7-ZC702-G.htm[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]
http://wiki.analog.com/software/linux/docs/iio/iio[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 <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] Re g: usrp_fft.py
Message-ID: <
address@hidden>
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 :-)
address@hidden:/usr/local/bin$ ./usrp_fft.py -h
Traceback (most recent call last):
File "./usrp_fft.py", line 27, in <module>
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 <module>
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 <module>
import fft_window
File
"/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/fft_window.py", line
33, in <module>
import forms
File
"/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/forms/__init__.py",
line 29, in <module>
from converters import \
File
"/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/forms/converters.py",
line 118, in <module>
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.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 8
Date: Wed, 25 Apr 2012 15:29:20 -0700
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] Question about USRP2 Tx procedure
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 04/25/2012 11:53 AM,
address@hidden 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
> On
> Wed, 25 Apr 2012 11:33:34 -0700, Josh Blum 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>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio------------------------------
Message: 9
Date: Wed, 25 Apr 2012 18:42:15 -0400
From: "Marcus D. Leech" <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] Re g: usrp_fft.py
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 04/25/2012 06:28 PM, sumitstop wrote:
> 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 :-)
>
>
>
> address@hidden:/usr/local/bin$ ./usrp_fft.py -h
> Traceback (most recent call last):
> File "./usrp_fft.py", line 27, in<module>
> 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<module>
> 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<module>
> import fft_window
> File
> "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/fft_window.py", line
> 33,
in<module>
> import forms
> File
> "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/forms/__init__.py",
> line 29, in<module>
> from converters import \
> File
> "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/forms/converters.py",
> line 118, in<module>
> 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
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 Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org------------------------------
Message: 10
Date: Wed, 25 Apr 2012 16:08:16 -0700
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] selecting the USRP antenna port in GRC
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
>
> 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?
>
>
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 <user setting>.
http://files.ettus.com/uhd_docs/manual/html/dboards.html#wbx-seriesYou 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 <
address@hidden>
To: wayne roberts <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio]
Transmit and receive suing GMSK
Message-ID:
<CABS7YrgM35rH-V57WX6cekkFEUDYQEtYhe=pOm9YoVr=
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Thu, Apr 26, 2012 at 5:12 AM, wayne roberts <
address@hidden>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
> 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.
>
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
>
> On Wed, Apr 25, 2012 at 1:41 AM, Jamie Wo <
address@hidden>wrote:
>
>> Hi all,
>>
>> I am currently working on tranmiting and receiving data
using 2
>> USRPN210s. I got some ideas from here and did this task using GMSK in GRC.
>>
>> The transmit side: File source --> Packet encoder --> GMSK Mod --> UHD
>> sink.
>> The receiver side: UHD source --> GMSK Demod --> Packet decoder --> File
>> sink.
>>
>> Data in file source can be received by the receiver. However, I am not
>> sure whether the data has been received correctly. Does anyone know how to
>> test it ?
>>
>> My method is to use wav source and audio sink like this:
>>
>> The transmit side: Wav source --> Packet encoder --> GMSK Mod --> UHD
>> sink.
>> The receiver side: UHD source --> GMSK Demod --> Packet decoder --> Audio
>> sink. (samp_rate 48K).
>>
>> I think if the sound received on the receiver is the same as the
wav
>> file, the data may be correctly received. However, after I tried this, the
>> sound received was disjointedly, not as smooth as the wav source, and
>> "audio underrun" happened sometimes.
>>
>> However, when I put all the blocks in one flow graph without UHD like
>> this:
>> wav source --> Packet encoder --> GMSK Mod --> GMSK Demod --> packet
>> decoder --> audio sink.(samp_rate 48K), it works very well.
>>
>> Does anyone meet the same problem or know how to solve it? Is my way to
>> test how to receive correctly right?
>>
>> To do what I want, is there any other blocks that need to be added in the
>> GRC?
>>
>> Please give me some guidance.
>>
>> Thanks in advance.
>>
>> Jamie
>>
>>
_______________________________________________
>> Discuss-gnuradio mailing list
>>
address@hidden>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>
>>
>
-------------- 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 <
address@hidden>
To: Huzaifa Zafar <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] Transmit and receive suing GMSK
Message-ID:
<CABS7YrhgoaoEB7VEMa4fu=
address@hidden>
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
<
address@hidden>wrote:
> Try increasing the sampling rate (to 1M). We were doing something similar,
>
and in our case, it helped.
>
> On Wed, Apr 25, 2012 at 1:41 PM, Jamie Wo <
address@hidden>wrote:
>
>> Hi all,
>>
>> I am currently working on tranmiting and receiving data using 2
>> USRPN210s. I got some ideas from here and did this task using GMSK in GRC.
>>
>> The transmit side: File source --> Packet encoder --> GMSK Mod --> UHD
>> sink.
>> The receiver side: UHD source --> GMSK Demod --> Packet decoder --> File
>> sink.
>>
>> Data in file source can be received by the receiver. However, I am not
>> sure whether the data has been received correctly. Does anyone know how to
>> test it ?
>>
>> My method is to use wav source and audio sink like
this:
>>
>> The transmit side: Wav source --> Packet encoder --> GMSK Mod --> UHD
>> sink.
>> The receiver side: UHD source --> GMSK Demod --> Packet decoder --> Audio
>> sink. (samp_rate 48K).
>>
>> I think if the sound received on the receiver is the same as the wav
>> file, the data may be correctly received. However, after I tried this, the
>> sound received was disjointedly, not as smooth as the wav source, and
>> "audio underrun" happened sometimes.
>>
>> However, when I put all the blocks in one flow graph without UHD like
>> this:
>> wav source --> Packet encoder --> GMSK Mod --> GMSK Demod --> packet
>> decoder --> audio sink.(samp_rate 48K), it works very well.
>>
>> Does anyone meet the same problem or know how to solve it? Is my
way to
>> test how to receive correctly right?
>>
>> To do what I want, is there any other blocks that need to be added in the
>> GRC?
>>
>> Please give me some guidance.
>>
>> Thanks in advance.
>>
>> Jamie
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>>
address@hidden>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>
>>
>
>
> --
> 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 <
address@hidden>
To: Javier Suarez <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] Transmit and receive suing GMSK
Message-ID:
<CABS7YriL-9tHKdnLA1MkNHaO8mT0rCxBGkm2+
address@hidden>
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 Suarez <
address@hidden> wrote:
>
> Hi Jamie Wo,
>
> For helping you, could you give us some details about the sample rate
of
>> the UHD, rate symbol and samples/symbol you are transmitting. Which are
>> the sample rate of the input?
>>
>
> Javier M.
>
>
>
-------------- 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 Braun <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] Porting new hardware to GNURadio
Message-ID:
<
address@hidden>
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 Braun
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?=" <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] benchmark_tx.py BPSK Signal Details
Message-ID: <
address@hidden>
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:
address@hiddenTo:
address@hiddenSubject: [Discuss-gnuradio] CMake build problem
Message-ID: <
address@hidden>
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 <module>
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" <
address@hidden>
To: <
address@hidden>
Cc: "Hennerich, Michael" <
address@hidden>
Subject: Re: [Discuss-gnuradio] Porting new hardware to
GNURadio
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="utf-8"
On Thu 26 Apr 2012 03:19, Martin Braun pondered:
> 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.
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 Corgan <
address@hidden>
To: "Getz, Robin" <
address@hidden>
Cc: "Hennerich, Michael" <
address@hidden>,
address@hiddenSubject: Re: [Discuss-gnuradio] Porting new hardware to GNURadio
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Apr 26, 2012 at 07:38, Getz, Robin <
address@hidden> 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" <
address@hidden>
To: "
address@hidden" <
address@hidden>
Subject: [Discuss-gnuradio] Post-facto waterfall plots
Message-ID: <
address@hidden>
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 Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org------------------------------
Message: 20
Date: Thu, 26 Apr 2012 23:04:01 +0800
From: Alick Zhao <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] benchmark_tx.py BPSK Signal Details
Message-ID: <
address@hidden>
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" <
address@hidden>
To: Johnathan Corgan <
address@hidden>
Cc: "Hennerich, Michael" <
address@hidden>,
"
address@hidden" <
address@hidden>
Subject: Re: [Discuss-gnuradio] Porting
new hardware to GNURadio
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Thu 26 Apr 2012 10:58, Johnathan Corgan pondered:
> On Thu, Apr 26, 2012 at 07:38, Getz, Robin <
address@hidden> 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-AssignmentThanks
-Robin
------------------------------
Message: 22
Date: Thu, 26 Apr 2012 08:48:29 -0700
From: wayne roberts <
address@hidden>
To: Jamie Wo <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] Transmit and receive suing
GMSK
Message-ID:
<CA+Vqsr+t+ciV7OGUg2S+
address@hidden>
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 <
address@hidden> wrote:
>
>
> On Thu, Apr 26, 2012 at 5:12 AM, wayne roberts <
address@hidden>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
>> 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.
>>
>
> 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
>
>
>>
>> On Wed, Apr 25, 2012 at 1:41 AM, Jamie Wo <
address@hidden>wrote:
>>
>>> Hi all,
>>>
>>> I am currently working on tranmiting and receiving data using 2
>>> USRPN210s. I got some ideas from here and did this task using GMSK in GRC.
>>>
>>> The transmit side: File source --> Packet encoder --> GMSK Mod --> UHD
>>> sink.
>>> The receiver side: UHD source --> GMSK Demod --> Packet decoder --> File
>>> sink.
>>>
>>> Data in file source can be received by the receiver. However, I am not
>>> sure whether the data has been received correctly. Does anyone know how to
>>> test it ?
>>>
>>> My method is to use wav source and audio sink like this:
>>>
>>> The transmit side: Wav source --> Packet encoder
--> GMSK Mod --> UHD
>>> sink.
>>> The receiver side: UHD source --> GMSK Demod --> Packet decoder -->
>>> Audio sink. (samp_rate 48K).
>>>
>>> I think if the sound received on the receiver is the same as the wav
>>> file, the data may be correctly received. However, after I tried this, the
>>> sound received was disjointedly, not as smooth as the wav source, and
>>> "audio underrun" happened sometimes.
>>>
>>> However, when I put all the blocks in one flow graph without UHD like
>>> this:
>>> wav source --> Packet encoder --> GMSK Mod --> GMSK Demod --> packet
>>> decoder --> audio sink.(samp_rate 48K), it works very well.
>>>
>>> Does anyone meet the same problem or know how to solve it? Is my way to
>>>
test how to receive correctly right?
>>>
>>> To do what I want, is there any other blocks that need to be added in
>>> the GRC?
>>>
>>> Please give me some guidance.
>>>
>>> Thanks in advance.
>>>
>>> Jamie
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>>
address@hidden>>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>>
>>>
>>
>
-------------- 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 Zhao <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] USRP: is performance degradation of
PSK OK?
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=UTF-8
On Wed, 25 Apr 2012 12:01:33 +0800, Alick Zhao wrote:
> On Tue, 24 Apr 2012
07:52:09 -0700, Nick Foster wrote:
>
>>
>> Alick,
>>
>> You will have to instrument your flowgraph in order to find out. Add file
>> sinks to different stages in the transmitter and receiver to verify that
>> the data looks as expected. You can use MATLAB or Octave to visualize the
>> data. There are scripts in gnuradio-core/src/utils which will aid you in
>> loading sample data into MATLAB. Verify that the frequency offset is within
>> 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]
http://www.trondeau.com/blog/2011/8/13/control-loop-gain-values.html--
alick
Fedora 16 (Verne) user
https://fedoraproject.org/wiki/User:Alick------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradioEnd of Discuss-gnuradio Digest, Vol 113, Issue 30
*************************************************