Re: [Discuss-gnuradio] Issue Receiving Messages Using Gr-IEEE-802-15-4

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 <mail@bastibl.net> 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

[Discuss-gnuradio] How to get a specific output of a block if a condition is true?

new_mode_vppm_demodulator_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 float *in = (const float *) input_items[0];
unsigned char *out = (unsigned char *) output_items[0];

// get the lowest count of items of the input and output buffer
int ninput_noutput_min = std::min(noutput_items, ninput_items[0]);

// create a vector of type tag_t which can hold the tag information of found tags
std::vector<tag_t> tags;

// store the distance between the first sample in the input buffer and the tag
int nitems_read_tag_delta = 0;
int tag_offset = 0;

int ninput_items_tag_offset_delta = 0;

if (d_tag_found)
{
std::cout << "Tag found before - get the remaining data" << std::endl;
// there was one tag already in the previous call of the work-function
// copy the remaining data into the array
int tmp = d_read_counter;
for (int i = 0; i < ninput_items[0]; i++)
{
/* check if the iteration variable "i" is equal to the max count of samples per symbol
* or if the counter variable "d_read_counter" is equal the max count of samples per symbol
*/
if ((i == d_samples_per_symbol) || (d_read_counter == d_samples_per_symbol))
{
// reset the d_read_counter
d_read_counter = 0;
d_ready_for_correlation = true;

std::cout << "********* !!!READY FOR CORRELATION!!! *********" << std::endl;
// leave the for-loop because the necessary amount of data is available for correlation
break;
}
else{
// store the samples in the vector for correlation
d_vppm_symbol_samples[i + tmp] = in[i];
d_read_counter++;
}

} // end for-loop
std::cout << "d_tag_found=true d_read_counter: " << d_read_counter << std::endl;

}
else // no tag found yet
{
// get all tags that are stored in the sample stream
get_tags_in_range(tags, 0, nitems_read(0), nitems_read(0) + ninput_items[0], d_lengthtag);

// check if tags were found in the bunch of samples in input buffer
if (tags.size() > 0)
{
d_tag_found = true;
// There was a tag in the sample stream!
std::cout << "Tag found - move on!!" << std::endl;
std::cout << "count of tags: " << tags.size() << std::endl; // this line prints the count of tags that were found

// store the offset between the first sample of the input stream and the tag
tag_offset = tags[0].offset;

// the delta between ID of tag.offset and first item of input_buffer
nitems_read_tag_delta = tag_offset - nitems_read(0);

// get the count of samples that can be copied from the tag until the end of the current input buffer samples
ninput_items_tag_offset_delta = ninput_items[0] - (nitems_read_tag_delta);

// copy all items after the tag
for (int i = 0; i < ninput_items_tag_offset_delta; i++)
{
if (i == d_samples_per_symbol) //((i == d_samples_per_symbol) || (d_read_counter == d_samples_per_symbol))
{
//reset variables and exit the loop
d_read_counter = 0;
std::cout << "********* !!! first attempt READY FOR CORRELATION!!! *********" << std::endl;

d_ready_for_correlation = true;

// leave the for-loop
// next step will be to calculate the correlation
break;
}
else
{
d_vppm_symbol_samples[i] = in[i + tag_offset];
d_read_counter++;
}

if (i == (ninput_items_tag_offset_delta - 1))
{
std::cout << "Not enough samples yet. Continue with the next call of the work function!" << std::endl;
}
}
std::cout << "d_tag_found=false d_read_counter: " << d_read_counter << std::endl;
} // loop for processing the found tags
}

// skip code.....

// end skip code....
}

Hello GNU Radio community,

I'm trying to program a demodulation block for a variable pulse position modulation with c++ and have a problem where nobody know how to solve it.

At the moment it is a offline simulation and don't use USRP yet but this is my final goal.

I already created a block (type interpolator) that gets a byte and creates a 4-vppm symbol (containing 2 bits which mean there are 4 slots) that contains out of 4000 samples. Depending of the byte value only 10 samples are 1 at the beginning of the respective slot (i.e. (1100 0000 0000 0000 if byte is 0x00 or 0000 0000 1100 0000 if byte is 0x02). For adding the preamble sequence before the vppm symbol I use the "Stream Mux" block.

Now the part of my problem:

On the receiver side I created a preamble detection block (type general) which runs a cross-correlation and adds a tag to the stream if the preamble was found.

First I used the block "Tagged Stream Align" but I found out that the block only aligns the stream one time. So if i want to start a second transmission the stream is not aligned again and I don't get the expected output.

So my idea was to create a block (type general?) that search in the incoming stream for the tag "preamble_match". If a tag is found than copy 4000 samples beginning of the tag offset. It's possible that ninput_items[0] is < 4000 so I have to get the remaining items with the next call of the work-function. If I have 4000 items I want to start the demodulation and the block should only output one value. All the other time there should be no output of the block. I conected the block with a file sink and observed that the block is putting out data all the time. So how can I make sure that the block only put out a specific amout of data if a condition is true and if the condition is false no data is put out?

Please find below a stripped down version of the c++ code (and attached as txt file) of my general work function:

    new_mode_vppm_demodulator_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 float *in = (const float *) input_items[0];
        unsigned char *out = (unsigned char *) output_items[0];

        // get the lowest count of items of the input and output buffer
        int ninput_noutput_min = std::min(noutput_items, ninput_items[0]);

        // create a vector of type tag_t which can hold the tag information of found tags
        std::vector<tag_t> tags;

        // store the distance between the first sample in the input buffer and the tag
        int nitems_read_tag_delta = 0;
        int tag_offset = 0;

        int ninput_items_tag_offset_delta = 0;

        if (d_tag_found)
        {
            std::cout << "Tag found before - get the remaining data" << std::endl;
            // there was one tag already in the previous call of the work-function
            // copy the remaining data into the array
            int tmp = d_read_counter;
            for (int i = 0; i < ninput_items[0]; i++)
            {
                /* check if the iteration variable "i" is equal to the max count of samples per symbol
                 * or if the counter variable "d_read_counter" is equal the max count of samples per symbol
                 */
                if ((i == d_samples_per_symbol) || (d_read_counter == d_samples_per_symbol))
                {
                    // reset the d_read_counter
                    d_read_counter = 0;
                    d_ready_for_correlation = true;

                    std::cout << "********* !!!READY FOR CORRELATION!!! *********" << std::endl;
                    // leave the for-loop because the necessary amount of data is available for correlation
                    break;
                }
                else{
                    // store the samples in the vector for correlation
                    d_vppm_symbol_samples[i + tmp] = in[i];
                    d_read_counter++;
                }


            } // end for-loop
            std::cout << "d_tag_found=true d_read_counter: " << d_read_counter << std::endl;

        }
        else // no tag found yet
        {
            // get all tags that are stored in the sample stream
            get_tags_in_range(tags, 0, nitems_read(0), nitems_read(0) + ninput_items[0], d_lengthtag);

            // check if tags were found in the bunch of samples in input buffer
            if (tags.size() > 0)
            {
                d_tag_found = true;
                // There was a tag in the sample stream!
                std::cout << "Tag found - move on!!" << std::endl;
                std::cout << "count of tags: " << tags.size() << std::endl; // this line prints the count of tags that were found

                // store the offset between the first sample of the input stream and the tag
                tag_offset = tags[0].offset;

                // the delta between ID of tag.offset and first item of input_buffer
                nitems_read_tag_delta = tag_offset - nitems_read(0);

                // get the count of samples that can be copied from the tag until the end of the current input buffer samples
                ninput_items_tag_offset_delta = ninput_items[0] - (nitems_read_tag_delta);

                // copy all items after the tag
                for (int i = 0; i < ninput_items_tag_offset_delta; i++)
                {
                    if (i == d_samples_per_symbol) //((i == d_samples_per_symbol) || (d_read_counter == d_samples_per_symbol))
                    {
                        //reset variables and exit the loop
                        d_read_counter = 0;
                        std::cout << "********* !!! first attempt READY FOR CORRELATION!!! *********" << std::endl;

                        d_ready_for_correlation = true;

                        // leave the for-loop
                        // next step will be to calculate the correlation
                        break;
                    }
                    else
                    {
                        d_vppm_symbol_samples[i] = in[i + tag_offset];
                        d_read_counter++;
                    }

                    if (i == (ninput_items_tag_offset_delta - 1))
                    {
                        std::cout << "Not enough samples yet. Continue with the next call of the work function!" << std::endl;
                    }
                }
                std::cout << "d_tag_found=false d_read_counter: " << d_read_counter << std::endl;
            } // loop for processing the found tags
        }


// skip code.....

// end skip code....
    }

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

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"

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

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.

Basically, at the Decoder general_work() I have the following (just a overview, not pseudo-code):

 if (ninput_items[0] <k)

       //do nothing

      //consume_each(0)

else

     // process the input samples

     //consume_each(k)

My problem is that if I set k~8900, I get 'D' messages on the terminal.

And one interesting? thing happens. When ninput_items[0] gets close to k=8500 (or higher value), is when I start getting  'D', and after

that ninput_items[0] = 800, no matter the value of k.

Thank you.

Cheers

Laura.

On Fri, Aug 30, 2019 at 7:29 AM Müller, Marcus (CEL) <mueller@kit.edu> wrote:

Hi Ron,

just because I think this might be interesting to people dealing with
really high rates:
The maximum size is typically limited by the size of mmap'able memory
that you can allocate; that depends on the circular buffer factory
used:
For the posix shared memory thing, I don't think anything is stopping
you from using "memory space size" order amounts of buffer.
For anonymous file-backed mmap'ed buffers, I'd expect that we haven't
addressed the possibility of using more than 32 bit addresses, so
somewhere around 2 GB you'd find your upper limit.

Best regards,
Marcus

On Fri, 2019-08-30 at 06:20 -0700, Ron Economos wrote:
> Just to put a number on this question, the DVB-T2 transmitter uses up to 16 Megabyte buffers between blocks. I'm not sure what the absolute maximum is, but 16 Megabytes should cover most applications.
> The DVB-T2 blocks use set_output_multiple() in conjunction with forecast() to allocate these large buffers.
> Ron
> On 8/28/19 11:46, Laura Arjona wrote:
> > Hello GNURadio community,
> >
> > Does anyone know what is the maximum number of input items that an Out Of Tree block can consume on each input stream?
> >
> > consume_each(consumed) --> what is the maximum value that the variable consumed can take?
> >
> > Thank you very much.
> >
> >
> > --
> > Laura Arjona
> > Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering
> >
> > Paul G. Allen School of Computer Science & Engineering
> > 185 E Stevens Way NE
> > University of Washington
> > Seattle, WA 98195-2350
> >
> >
> > _______________________________________________
> > 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

--

Laura Arjona 

Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering

Paul G. Allen School of Computer Science & Engineering

185 E Stevens Way NE

University of Washington

Seattle, WA 98195-2350

Re: [Discuss-gnuradio] Expensive file write operation

Also note that a total of 40 MS/s, even at 16sc, is still 160 MB/s in
data; it's not guaranteed that a consumer SSD would sustain that rate
for arbitrarily long.
Average write rates these days most definitely suffice, but don't
underestimate the effect filesystem bookkeeping and imperfect buffer
handling on OS side.

Best regards,
Marcus

On Fri, 2019-08-30 at 19:56 +0200, sumit kumar wrote:
> Hi Nate,
> Ok I understood your point. Thanks for the Freq hint :) , I missed that in hurry.
> Regards
> Sumit
>
> On Fri, 30 Aug 2019 at 19:50, Nate Temple <nate.temple@ettus.com> wrote:
> > Hi Sumit,
> >
> > The change for the output type doesn't address the limits of the transport. The output change however does cut the rate of data you're storing to disk in half, which can be useful if you have longer recordings or if your SSD is the bottle neck.
> >
> > This Akitio adapter box paired with a Mellanox card is a setup we have tested for TB3 to 10Gb:
> >
> > https://www.newegg.com/akitio-model-t3pb-t3dis-aktu/p/N82E16814988001
> > https://store.mellanox.com/products/mellanox-mcx4121a-acat-connectx-4-lx-en-network-interface-card-25gbe-dual-port-sfp28-pcie3-0-x8-rohs-r6.html
> >
> > I have not personally used this QNAP product, but others have reported it works fine (you'd want the one with the SFP port)
> >
> > https://www.qnap.com/en-us/product/qna-tb-10gbe
> >
> >
> > One other observation on your flowgraph, you do not have the Ch1 Center Freq set correctly, it is currently set as 0.
> >
> >
> > Regards,
> > Nate Temple
> >
> >
> > On Fri, Aug 30, 2019 at 10:42 AM sumit kumar <sumitstop@gmail.com> wrote:
> > > Hi Nate,
> > > Thanks.
> > > My understanding about this was wrong :D I will order one adapter.
> > > Meanwhile, I tried your suggestion, it is still giving overruns.
> > > I have attached the screenshots of my config, can you please verify.
> > >
> > >
> > >
> > >
> > >
> > > On Fri, 30 Aug 2019 at 19:12, Nate Temple <nate.temple@ettus.com> wrote:
> > > > Hi Sumit,
> > > >
> > > > Are you using a 1Gb transport to the X310?
> > > >
> > > > The max data rate a 1Gb link can handle is ~25 MS/s @ sc16 OTW. With the two channels at 20 MS/s you're over this limit and would need to use 10Gb. If your laptop has a TB3/USB-C port, there are several TB3 to 10Gb adapters available.
> > > >
> > > >
> > > > Another observation -- if you switch the output type of the UHD Source block to be Complex int16 and then set your file sinks to have the data type Ints, you will cut the data rate in half that is being written to disk (complex 16bit Ints vs complex 32 bit floats).
> > > >
> > > > Regards,
> > > > Nate Temple
> > > >
> > > >
> > > > On Fri, Aug 30, 2019 at 9:59 AM sumit kumar <sumitstop@gmail.com> wrote:
> > > > > Hi,
> > > > > I am trying to capture RF data thru X310 from 2 channels and writing them to file using GNU Radio. But when I use a sampling rate of 20 MHz, packets start dropping badly.
> > > > >
> > > > > I have a very decent Laptop i7 8th Gen, SSD, 16 gb RAM. I also observed the CPU performance, it does not look stressed at all. I mean, none of the cores were reaching anywhere near to even 50%.
> > > > > Am I doing something wrong? For 10MHz sampling rate it is good, no overruns.
> > > > > I have attached my flowgraph, and the cpu performance screenshot.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Regards
> > > > > --
> > > > > Sumit Kumar
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Discuss-gnuradio mailing list
> > > > > Discuss-gnuradio@gnu.org
> > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > >
> > > --
> > > Sumit Kumar
> > >
> > >
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Expensive file write operation

Hi Nate, 

Thanks. 

My understanding about this was wrong :D I will order one adapter. 

Meanwhile, I tried your suggestion, it is still giving overruns. 

I have attached the screenshots of my config, can you please verify. 

On Fri, 30 Aug 2019 at 19:12, Nate Temple <nate.temple@ettus.com> wrote:

Hi Sumit,

Are you using a 1Gb transport to the X310?

The max data rate a 1Gb link can handle is ~25 MS/s @ sc16 OTW. With the two channels at 20 MS/s you're over this limit and would need to use 10Gb. If your laptop has a TB3/USB-C port, there are several TB3 to 10Gb adapters available.


Another observation -- if you switch the output type of the UHD Source block to be Complex int16 and then set your file sinks to have the data type Ints, you will cut the data rate in half that is being written to disk (complex 16bit Ints vs complex 32 bit floats).

Regards,
Nate Temple

On Fri, Aug 30, 2019 at 9:59 AM sumit kumar <sumitstop@gmail.com> wrote:

Hi, 

I am trying to capture RF data thru X310 from 2 channels and writing them to file using GNU Radio. But when I use a sampling rate of 20 MHz, packets start dropping badly. 

I have a very decent Laptop i7 8th Gen, SSD, 16 gb RAM. I also observed the CPU performance, it does not look stressed at all. I mean, none of the cores were reaching anywhere near to even 50%. 

Am I doing something wrong? For 10MHz sampling rate it is good, no overruns. 

I have attached my flowgraph, and the cpu performance screenshot. 

Regards

--

Sumit Kumar

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

--

Sumit Kumar

Re: [Discuss-gnuradio] Expensive file write operation

Hi Sumit,

Are you using a 1Gb transport to the X310?

The max data rate a 1Gb link can handle is ~25 MS/s @ sc16 OTW. With the two channels at 20 MS/s you're over this limit and would need to use 10Gb. If your laptop has a TB3/USB-C port, there are several TB3 to 10Gb adapters available.


Another observation -- if you switch the output type of the UHD Source block to be Complex int16 and then set your file sinks to have the data type Ints, you will cut the data rate in half that is being written to disk (complex 16bit Ints vs complex 32 bit floats).

Regards,
Nate Temple

On Fri, Aug 30, 2019 at 9:59 AM sumit kumar <sumitstop@gmail.com> wrote:

Hi, 

I am trying to capture RF data thru X310 from 2 channels and writing them to file using GNU Radio. But when I use a sampling rate of 20 MHz, packets start dropping badly. 

I have a very decent Laptop i7 8th Gen, SSD, 16 gb RAM. I also observed the CPU performance, it does not look stressed at all. I mean, none of the cores were reaching anywhere near to even 50%. 

Am I doing something wrong? For 10MHz sampling rate it is good, no overruns. 

I have attached my flowgraph, and the cpu performance screenshot. 

Regards

--

Sumit Kumar

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

[Discuss-gnuradio] Expensive file write operation

Hi, 

I am trying to capture RF data thru X310 from 2 channels and writing them to file using GNU Radio. But when I use a sampling rate of 20 MHz, packets start dropping badly. 

I have a very decent Laptop i7 8th Gen, SSD, 16 gb RAM. I also observed the CPU performance, it does not look stressed at all. I mean, none of the cores were reaching anywhere near to even 50%. 

Am I doing something wrong? For 10MHz sampling rate it is good, no overruns. 

I have attached my flowgraph, and the cpu performance screenshot. 

Regards

--

Sumit Kumar

[Discuss-gnuradio] Phase Align two RFNoC Radio Blocks in GRC

Hello together,

I am trying to transmit one complex cosine from both TX - Antenna of my
USRP-x310 with two UBX-160 Daugtherboards. I am transmitting a cosine with
the frequency of 100 kHz and the center frequency of my RFNoC Radio Blocks
is 2.45 GHz. So basically I see a peak at 2.45 Ghz + 100 kHz at my
spectrum analyzer (plus the lo leakage at 2.45 GHz). Additionally I
receive the spectrum on another x310.

In the following link you can see my flowgraph in GRC:
https://ibb.co/7W6mTKf

As you can see i have two multiply blocks to change the phase of the
complex cosines, the value of the multiply blocks are

> pow(math.e, 1j*phi*(math.pi/180)) and
> pow(math.e, 1j*psi*(math.pi/180)).

I can change phi and psi with a qt gui range slider. Default value ist
multiplication by 1.

My goal with this setup was to check the MIMO capabilities of the USRP x310.
I calculated the Phase offset both transmitted waves should have at the
antenna of my spectrum analyzer. With my multiplication blocks I created
different phase offsets, thus causing destructive interference at the
receiving end (peak at analyzer is the smallest at this phase).

However most of the time when I start different runs of my flowgraph (or
when I power cycle the device) I always have to set a different phase
offset to see the destructive interference. To me it seems pretty random
which phase offset both transmitting path get even though i don't
understand why.

In another thread I read that maybe timed tuning will work for me but I
did not quite understand what that improves in particular nor who I use it
in my GRC generated python file. (Using the RFnoC Radio Blocks does not
make it easier by the way.) This is the link:

http://ettus.80997.x6.nabble.com/USRP-users-use-a-usrp-x310-as-MIMO-transmitter-daughterboard-synchronization-tt11642.html

Any ideas, suggestions and explanations on how to phase align the transmit
path of my (single) USRP x310 would be greatly appreciated!
(I posted to the USRP List too, but I think maybe it's more of a python
code fix and not HDL where you guys are better in..)

Best regards

Felix

P.S:

One last point if that helps: When I use the same setup with the USRP sink
block with two inputs the phase seems to be locked and does not change
with each new start of the flowgraph, even though i did not use timed
commands there. When I try to use the RFNoC Radio Block with two inputs it
does not work at all.

_______________________________________________
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

Hi Ron,

just because I think this might be interesting to people dealing with
really high rates:
The maximum size is typically limited by the size of mmap'able memory
that you can allocate; that depends on the circular buffer factory
used:
For the posix shared memory thing, I don't think anything is stopping
you from using "memory space size" order amounts of buffer.
For anonymous file-backed mmap'ed buffers, I'd expect that we haven't
addressed the possibility of using more than 32 bit addresses, so
somewhere around 2 GB you'd find your upper limit.

Best regards,
Marcus

On Fri, 2019-08-30 at 06:20 -0700, Ron Economos wrote:
> Just to put a number on this question, the DVB-T2 transmitter uses up to 16 Megabyte buffers between blocks. I'm not sure what the absolute maximum is, but 16 Megabytes should cover most applications.
> The DVB-T2 blocks use set_output_multiple() in conjunction with forecast() to allocate these large buffers.
> Ron
> On 8/28/19 11:46, Laura Arjona wrote:
> > Hello GNURadio community,
> >
> > Does anyone know what is the maximum number of input items that an Out Of Tree block can consume on each input stream?
> >
> > consume_each(consumed) --> what is the maximum value that the variable consumed can take?
> >
> > Thank you very much.
> >
> >
> > --
> > Laura Arjona
> > Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering
> >
> > Paul G. Allen School of Computer Science & Engineering
> > 185 E Stevens Way NE
> > University of Washington
> > Seattle, WA 98195-2350
> >
> >
> > _______________________________________________
> > 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] Maximum input items consumed on each input stream

Just to put a number on this question, the DVB-T2 transmitter uses up to 16 Megabyte buffers between blocks. I'm not sure what the absolute maximum is, but 16 Megabytes should cover most applications.

The DVB-T2 blocks use set_output_multiple() in conjunction with forecast() to allocate these large buffers.

Ron

On 8/28/19 11:46, Laura Arjona wrote:

Hello GNURadio community,

Does anyone know what is the maximum number of input items that an Out Of Tree block can consume on each input stream?

consume_each(consumed) --> what is the maximum value that the variable consumed can take?

Thank you very much.

--

Laura Arjona 

Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering

Paul G. Allen School of Computer Science & Engineering

185 E Stevens Way NE

University of Washington

Seattle, WA 98195-2350

_______________________________________________  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

Hi Laura - All of what's written already is basically correct. I'll add on minor tweak: "ninput_items" and "noutput_items", which are 2 of the arguments to the "work" or "general_work" method, define the maximum number of input and/or output items available to use or requested to produce; see the comments in the header for this method: < https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/include/gnuradio/block.h#L168 >. Which of these variables is used depends on the actual block type as already  noted: source, sink, sync, tagged_stream, etc ... for example for a source block -- one that does have inputs -- "ninput_items" is not used; for a sink block "noutput_items" is not used. For general blocks, "ninput_items" is as noted in the header: "number of input items available on each input stream", and "noutput_items" is "number of output items to write on each output stream" ... but note that both of these are maximums. The values of these variables generally varies during runtime -- or rather, it is not guaranteed that they will constant -- so, you can't do something like "always produce 100 items", because there might not be enough output buffer space. Hence you have to rely on the values of these variables to determine how to do "work", and needs to keep track of the number of items consumed during work (and then consume just that number). Hopefully this and the other replies provide enough information for you to figure out how to proceed. Cheers! - MLD

ps> It is -very- cool to have a neuroengineer and anesthesiologist using GR!

On Fri, Aug 30, 2019 at 6:27 AM Albin Stigö <albin.stigo@gmail.com> wrote:

Laura et al,

consume_each <= ninput_items.

If you need a larger buffer than you consume you can abuse the
scheduler slightly by set_relative_rate(1, some_min_input_items), this
is done in the stream to vector blocks for example. I do this in a
visualization sink where I need to produce FFTs with a certain
overlap.

// We need at least this number of points to do our job
m_input_length = std::max<int>(m_consume_each, m_fft_size);
// This is probably abusing the scheduler quite a bit
set_relative_rate(1, m_input_length);

Interesting to see you work in neuroengineering. I'm an
anesthesiologist and very interested these applications of gnuradio.


--Albin

On Fri, Aug 30, 2019 at 11:44 AM Marcus Müller <mmueller@gnuradio.org> wrote:
>
> Hi Laura,
>
> the buffer sizes are determined at flow graph startup based on the
> involved block's io signature, output multiples, alignment
> requirements, minimum and maximum buffer sizes, and the page size
> (which practically everywhere is 4kB).
>
> I think you're expecting the amount of items your block is presented
> with to be deterministic: it's simply not.
>
> It's a thing that depends on  the temporal execution of the signal
> processing flowgraph at run time. Thus, your work (or general_work)
> must always make sure it works within the boundaries of how many
> samples are supplied in that specific call, and how much output space
> is available at that point.
>
> I think
>
> https://www.gnuradio.org/blog/2017-01-05-buffers/
>
> might be of interest to you.
>
> Best regards,
> Marcus
>
> On Thu, 2019-08-29 at 14:27 -0700, Laura Arjona wrote:
> > Thank you very much Michael.
> >
> >  What are the I/O buffer sizes?
> >
> > * My block is a general block
> > * In my forecast: ninput_items_required[0] = noutput_items;
> > * In the general_work:  const gr_complex *in = (const gr_complex *)
> > input_items[0];
> >                                       float *out = (float *)
> > output_items[0];
> >
> > /*
> >      * The private constructor
> >      */
> >     decoder_impl::frame_decoder_impl(int sample_rate,std::vector<int>
> > output_sizes)
> >       : gr::block("decoder",
> >               gr::io_signature::make(1, 1, sizeof(gr_complex)),
> >               gr::io_signature::makev(2, 2, output_sizes)),
> >               s_rate(sample_rate)
> >     {
> >
> >
> >
> >
> > On Thu, Aug 29, 2019 at 5:41 AM Michael Dickens <
> > michael.dickens@ettus.com> wrote:
> > > Hi Laura - In the "work" or "general_work" method, there are
> > > arguments that contain the information you're looking for. These
> > > arguments are set depending on what type of block you're creating
> > > (source, sink, sync, tagged_stream, whatever), are influenced by
> > > what the "forecast()" method returns, and are constrained by the
> > > I/O buffer sizes. Sorry to be a little vague, but the answer is
> > > that the value of the variable "consumed" in your description is
> > > context dependent. Hope this is useful! - MLD
> > >
> > > On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona <arjonal@uw.edu>
> > > wrote:
> > > > Hello GNURadio community,
> > > >
> > > > Does anyone know what is the maximum number of input items that
> > > > an Out Of Tree block can consume on each input stream?
> > > >
> > > > consume_each(consumed) --> what is the maximum value that the
> > > > variable consumed can take?
> > > >
> > > > Thank you very much.
> > > >
> > > >
> > > > --
> > > > Laura Arjona
> > > > Washington Research Foundation Innovation Postdoctoral Fellow in
> > > > Neuroengineering
> > > >
> > > > Paul G. Allen School of Computer Science & Engineering
> > > > 185 E Stevens Way NE
> > > > University of Washington
> > > > Seattle, WA 98195-2350
> > > > _______________________________________________
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > >
> > > --
> > > Michael Dickens, Mac OS X Programmer
> > >
> > > Ettus Research Technical Support
> > >
> > > Email: support@ettus.com
> > >
> > > Web: http://www.ettus.com
> >
> >
> > _______________________________________________
> > 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

--

Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: support@ettus.com

Web: http://www.ettus.com

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

Laura et al,

consume_each <= ninput_items.

If you need a larger buffer than you consume you can abuse the
scheduler slightly by set_relative_rate(1, some_min_input_items), this
is done in the stream to vector blocks for example. I do this in a
visualization sink where I need to produce FFTs with a certain
overlap.

// We need at least this number of points to do our job
m_input_length = std::max<int>(m_consume_each, m_fft_size);
// This is probably abusing the scheduler quite a bit
set_relative_rate(1, m_input_length);

Interesting to see you work in neuroengineering. I'm an
anesthesiologist and very interested these applications of gnuradio.

--Albin

On Fri, Aug 30, 2019 at 11:44 AM Marcus Müller <mmueller@gnuradio.org> wrote:
>
> Hi Laura,
>
> the buffer sizes are determined at flow graph startup based on the
> involved block's io signature, output multiples, alignment
> requirements, minimum and maximum buffer sizes, and the page size
> (which practically everywhere is 4kB).
>
> I think you're expecting the amount of items your block is presented
> with to be deterministic: it's simply not.
>
> It's a thing that depends on the temporal execution of the signal
> processing flowgraph at run time. Thus, your work (or general_work)
> must always make sure it works within the boundaries of how many
> samples are supplied in that specific call, and how much output space
> is available at that point.
>
> I think
>
> https://www.gnuradio.org/blog/2017-01-05-buffers/
>
> might be of interest to you.
>
> Best regards,
> Marcus
>
> On Thu, 2019-08-29 at 14:27 -0700, Laura Arjona wrote:
> > Thank you very much Michael.
> >
> > What are the I/O buffer sizes?
> >
> > * My block is a general block
> > * In my forecast: ninput_items_required[0] = noutput_items;
> > * In the general_work: const gr_complex *in = (const gr_complex *)
> > input_items[0];
> > float *out = (float *)
> > output_items[0];
> >
> > /*
> > * The private constructor
> > */
> > decoder_impl::frame_decoder_impl(int sample_rate,std::vector<int>
> > output_sizes)
> > : gr::block("decoder",
> > gr::io_signature::make(1, 1, sizeof(gr_complex)),
> > gr::io_signature::makev(2, 2, output_sizes)),
> > s_rate(sample_rate)
> > {
> >
> >
> >
> >
> > On Thu, Aug 29, 2019 at 5:41 AM Michael Dickens <
> > michael.dickens@ettus.com> wrote:
> > > Hi Laura - In the "work" or "general_work" method, there are
> > > arguments that contain the information you're looking for. These
> > > arguments are set depending on what type of block you're creating
> > > (source, sink, sync, tagged_stream, whatever), are influenced by
> > > what the "forecast()" method returns, and are constrained by the
> > > I/O buffer sizes. Sorry to be a little vague, but the answer is
> > > that the value of the variable "consumed" in your description is
> > > context dependent. Hope this is useful! - MLD
> > >
> > > On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona <arjonal@uw.edu>
> > > wrote:
> > > > Hello GNURadio community,
> > > >
> > > > Does anyone know what is the maximum number of input items that
> > > > an Out Of Tree block can consume on each input stream?
> > > >
> > > > consume_each(consumed) --> what is the maximum value that the
> > > > variable consumed can take?
> > > >
> > > > Thank you very much.
> > > >
> > > >
> > > > --
> > > > Laura Arjona
> > > > Washington Research Foundation Innovation Postdoctoral Fellow in
> > > > Neuroengineering
> > > >
> > > > Paul G. Allen School of Computer Science & Engineering
> > > > 185 E Stevens Way NE
> > > > University of Washington
> > > > Seattle, WA 98195-2350
> > > > _______________________________________________
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > >
> > > --
> > > Michael Dickens, Mac OS X Programmer
> > >
> > > Ettus Research Technical Support
> > >
> > > Email: support@ettus.com
> > >
> > > Web: http://www.ettus.com
> >
> >
> > _______________________________________________
> > 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] Maximum input items consumed on each input stream

Hi Laura,

the buffer sizes are determined at flow graph startup based on the
involved block's io signature, output multiples, alignment
requirements, minimum and maximum buffer sizes, and the page size
(which practically everywhere is 4kB).

I think you're expecting the amount of items your block is presented
with to be deterministic: it's simply not.

It's a thing that depends on the temporal execution of the signal
processing flowgraph at run time. Thus, your work (or general_work)
must always make sure it works within the boundaries of how many
samples are supplied in that specific call, and how much output space
is available at that point.

I think

https://www.gnuradio.org/blog/2017-01-05-buffers/

might be of interest to you.

Best regards,
Marcus

On Thu, 2019-08-29 at 14:27 -0700, Laura Arjona wrote:
> Thank you very much Michael.
>
> What are the I/O buffer sizes?
>
> * My block is a general block
> * In my forecast: ninput_items_required[0] = noutput_items;
> * In the general_work: const gr_complex *in = (const gr_complex *)
> input_items[0];
> float *out = (float *)
> output_items[0];
>
> /*
> * The private constructor
> */
> decoder_impl::frame_decoder_impl(int sample_rate,std::vector<int>
> output_sizes)
> : gr::block("decoder",
> gr::io_signature::make(1, 1, sizeof(gr_complex)),
> gr::io_signature::makev(2, 2, output_sizes)),
> s_rate(sample_rate)
> {
>
>
>
>
> On Thu, Aug 29, 2019 at 5:41 AM Michael Dickens <
> michael.dickens@ettus.com> wrote:
> > Hi Laura - In the "work" or "general_work" method, there are
> > arguments that contain the information you're looking for. These
> > arguments are set depending on what type of block you're creating
> > (source, sink, sync, tagged_stream, whatever), are influenced by
> > what the "forecast()" method returns, and are constrained by the
> > I/O buffer sizes. Sorry to be a little vague, but the answer is
> > that the value of the variable "consumed" in your description is
> > context dependent. Hope this is useful! - MLD
> >
> > On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona <arjonal@uw.edu>
> > wrote:
> > > Hello GNURadio community,
> > >
> > > Does anyone know what is the maximum number of input items that
> > > an Out Of Tree block can consume on each input stream?
> > >
> > > consume_each(consumed) --> what is the maximum value that the
> > > variable consumed can take?
> > >
> > > Thank you very much.
> > >
> > >
> > > --
> > > Laura Arjona
> > > Washington Research Foundation Innovation Postdoctoral Fellow in
> > > Neuroengineering
> > >
> > > Paul G. Allen School of Computer Science & Engineering
> > > 185 E Stevens Way NE
> > > University of Washington
> > > Seattle, WA 98195-2350
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> > --
> > Michael Dickens, Mac OS X Programmer
> >
> > Ettus Research Technical Support
> >
> > Email: support@ettus.com
> >
> > Web: http://www.ettus.com
>
>
> _______________________________________________
> 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] Hiring Radio Enthusiasts at Astranis

Let me know if you're interested in building new radios for space! We're looking for both full time and interns with a background in digital communications. We actually flew an Ettus E310 about 18 months ago, but now we're building a couple SDRs of our own. Here's our website:

 https://www.astranis.com/  

A few things we're currently using gnuradio for:
1.  custom waveform and modem design for a low throughput, high reliability radio (for spacecraft control, telemetry, and ranging). The radio is custom, software defined hardware platform.
2. ultra wide band channelization, equalization, etc. for a high throughput, high reliability radio. The radio is also a fully custom, software defined hardware platform.
3. network modelling, optimization, and planning to maximize network capacity for a range of use cases around the globe.

A few things we're going to use gnuradio for in the slightly longer term (12+ months out),  
1. ultra high-rate DVB-S2x modem design

3. significantly expand and evolve our SDRs processing bandwidth and architecture

And much more...plenty of digital communications and signal processing work going forward!

If this sounds interesting to you, shoot me an email and apply online: https://www.astranis.com/  

Thanks,

Steve Joseph

Astranis

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

Thank you very much Michael.

 What are the I/O buffer sizes?

* My block is a general block

* In my forecast: ninput_items_required[0] = noutput_items;

* In the general_work:  const gr_complex *in = (const gr_complex *) input_items[0]; 

                                      float *out = (float *) output_items[0]; 

/*

     * The private constructor       */      decoder_impl::frame_decoder_impl(int sample_rate,std::vector<int> output_sizes)        : gr::block("decoder",                gr::io_signature::make(1, 1, sizeof(gr_complex)),                gr::io_signature::makev(2, 2, output_sizes)),                s_rate(sample_rate)      {  
      

On Thu, Aug 29, 2019 at 5:41 AM Michael Dickens <michael.dickens@ettus.com> wrote:

Hi Laura - In the "work" or "general_work" method, there are arguments that contain the information you're looking for. These arguments are set depending on what type of block you're creating (source, sink, sync, tagged_stream, whatever), are influenced by what the "forecast()" method returns, and are constrained by the I/O buffer sizes. Sorry to be a little vague, but the answer is that the value of the variable "consumed" in your description is context dependent. Hope this is useful! - MLD

On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona <arjonal@uw.edu> wrote:

Hello GNURadio community,

Does anyone know what is the maximum number of input items that an Out Of Tree block can consume on each input stream?

consume_each(consumed) --> what is the maximum value that the variable consumed can take?

Thank you very much.

--

Laura Arjona 

Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering

Paul G. Allen School of Computer Science & Engineering

185 E Stevens Way NE

University of Washington

Seattle, WA 98195-2350

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

--

Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: support@ettus.com

Web: http://www.ettus.com

--

Laura Arjona 

Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering

Paul G. Allen School of Computer Science & Engineering

185 E Stevens Way NE

University of Washington

Seattle, WA 98195-2350

Re: [Discuss-gnuradio] Do we really need logging in GNU Radio?

Hi,

> > during the last congress (35c3) we have been talking about
> > the logging in GNU Radio. I was not thinking about this much,
> > until the recent discussion with another GNU Radio developer
> > at the CCCamp 2019 (unfortunately, I forgot his name, sorry).

I plead guilty. It was me.

> > Instead of printing directly to stderr (or anywhere else),
> > we can define a value-string array of possible events:
> >
> > enum gr_audio_event_t {
> > GR_AUDIO_EV_OVERRUN,
> > GR_AUDIO_EV_UNDERRUN,
> > GR_AUDIO_EV_FOO_BAR,
> > /* other events... */
> > };
> >
> > struct value_string {
> > unsigned int value;
> > const char *string;
> > } gr_audio_events[] = {
> > { GR_AUDIO_EV_OVERRUN, "Buffer overrun" },
> > { GR_AUDIO_EV_UNDERRUN, "Buffer underrun" },
> > { GR_AUDIO_EV_FOO_BAR, "Pretty description" },
> > /* other events... */
> > { 0, NULL }
> > };
> >
> > and give a possibility to the API user to subscribe either to
> > some of the events, or to all of them, so logging can be done
> > by the user itself, if needed. For GUI applications, the
> > corresponding part of UI can be updated instead.

This idea was especially valuable as blocks/objects/modules could keep
the logging messages in a binary format. Meaning that for each
event/block there could be a struct which contains information and
instead of serializing/stringifying every event logged the information
could stay in a binary/original format until it really needs to be
converted to a string. (Which is actually how the python logging
library handles string formating as well).

I thought about something like passing a
"event_severity, event_component, event_data_t, event_data_fmt" with
the last argument being a function pointer which can convert
event_data_t to string. For simple logging messages with static content
this could just be a static string, but for dynamic content this could
convert all sorts of information to a printable string (if needed).

Obviously I'm not going to implement this, just my 2 cents where this
idea originated.

Cheers
Andrej

_______________________________________________
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

Hi Laura - In the "work" or "general_work" method, there are arguments that contain the information you're looking for. These arguments are set depending on what type of block you're creating (source, sink, sync, tagged_stream, whatever), are influenced by what the "forecast()" method returns, and are constrained by the I/O buffer sizes. Sorry to be a little vague, but the answer is that the value of the variable "consumed" in your description is context dependent. Hope this is useful! - MLD

On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona <arjonal@uw.edu> wrote:

Hello GNURadio community,

Does anyone know what is the maximum number of input items that an Out Of Tree block can consume on each input stream?

consume_each(consumed) --> what is the maximum value that the variable consumed can take?

Thank you very much.

--

Laura Arjona 

Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering

Paul G. Allen School of Computer Science & Engineering

185 E Stevens Way NE

University of Washington

Seattle, WA 98195-2350

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

--

Michael Dickens, Mac OS X Programmer

Ettus Research Technical Support

Email: support@ettus.com

Web: http://www.ettus.com

Re: [Discuss-gnuradio] Do we really need logging in GNU Radio?

Hey Vadim,

nice!
So, just writing without much of a filter:

1. Yes. GNU Radio should be a non-intrusive library. Stuff being
printed directly to stdout is a bad idea and we need to get away from
that.
2. Well, GNU Radio is used to construct pretty complex applications,
which leads to potentially a lot of log messages that are only of
interest within the GNU Radio "part" of an application that uses GNU
Radio as library (for example: Info that a buffer of a certain size was
allocated during flow graph startup), and others that are relevant to
some "business logic" of an application (e.g. network connection
dropped).
So, I think GNU Radio does need an internal logging mechanism, BUT:
That needs to be something that the application using GNU Radio can
selectively "subscribe" to.

So, what I'd say is we should get the following:

* Good GNU Radio-centralized logging, because it's such a common
requirement
* Easy ways to attach a callback to a filter on that centralized
logging instance.

The way to do that filtering could indeed be through some kind of enum
categorization. Logging frameworks do that – typically, there's
categories of severity (trace, debug, info, warning, critical, fatal or
similar). I think a string "component" and a matching filter wouldn't
be so bad a choice for a callback subscriber?

Needn't be a callback, by the way. Could also be a ZMQ sub socket.

Best regards,
Marcus

On Thu, 2019-08-29 at 00:11 +0200, Vadim Yanitskiy wrote:
> Hello Marcus and GNU Radio community,
>
> during the last congress (35c3) we have been talking about
> the logging in GNU Radio. I was not thinking about this much,
> until the recent discussion with another GNU Radio developer
> at the CCCamp 2019 (unfortunately, I forgot his name, sorry).
>
> That developer shared an interesting opinion that GNU Radio
> should be considered as a library, thus it should not do any
> logging itself. And then I came up with the following idea:
>
> What if a GNU Radio block could have a set of events that are
> being generated in some situations? Let's just look at the
> Audio Source and Sink (ALSA) blocks. In case of a buffer
> overrun / underrun, we do print magic 'aO' / 'aU' symbols.
> That's how we currently signal that something has happened.
>
> Instead of printing directly to stderr (or anywhere else),
> we can define a value-string array of possible events:
>
> enum gr_audio_event_t {
> GR_AUDIO_EV_OVERRUN,
> GR_AUDIO_EV_UNDERRUN,
> GR_AUDIO_EV_FOO_BAR,
> /* other events... */
> };
>
> struct value_string {
> unsigned int value;
> const char *string;
> } gr_audio_events[] = {
> { GR_AUDIO_EV_OVERRUN, "Buffer overrun" },
> { GR_AUDIO_EV_UNDERRUN, "Buffer underrun" },
> { GR_AUDIO_EV_FOO_BAR, "Pretty description" },
> /* other events... */
> { 0, NULL }
> };
>
> and give a possibility to the API user to subscribe either to
> some of the events, or to all of them, so logging can be done
> by the user itself, if needed. For GUI applications, the
> corresponding part of UI can be updated instead.
>
> Other blocks, such as TCP Source and Sink, could also generate
> some potentially interesting events, such as connection status
> (server got a new connection, client has lost connection, etc.).
>
> I am not going to work on it, this is just an idea, which may
> probably look interesting to some developers / users too.
>
> With best regards,
> Vadim Yanitskiy.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Do we really need logging in GNU Radio?

Hello Marcus and GNU Radio community,

during the last congress (35c3) we have been talking about
the logging in GNU Radio. I was not thinking about this much,
until the recent discussion with another GNU Radio developer
at the CCCamp 2019 (unfortunately, I forgot his name, sorry).

That developer shared an interesting opinion that GNU Radio
should be considered as a library, thus it should not do any
logging itself. And then I came up with the following idea:

What if a GNU Radio block could have a set of events that are
being generated in some situations? Let's just look at the
Audio Source and Sink (ALSA) blocks. In case of a buffer
overrun / underrun, we do print magic 'aO' / 'aU' symbols.
That's how we currently signal that something has happened.

Instead of printing directly to stderr (or anywhere else),
we can define a value-string array of possible events:

enum gr_audio_event_t {
GR_AUDIO_EV_OVERRUN,
GR_AUDIO_EV_UNDERRUN,
GR_AUDIO_EV_FOO_BAR,
/* other events... */
};

struct value_string {
unsigned int value;
const char *string;
} gr_audio_events[] = {
{ GR_AUDIO_EV_OVERRUN, "Buffer overrun" },
{ GR_AUDIO_EV_UNDERRUN, "Buffer underrun" },
{ GR_AUDIO_EV_FOO_BAR, "Pretty description" },
/* other events... */
{ 0, NULL }
};

and give a possibility to the API user to subscribe either to
some of the events, or to all of them, so logging can be done
by the user itself, if needed. For GUI applications, the
corresponding part of UI can be updated instead.

Other blocks, such as TCP Source and Sink, could also generate
some potentially interesting events, such as connection status
(server got a new connection, client has lost connection, etc.).

I am not going to work on it, this is just an idea, which may
probably look interesting to some developers / users too.

With best regards,
Vadim Yanitskiy.

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

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

Hello GNURadio community,

Does anyone know what is the maximum number of input items that an Out Of Tree block can consume on each input stream?

consume_each(consumed) --> what is the maximum value that the variable consumed can take?

Thank you very much.

--

Laura Arjona 

Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering

Paul G. Allen School of Computer Science & Engineering

185 E Stevens Way NE

University of Washington

Seattle, WA 98195-2350

Re: [Discuss-gnuradio] Remotely controlling a GNURadio flowgraph via LAN

Chaps - this is great. I knew there was a way to do it. I would classify my python skills as "above script kiddie, but not all the way to novice"!

I understand what the proposed solutions are and i can comprehend what is needed to do it, but i don't have experience of implementation in code so therefore i apologise for having to ask for a little further help. I have read up on XMLRPC and understand the premise, but i think a lot of perseverance and trial and error will be necessary to make it work with my current skills. As i would be keen to make progress within a reasonable amount of time, any example code / structure would be most welcome - as i think my immediate goal to be able to control the parameters is very achievable, but without a guiding hand i may get a bit lost.

Really appreciate the help. :)

On Fri, 9 Aug 2019 at 15:53, Albin Stigö <albin.stigo@gmail.com> wrote:

You could implement your flowgraph in python and then use some python library for rpc and write a thin layer between...

You can also implement a flowgraph in C++.

I'm currently playing around with RPC over DBUS (only control, no data) for an application I'm writing in C++.

--Albin

On Fri, Aug 9, 2019, 10:35 Müller, Marcus (CEL) <mueller@kit.edu> wrote:

Hi Alex,

we do have two approaches for that

1. the XMLRPC thing, which is a python-world block that basically would
allow you to do the same you can do with e.g. a Qt GUI Range slider
(i.e. change Python variables at runtime)
2. Ctrlport and the thrift backend, the latter of which is notoriously
hard to get right.

I **really** think RPC is big in GNU Radio's future; we'll work on that
fundamentally. The problem is you're trying to solve a technical
challenge now, not then.

So, check out the XMLRPC, see if it suits you.

If it doesn't: What I'd recommend is to

1. use GRC to construct your flow graph as desired, assuming you're
doing that so far. Hint: if you use "Parameter" blocks instead of
"Variable" blocks, you get arguments to your top block's constructor)
2. Take the resulting python file, and use it as a Python module
(rather than running it as executable itself), containing a class named
like the "id" you set in the options block (the instance of
gr.top_block).
3. Write a simple application that imports that module, and modifies
the state of the top block (see the "main" function at the end of the
generated Python file) as dictated through RPC from your receiving end.

For 3: I do like zeroMQ, it has good Python integration and for your
application, the REQuest/REPly socket pattern would probably work very
well. You can encode RPC commands however you like, for example simple
JSON like {"tune", [2.4e9, 1e6]} or so.

Or, you can directly use a python RPC thing. I've not personally tried
that, but zerorpc.io looks fine for this kind of thing. Quite possible,
all you'd need to build on the Pi would be

#!/usr/bin/env python
import zerorpc
import myfg #replace with the generated .py

server = zerorpc.Server(myfg.myfg(sensible_arguments_if_any))
server.bind("tcp://0.0.0.0:1337") #bind to all interaces on port 1337

# could be tcp://127.0.0.1:1337 instead, if you're doing e.g. port
forwarding through `ssh -R 127.0.0.1:1337:1337!
# There's even ZMQ brokers and stuff, but that'd lead too far.
s.run()


And locally, you could try

import zerorpc
client = zerorpc.Client()
client.connect("tcp://yourPisAdddress:1337")
client.start()
client.set_samp_rate(4e6) #or whatever methods your top block has

Best regards,
Marcus

On Thu, 2019-08-08 at 23:16 +0100, Alex Pane wrote:
> Hi,
>
> I have created a simple tcp based iq stream using ZMQ blocks to use a HackRF remotely over an ethernet network.
>
> I have a linux computer (Raspberry Pi) connected to the HackRF running GNURadio. The HackRF source is connected to a ZMQ sink that transmits the packets to a receiving linux PC running GNURadio - where a ZMQ source connected to a QT sink for visualising the IQ signal stream.
>
> This works fine for a fixed frequency, sample rate and fft size etc, however my problem is that i want to be able to change those parameters from the receiving PC.
>
> Despite much research, i have been unable to find a way to change the parameters of the remote flowgraph (client) from the receiving display end (server).
>
> Is there a way to natively perform this operation within GNURadio and can someone provide guidance on how to setup a flowgraph to achieve this? Or is there some additional OOT block or custom python block i would need to create to do this.
>
> Thanks
>
> Alex
> _______________________________________________
> 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