|
| From: | Murtaza Ali |
| Subject: | Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 135, Issue 8 |
| Date: | Sat, 8 Feb 2014 13:51:24 +0000 |
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: Fwd: Documentation for out-of-tree module (Douglas Geiger)
2. Re: [VOLK] 16i_max_star_horizontal_16i non-saturating
subtraction (Tom Tsou)
3. OOT module based on file_sink_base generates symbol not found
error (Jose Rodriguez)
4. Re: OOT module based on file_sink_base generates symbol not
found error (Marcus M?ller)
5. Re: set_relative_rate (Miklos Maroti)
6. Re: OOT module based on file_sink_base generates symbol not
found error (Johannes Demel)
7. Byte Input into Custom Modulator (Jonathan Fox)
8. Re: Byte Input into Custom Modulator (Martin Braun)
9. WX GUI FFT sink on Raspberry Pi (Jim Larsen)
10. Re: Byte Input into Custom Modulator (Jonathan Fox)
11. How to set the bandwidth in WX GUI FFT Sink
(Pablo Fern?ndez Alonso)
12. Re: [VOLK] 16i_max_star_horizontal_16i non-saturating
subtraction (Tom Rondeau)
13. Re: set_relative_rate (Tom Rondeau)
14. Re: WX GUI FFT sink on Raspberry Pi (Tom Rondeau)
15. Re: How to set the bandwidth in WX GUI FFT Sink (Tom Rondeau)
16. Some fairy C++ error in gr-filter (Gisle Vanem)
17. Re: Some fairy C++ error in gr-filter (Tom Rondeau)
18. Two_work_functions (Siva Krishna)
19. Re: set_relative_rate (Miklos Maroti)
20. Re: Possible bug with PATH/gr-channels/lib/cfo_model_impl.h
(Tom Rondeau)
21. Re: Possible bug with PATH/gr-channels/lib/cfo_model_impl.h
(Aditya Dhananjay)
22. Re: Two_work_functions (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Thu, 6 Feb 2014 12:06:14 -0500
From: Douglas Geiger <address@hidden>
To: Martin Braun <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Fwd: Documentation for out-of-tree
module
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Thu, Feb 6, 2014 at 10:31 AM, Martin Braun <address@hidden>wrote:
> On 06.02.2014 03:04, Tom Rondeau wrote:
>
>> Just want to confirm that in the current way gr_modtool generates a new
>>> OOT
>>> module,
>>> no matter what content we put on the "docs" directory, this will not
>>> result
>>> in an invocation of doxygen, and thus it will not generate ANY kind of
>>> manual
>>> (not necessarily from header files, but even , say, a intro page for the
>>> module).
>>>
>>> Can you confirm that.
>>>
>>> thanks again
>>> Achilleas
>>>
>>
>> Achilleas,
>>
>> Correct. There is no doxygen build support in OOT modules built from
>> gr_modtool. We plan to fix this, though.
>>
>
> See http://gnuradio.org/redmine/issues/646.
>
> MB
>
>
I believe that particular issue is due to the CMakeLists.txt essentially
being lifted from the main GNURadio docs CMakeLists.txt (minus the
Sphinx-related bits), and toplevel GNURadio allows ENABLE_DOXYGEN to be
set, and OOT modules do not. So there is a conditional check on
ENABLE_DOXYGEN that will never be true, and so the <gr-oot>/docs/doxygen
directory never gets included in the build. I've attached a patch to issue
646 that just disables this check, but I don't know what the effect will be
on systems that don't actually have doxygen installed: i.e. if the
find_packages(doxygen) in docs/CMakeLists.txt fails.
Doug
--
Doug Geiger
address@hidden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140206/322496b0/attachment.html>
------------------------------
Message: 2
Date: Thu, 6 Feb 2014 12:31:53 -0500
From: Tom Tsou <address@hidden>
To: Douglas Geiger <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] [VOLK] 16i_max_star_horizontal_16i
non-saturating subtraction
Message-ID:
<CAATyM+bykFEATjBAic42BgtD+4nO0VbBwqEHmHqSiZNjGvyP=address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Feb 6, 2014 at 11:58 AM, Douglas Geiger
<address@hidden> wrote:
> I'll suggest that the generic kernel should be trusted to do the correct
> thing, or at least have the correct set of intentions, and that if you want
> to change the behavior of the generic kernel, that you are introducing a
> change that will break applications depending on this behavior.
>
> I believe the use of casting the subtraction before the comparison (where:
> ((int16_t) (src0[i] - src0[i + 1]) > 0) ? src0[i] : src0[i+1]; is the full
> comparison) was intentional to ensure overflow subtraction vs. saturation
> subtraction.
Assuming this kernel is used for some type of trellis decoding, the
overflow makes sense as it avoids the need for normalization of
accumulated metrics. It does, however, require that the spread of
input values be bounded for it to work. Otherwise, you have
comparisons between overflow values and non-overflow values, which
makes the comparison ambiguous and the output not-sane.
-TT
------------------------------
Message: 3
Date: Thu, 6 Feb 2014 14:48:16 -0500
From: Jose Rodriguez <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: [Discuss-gnuradio] OOT module based on file_sink_base
generates symbol not found error
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Guys,
This may be a beginner question, but here it goes. I have built several OOT
modules for my own blocks using gr_modtool as indicated in the Out-of-tree
tutorial w. great success. These blocks were subclasses of gr::blocks.
Now I have created a new block called file_format_sink very similar to
file_sink whose parent class is gr::file_sink_base. It all builds fine but
when I run a flowgraph with file_format_sink using grc, I get the following
error:
Traceback (most recent call last):
File "/home/joser/Desktop/Panorama/grc/top_block.py", line 24, in <module>
import jmr
File "/usr/local/lib/python2.7/dist-packages/jmr/__init__.py", line 45,
in <module>
from jmr_swig import *
File "/usr/local/lib/python2.7/dist-packages/jmr/jmr_swig.py", line 26,
in <module>
_jmr_swig = swig_import_helper()
File "/usr/local/lib/python2.7/dist-packages/jmr/jmr_swig.py", line 22,
in swig_import_helper
_mod = imp.load_module('_jmr_swig', fp, pathname, description)
ImportError: /usr/local/lib/libgnuradio-jmr.so: undefined symbol:
_ZN2gr6blocks14file_sink_baseD2Ev
>>> Done
The missing symbol above, ...file_sink_base... is in
/usr/local/libgnuradio-blocks.so (actually in
libgnuradio-blocks-3.7.2.1.so.0.0.0)
And I believe the above error is caused by not finding the right lib but I
have tried many things including the suggestions in the FAQ (involving
ldconfig and /etc/ld.so.conf) and I have searched in google with no luck.
I have looked at swig/jmr_swig.i and the module directory's CMakeList.txt
file and can't determine how Python's lib load path is set.
Does anyone have any suggestions on how to fix this? thanks,
Jose Rodriguez
address@hidden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140206/358c5969/attachment.html>
------------------------------
Message: 4
Date: Thu, 06 Feb 2014 21:16:20 +0100
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] OOT module based on file_sink_base
generates symbol not found error
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Jose,
this is an advanced question :)
Usually this causes an linker error, but can you verify that you
include the blocks in CMakeLists.txt like the following?
set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS)
Greetings,
Marcus
On 06.02.2014 20:48, Jose Rodriguez wrote:
> Guys,
>
> This may be a beginner question, but here it goes. I have built
> several OOT modules for my own blocks using gr_modtool as indicated
> in the Out-of-tree tutorial w. great success. These blocks were
> subclasses of gr::blocks.
>
> Now I have created a new block called file_format_sink very similar
> to file_sink whose parent class is gr::file_sink_base. It all
> builds fine but when I run a flowgraph with file_format_sink using
> grc, I get the following error:
>
> Traceback (most recent call last): File
> "/home/joser/Desktop/Panorama/grc/top_block.py", line 24, in
> <module> import jmr File
> "/usr/local/lib/python2.7/dist-packages/jmr/__init__.py", line 45,
> in <module> from jmr_swig import * File
> "/usr/local/lib/python2.7/dist-packages/jmr/jmr_swig.py", line 26,
> in <module> _jmr_swig = swig_import_helper() File
> "/usr/local/lib/python2.7/dist-packages/jmr/jmr_swig.py", line 22,
> in swig_import_helper _mod = imp.load_module('_jmr_swig', fp,
> pathname, description) ImportError:
> /usr/local/lib/libgnuradio-jmr.so: undefined symbol:
> _ZN2gr6blocks14file_sink_baseD2Ev
>
>>>> Done
>
> The missing symbol above, ...file_sink_base... is in
> /usr/local/libgnuradio-blocks.so (actually in
> libgnuradio-blocks-3.7.2.1.so.0.0.0) And I believe the above error
> is caused by not finding the right lib but I have tried many things
> including the suggestions in the FAQ (involving ldconfig and
> /etc/ld.so.conf) and I have searched in google with no luck.
>
> I have looked at swig/jmr_swig.i and the module directory's
> CMakeList.txt file and can't determine how Python's lib load path
> is set.
>
> Does anyone have any suggestions on how to fix this? thanks,
>
> Jose Rodriguez address@hidden
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJS8+2UAAoJEAFxB7BbsDrLTKEIAJEvU9CvGbZL/Y+X562vT3M6
hBSHEcwP/EB1Xz+0dL4sYI3NnBYKL6HthMGEnXdpWHEF+dblqqhvnbYbBWyobeDh
yDSl3Sf+HuGWuuuPXbwY+5Fviln71bxtf03U7zDROA+KNzWKV21L1ftEDzGR0w2d
Qofgi+ria0D32BWq2u+RIosUOrk/6AiUaffjTJ4LyubiFLWpwDAgA9WxQtf1y4P2
o0nfztUxsDnTnKKoo10tdNyBCRfcfpP0pE1aBWNHEA328UP3Hv73toueyIckgCgz
p3ONKUWWEn8pXyAVChyWcw4/wXfzQZjUJG4SK81Wj37eRMBNcAZJQpQc/rzBN94=
=YvXL
-----END PGP SIGNATURE-----
------------------------------
Message: 5
Date: Thu, 6 Feb 2014 22:14:08 +0100
From: Miklos Maroti <address@hidden>
To: Tom Rondeau <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] set_relative_rate
Message-ID:
<CAEUdg=address@hidden>
Content-Type: text/plain; charset=UTF-8
Hi Tom,
Thanks for the answer! I have considered both approach already. What
you are saying is that set_relative_rate cannot capture this scenario,
so it is impossible to set different relative rates, right?
Where exactly are the relative rates used in gnuradio core? Only for
the buffer size calculations or are they also used during runtime?
By the way, the vector approach does not scale ideally: if I increase
the size of vectors (to 100000 samples) or use set_output_multiple
with that large value then the performance of the block is degraded,
and I do not really understand why. If the block does pure streaming
(e.g. add) and does not require large quantities of data, then
everything works fine. I do not want to use messages, because the data
is processed (filtered, length changed, etc) along with other
transformations. Anyhow, what I am getting at that there is no good
way of processing very large blocks of data.
Miklos
On Thu, Feb 6, 2014 at 11:15 AM, Tom Rondeau <address@hidden> wrote:
> On Wed, Feb 5, 2014 at 7:02 PM, Miklos Maroti <address@hidden> wrote:
>> Hi Guys,
>>
>> Is it possible to write a c++ block that takes 2 input streams,
>> produces 1 output streams, but to generate 1000 outputs it needs 1000
>> inputs of the first kind and 1 input of the second kind? How do I set
>> the set_output_rate? Does it apply to both input streams? How can I
>> ensure that the scheduler does not create too big buffer for the
>> second type of input?
>>
>> Miklos
>
>
> There are a couple of ways to do this. It might be easiest for you to
> use vectors of samples on input port 0. The output could be another
> vector or you could convert it to a stream again here. This is
> assuming that you always want to process 1000 samples at a time for
> every 1 sample on input port 1. You set your IO signature like:
>
> gr::io_signature::make2(2, 2, 1000*sizeof(type0), 1*sizeof(type1))
>
> The output signature is either 1000*sizeof(type0) and you can use a
> gr::sync_block (because 1 output item is 1 input item) or your output
> signature is 1*sizeof(type0) but you'll use a gr::sync_interpolator
> because now you'll be producing 1000 items after taking in a stream of
> 1 item. See vector_to_stream for a model of this second approach.
>
> You might also want to consider the tag stream interface instead of an
> indicator on stream 1. You would then have one input stream but look
> for the tag to process your 1000 output samples. This would be a more
> general approach if you aren't always using 1000 items at a time.
>
> Tom
------------------------------
Message: 6
Date: Fri, 7 Feb 2014 00:43:14 +0100
From: Johannes Demel <address@hidden>
To: <address@hidden>
Subject: Re: [Discuss-gnuradio] OOT module based on file_sink_base
generates symbol not found error
Message-ID: <address@hidden>
Content-Type: text/plain; charset="ISO-8859-1"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Jose,
check correct linking with 'ldd /usr/local/libgnuradio-jmr.so'.
'libnguradio-blocks.so' should appear in the output with the correct path.
happy hacking
Johannes
On 06.02.2014 20:48, Jose Rodriguez wrote:
>
> Guys,
>
> This may be a beginner question, but here it goes. I have built
> several OOT modules for my own blocks using gr_modtool as indicated
> in the Out-of-tree tutorial w. great success. These blocks were
> subclasses of gr::blocks.
>
> Now I have created a new block called file_format_sink very similar
> to file_sink whose parent class is gr::file_sink_base. It all
> builds fine but when I run a flowgraph with file_format_sink using
> grc, I get the following error:
>
> Traceback (most recent call last): File
> "/home/joser/Desktop/Panorama/grc/top_block.py", line 24, in
> <module> import jmr File
> "/usr/local/lib/python2.7/dist-packages/jmr/__init__.py", line 45,
> in <module> from jmr_swig import * File
> "/usr/local/lib/python2.7/dist-packages/jmr/jmr_swig.py", line 26,
> in <module> _jmr_swig = swig_import_helper() File
> "/usr/local/lib/python2.7/dist-packages/jmr/jmr_swig.py", line 22,
> in swig_import_helper _mod = imp.load_module('_jmr_swig', fp,
> pathname, description) ImportError:
> /usr/local/lib/libgnuradio-jmr.so: undefined symbol:
> _ZN2gr6blocks14file_sink_baseD2Ev
>
>>>> Done
>
> The missing symbol above, ...file_sink_base... is in
> /usr/local/libgnuradio-blocks.so (actually in
> libgnuradio-blocks-3.7.2.1.so.0.0.0) And I believe the above error
> is caused by not finding the right lib but I have tried many things
> including the suggestions in the FAQ (involving ldconfig and
> /etc/ld.so.conf) and I have searched in google with no luck.
>
> I have looked at swig/jmr_swig.i and the module directory's
> CMakeList.txt file and can't determine how Python's lib load path
> is set.
>
> Does anyone have any suggestions on how to fix this? thanks,
>
> Jose Rodriguez address@hidden
> <mailto:address@hidden>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJS9B4SAAoJEO7fmkDsqywMoTcP/A8ijsnSBUsP1nKv93jeiFfr
q7kNvgbNiOH6f3Bqd28NTljiKidubt/53tAgc+Wza3tZ1OWKXS/la1R9gApXqRFz
Rfw0NRS7DLt88G4YfGEhCL0BDsilE1j9FnQROFqcGPIz30cQJPS6OVwEkFMDlEy7
VbmcLvhVRADfO4JY6smXxQ/PvMX9EdQf3x/IdPl8vBn47DrO5Sr/oJd0kf70CyVV
p5ZjaWIc2R4WVulMg7x95VOUl/BgDGCEXLR8CLaClcrbo7yOBsGtqCruoa8ZDuJA
ExldRm0Rg0J5DDTWwT1p/fEzjlLfbojrVq/KZ33e9WcPBILFSVLK/8nXOGslT+cD
EYYGGRL2kwpVanr5GhktEvnMN1EQ3OoGp8ahd5+ro0b8PQD1ry2WteDqbaFQ8VT5
jV968jSj3v3ipdk+dmr57+JbKjQPL4uTZAjgdyyWv0lINcR876UQ3Os+MO4yHu86
/I32sKcABgIrNvauG6QRkS9UXVhrCV3VYip//uSYZN7Q3jATEeDdmk4QO2UWKCy1
mfVA9Cwj6lLGuCcVcXC2zPhQNkQ1K6UWeAj1UAg/Er9jf5uHpy0DYRgHVm+IVvQI
ZQflX72NjFGkvLtXvE/23ESGL3LtHAUbQTGLnjRsCY9te+63fVbt7jvdX7Cv6p/h
eEi+UPeAsSHZIeBREL2/
=27j8
-----END PGP SIGNATURE-----
------------------------------
Message: 7
Date: Thu, 6 Feb 2014 19:24:41 -0500
From: Jonathan Fox <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: [Discuss-gnuradio] Byte Input into Custom Modulator
Message-ID:
<CAPZrquZBGNzbxdptkFqR-j3=7WYuPvVnL6S=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Got a question concerning the byte data type in GNU Radio. I am writing my
own PSK modulator and I am having an issue understanding how the byte data
type appears as I am using it for my input.
I know byte is a char data type in C++ however how does it come in? Is it
the binary data stream of a character? Is it exactly how it is typed in,
e.g. 1, 3, 5?
I am asking because the test data I am trying to modulate is a series of
prime numbers in a vector source block. So I am not entirely sure if I have
to do the conversion to binary myself. I have tried to do a file sink to
see how char data appear but the file is just repeating characters that
make no sense.
Thanks,
Jon Fox
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140206/944d3157/attachment.html>
------------------------------
Message: 8
Date: Thu, 06 Feb 2014 16:41:05 -0800
From: Martin Braun <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Byte Input into Custom Modulator
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 06.02.2014 16:24, Jonathan Fox wrote:
> Got a question concerning the byte data type in GNU Radio. I am writing
> my own PSK modulator and I am having an issue understanding how the byte
> data type appears as I am using it for my input.
>
> I know byte is a char data type in C++ however how does it come in? Is
> it the binary data stream of a character? Is it exactly how it is typed
> in, e.g. 1, 3, 5?
>
> I am asking because the test data I am trying to modulate is a series of
> prime numbers in a vector source block. So I am not entirely sure if I
> have to do the conversion to binary myself. I have tried to do a file
> sink to see how char data appear but the file is just repeating
> characters that make no sense.
Jonathan,
byte is just that -- bytes. If you're reading from a file, the bytes of
this file get streamed as-is.
Don't confuse this with characters / strings! If you write '23' into a
file, you'll get two bytes, with the ASCII codes of each character.
Martin
------------------------------
Message: 9
Date: Thu, 6 Feb 2014 17:18:47 -0800 (PST)
From: Jim Larsen <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] WX GUI FFT sink on Raspberry Pi
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
I installed GNU Radio version 3.7.2 on my Raspberry Pi from the Raspbian
Jessie repository. It is working great for modeling a simple SSB receiver. I
want to compare the CPU performance of the QT GUI Frequency Sink and the WX
GUI FFT sink. The QT GUI Frequency display works fine. The WX GUI FFT window
shows the controls but the FFT display is blank. Does anyone know a fix for
this? The same flowgraph works fine with GNU Radio version 3.7.0 on my
MacBook running Ubuntu 13.10.
Regards,
Jim Larsen
--
View this message in context: http://gnuradio.4.n7.nabble.com/WX-GUI-FFT-sink-on-Raspberry-Pi-tp46197.html
Sent from the GnuRadio mailing list archive at Nabble.com.
------------------------------
Message: 10
Date: Thu, 6 Feb 2014 22:14:58 -0500
From: Jonathan Fox <address@hidden>
To: Martin Braun <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Byte Input into Custom Modulator
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Answers my question, thank you for the response.
Jon
On Thu, Feb 6, 2014 at 7:41 PM, Martin Braun <address@hidden> wrote:
> On 06.02.2014 16:24, Jonathan Fox wrote:
>
>> Got a question concerning the byte data type in GNU Radio. I am writing
>> my own PSK modulator and I am having an issue understanding how the byte
>> data type appears as I am using it for my input.
>>
>> I know byte is a char data type in C++ however how does it come in? Is
>> it the binary data stream of a character? Is it exactly how it is typed
>> in, e.g. 1, 3, 5?
>>
>> I am asking because the test data I am trying to modulate is a series of
>> prime numbers in a vector source block. So I am not entirely sure if I
>> have to do the conversion to binary myself. I have tried to do a file
>> sink to see how char data appear but the file is just repeating
>> characters that make no sense.
>>
>
> Jonathan,
>
> byte is just that -- bytes. If you're reading from a file, the bytes of
> this file get streamed as-is.
>
> Don't confuse this with characters / strings! If you write '23' into a
> file, you'll get two bytes, with the ASCII codes of each character.
>
> Martin
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140206/ca085ff3/attachment.html>
------------------------------
Message: 11
Date: Fri, 7 Feb 2014 10:53:54 +0100
From: Pablo Fern?ndez Alonso <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] How to set the bandwidth in WX GUI FFT
Sink
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I have a USRP B100 from Ettus and I am receiving FM Radio. I plotted the RF
Spectrum and the baseband spectrum in a notebook, but I don't know how to
change the frequency axis or zoom in the graph. I want to know if it
possible to change the frequency in the same graph as well.
I tried to do it but I can't. I am a newbie so I really appreciate your
help.
Thanks in advance,
Pablo Fernandez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140207/a5331f12/attachment.html>
------------------------------
Message: 12
Date: Fri, 7 Feb 2014 10:00:20 +0000
From: Tom Rondeau <address@hidden>
To: Tom Tsou <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] [VOLK] 16i_max_star_horizontal_16i
non-saturating subtraction
Message-ID:
<CA+SzT6hNYZP0Ep==address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Feb 6, 2014 at 5:31 PM, Tom Tsou <address@hidden> wrote:
> On Thu, Feb 6, 2014 at 11:58 AM, Douglas Geiger
> <address@hidden> wrote:
>> I'll suggest that the generic kernel should be trusted to do the correct
>> thing, or at least have the correct set of intentions, and that if you want
>> to change the behavior of the generic kernel, that you are introducing a
>> change that will break applications depending on this behavior.
>>
>> I believe the use of casting the subtraction before the comparison (where:
>> ((int16_t) (src0[i] - src0[i + 1]) > 0) ? src0[i] : src0[i+1]; is the full
>> comparison) was intentional to ensure overflow subtraction vs. saturation
>> subtraction.
>
> Assuming this kernel is used for some type of trellis decoding, the
> overflow makes sense as it avoids the need for normalization of
> accumulated metrics. It does, however, require that the spread of
> input values be bounded for it to work. Otherwise, you have
> comparisons between overflow values and non-overflow values, which
> makes the comparison ambiguous and the output not-sane.
>
> -TT
Yeah, Nathan emailed me back off-list and explained that to me. Makes sense now.
Thanks,
Tom
------------------------------
Message: 13
Date: Fri, 7 Feb 2014 10:10:47 +0000
From: Tom Rondeau <address@hidden>
To: Miklos Maroti <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] set_relative_rate
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Feb 6, 2014 at 9:14 PM, Miklos Maroti <address@hidden> wrote:
> Hi Tom,
>
> Thanks for the answer! I have considered both approach already. What
> you are saying is that set_relative_rate cannot capture this scenario,
> so it is impossible to set different relative rates, right?
Right; relative_rate as a value is defined as a single value for the
entire block. you can consume and produce at different rates for each
input/output stream.
> Where exactly are the relative rates used in gnuradio core? Only for
> the buffer size calculations or are they also used during runtime?
Yes, mostly the initial buffer size calculation. It's also used to
update the item offset value of a tag through a rate-changing block.
> By the way, the vector approach does not scale ideally: if I increase
> the size of vectors (to 100000 samples) or use set_output_multiple
> with that large value then the performance of the block is degraded,
> and I do not really understand why. If the block does pure streaming
> (e.g. add) and does not require large quantities of data, then
> everything works fine. I do not want to use messages, because the data
> is processed (filtered, length changed, etc) along with other
> transformations. Anyhow, what I am getting at that there is no good
> way of processing very large blocks of data.
Use gr-perf-monitorx (or in GRC just look for Performance Monitor) if
you have ControlPort enabled and building properly [1][2]. You'll
likely see the buffer in front of your block backing up while the
output buffer is fairly empty as the scheduler has to dump lots of
data into it before anything else can go, so you'll be starving the
follow-on blocks.
Another model is to try and handle the state internally. Just allow
data to flow in from each data stream and keep internal buffers. This
might allow you to work with the scheduler better.
I'm interested to see if you can get an approach that works well with
your problem. So far, what you're trying to do seems somewhat of a
non-standard use-case for GNU Radio, but I can see more people trying
to do this kind of processing in the future. Would be good to know
both the limits and why.
[1] http://gnuradio.org/doc/doxygen/page_ctrlport.html
[2] http://gnuradio.org/redmine/projects/gnuradio/wiki/PerformanceCounters
Tom
> Miklos
>
> On Thu, Feb 6, 2014 at 11:15 AM, Tom Rondeau <address@hidden> wrote:
>> On Wed, Feb 5, 2014 at 7:02 PM, Miklos Maroti <address@hidden> wrote:
>>> Hi Guys,
>>>
>>> Is it possible to write a c++ block that takes 2 input streams,
>>> produces 1 output streams, but to generate 1000 outputs it needs 1000
>>> inputs of the first kind and 1 input of the second kind? How do I set
>>> the set_output_rate? Does it apply to both input streams? How can I
>>> ensure that the scheduler does not create too big buffer for the
>>> second type of input?
>>>
>>> Miklos
>>
>>
>> There are a couple of ways to do this. It might be easiest for you to
>> use vectors of samples on input port 0. The output could be another
>> vector or you could convert it to a stream again here. This is
>> assuming that you always want to process 1000 samples at a time for
>> every 1 sample on input port 1. You set your IO signature like:
>>
>> gr::io_signature::make2(2, 2, 1000*sizeof(type0), 1*sizeof(type1))
>>
>> The output signature is either 1000*sizeof(type0) and you can use a
>> gr::sync_block (because 1 output item is 1 input item) or your output
>> signature is 1*sizeof(type0) but you'll use a gr::sync_interpolator
>> because now you'll be producing 1000 items after taking in a stream of
>> 1 item. See vector_to_stream for a model of this second approach.
>>
>> You might also want to consider the tag stream interface instead of an
>> indicator on stream 1. You would then have one input stream but look
>> for the tag to process your 1000 output samples. This would be a more
>> general approach if you aren't always using 1000 items at a time.
>>
>> Tom
------------------------------
Message: 14
Date: Fri, 7 Feb 2014 10:12:04 +0000
From: Tom Rondeau <address@hidden>
To: Jim Larsen <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] WX GUI FFT sink on Raspberry Pi
Message-ID:
<CA+SzT6hQO31sJNfG4vxGkm98mTvuZCjL=Cq=address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Feb 7, 2014 at 1:18 AM, Jim Larsen <address@hidden> wrote:
> I installed GNU Radio version 3.7.2 on my Raspberry Pi from the Raspbian
> Jessie repository. It is working great for modeling a simple SSB receiver. I
> want to compare the CPU performance of the QT GUI Frequency Sink and the WX
> GUI FFT sink. The QT GUI Frequency display works fine. The WX GUI FFT window
> shows the controls but the FFT display is blank. Does anyone know a fix for
> this? The same flowgraph works fine with GNU Radio version 3.7.0 on my
> MacBook running Ubuntu 13.10.
>
> Regards,
>
> Jim Larsen
The RaspberryPi is a pretty light-weight processor. WxGUI does a lot
of processing in Python, and it could just be that the processor
stalls with the amount of work it's trying to handle.
Tom
------------------------------
Message: 15
Date: Fri, 7 Feb 2014 10:22:25 +0000
From: Tom Rondeau <address@hidden>
To: Pablo Fern?ndez Alonso <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] How to set the bandwidth in WX GUI FFT
Sink
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Feb 7, 2014 at 9:53 AM, Pablo Fern?ndez Alonso
<address@hidden> wrote:
> Hello,
>
> I have a USRP B100 from Ettus and I am receiving FM Radio. I plotted the RF
> Spectrum and the baseband spectrum in a notebook, but I don't know how to
> change the frequency axis or zoom in the graph. I want to know if it
> possible to change the frequency in the same graph as well.
>
> I tried to do it but I can't. I am a newbie so I really appreciate your
> help.
>
> Thanks in advance,
>
> Pablo Fernandez
The bandwidth is directly related to the sample rate of the gui block.
But understand that the GUI doesn't actually /do/ anything about the
sampling rate of the signal. It doesn't change it or really get
influenced by it. All it does is set the x-axis label.
And to zoom, you can adjust the x and y scales using the Axis Options
buttons on the left-hand side toolbar.
Tom
------------------------------
Message: 16
Date: Fri, 7 Feb 2014 11:50:12 +0100
From: "Gisle Vanem" <address@hidden>
To: "GnuRadio" <address@hidden>
Subject: [Discuss-gnuradio] Some fairy C++ error in gr-filter
Message-ID: <address@hidden>
Content-Type: text/plain; format=flowed; charset="utf-8";
reply-type=original
Hi list. My 1st post here.
I have a big problem with CMake and some of the generated
files under gr-filter/lib. E.g. here is a snippet from it:
#include "fir_filter_ccc.h"
#include <gnuradio/io_signature.h>
#include <volk/volk.h>
namespace gr {
namespace filter {
fir_filter_ccc::sptr
fir_filter_ccc::make(int decimation, const std::vector<gr_complex> &taps)
{
return gnuradio::get_initial_sptr(new fir_filter_ccc
(decimation, taps)); /// <<< line 40
}
At line 40 my g++ 4.7.2 starts yelling w/o me understanding what it says.
Here is the 1st error (edited):
fir_filter_ccc_impl.cc: In static member function 'static gr::filter::fir_filter_ccc::
sptr gr::filter::fir_filter_ccc::make(int, const std::vector<std::complex<float> >&)':
fir_filter_ccc_impl.cc:40:23: error: cannot allocate an object of abstract type
'gr::filter::fir_filter_ccc'
What's this? Is this because 'FILTER_API' is an dllexport? Or is my
fir_filter_ccc_impl.cc generated incorrectly? What is that file and
fir_filter_ccc.h supposed to look like?
Some info for you: 'g++ -fconserve-space -c -DDEBUG -g -O1 -Wall' ..etc.
Thanks in advance.
--gv
------------------------------
Message: 17
Date: Fri, 7 Feb 2014 10:57:37 +0000
From: Tom Rondeau <address@hidden>
To: Gisle Vanem <address@hidden>
Cc: GnuRadio <address@hidden>
Subject: Re: [Discuss-gnuradio] Some fairy C++ error in gr-filter
Message-ID:
<CA+SzT6iqHoVQKNbYKYJ7gQb4mq2AR=Bi7_y7XV2_fkaj=address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Feb 7, 2014 at 10:50 AM, Gisle Vanem <address@hidden> wrote:
> Hi list. My 1st post here.
> I have a big problem with CMake and some of the generated
> files under gr-filter/lib. E.g. here is a snippet from it:
>
> #include "fir_filter_ccc.h"
> #include <gnuradio/io_signature.h>
> #include <volk/volk.h>
>
> namespace gr {
> namespace filter {
> fir_filter_ccc::sptr
> fir_filter_ccc::make(int decimation, const std::vector<gr_complex> &taps)
> {
> return gnuradio::get_initial_sptr(new fir_filter_ccc
> (decimation, taps)); /// <<< line 40
> }
>
> At line 40 my g++ 4.7.2 starts yelling w/o me understanding what it says.
> Here is the 1st error (edited):
>
> fir_filter_ccc_impl.cc: In static member function 'static
> gr::filter::fir_filter_ccc::
> sptr gr::filter::fir_filter_ccc::make(int, const
> std::vector<std::complex<float> >&)':
> fir_filter_ccc_impl.cc:40:23: error: cannot allocate an object of abstract
> type
> 'gr::filter::fir_filter_ccc'
>
> What's this? Is this because 'FILTER_API' is an dllexport? Or is my
> fir_filter_ccc_impl.cc generated incorrectly? What is that file and
> fir_filter_ccc.h supposed to look like?
>
> Some info for you: 'g++ -fconserve-space -c -DDEBUG -g -O1 -Wall' ..etc.
>
> Thanks in advance.
>
> --gv
OS? GNU Radio version?
Tom
------------------------------
Message: 18
Date: Fri, 7 Feb 2014 16:56:45 +0530
From: Siva Krishna <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Two_work_functions
Message-ID:
<CA+SyCfc93S3hs-SSy1vBXcVM3-jNecQ=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
What is the need for two types of work functions in a block(work and
general_work). Can't we do that behavioral with single work function?. Is
there any particular reason behind that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140207/da5db70c/attachment.html>
------------------------------
Message: 19
Date: Fri, 7 Feb 2014 14:10:19 +0100
From: Miklos Maroti <address@hidden>
To: Tom Rondeau <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] set_relative_rate
Message-ID:
<CAEUdg=address@hidden>
Content-Type: text/plain; charset=UTF-8
Hi Tom,
On Fri, Feb 7, 2014 at 11:10 AM, Tom Rondeau <address@hidden> wrote:
> On Thu, Feb 6, 2014 at 9:14 PM, Miklos Maroti <address@hidden> wrote:
>> Hi Tom,
>>
>> Thanks for the answer! I have considered both approach already. What
>> you are saying is that set_relative_rate cannot capture this scenario,
>> so it is impossible to set different relative rates, right?
>
> Right; relative_rate as a value is defined as a single value for the
> entire block. you can consume and produce at different rates for each
> input/output stream.
>
>> Where exactly are the relative rates used in gnuradio core? Only for
>> the buffer size calculations or are they also used during runtime?
>
> Yes, mostly the initial buffer size calculation. It's also used to
> update the item offset value of a tag through a rate-changing block.
>
>> By the way, the vector approach does not scale ideally: if I increase
>> the size of vectors (to 100000 samples) or use set_output_multiple
>> with that large value then the performance of the block is degraded,
>> and I do not really understand why. If the block does pure streaming
>> (e.g. add) and does not require large quantities of data, then
>> everything works fine. I do not want to use messages, because the data
>> is processed (filtered, length changed, etc) along with other
>> transformations. Anyhow, what I am getting at that there is no good
>> way of processing very large blocks of data.
>
> Use gr-perf-monitorx (or in GRC just look for Performance Monitor) if
> you have ControlPort enabled and building properly [1][2]. You'll
> likely see the buffer in front of your block backing up while the
> output buffer is fairly empty as the scheduler has to dump lots of
> data into it before anything else can go, so you'll be starving the
> follow-on blocks.
Yes, I have used the performance monitor and indeed the data backs up
at that point and starves the follow-on blocks. What I have found is
that increasing the history size (set_history) to huge values does not
impair the performance, but increasing the output size (either with
using huge vectors or using set_output_multiple) degrades the
performance significantly. I am talking of 1000000 samples at a time.
However, I think the starving is happening because the block is unable
to produce the data fast enough: maybe output multiple works like a
filter: it just rounds down the noutput_values to an integer multiple,
but the scheduler will keep calling this block which cannot produce
data because there is not enough space in the followup buffer.
> Another model is to try and handle the state internally. Just allow
> data to flow in from each data stream and keep internal buffers. This
> might allow you to work with the scheduler better.
Yes, I have considered that as well, but then it would have to copy
data twice (from stream to main memory and back). Maybe that is the
easiest way to do it, but most likely would require the use of a
non-fixed rate block. If set_output_multiple would not degrade
performance, then that would be the easiest way to do things.
> I'm interested to see if you can get an approach that works well with
> your problem. So far, what you're trying to do seems somewhat of a
> non-standard use-case for GNU Radio, but I can see more people trying
> to do this kind of processing in the future. Would be good to know
> both the limits and why.
The typical problematic block is the following: take 128 pieces of
5000 long sample blocks and mix them into a stream of 5000 long
128-sized vectors. This is just matrix transposition: read in a large
matrix row by row and output the values column by column.
Miklos
> [1] http://gnuradio.org/doc/doxygen/page_ctrlport.html
> [2] http://gnuradio.org/redmine/projects/gnuradio/wiki/PerformanceCounters
>
>
> Tom
>
>
>> Miklos
>>
>> On Thu, Feb 6, 2014 at 11:15 AM, Tom Rondeau <address@hidden> wrote:
>>> On Wed, Feb 5, 2014 at 7:02 PM, Miklos Maroti <address@hidden> wrote:
>>>> Hi Guys,
>>>>
>>>> Is it possible to write a c++ block that takes 2 input streams,
>>>> produces 1 output streams, but to generate 1000 outputs it needs 1000
>>>> inputs of the first kind and 1 input of the second kind? How do I set
>>>> the set_output_rate? Does it apply to both input streams? How can I
>>>> ensure that the scheduler does not create too big buffer for the
>>>> second type of input?
>>>>
>>>> Miklos
>>>
>>>
>>> There are a couple of ways to do this. It might be easiest for you to
>>> use vectors of samples on input port 0. The output could be another
>>> vector or you could convert it to a stream again here. This is
>>> assuming that you always want to process 1000 samples at a time for
>>> every 1 sample on input port 1. You set your IO signature like:
>>>
>>> gr::io_signature::make2(2, 2, 1000*sizeof(type0), 1*sizeof(type1))
>>>
>>> The output signature is either 1000*sizeof(type0) and you can use a
>>> gr::sync_block (because 1 output item is 1 input item) or your output
>>> signature is 1*sizeof(type0) but you'll use a gr::sync_interpolator
>>> because now you'll be producing 1000 items after taking in a stream of
>>> 1 item. See vector_to_stream for a model of this second approach.
>>>
>>> You might also want to consider the tag stream interface instead of an
>>> indicator on stream 1. You would then have one input stream but look
>>> for the tag to process your 1000 output samples. This would be a more
>>> general approach if you aren't always using 1000 items at a time.
>>>
>>> Tom
------------------------------
Message: 20
Date: Fri, 7 Feb 2014 14:22:18 +0000
From: Tom Rondeau <address@hidden>
To: Aditya Dhananjay <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Possible bug with
PATH/gr-channels/lib/cfo_model_impl.h
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Feb 5, 2014 at 7:40 PM, Aditya Dhananjay <address@hidden> wrote:
> Dear All,
>
> I suspect there is a bug in cfo_model_impl.h, where calling set_std_dev to
> set the std_dev back to 0 causes undesirable effects.
>
> How to reproduce the bug:
>
> a) Standard OFDM TX-RX example in GRC. Connect the TX block to the RX block
> through this channel model block.
>
> b) Use a variable slider to control the std_dev of the CFO model block.
>
> c) Start the flowgraph, with 0 as the initial value of the std_dev. All
> should be fine.
>
> d) Bump up the std_dev and observe high packet errors.
>
> e) Drop the std_dev back to 0. While we expect the packet error rate to drop
> back to 0, but that does not happen.
>
> Reason: The value of d_cfo might be a high non-zero value. Even though we
> drop std_dev back to 0, d_cfo remains high, and continues to create CFO.
>
> How to fix it:
>
> In the function set_std_dev, reset the value of d_cfo to 0.
>
> If someone could verify that this is indeed a bug, that would be very
> helpful. Thank you in advance for your help.
>
> Best regards,
> Aditya
Nope, not a bug. You're reducing the standard deviation, but the
actual CFO value is not this value but is adjusted based on it.
I think more of what you are looking for is a direct way to set the
value of the CFO (or something like a reset() function).
Tom
------------------------------
Message: 21
Date: Fri, 7 Feb 2014 11:08:59 -0500
From: Aditya Dhananjay <address@hidden>
To: Tom Rondeau <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Possible bug with
PATH/gr-channels/lib/cfo_model_impl.h
Message-ID:
<CAEiFAxb+Kswh7Tw4XAsMw2ffDRPGT8TaZonT0+eu2=5o=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
>
> Nope, not a bug. You're reducing the standard deviation, but the
> actual CFO value is not this value but is adjusted based on it.
>
> I think more of what you are looking for is a direct way to set the
> value of the CFO (or something like a reset() function).
>
Hi Tom, thanks for the clarification!
best regards,
aditya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20140207/b29c2964/attachment.html>
------------------------------
Message: 22
Date: Fri, 07 Feb 2014 17:37:17 +0100
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Two_work_functions
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Siva,
yes, referring to the introductory tutorials I can explain:
gr::block, the mother of all blocks that can process samples, has
general_work. That gets called to process samples, but does not make
any guarantees about the ratio of the numbers of input- and output
items, so you need to call consume() yourself to tell GNU Radio how
many input items you consumed to produce your output.
work is the function of a block that has a defined ratio between the
numbers of in- and output items (gr::sync_block and derived types,
which itself is a subclass of gr::block),
which "wraps" the functionality to alleviate the need to call
consume() yourself, since from the number of items a sync block
produced you directly know how many it consumed.
So, no, by choice of design we can't have the same behaviour with a
single method.
Hope that was helpful!
Greetings,
Marcus
On 07.02.2014 12:26, Siva Krishna wrote:
> Hi, What is the need for two types of work functions in a
> block(work and general_work). Can't we do that behavioral with
> single work function?. Is there any particular reason behind that.
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJS9Qu9AAoJEAFxB7BbsDrLMc0H/R0TH2kR0ixa47SUb1zrxlFQ
CwZIQWOVe/idWiN5/LZ/pZyHESKJ1p8DJ749UW2PJsec5s4QuNKV6PQliH7+o7aq
kVgSFzLy3EZIpg3ECAxO1OCgzh2WXlVBVW5lgFSMlaI4CuPpnOtSCof2K6QGoJ2b
56hYc+Jae59b+lyyjURjvCYgqqk0ksqT0f8A6h7kxWNvUQDwGfuTpXLZ4xyIFXyE
xs6KKvy5kFrQUAzIxCwDz2eDjvZknIWLalp6Ga5ulhLEEh7eAw1T4/zccBiU9xZD
UX+4qIPfYPmgwIfA0WqG9KwRLJNRsLI9f5qPZpj+n5bYPmLQnFFy5rD2iXuvi8A=
=yYRp
-----END PGP SIGNATURE-----
------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
End of Discuss-gnuradio Digest, Vol 135, Issue 8
************************************************
| [Prev in Thread] | Current Thread | [Next in Thread] |