Re: [Discuss-gnuradio] Multiple Inputs in Tagged Stream Block
Hi Martin and everyone, I've pinpointed what causes this error to occur with 3 inputs, but not occur with just 1 input. > gr::log :FATAL: geese_vcvc0 - Missing a required length tag on port 1 at > item #0 > thread[thread-per-block[46]: ]: Missing length tag. The culprit seems to be the following block of code inside my geese_vcvc_impl.cc file. I have it in my code right now because I based my block on ofdm_frame_equalizer.cc. I gather that it parses length of tags, and but seems to only do so for one input? Unfortunately I am unsure how to exactly interpret what it is doing. Martin, I notice you've worked on the ofdm_frame_equalizer block before--could you please help me go through what this piece of code does, and how I could change it to be compatible with a block with multiple inputs. I'm not thoroughly familiar with c++, and also am not sure about the particular purposes of variables here, or what the specific characteristics of "tags" vector are. *My goal is to do something similar to add two equalized input tagged streams together, and output the sum tagged stream, while also propagating tags through for tag debug.* *I would tremendously appreciate if you could briefly walk me through the following lines. Is this code necessary for tag propagation, or can I do without it? I don't get the error if this code is commented out.* On Fri, Apr 22, 2016 at 12:15 PM, Jingyi Sun <sunjing...@gmail.com> wrote: > Hi Martin, Andrej and everyone, > > Revision on my last email: I found out why my out-of-tree copy of > tagged_stream_mux wasn't working and fixed the problem--it was a bug with > having the wrong variable name input in the blockt after everything was > built. My copy now works like the original tagged_stream_mux does! > > So I will work on slowly modifying this copy of tagged_stream_mux to look > like what I want until something breaks, and then update you guys on that. > Hopefully that will help! > > Thanks again for all your help!! > > Best, > Jenny > > On Thu, Apr 21, 2016 at 2:37 PM, Jingyi Sun <sunjing...@gmail.com> wrote: > >> Hi Martin, >> >> I did more tests, including* trying to recreate tagged_stream_mux* as an >> out-of-tree block. My block is called mux, but everything else (.cc, .c, >> .xml), are exactly the same. I copied and pasted everything from github, >> minus the name. >> >> *It gives me the same error. * >> >> I suspect the source code that my installed binary version of GNU Radio >> is based on is different from the one used to originally create >> tagged_stream_mux block that comes with GNU Radio. >> >> Do you know if there is a specific person I can contact who would know >> about tagged_stream_block source code? Or do you think there's something >> else I haven't thought of. >> >> I'm not sure what else I can try right now, and would be willing to try >> anything you (or anyone else) might have to suggest. >> >> Thanks, >> Jenny >> >> >> On Thu, Apr 21, 2016 at 2:02 PM, Martin Braun <martin.br...@ettus.com> >> wrote: >> >>> On 04/20/2016 04:48 PM, Jingyi Sun wrote: >>> > tagged_stream_mux works when substituted for my block, so I think all >>> of >>> > my inputs are tagged streams. Also, my inputs are coming from the >>> > outputs of OFDM_frame_equalizer, which I think propagates tagged >>> streams? >>> >>> Yes. >>> >>> M >>> >>> > I think it's an error somewhere in the code, but the changes I >>> mentioned >>> > are the only changes I made between the block working and the block not >>> > working. >>> > >>> > My code is based on OFDM_frame_equalizer, but without the actual signal >>> > processing part. I will fill in my own signal processing after I know I >>> > can at least pass one out of three inputs along so that the outputs are >>> > the same as if this new block were bypassed. >>> > >>> > >>> > >>> > >>> > On Wed, Apr 20, 2016 at 6:24 PM, Martin Braun <martin.br...@ettus.com >>> > <mailto:martin.br...@ettus.com>> wrote: >>> > >>> > The tagged_stream_mux is an example of this kind of block. As >>> Andrej >>> > points out, you need to make sure every input signal is actually a >>> > tagged stream. >>> > >>> > Cheers, >>> > M >>> > >>> > On 04/20/2016 03:12 PM, Andrej Rode wrote: >>> > > Hello Jenny, >>> > > >>> > > I
Re: [Discuss-gnuradio] Multiple Inputs in Tagged Stream Block
Hi Martin, Andrej and everyone, Revision on my last email: I found out why my out-of-tree copy of tagged_stream_mux wasn't working and fixed the problem--it was a bug with having the wrong variable name input in the blockt after everything was built. My copy now works like the original tagged_stream_mux does! So I will work on slowly modifying this copy of tagged_stream_mux to look like what I want until something breaks, and then update you guys on that. Hopefully that will help! Thanks again for all your help!! Best, Jenny On Thu, Apr 21, 2016 at 2:37 PM, Jingyi Sun <sunjing...@gmail.com> wrote: > Hi Martin, > > I did more tests, including* trying to recreate tagged_stream_mux* as an > out-of-tree block. My block is called mux, but everything else (.cc, .c, > .xml), are exactly the same. I copied and pasted everything from github, > minus the name. > > *It gives me the same error. * > > I suspect the source code that my installed binary version of GNU Radio is > based on is different from the one used to originally create > tagged_stream_mux block that comes with GNU Radio. > > Do you know if there is a specific person I can contact who would know > about tagged_stream_block source code? Or do you think there's something > else I haven't thought of. > > I'm not sure what else I can try right now, and would be willing to try > anything you (or anyone else) might have to suggest. > > Thanks, > Jenny > > > On Thu, Apr 21, 2016 at 2:02 PM, Martin Braun <martin.br...@ettus.com> > wrote: > >> On 04/20/2016 04:48 PM, Jingyi Sun wrote: >> > tagged_stream_mux works when substituted for my block, so I think all of >> > my inputs are tagged streams. Also, my inputs are coming from the >> > outputs of OFDM_frame_equalizer, which I think propagates tagged >> streams? >> >> Yes. >> >> M >> >> > I think it's an error somewhere in the code, but the changes I mentioned >> > are the only changes I made between the block working and the block not >> > working. >> > >> > My code is based on OFDM_frame_equalizer, but without the actual signal >> > processing part. I will fill in my own signal processing after I know I >> > can at least pass one out of three inputs along so that the outputs are >> > the same as if this new block were bypassed. >> > >> > >> > >> > >> > On Wed, Apr 20, 2016 at 6:24 PM, Martin Braun <martin.br...@ettus.com >> > <mailto:martin.br...@ettus.com>> wrote: >> > >> > The tagged_stream_mux is an example of this kind of block. As Andrej >> > points out, you need to make sure every input signal is actually a >> > tagged stream. >> > >> > Cheers, >> > M >> > >> > On 04/20/2016 03:12 PM, Andrej Rode wrote: >> > > Hello Jenny, >> > > >> > > I can try to help you, but I'm not quite sure if I am right. If I >> > am wrong I >> > > will be corrected soon. >> > > >> > >>>> Generating: "/home/jenny/Tutorials/rx_ofdm.py" >> > >>>> Executing: "/home/jenny/Tutorials/rx_ofdm.py" >> > >>>> Using Volk machine: sse4_2_64_orc >> > >>>> gr::log :FATAL: geese_vcvc0 - Missing a required length tag on >> > port 1 at >> > >>>> item #0 >> > >>>> thread[thread-per-block[46]: ]: Missing >> > length tag. >> > > >> > > This error tells you that your block is missing a length tag in >> > one of his >> > > inputs. A Stream Tag on the first sample is a requirement for a >> > tagged stream >> > > block. This Stream Tag has to provide information about how much >> > input data >> > > your block has to process. >> > > I assume you don't have an tagged stream on each of your inputs >> > and this >> > > causes a problem for your tagged stream block. >> > > >> > > Best you provide a screenshot of your example flowgraph (the >> > relevant parts). >> > > Based on the error it is nothing inside of your block but the way >> > you are >> > > trying to feed it with samples. >> > > >> > > Best Regards, >> > > Andrej >> > > >> > > >> > > >> > > ___ >> > > Discuss-gnuradio mailing list >> > > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > >> > >> > >> > >> > ___ >> > Discuss-gnuradio mailing list >> > Discuss-gnuradio@gnu.org <mailto: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] Multiple Inputs in Tagged Stream Block
Hi Martin, I did more tests, including* trying to recreate tagged_stream_mux* as an out-of-tree block. My block is called mux, but everything else (.cc, .c, .xml), are exactly the same. I copied and pasted everything from github, minus the name. *It gives me the same error. * I suspect the source code that my installed binary version of GNU Radio is based on is different from the one used to originally create tagged_stream_mux block that comes with GNU Radio. Do you know if there is a specific person I can contact who would know about tagged_stream_block source code? Or do you think there's something else I haven't thought of. I'm not sure what else I can try right now, and would be willing to try anything you (or anyone else) might have to suggest. Thanks, Jenny On Thu, Apr 21, 2016 at 2:02 PM, Martin Braun <martin.br...@ettus.com> wrote: > On 04/20/2016 04:48 PM, Jingyi Sun wrote: > > tagged_stream_mux works when substituted for my block, so I think all of > > my inputs are tagged streams. Also, my inputs are coming from the > > outputs of OFDM_frame_equalizer, which I think propagates tagged streams? > > Yes. > > M > > > I think it's an error somewhere in the code, but the changes I mentioned > > are the only changes I made between the block working and the block not > > working. > > > > My code is based on OFDM_frame_equalizer, but without the actual signal > > processing part. I will fill in my own signal processing after I know I > > can at least pass one out of three inputs along so that the outputs are > > the same as if this new block were bypassed. > > > > > > > > > > On Wed, Apr 20, 2016 at 6:24 PM, Martin Braun <martin.br...@ettus.com > > <mailto:martin.br...@ettus.com>> wrote: > > > > The tagged_stream_mux is an example of this kind of block. As Andrej > > points out, you need to make sure every input signal is actually a > > tagged stream. > > > > Cheers, > > M > > > > On 04/20/2016 03:12 PM, Andrej Rode wrote: > > > Hello Jenny, > > > > > > I can try to help you, but I'm not quite sure if I am right. If I > > am wrong I > > > will be corrected soon. > > > > > >>>> Generating: "/home/jenny/Tutorials/rx_ofdm.py" > > >>>> Executing: "/home/jenny/Tutorials/rx_ofdm.py" > > >>>> Using Volk machine: sse4_2_64_orc > > >>>> gr::log :FATAL: geese_vcvc0 - Missing a required length tag on > > port 1 at > > >>>> item #0 > > >>>> thread[thread-per-block[46]: ]: Missing > > length tag. > > > > > > This error tells you that your block is missing a length tag in > > one of his > > > inputs. A Stream Tag on the first sample is a requirement for a > > tagged stream > > > block. This Stream Tag has to provide information about how much > > input data > > > your block has to process. > > > I assume you don't have an tagged stream on each of your inputs > > and this > > > causes a problem for your tagged stream block. > > > > > > Best you provide a screenshot of your example flowgraph (the > > relevant parts). > > > Based on the error it is nothing inside of your block but the way > > you are > > > trying to feed it with samples. > > > > > > Best Regards, > > > Andrej > > > > > > > > > > > > ___ > > > Discuss-gnuradio mailing list > > > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org <mailto: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] BER & constellation plot for OFDM transmit/receive
What do you mean by "hard-decision" equalizer, and "drop them down"? Thanks so much!! On Thu, Apr 21, 2016 at 2:01 PM, Martin Braun <martin.br...@ettus.com> wrote: > That's because the equalizer used is a hard-decision equalizer. You can > write your own equalizers and drop them down for better results; that's > something I've been meaning to do for a while, but haven't found the > time yet. > > Cheers, > M > > On 04/20/2016 09:56 PM, Jingyi Sun wrote: > > Hope pictures below give more context. Has anyone seen this happen > before? > > > > To reword the part of our question about constellation plots a little, > > does anyone know when the constellation block would output just four > > single points? > > > > The problem we’re currently facing is that the constellation plot does > > not even really show up -/there’s not even a giant blob to indicate > > noise/. Instead, we get only 4 points, one in each of the four locations > > you’d expect for a QPSK signal - but only those 4 points./It almost > > feels like the constellation plot stops triggering after these first > > four points/, and that’s why we don’t receive anymore data. *We’re using > > a free trigger on the positive slope, centered at 0, *which I feel > > should trigger at least something even if it’s just noise. We have also > > tried other trigger methods, which output either 4 points, 5 points (1 > > additional point in the center), or just 1 center point. > > > > > > > > > > > > > > On Mon, Apr 18, 2016 at 5:01 PM, Jingyi Sun <sunjing...@gmail.com > > <mailto:sunjing...@gmail.com>> wrote: > > > > We are not compensating for any lost packets, although we would be > > aware of them thanks to the packet number. Could you tell us if > > there’s a block to do this, or would we need a custom block? > > > > > > Also, could you tell us why the constellation diagram is not > > displaying properly? > > > > > > Thanks, > > > > Jenny > > > > > > > > On Mon, Apr 18, 2016 at 1:26 PM, Martin Braun > > <martin.br...@ettus.com <mailto:martin.br...@ettus.com>> wrote: > > > > Are you comparing the correct packets? E.g., if packets get > > lost, do you > > take that into account? > > > > M > > > > On 04/16/2016 02:38 PM, Jingyi Sun wrote: > > > Hi everyone, > > > > > > We are working on an experiment for a conference paper > deadline in two > > > weeks, and need to transmit and receive OFDM packets and want > to study > > > the constellation diagram and BER. > > > > > > I put together a flow graph consisting of an *OFDM transmitter > > block* > > > and an *unpacked OFDM receiver* based on the online example > > rx_ofdm.grc. > > > Here's how I'm trying to measure constellation diagram and BER: > > > > > > * I inserted a QT constellation sink right before the > > constellation > > > decoder on the payload IQ stream, but it does not seem to > output > > > anything meaningful. The plot just shows single, clean > points, which > > > I am pretty sure does not correspond to real data. I > suspect that > > > the plots are not triggering properly, but am not sure. > > > > > > * For BER, we tried several different configurations, and > > they mostly > > > give BER = 0.5 (i.e. random). Our leading theory is that > we're not > > > comparing the data at the correct points in the flow > graph. Any > > > suggestions as to what the BER inputs should be would be > helpful. > > > > > > We've been running some diagnostics that seem to eliminate our > > > communication channel as the problem: > > > > > > * We are transmitting the data over-the-air at 915 MHz using > > > two omnidirectional antennas, placed roughly 1 meter > apart. The > > > output spectra at the transmitter output and receiver > input are > > > attached - all signals are comfortably above the noise > floor. > > > * From the tag debug output, we see that the OFDM packet > > headers are > > > be
[Discuss-gnuradio] Multiple Inputs in Tagged Stream Block
Hello everyone,
I am trying to create an out-of-tree tagged stream block with multiple (3)
input ports. Am I coding the private constructor incorrectly, or is there
something else?
Here's my process:
First, I got the block to work with just one input port. Then, I added
additional inputs by changing the number of min and max inputs, as follows,
> : gr::tagged_stream_block("geese_vcvc",
> gr::io_signature::make(3, 3, sizeof(gr_complex) * fft_len),
> gr::io_signature::make(1, 1, sizeof(gr_complex) * fft_len), tsb_key),
add two more inputs in work, as follows,
const gr_complex *a = (const gr_complex *) input_items[0];
> const gr_complex *d = (const gr_complex *) input_items[1];
> const gr_complex *x = (const gr_complex *) input_items[2];
>
> gr_complex *out = (gr_complex *) output_items[0];
and finally change the xml file to add two more sinks.
Before these changes (highlighted in yellow), the block is able to run
without runtime errors. However, after these changes, I get the following
output:
Showing: "/home/jenny//Tutorials/rx_ofdm.grc"
> Generating: "/home/jenny/Tutorials/rx_ofdm.py"
> Executing: "/home/jenny/Tutorials/rx_ofdm.py"
> Using Volk machine: sse4_2_64_orc
> gr::log :FATAL: geese_vcvc0 - Missing a required length tag on port 1 at
> item #0
> thread[thread-per-block[46]: ]: Missing length tag.
Thanks,
Jenny
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BER & constellation plot for OFDM transmit/receive
We are not compensating for any lost packets, although we would be aware of them thanks to the packet number. Could you tell us if there’s a block to do this, or would we need a custom block? Also, could you tell us why the constellation diagram is not displaying properly? Thanks, Jenny On Mon, Apr 18, 2016 at 1:26 PM, Martin Braun <martin.br...@ettus.com> wrote: > Are you comparing the correct packets? E.g., if packets get lost, do you > take that into account? > > M > > On 04/16/2016 02:38 PM, Jingyi Sun wrote: > > Hi everyone, > > > > We are working on an experiment for a conference paper deadline in two > > weeks, and need to transmit and receive OFDM packets and want to study > > the constellation diagram and BER. > > > > I put together a flow graph consisting of an *OFDM transmitter block* > > and an *unpacked OFDM receiver* based on the online example rx_ofdm.grc. > > Here's how I'm trying to measure constellation diagram and BER: > > > > * I inserted a QT constellation sink right before the constellation > > decoder on the payload IQ stream, but it does not seem to output > > anything meaningful. The plot just shows single, clean points, which > > I am pretty sure does not correspond to real data. I suspect that > > the plots are not triggering properly, but am not sure. > > > > * For BER, we tried several different configurations, and they mostly > > give BER = 0.5 (i.e. random). Our leading theory is that we're not > > comparing the data at the correct points in the flow graph. Any > > suggestions as to what the BER inputs should be would be helpful. > > > > We've been running some diagnostics that seem to eliminate our > > communication channel as the problem: > > > > * We are transmitting the data over-the-air at 915 MHz using > > two omnidirectional antennas, placed roughly 1 meter apart. The > > output spectra at the transmitter output and receiver input are > > attached - all signals are comfortably above the noise floor. > > * From the tag debug output, we see that the OFDM packet headers are > > being received. For example, we can see when the packets are > > received, the packet numbers, as well as the channel estimation tap > > values. We take this to mean that we are receiving data > > successfully, and that our difficulties regarding BER and > > constellation diagram are something we're executing incorrectly in > > the software. > > > > > > The relevant annotated GRC block diagrams are attached. > > > > Thanks so much, > > Jenny > > > > > > ___ > > 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
[Discuss-gnuradio] OFDM tx rx error
Hi, I'm using the examples rx_ofdm.grc and tx_ofdm.grc together to transmit and receive packets over the air. Both work over a simulated channel, but when I actually transmit and receive over the air, I get the error: *"Detected a packet larger than max frame size (100 symbols)"* I saw the previous thread on this called "OFDM transmitter receiver" which goes as follows, but I don't really know what to make of this... I tried to run *sysctl kernel.shmmax *in terminal, but I got the message "No such file or directory". I'm also not sure what kernel.shmmax is. These are my parameters: fft length= 64 cyclic prefix = 16 packet length = 96 no. of occupied carriers = 53 no. of pilot carriers = 4 I'm very new to gnuradio, and any insights into this would be appreciated!! Thanks, Jenny PS sorry if this is redundant. I didn't get my email through the list so I'm assuming it didn't go through the first time. -- *From*: Martin Braun *Subject*: Re: [Discuss-gnuradio] OFDM transmitter receiver *Date*: Tue, 26 Aug 2014 11:10:53 +0200 *User-agent*: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 -- Try and not kill the context in a mailing list thread; these are also archived and are used by others for referral. Max frame size depends on max_output_buffer(). 80 symbols at a 64-sized FFT would be ~40kB... that doesn't seem unreasonable. Not sure if there's a problem here. I suggest you have a look at the buffer sizes to track down this problem. M On 08/25/2014 03:31 PM, Martin Braun wrote: >* What's your kernel.shmmax value? (run sysctl kernel.shmmax)* > >* M* > >* On 08/25/2014 12:47 PM, sreena p h wrote:* >*> Hi* >*> I used the ofdm transmitter receiver blocks to create a simple system as* >*> shown in the attachment. I used the system parameters as those used in* >*> the example transmitter and receiver grcs. Now I get error that* >*> 'Detected a packet larger than max frame size (80 symbols)'. I would* >*> like to know how the max frame size is set and should I add more* >*> information to the grc. * >*>* >*> My transmitter- receiver parameters* >*>* >*> fft length= 64* >*> cyclic prefix = 16* >*> packet length = 96* >*> no. of occupied carriers = 48* >*> no. of pilot carriers = 4* >*>* >*>* >*>* >*> ___* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM tx rx error
Hi, I'm using the examples rx_ofdm.grc and tx_ofdm.grc together to transmit and receive packets over the air. Both work over a simulated channel, but when I actually transmit and receive over the air, I get the error: *"Detected a packet larger than max frame size (100 symbols)"* I saw the previous thread on this called "OFDM transmitter receiver" which goes as follows, but I don't really know what to make of this... I tried to run *sysctl kernel.shmmax *in terminal, but I got the message "No such file or directory". I'm also not sure what kernel.shmmax is. These are my parameters: fft length= 64 cyclic prefix = 16 packet length = 96 no. of occupied carriers = 53 no. of pilot carriers = 4 I'm very new to gnuradio, and any insights into this would be appreciated!! Thanks, Jenny -- *From*: Martin Braun *Subject*: Re: [Discuss-gnuradio] OFDM transmitter receiver *Date*: Tue, 26 Aug 2014 11:10:53 +0200 *User-agent*: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 -- Try and not kill the context in a mailing list thread; these are also archived and are used by others for referral. Max frame size depends on max_output_buffer(). 80 symbols at a 64-sized FFT would be ~40kB... that doesn't seem unreasonable. Not sure if there's a problem here. I suggest you have a look at the buffer sizes to track down this problem. M On 08/25/2014 03:31 PM, Martin Braun wrote: >* What's your kernel.shmmax value? (run sysctl kernel.shmmax)* > >* M* > >* On 08/25/2014 12:47 PM, sreena p h wrote:* >*> Hi* >*> I used the ofdm transmitter receiver blocks to create a simple system as* >*> shown in the attachment. I used the system parameters as those used in* >*> the example transmitter and receiver grcs. Now I get error that* >*> 'Detected a packet larger than max frame size (80 symbols)'. I would* >*> like to know how the max frame size is set and should I add more* >*> information to the grc. * >*>* >*> My transmitter- receiver parameters* >*>* >*> fft length= 64* >*> cyclic prefix = 16* >*> packet length = 96* >*> no. of occupied carriers = 48* >*> no. of pilot carriers = 4* >*>* >*>* >*>* >*> ___* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
