Re: [Discuss-gnuradio] Maximum input items consumed on each input stream

[Adrian Musceac]

Hi,

I found this thread very useful, and I have another question regarding the
scheduler internals.
It is my understanding from reading documentation that each block's *work*
or *general_work* function
will be called at the highest sample rate that the block will see, whether
that is on the input or output of the block.
I'd like to know what happens if the block's work function does not finish
within the time allotted to it.
Is part of the input/output buffer dropped, or does it interfere with the
sample rate of the next blocks?

For example, I have a block which filters incoming samples with a variable
tap length matched filter to output the maximum correlation:
https://github.com/kantooon/gr-dsss/blob/master/lib/dsss_decoder_cc_impl.cc
If the filter size is too large, the block will consume too much CPU time
doing the filtering and output some wrong values.
Is this because some output is dropped/truncated, or because it changes the
sample rate of the next blocks?

Thanks,
Adrian

On Sat, Aug 31, 2019 at 4:56 AM Ron Economos  wrote:

> If you use set_output_multiple(), you don't have to check the input
> buffer. The block will only execute if there are a multiple of the value
> used in set_output_multiple() items available. For example, if
> set_output_multiple() is set to 256, the block will only execute if
> noutput_items is at least 256, but it could also be 512, 768, 1024, 1280,
> 1536, etc.
>
> Since forecast() sets ninput_items_required to noutput_items, the same
> number of items appears on the input buffer.
>
> Here's a dummy block that just copies input to output to show the
> structure. The loop in general_work() allows for any value of CHUNK_SIZE to
> work properly. With a size of 8900, the loop will typically only execute
> once.
>
> #ifdef HAVE_CONFIG_H
> #include "config.h"
> #endif
>
> #include 
> #include 
> #include "buffer_cc_impl.h"
>
> #define CHUNK_SIZE 8900
>
> namespace gr {
>   namespace laura {
>
> buffer_cc::sptr
> buffer_cc::make()
> {
>   return gnuradio::get_initial_sptr
> (new buffer_cc_impl());
> }
>
> /*
>  * The private constructor
>  */
> buffer_cc_impl::buffer_cc_impl()
>   : gr::block("buffer_cc",
>   gr::io_signature::make(1, 1, sizeof(gr_complex)),
>   gr::io_signature::make(1, 1, sizeof(gr_complex)))
> {
>   set_output_multiple(CHUNK_SIZE);
> }
>
> /*
>  * Our virtual destructor.
>  */
> buffer_cc_impl::~buffer_cc_impl()
> {
> }
>
> void
> buffer_cc_impl::forecast (int noutput_items, gr_vector_int
> &ninput_items_required)
> {
>   ninput_items_required[0] = noutput_items;
> }
>
> int
> buffer_cc_impl::general_work (int noutput_items,
>gr_vector_int &ninput_items,
>gr_vector_const_void_star &input_items,
>gr_vector_void_star &output_items)
> {
>   const gr_complex *in = (const gr_complex *) input_items[0];
>   gr_complex *out = (gr_complex *) output_items[0];
>
>   printf("noutput_items = %d\n", noutput_items);
>   for (int i = 0; i < noutput_items; i += CHUNK_SIZE) {
> memcpy(out, in, CHUNK_SIZE * sizeof(gr_complex));
> in += CHUNK_SIZE;
> out += CHUNK_SIZE;
>   }
>
>   consume_each (noutput_items);
>
>   // Tell runtime system how many output items we produced.
>   return noutput_items;
> }
>
>   } /* namespace laura */
> } /* namespace gr */
>
> Ron
> On 8/30/19 15:58, Laura Arjona wrote:
>
> Thank you very much Marcus, Michael, Abin, and Ron, really appreciate your
> responses.
> To give some context, I just started designing a prototype reader to
> implement a custom protocol for backscatter neural implants; very excited
> to build my platform with GNU-radio :)
>
> After reading all the information from your responses and links provided,
> I still have a problem with my implementation. According to the buffer
> sizes that you mentioned, I should not have this problem, but
> I think I am missing something. I may need to re-design my
> system/flow-graph, but I would like to get a last advice/help, if possible.
> Thanks in advance!
>
> *I want my block Decoder to consume_each(>8900) but I get overflows "D"
> messages. See details below*
>
> I have 2  general out of tree blocks: Gate and Decoder.
> They both have*:*
> *ninput_items_required[0] = noutput_items;*
> *const gr_complex *in = (const gr_complex *)
> input_items[0];*
>
> *   gr_complex *out = (gr_complex *) output_items[0];   *
>
>
> The flow-graph looks like
> *uhd_source -> fir_filter_ccc -> Gate -> Decoder -> other blocks.   (Using
> a USRP N210 + SBX) *
> The idea is that I want the block *Decoder* to only process the input
> samples when I have received *k* samples. Let's set k=~8900
> So, at the *Decoder* block general_work(), I set  *consume_each(0) *until
> *ninput_items[0]>=k.*
>
> Basica

[Discuss-gnuradio] ffast-math

[Albin Stigö]

Anyone has experience with the real world impact of using gcc -ffast-math
with SDR in general, and GNURadio/Volk in particular?


--Albin SM6WJM
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Maximum input items consumed on each input stream

[Kevin Reid]

On Sun, Sep 1, 2019 at 3:15 AM Adrian Musceac  wrote:

> I'd like to know what happens if the block's work function does not finish
> within the time allotted to it.
> Is part of the input/output buffer dropped, or does it interfere with the
> sample rate of the next blocks?
>

GNU Radio's flow graph has no notion of time or sample rate; it transfers
items (samples) from one block to another whenever some are available, and
without ever discarding any. If a block in the middle of a chain is slow,
then the buffers between blocks upstream of it will be mostly full, and the
buffers between blocks downstream of it will be mostly empty.

This means that all of the responsibility for dealing with time is on the
sink and/or source blocks in the flow graph. If samples are taken too
slowly from a source attached to some hardware generating samples at a
fixed rate, usually it will discard samples that it cannot fit into its
output buffer. Thus, *everything* downstream of the source will see the
discard glitch, not just the blocks downstream of the block that is
actually the computation bottleneck.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Building GNU Radio on Fedora 30 with pybomb to get a 3.8 installation

[Barry Scott]

This is my first time using GNU radio.

The 3.8 release is what I wish to use as it supports PyQt5.

I am follow the instructions from the Wiki.

But it seems that I ended up with a 3.7 install after some issues
that I'll describe.

Specifically:

pip3 install --user pybombs
pybombs auto-config
pybombs recipes add-defaults
pybombs prefix init ~/gnuradio -R gnuradio-default

I am seeing failures. It seems that the build wants to use python2 packages
which it did not install. I have been making progress by installing the
missing packages.

dnf install python2-lxml python2-numpy
pip2 install --user mako
pip3 install --user mako

After that The build completed. But its a 3.7.13.5 build not the 3.8 I was 
hoping for.

What is the recommended way to build gnu radio 3.8 in Fedora?
(I see that its not package for Fedora yet, even in rawhide).

Barry


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Building GNU Radio on Fedora 30 with pybomb to get a 3.8 installation

[jean-michel.fri...@femto-st.fr]

> pybombs prefix init ~/gnuradio -R gnuradio-default

gnuradio-default.lwr recipe is 3.7. Edit the recipe in 
.pybombs/recipes/gr-recipes
and replace gnuradio with (in order to call gnuradio38.lwr)
depends:
- gnuradio38

and in gnuradio38.lwr
gitbranch: master -> gitrev: v3.8.0.0
(since master is now 3.9)

JM

> 
> I am seeing failures. It seems that the build wants to use python2 packages
> which it did not install. I have been making progress by installing the
> missing packages.
> 
> dnf install python2-lxml python2-numpy
> pip2 install --user mako
> pip3 install --user mako
> 
> After that The build completed. But its a 3.7.13.5 build not the 3.8 I was 
> hoping for.
> 
> What is the recommended way to build gnu radio 3.8 in Fedora?
> (I see that its not package for Fedora yet, even in rawhide).
> 
> Barry
> 
> ___
> 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] Issue Receiving Messages Using Gr-IEEE-802-15-4

[Bastian Bloessl]

Hi,

great you got it working. AFAIK, there is not *the* XBee module, but
very different modules are sold as XBee. Some of them support standard
compliant IEEE 802.15.4/ZigBee (O-QPSK in 2.4GHz). They will work with
the OOT.

Best,
Bastian

On 8/31/19 8:29 PM, Tellrell White wrote:
> Thanks Bastian
> I was able to get it to work by adjusting the tuning frequency and the
> gain. I do have an additional question for you. Can the platform be used
> to communicate with XBee modules? For example, if I create a message
> using the message strobe in the flow graph would I be able to see this
> message using an XBee module?
> 
> Tellrell 
> 
> On Thu, Aug 15, 2019 at 5:16 AM Bastian Bloessl  > wrote:
> 
> Hi,
> 
> there are quite a lot of "XBee" boards. Some of them support multiple
> PHYs etc. So please make sure that the device is actually sending
> standard compliant IEEE 802.15.4 frames on the channel that you are
> tuned to. Use gr-fosphor to make sure that the device is actually
> sending on the frequency that you are expecting.
> 
> The transceiver, by default, shows a loopback configuration. Make sure
> it worked, i.e., it showed something in the PCAP file (you have to
> enable the Wireshark block).
> When switching to HW, disable the blocks that loop the samples back to
> the PHY.
> 
> If you still have problems, try different gains, make sure the antenna
> is connected to the correct port, make sure there are no overflows. If
> you use an SDR with an uncompensated DC offset, you can also try offset
> tuning.
> 
> If that also doesn't work, please provide more information.
> 
> Best,
> Bastian
> 
> 
> On 8/15/19 9:48 AM, Tellrell White wrote:
> > Hello
> > I'm using the GR-IEEE 802.15.4 OQPSK Transceiver and I'm trying to
> > receive a packet from a XBee ZigBee module and then import that packet
> > to wireshark. However, the file sink is always empty after running the
> > flowgraph. I have the rime stack, socket pdu, message strobe, and
> packet
> > pad all disabled since I'm simply trying to receive a packet. Is there
> > something I need to configure within the MAC block to do this?
> >
> > Tellrell
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> 
> -- 
> Dr. Bastian Bloessl
> Secure Mobile Networking Lab (SEEMOO)
> TU Darmstadt, Germany
> 
> www.bastibl.net 
> GitHub/Twitter: @bastibl
> 




smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio