GNU Radio, One Step at a Time: September 2011

Friday, September 30, 2011

Re: [Discuss-gnuradio] Uninstalling UHD

> This is the FAQ for removing gnuradio install. Same rules apply to UHD,
> and anything else really:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#The-problem-of-multiple-installs
>
> -josh
>
I've found that if you started-out using build-gnuradio, you can
continue to use it ad-infinitum, without having to uninstall between.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] Receiving On-Off-Keyed Signal

On Fri, Sep 30, 2011 at 5:59 AM, Guido Schmitz <g.schmitz@gtrs.de> wrote:
> Hello,
>
> I am trying to receive an on-off-keyed signal at 25kHz with USRP N210
> and Gnuradio.
> The connection between N210 and Gnuradio works - I am able to visualize
> it with the waterfall and the fft-sink.
>
> I want to convert the signal to a time-discrete bitstream, where I have
> 1 for signal on and 0 for signal off. The switching between the two
> states in the signal is very fast - only a few oscillations long.
>
> How can I do this with Gnuradio?

You'll need to follow the standard digital receiver dataflow model:

(filtering)-->(demodulation)-->(clock recovery)-->(slicing)

So you can use a clock recovery block in Gnuradio (either the Mueller
and Muller or the polyphase clock recovery blocks) followed by
something to slice (determine whether a particular sample represents a
1 or a 0). One easy way to slice OOK data is to use a single-pole IIR
or moving-average filter to get the DC level of the signal (assuming
the signal is encoded to spend equal time high and low), subtract that
from the original signal, and then just use the simple slicer in
Gnuradio (which returns 1 if the signal level is >0, 0 otherwise) to
convert to bits.

HTH,
Nick

>
> Kind regards,
>
> Guido
>
> _______________________________________________
> 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] Uninstalling UHD

On 09/30/2011 09:17 AM, sirjanselot wrote:
>
> Hello,
>
> How can I uninstall UHD drivers? I would like to upgrade to the new ones
> that were recently released.
>
> I tried to make uninstall but that doesn't work.
>
> - Jan

This is the FAQ for removing gnuradio install. Same rules apply to UHD,
and anything else really:

http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#The-problem-of-multiple-installs

-josh

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

[Discuss-gnuradio] Uninstalling UHD

Hello,

How can I uninstall UHD drivers? I would like to upgrade to the new ones
that were recently released.

I tried to make uninstall but that doesn't work.

- Jan
--
View this message in context: http://old.nabble.com/Uninstalling-UHD-tp32570056p32570056.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

[Discuss-gnuradio] Decoding GSM uplink signals

Hi,

I wonder if any of you guys knows a method to decode uplink GSM signals. I have previoulsy used Airprobe to decode downlink signals, but it does not work with uplink signals. I was using the following scheme:

USRPN210--->gsm-receiver/gsmtvoid---->gsmdecode/Wireshark

My approach is to modify gsm-receiver block to adapt it to uplink and to frequency hopping, and I think that I can solve this issue. But when it comes to decode the signals...I do not have any idea on how to change gsmdecode to decode uplink signals. I also wonder if Wireshark is capable to do that.

Any idea/advise?

Re: [Discuss-gnuradio] USRP network based spectrum analyzer

Thanks Marcus!

I took your idea and ran with it but encountered a funny issue. I'm slightly confused about the output of the logpwrfft (which is giving me the output of gr_fft_vcc). I've been assuming that logpwrfft returns a vector of amplitudes in dB for each fft bin. Lets say my fft size is 1024, I'm assuming vector index 0 is the lowest frequency and vector index 1023 is the maximum frequency. In plotting these values it appears to be something different.

It goes from DC-bandwidth/2, then -bandwidth/2 to DC--standard form of the underlying FFTW library.

I can only guess vector index 0 is the center frequency, index 511 is the max frequency and index 512 is the min frequency. Digging around gr_fft_vcc and I didn't see an obvious answer. Any insight into what the fft is doing here? Thanks!

-Phelps

On Wed, Sep 28, 2011 at 2:35 PM, Marcus D. Leech <mleech@ripnet.com> wrote:

On 28/09/2011 4:50 PM, Phelps Williams wrote:

I have a usrp and computer in a remote location without much network bandwidth available to the system and I'm using it as a spectrum analyzer. I'd like to run the fft on the remote system and then send the results to a connected client for display. This would allow me to get greater fidelity than xwindows forwarding or the ascii dft example while also using less bandwidth. I would imagine the client side would potentially reuse some of the existing wx or qt interfaces for display and control.

This seems like a pretty useful / simple use of this hardware. Does anybody know of any implementations floating around that does this? I'd prefer not to reinvent the wheel.

-Phelps

Because I'm such an insanely nice guy, I quickly implemented something like what you'd need. Attached.

It uses a UHD source, computes a (default 2048-point) 10*log10-scaled FFT, then outputs the resulting float-vector to a file-sink at a 5Hz rate.

Everything is pretty-much parameterized on the command line, including:

frequency (100M)
gain (20)
srate (1.0e6)
fifoname ("fft_output_fifo")
devicecfg ("addr=192.168.10.2")
xmlport (6060)

I've included the ability to change parameters on-the-fly using the XMLRPC server, which would allow you to, for example, change
run-time parameters from some external interface, such as a WEB gui or similar.

If this were my problem, I'd start this thing in a script which creates the fifo file, starts some program that reads the FIFO (left as an
exercise for the proverbial reader) in the background, then calls the Gnu Radio program.

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

--  Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org

[Discuss-gnuradio] Receiving On-Off-Keyed Signal

Hello,

I am trying to receive an on-off-keyed signal at 25kHz with USRP N210
and Gnuradio.
The connection between N210 and Gnuradio works - I am able to visualize
it with the waterfall and the fft-sink.

I want to convert the signal to a time-discrete bitstream, where I have
1 for signal on and 0 for signal off. The switching between the two
states in the signal is very fast - only a few oscillations long.

How can I do this with Gnuradio?

Kind regards,

Guido

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

[Discuss-gnuradio] UHD RFID projects

Hi All

I have located 2 GNU Radio projects on the cgran project page[1][2]

The files seem to be configured for the USRP2 device however I have an N210. I have tried changing to source information on the scripts to use the UHD source however im getting a whole host of type missmatch errors.

Firstly are there any UHD rfid projects, or are there any decent tutorials on converting projects to use the UHD driver or even converting a .py to a .grc file.

Many Thanks

[1]https://www.cgran.org/wiki/Gen2Listener
[2]https://www.cgran.org/wiki/Gen2

Thursday, September 29, 2011

Re: [Discuss-gnuradio] USRP network based spectrum analyzer

Thanks Marcus!

I took your idea and ran with it but encountered a funny issue. I'm slightly confused about the output of the logpwrfft (which is giving me the output of gr_fft_vcc). I've been assuming that logpwrfft returns a vector of amplitudes in dB for each fft bin. Lets say my fft size is 1024, I'm assuming vector index 0 is the lowest frequency and vector index 1023 is the maximum frequency. In plotting these values it appears to be something different.

I can only guess vector index 0 is the center frequency, index 511 is the max frequency and index 512 is the min frequency. Digging around gr_fft_vcc and I didn't see an obvious answer. Any insight into what the fft is doing here? Thanks!

-Phelps

On Wed, Sep 28, 2011 at 2:35 PM, Marcus D. Leech <mleech@ripnet.com> wrote:

On 28/09/2011 4:50 PM, Phelps Williams wrote:

I have a usrp and computer in a remote location without much network bandwidth available to the system and I'm using it as a spectrum analyzer. I'd like to run the fft on the remote system and then send the results to a connected client for display. This would allow me to get greater fidelity than xwindows forwarding or the ascii dft example while also using less bandwidth. I would imagine the client side would potentially reuse some of the existing wx or qt interfaces for display and control.

This seems like a pretty useful / simple use of this hardware. Does anybody know of any implementations floating around that does this? I'd prefer not to reinvent the wheel.

-Phelps

Because I'm such an insanely nice guy, I quickly implemented something like what you'd need. Attached.

It uses a UHD source, computes a (default 2048-point) 10*log10-scaled FFT, then outputs the resulting float-vector to a file-sink at a 5Hz rate.

Everything is pretty-much parameterized on the command line, including:

frequency (100M)
gain (20)
srate (1.0e6)
fifoname ("fft_output_fifo")
devicecfg ("addr=192.168.10.2")
xmlport (6060)

I've included the ability to change parameters on-the-fly using the XMLRPC server, which would allow you to, for example, change
run-time parameters from some external interface, such as a WEB gui or similar.

If this were my problem, I'd start this thing in a script which creates the fifo file, starts some program that reads the FIFO (left as an
exercise for the proverbial reader) in the background, then calls the Gnu Radio program.

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

Re: [Discuss-gnuradio] different CPU loads with 2 similar GRC graphs

On Thu, Sep 22, 2011 at 1:41 AM, Achilleas Anastasopoulos
<anastas@umich.edu> wrote:
> I am comparing the following 2 systems on GRC:
>
> [source] --> [block A] --> [sink]
>
> and
>
> [source] --> [block A] -->[sink]
> |___________________^
>
> where [block A] is a very CPU-intensive SP block, source and sink are
> very simple SP blocks,
> and neither source nor sink set the sample rate, neither do i have any
> throttle in the graph (intentionally).
>
> When I run the first configuration on a 2-core machine
> I get 2 CPU traces that alternate between 100% and 20%
> for large chunks of time which means that the thread that is running
> A overwhelms the system.
>
> So far so good.
>
> When I run the second configuraiton i get 2 CPU traces that alternate
> around a load of
> 65% without any of them touching 100% (except occasionally) which seems like a
> more "normal" situation.
>
> So I have 2 questions:
>
> 1) why is it that the system does not "crash" even in the absense of a throttle?
> 2) why is it that the 2nd configuration results in a lower overall load?

Then I guess that your sink is getting twice the amount of data in the
second graph. As the sink is now slower tahn source, it drives the
pipeline. Then your block A gets samples at half rate. First graph is
100%+20% = 120%. If block A uses all CPU power, then the second graph
should use around 120% / 2 = 60%.

Does it makes sense?

Pascal

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

Re: [Discuss-gnuradio] C++ block that generate extra data

I think you should tell it in the constructor.
like this:

#define NR_OF_WORDS_ADDITIONALLY_NEEDED 4

my_usrp_rx_tx::my_usrp_rx_tx(void) : gr_block("my_usrp_rx_tx",
gr_make_io_signature(1, 1, sizeof(short)),
gr_make_io_signature(1, 1, sizeof(short)))
{
set_output_multiple(NR_OF_WORDS_ADDITIONALLY_NEEDED);
}

Then in general work function, for example, you can increment "manually" 4
words before your out buffer will say "bang".

Patrik

----- Original Message -----
From: "Mattia Rizzi" <mattia.rizzi@gmail.com>
To: "gnu radio" <discuss-gnuradio@gnu.org>
Sent: Thursday, September 29, 2011 19:04
Subject: Re: [Discuss-gnuradio] C++ block that generate extra data

> Thank you for the reply.
> How can i reallocate the output buffer if is too small?
> Let's assume that my block has an input itemsize of 3 byte and an output
> itemsize of 4 byte. Forecast with 1:1.
> If the scheduler keeps to give to my block only 4 bytes for output, how
> can i force to give me more?
> Thanks
>
> -----Messaggio originale-----
> From: Martin Braun
> Sent: Thursday, September 29, 2011 4:20 PM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] C++ block that generate extra data
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] C++ block that generate extra data

Thank you for the reply.
How can i reallocate the output buffer if is too small?
Let's assume that my block has an input itemsize of 3 byte and an output
itemsize of 4 byte. Forecast with 1:1.
If the scheduler keeps to give to my block only 4 bytes for output, how can
i force to give me more?
Thanks

-----Messaggio originale-----
From: Martin Braun
Sent: Thursday, September 29, 2011 4:20 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] C++ block that generate extra data

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

Re: [Discuss-gnuradio] USRP network based spectrum analyzer

On 9/28/11 4:54 PM, Marcus D. Leech wrote:
> On 28/09/2011 4:50 PM, Phelps Williams wrote:
>> I have a usrp and computer in a remote location without much network
>> bandwidth available to the system and I'm using it as a spectrum
>> analyzer. I'd like to run the fft on the remote system and then send
>> the results to a connected client for display. This would allow me to
>> get greater fidelity than xwindows forwarding or the ascii dft example
>> while also using less bandwidth. I would imagine the client side
>> would potentially reuse some of the existing wx or qt interfaces for
>> display and control.
>>
>> This seems like a pretty useful / simple use of this hardware. Does
>> anybody know of any implementations floating around that does this?
>> I'd prefer not to reinvent the wheel.
>>
>> -Phelps
>>
> You could use a GRC-based flow-graph that computes the FFT, and outputs
> the results to a FIFO, and have a small C program that simply puts
> "snapshots" in an appropriate place. Once it's in an "appropriate
> place" (and perhaps in a form that you like), you could use a web server
> to observe the results. Roughly 1e6 ways of skinning this particular
> cat.

Why not just use VNC? Its generally much lower bandwidth than X forwarding.

@(^.^)@ Ed

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

Re: [Discuss-gnuradio] USRP network based spectrum analyzer

On 29/09/2011 11:02 AM, Ed Criscuolo wrote:
>
>
> Why not just use VNC? It's generally much lower bandwidth than X
> forwarding.
>
That hasn't been my experience at all.

And it's reasonable to want a "remote sniffer" type of situation that
you could reasonably access via the web or similar.

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

Re: [Discuss-gnuradio] C++ block that generate extra data

On Thu, Sep 29, 2011 at 04:14:04PM +0200, Mattia Rizzi wrote:
> Hello,
>
> i have a block that takes 3 bytes of data in and output 4bytes of data (3:4).
>
> It's possible to generate, sometimes, extra output?
>
> I mean, sometimes it take 3 bytes and output 5 bytes. It's possible? How i tell
> to the scheduler?

That's possible if you create a gr_block and use the general_work()
function (so don't derive from a sync_interpolator).
The general_work() function lets you manually set how many bytes were
consumed and how many were written to the output buffer. But you *must*
check the output buffer's large enough.

However, you sacrifice some performance and possibly some functionality
of GNU Radio (e.g., IIRC, I don't think you could propagate stream tags
automatically through this kind of block).

Perhaps re-thinking your signal flow is more optimal.

MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

[Discuss-gnuradio] C++ block that generate extra data

Hello,

i have a block that takes 3 bytes of data in and output 4bytes of data (3:4).

It's possible to generate, sometimes, extra output?

I mean, sometimes it take 3 bytes and output 5 bytes. It's possible? How i tell to the scheduler?

Thank you

Wednesday, September 28, 2011

[Discuss-gnuradio] build-gnuradio updated

http://www.sbrac.org/files/build-gnuradio

I changed the "configure" to use "--disable-volk" for now, since volk
isn't building right now in some scenarios.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

from gnuradio import blks2
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import uhd
from gnuradio.eng_option import eng_option
from gnuradio.gr import firdes
from optparse import OptionParser
import SimpleXMLRPCServer
import threading

class uhd_fft_to_file(gr.top_block):

def __init__(self, frequency=100e6, gain=20, srate=1.0e6, xmlport=6060, fifoname="fft_output_fifo", devicecfg="addr=192.168.10.2"):
gr.top_block.__init__(self, "Uhd Fft To File")

##################################################
# Parameters
##################################################
self.frequency = frequency
self.gain = gain
self.srate = srate
self.xmlport = xmlport
self.fifoname = fifoname
self.devicecfg = devicecfg

##################################################
# Variables
##################################################
self.samp_rate = samp_rate = srate
self.fft_size = fft_size = 2048

##################################################
# Blocks
##################################################
self.xmlrpc_server_0 = SimpleXMLRPCServer.SimpleXMLRPCServer(("localhost", xmlport), allow_none=True)
self.xmlrpc_server_0.register_instance(self)
threading.Thread(target=self.xmlrpc_server_0.serve_forever).start()
self.uhd_usrp_source_0 = uhd.usrp_source(
device_addr="devicefg",
io_type=uhd.io_type.COMPLEX_FLOAT32,
num_channels=1,
)
self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_center_freq(frequency, 0)
self.uhd_usrp_source_0.set_gain(gain, 0)
self.gr_file_sink_0 = gr.file_sink(gr.sizeof_float*fft_size, fifoname)
self.gr_file_sink_0.set_unbuffered(True)
self.blks2_logpwrfft_x_0 = blks2.logpwrfft_c(
sample_rate=samp_rate,
fft_size=fft_size,
ref_scale=2,
frame_rate=5,
avg_alpha=0.1,
average=True,
)

##################################################
# Connections
##################################################
self.connect((self.uhd_usrp_source_0, 0), (self.blks2_logpwrfft_x_0, 0))
self.connect((self.blks2_logpwrfft_x_0, 0), (self.gr_file_sink_0, 0))

def get_frequency(self):
return self.frequency

def set_frequency(self, frequency):
self.frequency = frequency
self.uhd_usrp_source_0.set_center_freq(self.frequency, 0)

def get_gain(self):
return self.gain

def set_gain(self, gain):
self.gain = gain
self.uhd_usrp_source_0.set_gain(self.gain, 0)

def get_srate(self):
return self.srate

def set_srate(self, srate):
self.srate = srate
self.set_samp_rate(self.srate)

def get_xmlport(self):
return self.xmlport

def set_xmlport(self, xmlport):
self.xmlport = xmlport

def get_fifoname(self):
return self.fifoname

def set_fifoname(self, fifoname):
self.fifoname = fifoname

def get_devicecfg(self):
return self.devicecfg

def set_devicecfg(self, devicecfg):
self.devicecfg = devicecfg

def get_samp_rate(self):
return self.samp_rate

def set_samp_rate(self, samp_rate):
self.samp_rate = samp_rate
self.blks2_logpwrfft_x_0.set_sample_rate(self.samp_rate)
self.uhd_usrp_source_0.set_samp_rate(self.samp_rate)

def get_fft_size(self):
return self.fft_size

def set_fft_size(self, fft_size):
self.fft_size = fft_size

if __name__ == '__main__':
parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
parser.add_option("", "--frequency", dest="frequency", type="eng_float", default=eng_notation.num_to_str(100e6),
help="Set frequency [default=%default]")
parser.add_option("", "--gain", dest="gain", type="eng_float", default=eng_notation.num_to_str(20),
help="Set gain [default=%default]")
parser.add_option("", "--srate", dest="srate", type="eng_float", default=eng_notation.num_to_str(1.0e6),
help="Set srate [default=%default]")
parser.add_option("", "--xmlport", dest="xmlport", type="intx", default=6060,
help="Set xmlport [default=%default]")
parser.add_option("", "--fifoname", dest="fifoname", type="string", default="fft_output_fifo",
help="Set fifoname [default=%default]")
parser.add_option("", "--devicecfg", dest="devicecfg", type="string", default="addr=192.168.10.2",
help="Set devicecfg [default=%default]")
(options, args) = parser.parse_args()
tb = uhd_fft_to_file(frequency=options.frequency, gain=options.gain, srate=options.srate, xmlport=options.xmlport, fifoname=options.fifoname, devicecfg=options.devicecfg)
tb.run()

On 28/09/2011 4:50 PM, Phelps Williams wrote:
> I have a usrp and computer in a remote location without much network
> bandwidth available to the system and I'm using it as a spectrum
> analyzer. I'd like to run the fft on the remote system and then send
> the results to a connected client for display. This would allow me to
> get greater fidelity than xwindows forwarding or the ascii dft example
> while also using less bandwidth. I would imagine the client side
> would potentially reuse some of the existing wx or qt interfaces for
> display and control.
>
> This seems like a pretty useful / simple use of this hardware. Does
> anybody know of any implementations floating around that does this?
> I'd prefer not to reinvent the wheel.
>
> -Phelps
>
Because I'm such an insanely nice guy, I quickly implemented something
like what you'd need. Attached.

It uses a UHD source, computes a (default 2048-point) 10*log10-scaled
FFT, then outputs the resulting float-vector to a file-sink at a 5Hz rate.

Everything is pretty-much parameterized on the command line, including:

frequency (100M)
gain (20)
srate (1.0e6)
fifoname ("fft_output_fifo")
devicecfg ("addr=192.168.10.2")
xmlport (6060)

I've included the ability to change parameters on-the-fly using the
XMLRPC server, which would allow you to, for example, change
run-time parameters from some external interface, such as a WEB gui
or similar.

If this were my problem, I'd start this thing in a script which creates
the fifo file, starts some program that reads the FIFO (left as an
exercise for the proverbial reader) in the background, then calls the
Gnu Radio program.

Re: [Discuss-gnuradio] USRP network based spectrum analyzer

On 28/09/2011 4:50 PM, Phelps Williams wrote:
> I have a usrp and computer in a remote location without much network
> bandwidth available to the system and I'm using it as a spectrum
> analyzer. I'd like to run the fft on the remote system and then send
> the results to a connected client for display. This would allow me to
> get greater fidelity than xwindows forwarding or the ascii dft example
> while also using less bandwidth. I would imagine the client side
> would potentially reuse some of the existing wx or qt interfaces for
> display and control.
>
> This seems like a pretty useful / simple use of this hardware. Does
> anybody know of any implementations floating around that does this?
> I'd prefer not to reinvent the wheel.
>
> -Phelps
>
You could use a GRC-based flow-graph that computes the FFT, and outputs
the results to a FIFO, and have a small C program that simply puts
"snapshots" in an appropriate place. Once it's in an "appropriate
place" (and perhaps in a form that you like), you could use a web server
to observe the results. Roughly 1e6 ways of skinning this particular
cat.

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

[Discuss-gnuradio] USRP network based spectrum analyzer

I have a usrp and computer in a remote location without much network bandwidth available to the system and I'm using it as a spectrum analyzer. I'd like to run the fft on the remote system and then send the results to a connected client for display. This would allow me to get greater fidelity than xwindows forwarding or the ascii dft example while also using less bandwidth. I would imagine the client side would potentially reuse some of the existing wx or qt interfaces for display and control.

This seems like a pretty useful / simple use of this hardware. Does anybody know of any implementations floating around that does this? I'd prefer not to reinvent the wheel.

-Phelps

Re: [Discuss-gnuradio] Bandwidth of XCVR 2450 Daugtherboard

On 28/09/2011 2:32 PM, Konstantinos wrote:
> Thanks for your reply.
>
> However, I am a little bit confused since in your reply you mention that these
> are programmable low-pass filters which operate at baseband, while in the code
> the associated comment says that this is the bandwidth of the bandpass filter on
> the board. Secondly, why are these baseband filters? These are on the
> daughterboard so I would expect them to operate on the intermediate band, since
> the daughterboard converts complex IF to Real RF. Please let me know where I get
> this wrong.
>
> Thank you for your time again.
>
> BR,
>
> Konstantinos
>
>
Most of the daughtercards convert to/from complex-baseband to/from real
RF. The analog filters operate at baseband, and are therefore
low-pass filters.

There are exceptions--the TVRX and TVRX2 use a non-zero IF. But all the
other daughtercards use complex-baseband.

So, in complex baseband, if you want a total bandwidth of 40MHz, what
you're actually asking for is -20Mhz to +20Mhz. Which means that
I and Q are both low-pass filtered to 20MHz.

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

Re: [Discuss-gnuradio] Bandwidth of XCVR 2450 Daugtherboard

Thanks for your reply.

However, I am a little bit confused since in your reply you mention that these
are programmable low-pass filters which operate at baseband, while in the code
the associated comment says that this is the bandwidth of the bandpass filter on
the board. Secondly, why are these baseband filters? These are on the
daughterboard so I would expect them to operate on the intermediate band, since
the daughterboard converts complex IF to Real RF. Please let me know where I get
this wrong.

Thank you for your time again.

BR,

Konstantinos

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

Re: [Discuss-gnuradio] Bandwidth of XCVR 2450 Daugtherboard

On 28/09/2011 11:19 AM, Matt Ettus wrote:

On Wed, Sep 28, 2011 at 5:18 AM, Konstantinos <mammasis82@hotmail.com> wrote:

Hi again,

I recently found out that the Bandwidths of the XCVR 2450 Daugtherboard are as
follows for the RX and TX side respectively:

Bandwidths (Hz):

RX: 15M, 19M, 28M, 36M; (each +-0, 5, or 10%)
TX: 24M, 36M, 48M

Can someone elaborate on these values please and how to decide upon which one to
use? As I can understand, this is dependent on the specific application,
however, I am puzzled as to why they are different since these values correspond
to the bandwidth allowed in the bandpass filter prior to transmission/reception.

These filters are programmable low-pass filters which operate at baseband. In general, you just need to set them wide enough for the signals you wish to deal with.

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

My impression is that, except in special circumstances, the analog filters are set "appropriately", if the hardware has settable filters.

The analog bandwidth should generally be set to be somewhere less than Fs/2, for whatever Fs is in use on the motherboard--
64Msps on the USRP1/E100 and 100Msps on the USRP2/N2XXX family. Since the FPGA normally does digital filtering, as long
as the analog bandwidth is set to less than Fs/2, you shouldn't need to adjust the filters, and I think UHD does this automatically.

Re: [Discuss-gnuradio] Bandwidth of XCVR 2450 Daugtherboard

On Wed, Sep 28, 2011 at 5:18 AM, Konstantinos <mammasis82@hotmail.com> wrote:

Hi again,

I recently found out that the Bandwidths of the XCVR 2450 Daugtherboard are as
follows for the RX and TX side respectively:

Bandwidths (Hz):

RX: 15M, 19M, 28M, 36M; (each +-0, 5, or 10%)
TX: 24M, 36M, 48M

Can someone elaborate on these values please and how to decide upon which one to
use? As I can understand, this is dependent on the specific application,
however, I am puzzled as to why they are different since these values correspond
to the bandwidth allowed in the bandpass filter prior to transmission/reception.

These filters are programmable low-pass filters which operate at baseband. In general, you just need to set them wide enough for the signals you wish to deal with.

Matt

Re: [Discuss-gnuradio] Tx Amplitude in USRP N210

On 28/09/11 04:01 AM, Konstantinos wrote:
> Hi,
>
> I am trying to find out how to set the TX-amplitude parameter between 0-1,
> which
> is given as an option in USRP sink. My attempts
> to find a clear explanation of
> this parameter have all failed.
>
A UHD sink has a "Gain" parameter--is that what you're talking about?
That parameter sets the
*analog gain* of the particular daughtercard in use. The final output
power produced by the
transmit side will be a product of the analog gain setting, and the
magnitude of the signals
coming from the Gnu Radio flow-graph. In UHD, it expects signals that
are normalized into
{-1.0,+1.0}, and UHD scales that into the range expected by the
particular hardware.

> Also, I would like to understand how to
> set the receive SNR in the source file?
>
> As for the receive SNR, my guess would be
> to solve the classic equation, which
> involves estimating the noise figure,
> transmitted power, gains of antennas etc.,
> however it does not seem to me a very
> realistic approach. How do you set this value?
>
> I would appreciate anyone's hints.
>
>
Not sure what you mean by "set the receive SNR in the source file". The
SNR is a property of a received
signal. It's not something you "set" in the hardware, although
hardware/software settings can
certainly *influence* the received SNR.

--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

[Discuss-gnuradio] Bandwidth of XCVR 2450 Daugtherboard

Hi again,

I recently found out that the Bandwidths of the XCVR 2450 Daugtherboard are as
follows for the RX and TX side respectively:

Bandwidths (Hz):

RX: 15M, 19M, 28M, 36M; (each +-0, 5, or 10%)
TX: 24M, 36M, 48M

Can someone elaborate on these values please and how to decide upon which one to
use? As I can understand, this is dependent on the specific application,
however, I am puzzled as to why they are different since these values correspond
to the bandwidth allowed in the bandpass filter prior to transmission/reception.

Thank you once more for your time.

Best Regards,

Konstantinos

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

[Discuss-gnuradio] Tx Amplitude in USRP N210

Hi,

I am trying to find out how to set the TX-amplitude parameter between 0-1,
which
is given as an option in USRP sink. My attempts
to find a clear explanation of
this parameter have all failed.

Also, I would like to understand how to
set the receive SNR in the source file?

As for the receive SNR, my guess would be
to solve the classic equation, which
involves estimating the noise figure,
transmitted power, gains of antennas etc.,
however it does not seem to me a very
realistic approach. How do you set this value?

I would appreciate anyone's hints.

Best Regards,

Konstantinos

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

Tuesday, September 27, 2011

Re: [Discuss-gnuradio] New block: Segfault thrown when calling self.connect

On 09/27/2011 06:09 PM, Sebastian Götte wrote:
> Hello,
> I wrote a GNU Radio block using the template from here:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Basic_block
> which shall eventually become a source module providing access to a
> low-speed electroencephalographic capture board I designed and built, in
> order to "abuse" the GNU Radio framework for that kind of data analysis.
> This is the test program I tried to run (generated with grc, modified by
> hand):
> https://github.com/jaseg/openmind-viewer/blob/master/apps/top_block.py
> On each run the program throws a segfault in the second connect call on
> line 55:
> self.connect((self.openmind_buspirate_source_0, 0),
> (self.gr_interleaved_short_to_complex_0, 0))
> When I follow the segfault using gdb or pdb I end up somewhere in the
> gnuradio internals.
> I have no idea what causes this segfault and would be glad for any hints.
> The source files of the rest of the block are to be found here (I do not
> know which are actually relevant to this question):
> https://github.com/jaseg/openmind-viewer
> Thanks in advance (hoping that I provided enough information)
>
Without looking too deeply into it, having looked-over your block
source, I might suggest that a better approach to interfacing to
your "buspirate" device would be to write an external program and
have it communicate data over a named pipe, and your Gnu Radio
"stuff" can simply use a 'file source' on the named-pipe. There's no
real performance penalty for this--named pipes are quite fast, and
your source looks like it runs at a paltry 115200Kbps, which is "way
down in the noise" as far as sample rates go.

My suspicion is that there's something wrong with your I/O signatures
which is causing the Gnu Radio flow-graph "organizer" to
barf in a non-graceful way.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] reg calculation of BER/SNR using gnuradio UHD

On 09/27/2011 06:12 PM, shantharam balasubramanian wrote:
> Hi
>
> When I run it in USRP1 nodes, I don't get the error as before, that
> says it cannot find USRP1.
USRP1s didn't require any "wire format" or firmware/FPGA changes to
support UHD, so both "classic" and "UHD" programs will work,
with USRP1s provided that the daughtercard in use is "pre-UHD".
Development of the "classic" branch was frozen quite some time ago, so
any cards that are "new" won't work in anything but the UHD environment.

>
> But the benchmark_tx program says "Failed to tune to center
> frequency". I then tried to send it in 2 MHZ and also in 2 GHZ
> frequency, but it still doesn't work.
>
What daughtercard are you using?

What rev of Gnu Radio are you using? I strongly suggest always trying
to run with some quite current.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] Make USRP run w/o SW intervention

On 09/27/2011 06:04 PM, Philip Balister wrote:
>
> I see a couple of possibilities;
>
> 1) Use a microblaze in the fpga to control the spi bus and other
> control functions. (It may already use a microblaze, so update the
> code to do this internally, instead of taking commands from ethernet)
There's a ZPU in the FPGA--it handles some of the protocol and low-speed
interfacing "goop" in the normal firmware/FPGA load.
But the general "model" is that the FPGA/firmware is "dumb". It
simply provides a fairly generic "peek and poke" interface over
the Ethernet, with all the "smarts" in the host code. I think part
of the motivation for this is that it's easier to modify host code
for minor performance tweaks, etc, than doing it in the firmware/FPGA
code. But one could certainly enhance the small amount
of firmware that runs on the ZPU to handle all the device register
initialization, etc.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] reg calculation of BER/SNR using gnuradio UHD

When I run it in USRP1 nodes, I don't get the error as before, that says it cannot find USRP1.

But the benchmark_tx program says "Failed to tune to center frequency". I then tried to send it in 2 MHZ and also in 2 GHZ frequency, but it still doesn't work.

Can anyone tell me why it's happening.? It will be greatly helpful if someone can help me out with this center frequency setting process.

Thanks

Shantharam

[Discuss-gnuradio] New block: Segfault thrown when calling self.connect

Hello,
I wrote a GNU Radio block using the template from here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Basic_block
which shall eventually become a source module providing access to a
low-speed electroencephalographic capture board I designed and built, in
order to "abuse" the GNU Radio framework for that kind of data analysis.
This is the test program I tried to run (generated with grc, modified by
hand):
https://github.com/jaseg/openmind-viewer/blob/master/apps/top_block.py
On each run the program throws a segfault in the second connect call on
line 55:
self.connect((self.openmind_buspirate_source_0, 0),
(self.gr_interleaved_short_to_complex_0, 0))
When I follow the segfault using gdb or pdb I end up somewhere in the
gnuradio internals.
I have no idea what causes this segfault and would be glad for any hints.
The source files of the rest of the block are to be found here (I do not
know which are actually relevant to this question):
https://github.com/jaseg/openmind-viewer
Thanks in advance (hoping that I provided enough information)

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

Re: [Discuss-gnuradio] Make USRP run w/o SW intervention

On 09/27/2011 04:25 PM, Reginald Cornwallice wrote:
> Hello Friends,
>
> My name is Reginald and I am an SDR enthusiast currently pursuing my latest
> project with the N210 box. I have the utmost respect for this hardware and
> hope to integrate it into my newest intellectual pursuit.
>
> My project is a box that sends and receives cellular SMS messages and with
> my expertise being mostly in FPGA I am tackling this venture by modifying
> the FPGA code. So far I have been successful implanting my HDL based
> cellular receiver in the FPGA after the dsp_core_rx module and a attaching
> my transmit directly to the DAC output pins, bypassing dsp_core_tx.
>
> However, it seems that the box cannot run standalone without software
> intervention because the ethernet IO is not free running and ADC and DAC
> clocks can be shut off by software. Furthermore, it seems running example
> programs such as rx_samples_to_file overwrite SPI values programmed to
> AD9510 in the firmware burned onto the motherboard, for example, changing
> the divisors for the clocks to ADC and DAC. I confirmed this by probing the
> hardware.
>
> My project works when I run rx_samples_to_file program to force the board to
> be active on receive and transmit, and also force the ethernet output to be
> active, which I have configured to send out some status messages so I can
> tell the demodulator is functioning.
>
> Is there any simple change I can make to the FPGA or firmware in order to
> have the box run without intervention, meaning all the SPI programming is
> handled by firmware, DAC/ADC clocks are on forever, and the ethernet output
> is continuously putting out the output I've wired it up for in the FPGA?
>
> Many thanks for any assistance on this matter.

I see a couple of possibilities;

1) Use a microblaze in the fpga to control the spi bus and other control
functions. (It may already use a microblaze, so update the code to do
this internally, instead of taking commands from ethernet)

2) Use an E100 (or likely an E110) and write some code on the ARM to do
the control tasks.

Philip

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

Re: [Discuss-gnuradio] reg calculation of BER/SNR using gnuradio UHD

Thanks for the reply. And yes you are correct. It just works for USRP1 alone, though it seeks to give the option of selecting the USRP number.

Re: [Discuss-gnuradio] reg calculation of BER/SNR using gnuradio UHD

On 09/27/2011 05:00 PM, shantharam balasubramanian wrote:
>
> Hi Ben,
>
> Thanks a lot for the reply. One of our colleagues downloaded the
> gnuradio version 3.1.2 and we are using that version. I don't know if
> we need to download the latest version of gnuradio (3.4.0) and run that.
>
> Now, the thing is, the benchmark_tx and benchmark_rx programs in
> gnuradio-examples/python/digital sub-folder work properly. That means,
> the receiver receives the packets transmitted by the transmitter.
> However, when we try running the benchmark_rx and benchmark_tx
> programs of gnuradio-examples/python/digital-bert subfolder, it fails
> to find usrp.
>
> We give the following command to run the benchmark_rx program of bert
> subfolder:
>
> ./benchmark_rx.py -f 2.412G -r 1M
>
> We have also tried with: ./benchmark_rx.py -f 2.412G -r 1M -w 2 (We
> are using USRP2)
>
> The program shows the following error message:
>
> usrp: failed to find usrp[0] (If we give -w 2, it says failed to find
> usrp[2])
>
> Runtime error: can't open usrp
>
> We don't know if we are giving wrong commands because similar commands
> work well for benchmark programs in the python/digital sub-folder.
> Your help will be very appreciated.
>
>
> Thanks,
>
> --
> Regards
>
>
The examples you are using are designed strictly for a USRP1, using
the "classic" interface. You have presumably modified your USRP2
for "UHD", which does not interoperate with programs using the
"classic" API.

I believe Tom Rondeau is busy working on updating most of the important
examples to use UHD, which will allow, among other things,
the ability to use *any* of the USRP hardware, more-or-less
seamlessly with most of the examples.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] reg calculation of BER/SNR using gnuradio UHD

Hi Ben,

Thanks a lot for the reply. One of our colleagues downloaded the gnuradio version 3.1.2 and we are using that version. I don't know if we need to download the latest version of gnuradio (3.4.0) and run that.

Now, the thing is, the benchmark_tx and benchmark_rx programs in gnuradio-examples/python/digital sub-folder work properly. That means, the receiver receives the packets transmitted by the transmitter. However, when we try running the benchmark_rx and benchmark_tx programs of gnuradio-examples/python/digital-bert subfolder, it fails to find usrp.

We give the following command to run the benchmark_rx program of bert subfolder:

./benchmark_rx.py -f 2.412G -r 1M

We have also tried with: ./benchmark_rx.py -f 2.412G -r 1M -w 2 (We are using USRP2)

The program shows the following error message:

usrp: failed to find usrp[0] (If we give -w 2, it says failed to find usrp[2])

Runtime error: can't open usrp

We don't know if we are giving wrong commands because similar commands work well for benchmark programs in the python/digital sub-folder. Your help will be very appreciated.

Thanks,

Regards

Shantharam Balasubramanian
MS in Electrical and Computer Engineering
Rutgers University
Ph:732-543-6863
Email:shantharampsg@gmail.com

[Discuss-gnuradio] Make USRP run w/o SW intervention

Hello Friends,

My name is Reginald and I am an SDR enthusiast currently pursuing my latest project with the N210 box. I have the utmost respect for this hardware and hope to integrate it into my newest intellectual pursuit.

My project is a box that sends and receives cellular SMS messages and with my expertise being mostly in FPGA I am tackling this venture by modifying the FPGA code. So far I have been successful implanting my HDL based cellular receiver in the FPGA after the dsp_core_rx module and a attaching my transmit directly to the DAC output pins, bypassing dsp_core_tx.

However, it seems that the box cannot run standalone without software intervention because the ethernet IO is not free running and ADC and DAC clocks can be shut off by software. Furthermore, it seems running example programs such as rx_samples_to_file overwrite SPI values programmed to AD9510 in the firmware burned onto the motherboard, for example, changing the divisors for the clocks to ADC and DAC. I confirmed this by probing the hardware.

My project works when I run rx_samples_to_file program to force the board to be active on receive and transmit, and also force the ethernet output to be active, which I have configured to send out some status messages so I can tell the demodulator is functioning.

Is there any simple change I can make to the FPGA or firmware in order to have the box run without intervention, meaning all the SPI programming is handled by firmware, DAC/ADC clocks are on forever, and the ethernet output is continuously putting out the output I've wired it up for in the FPGA?

Many thanks for any assistance on this matter.

Reginald

[Discuss-gnuradio] reg calculation of BER/SNR using gnuradio UHD

I am working in WINLAB and I have been using gnuradio UHD image for running some of the programs I have previously worked in summer.

I came across a post in this forum, where few months ago someone has asked how to calculate BER and Tom has given him the answer to look into digital-bert folder.

http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/show/gnuradio-examples/python/digital-bert

When I tried to run the program it said it cannot find USRP and I guess this is due to the problem of firmware image I am using.

Does anyone have any idea of what image I should use for these programs? It will be much helpful if someone can help me out with this.

Thank you

--
Regards

Shantharam Balasubramanian
MS in Electrical and Computer Engineering
Rutgers University
Ph:732-543-6863
Email:shantharampsg@gmail.com

Re: [Discuss-gnuradio] making gnuradio blocks entirely in python

On Tue, Sep 27, 2011 at 11:14 AM, Josh Blum <josh@joshknows.com> wrote:

>>
>> I want to support proper message passing. I noticed that I can register
>> a message handler to receive messages. Can you point me to how messages
>> are produced?
>>
>
> So you basically need to create a callback function and set it as the
> message handler. So you call:
>
> template <typename T> void set_msg_handler(T msg_handler){
> d_msg_handler = msg_handler_t(msg_handler);
> }
>
> Where d_msg_handler is of type:
>
> typedef boost::function<void(pmt::pmt_t)> msg_handler_t;
>
> You then use gruel::send (in msg_passing.h) to a block that has a message
> acceptor handler defined (or not; if there is no handler, nothing happens).
> You can see gnuradio-core/src/lib/runtime/qa_set_msg_handler.cc for an
> example of this.
>

I did my own digging last night, and found that gr_block inherits
gr_basic_block inherits gr_msg_accepter which has post(). So the
gruel::send is just a function to call this post() method.

So, there is nothing here that really deals with message propagation.
Message sending exists at the block level but not at the flow graph
level. Or am I am misunderstanding.

-Josh

You are correct, sir.

The messages are handled, on the other hand, in the flowgraph. You can find it in gr_block_executor, if you are so inclined. But that's purposefully behind the scenes, so you shouldn't have to worry about that at all.

Tom

Re: [Discuss-gnuradio] making gnuradio blocks entirely in python

>>
>> I want to support proper message passing. I noticed that I can register
>> a message handler to receive messages. Can you point me to how messages
>> are produced?
>>
>
> So you basically need to create a callback function and set it as the
> message handler. So you call:
>
> template <typename T> void set_msg_handler(T msg_handler){
> d_msg_handler = msg_handler_t(msg_handler);
> }
>
> Where d_msg_handler is of type:
>
> typedef boost::function<void(pmt::pmt_t)> msg_handler_t;
>
> You then use gruel::send (in msg_passing.h) to a block that has a message
> acceptor handler defined (or not; if there is no handler, nothing happens).
> You can see gnuradio-core/src/lib/runtime/qa_set_msg_handler.cc for an
> example of this.
>

I did my own digging last night, and found that gr_block inherits
gr_basic_block inherits gr_msg_accepter which has post(). So the
gruel::send is just a function to call this post() method.

So, there is nothing here that really deals with message propagation.
Message sending exists at the block level but not at the flow graph
level. Or am I am misunderstanding.

-Josh

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