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: NOAA antenna (John Coppens)
2. Re: gr-ctrlport and multiple applications (Tom Rondeau)
3. Re: where is gnuradio-examples/python/pfb? (Tom Rondeau)
4. Regarding on the new OFDM implementation. (Alex Zhang)
5. Re: VITA49 - VRT Output from spectrum analyser (Josh Blum)
6. Upcoming GNURadio Conferences in USA? (Eric Cottrell)
7. Troubled by the pfb channelizer center frequency location
(LD Zhang)
8. Re: Troubled by the pfb channelizer center frequency location
(LD Zhang)
9. Re: NOAA antenna (Patrik Tast)
10. Re: WX GUI FFT Sink Performance (Mark McCarron)
11. Re: Discuss-gnuradio Digest, Vol 117, Issue 24
(Dominique Guelord
Ingala)
12. Can I make USRP switch between speaking and muting? (??)
13. Allign LOs for SBX boards (Dominique Guelord Ingala)
14. Re: Allign LOs for SBX boards (Josh Blum)
15. Re: WX GUI FFT Sink Performance (Mark McCarron)
16. Re: Regarding on the new OFDM implementation. (Martin Braun (CEL))
17. new block style instructions doubt (Nemanja Savic)
18. Requesting for suggestion to transmit Signal in 2 x 2 MIMO
network (RAM CHARAN M C)
19. Re: Dev Call May 16 / Google Hangout (Martin Braun (CEL))
20. Re: new block style instructions doubt (Martin Braun (CEL))
21. Re: WX GUI FFT Sink Performance (Marcus D. Leech)
22. Re: NOAA antenna (
address@hidden)
23. Something for "next" in
the GUI area (Marcus D.
Leech)
24. DSP Book : Free as PDF (Michael Dickens)
25. Re: DSP Book : Free as PDF (Marcus D. Leech)
26. Re: WX GUI FFT Sink Performance (Mark McCarron)
27. Re: DSP Book : Free as PDF (Evan Merewether)
28. Re: WX GUI FFT Sink Performance (Marcus D. Leech)
29. Re: DSP Book : Free as PDF (Marcus D. Leech)
----------------------------------------------------------------------
Message: 1
Date: Wed, 15 May 2013 13:29:09 -0300
From: John Coppens <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] NOAA antenna
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=US-ASCII
On Wed, 15 May 2013 08:29:59 -0400
"Marcus D. Leech" <
address@hidden> wrote:
> I think a lot of people use a QFH antenna, or a turnstile antenna for
> NOAA satellites at 137Mhz.
Note that you will almost certainly need an antenna amplifier too (unless
you make a huge antenna ;) Even a specialized receiver needs one to
compensate for the cable loss. And the ezcap receiver is not too
sensitive either...
As Marcus stated, many use QFH antennas (sometimes called QHA), though
many also use turnstiles (two, crossed dipoles) because it looks easier
to build.
If interested, there's some info you
might find interesting on my site:
http://www.jcoppens.com/ant/qfh/index.en.php (QFH antenna construction)
http://www.jcoppens.com/sat/gaasfet/index.en.php (Example antenna amp)
John
------------------------------
Message: 2
Date: Wed, 15 May 2013 18:01:40 +0100
From: Tom Rondeau <
address@hidden>
To: Alexandru Csete <
address@hidden>
Cc: GNURadio Discussion List <
address@hidden>
Subject: Re: [Discuss-gnuradio] gr-ctrlport and multiple applications
Message-ID:
<CA+SzT6iy8idL4-_UL_S=EAhF=
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, May 15, 2013 at 9:42 AM, Alexandru Csete <
address@hidden> wrote:
> Greetings,
>
> Today, we can configure gr-ctrlport to use a specific port. Doing so
> leads to a problem when trying to execute more than one gnuradio
> application even if they are not explicitly using controlport. The
> first application will take control of the network socket
and the
> second will fail to start with:
>
> RuntimeError: Network.cpp:1104: Ice::SocketException:
> socket exception: Address already in use
>
> According to Ice documentation, I can specify a different
> configuration file for each
application using ICE_CONFIG environment,
> but this seems to be overruled by the gnuradio runtime.
>
> Is there a way to configure controlport so that application A uses one
> port, application B uses another port, etc.?
>
> Is it possible to disable controlport at runtime?
>
> Alex
You can configure ControlPort through the preference files and set
enable/disable in ~/.gnuradio/config.conf using:
[ControlPort]
on = True
The 'config' option allows you to point to an ICE configuration file,
where you can define endpoints. One thing here is that you don't need
to set a port number for your endpoint, at which point it will select
an ephemeral port for you for each ControlPort app that's launched.
You can also not use a configuration file, and in this case, again, it
will find an open ephemeral port and enable it on all current
interfaces.
For programmatic
control over if ControlPort is enabled/disabled in
your application, you can set the environmental variable. In Python, I
do it this way:
os.environ['GR_CONF_CONTROLPORT_ON'] = 'True' (or 'False')
The environmental variables will override any settings in config.conf
or the installed gnuradio-runtime.conf settings and are checked every
time you query the preferences.
You should also be able to use:
gr.prefs().set_string('ControlPort', 'On', 'False')
I'm not sure if how we have it set up allows you to easily set
different endpoints to different apps. Like I said, you can not
specify the port, and it will select one for you. But if you want to
control this for many different applications, maybe the best way is to
set the GR_CONF_CONTROLPORT_CONFIG variable (or with the
set_string('ControlPort', 'Config', 'FILENAME') method) for each
application to point to your different ICE
config files.
Tom
------------------------------
Message: 3
Date: Wed, 15 May 2013 18:08:53 +0100
From: Tom Rondeau <
address@hidden>
To: LD Zhang <
address@hidden>
Cc: discuss-gnuradio Discussion Group <
address@hidden>
Subject: Re: [Discuss-gnuradio] where is gnuradio-examples/python/pfb?
Message-ID:
<CA+SzT6hbNnUAOtVaGOw+9rkzsZ84W7ppxSeFq7OMwspD2P5d+
address@hidden>
Content-Type: text/plain;
charset=ISO-8859-1
On Wed, May 15, 2013 at 12:15 AM, LD Zhang <
address@hidden> wrote:
> I find the example at the online page
>
http://gnuradio.org/doc/doxygen/page_pfb.html very helpful (code at the end
> of the page). It runs and generates nice plots. Still trying to get used to
> it.
Great!
> But the code at gr-filter/python/pfb.py does not run. It appears to be a
> module? How do I run it or use it?
That's not a Python file that is designed to be run from the command
line. It gets installed and provides helper hier_block2 classes to
make using the PFB code easier. So you would use it in a program like
filter.pfb.channelizer_ccf(...).
Look at the examples in
gr-filter/examples, not at this file.
> Also what does gr-filter/python/qa_pfb_channelizer.py do? Some of this trace
> to pfb_channelizer_ccf.cc code?
What does "blks2" relate to this and other
> examples?
>
> Thanks for explaining,
>
> LD
Yes, the QA code is our quality assurance code that is executed during
'make test'. But they can be useful to show you how to use the blocks.
The blks2 is a set of classes created in
gnuradio-core/src/python/gnuradio/blks2impl, including some of the
original PFB stuff that is now moved into gr-filter completely. Note
that we have deleted blks2 from GNU Radio on the next branch (and
therefore in 3.7), so this will all be replaced by things like
filter.pfb....
Tom
------------------------------
Message: 4
Date: Wed, 15 May 2013 12:13:16 -0500
From: Alex Zhang <
address@hidden>
To: gnuradio mailing list <
address@hidden>
Subject: [Discuss-gnuradio] Regarding on the new OFDM implementation.
Message-ID:
<CA+FEAndNZ_GfyA6AhVGHTGMrk-R6md=Po6WfmihBM+
address@hidden>
Content-Type: text/plain; charset="windows-1252"
Hi,
It is excited to see the new OFDM implementation has been merged and test
in the GNURadio master branch. Several Questions:
1. What are the main changes from the old design?
2. Seems it support NC-OFDM as the user can arrange the carriers? And how
is the gain of dB between the occupied carriers and vacant carriers?
3. How about the data rate which is the supported by the new design?
Will find a time to evaluate the tx_ofdm.grc and
rx_ofdm.grc, but still
looking forward to the answers of the above questions.
Best
Regards,
Alex,
*Dreams can come true ? just believe.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130515/af9b643b/attachment.html>
------------------------------
Message: 5
Date: Wed, 15 May 2013 13:58:39 -0500
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] VITA49 - VRT Output from spectrum
analyser
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
>
> Yes, that would be fab.
>
> I
> would caution that because VITA-49 doesn't actually specify any
> encapsulation mechanisms for any higher-layer protocols, there's no
> "standard" way of placing VITA-49 over TCP and UDP, it is necessarily
> proprietary.
>
> It would be much better if there were a standard
> encapsulation--that would make having a Gnu Radio block be a very
> desirable thing...
>
So this set of blocks will encapsulate a stream over VRL (vita radio
link layer) and VITA49 IF data packets. The VRL is really what makes
this work because its so much easier to do bounds recovery with.
Perhaps you can use this with the GrExtras socket
block to receive from
your analyzer. Or perhaps with some minor
modifications:
https://github.com/guruofquality/grextras/wiki/NextBlocks#wiki-de-serialization-io-blocks-josh
------------------------------
Message: 6
Date: Wed, 15 May 2013 15:26:58 -0400 (EDT)
From: "Eric Cottrell" <
address@hidden>
To: "discuss-gnuradio" <
address@hidden>
Subject: [Discuss-gnuradio] Upcoming GNURadio Conferences in USA?
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="utf-8"
Hello,
I got an email from Ettus Research
and noticed there is an SDR Conference near me in Worchester, MA (NEWSDR?13). Unfortunate for me, it is this Friday so I can not get food or parking because I cannot preregister (link gives an error).
I remember there was a GNU Radio conference in the fall (a past one was held in Philly) that I have not been able to attend. Will there be other GNURadio conferences this year or do I have wait until 2014?
73 Eric
------------------------------
Message: 7
Date: Wed, 15 May 2013 16:16:08 -0700
From: LD Zhang <
address@hidden>
To: discuss-gnuradio Discussion Group <
address@hidden>
Subject: [Discuss-gnuradio] Troubled by the pfb channelizer
center
frequency
location
Message-ID:
<CAMDE96C1LpQfR-PGWSpWN4ptJEZL6hODbw+
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Dear Group,
I am learning to do the pfb channelizer using the now famous example on the
documentation page at:
http://gnuradio.org/doc/doxygen/page_pfb.htmlThe example is at the end of the page, where a 9-subchannels are pulled out
of the original 9 kHz bandwidth signal. The original signals' tones are at
[freqs = [-4070, -3050, -2030, -1010, 10, 1020, 2040, 3060, 4080]
The original signal bandwidth should be from -4500 to 4500 Hz.
According to my understanding the first channel signal should be centered
at
-70 Hz, since the 9 channels' centers should be
at [-4000, -3000, ...,
3000, 4000].
But the output plot from the example shows that the first tone is at
slightly greater than 0 Hz frequency.
I don't know what is going on here?
LD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130515/8d4ec6fa/attachment.html>
------------------------------
Message: 8
Date: Wed, 15 May 2013 16:26:58 -0700
From: "LD Zhang" <
address@hidden>
To: "'discuss-gnuradio Discussion Group'" <
address@hidden>
Subject: Re: [Discuss-gnuradio] Troubled by the
pfb channelizer center
frequency location
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
I guess I got it! The default channel map is such that the first channel is
the UN-fftshifted frequency location which is at 10 Hz (the 5th one on the
list)! Whoo! It would be nice to tell a newcomer about this.
LD
From: LD Zhang [mailto:
address@hidden]
Sent: Wednesday, May 15, 2013 4:16 PM
To: discuss-gnuradio Discussion Group
Subject: Troubled by the pfb channelizer center frequency location
Dear Group,
I am learning to do the pfb channelizer using the now famous example on the
documentation page at:
http://gnuradio.org/doc/doxygen/page_pfb.htmlThe example is at the end of the page, where a 9-subchannels are pulled out
of the original 9 kHz bandwidth signal. The original signals' tones are at
[freqs = [-4070, -3050, -2030, -1010, 10, 1020, 2040, 3060, 4080]
The original signal bandwidth should be from -4500 to 4500 Hz.
According to my understanding the first channel signal should be centered at
-70 Hz, since the 9 channels' centers should be at [-4000, -3000, ..., 3000,
4000].
But the output plot from the example shows that the first tone is at
slightly greater than 0 Hz frequency.
I don't know what is going on here?
LD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130515/03104bb0/attachment.html>
------------------------------
Message: 9
Date: Thu, 16 May 2013 07:47:20 +0300
From: Patrik Tast <
address@hidden>
To: Discuss-GNURadio <
address@hidden>
Subject: Re: [Discuss-gnuradio] NOAA antenna
Message-ID: <
address@hidden>
Content-Type: text/plain;
charset="iso-8859-1"
Hi
Here is the 137 MHz RHCP antenna we have developed
http://www.poes-weather.com/download/jm-dca/This antenna will give you better performance at low satellite
elevations (horizons).
It is easy to build and you don't have to be that careful.
We don't use a pre-amp if coax < 15 m (loss ~2 dB RG-58).
--
Best Regards,
Patrik Tast
POES-Weather Ab Ltd Remote Sensing
Business id: FI 23624190
CEO Patrik Tast
GSM: +358 40 833 11 70
Street address: Furuskogsv?gen 89
Postal code: 65280
City: Vasa
Country: Finland
Web: poes-weather.com
-----Original Message-----
From: John Coppens <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] NOAA antenna
Date: Wed, 15 May 2013 13:29:09 -0300
On Wed, 15 May
2013 08:29:59 -0400
"Marcus D. Leech" <
address@hidden> wrote:
> I think a lot of people use a QFH antenna, or a turnstile antenna for
> NOAA satellites at 137Mhz.
Note that you will almost certainly need an antenna amplifier too (unless
you make a huge antenna ;) Even a specialized receiver needs one to
compensate for the cable loss. And the ezcap receiver is not too
sensitive either...
As Marcus stated, many use QFH antennas (sometimes called QHA), though
many also use turnstiles (two, crossed dipoles) because it looks easier
to build.
If interested, there's some info you might find interesting on my site:
http://www.jcoppens.com/ant/qfh/index.en.php (QFH antenna construction)
http://www.jcoppens.com/sat/gaasfet/index.en.php (Example antenna amp)
John
_______________________________________________
Discuss-gnuradio mailing list
address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130516/d805b80d/attachment.html>
------------------------------
Message:
10
Date: Thu, 16 May 2013 06:21:34 +0100
From: Mark McCarron <
address@hidden>
To: GNURadio Discussion List <
address@hidden>
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Marcus,
Sorry for the late reply on this, I've been upgrading my hardware and I'm just catching up. Here is my issue, in Spectrum lab if I provide a FFT Input length of 65536 on a 192Ksps stream, I get the
following characteristics:
Effect of FFT settings with fs= 192.000 kHz:
Width of one FFT-bin: 2.92969 Hz
Equiv. noise bandwidth: 4.39453 Hz
Max freq
range: 0.00000 Hz .. 96.0000 kHz
FFT window time: 0.341 s
Overlap from scroll interval: 98.4 %
It runs quite fast. If I provide the same FFT size to WX GUI FFT sink, it basically hangs. Do you know why?
Regards,
Mark McCarron
Date: Sat, 11 May 2013 15:59:18 -0400
From:
address@hiddenTo:
address@hidden;
address@hiddenSubject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
I figured that one out, but why is
the performance
so poor?
In other applications, I can push over half a million samples
without causing issues.
Regards,
Mark McCarron
Your OpenGL implementation may suck.
What sample rate are you using?
If it's quite a low rate, then with a large number of bins, there
may be no way to achieve the given frame rate, given the sample
rate, and FFT size.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130516/2174e73b/attachment.html>
------------------------------
Message: 11
Date: Thu, 16 May 2013 08:29:36 +0100 (BST)
From: Dominique Guelord Ingala <
address@hidden>
To: "
address@hidden" <
address@hidden>
Subject: Re: [Discuss-gnuradio]
Discuss-gnuradio Digest, Vol 117,
Issue 24
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Topic 7:
> Hi,
> I'm designing a beamforming network. I want to know if it is now
> possible to align LOs from multiple SBX and usrp boards. It was said
> from Ettus Research website that the re-synchronization feature? in UHD
> using SBX boards will be released in 2012. Could you please confirm if
> it is implementable.
> Regards.
> Dominique.
>
>>
http://files.ettus.com/uhd_docs/manual/html/sync.html#align-los-in-the-front-end-sbx-wbx-n-series>>The set/clear_command_time are exposed for the UHD source and sink
>>blocks. You can do this in gnradio with c++ or python.
>> -josh
Hi Josh,
Thanks for your reply.
I've been working on this for a while, but I'm still confused a bit. Please what is the directory for the UHD source and sink blocks where the timed command must be applied. Which part of the code must be changed in these files. Also how will I know that the LOs are now alligned.?
I'm using ubuntu 11.10. I found 2 files (gr_uhd_usrp_source.cc and gr_uhd_usrp_sink.cc) under the directory : gnuradio/gr-uhd/lib. Is this right? I'm not too sure how to modify these files.
Your answer will be
appreciated.
Regards.
Dominique.
>________________________________
> De?: "
address@hidden" <
address@hidden>
>??:
address@hidden >Envoy? le : Mercredi 22 ao?t 2012 18h00
>Objet?: Discuss-gnuradio Digest, Vol 117, Issue 24
>
>
>Send Discuss-gnuradio mailing list submissions to
>???
address@hidden>
>To
subscribe or unsubscribe via the World Wide Web, visit
>???
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>or, via email, send a
message with subject or body 'help' to
>???
address@hidden>
>You can reach the person managing the list at
>???
address@hidden>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Discuss-gnuradio digest..."
>
>
>Today's Topics:
>
>? 1. Re: WX GUI Widgets Under C++ (Josh Blum)
>? 2. Re g : spectrum sensing code (sumitstop)
>? 3. Re: WX GUI Widgets Under C++ (Daniel Labarowski)
>? 4. When Modifying a Block Do We Have to Recompile??? Everything?
>? ? ? (Frederick Lee)
>? 5. Re: When
Modifying a Block Do We Have to??? Recompile
>? ? ? Everything?
(Tom Rondeau)
>? 6. Re: WX GUI Widgets Under C++ (Josh Blum)
>? 7. Re: SBX Board re-synchonization feature. (Josh Blum)
>? 8. Re: gri_control_loop::set_frequency() Possible??? Error?
>? ? ? (Tom Rondeau)
>? 9.? Question about Spectrum Sense codes (cdong8812)
>? 10. Re: Question about digital_ofdm_mapper_bcv class and d_msg
>? ? ? variable (Tom Rondeau)
>? 11. Re: Audio sink does not throttle sample flow (Tom Rondeau)
>? 12. Re: When Modifying a Block Do We Have to??? Recompile
>? ? ? Everything? (Frederick Lee)
>? 13.? UHD I/O Pins (sibar002)
>? 14. Re: When Modifying a Block Do We Have to??? Recompile
>? ? ? Everything? (Frederick Lee)
>? 15. Re: UHD I/O Pins (Josh Blum)
>? 16. Re: Re g : spectrum sensing code (sreeraj r)
>? 17. simple parallel output shift register (abdullah unutmaz)
>? 18. Re: Question about Spectrum Sense
codes (sumitstop)
>? 19. Re: Setting the XCVR2450 Bandwidth (Michael Hill)
>? 20. Re: Question about digital_ofdm_mapper_bcv class and d_msg
>? ? ? variable (Lampros Katsikas)
>? 21. Re: Re? g : spectrum sensing code (sumitstop)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 21 Aug 2012 09:05:01 -0700
>From: Josh Blum <
address@hidden>
>To:
address@hidden>Subject: Re: [Discuss-gnuradio] WX GUI Widgets Under C++
>Message-ID: <
address@hidden>
>Content-Type: text/plain; charset=ISO-8859-1
>
>
>
>On 08/21/2012
08:46 AM, Daniel Labarowski wrote:
>> I was wondering if there was any way to use WX GUI Widgets, such as the
>> scope and fft plot, in a C++ flowgraph? Are any examples or other
>> resources available? I have been designing these flowgraphs based on the
>> dial tone example. Thanks ahead of time!
>>
>
>The existing WX widgets and windows in gnuradio are exclusively python.
>You would have to involve python in your application to use them.
>
>Now, the QTGui widgets, those are written and can be used in C++
>
>-josh
>
>
>
>------------------------------
>
>Message: 2
>Date: Tue, 21 Aug 2012 09:22:49 -0700 (PDT)
>From: sumitstop <
address@hidden>
>To:
address@hidden>Subject: [Discuss-gnuradio] Re g : spectrum sensing code
>Message-ID: <
address@hidden>
>Content-Type: text/plain; charset=us-ascii
>
>
>Hi Community,
>
>Question - 1
>
>I was working with the UHD version of spectrum sensing code.
>
>I have USRP2 with me. I learnt that USRP2 can achieve 50MHz of RF bandwidth
>with 8 bit samples and 25MHz of RF bandwidth with 16 bit samples.
>
>I wanted to know how does this information translates while passing min_freq
>ans max_freq parameters to the spectrum sensing code. Does it mean (max_freq
>- min_freq) =
25MHz.
>
>Please correct me if I am wrong :teeth:
>
>Question
- 2
>
>Why the minimum center frequency is set as follows :
>
>self.min_center_freq = self.min_freq + self.freq_step/2
>
>Why it simply doesn't take the minimum frequency as we provided. Setting the
>max_center_freq I understood somehow.
>
>
>Question - 3
>
>In non UHD version of spectrum sensing code the adc_rate was fixed fro
>USRP-1 i.e. 64M and that was used to calculate usrp_rate while in UHD
>version of the same code usrp_rate is calculated by the sampling rate we
>give.
>
>I was wondering how does the code manages to work with devices of different
>sampling rates i.e. USRP-1 with 64M USRP2 with 100M
>
>Context : I am trying to scan WLAN channels 1, 6, 11 continuously. So I have
>to keep working with a total bandwidth of 76 MHz
>
>-----
>Sumit Kr.
>Research Assistant
>Communication Research
center
>IIIT Hyderabad
>India
>--
>View this message in context:
http://old.nabble.com/Reg-%3A-spectrum-sensing-code-tp34330101p34330101.html>Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
>
>
>------------------------------
>
>Message: 3
>Date: Tue, 21 Aug 2012 13:23:08 -0400
>From: Daniel Labarowski <
address@hidden>
>To:
address@hidden>Subject: Re: [Discuss-gnuradio] WX GUI Widgets Under C++
>Message-ID: <
address@hidden>
>Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
>Josh,
>Thanks for the reply. The QT Gui Time Sink sounds like it might be
>similar to the scope and the Sink sounds like it might be an fft, but I
>can't seem to get them to run in GRC. I am receiving the error below. It
>looks like these blocks make a call to top layout which doesn't exist? I
>built gnuradio using the build-gnuradio script on the 25th of last month.
>
>-Dan
>
>*Time Sink*
>> Traceback (most recent call last):
>>? File "top_block.py", line 59, in <module>
>>? ? tb = top_block()
>>? File "top_block.py", line 41, in __init__
>>? ?
self.top_layout.addWidget(self._qtgui_time_sink_x_0_win)
>>? File "top_block.py", line 94, in
__getattr__
>>? ? return getattr(self._tb, name)
>> AttributeError: 'gr_top_block_sptr' object has no attribute 'top_layout'
>
>*Sink*
>> Traceback (most recent call last):
>>? File "top_block.py", line 67, in <module>
>>? ? tb = top_block()
>>? File "top_block.py", line 46, in __init__
>>? ? self.top_layout.addWidget(self._qtgui_sink_x_0_win)
>>? File "top_block.py", line 94, in __getattr__
>> AttributeError: 'gr_top_block_sptr' object has no attribute 'top_layout'
>>? ? return getattr(self._tb, name)
>
>
>On 08/21/2012 12:05 PM, Josh Blum wrote:
>> The existing WX widgets and windows in gnuradio are exclusively python.
>> You would have to involve python in your application to use them.
>>
>> Now, the QTGui widgets, those are written and can be used
in C++
>>
>> -josh
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120821/c2f11368/attachment.html>
>
>------------------------------
>
>Message: 4
>Date: Tue, 21 Aug 2012 11:27:39 -0700
>From: Frederick Lee <
address@hidden>
>To:
address@hidden>Subject: [Discuss-gnuradio] When Modifying a Block Do We Have to
>??? Recompile???
Everything?
>Message-ID:
>??? <CAOEHxm0uX1oLfH0zaeL_trCa4DML-J0rtp=
address@hidden>
>Content-Type: text/plain; charset="iso-8859-1"
>
>HI,
>
>I wanted to modify a block and use it. Will I have to recompile everything
>or can I just use it without compiling?
>I'm still new to Linux, so if I need to compile can someone provide a link
>to some instructions to do so?
>
>Thanks,
>
>Frederick
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120821/bdef083a/attachment.html>
>
>------------------------------
>
>Message: 5
>Date: Tue, 21 Aug 2012 17:48:51
-0400
>From: Tom Rondeau <
address@hidden>
>To: Frederick Lee <
address@hidden>
>Cc:
address@hidden>Subject: Re: [Discuss-gnuradio] When Modifying a Block Do We Have to
>??? Recompile Everything?
>Message-ID:
>??? <CA+SzT6gADvJJFbXKyT+ZG7XQrYx3RvQbqun0=R75FR3poX+
address@hidden>
>Content-Type: text/plain; charset=ISO-8859-1
>
>On Tue, Aug 21, 2012 at 2:27 PM, Frederick Lee <
address@hidden> wrote:
>> HI,
>>
>> I
wanted to modify a block and use it. Will I have to recompile everything
>> or can I just use it without compiling?
>> I'm still new to Linux, so if I need to compile can someone provide a link
>> to some instructions to do so?
>>
>> Thanks,
>>
>> Frederick
>
>Frederick,
>
>You will have to recompile and reinstall, but not everything. If you
>are modifying a single block, you can just rebuild from that
>components directory. You want to do the entire component to make sure
>SWIG is initiated again to rebuild the Python interface. But this is
>much quicker than rebuilding from the top source directory that would
>walk through all directories (it won't rebuild them, but the walking
>takes time).
>
>So if you are changing a block in gr-digital, you can just:
>
>cd gr-digital
>make
>make test (or
ctest)
>sudo make install
>
>Tom
>
>
>
>------------------------------
>
>Message: 6
>Date: Tue, 21 Aug 2012 14:51:30 -0700
>From: Josh Blum <
address@hidden>
>To:
address@hidden>Subject: Re: [Discuss-gnuradio] WX GUI Widgets Under C++
>Message-ID: <
address@hidden>
>Content-Type: text/plain; charset=ISO-8859-1
>
>
>
>On 08/21/2012 10:23 AM, Daniel Labarowski wrote:
>> Josh,
>> Thanks for the reply. The QT Gui Time Sink sounds like it might be
>>
similar to the scope and the Sink sounds like it might be an fft, but I
>> can't seem
to get them to run in GRC. I am receiving the error below. It
>> looks like these blocks make a call to top layout which doesn't exist? I
>> built gnuradio using the build-gnuradio script on the 25th of last month.
>>
>
>Try changing the options block to qt gui. -josh
>
>> -Dan
>>
>> *Time Sink*
>>> Traceback (most recent call last):
>>>? File "top_block.py", line 59, in <module>
>>>? ? tb = top_block()
>>>? File "top_block.py", line 41, in __init__
>>>? ? self.top_layout.addWidget(self._qtgui_time_sink_x_0_win)
>>>? File "top_block.py", line 94, in __getattr__
>>>? ? return getattr(self._tb, name)
>>> AttributeError: 'gr_top_block_sptr' object has no attribute 'top_layout'
>>
>> *Sink*
>>> Traceback (most recent
call last):
>>>? File "top_block.py", line 67, in <module>
>>>? ? tb = top_block()
>>>? File "top_block.py", line 46, in __init__
>>>? ? self.top_layout.addWidget(self._qtgui_sink_x_0_win)
>>>? File "top_block.py", line 94, in __getattr__
>>> AttributeError: 'gr_top_block_sptr' object has no attribute 'top_layout'
>>>? ? return getattr(self._tb, name)
>>
>>
>> On 08/21/2012 12:05 PM, Josh Blum wrote:
>>> The existing WX widgets and windows in gnuradio are exclusively python.
>>> You would have to involve python in your application to use them.
>>>
>>> Now, the QTGui widgets, those are written and can be used in C++
>>>
>>> -josh
>>>
>>
>>
>>
>>
_______________________________________________
>> Discuss-gnuradio mailing list
>>
address@hidden>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>
>
>
>
>------------------------------
>
>Message: 7
>Date: Tue, 21 Aug 2012 14:51:46 -0700
>From: Josh Blum <
address@hidden>
>To:
address@hidden>Subject: Re: [Discuss-gnuradio] SBX Board re-synchonization feature.
>Message-ID: <
address@hidden>
>Content-Type: text/plain; charset=ISO-8859-1
>
>
>
>On 08/21/2012 07:30 AM, guelord ingala wrote:
>> Hi,
>> I'm designing a beamforming network. I want to know if it is now
>> possible to align LOs from multiple SBX and usrp boards. It was said
>> from Ettus Research website that the re-synchronization feature? in UHD
>> using SBX boards will be released in 2012. Could you please confirm if
>> it is implementable.
>> Regards.
>> Dominique.
>>
>
>
http://files.ettus.com/uhd_docs/manual/html/sync.html#align-los-in-the-front-end-sbx-wbx-n-series>
>The set/clear_command_time are exposed for the UHD source and
sink
>blocks. You can do this in gnradio with c++ or python.
>
>-josh
>
>
>
>------------------------------
>
>Message: 8
>Date: Tue, 21 Aug 2012 17:52:02 -0400
>From: Tom Rondeau <
address@hidden>
>To: Frederick Lee <
address@hidden>
>Cc:
address@hidden>Subject: Re: [Discuss-gnuradio] gri_control_loop::set_frequency()
>??? Possible??? Error?
>Message-ID:
>??? <CA+SzT6g55SjALAe=KWei_eiBmyDS6QQSuVBEmjJU3ZLEqE0+
address@hidden>
>Content-Type: text/plain; charset=ISO-8859-1
>
>On Thu,
Aug 16, 2012 at 7:11 PM, Frederick Lee <
address@hidden> wrote:
>> Hi,
>>
>> I was looking at the gri_control_loop.cc file and notices the
>> set_frequency() function seemed a little odd. Here's what it looked like.
>>
>> void
>> gri_control_loop::set_frequency(float freq)
>> {
>>? if(freq > d_max_freq)
>>? ? d_freq = d_min_freq;
>>? else if(freq < d_min_freq)
>>? ? d_freq = d_max_freq;
>>? else
>>? ? d_freq = freq;
>> }
>>
>> This doesn't seem logical to me. Shouldn't the it be "d_freq = d_max_freq"
>> in the if statement and "d_freq = d_min_freq" in the else if statement?
>> The frequency_limit() function has it
the way I
stated
>>
>> void
>> gri_control_loop::frequency_limit()
>> {
>>? if (d_freq > d_max_freq)
>>? ? d_freq = d_max_freq;
>>? else if (d_freq < d_min_freq)
>>? ? d_freq = d_min_freq;
>> }
>>
>> Regards,
>>
>> Frederick
>
>
>Frederick,
>
>Yes, that it s a bit odd. It's due to the historical nature of that
>loop. We wanted the frequency to wrap around in some of the early
>loops as opposed to just railing against the edges. I think the idea
>is to let it keep searching in the bandwidth for a lock.
>
>Now, that might not be the right answer. I'm not entirely sure what
>is, though. If you just rail it against the max or min frequency,
>you're just sitting there doing nothing. Is that better or worse than
>forcing it around to the other
side? Frankly, if the frequency of the
>signal that you are trying to track is outside of the loop, you're
>kind of hosed anyways. Would holding it stable at the max/min be more
>appropriate?
>
>Tom
>
>
>
>------------------------------
>
>Message: 9
>Date: Tue, 21 Aug 2012 14:56:14 -0700 (PDT)
>From: cdong8812 <
address@hidden>
>To:
address@hidden>Subject: [Discuss-gnuradio]? Question about Spectrum Sense codes
>Message-ID: <
address@hidden>
>Content-Type:
text/plain; charset=us-ascii
>
>
>Hi,
>I'm currently working on a
project about spectrum sensing and I went over
>the USRP_Spectrun_Sense codes. But I've got a question about the content of
>m.data. Because in the while loop, when you print out m.data, it's FFT_Size
>of samples for each center frequency(Not a single value). If I want to get
>the FFT result for each FFT bin, is it correct to do like this: print
>m.center_freq sum(m.data) in each loop. Any help would be appreciated.
>
>Regards,
>
>
>Chen Dong
>--
>View this message in context:
http://old.nabble.com/Question-about-Spectrum-Sense-codes-tp34331807p34331807.html>Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
>
>
>------------------------------
>
>Message: 10
>Date: Tue, 21 Aug 2012 18:00:34
-0400
>From: Tom Rondeau <
address@hidden>
>To: Lampros Katsikas <
address@hidden>
>Cc:
address@hidden>Subject: Re: [Discuss-gnuradio] Question about digital_ofdm_mapper_bcv
>??? class and d_msg variable
>Message-ID:
>??? <CA+
address@hidden>
>Content-Type: text/plain;
charset=ISO-8859-1
>
>On Wed, Aug 15, 2012 at 4:17 AM, Lampros Katsikas
><
address@hidden> wrote:
>> Hello everyone,
>>
>> In the current implementation of the digital_ofdm_mapper_bcv::work() method
>> only one packet of 528 size(in other words d_msg->length() == 528) is
>> consumed each time in order to create a symbol.
>> I tried to modify the method to consume more of those packets but it still
>> not works.
>> So the question is if there is a way to change the packet size of the msg
>> (d_msg->length()) from 528 to another integer.I could not find where this
>> value is given yet.
>>
>> Thans in advance,
>> Lampros.
>
>You can change the lengths of most parts of
the symbol and packet. If
>you run the benchmark_tx.py script with '-h', you'll see the list of
>options. The '-s' allows you to specify the length of the
packet
>(default = 400 bytes), the number of subcarriers (--fft-length), the
>number of used subcarriers (--occupied-tones) and the length of the
>cyclic prefix (--cp-length).
>
>You should be able to make the OFDM code work on more than one symbol
>at a time, which should help a bit in the performance. The
>book-keeping starts to get nasty, so to make it easier on us when we
>put this together, we decided to get it right by only using one symbol
>at a time.
>
>Tom
>
>
>
>------------------------------
>
>Message: 11
>Date: Tue, 21 Aug 2012 18:09:23 -0400
>From: Tom Rondeau <
address@hidden>
>To: Felix Wunsch <
address@hidden>
>Cc:
address@hidden>Subject: Re: [Discuss-gnuradio] Audio sink does not throttle sample
>??? flow
>Message-ID:
>??? <CA+
address@hidden>
>Content-Type: text/plain; charset=ISO-8859-1
>
>On Mon, Aug 13, 2012 at 12:25 PM, Felix Wunsch
><
address@hidden> wrote:
>>
>> Am 13.08.2012 13:33, schrieb
Tom Rondeau:
>>>
>>> On Mon, Aug 13, 2012 at 5:05 AM, Felix Wunsch
>>> <
address@hidden> wrote:
>>>>
>>>> Am 12.08.2012 19:19, schrieb Tom Rondeau:
>>>>
>>>>> On Tue, Aug 7, 2012 at 6:22 AM, Felix Wunsch
>>>>> <
address@hidden> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I recently wrote a block for decoding DRM AAC streams. For testing I
>>>>>> put
>>>>>> together a small flow graph consisting of a wav source, encoder
block,
>>>>>> decoder block, (rational) resampler and an audio sink (an image of the
>>>>>> flow
>>>>>> graph is
attached).
>>>>>>
>>>>>> When I now run this flow graph, the audio is correctly decoded, but the
>>>>>> output is not throttled to 44.1 kHz as it should be. It seems to be
>>>>>> running
>>>>>> at full speed. I also connected a resampler and an audio sink directly
>>>>>> to
>>>>>> the wav source and there the output is correct.
>>>>>>
>>>>>> I use default values for the audio sink (alsa, 44.1 kHz), GNU Radio
>>>>>> 3.5.1
>>>>>> and xubuntu 11.10.
>>>>>>
>>>>>> Any hints why this is happening and how to solve this?
>>>>>>
>>>>>> Best regards,
>>>>>> Felix Wunsch
>>>>>
>>>>>
Felix,
>>>>>
>>>>> I know that the audio sink will throttle the flow graph. What evidence
>>>>> do you have that it's not or that it's running at full speed? Is it
>>>>> the sound coming from the audio? My first guess is that there's a
>>>>> misunderstanding somewhere of the actual sample rate. You're
>>>>> resampling by almost 2x, which means you expect the signal coming from
>>>>> the decoder to be 44.1e3/2. Is that right?
>>>>>
>>>>> Tom
>>>>
>>>>
>>>> Hi Tom,
>>>>
>>>> thanks for your reply.
>>>>
>>>> My first evidence was in fact the sound coming from the audio that is
>>>> running at a very high speed. However, the pitch seems to be normal. The
>>>> flow
graph is set to "run to completion" and processes a 3 min wav-file
>>>> in
>>>> about 15 sec.
>>>>
>>>> The signal coming from the decoder has a sample rate of 24 kHz. I
>>>> verified
>>>> that by writing the decoder output into a file and using aplay for
>>>> playback
>>>> with -r 24000. At this point, the sound is still normal.
>>>>
>>>> The next steps are in detail:
>>>> - Type conversion short->float
>>>> - multiply const (1/32768) for range adjustment
>>>> - rational resampler( interp: 441, decim: 240)
>>>> - audio sink (44.1kHz)
>>>>
>>>> Did I configure the resampler correctly? I left taps blank and fractional
>>>> bandwidth at 0.
>>>>
>>>> I also attached a file
sink to the output of the resampler and tried to
>>>> play
>>>> it with aplay using -r 44100. It shows the same behaviour like the audio
>>>> sink (normal pitch, very fast playback).
>>>>
>>>> Best regards,
>>>> Felix
>>>
>>> Felix,
>>>
>>> That looks like you're doing everything correctly. I wonder if it's an
>>> issue with the sound card, seeing as you're getting the same behavior
>>> with aplay. Can you set the output device? If you can use pulseaudio,
>>> set the device string to 'pulse' and see what that does. Otherwise,
>>> try 'plughw:0,0'. They might handle the sampling rate settings better.
>>>
>>> Tom
>>
>> Hi Tom,
>>
>> I don't think that it's a sound card issue as I successfully used the
>>
audio sink before. Nevertheless, I tried pulse and plughw:0,0 to be
>> sure. Results are exactly the same. I also attached an audio sink
>> directly to my wav file source at the beginning of the flow graph and
>> this one is working properly.
>>
>> While I was trying the different setups, I noticed that the file sizes
>> of my two file sink outputs are not as expected. The decoder output in
>> my special case is 8.7 MB while the resampler output is no more than 1.1
>> MB. I would have expected a size of 8.7 MB * resampling rate, about 15 MB.
>>
>> To me, it looks like I'm losing lots of samples (about 7 out of 8) in
>> the rational resampler block.
>>
>> Felix
>
>
>Sorry, Felix, lost track of things last week. Are you still having
>issues or have you solved it?
>
>Since you're seeing different files
sizes, yes, something is going
>wrong with you're resampling. Can you try to plug in the pfb_arbitrary
>resampler? You can use the one in blks2 (or
>filter.pfb.arb_resampler_xxf if you are working on a branch with
>gr-filter already) with which you can just tell it the resampling rate
>you want (as a float) and it will create a filter for you that passes
>the entire spectrum of the input signal.
>
>Tom
>
>
>
>------------------------------
>
>Message: 12
>Date: Tue, 21 Aug 2012 15:45:08 -0700
>From: Frederick Lee <
address@hidden>
>To: Tom Rondeau <
address@hidden>
>Cc:
address@hidden>Subject: Re: [Discuss-gnuradio] When Modifying a Block Do We Have to
>??? Recompile Everything?
>Message-ID:
>??? <CAOEHxm0+fcAhgfjE+
address@hidden>
>Content-Type: text/plain; charset="iso-8859-1"
>
>On Tue, Aug 21, 2012 at 2:53 PM, Frederick Lee <
address@hidden>wrote:
>
>>
>>> Frederick,
>>>
>>> You will have to recompile and reinstall, but not everything. If you
>>> are modifying a single
block, you can just rebuild from that
>>> components directory. You want to do the entire component to make
sure
>>> SWIG is initiated again to rebuild the Python interface. But this is
>>> much quicker than rebuilding from the top source directory that would
>>> walk through all directories (it won't rebuild them, but the walking
>>> takes time).
>>>
>>> So if you are changing a block in gr-digital, you can just:
>>>
>>> cd gr-digital
>>> make
>>> make test (or ctest)
>>> sudo make install
>>>
>>> Tom
>>>
>>
>> Thanks a lot Tom. It's great to know that I don't have to go through all
>> the directories because I was using the gnuradio_build option on the
>> build-gnuradio script to rebuild and it takes some time to complete. :)
>>
>> Thanks again
>>
>> Frederick
>>
>> Sorry for posting again, but when I
try the above instructions the make
>command fails. The error I get it this:
>
>make: *** No targets specified and no makefile found.? Stop.
>
>Does the build-gnuradio script put makefiles into the directories for you?
>If not, is it possible to get the makefile else where or find a way around
>it?
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120821/cf02382c/attachment.html>
>
>------------------------------
>
>Message: 13
>Date: Tue, 21 Aug 2012 15:45:08 -0700 (PDT)
>From: sibar002 <
address@hidden>
>To:
address@hidden>Subject: [Discuss-gnuradio]? UHD I/O Pins
>Message-ID: <
address@hidden>
>Content-Type: text/plain; charset=us-ascii
>
>
>Hello,
>
>I would like to control the io_rx[15 - 0] pins on the basic_rx
>daugtherboard. I am able to set them as either input or output pins by using
>the set_pin_ctrl() function. I would like to input a signal into one of
>these pins and be able to read the value. I have been reading the different
>daughterboard .cc files in the host directory, but I havent found any code
>that does this. I would
greatly appreciate any help or advice on how to do
>this. Thank you for your time and help.
>
>Sam
>--
>View this message in context:
http://old.nabble.com/UHD-I-O-Pins-tp34332005p34332005.html>Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
>
>
>------------------------------
>
>Message: 14
>Date: Tue, 21 Aug 2012 15:53:20 -0700
>From: Frederick Lee <
address@hidden>
>To: Tom Rondeau <
address@hidden>
>Cc:
address@hidden>Subject: Re: [Discuss-gnuradio] When Modifying a Block Do We Have
to
>??? Recompile Everything?
>Message-ID:
>???
<CAOEHxm2JeCU_yvY6kN4TYCa05mtwfy-kJ3f7cWhpp6a9Xbc2=
address@hidden>
>Content-Type: text/plain; charset="iso-8859-1"
>
>On Tue, Aug 21, 2012 at 3:45 PM, Frederick Lee <
address@hidden>wrote:
>
>>
>>
>> On Tue, Aug 21, 2012 at 2:53 PM, Frederick Lee <
address@hidden>wrote:
>>
>>>
>>>> Frederick,
>>>>
>>>> You will have to recompile and reinstall, but not everything. If you
>>>> are modifying a single block, you can just rebuild from that
>>>>
components directory. You want to do the entire component to make sure
>>>> SWIG
is initiated again to rebuild the Python interface. But this is
>>>> much quicker than rebuilding from the top source directory that would
>>>> walk through all directories (it won't rebuild them, but the walking
>>>> takes time).
>>>>
>>>> So if you are changing a block in gr-digital, you can just:
>>>>
>>>> cd gr-digital
>>>> make
>>>> make test (or ctest)
>>>> sudo make install
>>>>
>>>> Tom
>>>>
>>>
>>> Thanks a lot Tom. It's great to know that I don't have to go through all
>>> the directories because I was using the gnuradio_build option on the
>>> build-gnuradio script to rebuild and it takes some time to complete. :)
>>>
>>> Thanks again
>>>
>>>
Frederick
>>>
>>> Sorry for posting again, but when I try the above instructions the make
>> command fails. The error I get it this:
>>
>> make: *** No targets specified and no makefile found.? Stop.
>>
>> Does the build-gnuradio script put makefiles into the directories for you?
>> If not, is it possible to get the makefile else where or find a way around
>> it?
>>
>> Nevermind, I found the correct directory. I was looking in the
>gnuradio/gr-digital directroy instead of the gnuradio/build/gr-digital
>directory.
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120821/2769047c/attachment.html>
>
>------------------------------
>
>Message: 15
>Date: Tue, 21 Aug 2012 16:09:16 -0700
>From: Josh Blum <
address@hidden>
>To:
address@hidden>Subject: Re: [Discuss-gnuradio] UHD I/O Pins
>Message-ID: <
address@hidden>
>Content-Type: text/plain; charset=ISO-8859-1
>
>
>
>On 08/21/2012 03:45 PM,
sibar002 wrote:
>>
>> Hello,
>>
>> I would like to control the io_rx[15 - 0] pins on the basic_rx
>> daugtherboard. I am able to set them
as either input or output pins by using
>> the set_pin_ctrl() function. I would like to input a signal into one of
>
>You will need to set GPIO input
>
http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1dboard__iface.html#a377aa6291e0a77cbdf74c58762799c73>
>And call read gpio:
>
http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1dboard__iface.html#ad623a6a90d91eb4e0e047b9da56d1a98>
>> these pins and be able to read the value. I have been reading the different
>> daughterboard .cc files in the host directory, but I havent found any
code
>> that does this. I
would greatly appreciate any help or advice on how to do
>> this. Thank you for your time and help.
>>
>> Sam
>>
>
>
>
>------------------------------
>
>Message: 16
>Date: Wed, 22 Aug 2012 15:17:22 +0800 (SGT)
>From: sreeraj r <
address@hidden>
>To: sumitstop <
address@hidden>,
>??? "
address@hidden" <
address@hidden>
>Subject: Re: [Discuss-gnuradio] Re g : spectrum sensing code
>Message-ID:
>??? <
address@hidden>
>Content-Type: text/plain; charset="iso-8859-1"
>
>
>
>>Question - 1
>>
>>I was working with the UHD version of spectrum sensing code.
>>
>>I have USRP2 with me. I learnt that USRP2 can achieve 50MHz of RF bandwidth
>>with 8 bit samples and 25MHz of RF bandwidth with 16 bit samples.
>>
>>I wanted to know how does this information translates while passing min_freq
>>ans max_freq parameters to the spectrum sensing code. Does it mean
(max_freq
>>- min_freq) = 25MHz.
>>
>>Please correct me if I am wrong :teeth:
>
>As far as I understand spectrum sensing code is used for wideband spectrum analysis, that
is
>to scan across wide RF bands which USRP is not able to analyze at a time. So obviously
>max_freq - min_freq > 25 MHz .
>
>e.g Conider you have to analyze the spectrum from 400 MHz to 500 MHz. You can keep
>min_freq = 400 MHz and max_freq = 500MHz. If you have configured USRP sample rate
>to get 25 MHz bandwidth, ideally one round of scan will be complete by 4 tuning steps.
>(practically 6 steps as the code is using 25% overlap to reduce non-linearity in DDC response).
>
>Firas posted a detailed explanation of the code in the mailing list long back. You can find it
>here
http://www.ruby-forum.com/topic/174437.
>
>>Question - 2
>
>>Why the minimum center frequency is set as follows :
>>
>>self.min_center_freq = self.min_freq + self.freq_step/2
>
>>Why it
simply doesn't take the minimum frequency as we provided. Setting the
>>max_center_freq I understood somehow.
>
>e.g. Scan range 10MHz to 40 MHz
>???? USRP1 B/W = 8MHz
>???? First tuning step is with centre freq 14Mhz (10+8/2 ideally) which will cover the bandwidth from 10 to 18 Mhz
>
>>Question - 3
>
>>In non UHD version of spectrum sensing code the adc_rate was fixed fro
>>USRP-1 i.e. 64M and that was used to calculate usrp_rate while in UHD
>>version of the same code usrp_rate is calculated by the sampling rate we
>>give.
>
>>I was wondering how does the code manages to work with devices of different
>>sampling rates i.e. USRP-1 with 64M USRP2 with 100M
>
>sampling rate ----> Bandwidth? ----> feq_step
>
>>Context : I am trying to scan WLAN channels 1, 6, 11 continuously. So I have
>>to keep
working with a total bandwidth of 76 MHz
>
>Check the tuning delay of the device you are using and make sure that you are not losing any data during the sweeping process.I may be wrong somewhere. Please go through Firas's explanation which will make things clear.
>
>regards
>Sreeraj Rajendran
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120822/6ce9a93c/attachment.html>
>
>------------------------------
>
>Message: 17
>Date: Wed, 22 Aug 2012 04:24:08 -0700 (PDT)
>From: abdullah unutmaz <
address@hidden>
>To: discuss-gnuradio
Discussion Group <
address@hidden>
>Subject: [Discuss-gnuradio] simple parallel output shift register
>Message-ID:
>??? <
address@hidden>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Greetings everybody,
>
>I have been trying to design a simple parallel output shift register, use gr.buffer & gr.buffer_reader.
>But I am having the
error:
>
>------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>
>File "dataST.py", line 61, in <module>
>??? tb =
top_block()
>? File "dataST.py", line 40, in __init__
>??? self.my_buffer=gr.buffer(11,gr.sizeof_char*1,self.my_h)
>? File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core_runtime.py", line 312, in buffer
>??? return _gnuradio_core_runtime.buffer(*args, **kwargs)
>TypeError: in method 'buffer', argument 3 of type 'gr_block_sptr'
>
>
>------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>
>You can see all of my program below:
>
>
>from gnuradio import eng_notation
>from gnuradio import gr
>from gnuradio.eng_option import eng_option
>from gnuradio.gr import firdes
>from grc_gnuradio import wxgui as grc_wxgui
>from optparse import OptionParser
>import wx
>import time
>
>class
top_block(grc_wxgui.top_block_gui):
>
>??? def __init__(self):
>??????????? grc_wxgui.top_block_gui.__init__(self, title="Top Block")
>??????????? _icon_path = "/usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png"
>??????????? self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))
>
>??????????? ##################################################
>??????????? # Variables
>??????????? ##################################################
>??????????? self.samp_rate = samp_rate = 1000000
>
>??????????? ##a################################################
>??????????? # Blocks
>??????????? ##################################################
>??????????? self.my_vec_src = gr.vector_source_b((1, 1, 1, 1,1, 1, 1, 1,1, 1, 1), True, 1)
>??????????? #self.my_vec_snk = gr.vector_sink_b(1)
>??????????? self.my_thro = gr.throttle(gr.sizeof_char*1,
samp_rate)
>??????????? self.my_h = gr.head(gr.sizeof_char*1, 11)
>
>???????????
>??????????? # buffer
>???????????
>??????????? self.my_buffer=gr.buffer(11,gr.sizeof_char*1,self.my_h)
>??????????? self.my_buffer_reader=gr.buffer_reader(self.my_buffer,11)
>???????????
>??????????? ##################################################
>??????????? # Connections
>??????????? ##################################################
>??????????? self.connect((self.my_vec_src, 0), (self.my_thro, 0))
>??????????? self.connect((self.my_thro, 0), (self.my_h, 0))
>??????????? self.connect((self.my_h, 0), (self.my_buffer, 0))
>
>???????????
>
>??? def get_samp_rate(self):
>??? ??? return self.samp_rate
>
>??? def set_samp_rate(self, samp_rate):
>??? ??? self.samp_rate = samp_rate
>
>if __name__ == '__main__':
>??? parser
= OptionParser(option_class=eng_option, usage="%prog: [options]")
>??? (options, args) = parser.parse_args()
>??? tb = top_block()
>??? tb.Run(True)
>??????? while(True):
>??????????? #time.sleep(10)
>??????????? if(tb.my_buffer.done()):
>??????????????? my_data=tb.my_buffer_reader.read_pointer()
>??????????????? print "data: ",my_data
>
>---------------------------------------------------------------------------------------------------------------------------------------------------
>
>Is there anyway to use gr_buffer & gr_buffer_reader properly to design a simple parallel output shift register?
>I searched not only the other discussions in the forum, but also examples I can find. I also tried to find a
>use of gr_buffer in python files, also in doxygen, nothing... Third argument , "link" , is confusing, I tried to make a connection
>
>between gr_buffer
and gr_throttle instead of gr_head, unfortunately it does not work, too.
>
>What should I do?
>
>
>Thanks in advance,
>Abdullah
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120822/3c680539/attachment.html>
>
>------------------------------
>
>Message: 18
>Date: Wed, 22 Aug 2012 05:21:40 -0700 (PDT)
>From: sumitstop <
address@hidden>
>To:
address@hidden>Subject: Re: [Discuss-gnuradio] Question about
Spectrum Sense codes
>Message-ID: <
address@hidden>
>Content-Type: text/plain; charset=us-ascii
>
>
>Hi Chen,
>I was also doing the same as you asked. Since energy equals the sum of all
>FFT coefficients hence summation of all FFT bins looks reasonable to me.
>:teeth:
>
>
>cdong8812 wrote:
>>
>> Hi,
>> I'm currently working on a project about spectrum sensing and I went over
>> the USRP_Spectrun_Sense codes. But I've got a question about the content
>> of m.data. Because in the while loop, when you print out m.data, it's
>> FFT_Size of samples for each center frequency(Not a single value). If I
>> want to get the FFT result for each FFT bin, is it correct to do like
>>
this: print m.center_freq
sum(m.data) in each loop. Any help would be
>> appreciated.
>>
>> Regards,
>>
>>
>> Chen Dong
>>
>
>
>-----
>Sumit Kr.
>Research Assistant
>Communication Research center
>IIIT Hyderabad
>India
>--
>View this message in context:
http://old.nabble.com/Question-about-Spectrum-Sense-codes-tp34331807p34334088.html>Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
>
>
>------------------------------
>
>Message: 19
>Date: Wed, 22 Aug 2012 22:41:00 +0930
>From: Michael Hill <
address@hidden>
>To:
address@hidden>Cc: "
address@hidden" <
address@hidden>
>Subject: Re: [Discuss-gnuradio] Setting the XCVR2450 Bandwidth
>Message-ID:
>??? <
address@hidden>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Thanks Josh,
>
>I've still been toying with this though.. and aren't really having
any
>success.
>E.g. if I pick a Tx bandwidth of 24MHz.. and transmit
>
>and use 8bit I&Q samples transmitted at 50MHz.. then
shouldn't I see some
>signs of the filter?
>What should I be looking for on my spec amp?
>
>I assume by baseband filter, that you mean this is a digital filter that
>applies what I send from the CPU to the USRP..
>
>
>
>Cheers
>
>-Michael
>
>
>On Wed, Jul 11, 2012 at 9:09 AM, Josh Blum <
address@hidden> wrote:
>
>>
>>
>> On 07/08/2012 04:28 AM, Michael Hill wrote:
>> > Hi,
>> >
>> > This is a two part question
>> >
>> > 1) What are the XCVR2450 bandwidth options?
>> > I've looked at the website and discussion list threads on the matter and
>> > seen different answers on what the the bandwidth options are for the
>> > XCVR2450
daughterboard.
>> > The spec sheets
seem to indicate different answers too.. which muddle me
>> > further as I'm unsure if i'm reading them wrong.
>> > Can someone clarify for me what they are? Have there been two revisions
>> of
>> > this hardware of something?
>> >
>>
>> Maybe there is some confusion about specifying the bandwidth of a
>> baseband filter. See this for available rates.
>> 20 MHz means +/- 10 MHz about the center of the baseband signal.
>>
http://files.ettus.com/uhd_docs/manual/html/dboards.html#xcvr-2450>>
>> > 2) How do I se the bandwidth?
>> > I'm trying to use the Bandwidth block on the UHD_Sink.
>> > However I don't get any confirmation messages or indicators if i've set
>> it
>> > wrong..
how can I
check?
>> >
>>
>> RX defaults to 19MHz and TX 24MHz. You really cant see the filter
>> profile unless sample rate > filter BW
>>
>> -josh
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120822/e9ea7a2b/attachment.html>
>
>------------------------------
>
>Message: 20
>Date: Wed, 22 Aug 2012 17:49:33 +0300
>From: Lampros Katsikas <
address@hidden>
>To: Tom Rondeau <
address@hidden>
>Cc:
address@hidden>Subject: Re: [Discuss-gnuradio] Question about digital_ofdm_mapper_bcv
>??? class and d_msg variable
>Message-ID:
>??? <CAHCBcJE=
address@hidden>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Thank you very much for your reply but this is not what i was looking for...
>Its my fault because didn't tell you? what exactly i would like to do!
>
>So, i don't want just to run the benchmark_tx.py to see its behaviour but i
>would like if possible to give
the packet_size as a parameter or even set
>it? statically with another size in order to handle bigger packets at
the
>work method of the digital_ofdm_mapper_bcv class.
>I have already checked the gr_buffer and gr_msg_queue files from
>gnuradio_core folder but i havent seen anything yet.
>
>Thank you in advance,
>Lampros.
>
>2012/8/22 Tom Rondeau <
address@hidden>
>
>> On Wed, Aug 15, 2012 at 4:17 AM, Lampros Katsikas
>> <
address@hidden> wrote:
>> > Hello everyone,
>> >
>> > In the current implementation of the digital_ofdm_mapper_bcv::work()
>> method
>> > only one packet of 528 size(in other words d_msg->length() == 528) is
>> > consumed each time in order to create a
symbol.
>> > I tried to modify the method to consume more
of those packets but it
>> still
>> > not works.
>> > So the question is if there is a way to change the packet size of the msg
>> > (d_msg->length()) from 528 to another integer.I could not find where this
>> > value is given yet.
>> >
>> > Thans in advance,
>> > Lampros.
>>
>> You can change the lengths of most parts of the symbol and packet. If
>> you run the benchmark_tx.py script with '-h', you'll see the list of
>> options. The '-s' allows you to specify the length of the packet
>> (default = 400 bytes), the number of subcarriers (--fft-length), the
>> number of used subcarriers (--occupied-tones) and the length of the
>> cyclic prefix (--cp-length).
>>
>> You should be able to make the OFDM code work on more than one symbol
>> at a time, which should help a bit in
the performance. The
>> book-keeping starts to get nasty, so to make it easier on us when we
>> put this together, we decided to get it right by only using one symbol
>> at a time.
>>
>> Tom
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120822/a52ce572/attachment.html>
>
>------------------------------
>
>Message: 21
>Date: Wed, 22 Aug 2012 08:52:32 -0700 (PDT)
>From: sumitstop <
address@hidden>
>To:
address@hidden>Subject: Re: [Discuss-gnuradio] Re? g : spectrum sensing code
>Message-ID: <
address@hidden>
>Content-Type: text/plain; charset=UTF-8
>
>
>Hi Sreeraj,
>
>Thanks for the reply.
>
>sreeraj r wrote:
>>
>>
>>
>>>Question - 1
>>>
>>>I was working with the UHD version of spectrum sensing code.
>>>
>>>I have USRP2 with me. I learnt that USRP2 can achieve 50MHz of RF
>bandwidth
>>>with 8 bit samples and 25MHz of RF bandwidth with 16 bit samples.
>>>
>>>I wanted to know how does this information
translates while passing
>min_freq
>>>ans max_freq parameters to the spectrum
sensing code. Does it mean
>(max_freq
>>>- min_freq) = 25MHz.
>>>
>>>Please correct me if I am wrong :teeth:
>>
>> As far as I understand spectrum sensing code is used for wideband spectrum
>> analysis, that is
>> to scan across wide RF bands which USRP is not able to analyze at a time.
>> So obviously
>> max_freq - min_freq > 25 MHz .
>>
>> e.g Conider you have to analyze the spectrum from 400 MHz to 500 MHz. You
>> can keep
>> min_freq = 400 MHz and max_freq = 500MHz. If you have configured USRP
>> sample rate
>> to get 25 MHz bandwidth, ideally one round of scan will be complete by 4
>> tuning steps.
>> (practically 6 steps as the code is using 25% overlap to reduce
>> non-linearity in DDC response).
>>
>> Firas posted a detailed explanation of the
code in the mailing list long
>> back. You can find it
>> here
http://www.ruby-forum.com/topic/174437.
>> @@@@@@@@@@@@@@@@@@@@@@@@@@
>> I already went through the code explanation by Firas. So according to your
>> saying :
>> To scan 400MHz to 500MHz I have to take 4 tuning steps. Center frequency
>> of tuning steps shall be 412.5MHz, 437.5MHz, 462.5MHz and 487.5 (for the
>> time being lets ignore the FFT overlaping)
>> And this tuning step size is calculated according to : freq_step = 0.75 *
>> usrp_rate
>> where USRP rate is the sampling rate we give.
>> I have a basic doubt. Since the processing bandwidth at a time is 25MHz,
>> so shall I pass sampling rate = 2*bandwidth i.e. for this case 2*25Mhz =
>> 50MSPS (Pl correct if I am
wrong)
>>>Question - 2
>>
>>>Why the minimum center frequency is set as follows :
>>>
>>>self.min_center_freq = self.min_freq + self.freq_step/2
>>
>>>Why it simply doesn't take the minimum frequency as we provided. Setting
>the
>>>max_center_freq I understood somehow.
>>
>> e.g. Scan range 10MHz to 40 MHz
>> ???? USRP1 B/W = 8MHz
>> ???? First tuning step is with centre freq 14Mhz (10+8/2 ideally) which
>> will cover the bandwidth from 10 to 18 Mhz
>> @@@@@@@@@@@
>> Thanks , I was so intuitive :)
>> @@@@@@@@@@@
>>>Question - 3
>>
>>>In non UHD version of spectrum sensing code the adc_rate was fixed fro
>>>USRP-1 i.e. 64M and that was used to calculate usrp_rate while in UHD
>>>version of the same code usrp_rate is calculated
by the sampling rate we
>>>give.
>>
>>>I was wondering how does the code manages to work with devices of
>different
>>>sampling rates i.e. USRP-1 with 64M USRP2 with 100M
>>
>> sampling rate ----> Bandwidth? ----> feq_step
>>
>>>Context : I am trying to scan WLAN channels 1, 6, 11 continuously. So I
>have
>>>to keep working with a total bandwidth of 76 MHz
>>
>> Check the tuning delay of the device you are using and make sure that you
>> are not losing any data during the sweeping process.I may be wrong
>> somewhere. Please go through Firas's explanation which will make things
>> clear.
>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>> Any standard process you know to check the tuning delay.
>>
>>
>> regards
>> Sreeraj
Rajendran
>> _______________________________________________
>> Discuss-gnuradio mailing list
>>
address@hidden>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>
>>
>
>
>-----
>Sumit Kr.
>Research Assistant
>Communication Research center
>IIIT Hyderabad
>India
>--
>View this message in context:
http://old.nabble.com/Reg-%3A-spectrum-sensing-code-tp34330101p34335158.html>Sent from the GnuRadio mailing list archive at
Nabble.com.
>
>
>
>
>------------------------------
>
>_______________________________________________
>Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
>End of Discuss-gnuradio Digest, Vol 117, Issue 24
>*************************************************
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130516/18fbe3f8/attachment.html>
------------------------------
Message: 12
Date: Thu, 16 May 2013 15:21:35 +0800 (CST)
From: ?? <
address@hidden>
To: "
address@hidden" <
address@hidden>
Subject: [Discuss-gnuradio] Can I make USRP switch between speaking
and muting?
Message-ID: <
address@hidden>
Content-Type:
text/plain; charset="gbk"
I want to send one ofdm symbol then mute during one symbol, and loop in that way.
I have tried to make the second symbol to be all 0+0j in baseband. But the output remains
an output noise which is not as low as requied. I think the RF always output something even
if the baseband gives him 0+0j.
Can I make the silent symbol as weak as background noise?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130516/6626c4e9/attachment.html>
------------------------------
Message: 13
Date: Thu, 16 May 2013 08:38:29 +0100 (BST)
From: Dominique Guelord Ingala <
address@hidden>
To: GNU Radio blog <
address@hidden>
Subject: [Discuss-gnuradio] Allign LOs for SBX boards
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hi, I need to allign the LOs for SBX boards. I read the application notes on UHD-Synchronization.
http://files.ettus.com/uhd_docs/manual/html/sync.html#align-los-in-the-front-end-sbx-wbx-n-seriesI've been working on this for a while, but
I'm still confused a bit. Please
what is the directory for the UHD source and sink blocks where the timed command must be applied. Which part of the code must be changed in
these files. Also how will I know that the LOs are now alligned.?
I'm using ubuntu 11.10. I found 2 files (gr_uhd_usrp_source.cc and
gr_uhd_usrp_sink.cc) under the directory : gnuradio/gr-uhd/lib.? I'm not sure if these are the right files where the timed command must be applied. I tried some changes in this files, but there is no reaction from the USRP.?
Your answer will be appreciated.
Regards.Dominique.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130516/2be166cf/attachment.html>
------------------------------
Message: 14
Date: Thu, 16 May 2013 02:52:11 -0500
From: Josh Blum <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] Allign LOs for SBX boards
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 05/16/2013 02:38 AM, Dominique Guelord Ingala wrote:
> Hi, I
need to allign the LOs for SBX boards. I read the application
> notes on UHD-Synchronization.
>
>
>
http://files.ettus.com/uhd_docs/manual/html/sync.html#align-los-in-the-front-end-sbx-wbx-n-series>
> I've been working on this for a while, but I'm still confused a bit.
> Please what is the directory for the UHD source and sink blocks where
> the timed command must be applied. Which part of the code must be
> changed in these files. Also how will I know that the LOs are now
> alligned. I'm using ubuntu 11.10. I found 2 files
> (gr_uhd_usrp_source.cc and gr_uhd_usrp_sink.cc) under the directory :
> gnuradio/gr-uhd/lib. I'm not sure if these are the right files where
> the timed command must be applied. I tried some changes
in this
> files, but there is no reaction from the USRP.
>
>
No problems. I think you have the wrong impression. You
dont have to
change any files. The timed commands is actually an API call. This
called is exposed as part of uhd in the multi_usrp.hpp file. And its
also exposed in the gr-uhd gnuradio support wrappers. This means you can
use this API in C++ or python with the UHD gnuradio blocks.
-josh
> Your answer will be appreciated.
>
> Regards.Dominique.
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list
address@hidden >
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
------------------------------
Message: 15
Date: Thu, 16 May 2013 09:13:18 +0100
From: Mark McCarron <
address@hidden>
To: GNURadio Discussion List <
address@hidden>
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Marcus,
I have run some tests and it looks like the WX GUI FFT Sink stops responding with any settings above address@hidden FPS.
I've upgrade my video card drivers and they work fine with everything else. Processor usage is fine, nothing in the event
logs.
Regards,
Mark McCarron
From:
address@hiddenTo:
address@hiddenSubject: RE: [Discuss-gnuradio] WX GUI FFT Sink Performance
Date: Thu, 16 May 2013 06:21:34 +0100
Marcus,
Sorry for the late reply on this, I've been upgrading my hardware and I'm just catching up. Here is my issue, in Spectrum lab if I provide a FFT Input length of 65536 on a 192Ksps stream, I get the following characteristics:
Effect of FFT settings with fs= 192.000 kHz:
Width of one FFT-bin: 2.92969 Hz
Equiv. noise bandwidth: 4.39453 Hz
Max freq range: 0.00000 Hz .. 96.0000 kHz
FFT window time: 0.341 s
Overlap from scroll interval: 98.4
%
It runs quite fast. If I provide the same FFT size to WX GUI FFT sink, it basically hangs. Do you know why?
Regards,
Mark
McCarron
Date: Sat, 11 May 2013 15:59:18 -0400
From:
address@hiddenTo:
address@hidden;
address@hiddenSubject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
I figured that one out, but why is the performance
so poor?
In other applications, I can push over half a million samples
without causing issues.
Regards,
Mark McCarron
Your OpenGL implementation may suck.
What sample rate are you using?
If it's quite a low rate, then with a large number of bins, there
may be no way to achieve the given frame rate, given the sample
rate, and FFT size.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org -------------- next part
--------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130516/b82af18e/attachment.html>
------------------------------
Message: 16
Date: Thu, 16 May 2013 10:20:20 +0200
From: "Martin Braun (CEL)" <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] Regarding on the new OFDM
implementation.
Message-ID: <
address@hidden>
Content-Type: text/plain;
charset="utf-8"
Hi Alex,
On Wed, May 15, 2013 at 12:13:16PM -0500, Alex Zhang wrote:
> It is excited to see the new OFDM implementation has been merged and test in
> the GNURadio master branch. Several Questions:
>
> 1. What are the main changes from the old design?
The biggest differences are the increased modularity and
configurability.
Before, you couldn't really change the flow graphs much. These new OFDM
blocks can be configured in many ways, and if one individual element (it
might be the synchronization, or the equalizer, or whatever) needs to be
changed, it's as easy as exchanging blocks. You can also test and
re-arrange the flow graphs in GRC as a result of this.
The new blocks operate on a frame-by-frame basis. For this, we used the
new tagged_stream_blocks (in fact, these were triggered by the OFDM
code).
> 2. Seems it support NC-OFDM as the user can arrange
the carriers? And how is
> the gain of dB between the occupied carriers and vacant carriers?
You can arrange the carriers however you want (this also makes your
second question irrelevant), which is one of the new features. Right
now, you can't change them adaptively, though.
> 3. How about the data rate which is the supported by the new design??
We're lacking proper benchmarks. As usual, there wouldn't be a
definitive answer to this question as it depends on too many things.
What's still lacking are support for frame-by-frame FEC and better
equalizers. Also, there's only one detection and synchronisation
algorithm implemented (Schmidl & Cox). However, the infrastructure
allows easy adding of such blocks.
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/20130516/b17154a1/attachment.pgp>
------------------------------
Message: 17
Date: Thu, 16 May 2013 13:30:43 +0200
From: Nemanja Savic <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] new block style instructions doubt
Message-ID:
<CAFD_UOcp5WbVHxGp7Sm22Gg=
address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi all guys,
I have just been reading instructions for makin new fashion signal
processing block, and I have a certain doubt:
In the following link:
http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuideyou can see for example this in public header file:
namespace gr {
namespace foo
{
class FOO_API bar : virtual public gr_sync_block
and in this page:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7it is written:
class MODNAME_API classname : public gr_sync_block
becomes
class MODNAME_API classname : public gr::sync_block
Does this mean that header file in the first link should contain:
namespace gr {
namespace foo {
class FOO_API bar : virtual public sync_block
If I am right, than maybe the tutorial page should be changed.
Best
Nemanja
--
Nemanja Savi?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130516/0c3ae175/attachment.html>
------------------------------
Message: 18
Date: Thu, 16 May 2013 06:05:48 -0700 (PDT)
From: RAM CHARAN M C <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] Requesting for suggestion to transmit
Signal in 2 x 2 MIMO network
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Hi Everyone
I am trying to 2 x 2 MIMO using
USRPN210.. Until now I
have successfully constructed a receiver using 2 USRPs having a daughter
board RFX2400 using the freely available file multi_sampler.cpp .. I have
been able to recieve the signals synchronously with zero phase offset on
both USRPS which are interconnected through the MIMO cable successfully.
Now At the transmitter end I have 2 USRPs interconnected through MIMO
cable having the daughter board XCVR2450 and the USRP connectedd to the host
PC contains the GPSDO required to provide the PPS and REF signal for MIMO
synchronization... I have been trying to modify the tx_sample_to_file to
enable MIMO transmitter but I haven't solution as yet
I am looking forward for your support in providing valuable suggestion
towards the issue....
Thanking You
--
View this message in context:
http://gnuradio.4.n7.nabble.com/Requesting-for-suggestion-to-transmit-Signal-in-2-x-2-MIMO-network-tp41369.htmlSent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 19
Date: Thu, 16 May 2013 15:08:39 +0200
From: "Martin Braun (CEL)" <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] Dev Call May 16 / Google Hangout
Message-ID: <
address@hidden>
Content-Type: text/plain;
charset="utf-8"
Quick reminder... if you want to join the dev call, make sure you have
the plugin installed, your mic works (and doesn't echo), and you're in
IRC by 1700 UTC to make sure you don't miss anything.
MB
On Mon, May 13, 2013 at 12:57:19PM +0200, Martin Braun (CEL) wrote:
> This Thursday, May 16, we will do our monthly developers call.
>
> As before, at's at 10 AM Pacific, 19:00 CEST, 1700 UTC.
>
> IMPORTANT: We will be using a Google+ hangout via our G+ community,
> which you can find at:
>
https://plus.google.com/communities/105194615257651755927>
> To participate, you must install the plugin beforehand. You can find it
> at:
>
https://tools.google.com/dlpage/hangoutplugin>
> Make sure you've checked your audio is working and the plugin works
> *before* the dev call.
>
> Also, we've identified some trouble with the hangout notification.
> Usually, to join the hangout, you go to the G+ GNU Radio page (see
> above), and you'll see a 'Join Hangout' button at the right.
> Last time, this didn't work for everyone. If you can't join, tell us in
> IRC and we'll send you an invite directly.
> In case this was unclear: We will continue to use IRC as part of the
> note-taking.
>
> All off this G+ stuff is still in testing phase, so bear with us.
>
> 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
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio--
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/20130516/a1528157/attachment.pgp>
------------------------------
Message: 20
Date: Thu, 16 May 2013 15:14:44 +0200
From: "Martin Braun (CEL)" <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] new block style instructions doubt
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="utf-8"
Nemanja,
first note that we're in the middle of moving to 3.7.
So things will definitely be out of sync.
However, those two docs describe two different things:
On Thu, May 16, 2013 at 01:30:43PM +0200, Nemanja Savic wrote:
> In the following link:
>
http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide>
> [...]
This describes how to code blocks, and is valid for 3.6.
> and in this page:
>
http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7>
>
> [...]
This describes what you
have to do if you have old code, and want it to
be compatible with 3.7.
> If I am right, than maybe the tutorial page should be changed.
There will be changes, yes. But 3.7 is still under heavy development,
and before it is not finalized, no need to update the docs. Only if you
are operating on next, this would affect you--in this case, we assume
you know what you're doing.
Still, thanks for proof-reading the docs. My philosophy here is that
outdated docs are worse than none, but the 3.6 series not yet outdated.
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/20130516/8636baaf/attachment.pgp>
------------------------------
Message: 21
Date: Thu, 16 May 2013 09:49:59 -0400
From: "Marcus D. Leech" <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> Marcus,
>
> Sorry for the late reply on this, I've been upgrading my hardware and
> I'm just catching up. Here is my issue, in Spectrum lab if I provide
> a FFT Input length of 65536 on a 192Ksps stream, I get the following
> characteristics:
>
> Effect of FFT settings with fs= 192.000 kHz:
> Width of one FFT-bin: 2.92969 Hz
> Equiv. noise bandwidth: 4.39453 Hz
> Max freq range: 0.00000 Hz .. 96.0000 kHz
> FFT window time: 0.341 s
> Overlap from scroll interval: 98.4 %
>
> It runs quite fast. If I provide the same FFT size to WX GUI FFT
> sink, it basically hangs. Do you know why?
>
> Regards,
>
> Mark
McCarron
Because apparently SpectrumLab is using an
overlapped FFT
implementation. The one in wXGUI doesn't. Further, the wxGUI
implmentation has far
too much Python involved in processing samples, so trying to process
65536 samples at a time is likely sluggish, to the point that it can't keep
up in real time.
The underlying FFT implementation itself is very fast--Gnu Radio uses FFTW.
I've regularly built FFT filters with 250e3 taps, and they are able to
run in real time with sample rates into the many Msps.
So, if you do the math, a non-overlapped FFT implementation of 65536
bins at 192Ksps means 2.92 FFTs/second. If the display update rate is
more than that, there's no way to actually produce an update rate
faster than 2 per second under those circumstances, with a non-overlapped
FFT.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130516/a669d029/attachment.html>
------------------------------
Message: 22
Date: Thu, 16 May 2013 15:54:33 +0200 (CEST)
From: "
address@hidden" <
address@hidden>
To:
address@hiddenSubject: Re:
[Discuss-gnuradio] NOAA antenna
Message-ID:
<address@hidden>
Content-Type: text/plain;charset="UTF-8"
Thank you guys for yours responses.
@Coppens: you have a nice websites (:
Just one thing: I must found another e-shop, because my favourite(tayda)
doesn't have all component..
@Tast: In your opinion, could your antenna work with ezcap tuner without pre-
amp?
By,
Marco Ribero
------------------------------
Message: 23
Date: Thu, 16 May 2013 10:51:49 -0400
From: "Marcus D. Leech" <
address@hidden>
To: "
address@hidden" <
address@hidden>
Subject: [Discuss-gnuradio] Something for
"next" in the GUI area
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
The ability to set your own axis-labelling function for the FFT display
would be useful for certain types of applications where the frequency is
actually
interpreted as something else--like doppler shift, for example.
I'm thinking that you could pass a function that takes the generated
list of frequencys, and the current center frequency:
axis_label_function (float listoffreqs[], float center_freq)
returns float listoflabels[]
or perhaps
returns string listoflabels[]
This is obviously driven by my radio astronomy stuff, but I imagine that
radar applications and others might want "weird" axis labels on the
FFT
display.
Similarly it
should be easy to change the Axis title to something other
than the default.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org------------------------------
Message: 24
Date: Thu, 16 May 2013 11:31:29 -0400
From: Michael Dickens <
address@hidden>
To: "
address@hidden List" <
address@hidden>
Subject: [Discuss-gnuradio] DSP Book : Free as PDF
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
Not sure if this has been mentioned here before, and it cannot hurt to mention it again. The book "The Scientist and Engineer's Guide to Digital Signal Processing" by "Steven W. Smith, Ph.D." is available online as PDFs for free here <
http://www.dspguide.com/pdfbook.htm >; you have to download individual chapters (
http://www.dspguide.com/CH[0-9]*.PDF). I've looked through some of the content, and it looks both thorough and useful for GNU Radio users; and, it's free! Enjoy. -
MLD
------------------------------
Message: 25
Date: Thu, 16 May 2013 11:35:39 -0400
From: "Marcus D. Leech" <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] DSP Book : Free as PDF
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Not sure if this has been mentioned here before, and it cannot hurt to mention it again. The book "The Scientist and Engineer's Guide to Digital Signal Processing" by "Steven W. Smith, Ph.D." is available online as PDFs for free
here<
http://www.dspguide.com/pdfbook.htm>; you have to download individual chapters (
http://www.dspguide.com/CH[0-9]*.PDF). I've looked through some of the content, and it looks both thorough and useful for GNU Radio users; and, it's free! Enjoy. - MLD
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
Lyons' book is also available as PDFs online. I'm not certain of the
legal status of that,
though.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org------------------------------
Message: 26
Date: Thu, 16 May 2013
16:47:58 +0100
From: Mark McCarron <
address@hidden>
To: "
address@hidden" <
address@hidden>
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Marcus,
Thanks, that would explain the slow updates that I was seeing. Perhaps an overlapped FFT would be useful for
interactive scenarios. Has one been implemented?
This, however, does not explain why my windows are not
responding. After about 8 seconds, the window turns to grey and the GUI of the FFT becomes frozen.
Regards,
Mark McCarron
Date: Thu, 16 May 2013 09:49:59 -0400
From:
address@hiddenTo:
address@hiddenSubject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
Marcus,
Sorry for the late reply on this, I've been upgrading my
hardware and I'm just catching up. Here is my issue, in
Spectrum lab if I provide a FFT Input length
of 65536 on a
192Ksps stream,
I get the following characteristics:
Effect of FFT settings with fs= 192.000 kHz:
Width of one FFT-bin: 2.92969 Hz
Equiv. noise bandwidth: 4.39453 Hz
Max freq range: 0.00000 Hz .. 96.0000 kHz
FFT window time: 0.341 s
Overlap from scroll interval: 98.4 %
It runs quite fast. If I provide the same FFT size to WX GUI
FFT sink, it basically hangs. Do you know why?
Regards,
Mark McCarron
Because
apparently SpectrumLab is using an overlapped FFT
implementation. The one in wXGUI doesn't. Further, the wxGUI
implmentation has far
too much Python involved in processing samples, so trying to
process 65536 samples at a time is likely sluggish, to the point
that it can't keep
up in real time.
The underlying FFT implementation itself is very fast--Gnu Radio
uses FFTW.
I've regularly built FFT filters with 250e3 taps, and they are able
to run in real time with sample rates into the many Msps.
So, if you do the math, a non-overlapped FFT implementation of 65536
bins at 192Ksps means 2.92 FFTs/second. If the display update rate
is
more than that, there's no way to actually produce an update rate
faster than 2 per second under those circumstances, with a
non-overlapped
FFT.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org _______________________________________________
Discuss-gnuradio mailing list
address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130516/d882e87c/attachment.html>
------------------------------
Message: 27
Date: Thu, 16 May 2013 09:58:00 -0600
From: "Evan Merewether" <
address@hidden>
To: <
address@hidden>
Subject: Re: [Discuss-gnuradio] DSP Book : Free as PDF
Message-ID: <
address@hidden>
Content-Type:
text/plain; charset="us-ascii"
What is the link to Lyon's book?
Evan Merewether - 575-640-5582
-----Original Message-----
From: discuss-gnuradio-bounces+evan=
address@hidden[mailto:discuss-gnuradio-bounces+evan=
address@hidden] On Behalf Of
Marcus D. Leech
Sent: Thursday, May 16, 2013 9:36 AM
To:
address@hiddenSubject: Re: [Discuss-gnuradio] DSP Book : Free as PDF
> Not sure if this has been mentioned here before, and it cannot hurt to
mention it again. The book "The Scientist and Engineer's Guide to Digital
Signal Processing" by
"Steven W. Smith, Ph.D." is available online as PDFs
for free here<
http://www.dspguide.com/pdfbook.htm>; you have to download
individual chapters (
http://www.dspguide.com/CH[0-9]*.PDF). I've looked
through some of the content, and it looks both thorough and useful for GNU
Radio users; and, it's free! Enjoy. - MLD
> _______________________________________________
> Discuss-gnuradio mailing list
>
address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
Lyons' book is also available as
PDFs online. I'm not certain of the
legal status of that, though.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio
Astronomy Consortium
http://www.sbrac.org_______________________________________________
Discuss-gnuradio mailing list
address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3336 / Virus Database: 3162/6329 - Release Date: 05/16/13
------------------------------
Message: 28
Date: Thu, 16 May 2013 11:59:33 -0400
From: "Marcus D. Leech" <
address@hidden>
To: Mark
McCarron <
address@hidden>,
"
address@hidden" <
address@hidden>
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> Marcus,
>
> Thanks, that would explain the slow updates that I was seeing.
> Perhaps an overlapped FFT would be useful for interactive
scenarios.
> Has one been implemented?
I think they're implementing an overlapped-FFT option for the QtGUI
sinks for "next". Not sure. The thing about
overlapped display FFTs is
that you're
trading (sometimes significant) temporal accuracy of the estimate for
display-update-rate.
Further, given that your display is only probably 1280 pixels wide, I
fail to see how you expect to extract any more "useful" information from a
65536-bin FFT that must necessarily *lose* information when it's
mapped to a narrow display. The wxGUI tools don't support scrolled FFT
windows,
so they necessarily drop bins to satisfy the display requirement.
There are three common "strategies" for mapping a many-binned FFT into a
smaller display window:
o drop bins
o select peak
o average bins
All of those options lose information in the display.
Internally, of course, for signal processing and data recording
purposes, you can
have FFTs that are very wide.
The other thing to consider is that ALL the GUI widgets that are "wired
in" to Gnu Radio were designed *primarily* for debugging/instrumentation
purposes--akin to sticking a voltmeter or oscilloscope on your
circuit board. The problem is that they're *just barely* "good
enough" to construct
applications with, and so there's a natural expectation that they
implement all the GUI thingies you might even want to attach to a
signal-processing
stream.
There is *zero* requirement that you use the built-in GUI widgets.
Lots of applications have been built that use the Gnu Radio
signal-processing path,
and completely-different approaches to providing a GUI--GQRX is one
such example, and my own IRA software uses an XFORMS based GUI, with
a Gnu Radio signal flow underneath.
The QtGUI widgets in "next" are, I
understand, substantially enhanced
over the current set in "master", so perhaps we can see some more
elegant applications written with the Gnu Radio built-in GUI bits.
>
> This, however, does not explain why my windows are not responding.
> After about 8 seconds, the window turns to grey and the GUI of the FFT
> becomes frozen.
That's generally because your flow-graph has some structural problem
that is causing the GUI thread to fail to get any cycles.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130516/e05a9b7c/attachment.html>
------------------------------
Message: 29
Date: Thu, 16 May 2013 12:00:33 -0400
From: "Marcus D. Leech" <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] DSP Book : Free as PDF
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> What is the link to Lyon's book?
>
>
Evan Merewether - 575-640-5582
>
I don't have it off the top of my head, but I'm sure Google knows...
--
Marcus Leech
Principal
Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradioEnd of Discuss-gnuradio Digest, Vol 126, Issue 16
*************************************************