Cross compile gnuradio in E312 error

[GNU Radio, the Free & Open-Source Toolkit for Software Radio]

Re: Packet Loopback Example Using USRP

[Jada Mariano Berenguer]

That makes sense. Thank you so much for all of your help!! It's much
appreciated and has helped me understand what's going on a lot better as
well.

On Sun, Jan 24, 2021 at 4:59 PM Jeff Long  wrote:

> You're not seeing anything on the gui sinks because they only show you
> periodic snapshots (except for gr-fosphor if you have that installed) and
> the bursts fall between the snapshots. Inspectrum lets you see every sample
> in a recorded file.
>
> I'm not going to have time to try out the RX part, but make sure the RF
> path is sane (attentuators, levels, verify using a File Sink or other
> method) and then build up the RX one piece at a time. You may have to learn
> about the internals of packet_rx, and use various debug blocks/gui sinks to
> figure out what's going on. GRC makes it look like you can drag-and-drop
> and make a radio.
>
> On Sun, Jan 24, 2021 at 6:39 PM Jada Mariano Berenguer 
> wrote:
>
>> Okay, so do the bursts of digital data mean that the USRP Sink is able to
>> successfully get the packet as input and transmit it?
>>
>> If so, when I run the packet_usrp.grc flowgraph, why do I not see the
>> USRP Source receive anything? For example, the graphs that represent the
>> USRP Source's output never change. I would expect it to change when it
>> receives a packet of data. Also, if the USRP source was receiving
>> something, wouldn't the Packet RX block decode the packet and print the
>> contents to the terminal using the Message Debug block?
>>
>> On Sun, Jan 24, 2021 at 2:04 PM Jeff Long  wrote:
>>
>>> Yes, that shows bursts of digital data, which is what your tx produces.
>>> Use a smaller FFT size to see more detail in the time domain.
>>>
>>> On Sun, Jan 24, 2021 at 4:44 PM Jada Mariano Berenguer 
>>> wrote:
>>>
 So, from my understanding you added a File Sink that took in the USRP
 Source's output to the packet_usrp_tx.grc flowgraph? I tried to recreate
 what you did and opened the file with Inspectrum and a screenshot of the
 results is attached. I'm not sure if this is what you got, or what it
 means. I may be saving it to the File Sink incorrectly, so I attached a
 screenshot of the File Sink parameters as well.

 Also, what do you mean by 'What happens if you ignore this and keep
 working' ? Because if I run the packet_usrp.grc flowgraph for a while and
 ignore the U's printing out, it doesn't give me the result that I expect.
 The result that I expect would be similar to the result when running the
 packet_loopback_hier.grc file.

 Thanks again for your continued help!

 On Sun, Jan 24, 2021 at 12:03 PM Jeff Long  wrote:

> Best I can tell (recording raw samples from the USRP Source to a File
> Sink, then viewing it with inspectrum), it works and the single 'U' per
> burst is spurious. The docs would lead you to believe you shouldn't see
> this. Nothing stands out as wrong in the GRCs. What happens if you ignore
> this and keep working?
>
> On Sun, Jan 24, 2021 at 1:41 PM Jada Mariano Berenguer <
> beren...@uci.edu> wrote:
>
>> Okay, thanks for the tip. Attached in this email is a flowgraph that
>> only does TX (packet_usrp_tx.grc). I'll continue to look into the problem
>> and see if I can find any solutions myself as well, but again I'm pretty
>> new to GNURadio and USRP. If anyone can help me figure out the problem,
>> it'd be greatly appreciated!! I've also attached the packet loopback
>> example using the USRP with both TX and RX (packet_usrp.grc), the 
>> original
>> packet loopback example without USRP (packet_loopback_hier.grc), and the
>> packet_tx and packet_rx flowgraphs as well.
>>
>> On Sat, Jan 23, 2021 at 4:36 AM Jeff Long 
>> wrote:
>>
>>> Recommend you find the simplest flowgraph that demonstrates this
>>> problem. For example, do TX only. Once you find that minimal case, post 
>>> the
>>> actual GRC file somewhere so someone can try it out. It's really 
>>> difficult
>>> to look through a bunch of parameters in a screenshot and try to guess
>>> what's happening, unless it's something really obvious.
>>>
>>> On Fri, Jan 22, 2021 at 9:24 PM Jada Mariano Berenguer <
>>> beren...@uci.edu> wrote:
>>>
 Hi again, I have a previous message thread regarding this problem,
 but I kept forgetting to 'reply all' to include the GNURadio email to 
 keep
 it on the thread and my questions got kind of disorganized, so I 
 wanted to
 start fresh with a new one and will make sure to reply all in the 
 future.

 So, I found a packet_loopback example (under the directory:
 examples/digital/packet) from this message thread
 
  and
 it says that I can replace the Channel Model block with the USRP 
 source 

Re: Packet Loopback Example Using USRP

[Jeff Long]

You're not seeing anything on the gui sinks because they only show you
periodic snapshots (except for gr-fosphor if you have that installed) and
the bursts fall between the snapshots. Inspectrum lets you see every sample
in a recorded file.

I'm not going to have time to try out the RX part, but make sure the RF
path is sane (attentuators, levels, verify using a File Sink or other
method) and then build up the RX one piece at a time. You may have to learn
about the internals of packet_rx, and use various debug blocks/gui sinks to
figure out what's going on. GRC makes it look like you can drag-and-drop
and make a radio.

On Sun, Jan 24, 2021 at 6:39 PM Jada Mariano Berenguer 
wrote:

> Okay, so do the bursts of digital data mean that the USRP Sink is able to
> successfully get the packet as input and transmit it?
>
> If so, when I run the packet_usrp.grc flowgraph, why do I not see the USRP
> Source receive anything? For example, the graphs that represent the USRP
> Source's output never change. I would expect it to change when it receives
> a packet of data. Also, if the USRP source was receiving something,
> wouldn't the Packet RX block decode the packet and print the contents to
> the terminal using the Message Debug block?
>
> On Sun, Jan 24, 2021 at 2:04 PM Jeff Long  wrote:
>
>> Yes, that shows bursts of digital data, which is what your tx produces.
>> Use a smaller FFT size to see more detail in the time domain.
>>
>> On Sun, Jan 24, 2021 at 4:44 PM Jada Mariano Berenguer 
>> wrote:
>>
>>> So, from my understanding you added a File Sink that took in the USRP
>>> Source's output to the packet_usrp_tx.grc flowgraph? I tried to recreate
>>> what you did and opened the file with Inspectrum and a screenshot of the
>>> results is attached. I'm not sure if this is what you got, or what it
>>> means. I may be saving it to the File Sink incorrectly, so I attached a
>>> screenshot of the File Sink parameters as well.
>>>
>>> Also, what do you mean by 'What happens if you ignore this and keep
>>> working' ? Because if I run the packet_usrp.grc flowgraph for a while and
>>> ignore the U's printing out, it doesn't give me the result that I expect.
>>> The result that I expect would be similar to the result when running the
>>> packet_loopback_hier.grc file.
>>>
>>> Thanks again for your continued help!
>>>
>>> On Sun, Jan 24, 2021 at 12:03 PM Jeff Long  wrote:
>>>
 Best I can tell (recording raw samples from the USRP Source to a File
 Sink, then viewing it with inspectrum), it works and the single 'U' per
 burst is spurious. The docs would lead you to believe you shouldn't see
 this. Nothing stands out as wrong in the GRCs. What happens if you ignore
 this and keep working?

 On Sun, Jan 24, 2021 at 1:41 PM Jada Mariano Berenguer <
 beren...@uci.edu> wrote:

> Okay, thanks for the tip. Attached in this email is a flowgraph that
> only does TX (packet_usrp_tx.grc). I'll continue to look into the problem
> and see if I can find any solutions myself as well, but again I'm pretty
> new to GNURadio and USRP. If anyone can help me figure out the problem,
> it'd be greatly appreciated!! I've also attached the packet loopback
> example using the USRP with both TX and RX (packet_usrp.grc), the original
> packet loopback example without USRP (packet_loopback_hier.grc), and the
> packet_tx and packet_rx flowgraphs as well.
>
> On Sat, Jan 23, 2021 at 4:36 AM Jeff Long  wrote:
>
>> Recommend you find the simplest flowgraph that demonstrates this
>> problem. For example, do TX only. Once you find that minimal case, post 
>> the
>> actual GRC file somewhere so someone can try it out. It's really 
>> difficult
>> to look through a bunch of parameters in a screenshot and try to guess
>> what's happening, unless it's something really obvious.
>>
>> On Fri, Jan 22, 2021 at 9:24 PM Jada Mariano Berenguer <
>> beren...@uci.edu> wrote:
>>
>>> Hi again, I have a previous message thread regarding this problem,
>>> but I kept forgetting to 'reply all' to include the GNURadio email to 
>>> keep
>>> it on the thread and my questions got kind of disorganized, so I wanted 
>>> to
>>> start fresh with a new one and will make sure to reply all in the 
>>> future.
>>>
>>> So, I found a packet_loopback example (under the directory:
>>> examples/digital/packet) from this message thread
>>> 
>>>  and
>>> it says that I can replace the Channel Model block with the USRP source 
>>> and
>>> sink blocks to try to send packets over the air (a screenshot of the
>>> original packet_loopback example and my modified packet_loopback 
>>> example is
>>> attached as well). This is exactly what I want to do, but I'm running 
>>> into
>>> some issues with the USRP sink.
>>>
>>> 

Re: Packet Loopback Example Using USRP

[Jada Mariano Berenguer]

Okay, so do the bursts of digital data mean that the USRP Sink is able to
successfully get the packet as input and transmit it?

If so, when I run the packet_usrp.grc flowgraph, why do I not see the USRP
Source receive anything? For example, the graphs that represent the USRP
Source's output never change. I would expect it to change when it receives
a packet of data. Also, if the USRP source was receiving something,
wouldn't the Packet RX block decode the packet and print the contents to
the terminal using the Message Debug block?

On Sun, Jan 24, 2021 at 2:04 PM Jeff Long  wrote:

> Yes, that shows bursts of digital data, which is what your tx produces.
> Use a smaller FFT size to see more detail in the time domain.
>
> On Sun, Jan 24, 2021 at 4:44 PM Jada Mariano Berenguer 
> wrote:
>
>> So, from my understanding you added a File Sink that took in the USRP
>> Source's output to the packet_usrp_tx.grc flowgraph? I tried to recreate
>> what you did and opened the file with Inspectrum and a screenshot of the
>> results is attached. I'm not sure if this is what you got, or what it
>> means. I may be saving it to the File Sink incorrectly, so I attached a
>> screenshot of the File Sink parameters as well.
>>
>> Also, what do you mean by 'What happens if you ignore this and keep
>> working' ? Because if I run the packet_usrp.grc flowgraph for a while and
>> ignore the U's printing out, it doesn't give me the result that I expect.
>> The result that I expect would be similar to the result when running the
>> packet_loopback_hier.grc file.
>>
>> Thanks again for your continued help!
>>
>> On Sun, Jan 24, 2021 at 12:03 PM Jeff Long  wrote:
>>
>>> Best I can tell (recording raw samples from the USRP Source to a File
>>> Sink, then viewing it with inspectrum), it works and the single 'U' per
>>> burst is spurious. The docs would lead you to believe you shouldn't see
>>> this. Nothing stands out as wrong in the GRCs. What happens if you ignore
>>> this and keep working?
>>>
>>> On Sun, Jan 24, 2021 at 1:41 PM Jada Mariano Berenguer 
>>> wrote:
>>>
 Okay, thanks for the tip. Attached in this email is a flowgraph that
 only does TX (packet_usrp_tx.grc). I'll continue to look into the problem
 and see if I can find any solutions myself as well, but again I'm pretty
 new to GNURadio and USRP. If anyone can help me figure out the problem,
 it'd be greatly appreciated!! I've also attached the packet loopback
 example using the USRP with both TX and RX (packet_usrp.grc), the original
 packet loopback example without USRP (packet_loopback_hier.grc), and the
 packet_tx and packet_rx flowgraphs as well.

 On Sat, Jan 23, 2021 at 4:36 AM Jeff Long  wrote:

> Recommend you find the simplest flowgraph that demonstrates this
> problem. For example, do TX only. Once you find that minimal case, post 
> the
> actual GRC file somewhere so someone can try it out. It's really difficult
> to look through a bunch of parameters in a screenshot and try to guess
> what's happening, unless it's something really obvious.
>
> On Fri, Jan 22, 2021 at 9:24 PM Jada Mariano Berenguer <
> beren...@uci.edu> wrote:
>
>> Hi again, I have a previous message thread regarding this problem,
>> but I kept forgetting to 'reply all' to include the GNURadio email to 
>> keep
>> it on the thread and my questions got kind of disorganized, so I wanted 
>> to
>> start fresh with a new one and will make sure to reply all in the future.
>>
>> So, I found a packet_loopback example (under the directory:
>> examples/digital/packet) from this message thread
>> 
>>  and
>> it says that I can replace the Channel Model block with the USRP source 
>> and
>> sink blocks to try to send packets over the air (a screenshot of the
>> original packet_loopback example and my modified packet_loopback example 
>> is
>> attached as well). This is exactly what I want to do, but I'm running 
>> into
>> some issues with the USRP sink.
>>
>> I believe the problem has to do with the way that the USRP sink is
>> receiving the packets. I believe it deals with 'bursty transmission
>> ', and so I specified
>> the USRP sink's 'TSB tag name' parameter to 'packet_len', which is what 
>> the
>> packet_tx block specifies as the length tag name (I've also attached a
>> screenshot of the packet_tx flowgraph). I confirmed that the tag name is
>> 'packet_len' by using the Tag Debug block.
>>
>> Also, I've attached a video link here
>> 
>> of what happens when I run the program. It seems like the USRP receives 
>> the
>> packet here and there because of the short 'bursts' shown on 

Re: Unable to add FMCOMMS5 from git library

[Rupak Paul]

Hi Marcus,

Thanks for your suggestion.
Actually I had my old projects on older version 3.7 on both Ubuntu and
Windows.

Will download new versions and try again. Thanks.

Regards,
Rupak




On Sun, Jan 24, 2021 at 11:58 PM Marcus Müller 
wrote:

> Hi Rupak,
>
> this makes no sense: ADI put a lot of effort into getting gr-iio to work
> with GNU Radio
> 3.8, and porting efforts to 3.9 are at least underway.
>
> It absolutely makes no sense to use GNU Radio 3.7 on a new project,
> especially since
> multiple of its dependencies have gone end-of-life. You can trivially
> upgrade to GNU Radio
> 3.8 using GNU Radio's own PPA, or from Ubuntu's own package repositories
> if you upgrade
> your Ubuntu 20.04.
>
> If you've already got working infrastructure based on GNU Radio 3.7, the
> situation is
> different: we do take a bit of caution to help 3.7 keep running on legacy
> systems. We are,
> however, not porting it to new platforms (which simply doesn't work due to
> the
> dependencies mentioned above), and I'd certainly recommend not starting a
> project with 3.7
> in 2021.
>
> Best regards,
> Marcus
>
> On 24.01.21 23:33, Rupak Paul wrote:
> > Hello there,
> > I am using Gnuradio v3.7 in linux 18.04. But I can't find FMCOMMS5 block
> in this version.
> > I tried to add it from github library using "git clone
> > https://github.com/analogdevicesinc/gr-iio.git
> > "
> > but didn't work either.
> >
> > Anybody please guide me, how to add it by using gr_modtool or from
> github library?
> >
> > --
> >
> >
> > Regards,
> > Rupak Paul
> >
>
>

-- 


Regards,
Rupak Paul

Re: Unable to add FMCOMMS5 from git library

[Marcus Müller]

Hi Rupak,

this makes no sense: ADI put a lot of effort into getting gr-iio to work with 
GNU Radio
3.8, and porting efforts to 3.9 are at least underway.

It absolutely makes no sense to use GNU Radio 3.7 on a new project, especially 
since
multiple of its dependencies have gone end-of-life. You can trivially upgrade 
to GNU Radio
3.8 using GNU Radio's own PPA, or from Ubuntu's own package repositories if you 
upgrade
your Ubuntu 20.04.

If you've already got working infrastructure based on GNU Radio 3.7, the 
situation is
different: we do take a bit of caution to help 3.7 keep running on legacy 
systems. We are,
however, not porting it to new platforms (which simply doesn't work due to the
dependencies mentioned above), and I'd certainly recommend not starting a 
project with 3.7
in 2021.

Best regards,
Marcus

On 24.01.21 23:33, Rupak Paul wrote:
> Hello there,
> I am using Gnuradio v3.7 in linux 18.04. But I can't find FMCOMMS5 block in 
> this version.
> I tried to add it from github library using "git clone
> https://github.com/analogdevicesinc/gr-iio.git
> " 
> but didn't work either.
> 
> Anybody please guide me, how to add it by using gr_modtool or from github 
> library?
> 
> -- 
> 
> 
> Regards,
> Rupak Paul 
> 

Unable to add FMCOMMS5 from git library

[Rupak Paul]

Hello there,
I am using Gnuradio v3.7 in linux 18.04. But I can't find FMCOMMS5 block in
this version. I tried to add it from github library using "git clone
https://github.com/analogdevicesinc/gr-iio.git;
but didn't work either.

Anybody please guide me, how to add it by using gr_modtool or from github
library?

-- 


Regards,
Rupak Paul

Re: Packet Loopback Example Using USRP

[Jeff Long]

Yes, that shows bursts of digital data, which is what your tx produces. Use
a smaller FFT size to see more detail in the time domain.

On Sun, Jan 24, 2021 at 4:44 PM Jada Mariano Berenguer 
wrote:

> So, from my understanding you added a File Sink that took in the USRP
> Source's output to the packet_usrp_tx.grc flowgraph? I tried to recreate
> what you did and opened the file with Inspectrum and a screenshot of the
> results is attached. I'm not sure if this is what you got, or what it
> means. I may be saving it to the File Sink incorrectly, so I attached a
> screenshot of the File Sink parameters as well.
>
> Also, what do you mean by 'What happens if you ignore this and keep
> working' ? Because if I run the packet_usrp.grc flowgraph for a while and
> ignore the U's printing out, it doesn't give me the result that I expect.
> The result that I expect would be similar to the result when running the
> packet_loopback_hier.grc file.
>
> Thanks again for your continued help!
>
> On Sun, Jan 24, 2021 at 12:03 PM Jeff Long  wrote:
>
>> Best I can tell (recording raw samples from the USRP Source to a File
>> Sink, then viewing it with inspectrum), it works and the single 'U' per
>> burst is spurious. The docs would lead you to believe you shouldn't see
>> this. Nothing stands out as wrong in the GRCs. What happens if you ignore
>> this and keep working?
>>
>> On Sun, Jan 24, 2021 at 1:41 PM Jada Mariano Berenguer 
>> wrote:
>>
>>> Okay, thanks for the tip. Attached in this email is a flowgraph that
>>> only does TX (packet_usrp_tx.grc). I'll continue to look into the problem
>>> and see if I can find any solutions myself as well, but again I'm pretty
>>> new to GNURadio and USRP. If anyone can help me figure out the problem,
>>> it'd be greatly appreciated!! I've also attached the packet loopback
>>> example using the USRP with both TX and RX (packet_usrp.grc), the original
>>> packet loopback example without USRP (packet_loopback_hier.grc), and the
>>> packet_tx and packet_rx flowgraphs as well.
>>>
>>> On Sat, Jan 23, 2021 at 4:36 AM Jeff Long  wrote:
>>>
 Recommend you find the simplest flowgraph that demonstrates this
 problem. For example, do TX only. Once you find that minimal case, post the
 actual GRC file somewhere so someone can try it out. It's really difficult
 to look through a bunch of parameters in a screenshot and try to guess
 what's happening, unless it's something really obvious.

 On Fri, Jan 22, 2021 at 9:24 PM Jada Mariano Berenguer <
 beren...@uci.edu> wrote:

> Hi again, I have a previous message thread regarding this problem, but
> I kept forgetting to 'reply all' to include the GNURadio email to keep it
> on the thread and my questions got kind of disorganized, so I wanted to
> start fresh with a new one and will make sure to reply all in the future.
>
> So, I found a packet_loopback example (under the directory:
> examples/digital/packet) from this message thread
> 
>  and
> it says that I can replace the Channel Model block with the USRP source 
> and
> sink blocks to try to send packets over the air (a screenshot of the
> original packet_loopback example and my modified packet_loopback example 
> is
> attached as well). This is exactly what I want to do, but I'm running into
> some issues with the USRP sink.
>
> I believe the problem has to do with the way that the USRP sink is
> receiving the packets. I believe it deals with 'bursty transmission
> ', and so I specified
> the USRP sink's 'TSB tag name' parameter to 'packet_len', which is what 
> the
> packet_tx block specifies as the length tag name (I've also attached a
> screenshot of the packet_tx flowgraph). I confirmed that the tag name is
> 'packet_len' by using the Tag Debug block.
>
> Also, I've attached a video link here
> 
> of what happens when I run the program. It seems like the USRP receives 
> the
> packet here and there because of the short 'bursts' shown on the middle
> graph. Also, I noticed that there's a 'tG' printed in the terminal window
> (a screenshot of this is attached as well) when the program is first run.
> What does this mean? I also know that it's experiencing a lot of 
> underruns,
> which is essentially the problem I'm trying to solve. It must do with the
> way the USRP sink is configured to receive the packets.
>
> Are there any other parameters that need to be set?
>
> Thanks so much in advance!! I appreciate any help :)
>
>
>

Re: Packet Loopback Example Using USRP

[Jeff Long]

Best I can tell (recording raw samples from the USRP Source to a File Sink,
then viewing it with inspectrum), it works and the single 'U' per burst is
spurious. The docs would lead you to believe you shouldn't see this.
Nothing stands out as wrong in the GRCs. What happens if you ignore this
and keep working?

On Sun, Jan 24, 2021 at 1:41 PM Jada Mariano Berenguer 
wrote:

> Okay, thanks for the tip. Attached in this email is a flowgraph that only
> does TX (packet_usrp_tx.grc). I'll continue to look into the problem and
> see if I can find any solutions myself as well, but again I'm pretty new to
> GNURadio and USRP. If anyone can help me figure out the problem, it'd be
> greatly appreciated!! I've also attached the packet loopback example using
> the USRP with both TX and RX (packet_usrp.grc), the original packet
> loopback example without USRP (packet_loopback_hier.grc), and the packet_tx
> and packet_rx flowgraphs as well.
>
> On Sat, Jan 23, 2021 at 4:36 AM Jeff Long  wrote:
>
>> Recommend you find the simplest flowgraph that demonstrates this problem.
>> For example, do TX only. Once you find that minimal case, post the actual
>> GRC file somewhere so someone can try it out. It's really difficult to look
>> through a bunch of parameters in a screenshot and try to guess what's
>> happening, unless it's something really obvious.
>>
>> On Fri, Jan 22, 2021 at 9:24 PM Jada Mariano Berenguer 
>> wrote:
>>
>>> Hi again, I have a previous message thread regarding this problem, but I
>>> kept forgetting to 'reply all' to include the GNURadio email to keep it on
>>> the thread and my questions got kind of disorganized, so I wanted to start
>>> fresh with a new one and will make sure to reply all in the future.
>>>
>>> So, I found a packet_loopback example (under the directory:
>>> examples/digital/packet) from this message thread
>>>  
>>> and
>>> it says that I can replace the Channel Model block with the USRP source and
>>> sink blocks to try to send packets over the air (a screenshot of the
>>> original packet_loopback example and my modified packet_loopback example is
>>> attached as well). This is exactly what I want to do, but I'm running into
>>> some issues with the USRP sink.
>>>
>>> I believe the problem has to do with the way that the USRP sink is
>>> receiving the packets. I believe it deals with 'bursty transmission
>>> ', and so I specified
>>> the USRP sink's 'TSB tag name' parameter to 'packet_len', which is what the
>>> packet_tx block specifies as the length tag name (I've also attached a
>>> screenshot of the packet_tx flowgraph). I confirmed that the tag name is
>>> 'packet_len' by using the Tag Debug block.
>>>
>>> Also, I've attached a video link here
>>> 
>>> of what happens when I run the program. It seems like the USRP receives the
>>> packet here and there because of the short 'bursts' shown on the middle
>>> graph. Also, I noticed that there's a 'tG' printed in the terminal window
>>> (a screenshot of this is attached as well) when the program is first run.
>>> What does this mean? I also know that it's experiencing a lot of underruns,
>>> which is essentially the problem I'm trying to solve. It must do with the
>>> way the USRP sink is configured to receive the packets.
>>>
>>> Are there any other parameters that need to be set?
>>>
>>> Thanks so much in advance!! I appreciate any help :)
>>>
>>>
>>>

Re: Problem with OOT Interpolator Python module

[George Edwards]

Hi Cinaed,

Thanks for the attempt!

I will continue to seek a solution via experimentation with trying more
permutations and going back to Gnuradio Discussion if I still cannot find
something to stick.

Regards,
George

George

On Sat, Jan 23, 2021 at 11:15 PM Cinaed Simson 
wrote:

> Hi Edward - okay, I sent the wrong copy anyway - the one I sent wasn't
> finished.When I change the inputs to 5 complex numbers I get 9 complex
> values.
>
> And that's good because it appeared you weren't doing anything.
>
> See the loop
>
>   for k in range(0,2)
>
> which is loop over only 3 values - may be you're clipping your output?
>
> I don't anything about the OOT module or C++.
>
> Sorry - I can't help you.
>
> -- Cinaed
> S
>
>
> On 1/23/21 5:37 PM, George Edwards wrote:
>
> Hi Cinaed,
>
> Thanks again for your suggestion.
>
> I can tell it will not work because I am not writing plain stand alone
> Python. My code is written within Gnuradio constructs in an OOT module. The
> QA test shows the module is reading in the input complex samples (5 complex
> samples) and responding with the correct amount of output samples (10
> complex samples). However, it was working properly all 10 output samples
> would be 1+j1. Instead only the first two and last two samples are correct
> and the middle value 6 values are j0 (which are wrong). So the question is:
> "how do I fix my code to output 10 samples of 1+j1". Based on how I have
> written the code, I am under the belief that I am writing 1+j1 to the
> output buffer 10 times, but my output is not 1+j1 10 times, so something is
> wrong. So I am looking for help on how to modify the code to fulfill the
> proper operation of Gnuradio OOT Interpolator module.
>
> Thanks again for the help.
>
> George
>
>
>
> On Sat, Jan 23, 2021 at 7:00 PM George Edwards 
> wrote:
>
>> Thanks Cinaed!
>>
>> I will test how it works.
>>
>> George
>>
>> On Sat, Jan 23, 2021 at 2:58 PM Cinaed Simson 
>> wrote:
>>
>>> Hi George - I'm presuming the enclosed example.py script is what you're
>>> trying calculate - and that the input data is complex.
>>>
>>> I invented my own data.
>>>
>>> If true, it should be easy to adapt it to your problem by combining the
>>> 2 loops for any value of n.
>>>
>>> -- Cinaed
>>>
>>>
>>> On 1/22/21 10:49 AM, George Edwards wrote:
>>>
>>> Hello,
>>> I am working with the OOT Interpolator template and I set the
>>> interpolation factor to 2. In the QA file I input 5-complex samples  and
>>> based on my simple code below in the work() method, I expect the QA test to
>>> return 1+j1, 10-times (5x2). The QA returns ((1+1j), (1+1j), 0j,  0j,  0j,
>>> 0j,  0j,  0j,  (1+1j) ,  (1+1j)). I have tried a lot of different coding
>>> permutations and this is the closest I come to a solution, but it is
>>> wrong!!!  Any help is greatly appreciated!
>>>
>>> def work(self, input_items, output_items):
>>>
>>> in0 = input_items[0]
>>>
>>> out = output_items[0]
>>>
>>> for ii in range(0,len(in0)):
>>>
>>> for k in range(0,2):
>>>
>>> out[k] = 1.0+1.0*1j
>>>
>>>
>>>
>>> return len(output_items[0])
>>>
>>> Thanks,
>>> George
>>>
>>>
>>>
>