Sure, either way will work, but if you don't need any special
behavior, call set_history() and let the default forecast() in
block.cc:
void
block::forecast(int noutput_items, gr_vector_int &ninput_items_required)
{
unsigned ninputs = ninput_items_required.size ();
for(unsigned i = 0;
I got it. Thank you for your response.
Best,
Weihan
On Wed, Jan 17, 2018 at 5:30 PM, Sakthivel Velumani
wrote:
> Hi Weihan,
>
> For any block, the noutput_items is just a scalar - meaning "number of
> items actually written to each output stream" is same for all the output
> ports. The buffer s
Hi Weihan,
For any block, the noutput_items is just a scalar - meaning "number of
items actually written to each output stream" is same for all the output
ports. The buffer size of all output ports are the same.
Best,
Sakthivel
On Wed, Jan 17, 2018 at 4:23 PM, Weihan Chen wrote:
> Hi,
>
> From
Hi Markus,
A better way is to specify the amount of data you need for the processing
in the forecast function. By doing so, the GNU Radio scheduler will
guarantee the sufficient amount of input data and hence you can remove the
return 0 from the work function.
Best,
Sakthivel
On Wed, Jan 17, 201
Hi Brian,
this came up today already, and seems solved by a patch:
http://lists.gnu.org/archive/html/discuss-gnuradio/2018-01/msg00108.htm
l
Maybe this helps,
best regards,
Marcus
On Wed, 2018-01-17 at 19:00 +, Brian Clark wrote:
> Good evening all,
>
> I have recently updated my kali linu
Good evening all,
I have recently updated my kali linux distribution using the below commands.
apt-get update
apt-get upgrade
apt-get dist-upgrade
I have a strange error that has occurred within GNU Radio where an error
message as shown below appears:
self.restoreGeometry(self.settings.value("g
*
* Save The Date *
*
NEWSDR 2018
New England Workshop on Software Defined Radio
Hi,
>From the manual it says this number is "number of items actually written to
each output stream". But I'm a bit confused that if we have a block with
multiple output ports, then what does the return value mean? Please help,
thanks.
Regards,
Weihan
_
Hello,
I have the following problem:
I wrote a block that does some processing and needs to look ahead in the
data for a certain amount.
Therefore the work function of the sync_block will return 0 if the
current amount of data is insufficient.
This works fine if the program is running infinitely
Yes indeed, it was a C++11 issue! Thanks
On 13 January 2018 at 11:16, Sakthivel Velumani wrote:
> I think you are using an older standard of C compiler. The C11 does not
> allow to initialise a vector using {}. But this doesn't matter as it
> compiled successfully. Try initialising the vector wi
Ah, cool!
Interestingly, "my" GNU Radio never uses PyQt5, only PyQt4: It seems
that Maitland's packaging is more advanced than I am :) (it is, I just
checked: Maitland already has qt5-qtgui and qt5-qtgui-grc patches)
Best regards,
Marcus
On Wed, 2018-01-17 at 13:17 +0100, s.achte...@rug.nl wrote
Hello,
problem solved.
Debian testing is switching to PyQt5.
There already is a simple patch for it in debian-bugs.
See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886807
And it works!
Thanks for the help.
Sietse
PS. I am a bit confused by the mailinglist, I see my name (only)
Hej,
Can you try editing your /home/sietse/top_block.py, and running it from
a console (regenerating it from GRC will overwrite your changes):
Add a
import sip
sip.setapi('QString', 1)
sip.setapi('QVariant', 1)
directly *before* "from PyQt4 import Qt".
Does that help?
Best regards,
Marcus
O
Hm, that being said: This might be a PyQT API v2 versus API v1 issue.
Will later have a look at these APIs.
Best regards,
Marcus
On Wed, 2018-01-17 at 12:01 +, Müller, Marcus (CEL) wrote:
> Hello Sietse,
>
> unless you're building GNU Radio from source on the next or a Qt5
> development branc
Hello Sietse,
unless you're building GNU Radio from source on the next or a Qt5
development branch, all this should use PyQt4, as far as I remember.
Best regards,
Marcus
On Wed, 2018-01-17 at 11:21 +0100, s.achte...@rug.nl wrote:
> Hello list (second attempt),
>
> Starting with gnuradio on
Sorry if this post appears twice, but my mail provider had problems so
I'm not sure if this post was really sent.
Hello,
the line
self.restoreGeometry(self.settings.value("geometry").toByteArray()
is correct.
But gnuradio uses QT4, so PyQt4 is required.
Volker
Am 17.01.2018 um 11:21 schr
Hi,
I am doing some proof of concept using gr-ieee 802.11.
The paper by author [1] says that it uses softbits, however in the method
*constellation::decision_maker(const gr_complex *sample)*, I see outputs as
hardbits.
Am I missing something here i.e. any particular commit or branch where the
sof
Thank you for your reply.
What I want to do is write a block that copies a certain number of
samples after a certain tag to the output and drops all other samples.
I'll go through your questions below. But any further ideas on how to
implement this would also be appreciated.
Am 16.01.2018 um 14:3
Hello,
the line
self.restoreGeometry(self.settings.value("geometry").toByteArray()
is correct.
But gnuradio uses QT4, so PyQt4 is required.
Volker
Am 17.01.2018 um 11:21 schrieb s.achte...@rug.nl:
Hello list (second attempt),
Starting with gnuradio on Debian testing/buster and trying a
Hello list (second attempt),
Starting with gnuradio on Debian testing/buster and trying a flowgraph with only
a "wav file source" and an "audio sink".
With option "WX gui" it just works, but with option "QT gui" there is the
following error:
File "/home/sietse/top_block.py", line 55, in __i
20 matches
Mail list logo
