Re: [Discuss-gnuradio] blocks.complex_to_arg() implementation
On 13/08/2014 16:37, Tom Rondeau wrote: The version we have in there is much (MUCH) faster than the libm atan2 function. So yes, we trade off a bit of error for a massive computational gain. The error is very small from what I recall, expect in a few instances (near 0 or near pi/2 or something like that). Having a graph of the error somewhere would be helpful. I think it depends on the point of view, for me it is a bit of computational gain for a massive error :) The fast atan method we use is still faster than what we have in VOLK. I remember testing this out myself, which included putting that code into the constructor. However, take a look at this post: http://www.trondeau.com/blog/2012/2/17/volk-benchmarking.html I don't see anything specific to the atan2() and alignment there. We see an improvement in speed of blocks by doing the alignment. Actually, I think that all blocks should probably have their alignment set whether or not they use VOLK. But that would be a lot of work to do correctly with all of our blocks to make sure it's done right and is actually giving us a benefit. But having test this one in particular, no, I don't see any need to remove this code. I see. Probably a comment in the code mentioning this, to avoid other being puzzled, is in order here :) Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio flow graph for Spectrum sensing
Hi Rodrigo, both is right, due to Parseval's Theorem stating that energy of a signal in time and frequency domain is equivalent. Regarding File is large: of course it is; I don't know what sampling rate you're using, but assume you have 1MS/s of complex float, that will be 2*32bit*10^6/s = 8MB/s of data. Regarding it cannot be opened: Opened by what? Maybe you're not aware of: http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-is-the-file-format-of-a-gr_file_sink-How-can-I-read-files-produced-by-a-file-sink Greetings, Marcus On 13.08.2014 23:29, Rodrigo Rozário wrote: Hi Martin, I am generating by the following flowgraph: RTL2832 source - FFT - File Sink I tried too: RTL2832 - File Sink Is it right? 2014-08-13 9:00 GMT-03:00 Martin Braun martin.br...@ettus.com: How are you generating those files? On 08/12/2014 01:30 AM, Rodrigo Rozário wrote: Hi guys, I'm trying to configure a spectrum analyzer with GNU Radio and I had a many problems. I tried a lot of ways to do it but all of them failed. More specifically, I need to get information about the FFT and store it. I tried the following: - I get data from the block RTL2832 and store it: this is generates a very big file data end a can't open. In a file of a few seconds of storage (50Mb) I can't recognize the power values. - I try to store and after open it on a editor, but not work. I think that there is any problem in the format of the data stored. Can you help? Anyone already can do it? -- /*Rodrigo Rozário */ /CREA-DF - 21339/D-DF - Professional Registration/ /Engenheiro de Redes de Comunicação - //Network Engineering/ /Universidade de Brasília - //University of Brasília/ / / ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ctest freezes in random moments on my OOT
Hello,
I've written a simple block that takes a c34vector message as input and
outputs a message containing average mag^2 of the samples in the vector.
I've added the QA code in Python and it seems to be working except the test
never finishes. I've added a few print statements to see whats up. From
what I can gather:
- The freeze doesn't use up CPU (at least nothing noticeable)
- Random number of messages are processed before the freeze occurs,
sometimes none are sent
Could someone give me a hint on that? I've added the relevant code in the
attachment.
BR,
Michal
/* -*- c++ -*- */
/*
* Copyright 2014 +YOU OR YOUR COMPANY+.
*
* This is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3, or (at your option)
* any later version.
*
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this software; see the file COPYING. If not, write to
* the Free Software Foundation, Inc., 51 Franklin Street,
* Boston, MA 02110-1301, USA.
*/
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include gnuradio/io_signature.h
#include burst_to_power_impl.h
namespace gr {
namespace gsm_measure {
burst_to_power::sptr
burst_to_power::make()
{
return gnuradio::get_initial_sptr
(new burst_to_power_impl());
}
/*
* The private constructor
*/
burst_to_power_impl::burst_to_power_impl()
: gr::block(burst_to_power,
gr::io_signature::make(0,0,0),
gr::io_signature::make(0,0,0))
{
message_port_register_in(pmt::mp(bursts));
message_port_register_out(pmt::mp(power));
set_msg_handler(pmt::mp(bursts), boost::bind(burst_to_power_impl::to_power, this, _1));
}
/*
* Our virtual destructor.
*/
burst_to_power_impl::~burst_to_power_impl()
{
}
void burst_to_power_impl::to_power(pmt::pmt_t pmt_vector){
std::vector gr_complex burst;
double power = 0;
if (pmt::is_c32vector(pmt_vector)){
//std::cout It's a c32vector, computing power std::endl;
burst = pmt::c32vector_elements(pmt_vector);
for (int i = 0; i burst.size(); i++){
power = power + std::norm(burst.at(i));
}
power = power/burst.size();
message_port_pub(pmt::mp(power), pmt::from_double(power));
}
else std::cout Not a c32vector!!! Check your flowgraph std::endl;
}
} /* namespace gsm_measure */
} /* namespace gr */
#!/usr/bin/env python
# -*- coding: utf-8 -*-
#
# Copyright 2014 +YOU OR YOUR COMPANY+.
#
# This is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
#
# This software is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this software; see the file COPYING. If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.
#
from gnuradio import gr, gr_unittest
from gnuradio import blocks
import gsm_measure_swig as gsm_measure
import pmt
import numpy as np
# Simple block to consume messages
class message_consumer(gr.sync_block):
def __init__(self):
gr.sync_block.__init__(
self,
name = message consumer,
in_sig = None,
out_sig = None
)
self.msg_list = []
self.message_port_register_in(pmt.intern('in_port'))
self.set_msg_handler(pmt.intern('in_port'),
self.handle_msg)
def handle_msg(self, msg):
# Create a new PMT from double and put in list
print(Message received)
self.msg_list.append(pmt.from_double(pmt.to_double(msg)))
# Simple block to generate messages
class message_generator(gr.sync_block):
def __init__(self, msg_list, msg_interval):
gr.sync_block.__init__(
self,
name = message generator,
in_sig = [np.float32],
out_sig = None
)
self.msg_list = msg_list
self.msg_interval = msg_interval
self.msg_ctr = 0
self.message_port_register_out(pmt.intern('out_port'))
def work(self, input_items, output_items):
inLen = len(input_items[0])
while self.msg_ctr
Re: [Discuss-gnuradio] fftw3 thread safety ?
Hi, Can someone point me to the way gnuradio solves this thread safety issue (which must be solved since I can use as many FFT display blocks I want) ? See planner::mutex() in gr-fft/lib/fft.cc The semaphore solution is not really satisfactory since I'd like not to ask my block to wait for all other data processing to be completed before I can complete its own task. The execution (fftw_execute and variants) is safe and can be executed by several threads in //, even on the same plan object. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio flow graph for Spectrum sensing
Hi Rodrigo (once again), one of the wise elders reminded me that in the FFT, power is but proportional to the input power in time domain, due to a factor of fft_length occuring when forward-backward transforming. Greetings, Marcus On 14.08.2014 11:29, Marcus Müller wrote: Hi Rodrigo, both is right, due to Parseval's Theorem stating that energy of a signal in time and frequency domain is equivalent. Regarding File is large: of course it is; I don't know what sampling rate you're using, but assume you have 1MS/s of complex float, that will be 2*32bit*10^6/s = 8MB/s of data. Regarding it cannot be opened: Opened by what? Maybe you're not aware of: http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-is-the-file-format-of-a-gr_file_sink-How-can-I-read-files-produced-by-a-file-sink Greetings, Marcus On 13.08.2014 23:29, Rodrigo Rozário wrote: Hi Martin, I am generating by the following flowgraph: RTL2832 source - FFT - File Sink I tried too: RTL2832 - File Sink Is it right? 2014-08-13 9:00 GMT-03:00 Martin Braun martin.br...@ettus.com: How are you generating those files? On 08/12/2014 01:30 AM, Rodrigo Rozário wrote: Hi guys, I'm trying to configure a spectrum analyzer with GNU Radio and I had a many problems. I tried a lot of ways to do it but all of them failed. More specifically, I need to get information about the FFT and store it. I tried the following: - I get data from the block RTL2832 and store it: this is generates a very big file data end a can't open. In a file of a few seconds of storage (50Mb) I can't recognize the power values. - I try to store and after open it on a editor, but not work. I think that there is any problem in the format of the data stored. Can you help? Anyone already can do it? -- /*Rodrigo Rozário */ /CREA-DF - 21339/D-DF - Professional Registration/ /Engenheiro de Redes de Comunicação - //Network Engineering/ /Universidade de Brasília - //University of Brasília/ / / ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] blocks.complex_to_arg() implementation
On Thu, Aug 14, 2014 at 5:15 AM, Daniele Nicolodi dani...@grinta.net wrote: On 13/08/2014 16:37, Tom Rondeau wrote: The version we have in there is much (MUCH) faster than the libm atan2 function. So yes, we trade off a bit of error for a massive computational gain. The error is very small from what I recall, expect in a few instances (near 0 or near pi/2 or something like that). Having a graph of the error somewhere would be helpful. I think it depends on the point of view, for me it is a bit of computational gain for a massive error :) You say massive error, but I've plotted the error between the fast atan and the libm atan function before and have not noticed any error to be massive. On the other hand, the bit of computational gain is, indeed, quite a lot. The fast atan method we use is still faster than what we have in VOLK. I remember testing this out myself, which included putting that code into the constructor. However, take a look at this post: http://www.trondeau.com/blog/2012/2/17/volk-benchmarking.html I don't see anything specific to the atan2() and alignment there. Nothing specific to the atan function. The post shows that changing from not using alignment to using alignment provides a boost in performance even before adding actual calls to VOLK. That's what the difference between the red and blue bars shows. Tom We see an improvement in speed of blocks by doing the alignment. Actually, I think that all blocks should probably have their alignment set whether or not they use VOLK. But that would be a lot of work to do correctly with all of our blocks to make sure it's done right and is actually giving us a benefit. But having test this one in particular, no, I don't see any need to remove this code. I see. Probably a comment in the code mentioning this, to avoid other being puzzled, is in order here :) Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ctest freezes in random moments on my OOT
On Thu, Aug 14, 2014 at 6:38 AM, Michal Jakubiak meho...@gmail.com wrote: Hello, I've written a simple block that takes a c34vector message as input and outputs a message containing average mag^2 of the samples in the vector. I've added the QA code in Python and it seems to be working except the test never finishes. I've added a few print statements to see whats up. From what I can gather: - The freeze doesn't use up CPU (at least nothing noticeable) - Random number of messages are processed before the freeze occurs, sometimes none are sent Could someone give me a hint on that? I've added the relevant code in the attachment. BR, Michal What version of GNU Radio are you using? There is a known problem with message-only apps not properly shutting down. This should be fixed in the latest 3.7.4 release, but I think 3.7.3 is still buggy on this one. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] blocks.complex_to_arg() implementation
On 14/08/2014 15:10, Tom Rondeau wrote: On Thu, Aug 14, 2014 at 5:15 AM, Daniele Nicolodi dani...@grinta.net mailto:dani...@grinta.net wrote: On 13/08/2014 16:37, Tom Rondeau wrote: The version we have in there is much (MUCH) faster than the libm atan2 function. So yes, we trade off a bit of error for a massive computational gain. The error is very small from what I recall, expect in a few instances (near 0 or near pi/2 or something like that). Having a graph of the error somewhere would be helpful. I think it depends on the point of view, for me it is a bit of computational gain for a massive error :) You say massive error, but I've plotted the error between the fast atan and the libm atan function before and have not noticed any error to be massive. On the other hand, the bit of computational gain is, indeed, quite a lot. I was trying to stress that the speed vs correctness tradeoff should be evaluated case by case on the base of the requirements and limitations and that the results of this evaluation may be quite different depending on the situation. Indeed in my current project I'm using both the fast atan and the libm atan to compute different hings in the same flow-graph (for a PLL loop the linear approximation for small angles is perfectly fine, not so much for other measurements). I may have completely wrong expectations, but I'm used to mathematical functions that, if not specified, return results exact within the precision of the number representation used. Any optimization trading precision for speed should be documented. I think we agree on that. The remaining discussion is purely academic :) Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ctest freezes in random moments on my OOT
On Thu, Aug 14, 2014 at 4:15 PM, Tom Rondeau t...@trondeau.com wrote:
On Thu, Aug 14, 2014 at 6:38 AM, Michal Jakubiak meho...@gmail.com
wrote:
Hello,
I've written a simple block that takes a c34vector message as input and
outputs a message containing average mag^2 of the samples in the vector.
I've added the QA code in Python and it seems to be working except the
test never finishes. I've added a few print statements to see whats up.
From what I can gather:
- The freeze doesn't use up CPU (at least nothing noticeable)
- Random number of messages are processed before the freeze occurs,
sometimes none are sent
Could someone give me a hint on that? I've added the relevant code in the
attachment.
BR,
Michal
What version of GNU Radio are you using? There is a known problem with
message-only apps not properly shutting down. This should be fixed in the
latest 3.7.4 release, but I think 3.7.3 is still buggy on this one.
Tom
I was on 3.7.2, I believe. I used the build-gnuradio script to update to
3.7.4. My problem persists. However, odd things happen. I doubt it is
relevant to my actual problem, but here it goes:
5: ==
5: FAIL: test_001_t (__main__.qa_burst_to_power)
5: --
5: Traceback (most recent call last):
5: File
/home/mehow/projects/gr-gsm_measure/python/qa_burst_to_power.py, line
124, in test_001_t
5: msg_pow.message_ports_in(), 0)), 'bursts')
5: AssertionError: 'system' != 'bursts'
5:
5: --
5: Ran 1 test in 0.005s
I don't have a port called 'system'. This happened only once and made me
tweak with the assertion statements. Now, when I check the message ports
against their actual names ('bursts' and 'power'), the assertion is passed,
but when I change the name to check against in the QA code I get (for both
of my ports):
5: AssertionError: 'system' != 'whatever_name_I_put_there'
Other than this oddity, I get exactly the same thing as at the beginning.
Could this happen because I have some leftovers of the previous version of
gnuradio after using the script?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Set QT GUI 'extras' from GRC?
On Thu, Aug 14, 2014 at 11:15 AM, John Murphy jmur...@comsonics.com wrote: Is there a way from GRC to set some of the 'extra' parameters in the QT GUI's? For example, say I want to enable auto-scaling, or set the FFT averaging, or set signal colors or names for the legend. I understand how to do all that after starting the flowgraph, but it takes some time and it only persists for the current run. So for some items I would like to make a set of behaviors more 'default' on my GUI. You'll have to be running 3.7.4. We added that ability recently with the new GRC property tabs. Look for the Config tab to configure the look of the lines. Other things like setting auto-scale and attributes like that are also in there, now. Martin and I did a lot of work on the qtgui blocks just after the 3.7.4 release to add even more features like this, so you might not find everything settable in 3.7.4. That will come in the next release. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] blocks.complex_to_arg() implementation
On Thu, Aug 14, 2014 at 9:25 AM, Daniele Nicolodi dani...@grinta.net wrote: On 14/08/2014 15:10, Tom Rondeau wrote: On Thu, Aug 14, 2014 at 5:15 AM, Daniele Nicolodi dani...@grinta.net mailto:dani...@grinta.net wrote: On 13/08/2014 16:37, Tom Rondeau wrote: The version we have in there is much (MUCH) faster than the libm atan2 function. So yes, we trade off a bit of error for a massive computational gain. The error is very small from what I recall, expect in a few instances (near 0 or near pi/2 or something like that). Having a graph of the error somewhere would be helpful. I think it depends on the point of view, for me it is a bit of computational gain for a massive error :) You say massive error, but I've plotted the error between the fast atan and the libm atan function before and have not noticed any error to be massive. On the other hand, the bit of computational gain is, indeed, quite a lot. I was trying to stress that the speed vs correctness tradeoff should be evaluated case by case on the base of the requirements and limitations and that the results of this evaluation may be quite different depending on the situation. Indeed in my current project I'm using both the fast atan and the libm atan to compute different hings in the same flow-graph (for a PLL loop the linear approximation for small angles is perfectly fine, not so much for other measurements). I may have completely wrong expectations, but I'm used to mathematical functions that, if not specified, return results exact within the precision of the number representation used. Any optimization trading precision for speed should be documented. I think we agree on that. The remaining discussion is purely academic :) Cheers, Daniele I don't think that it's academic at all. We're dealing with processing noisy signals here, often coming at us very quickly. We work in the tradeoff space between speed and performance and try to balance them well. This isn't like Matlab with double-precision math. In this case, the complexity of the atan function is really high. Meanwhile, I just pulled up my old tests, and the maximum error between fast_atan2f and atan2f is 0.00194 radians. I'm curious what application you are using that's requiring that level of precision? And what noiseless environment you are in where you can make that determination? As for the documentation: yes, I'm always in favor of adding information to the documentation to make things more clear. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Set QT GUI 'extras' from GRC?
Well, that is great news, looking forward to it along with a lot of other things I have seen on 3.7.4 descriptions. Fedora 20 repo has 3.7.3, even Ettus has a 3.7.3 from April 29 as their most recent. Only places I find with 3.7.4 rpm's are builds for rawhide or others which are Fedora 22. John Murphy jmur...@comsonics.com On Thu, Aug 14, 2014 at 11:29 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Aug 14, 2014 at 11:15 AM, John Murphy jmur...@comsonics.com wrote: Is there a way from GRC to set some of the 'extra' parameters in the QT GUI's? For example, say I want to enable auto-scaling, or set the FFT averaging, or set signal colors or names for the legend. I understand how to do all that after starting the flowgraph, but it takes some time and it only persists for the current run. So for some items I would like to make a set of behaviors more 'default' on my GUI. You'll have to be running 3.7.4. We added that ability recently with the new GRC property tabs. Look for the Config tab to configure the look of the lines. Other things like setting auto-scale and attributes like that are also in there, now. Martin and I did a lot of work on the qtgui blocks just after the 3.7.4 release to add even more features like this, so you might not find everything settable in 3.7.4. That will come in the next release. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Received Signal Power
Hello, I have transmitted and received signal using USRP board. I can see the received power spectral density by using WX GUI FFT Sink. How can I find the received power of a signal? I mean I don't require power spectral density but I need the received signal power. I highly appreciate your reply. Regards Nashid Anjum ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Received Signal Power
The power of a signal over its bandwidth is computed as: AVG(I*I+Q*Q) Average/Decimate/SQRT to taste. On 2014-08-14 14:44, Md. Anjum wrote: Hello, I have transmitted and received signal using USRP board. I can see the received power spectral density by using WX GUI FFT Sink. How can I find the received power of a signal? I mean I don't require power spectral density but I need the received signal power. I highly appreciate your reply. Regards Nashid Anjum ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1] Links: -- [1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Slow down rate of Python source block
From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom Rondeau Sent: 01 August 2014 14:31 To: David Halls Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Slow down rate of Python source block On Fri, Aug 1, 2014 at 5:24 AM, David Halls david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote: From: trond...@trondeau.commailto:trond...@trondeau.com [trond...@trondeau.commailto:trond...@trondeau.com] on behalf of Tom Rondeau [t...@trondeau.commailto:t...@trondeau.com] Sent: 31 July 2014 19:11 To: David Halls Cc: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Slow down rate of Python source block On Thu, Jul 31, 2014 at 12:21 PM, David Halls david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote: Dear All, I have a Python block that produces packets of size 1536 bytes. Due to various reasons, the latter parts of my flow graph are very slow (this is desired and cannot be changed). After producing 510 packets, I get the following error. handler caught exception: operands could not be broadcast together with shapes (1527) (1536) Traceback (most recent call last): File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py, line 55, in eval try: self._callback() File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py, line 160, in __gr_block_handle ) for i in self.__out_indexes], File /usr/local/lib/python2.7/dist-packages/trl/blsd_enc_b.py, line 198, in work out_cA[0:len(cAm)] = cAm ValueError: operands could not be broadcast together with shapes (1527) (1536) thread[thread-per-block[1]: block blsd_enc_b (2)]: caught unrecognized exception Debugging more carefully, I can see that: len(cAm) = 1536 , len(out_cA) = 32768 Just a quick response without really studying the problem or your code. The dynamic scheduler in GR is getting in your way, and the throttle block is definitely not the right way to help you. You need to either tell the scheduler what you need it to send your block or handle it internally. There are three ways to solve these issues: 1. Use set_output_multiple in the constructor, which will only allow the scheduler to send you chunks of data of some multiple of the number you pass that. I've seen this slow down the scheduler in other situations, but it sounds like you're going slow, anyways, so this shouldn't cause a problem. 2. Make your input signature your packet_length so each item will be a vector of that length. This would not be my preferred way, but we've played that game before. 3. Handle it internally. Buffer up the input until you have enough to produce what you need. You'd need to inherit from gr.basic_block here and do more management of the data and buffers yourself. Tom Tom, Thanks for your reply. Unfortunately as it is a Python block, I cannot use 'set_output_multiple'. For 2. do you mean set the input signature of the blocks fed from the source block. This could be possible but quite a few different blocks (some standard GR blocks) are fed from it. Could you provide some more details, or a link to similar implementation for option 3. - again is this possible from within a Python block? Regards, David David, set_output_multiple is exposed through the Python gateway code, so you should be able to call self.set_output_multiple inside the constructor.. For 2, yes, I mean that you can adjust the io signature of the block, essentially taking in a vector so that 1 item is now a full packet. But yes, this makes it more difficult to integrate with other blocks; one reason I said this isn't a preferred method. And for 3, the only think that I can think of is the qtgui sinks, like the freq sink that passes a chunk of data the length of the FFT size and buffers it internally. The work functions for these types of blocks tend to become more complex, though, and difficult to read. But you can certainly do it inside a Python block; you just may need to do hard copies out of the input buffers to make sure the data is actually moved and stored locally. Tom Hi Tom, I tried self.set_output_multiple and this doesn't work in Python, I believe for the same reasons as The set_min_noutput_items() is not yet a supported python statement [1] as per March 06, 2014. Also, I believe this statement should be placed in the member functions (constructor, work function, callback function etc) of your custom block, don't put it at the wrong place. In alternative, you may want to replace it with set_output_multiple() if this is more appropriate. 1. http://gnuradio.4.n7.nabble.com/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio-td46731.html;
Re: [Discuss-gnuradio] Received Signal Power
Use complex_to_maq_squared, integrate with decimate, then 10*log() + K, and into a time sink or signal probe. K is a calibration factor in dB that you obtain by feeding your hardware with a known power level, typically a signal generator. Lou KD4HSO Md. Anjum wrote Hello, I have transmitted and received signal using USRP board. I can see the received power spectral density by using WX GUI FFT Sink. How can I find the received power of a signal? I mean I don't require power spectral density but I need the received signal power. I highly appreciate your reply. Regards Nashid Anjum ___ Discuss-gnuradio mailing list Discuss-gnuradio@ https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://gnuradio.4.n7.nabble.com/Received-Signal-Power-tp49961p49964.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RDS for AM?
I finished work on a C-QUAM (AM Stereo) transmitter, and now want to add something similar to RDS, but not sure how to go about it. I am aware of AMSS, but I like my wideband audio signal, and think that using the subsonic frequencies could work. Basically, I want to send maybe a call-sign, genre, and maybe song info. For encoding I would porbably use UTF-16. Any ideas? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
