[Discuss-gnuradio] questions about syncing to an input bit stream that has a header
You can tell from my questions below that I am very new at this. If there is some other approach to my OOT that make more sense, please tell me... I am aware of the gr-dsd OOT, but I want to decode/encode using a method that won't violate patents. I'm working on a OOT that will have various blocks to encode/decode using an AMBE3000 device. For decoding, incoming data will have an overall sync of 64+15 bits followed by a 660 bit header and then 20 millisecond voice frames with the encoded data (72 bits) and a "slow data" (24 bits). Starting with the first voice frame, every 21st frame will have a 24 bit frame sync instead of slow data. (It's the DStar protocol, see http://www.qsl.net/kb9mwr/projects/dv/dstar/dstar_dv_frame3_en.pdf , and it uses GMSK to convert between rf and digital.) The AMBE3000 will decode the 9 bytes of voice data in the 12 byte frame into 160 audio samples (short ints at 8000 per sec). The final voice frame should not have any "slow data" but instead have a 48 bit termination pattern). My dstar_encode_sb block seems more straightforward: When the flow is started, just like a delay block, dstar_encode_sb will insert the overall sync and header at the beginning of the transmission, then the voice frames will be generated from an audio source. I'm unsure how to properly terminate the end. Is there another block function that I can override to add a final termination frame to the output stream as the flow is shutting down? My dstar_decode_bs is quite a bit more complicated. I would like my dstar_decode_bs block to print some values from the header and only output audio when it is receiving voice frames. Is that possible? Can work() return zero when my block is not processing voice frames? Is forecast() a hard rule, or is it just a suggestion to the gnuradio scheduler? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] The AttributeError problem now that I have modified a working OOT
I am developing an OOT. I have a preliminary version working, and now I
am working on a new version.
To make the new version, n the build directory, I first did a "sudo make
uninstall".
I changed some code in one of three block (dstar_decode_bs) in my module
as well as added two new classes (.cc and .h file) in lib. I also added
the two new cc files to CMakeList.txt file in lib.
I removed the build folder and did a cmake, make and "sudo make
install". (And "sudo ldconfig" just for good measure.)
Now I am getting the well-referenced "AttributeError" error with a very
simple test flow graph:
Executing: /usr/bin/python -u /home/tom/top_block.py
Using Volk machine: avx2_64_mmx_orc
gr::log :INFO: audio source - Audio sink arch: alsa
Traceback (most recent call last):
File "/home/tom/top_block.py", line 109, in
main()
File "/home/tom/top_block.py", line 97, in main
tb = top_block_cls()
File "/home/tom/top_block.py", line 67, in __init__
self.ambe3000_dstar_decode_bs_0 =
ambe3000.dstar_decode_bs("/dev/ttyUSB0", 230400)
AttributeError: 'module' object has no attribute 'dstar_decode_bs'
>>> Done
---
My block doesn't depend on any other block, so I don't think I have to
change GR_REQUIRED_COMPONENTS in the top level CMakeList.txt file.
You can see the working preliminary version (in the "master" branch) and
the non-working new version (in the "syncing" branch) at
https://github.com/ac2ie/gr-ambe3000. I have been searching for a
solution to the AttributeError message, but haven't found anything useful.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The AttributeError problem now that I have modified a working OOT
On 07/02/2016 06:01 AM, Marcus Müller wrote:
HI Tom,
this usually implies that SWIG, for some reason, can't/doesn't wrap the
class (dstar_decode_bs, in this case).
Now, I've taken the liberty to try and build your OOT myself, and I can,
without problem, create a dstar_decode_bs object from python.
Thanks Marcus, for trying this. I tried what you suggested and there was
no love. I even tried to uninstall, then rm'ed the build folder and
rebuilt, with still no luck. You cloned the "syncing" branch, right? The
"master" branch works fine. I have gone back a couple of times to see if
I could figure out what I broke.
S maybe it's just SWIG messing with us. Can you go back to your
build directory, make uninstall; make clean; make; make install and see
if that fixes it? SWIG sometimes behaves erratically in the presence of
previous build remains.
Best regards,
Marcus
On 02.07.2016 01:42, Tom Early wrote:
I am developing an OOT. I have a preliminary version working, and now
I am working on a new version.
To make the new version, n the build directory, I first did a "sudo
make uninstall".
I changed some code in one of three block (dstar_decode_bs) in my
module as well as added two new classes (.cc and .h file) in lib. I
also added the two new cc files to CMakeList.txt file in lib.
I removed the build folder and did a cmake, make and "sudo make
install". (And "sudo ldconfig" just for good measure.)
Now I am getting the well-referenced "AttributeError" error with a
very simple test flow graph:
Executing: /usr/bin/python -u /home/tom/top_block.py
Using Volk machine: avx2_64_mmx_orc
gr::log :INFO: audio source - Audio sink arch: alsa
Traceback (most recent call last):
File "/home/tom/top_block.py", line 109, in
main()
File "/home/tom/top_block.py", line 97, in main
tb = top_block_cls()
File "/home/tom/top_block.py", line 67, in __init__
self.ambe3000_dstar_decode_bs_0 =
ambe3000.dstar_decode_bs("/dev/ttyUSB0", 230400)
AttributeError: 'module' object has no attribute 'dstar_decode_bs'
Done
---
My block doesn't depend on any other block, so I don't think I have to
change GR_REQUIRED_COMPONENTS in the top level CMakeList.txt file.
You can see the working preliminary version (in the "master" branch)
and the non-working new version (in the "syncing" branch) at
https://github.com/ac2ie/gr-ambe3000. I have been searching for a
solution to the AttributeError message, but haven't found anything
useful.
___
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] The AttributeError problem now that I have modified a working OOT
Thanks Bastian,
I removed try/except int __init__.py and it gave:
ImportError: /usr/lib/libgnuradio-ambe3000.so: undefined symbol:
_ZN12CDStarHeaderD1Ev
I suspect this is telling about the undeclared destructor for
CDStarHeader, but I think I am to inexperienced to understand the _ZN12
prefix and D1Ev suffix!
Marcus,
Thanks! I removed the offending printf() and added an empty destructor
and can build successfully. Now I know that I have (a lot of) debugging
to do!
Do you have any idea why my system did not complain AT ALL when building
the syncing branch? I am using ubuntu 16.04 with the apt-installed grc
(3.7.9). Do I have some config screwed up somewhere?
Thanks again. I very much appreciate this support!
Tom
On 07/04/2016 05:22 AM, Marcus Müller wrote:
Hi!
nope, I've tried the master branch only :/
but: syncing fails to build at all for me:
make
[ 3%] Building CXX object
lib/CMakeFiles/gnuradio-ambe3000.dir/dstar_encode_sb_impl.cc.o
[ 6%] Building CXX object lib/CMakeFiles/gnuradio-ambe3000.dir/DV3000U.cc.o
[ 9%] Building CXX object lib/CMakeFiles/gnuradio-ambe3000.dir/DStarHeader.cc.o
[ 12%] Building CXX object lib/CMakeFiles/gnuradio-ambe3000.dir/DStarDecode.cc.o
[ 15%] Building CXX object
lib/CMakeFiles/gnuradio-ambe3000.dir/dstar_decode_bs_impl.cc.o
/home/marcus/src/gr-ambe3000/lib/dstar_decode_bs_impl.cc: In constructor
‘gr::ambe3000::dstar_decode_bs_impl::dstar_decode_bs_impl(char*, int)’:
/home/marcus/src/gr-ambe3000/lib/dstar_decode_bs_impl.cc:48:71: error: ‘printf’
was not declared in this scope
printf("%s is %s.\n", device, device_is_closed ? "closed" : "opened");
^
lib/CMakeFiles/gnuradio-ambe3000.dir/build.make:158: recipe for target
'lib/CMakeFiles/gnuradio-ambe3000.dir/dstar_decode_bs_impl.cc.o' failed
make[2]: *** [lib/CMakeFiles/gnuradio-ambe3000.dir/dstar_decode_bs_impl.cc.o]
Error 1
CMakeFiles/Makefile2:137: recipe for target
'lib/CMakeFiles/gnuradio-ambe3000.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-ambe3000.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2
After adding the necessary #include I got a linker error:
libgnuradio-ambe3000.so: undefined reference to `CDStarHeader::~CDStarHeader()'
A-ha! your DStarHeader.h declares a destructor, but you never implement
it; so either remove that declaration in the header, or add an actual
implementation!
With those two modifications [1] instantiating ds_decode_bs works on the
syncing branch for me.
Cheers,
Marcus
[1] https://github.com/ac2ie/gr-ambe3000/pull/1
On 03.07.2016 20:44, Bastian Bloessl wrote:
Hi,
On 07/03/2016 07:50 PM, Tom Early wrote:
Thanks Marcus, for trying this. I tried what you suggested and there was
no love. I even tried to uninstall, then rm'ed the build folder and
rebuilt, with still no luck. You cloned the "syncing" branch, right? The
"master" branch works fine. I have gone back a couple of times to see if
I could figure out what I broke.
IIRC, I had a similar problem and removing the try/except here:
https://github.com/ac2ie/gr-ambe3000/blob/master/python/__init__.py#L30
showed the actual error message. Maybe you want to try this.
Best,
Bastian
___
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] The AttributeError problem now that I have modified a working OOT
When Marcus build my OOT, he encountered both a "was not declared in this scope" comp error and an undefined reference linking error. (See his previous post in this discussion.) I did not encounter any errors or warnings building the exact same source. I'm trying to understand why. On 07/05/2016 01:06 AM, Sylvain Munaut wrote: Hi, Do you have any idea why my system did not complain AT ALL when building the syncing branch? I am using ubuntu 16.04 with the apt-installed grc (3.7.9). Do I have some config screwed up somewhere? No, that's expected. GR modules are libraries and as so the linking process will accept undefined symbols, and just expect them to be present when the .so is effectively loaded at runtime. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The AttributeError problem now that I have modified a working OOT
Sylvain and Marcus, Thanks. Good to know. I guess it might be wise for me to do all but the simplest grc developments in a statically linked environment as much as possible, and then port to my OOT. I got my decoder working now. On 07/06/2016 05:23 AM, Marcus Müller wrote: Yeah, I didn't trace back where that happened. Might be that my specific version of SWIG tries to link against that destructor's symbol. I really can't tell. Still, technically, Sylvain is right, such errors can hit you late when runtime dynamically loads/links. Best regards, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] (no module specified) in the block tree
I did a clean install of ubuntu 16.10 and then installed gnuradio 3.7.10 from apt. I also installed my own OOT module. My OOT blocks end up in a "(no module specified)" branch. The tool-tip on this branch says the modules should have a module name in their GRC Block Descriptions or their Block Tree. I have been unsuccessful in figuring out how fix this. Can someone point me in the correct direction? Thanks! PS. The blocks in gr-osmosdr also end up in this "(no module specified)" branch. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] (no module specified) in the block tree
Thanks Johnathan. I had the tags, but didn't have the square brackets! (And now I see the hint about the brackets in the first part of the tool-tip.) I guess it would be helpful if the on-line documentation were updated (at least in the OOT tutorial) with: [HOWTO] and maybe a short sentence that states the importance of the square brackets. On 11/09/2016 06:58 PM, Johnathan Corgan wrote: On Wed, Nov 9, 2016 at 3:39 PM, Tom Early <mailto:ac...@nycap.rr.com>> wrote: The tool-tip on this branch says the modules should have a module name in their GRC Block Descriptions or their Block Tree. I have been unsuccessful in figuring out how fix this. Can someone point me in the correct direction? Just add [NAME] to the XML description for each block, right after the name and key entries (change NAME to your module name as you want it listed.) This was something that was added in 3.7.10 to help clean up the category tree and to allow OOT modules to have all their blocks grouped together separately from the pre-supplied GNU Radio modules. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] the dreaded AttributeError: 'module' object has no attribute...
Sorry, me again.
Recently did a fresh install of ubuntu 16.10 and did a apt install of
gnuradio.
A few days ago you helped me get my OOT blocks properly installed on my
own tree by added square brackets around my value.
However there are now problems when I run:
File "/home/tom/grc-flow/top_block.py", line 147, in __init__
self.ambe3000_dstar_encode_sb_0 =
ambe3000.dstar_encode_sb('/dev/ttyUSB0', 230400)
AttributeError: 'module' object has no attribute 'dstar_encode_sb'
I'm having trouble finding useful info googling on this error message. I
have spend several days following various threads, including rebuilding
another, identical OOT from scratch with gr_modtool.
My OOT is at https://github.com/ac2ie/gr-ambe3000 . (This OOT worked
fine with ubuntu 16.04.)
Here is top_block.py:
#!/usr/bin/env python2
# -*- coding: utf-8 -*-
##
# GNU Radio Python Flow Graph
# Title: Dstar Transmitter
# Author: Thomas Early AC2IE
# Description: Uses NWDigitalRadio DV3000U
# Generated: Fri Nov 11 15:20:49 2016
##
if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print "Warning: failed to XInitThreads()"
from PyQt4 import Qt
from gnuradio import blocks
from gnuradio import digital
from gnuradio import eng_notation
from gnuradio import filter
from gnuradio import gr
from gnuradio import qtgui
from gnuradio import uhd
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
import ambe3000
import sip
import sys
import time
class top_block(gr.top_block, Qt.QWidget):
def __init__(self):
gr.top_block.__init__(self, "Dstar Audio Transmitter")
Qt.QWidget.__init__(self)
self.setWindowTitle("Dstar Audio Transmitter")
try:
self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
except:
pass
self.top_scroll_layout = Qt.QVBoxLayout()
self.setLayout(self.top_scroll_layout)
self.top_scroll = Qt.QScrollArea()
self.top_scroll.setFrameStyle(Qt.QFrame.NoFrame)
self.top_scroll_layout.addWidget(self.top_scroll)
self.top_scroll.setWidgetResizable(True)
self.top_widget = Qt.QWidget()
self.top_scroll.setWidget(self.top_widget)
self.top_layout = Qt.QVBoxLayout(self.top_widget)
self.top_grid_layout = Qt.QGridLayout()
self.top_layout.addLayout(self.top_grid_layout)
self.settings = Qt.QSettings("GNU Radio", "top_block")
self.restoreGeometry(self.settings.value("geometry").toByteArray())
##
# Variables
##
self.samp_rate = samp_rate = 32000
self.samples_per_symbol = samples_per_symbol = 100
self.lpf_taps = lpf_taps = firdes.low_pass(32767, samp_rate,
3500, 350, firdes.WIN_HAMMING, 6.76)
self.baud_rate = baud_rate = 4800
##
# Blocks
##
self.uhd_usrp_sink_0 = uhd.usrp_sink(
",".join(("", "")),
uhd.stream_args(
cpu_format="fc32",
channels=range(1),
),
)
self.uhd_usrp_sink_0.set_samp_rate(baud_rate*samples_per_symbol)
self.uhd_usrp_sink_0.set_center_freq(14655, 0)
self.uhd_usrp_sink_0.set_gain(20, 0)
self.uhd_usrp_sink_0.set_antenna('TX/RX', 0)
self.qtgui_time_sink_x_0 = qtgui.time_sink_c(
1024, #size
baud_rate*samples_per_symbol, #samp_rate
"", #name
1 #number of inputs
)
self.qtgui_time_sink_x_0.set_update_time(0.10)
self.qtgui_time_sink_x_0.set_y_axis(-1, 1)
self.qtgui_time_sink_x_0.set_y_label('Amplitude', "")
self.qtgui_time_sink_x_0.enable_tags(-1, True)
self.qtgui_time_sink_x_0.set_trigger_mode(qtgui.TRIG_MODE_FREE,
qtgui.TRIG_SLOPE_POS, 0.0, 0, 0, "")
self.qtgui_time_sink_x_0.enable_autoscale(True)
self.qtgui_time_sink_x_0.enable_grid(False)
self.qtgui_time_sink_x_0.enable_axis_labels(True)
self.qtgui_time_sink_x_0.enable_control_panel(False)
if not True:
self.qtgui_time_sink_x_0.disable_legend()
labels = ['', '', '', '', '',
'', '', '', '', '']
widths = [1, 1, 1, 1, 1,
1, 1, 1, 1, 1]
colors = ["blue", "red", "green", "black", "cyan",
"magenta", "yellow", "dark red", "dark green", "blue"]
styles = [1, 1, 1, 1, 1,
1, 1, 1, 1, 1]
markers = [-1, -1, -1, -1, -1,
-1, -1, -1, -1, -1]
Re: [Discuss-gnuradio] the dreaded AttributeError: 'module' object has no attribute...
Yes Nicolas, thanks. I did do that.
I have still been working on it and still haven't solved it.
On 11/12/2016 11:10 AM, Nicolas Cuervo wrote:
Hi Tom,
Did you, after you install your OOT module, run the following in your
terminal?:
sudo ldconfig
Cheers,
- Nicolas
On Fri, Nov 11, 2016 at 9:43 PM, Tom Early <mailto:ac...@nycap.rr.com>> wrote:
Sorry, me again.
Recently did a fresh install of ubuntu 16.10 and did a apt install
of gnuradio.
A few days ago you helped me get my OOT blocks properly installed
on my own tree by added square brackets around my value.
However there are now problems when I run:
File "/home/tom/grc-flow/top_block.py", line 147, in __init__
self.ambe3000_dstar_encode_sb_0 =
ambe3000.dstar_encode_sb('/dev/ttyUSB0', 230400)
AttributeError: 'module' object has no attribute 'dstar_encode_sb'
I'm having trouble finding useful info googling on this error
message. I have spend several days following various threads,
including rebuilding another, identical OOT from scratch with
gr_modtool.
My OOT is at https://github.com/ac2ie/gr-ambe3000
<https://github.com/ac2ie/gr-ambe3000> . (This OOT worked fine
with ubuntu 16.04.)
Here is top_block.py:
#!/usr/bin/env python2
# -*- coding: utf-8 -*-
##
# GNU Radio Python Flow Graph
# Title: Dstar Transmitter
# Author: Thomas Early AC2IE
# Description: Uses NWDigitalRadio DV3000U
# Generated: Fri Nov 11 15:20:49 2016
##
if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print "Warning: failed to XInitThreads()"
from PyQt4 import Qt
from gnuradio import blocks
from gnuradio import digital
from gnuradio import eng_notation
from gnuradio import filter
from gnuradio import gr
from gnuradio import qtgui
from gnuradio import uhd
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
import ambe3000
import sip
import sys
import time
class top_block(gr.top_block, Qt.QWidget):
def __init__(self):
gr.top_block.__init__(self, "Dstar Audio Transmitter")
Qt.QWidget.__init__(self)
self.setWindowTitle("Dstar Audio Transmitter")
try:
self.setWindowIcon(Qt.QIcon.fr
<http://Qt.QIcon.fr>omTheme('gnuradio-grc'))
except:
pass
self.top_scroll_layout = Qt.QVBoxLayout()
self.setLayout(self.top_scroll_layout)
self.top_scroll = Qt.QScrollArea()
self.top_scroll.setFrameStyle(Qt.QFrame.NoFrame)
self.top_scroll_layout.addWidget(self.top_scroll)
self.top_scroll.setWidgetResizable(True)
self.top_widget = Qt.QWidget()
self.top_scroll.setWidget(self.top_widget)
self.top_layout = Qt.QVBoxLayout(self.top_widget)
self.top_grid_layout = Qt.QGridLayout()
self.top_layout.addLayout(self.top_grid_layout)
self.settings = Qt.QSettings("GNU Radio", "top_block")
self.restoreGeometry(self.settings.value("geometry").toByteArray())
##
# Variables
##
self.samp_rate = samp_rate = 32000
self.samples_per_symbol = samples_per_symbol = 100
self.lpf_taps = lpf_taps = firdes.low_pass(32767,
samp_rate, 3500, 350, firdes.WIN_HAMMING, 6.76)
self.baud_rate = baud_rate = 4800
##
# Blocks
##
self.uhd_usrp_sink_0 = uhd.usrp_sink(
",".join(("", "")),
uhd.stream_args(
cpu_format="fc32",
channels=range(1),
),
)
self.uhd_usrp_sink_0.set_samp_rate(baud_rate*samples_per_symbol)
self.uhd_usrp_sink_0.set_center_freq(14655, 0)
self.uhd_u
[Discuss-gnuradio] debugging runtime errors
I would like to follow up a suggestion that my "AttributeError: 'module' object has no attribute ..." runtime error is caused by an improperly linked OOT. I am unsure how to do that. Can someone point me in the correct direction? Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] debugging runtime errors
Okay, my mistake. After more carefully reading the build output, I realized my system was missing swig. There was just a little, easy-to-miss comment about not finding swig buried in the "cmake .." output. Maybe cmake should error out if it can't find swig. Or am I missing something in the big picture? BTW, I'm using apt-installed gnuradio on a fresh install of ubuntu 16.10. On 11/16/2016 10:25 AM, Tom Early wrote: I would like to follow up a suggestion that my "AttributeError: 'module' object has no attribute ..." runtime error is caused by an improperly linked OOT. I am unsure how to do that. Can someone point me in the correct direction? Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] set_output_multiple() and forecast() when there are multiple sources in a general block
I am designing a general block that will split it's input into two outputs. 96 input items will become 9 items on one source and 3 items on another source. I have some questions: Is it required to set both streams in forecast()? How do I call set_output_multiple() where there are multiple sources, the larger stream, the first stream, the sum or what? When general_work() is called, is noutput_items for one stream or something else? Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] set_output_multiple() and forecast() when there are multiple sources in a general block
On 12/16/2016 11:52 PM, Andrej Rode wrote: Hey Tom, On 16/12/16 14:30, Tom Early wrote: I am designing a general block that will split it's input into two outputs. 96 input items will become 9 items on one source and 3 items on another source. I have some questions: Is it required to set both streams in forecast()? Forecast just determines how many items the scheduler should provide on each input port of your block to produce the requested number of output items by a upstream block. I'd is you take the maximum number of items you need at each input port to produce items on each output port. How do I call set_output_multiple() where there are multiple sources, the larger stream, the first stream, the sum or what? I would recommend you take the larger number of output items. The thing is the scheduler will only request chunks of n*output_multiple items and will give you a buffer with n*output_multiple for each output. (n>=1) When general_work() is called, is noutput_items for one stream or something else? noutput_items is basically the size of each of your output buffers. You are free to produce 0 items or any number up to noutput_items items on each of your outputs. For handling with multiple output streams with different rates I'd recommend you take a look at [0], especially forecast(), general_work(), consume() and produce() are interesting if you work with multiple inputs and multiple outputs with different rates. Maybe even history() if you want to retain a certain number of items for the next call of general_work(). I hope I could help you with your question :) Yes, this helps a lot, produce() and WORK_CALLED_PRODUCE is exactly what I was looking for! It is especially helpful as my next step after this was to make one of the sources produce a variable number of items with each general_work() call... and now I am already there! Thanks Andrej! Cheers, Andrej [0] http://gnuradio.org/doc/doxygen/classgr_1_1block.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
