[Discuss-gnuradio] SWIG director method error

[ogün levent]

 Hello there,

I am having this error recently which has never been occured before. What
could be the possible solution?

Best.

self.message_port_pub(pmt.intern("Vector_OUT"),pmt.cons(pmt.PMT_NIL,pmt.to_pmt(bufnp)))
  File "/usr/lib/python2.7/dist-packages/pmt/pmt_to_python.py", line 133,
in python_to_pmt
if p == None: return from_python(p)
ValueError: The truth value of an array with more than one element is
ambiguous. Use a.any() or a.all()
thread[thread-per-block[11]: ]: SWIG
director method error. Error detected when calling 'feval_p.eval'
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNURadio Help

[Ivan Zahartchuk]

Hello. I'm trying to write a block in gnuradio for broadband reception.
 The main problem at the moment is to transfer data to the fft block.
I'm new to python and so it's hard for me to figure this out.import numpy as np

I need an array of data to pass to the gnuradio.fft.fft.vcc block

from gnuradio import gr
from gnuradio import uhd
from gnuradio import fft

class blk(gr.sync_block):  # other base classes are basic_block,
decim_block, interp_block
"""Embedded Python Block example - a simple multiply const"""

def __init__(self,
gain=1.0,start_freq=70e6,stop_freq=6000e6,samp_rate=30e6):  # only
default arguments here
"""arguments to this function show up as parameters in GRC"""
gr.sync_block.__init__(
self,
name='Python Block',   # will show up in GRC
in_sig=None,
out_sig=[np.complex64,np.complex64]
)
# if an attribute with the same name as a parameter is found,
# a callback is registered (properties work, too).
self.gain = gain
self.start_freq=start_freq
self.stop_freq=stop_freq
self.samp_rate=samp_rate
self.uhd_usrp_source_0 = uhd.usrp_source(",".join(("", "")),
 uhd.stream_args(
 cpu_format="fc32",
 otw_format="sc16",
 chanels=range(1),
 ),
 )


self.uhd_usrp_source_0.set_clock_rate(30e6, uhd.ALL_MBOARDS)
self.uhd_usrp_source_0.set_samp_rate(self.samp_rate)
self.uhd_usrp_source_0.set_gain(self.gain, 0)
self.uhd_usrp_source_0.set_antenna("RX2", 0)
self.uhd_usrp_source_0.set_bandwidth(30e6, 0)
self.range_freq=(self.stop_freq-self.start_freq)/self.samp_rate

def work(self, input_items, output_items):
"""example: multiply with constant"""
for i in np.range(self.range_freq):

self.uhd_usrp_source_0.set_center_freq(self.start_freq+self.samp_rate*i)
data=np.array(self.uhd_usrp_source_0.finite_acquisition(8192))
output_items[0][:] = input_items[0] * self.example_param
return len(output_items[0])
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio Help

[CEL]

Dear Ivan,

you don't pass data to a block yourself. 

You write a block that does a clearly-limited signal processing job,
and use GNU Radio to connect that to other blocks:

https://tutorials.gnuradio.org

In your case, instantiating a USRP source in your block makes
absolutely no sense, for example. You'd build a flow graph containing
the USRP source, and your custom-written block, and you'd connect these
two.

It's sadly not really clear what you want to achieve, so I'm afraid I'm
not able to help you here.

Generally, GNU Radio pretty much takes the idea of "draw a block
diagram of what you want to achieve with your signal processing", and
directly translates it to "using existing blocks and writing new ones,
and letting GNU Radio take care of how the data gets around".

Also, wideband signal processing and implementing a sync_block in
Python... do not work well together.

So, I think you might really be a bit confused about the architecture
of GNU Radio – I really hope the tutorials explain that better than I
could.

Best regards,
Marcus

On Wed, 2018-06-13 at 17:16 +0300, Ivan Zahartchuk wrote:
> Hello. I'm trying to write a block in gnuradio for broadband reception.
>  The main problem at the moment is to transfer data to the fft block. 
> I'm new to python and so it's hard for me to figure this out.import numpy as 
> np
> 
> I need an array of data to pass to the gnuradio.fft.fft.vcc block
> 
> from gnuradio import gr
> from gnuradio import uhd
> from gnuradio import fft
> 
> class blk(gr.sync_block):  # other base classes are basic_block, decim_block, 
> interp_block
> """Embedded Python Block example - a simple multiply const"""
> 
> def __init__(self, 
> gain=1.0,start_freq=70e6,stop_freq=6000e6,samp_rate=30e6):  # only default 
> arguments here
> """arguments to this function show up as parameters in GRC"""
> gr.sync_block.__init__(
> self,
> name='Python Block',   # will show up in GRC
> in_sig=None,
> out_sig=[np.complex64,np.complex64]
> )
> # if an attribute with the same name as a parameter is found,
> # a callback is registered (properties work, too).
> self.gain = gain
> self.start_freq=start_freq
> self.stop_freq=stop_freq
> self.samp_rate=samp_rate
> self.uhd_usrp_source_0 = uhd.usrp_source(",".join(("", "")),
>  uhd.stream_args(
>  cpu_format="fc32",
>  otw_format="sc16",
>  chanels=range(1),
>  ),
>  )
> 
> 
> self.uhd_usrp_source_0.set_clock_rate(30e6, uhd.ALL_MBOARDS)
> self.uhd_usrp_source_0.set_samp_rate(self.samp_rate)
> self.uhd_usrp_source_0.set_gain(self.gain, 0)
> self.uhd_usrp_source_0.set_antenna("RX2", 0)
> self.uhd_usrp_source_0.set_bandwidth(30e6, 0)
> self.range_freq=(self.stop_freq-self.start_freq)/self.samp_rate
> 
> def work(self, input_items, output_items):
> """example: multiply with constant"""
> for i in np.range(self.range_freq):
> 
> self.uhd_usrp_source_0.set_center_freq(self.start_freq+self.samp_rate*i)
> data=np.array(self.uhd_usrp_source_0.finite_acquisition(8192))
> output_items[0][:] = input_items[0] * self.example_param
> return len(output_items[0])
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] GNURadio Help

[Ivan Zahartchuk]

I need to rebuild the frequency, do fft and then transfer the whole array
from 70 to 6GHz to the host machine. I do not quite imagine how you can do
this with standard blocks in gnuradio.


2018-06-13 17:32 GMT+03:00 Müller, Marcus (CEL) :

> Dear Ivan,
>
> you don't pass data to a block yourself.
>
> You write a block that does a clearly-limited signal processing job,
> and use GNU Radio to connect that to other blocks:
>
> https://tutorials.gnuradio.org
>
> In your case, instantiating a USRP source in your block makes
> absolutely no sense, for example. You'd build a flow graph containing
> the USRP source, and your custom-written block, and you'd connect these
> two.
>
> It's sadly not really clear what you want to achieve, so I'm afraid I'm
> not able to help you here.
>
> Generally, GNU Radio pretty much takes the idea of "draw a block
> diagram of what you want to achieve with your signal processing", and
> directly translates it to "using existing blocks and writing new ones,
> and letting GNU Radio take care of how the data gets around".
>
> Also, wideband signal processing and implementing a sync_block in
> Python... do not work well together.
>
> So, I think you might really be a bit confused about the architecture
> of GNU Radio – I really hope the tutorials explain that better than I
> could.
>
> Best regards,
> Marcus
>
> On Wed, 2018-06-13 at 17:16 +0300, Ivan Zahartchuk wrote:
> > Hello. I'm trying to write a block in gnuradio for broadband reception.
> >  The main problem at the moment is to transfer data to the fft block.
> > I'm new to python and so it's hard for me to figure this out.import
> numpy as np
> >
> > I need an array of data to pass to the gnuradio.fft.fft.vcc block
> >
> > from gnuradio import gr
> > from gnuradio import uhd
> > from gnuradio import fft
> >
> > class blk(gr.sync_block):  # other base classes are basic_block,
> decim_block, interp_block
> > """Embedded Python Block example - a simple multiply const"""
> >
> > def __init__(self, 
> > gain=1.0,start_freq=70e6,stop_freq=6000e6,samp_rate=30e6):
> # only default arguments here
> > """arguments to this function show up as parameters in GRC"""
> > gr.sync_block.__init__(
> > self,
> > name='Python Block',   # will show up in GRC
> > in_sig=None,
> > out_sig=[np.complex64,np.complex64]
> > )
> > # if an attribute with the same name as a parameter is found,
> > # a callback is registered (properties work, too).
> > self.gain = gain
> > self.start_freq=start_freq
> > self.stop_freq=stop_freq
> > self.samp_rate=samp_rate
> > self.uhd_usrp_source_0 = uhd.usrp_source(",".join(("", "")),
> >  uhd.stream_args(
> >  cpu_format="fc32",
> >  otw_format="sc16",
> >  chanels=range(1),
> >  ),
> >  )
> >
> >
> > self.uhd_usrp_source_0.set_clock_rate(30e6, uhd.ALL_MBOARDS)
> > self.uhd_usrp_source_0.set_samp_rate(self.samp_rate)
> > self.uhd_usrp_source_0.set_gain(self.gain, 0)
> > self.uhd_usrp_source_0.set_antenna("RX2", 0)
> > self.uhd_usrp_source_0.set_bandwidth(30e6, 0)
> > self.range_freq=(self.stop_freq-self.start_freq)/self.samp_rate
> >
> > def work(self, input_items, output_items):
> > """example: multiply with constant"""
> > for i in np.range(self.range_freq):
> > self.uhd_usrp_source_0.set_center_freq(self.start_freq+
> self.samp_rate*i)
> > data=np.array(self.uhd_usrp_source_0.finite_acquisition(
> 8192))
> > output_items[0][:] = input_items[0] * self.example_param
> > return len(output_items[0])
> > ___
> > 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] GNURadio Help

[Ivan Zahartchuk]

In the future, I would also like to use the RFNoC

2018-06-13 17:42 GMT+03:00 Ivan Zahartchuk :

> I need to rebuild the frequency, do fft and then transfer the whole array
> from 70 to 6GHz to the host machine. I do not quite imagine how you can
> do this with standard blocks in gnuradio.
>
>
> 2018-06-13 17:32 GMT+03:00 Müller, Marcus (CEL) :
>
>> Dear Ivan,
>>
>> you don't pass data to a block yourself.
>>
>> You write a block that does a clearly-limited signal processing job,
>> and use GNU Radio to connect that to other blocks:
>>
>> https://tutorials.gnuradio.org
>>
>> In your case, instantiating a USRP source in your block makes
>> absolutely no sense, for example. You'd build a flow graph containing
>> the USRP source, and your custom-written block, and you'd connect these
>> two.
>>
>> It's sadly not really clear what you want to achieve, so I'm afraid I'm
>> not able to help you here.
>>
>> Generally, GNU Radio pretty much takes the idea of "draw a block
>> diagram of what you want to achieve with your signal processing", and
>> directly translates it to "using existing blocks and writing new ones,
>> and letting GNU Radio take care of how the data gets around".
>>
>> Also, wideband signal processing and implementing a sync_block in
>> Python... do not work well together.
>>
>> So, I think you might really be a bit confused about the architecture
>> of GNU Radio – I really hope the tutorials explain that better than I
>> could.
>>
>> Best regards,
>> Marcus
>>
>> On Wed, 2018-06-13 at 17:16 +0300, Ivan Zahartchuk wrote:
>> > Hello. I'm trying to write a block in gnuradio for broadband reception.
>> >  The main problem at the moment is to transfer data to the fft block.
>> > I'm new to python and so it's hard for me to figure this out.import
>> numpy as np
>> >
>> > I need an array of data to pass to the gnuradio.fft.fft.vcc block
>> >
>> > from gnuradio import gr
>> > from gnuradio import uhd
>> > from gnuradio import fft
>> >
>> > class blk(gr.sync_block):  # other base classes are basic_block,
>> decim_block, interp_block
>> > """Embedded Python Block example - a simple multiply const"""
>> >
>> > def __init__(self, 
>> > gain=1.0,start_freq=70e6,stop_freq=6000e6,samp_rate=30e6):
>> # only default arguments here
>> > """arguments to this function show up as parameters in GRC"""
>> > gr.sync_block.__init__(
>> > self,
>> > name='Python Block',   # will show up in GRC
>> > in_sig=None,
>> > out_sig=[np.complex64,np.complex64]
>> > )
>> > # if an attribute with the same name as a parameter is found,
>> > # a callback is registered (properties work, too).
>> > self.gain = gain
>> > self.start_freq=start_freq
>> > self.stop_freq=stop_freq
>> > self.samp_rate=samp_rate
>> > self.uhd_usrp_source_0 = uhd.usrp_source(",".join(("", "")),
>> >  uhd.stream_args(
>> >  cpu_format="fc32",
>> >  otw_format="sc16",
>> >  chanels=range(1),
>> >  ),
>> >  )
>> >
>> >
>> > self.uhd_usrp_source_0.set_clock_rate(30e6, uhd.ALL_MBOARDS)
>> > self.uhd_usrp_source_0.set_samp_rate(self.samp_rate)
>> > self.uhd_usrp_source_0.set_gain(self.gain, 0)
>> > self.uhd_usrp_source_0.set_antenna("RX2", 0)
>> > self.uhd_usrp_source_0.set_bandwidth(30e6, 0)
>> > self.range_freq=(self.stop_freq-self.start_freq)/self.samp_rate
>> >
>> > def work(self, input_items, output_items):
>> > """example: multiply with constant"""
>> > for i in np.range(self.range_freq):
>> > self.uhd_usrp_source_0.set_center_freq(self.start_freq+self
>> .samp_rate*i)
>> > data=np.array(self.uhd_usrp_source_0.finite_acquisition(819
>> 2))
>> > output_items[0][:] = input_items[0] * self.example_param
>> > return len(output_items[0])
>> > ___
>> > 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] GNURadio Help

[CEL]

I don't understand what you mean with "do the FFT and then transfer […]
to the host machine": GNU Radio runs on the host machine, so whatever
processing you do already happens on the host machine.

Assuming this is just a small problem in expression, and you're doing
all this on the same machine:
Well, you'll need to send messages to the USRP source to re-tune with
timed commands, and to "sort" the samples coming out of the source by
the timestamp they have so that you know which FFT-length vectors
belong to which frequency (and drop the samples that were taken while
you were re-tuning). Note that the capability to tune on timed commands
is not given in all USRPs to the same degree at all.

It's a relatively complex application that you're planning. There's an
old GNU Radio example that does exactly that, but was written long
before timed commands were introduced, and is hence incredibly
inefficient (has to throw away most of the samples, because it never
knows when exactly tuning has happpened). I wouldn't recommend using it
for this reason, but it still works, and that without much custom
blocks (but with ugly and slow python code that noone would write
similarly today). It's in gnuradio/gr-uhd/examples/python and is called
usrp_spectrum_sense. Again, this is basically obsolete technologically,
but it still works. Please don't write the 400th thesis about this
piece of software!

Best regards,
Marcus

On Wed, 2018-06-13 at 17:42 +0300, Ivan Zahartchuk wrote:
> I need to rebuild the frequency, do fft and then transfer the whole array 
> from 70 to 6GHz to the host machine. I do not quite imagine how you can do 
> this with standard blocks in gnuradio.
> 
> 
> 2018-06-13 17:32 GMT+03:00 Müller, Marcus (CEL) :
> > Dear Ivan,
> > 
> > you don't pass data to a block yourself. 
> > 
> > You write a block that does a clearly-limited signal processing job,
> > and use GNU Radio to connect that to other blocks:
> > 
> > https://tutorials.gnuradio.org
> > 
> > In your case, instantiating a USRP source in your block makes
> > absolutely no sense, for example. You'd build a flow graph containing
> > the USRP source, and your custom-written block, and you'd connect these
> > two.
> > 
> > It's sadly not really clear what you want to achieve, so I'm afraid I'm
> > not able to help you here.
> > 
> > Generally, GNU Radio pretty much takes the idea of "draw a block
> > diagram of what you want to achieve with your signal processing", and
> > directly translates it to "using existing blocks and writing new ones,
> > and letting GNU Radio take care of how the data gets around".
> > 
> > Also, wideband signal processing and implementing a sync_block in
> > Python... do not work well together.
> > 
> > So, I think you might really be a bit confused about the architecture
> > of GNU Radio – I really hope the tutorials explain that better than I
> > could.
> > 
> > Best regards,
> > Marcus
> > 
> > On Wed, 2018-06-13 at 17:16 +0300, Ivan Zahartchuk wrote:
> > > Hello. I'm trying to write a block in gnuradio for broadband reception.
> > >  The main problem at the moment is to transfer data to the fft block. 
> > > I'm new to python and so it's hard for me to figure this out.import numpy 
> > > as np
> > > 
> > > I need an array of data to pass to the gnuradio.fft.fft.vcc block
> > > 
> > > from gnuradio import gr
> > > from gnuradio import uhd
> > > from gnuradio import fft
> > > 
> > > class blk(gr.sync_block):  # other base classes are basic_block, 
> > > decim_block, interp_block
> > > """Embedded Python Block example - a simple multiply const"""
> > > 
> > > def __init__(self, 
> > > gain=1.0,start_freq=70e6,stop_freq=6000e6,samp_rate=30e6):  # only 
> > > default arguments here
> > > """arguments to this function show up as parameters in GRC"""
> > > gr.sync_block.__init__(
> > > self,
> > > name='Python Block',   # will show up in GRC
> > > in_sig=None,
> > > out_sig=[np.complex64,np.complex64]
> > > )
> > > # if an attribute with the same name as a parameter is found,
> > > # a callback is registered (properties work, too).
> > > self.gain = gain
> > > self.start_freq=start_freq
> > > self.stop_freq=stop_freq
> > > self.samp_rate=samp_rate
> > > self.uhd_usrp_source_0 = uhd.usrp_source(",".join(("", "")),
> > >  uhd.stream_args(
> > >  cpu_format="fc32",
> > >  otw_format="sc16",
> > >  chanels=range(1),
> > >  ),
> > >  )
> > > 
> > > 
> > > self.uhd_usrp_source_0.set_clock_rate(30e6, uhd.ALL_MBOARDS)
> > > self.uhd_usrp_source_0.set_samp_rate(self.samp_rate)
> > > se

Re: [Discuss-gnuradio] GNURadio Help

[John Medrano]

Hello.

If I understand what you are saying correctly, you would like to process
wide band data. And you mention 70 MHz to 6 GHz.

Even with RFNOC there is a limitation on the amount of data you can process
simultaneously, and that is about 200 MHz. There is no way possible to
simultaneously process a 6GHz band with one host and radio. You would need
an array of radios.

Please provide more details on design requirements, it hard to understand
what you are trying to accomplish.

On Wed, Jun 13, 2018 at 8:46 AM, Ivan Zahartchuk 
wrote:

> In the future, I would also like to use the RFNoC
>
> 2018-06-13 17:42 GMT+03:00 Ivan Zahartchuk :
>
>> I need to rebuild the frequency, do fft and then transfer the whole array
>> from 70 to 6GHz to the host machine. I do not quite imagine how you can
>> do this with standard blocks in gnuradio.
>>
>>
>> 2018-06-13 17:32 GMT+03:00 Müller, Marcus (CEL) :
>>
>>> Dear Ivan,
>>>
>>> you don't pass data to a block yourself.
>>>
>>> You write a block that does a clearly-limited signal processing job,
>>> and use GNU Radio to connect that to other blocks:
>>>
>>> https://tutorials.gnuradio.org
>>>
>>> In your case, instantiating a USRP source in your block makes
>>> absolutely no sense, for example. You'd build a flow graph containing
>>> the USRP source, and your custom-written block, and you'd connect these
>>> two.
>>>
>>> It's sadly not really clear what you want to achieve, so I'm afraid I'm
>>> not able to help you here.
>>>
>>> Generally, GNU Radio pretty much takes the idea of "draw a block
>>> diagram of what you want to achieve with your signal processing", and
>>> directly translates it to "using existing blocks and writing new ones,
>>> and letting GNU Radio take care of how the data gets around".
>>>
>>> Also, wideband signal processing and implementing a sync_block in
>>> Python... do not work well together.
>>>
>>> So, I think you might really be a bit confused about the architecture
>>> of GNU Radio – I really hope the tutorials explain that better than I
>>> could.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On Wed, 2018-06-13 at 17:16 +0300, Ivan Zahartchuk wrote:
>>> > Hello. I'm trying to write a block in gnuradio for broadband reception.
>>> >  The main problem at the moment is to transfer data to the fft block.
>>> > I'm new to python and so it's hard for me to figure this out.import
>>> numpy as np
>>> >
>>> > I need an array of data to pass to the gnuradio.fft.fft.vcc block
>>> >
>>> > from gnuradio import gr
>>> > from gnuradio import uhd
>>> > from gnuradio import fft
>>> >
>>> > class blk(gr.sync_block):  # other base classes are basic_block,
>>> decim_block, interp_block
>>> > """Embedded Python Block example - a simple multiply const"""
>>> >
>>> > def __init__(self, 
>>> > gain=1.0,start_freq=70e6,stop_freq=6000e6,samp_rate=30e6):
>>> # only default arguments here
>>> > """arguments to this function show up as parameters in GRC"""
>>> > gr.sync_block.__init__(
>>> > self,
>>> > name='Python Block',   # will show up in GRC
>>> > in_sig=None,
>>> > out_sig=[np.complex64,np.complex64]
>>> > )
>>> > # if an attribute with the same name as a parameter is found,
>>> > # a callback is registered (properties work, too).
>>> > self.gain = gain
>>> > self.start_freq=start_freq
>>> > self.stop_freq=stop_freq
>>> > self.samp_rate=samp_rate
>>> > self.uhd_usrp_source_0 = uhd.usrp_source(",".join(("", "")),
>>> >  uhd.stream_args(
>>> >  cpu_format="fc32",
>>> >  otw_format="sc16",
>>> >  chanels=range(1),
>>> >  ),
>>> >  )
>>> >
>>> >
>>> > self.uhd_usrp_source_0.set_clock_rate(30e6, uhd.ALL_MBOARDS)
>>> > self.uhd_usrp_source_0.set_samp_rate(self.samp_rate)
>>> > self.uhd_usrp_source_0.set_gain(self.gain, 0)
>>> > self.uhd_usrp_source_0.set_antenna("RX2", 0)
>>> > self.uhd_usrp_source_0.set_bandwidth(30e6, 0)
>>> > self.range_freq=(self.stop_freq-self.start_freq)/self.samp_
>>> rate
>>> >
>>> > def work(self, input_items, output_items):
>>> > """example: multiply with constant"""
>>> > for i in np.range(self.range_freq):
>>> > self.uhd_usrp_source_0.set_ce
>>> nter_freq(self.start_freq+self.samp_rate*i)
>>> > data=np.array(self.uhd_usrp_s
>>> ource_0.finite_acquisition(8192))
>>> > output_items[0][:] = input_items[0] * self.example_param
>>> > return len(output_items[0])
>>> > ___
>>> > Discuss-gnuradio mailing list
>>> > Discuss-gnuradio@gnu.org
>>> > https://lists.gnu.org/mailman/list

Re: [Discuss-gnuradio] GNURadio Help

[Ivan Zahartchuk]

I want to process not 6GHz but 30 MHz at a time. Ie I read 30 MHz at a
frequency of 400 MHz (for example) then I do 30 MHz FFT and write them to
the buffer. And so up to 6GHz. Then when the buffer is full, I transfer the
data to the host machine (I use the USRP E310 board) to display the data.
In fact, it should be such a broadband spectrum analyzer not in real time.

2018-06-13 17:57 GMT+03:00 John Medrano :

> Hello.
>
> If I understand what you are saying correctly, you would like to process
> wide band data. And you mention 70 MHz to 6 GHz.
>
> Even with RFNOC there is a limitation on the amount of data you can
> process simultaneously, and that is about 200 MHz. There is no way possible
> to simultaneously process a 6GHz band with one host and radio. You would
> need an array of radios.
>
> Please provide more details on design requirements, it hard to understand
> what you are trying to accomplish.
>
> On Wed, Jun 13, 2018 at 8:46 AM, Ivan Zahartchuk 
> wrote:
>
>> In the future, I would also like to use the RFNoC
>>
>> 2018-06-13 17:42 GMT+03:00 Ivan Zahartchuk :
>>
>>> I need to rebuild the frequency, do fft and then transfer the whole
>>> array from 70 to 6GHz to the host machine. I do not quite imagine how
>>> you can do this with standard blocks in gnuradio.
>>>
>>>
>>> 2018-06-13 17:32 GMT+03:00 Müller, Marcus (CEL) :
>>>
 Dear Ivan,

 you don't pass data to a block yourself.

 You write a block that does a clearly-limited signal processing job,
 and use GNU Radio to connect that to other blocks:

 https://tutorials.gnuradio.org

 In your case, instantiating a USRP source in your block makes
 absolutely no sense, for example. You'd build a flow graph containing
 the USRP source, and your custom-written block, and you'd connect these
 two.

 It's sadly not really clear what you want to achieve, so I'm afraid I'm
 not able to help you here.

 Generally, GNU Radio pretty much takes the idea of "draw a block
 diagram of what you want to achieve with your signal processing", and
 directly translates it to "using existing blocks and writing new ones,
 and letting GNU Radio take care of how the data gets around".

 Also, wideband signal processing and implementing a sync_block in
 Python... do not work well together.

 So, I think you might really be a bit confused about the architecture
 of GNU Radio – I really hope the tutorials explain that better than I
 could.

 Best regards,
 Marcus

 On Wed, 2018-06-13 at 17:16 +0300, Ivan Zahartchuk wrote:
 > Hello. I'm trying to write a block in gnuradio for broadband
 reception.
 >  The main problem at the moment is to transfer data to the fft block.
 > I'm new to python and so it's hard for me to figure this out.import
 numpy as np
 >
 > I need an array of data to pass to the gnuradio.fft.fft.vcc block
 >
 > from gnuradio import gr
 > from gnuradio import uhd
 > from gnuradio import fft
 >
 > class blk(gr.sync_block):  # other base classes are basic_block,
 decim_block, interp_block
 > """Embedded Python Block example - a simple multiply const"""
 >
 > def __init__(self, 
 > gain=1.0,start_freq=70e6,stop_freq=6000e6,samp_rate=30e6):
 # only default arguments here
 > """arguments to this function show up as parameters in GRC"""
 > gr.sync_block.__init__(
 > self,
 > name='Python Block',   # will show up in GRC
 > in_sig=None,
 > out_sig=[np.complex64,np.complex64]
 > )
 > # if an attribute with the same name as a parameter is found,
 > # a callback is registered (properties work, too).
 > self.gain = gain
 > self.start_freq=start_freq
 > self.stop_freq=stop_freq
 > self.samp_rate=samp_rate
 > self.uhd_usrp_source_0 = uhd.usrp_source(",".join(("", "")),
 >  uhd.stream_args(
 >
 cpu_format="fc32",
 >
 otw_format="sc16",
 >  chanels=range(1),
 >  ),
 >  )
 >
 >
 > self.uhd_usrp_source_0.set_clock_rate(30e6, uhd.ALL_MBOARDS)
 > self.uhd_usrp_source_0.set_samp_rate(self.samp_rate)
 > self.uhd_usrp_source_0.set_gain(self.gain, 0)
 > self.uhd_usrp_source_0.set_antenna("RX2", 0)
 > self.uhd_usrp_source_0.set_bandwidth(30e6, 0)
 > self.range_freq=(self.stop_freq-self.start_freq)/self.samp_
 rate
 >
 > def work(self, input_items, output_items):
 > """example: multiply with constant"""
 > for i in np.range(self.range_freq):
 > 

Re: [Discuss-gnuradio] GNURadio Help

[John Medrano]

This is much more doable.

May I ask why you want to buffer all the data in the radio?

On Wed, Jun 13, 2018 at 9:06 AM, Ivan Zahartchuk 
wrote:

> I want to process not 6GHz but 30 MHz at a time. Ie I read 30 MHz at a
> frequency of 400 MHz (for example) then I do 30 MHz FFT and write them to
> the buffer. And so up to 6GHz. Then when the buffer is full, I transfer
> the data to the host machine (I use the USRP E310 board) to display the
> data.
> In fact, it should be such a broadband spectrum analyzer not in real time.
>
> 2018-06-13 17:57 GMT+03:00 John Medrano :
>
>> Hello.
>>
>> If I understand what you are saying correctly, you would like to process
>> wide band data. And you mention 70 MHz to 6 GHz.
>>
>> Even with RFNOC there is a limitation on the amount of data you can
>> process simultaneously, and that is about 200 MHz. There is no way possible
>> to simultaneously process a 6GHz band with one host and radio. You would
>> need an array of radios.
>>
>> Please provide more details on design requirements, it hard to understand
>> what you are trying to accomplish.
>>
>> On Wed, Jun 13, 2018 at 8:46 AM, Ivan Zahartchuk 
>> wrote:
>>
>>> In the future, I would also like to use the RFNoC
>>>
>>> 2018-06-13 17:42 GMT+03:00 Ivan Zahartchuk :
>>>
 I need to rebuild the frequency, do fft and then transfer the whole
 array from 70 to 6GHz to the host machine. I do not quite imagine how
 you can do this with standard blocks in gnuradio.


 2018-06-13 17:32 GMT+03:00 Müller, Marcus (CEL) :

> Dear Ivan,
>
> you don't pass data to a block yourself.
>
> You write a block that does a clearly-limited signal processing job,
> and use GNU Radio to connect that to other blocks:
>
> https://tutorials.gnuradio.org
>
> In your case, instantiating a USRP source in your block makes
> absolutely no sense, for example. You'd build a flow graph containing
> the USRP source, and your custom-written block, and you'd connect these
> two.
>
> It's sadly not really clear what you want to achieve, so I'm afraid I'm
> not able to help you here.
>
> Generally, GNU Radio pretty much takes the idea of "draw a block
> diagram of what you want to achieve with your signal processing", and
> directly translates it to "using existing blocks and writing new ones,
> and letting GNU Radio take care of how the data gets around".
>
> Also, wideband signal processing and implementing a sync_block in
> Python... do not work well together.
>
> So, I think you might really be a bit confused about the architecture
> of GNU Radio – I really hope the tutorials explain that better than I
> could.
>
> Best regards,
> Marcus
>
> On Wed, 2018-06-13 at 17:16 +0300, Ivan Zahartchuk wrote:
> > Hello. I'm trying to write a block in gnuradio for broadband
> reception.
> >  The main problem at the moment is to transfer data to the fft
> block.
> > I'm new to python and so it's hard for me to figure this out.import
> numpy as np
> >
> > I need an array of data to pass to the gnuradio.fft.fft.vcc block
> >
> > from gnuradio import gr
> > from gnuradio import uhd
> > from gnuradio import fft
> >
> > class blk(gr.sync_block):  # other base classes are basic_block,
> decim_block, interp_block
> > """Embedded Python Block example - a simple multiply const"""
> >
> > def __init__(self, 
> > gain=1.0,start_freq=70e6,stop_freq=6000e6,samp_rate=30e6):
> # only default arguments here
> > """arguments to this function show up as parameters in GRC"""
> > gr.sync_block.__init__(
> > self,
> > name='Python Block',   # will show up in GRC
> > in_sig=None,
> > out_sig=[np.complex64,np.complex64]
> > )
> > # if an attribute with the same name as a parameter is found,
> > # a callback is registered (properties work, too).
> > self.gain = gain
> > self.start_freq=start_freq
> > self.stop_freq=stop_freq
> > self.samp_rate=samp_rate
> > self.uhd_usrp_source_0 = uhd.usrp_source(",".join(("", "")),
> >  uhd.stream_args(
> >
> cpu_format="fc32",
> >
> otw_format="sc16",
> >
> chanels=range(1),
> >  ),
> >  )
> >
> >
> > self.uhd_usrp_source_0.set_clock_rate(30e6, uhd.ALL_MBOARDS)
> > self.uhd_usrp_source_0.set_samp_rate(self.samp_rate)
> > self.uhd_usrp_source_0.set_gain(self.gain, 0)
> > self.uhd_usrp_source_0.set_antenna("RX2", 0)
> > self.uhd_usrp_source_0.set_bandwidth(30e6, 0)
> > self.range_freq=

Re: [Discuss-gnuradio] GNURadio Help

[CEL]

Ivan,

the E310 is a very special USRP as it not only requires you to
understand radio, software, digital signal processing and development,
but also embedded hardware development and efficiently also FPGA
design. Are you *sure* you want to start with that? Without meaning to
cause any offense, this is a bigger project than you realize that
you're about to take on.
None of the things I explained before will work, because the E310's CPU
is simply too weak to get 30 MS/s out of the digital logic, let alone
do any processing on them.

This, by the way also answers John's question: Ivan's got to do the
processing in the radio, as the host computer is the E310's ARM CPU and
that can't even handle the memory bandwidth of 30 MS/s at 32 bit per
sample, but needs it to be broken down to a much smaller amount of
data. Also, since the E310 is one of the USRPs that cannot do tuned
commands, throwing away data in the FPGA before it even reaches the FFT
(which also has to happen in the FPGA) is kind of a necessity.

So, if you don't want to dive right into FPGA developement (and I
strongly recommend you don't!), you'll need to reduce your expectations
to doing maybe 1 MHz at once, because that's what your CPU will be able
to process in software with an FFT of any significant size.

So, the closest to what you want exists in the shape of RFNoC Fosphor
architecture: It sends FFT'ed, magnitude-squared, logarithmized, even
practically color-mapped values and thus can achieve good bandwidth
even on an E310. Adding the tuning and frequency coordination logic
would, on the other hand, really require a lot of work in the FPGA, and
it'll have nothing to do with GNU Radio.

If you want my personal opinion: Start with a different device.
Learning about GNU Radio, DSP, SDR is hard enough. Don't add FPGAs,
embedded devices and mandatory RFNoC to it for a start.

Best regards,
Marcus

On Wed, 2018-06-13 at 09:11 -0600, John Medrano wrote:
> This is much more doable. 
> 
> May I ask why you want to buffer all the data in the radio?
> 
> On Wed, Jun 13, 2018 at 9:06 AM, Ivan Zahartchuk  wrote:
> > I want to process not 6GHz but 30 MHz at a time. Ie I read 30 MHz at a 
> > frequency of 400 MHz (for example) then I do 30 MHz FFT and write them to 
> > the buffer. And so up to 6GHz. Then when the buffer is full, I transfer the 
> > data to the host machine (I use the USRP E310 board) to display the data.
> > In fact, it should be such a broadband spectrum analyzer not in real time.
> > 
> > 2018-06-13 17:57 GMT+03:00 John Medrano :
> > > Hello.
> > > 
> > > If I understand what you are saying correctly, you would like to process 
> > > wide band data. And you mention 70 MHz to 6 GHz. 
> > > 
> > > Even with RFNOC there is a limitation on the amount of data you can 
> > > process simultaneously, and that is about 200 MHz. There is no way 
> > > possible to simultaneously process a 6GHz band with one host and radio. 
> > > You would need an array of radios. 
> > > 
> > > Please provide more details on design requirements, it hard to understand 
> > > what you are trying to accomplish. 
> > > 
> > > On Wed, Jun 13, 2018 at 8:46 AM, Ivan Zahartchuk  
> > > wrote:
> > > > In the future, I would also like to use the RFNoC
> > > > 
> > > > 2018-06-13 17:42 GMT+03:00 Ivan Zahartchuk :
> > > > > I need to rebuild the frequency, do fft and then transfer the whole 
> > > > > array from 70 to 6GHz to the host machine. I do not quite imagine how 
> > > > > you can do this with standard blocks in gnuradio.
> > > > > 
> > > > > 
> > > > > 2018-06-13 17:32 GMT+03:00 Müller, Marcus (CEL) :
> > > > > > Dear Ivan,
> > > > > > 
> > > > > > you don't pass data to a block yourself. 
> > > > > > 
> > > > > > You write a block that does a clearly-limited signal processing job,
> > > > > > and use GNU Radio to connect that to other blocks:
> > > > > > 
> > > > > > https://tutorials.gnuradio.org
> > > > > > 
> > > > > > In your case, instantiating a USRP source in your block makes
> > > > > > absolutely no sense, for example. You'd build a flow graph 
> > > > > > containing
> > > > > > the USRP source, and your custom-written block, and you'd connect 
> > > > > > these
> > > > > > two.
> > > > > > 
> > > > > > It's sadly not really clear what you want to achieve, so I'm afraid 
> > > > > > I'm
> > > > > > not able to help you here.
> > > > > > 
> > > > > > Generally, GNU Radio pretty much takes the idea of "draw a block
> > > > > > diagram of what you want to achieve with your signal processing", 
> > > > > > and
> > > > > > directly translates it to "using existing blocks and writing new 
> > > > > > ones,
> > > > > > and letting GNU Radio take care of how the data gets around".
> > > > > > 
> > > > > > Also, wideband signal processing and implementing a sync_block in
> > > > > > Python... do not work well together.
> > > > > > 
> > > > > > So, I think you might really be a bit confused about the 
> > > > > > architecture
> > > > > > of GNU Radio – I really hope 

Re: [Discuss-gnuradio] GNURadio Help

[John Medrano]

Hello,

I see you are  using an E310, now this seems to make a bit more sense as to
what you are trying to do.

Although you can use RFNOC to increase the processor ability to do FFT
function, it is actually not needed for initial testing. In GNU radio,
there are many ways to enhance your design, but there is a simple approach
that will work.

RADIO->STREAM TO VECTOR->FFT->CUSTOM BLOCK

The FFT block will pass data to your custom blocks of X data points. Where
X is your FFT Size.

Your custom block would then store 1 block of X data points, and then set a
flag to indicate that it has data. So your custom block should have
functions to check flag and retrieve data.
 The rest of the work you can do in Python.

while 1:
tb.start()
time.sleep(1.0)
tb.stop()
tb.wait()
tb.store_data()
tb.change_freq()

tb.store_data() will check your custom block to see if data there, and if
yes will store it to file in whatever format you want. tb.change_freq()
will basically change the frequency of radio component to new frequency
setting. You would need to add code in Python that transmits to host when
all data blocks have been collected.

One big problem with E310 though, I doubt if you are going to be able to
process with a sample rate of 30 MHz. You may have to go down to as low as
5 MHz. The only approach that would increase band width would to move your
custom block and FFT back into FPGA with RFNOC. But this is very complex
endeavor.


On Wed, Jun 13, 2018 at 9:06 AM, Ivan Zahartchuk 
wrote:

> I want to process not 6GHz but 30 MHz at a time. Ie I read 30 MHz at a
> frequency of 400 MHz (for example) then I do 30 MHz FFT and write them to
> the buffer. And so up to 6GHz. Then when the buffer is full, I transfer
> the data to the host machine (I use the USRP E310 board) to display the
> data.
> In fact, it should be such a broadband spectrum analyzer not in real time.
>
> 2018-06-13 17:57 GMT+03:00 John Medrano :
>
>> Hello.
>>
>> If I understand what you are saying correctly, you would like to process
>> wide band data. And you mention 70 MHz to 6 GHz.
>>
>> Even with RFNOC there is a limitation on the amount of data you can
>> process simultaneously, and that is about 200 MHz. There is no way possible
>> to simultaneously process a 6GHz band with one host and radio. You would
>> need an array of radios.
>>
>> Please provide more details on design requirements, it hard to understand
>> what you are trying to accomplish.
>>
>> On Wed, Jun 13, 2018 at 8:46 AM, Ivan Zahartchuk 
>> wrote:
>>
>>> In the future, I would also like to use the RFNoC
>>>
>>> 2018-06-13 17:42 GMT+03:00 Ivan Zahartchuk :
>>>
 I need to rebuild the frequency, do fft and then transfer the whole
 array from 70 to 6GHz to the host machine. I do not quite imagine how
 you can do this with standard blocks in gnuradio.


 2018-06-13 17:32 GMT+03:00 Müller, Marcus (CEL) :

> Dear Ivan,
>
> you don't pass data to a block yourself.
>
> You write a block that does a clearly-limited signal processing job,
> and use GNU Radio to connect that to other blocks:
>
> https://tutorials.gnuradio.org
>
> In your case, instantiating a USRP source in your block makes
> absolutely no sense, for example. You'd build a flow graph containing
> the USRP source, and your custom-written block, and you'd connect these
> two.
>
> It's sadly not really clear what you want to achieve, so I'm afraid I'm
> not able to help you here.
>
> Generally, GNU Radio pretty much takes the idea of "draw a block
> diagram of what you want to achieve with your signal processing", and
> directly translates it to "using existing blocks and writing new ones,
> and letting GNU Radio take care of how the data gets around".
>
> Also, wideband signal processing and implementing a sync_block in
> Python... do not work well together.
>
> So, I think you might really be a bit confused about the architecture
> of GNU Radio – I really hope the tutorials explain that better than I
> could.
>
> Best regards,
> Marcus
>
> On Wed, 2018-06-13 at 17:16 +0300, Ivan Zahartchuk wrote:
> > Hello. I'm trying to write a block in gnuradio for broadband
> reception.
> >  The main problem at the moment is to transfer data to the fft
> block.
> > I'm new to python and so it's hard for me to figure this out.import
> numpy as np
> >
> > I need an array of data to pass to the gnuradio.fft.fft.vcc block
> >
> > from gnuradio import gr
> > from gnuradio import uhd
> > from gnuradio import fft
> >
> > class blk(gr.sync_block):  # other base classes are basic_block,
> decim_block, interp_block
> > """Embedded Python Block example - a simple multiply const"""
> >
> > def __init__(self, 
> > gain=1.0,start_freq=70e6,stop_freq=6000e6,samp_rate=30e6):
> # only default

[Discuss-gnuradio] Performance Monitor rpcmanager runtime error

[Jim Larsen]

I installed GNU Radio 3.7.11 on Ubuntu 18.04 from the Ubuntu repository. I 
added a CtrlPort Performance Monitor block to a simple Signal Source > Throttle 
> Null Sink flow graph to visualize block performance. When I run the flow 
graph, I get the following runtime error:

python: 
/build/gnuradio-BBYmSv/gnuradio-3.7.11/gnuradio-runtime/lib/controlport/rpcmanager.cc:40
 : static rpcserver_booter_base* rpcmanager::get(): 
Assertion `booter_registered || aggregator_registered' failed.

How can I fix this error?

Thanks,

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

Re: [Discuss-gnuradio] [USRP-users] TX-RX file through OFDM errors

[Martin Braun]

On 06/12/2018 10:28 AM, Ayaz Mahmud via USRP-users wrote:
> Hi,
> 
>  
> 
> I am trying to transmit and receive a .png file through OFDM (*Block
> diagram attached*). The file size is only 1.5kB. While running I am
> getting the below warning & error in console. Can someone point out the
> reason behind the error and what I am doing wrong. I am a beginner and
> just started to learn the Gnuradio from tutorials.
> 
>  
> 
> linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown
> [...]
> UHD Error:
> 
>     recv packet demuxer unexpected sid 0x330006
> 
>  
> 
> UHD Error:
> 
>     recv packet demuxer unexpected sid 0x49bf846e

Is this a B210/B200, and does it work with other examples?

-- M

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

Re: [Discuss-gnuradio] GNURadio Help

[Ivan Zahartchuk]

 I'm still interested in the principle of the UHD_Source unit.
 "Start continuous" tells the device to stream samples indefinitely.
 "Stop continuous" tells the device to end continuous streaming.
 "Num sams and done" tells the device to stream num sams and to not
expect a future stream command for contiguous samples.
 "Num samps and more" tells the device to stream num sams and to expect
a future stream command for contiguous samples.
I made such a receiver on python_und and I could get to see 4Ghz for 120ms
using the B200

2018-06-13 18:46 GMT+03:00 John Medrano :

> Hello,
>
> I see you are  using an E310, now this seems to make a bit more sense as
> to what you are trying to do.
>
> Although you can use RFNOC to increase the processor ability to do FFT
> function, it is actually not needed for initial testing. In GNU radio,
> there are many ways to enhance your design, but there is a simple approach
> that will work.
>
> RADIO->STREAM TO VECTOR->FFT->CUSTOM BLOCK
>
> The FFT block will pass data to your custom blocks of X data points. Where
> X is your FFT Size.
>
> Your custom block would then store 1 block of X data points, and then set
> a flag to indicate that it has data. So your custom block should have
> functions to check flag and retrieve data.
>  The rest of the work you can do in Python.
>
> while 1:
> tb.start()
> time.sleep(1.0)
> tb.stop()
> tb.wait()
> tb.store_data()
> tb.change_freq()
>
> tb.store_data() will check your custom block to see if data there, and if
> yes will store it to file in whatever format you want. tb.change_freq()
> will basically change the frequency of radio component to new frequency
> setting. You would need to add code in Python that transmits to host when
> all data blocks have been collected.
>
> One big problem with E310 though, I doubt if you are going to be able to
> process with a sample rate of 30 MHz. You may have to go down to as low as
> 5 MHz. The only approach that would increase band width would to move your
> custom block and FFT back into FPGA with RFNOC. But this is very complex
> endeavor.
>
>
> On Wed, Jun 13, 2018 at 9:06 AM, Ivan Zahartchuk 
> wrote:
>
>> I want to process not 6GHz but 30 MHz at a time. Ie I read 30 MHz at a
>> frequency of 400 MHz (for example) then I do 30 MHz FFT and write them to
>> the buffer. And so up to 6GHz. Then when the buffer is full, I transfer
>> the data to the host machine (I use the USRP E310 board) to display the
>> data.
>> In fact, it should be such a broadband spectrum analyzer not in real time.
>>
>> 2018-06-13 17:57 GMT+03:00 John Medrano :
>>
>>> Hello.
>>>
>>> If I understand what you are saying correctly, you would like to process
>>> wide band data. And you mention 70 MHz to 6 GHz.
>>>
>>> Even with RFNOC there is a limitation on the amount of data you can
>>> process simultaneously, and that is about 200 MHz. There is no way possible
>>> to simultaneously process a 6GHz band with one host and radio. You would
>>> need an array of radios.
>>>
>>> Please provide more details on design requirements, it hard to
>>> understand what you are trying to accomplish.
>>>
>>> On Wed, Jun 13, 2018 at 8:46 AM, Ivan Zahartchuk 
>>> wrote:
>>>
 In the future, I would also like to use the RFNoC

 2018-06-13 17:42 GMT+03:00 Ivan Zahartchuk :

> I need to rebuild the frequency, do fft and then transfer the whole
> array from 70 to 6GHz to the host machine. I do not quite imagine how
> you can do this with standard blocks in gnuradio.
>
>
> 2018-06-13 17:32 GMT+03:00 Müller, Marcus (CEL) :
>
>> Dear Ivan,
>>
>> you don't pass data to a block yourself.
>>
>> You write a block that does a clearly-limited signal processing job,
>> and use GNU Radio to connect that to other blocks:
>>
>> https://tutorials.gnuradio.org
>>
>> In your case, instantiating a USRP source in your block makes
>> absolutely no sense, for example. You'd build a flow graph containing
>> the USRP source, and your custom-written block, and you'd connect
>> these
>> two.
>>
>> It's sadly not really clear what you want to achieve, so I'm afraid
>> I'm
>> not able to help you here.
>>
>> Generally, GNU Radio pretty much takes the idea of "draw a block
>> diagram of what you want to achieve with your signal processing", and
>> directly translates it to "using existing blocks and writing new ones,
>> and letting GNU Radio take care of how the data gets around".
>>
>> Also, wideband signal processing and implementing a sync_block in
>> Python... do not work well together.
>>
>> So, I think you might really be a bit confused about the architecture
>> of GNU Radio – I really hope the tutorials explain that better than I
>> could.
>>
>> Best regards,
>> Marcus
>>
>> On Wed, 2018-06-13 at 17:16 +0300, Ivan Zahartchuk wrote:
>> > Hello. 

Re: [Discuss-gnuradio] GNURadio Help

[Ivan Zahartchuk]

N200

2018-06-14 8:58 GMT+03:00 Ivan Zahartchuk :

> I'm still interested in the principle of the UHD_Source unit.
>  "Start continuous" tells the device to stream samples indefinitely.
>  "Stop continuous" tells the device to end continuous streaming.
>  "Num sams and done" tells the device to stream num sams and to not
> expect a future stream command for contiguous samples.
>  "Num samps and more" tells the device to stream num sams and to
> expect a future stream command for contiguous samples.
> I made such a receiver on python_und and I could get to see 4Ghz for 120ms
> using the B200
>
> 2018-06-13 18:46 GMT+03:00 John Medrano :
>
>> Hello,
>>
>> I see you are  using an E310, now this seems to make a bit more sense as
>> to what you are trying to do.
>>
>> Although you can use RFNOC to increase the processor ability to do FFT
>> function, it is actually not needed for initial testing. In GNU radio,
>> there are many ways to enhance your design, but there is a simple approach
>> that will work.
>>
>> RADIO->STREAM TO VECTOR->FFT->CUSTOM BLOCK
>>
>> The FFT block will pass data to your custom blocks of X data points.
>> Where X is your FFT Size.
>>
>> Your custom block would then store 1 block of X data points, and then set
>> a flag to indicate that it has data. So your custom block should have
>> functions to check flag and retrieve data.
>>  The rest of the work you can do in Python.
>>
>> while 1:
>> tb.start()
>> time.sleep(1.0)
>> tb.stop()
>> tb.wait()
>> tb.store_data()
>> tb.change_freq()
>>
>> tb.store_data() will check your custom block to see if data there, and if
>> yes will store it to file in whatever format you want. tb.change_freq()
>> will basically change the frequency of radio component to new frequency
>> setting. You would need to add code in Python that transmits to host when
>> all data blocks have been collected.
>>
>> One big problem with E310 though, I doubt if you are going to be able to
>> process with a sample rate of 30 MHz. You may have to go down to as low as
>> 5 MHz. The only approach that would increase band width would to move your
>> custom block and FFT back into FPGA with RFNOC. But this is very complex
>> endeavor.
>>
>>
>> On Wed, Jun 13, 2018 at 9:06 AM, Ivan Zahartchuk 
>> wrote:
>>
>>> I want to process not 6GHz but 30 MHz at a time. Ie I read 30 MHz at a
>>> frequency of 400 MHz (for example) then I do 30 MHz FFT and write them to
>>> the buffer. And so up to 6GHz. Then when the buffer is full, I transfer
>>> the data to the host machine (I use the USRP E310 board) to display the
>>> data.
>>> In fact, it should be such a broadband spectrum analyzer not in real
>>> time.
>>>
>>> 2018-06-13 17:57 GMT+03:00 John Medrano :
>>>
 Hello.

 If I understand what you are saying correctly, you would like to
 process wide band data. And you mention 70 MHz to 6 GHz.

 Even with RFNOC there is a limitation on the amount of data you can
 process simultaneously, and that is about 200 MHz. There is no way possible
 to simultaneously process a 6GHz band with one host and radio. You would
 need an array of radios.

 Please provide more details on design requirements, it hard to
 understand what you are trying to accomplish.

 On Wed, Jun 13, 2018 at 8:46 AM, Ivan Zahartchuk 
 wrote:

> In the future, I would also like to use the RFNoC
>
> 2018-06-13 17:42 GMT+03:00 Ivan Zahartchuk :
>
>> I need to rebuild the frequency, do fft and then transfer the whole
>> array from 70 to 6GHz to the host machine. I do not quite imagine
>> how you can do this with standard blocks in gnuradio.
>>
>>
>> 2018-06-13 17:32 GMT+03:00 Müller, Marcus (CEL) :
>>
>>> Dear Ivan,
>>>
>>> you don't pass data to a block yourself.
>>>
>>> You write a block that does a clearly-limited signal processing job,
>>> and use GNU Radio to connect that to other blocks:
>>>
>>> https://tutorials.gnuradio.org
>>>
>>> In your case, instantiating a USRP source in your block makes
>>> absolutely no sense, for example. You'd build a flow graph containing
>>> the USRP source, and your custom-written block, and you'd connect
>>> these
>>> two.
>>>
>>> It's sadly not really clear what you want to achieve, so I'm afraid
>>> I'm
>>> not able to help you here.
>>>
>>> Generally, GNU Radio pretty much takes the idea of "draw a block
>>> diagram of what you want to achieve with your signal processing", and
>>> directly translates it to "using existing blocks and writing new
>>> ones,
>>> and letting GNU Radio take care of how the data gets around".
>>>
>>> Also, wideband signal processing and implementing a sync_block in
>>> Python... do not work well together.
>>>
>>> So, I think you might really be a bit confused about the architecture
>>> of GNU Radio – I real