[Discuss-gnuradio] PSK Demodulator performance
Does anyone have any information on the performance - specifically the implementation loss of the Gnuradio PSK demodulator block? I am trying to work out a link budget. Typically this would be 1dB or so from ideal. Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fwd: configuration incomplete , errors occur !
Hello Sara, this is very strange. It looks like there's an extra module (that you shouldn't be rebuilding, anyway) which tries to find an old version of GNU Radio. Can you tell us which module that is? You should realize what your doing here: you download the build-gnuradio script anew, and then call it two times... that's one download and one execution too many. The pupose of the build-gnuradio script is to fetch the source code and install all requirement, and in the end build GNU Radio and install it. Since you're modifying the source code, this might *not* be what you want. What you should be doing is going into your existing gnuradio/build directory, and do a "make -j3"[1], "sudo make install". This should be faster. Please check that your modifications are still around before, build-gnuradio might have overwritten them. Again, please have a look at http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide . In the other thread you asked what you can do to understand the C++ code; my suggestion here is going through http://gnuradio.org/redmine/projects/gnuradio/wiki/Tutorials , especially the "core concepts" and the "developing out-of-tree modules" tutorial, as well as "how to debug". I think the problem lies usually less in the C++ code but in the complexity brought on by a complex framework such as GNU Radio and by a complex task such as doing OFDM synchronization in software -- it's very important you get a feeling of what the system is doing (and what you are doing with the system) before trying to understand the C++ code in isolation. Hope that helped a little, Greetings, Marcus [1] or something, the -j parameters tells make how many things to do in parallel. As a rule of thumb: Number of CPU cores + 1 On Sat, May 3, 2014 at 6:21 AM, Sara Chérif wrote: > I am installing GNU radio using this command > > wget http://www.sbrac.org/files/build-gnuradio && chmod a+x > ./build-gnuradio && ./build-gnuradio --verbose > But I found at the end of the installation an error (after 2 hours from > beginning of installation during building of extra modules ) > > Building extra module grextras > -- The CXX compiler identification is GNU > -- The C compiler identification is GNU > -- Check for working CXX compiler: /usr/bin/c++ > -- Check for working CXX compiler: /usr/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Check for working C compiler: /usr/bin/gcc > -- Check for working C compiler: /usr/bin/gcc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Build type not specified: defaulting to release. > -- Boost version: 1.48.0 > -- checking for module 'volk' > -- found volk, version 0.1 > -- Found VOLK: /usr/local/lib/libvolk.so > -- checking for module 'gruel' > -- package 'gruel' not found > -- Could NOT find GRUEL (missing: GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS) > -- checking for module 'gnuradio-core' > -- package 'gnuradio-core' not found > -- Could NOT find GNURADIO_CORE (missing: GNURADIO_CORE_LIBRARIES > GNURADIO_CORE_INCLUDE_DIRS) > CMake Error at CMakeLists.txt:112 (message): > Gruel required to compile extras > -- Configuring incomplete, errors occurred! > make: *** No targets specified and no makefile found. Stop. > make: *** No rule to make target `install'. Stop. > Done function extras at: Sat May 3 06:02:03 EET 2014 > Starting function mod_groups at: Sat May 3 06:02:03 EET 2014 > make: *** No targets specified and no makefile found. Stop. > make: *** No rule to make target `install'. Stop. > Done function extras at: Sat May 3 06:02:03 EET 2014 > > Also when I run then GNURADIO in terminal , I got this line: XML parser: > Found 1 erroneous XML file while loading the block tree (see "Help/Parser > errors" for details) > > > sara@sara-Inspiron-N5010:~$ gnuradio-companion > Warning: Block key "blocks_ctrlport_monitor_performance" not found when > loading category tree. > Warning: Block key "blocks_ctrlport_monitor_performance" not found when > loading category tree. > linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.007.001-14-g1d2e8d39 > > <<< Welcome to GNU Radio Companion 3.7.3 >>> > > XML parser: Found 1 erroneous XML file while loading the block tree (see > "Help/Parser errors" for details) > > Showing: "" > > > --- > Is there a big problem in installation , Do I have to reinstall?! I don't > know why these errors occur!! > Thanks > > > > ___ > 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] PSK Demodulator performance
On 05/03/2014 09:35 AM, Mike Willis wrote: > Does anyone have any information on the performance – specifically the > implementation loss of the Gnuradio PSK demodulator block? I am trying > to work out a link budget. Typically this would be 1dB or so from ideal. By ideal, you mean the theoretical BER values for a given Eb/N0? If so, that would be easy to determine -- have a look at berawgn.py, replace the slicer with the PSK demod and allow for some initialization time. Cheers, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: configuration incomplete , errors occur !
On 05/03/2014 10:35 AM, Marcus Müller wrote: > Hello Sara, > this is very strange. It looks like there's an extra module (that you > shouldn't be rebuilding, anyway) which tries to find an old version of > GNU Radio. Can you tell us which module that is? Looks like it's grextras. You don't need that. > [1] or something, the -j parameters tells make how many things to do in > parallel. As a rule of thumb: Number of CPU cores + 1 I usually use less. Sometimes, I just want some space left to do other things, but parallel swigging can also seriously eat into your RAM, and cause swapping. Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PSK Demodulator performance
Hi Mike!
Well, from a purely algorithmic point of view, there is no approximate
magic happening inside the PSK demapper
(from constellation.cc):
unsigned int
constellation_psk::get_sector(const gr_complex *sample)
{
float phase = arg(*sample);
float width = M_TWOPI / n_sectors;
int sector = floor(phase/width + 0.5);
if(sector < 0)
sector += n_sectors;
return sector;
}
This is "perfect" up to the degree that arg() works well enough, which is
mainly a matter of float accuracy, I guess, and should therefore be well
below any significance.
The other thing is the finite-length root-raised cosine matched filtering;
I think you can derive losses for that, but I think Martin's approach of
measuring things might be faster and more accurate in the end.
Greetings,
Marcus
On Sat, May 3, 2014 at 10:59 AM, Mike Willis wrote:
> Marcus
>
>
>
> Thanks for the answer – what goes into the link budget is a maximum error
> rate – 10^-5 or 10^-6 would by typical – so assuming a perfect transmission
> system if you have an ideal demodulator you can work out the bit error rate
> curve which might give say 12dB Eb/No. In practice the demodulator won’t be
> perfect, it might need 13dB or 12.5 dB to achieve the same error rate as an
> ideal demodulator. That’s what I meant. No soft decisions here, regrettably
> its a hard decision, 0 or 1.
>
>
>
> I agree other parts of the chain add their own losses, we account for
> those also.
>
>
>
> To explain, we have a DBPSK packet with up to 280 bytes in it. So a
> reasonable bit error rate is maybe 10^-5 to not lose too many.
>
>
>
> Mike
>
>
>
> *From:* Marcus Müller [mailto:marcus.muel...@ettus.com]
> *Sent:* 03 May 2014 09:50
> *To:* Mike Willis
> *Subject:* Re: [Discuss-gnuradio] PSK Demodulator performance
>
>
>
> Hi Mike,
>
> to me, a link budget is essentially the minimum SNR that my system has to
> work under.
> That is basically: If every component of the transmission chain has its
> impact on overall SNR, the SNR is available at the point of symbol
> decision, which is your PSK demod (channel coding aside).
>
> So what's the loss for a PSK demodulator?
> If we look at the psk_demod available in the grc, all it does is take
> complex samples as input, use the root raised cosine pulse shape it assumes
> the signal to have to synchronize (and maximize SNR). From my point of
> view, that actually introduces processing gain, not loss. Maybe you were
> comparing it to a soft output decoder?
>
> Greetings,
>
> Marcus
>
>
>
> On Sat, May 3, 2014 at 9:35 AM, Mike Willis wrote:
>
> Does anyone have any information on the performance – specifically the
> implementation loss of the Gnuradio PSK demodulator block? I am trying to
> work out a link budget. Typically this would be 1dB or so from ideal.
>
>
>
> Mike
>
>
> ___
> 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] About the decoding result of gr-air-modes
Hi all, I install the gr-air modes. And the hardware I am using is USRP N210 without GPSDO. The command I am using is the default command of the modes_rx module. And after I run this module, I got the following Results: (-47 32.32056722) No handler for message type 24 from 739803 (-48 34.25826672) No handler for message type 24 from 207ee9 (-48 35.86728697) Type 5 (short surveillance ident reply) from a49b0c with ident 1264 (SPI ALERT) (-48 35.87198622) No handler for message type 24 from a35558 (-50 35.95602397) No handler for message type 24 from 8b672a (-49 35.97354972) Type 4 (short surveillance altitude reply) from 6e0c4c at 65200ft (AIRBORNE ALERT) (-48 36.32546122) Type 5 (short surveillance ident reply) from 69f33f with ident 5514 (SPI) (-49 37.18337247) Type 0 (short A-A surveillance) from 608e19 at 120900ft (No TCAS) (aircraft is on the ground) (-48 37.21837897) No handler for message type 24 from e80163 (-50 38.68267197) No handler for message type 24 from b3e6f2 (-48 39.26921197) Type 0 (short A-A surveillance) from 12ff05 at 2250ft (speed 600-1200kt) (aircraft is on the ground) (-49 40.52049497) Type 5 (short surveillance ident reply) from 38e9a8 with ident 3576 (SPI) (-48 40.56394397) Type 0 (short A-A surveillance) from cf63e4 at 8700ft (Full TCAS resolution) (aircraft is on the ground) (-47 40.56904497) No handler for message type 24 from 5353ab (-48 41.08549722) No handler for message type 24 from b60846 DD(-48 52.18300072) Type 5 (short surveillance ident reply) from da22a7 with ident 3450 (SPI) (-47 53.62936347) Type 5 (short surveillance ident reply) from 8c773 with ident 3374 (GROUND ALERT) D(-49 56.62670697) Type 0 (short A-A surveillance) from fa024d at 125800ft (speed 1200-2400kt) (-47 56.95657397) Type 5 (short surveillance ident reply) from 3b6a76 with ident 5634 (aircraft is on the ground) (-47 57.34665522) No handler for message type 24 from f9ac8a D(-50 59.47285847) Type 5 (short surveillance ident reply) from 7d6227 with ident 3510 (SPI ALERT) (-51 59.49907272) Type 0 (short A-A surveillance) from 581dfb at 76200ft (No TCAS) (aircraft is on the ground) D(-48 61.03326422) No handler for message type 24 from a90fee (-48 61.18943772) Type 21 link capability report from 18049d: ACS: 0xd0ccc, BCS: 0xfeae, ECS: 0xa7, continues 4 ident 1810 (-49 62.11700572) Type 4 (short surveillance altitude reply) from 62253 at 17325ft (SPI ALERT) (-47 62.44659672) No handler for message type 24 from 27adc7 D(-49 64.96764872) No handler for message type 24 from e30901 (-50 64.98554547) Type 5 (short surveillance ident reply) from a39eee with ident 7306 (SPI ALERT) (-47 65.04707547) No handler for message type 24 from 0ec82e (-49 65.10223472) Type 5 (short surveillance ident reply) from ca6477 with ident 3034 (AIRBORNE ALERT) (-48 66.02713647) No handler for message type 24 from b4567c (-48 66.37042047) No handler for message type 24 from 21544d (-49 66.49397872) No handler for message type 24 from 759628 (-49 66.62760947) No handler for message type 24 from d79b77 (-48 67.58220572) Type 5 (short surveillance ident reply) from 98fb94 with ident 3334 (AIRBORNE ALERT) (-49 68.06558797) No handler for message type 24 from 6d93b5 (-48 68.86033522) No handler for message type 24 from 4cc3fd This is not what I want and I don't think it is the correct decoding result, is it right? I did this experiments in indoor environment, then I think maybe the signal is too weak, then I move to the corridor and redo this and get similar results. I can not get the position of the air plane. So my question is that, is it all about the environment? Is there any other possible bugs or something I missed that cause the output I've received? I am very curious because the corridor is quite close to the out door environment. Thanks a lot. Yaxiong -- *Yaxiong Xie / **谢亚雄* School of Computer Engineering Nanyang Technological University, Singapore ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] configuration incomplete , errors occur !
On 05/03/2014 12:21 AM, Sara Chérif wrote: I am installing GNU radio using this command wget http://www.sbrac.org/files/build-gnuradio && chmod a+x ./build-gnuradio && ./build-gnuradio --verbose But I found at the end of the installation an error (after 2 hours from beginning of installation during building of extra modules ) Building extra module grextras -- The CXX compiler identification is GNU -- The C compiler identification is GNU -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Build type not specified: defaulting to release. -- Boost version: 1.48.0 -- checking for module 'volk' -- found volk, version 0.1 -- Found VOLK: /usr/local/lib/libvolk.so -- checking for module 'gruel' -- package 'gruel' not found -- Could NOT find GRUEL (missing: GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS) -- checking for module 'gnuradio-core' -- package 'gnuradio-core' not found -- Could NOT find GNURADIO_CORE (missing: GNURADIO_CORE_LIBRARIES GNURADIO_CORE_INCLUDE_DIRS) CMake Error at CMakeLists.txt:112 (message): Gruel required to compile extras -- Configuring incomplete, errors occurred! make: *** No targets specified and no makefile found. Stop. make: *** No rule to make target `install'. Stop. Done function extras at: Sat May 3 06:02:03 EET 2014 Starting function mod_groups at: Sat May 3 06:02:03 EET 2014 make: *** No targets specified and no makefile found. Stop. make: *** No rule to make target `install'. Stop. Done function extras at: Sat May 3 06:02:03 EET 2014 Also when I run then GNURADIO in terminal , I got this line: XML parser: Found 1 erroneous XML file while loading the block tree (see "Help/Parser errors" for details) sara@sara-Inspiron-N5010:~$ gnuradio-companion Warning: Block key "blocks_ctrlport_monitor_performance" not found when loading category tree. Warning: Block key "blocks_ctrlport_monitor_performance" not found when loading category tree. linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.007.001-14-g1d2e8d39 <<< Welcome to GNU Radio Companion 3.7.3 >>> XML parser: Found 1 erroneous XML file while loading the block tree (see "Help/Parser errors" for details) Showing: "" --- Is there a big problem in installation , Do I have to reinstall?! I don't know why these errors occur!! Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio The gr-extras code hasn't been updated for GR3.7, and so, won't build under 3.7. But it's not a critical subsystem, so its failure to build won't cause the rest of the build to fail. The errors about "blocks_ctrlport_monitor" are "normal", in that they are showing up because the XML for them is included even when the underlying subsystem code doesn't get built (which it won't unless you have all the pre-requisites required for ctrlport already installed). -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About the decoding result of gr-air-modes
Do you get the GPS location of the air plane? Or do you get it before? If it is not the radio or antenna, maybe the environment matters? I didn't do any experiments in a totally open area, so I don't know whether it works under that scenario. If we can decoding the signal in environment, I think it should be very useful. Yaxiong 2014-05-03 21:54 GMT+08:00 Silverfox : > I have had the type 24 message for a long time. However, the new reports > seem bogus to me as well. It is not the result of the radio or antenna as > far as I can determine. > > 73, > > Alan - W6ARH > > > > > > *From:* discuss-gnuradio-bounces+alan.r.hill=gmail@gnu.org [mailto: > discuss-gnuradio-bounces+alan.r.hill=gmail@gnu.org] *On Behalf Of *YAXIONG > XIE > *Sent:* Saturday, May 3, 2014 6:44 AM > *To:* discuss-gnuradio@gnu.org > *Subject:* [Discuss-gnuradio] About the decoding result of gr-air-modes > > > > Hi all, > > > > I install the gr-air modes. And the hardware I am using is USRP N210 > without GPSDO. The command I am using is the default command of the > modes_rx module. And after I run this module, I got the following Results: > > > > (-47 32.32056722) No handler for message type 24 from 739803 > > (-48 34.25826672) No handler for message type 24 from 207ee9 > > (-48 35.86728697) Type 5 (short surveillance ident reply) from a49b0c > with ident 1264 (SPI ALERT) > > (-48 35.87198622) No handler for message type 24 from a35558 > > (-50 35.95602397) No handler for message type 24 from 8b672a > > (-49 35.97354972) Type 4 (short surveillance altitude reply) from 6e0c4c > at 65200ft (AIRBORNE ALERT) > > (-48 36.32546122) Type 5 (short surveillance ident reply) from 69f33f > with ident 5514 (SPI) > > (-49 37.18337247) Type 0 (short A-A surveillance) from 608e19 at 120900ft > (No TCAS) (aircraft is on the ground) > > (-48 37.21837897) No handler for message type 24 from e80163 > > (-50 38.68267197) No handler for message type 24 from b3e6f2 > > (-48 39.26921197) Type 0 (short A-A surveillance) from 12ff05 at 2250ft > (speed 600-1200kt) (aircraft is on the ground) > > (-49 40.52049497) Type 5 (short surveillance ident reply) from 38e9a8 with > ident 3576 (SPI) > > (-48 40.56394397) Type 0 (short A-A surveillance) from cf63e4 at 8700ft > (Full TCAS resolution) (aircraft is on the ground) > > (-47 40.56904497) No handler for message type 24 from 5353ab > > (-48 41.08549722) No handler for message type 24 from b60846 > > DD(-48 52.18300072) Type 5 (short surveillance ident reply) from da22a7 > with ident 3450 (SPI) > > (-47 53.62936347) Type 5 (short surveillance ident reply) from 8c773 with > ident 3374 (GROUND ALERT) > > D(-49 56.62670697) Type 0 (short A-A surveillance) from fa024d at > 125800ft (speed 1200-2400kt) > > (-47 56.95657397) Type 5 (short surveillance ident reply) from 3b6a76 > with ident 5634 (aircraft is on the ground) > > (-47 57.34665522) No handler for message type 24 from f9ac8a > > D(-50 59.47285847) Type 5 (short surveillance ident reply) from 7d6227 > with ident 3510 (SPI ALERT) > > (-51 59.49907272) Type 0 (short A-A surveillance) from 581dfb at 76200ft > (No TCAS) (aircraft is on the ground) > > D(-48 61.03326422) No handler for message type 24 from a90fee > > (-48 61.18943772) Type 21 link capability report from 18049d: ACS: > 0xd0ccc, BCS: 0xfeae, ECS: 0xa7, continues 4 ident 1810 > > (-49 62.11700572) Type 4 (short surveillance altitude reply) from 62253 at > 17325ft (SPI ALERT) > > (-47 62.44659672) No handler for message type 24 from 27adc7 > > D(-49 64.96764872) No handler for message type 24 from e30901 > > (-50 64.98554547) Type 5 (short surveillance ident reply) from a39eee > with ident 7306 (SPI ALERT) > > (-47 65.04707547) No handler for message type 24 from 0ec82e > > (-49 65.10223472) Type 5 (short surveillance ident reply) from ca6477 with > ident 3034 (AIRBORNE ALERT) > > (-48 66.02713647) No handler for message type 24 from b4567c > > (-48 66.37042047) No handler for message type 24 from 21544d > > (-49 66.49397872) No handler for message type 24 from 759628 > > (-49 66.62760947) No handler for message type 24 from d79b77 > > (-48 67.58220572) Type 5 (short surveillance ident reply) from 98fb94 with > ident 3334 (AIRBORNE ALERT) > > (-49 68.06558797) No handler for message type 24 from 6d93b5 > > (-48 68.86033522) No handler for message type 24 from 4cc3fd > > > > This is not what I want and I don't think it is the correct decoding > result, is it right? > > > > I did this experiments in indoor environment, then I think maybe the > signal is too weak, then I move to the corridor and redo this and get > similar results. I can not get the position of the air plane. > > > > So my question is that, is it all about the environment? Is there any > other possible bugs or something I missed that cause the output I've > received? I am very curious because the corridor is quite close to the out > door environment. > > > > Thanks a lot. > > Yaxiong > > > > -- > > *Yaxiong Xie / **谢亚雄* > > > > S
[Discuss-gnuradio] CGRAN down, working on it
It looks like CGRAN is down for some reason. The machine that hosts it is still up and I haven't found the cause of the problem yet. Still digging. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CGRAN down, working on it
Something must have been upgraded on the machine, and a significant number of the dependencies needed to run Trac have disappeared. For example, python has disappeared from the machine :P This might take a while, sorry. On Sat, May 3, 2014 at 1:15 PM, George Nychis wrote: > It looks like CGRAN is down for some reason. The machine that hosts it is > still up and I haven't found the cause of the problem yet. Still digging. > > - George > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions on callback functions implementation of blocks in gr-trellis
Zhe, there are way too many changes in this diff file for anyone to track and debug. I suggest you start with a clean gr-trellis and change JUST one block (say the viterbi_combined) and see if this change propagates in python and grc as you expect. You can also post this change to the list for further feedback (together with the SIMPLEST possible grc example that indicates the problem.) best, Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Should return the number of input or the number of output?
Part of this question has been partially discussed, as below. On Mon, Mar 10, 2014 at 9:18 PM, Martin Braun wrote: > OK, I admit I was unclear. Let's try from scratch: > - The return function from work() or general_work() is the amount of > items that were *produced*. > Says, now I need to create a sink block, and I need to highly customize its built-in forecast() function. Hence I have two choices:- (i). Create this as a sink block, then explicitly overwrite its forecast() function in the body of the custom block. (ii). Create this as a general block. Question 1: Will option (i) above work? Question 2: If a sink block is implemented as a general block, does it still need to return noutput_items, or just return 0, or doesn't matter at all ? (I guess it should return 0 because the sink block doesn't produce any output) > - In a sync block, the number of items produced is the number of items > consumed, so we can use that to save the developer from manually > consuming(). In other words, in a sync block, the return value is *both* > the number of produced and consumed items. > - Sinks and sources are syncs, therefore the mechanic is always the same. > - Sinks are a special case because they don't produce anything. However, > the scheduler knows the block's io signature, and knows what to do. The > consume/produce mechanic stays the same, for consistency's sake, as with > all other sync blocks. > > Hope this clears things up! > M > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
