date:20140604

On Wed, Jun 4, 2014 at 7:10 PM, David Halls 
wrote:

> Activecat,
> In fact my horrible hack doesn't work properly. Once items start arriving
> at Payload TD Tx 2, they still don't arrive as 'consistently' (for want of
> a better word), as those from the Noise Source block, and thus zeros are
> inserted when they are not required!
>
> David
>

David,

Basically my idea to solve the problem may involve an overhaul of your
existing flowgraph, as below:

1).  You must understand that the output of UHD source is at constant rate.
In particular I am referring to the "Relay Rx" USRP.
  Even when the USRP does not receive any RF signal, it keeps sending
out zeros (plus noise) as its output, at constant rate.

  Try to make all your blocks behave in this way. I am referring to the
blocks between the "Relay Rx" and "Relay Tx".
  The idea is: keep transmitting, don't produce no output at any time.
If nothing need to be produced, then output zeros at constant rate.
  In this case all your custom blocks are either sync block, decimation
or interpolation blocks. You don't need any general block.

2).  With above condition fulfilled, we could ensure that the data fed into
the "Relay Tx" USRP is at constant rate, and we could then determine this
rate by simple calculations.
  The data stream into the "Relay Tx" USRP will not stop at any
instance. It is 'consistent'.

3).  You want the "Relay Rx" USRP ignores the received signal during the
time that the "Relay Tx" USRP is transmitting, that is fine.
  But just try to make the downstream block of "Relay Rx" USRP keep
transmitting zeros rather than stop transmitting during this period.

4).  With these, you will have both "Relay Tx" USRP and "Source" USRP
transmitting at constant data rate and nonstop.
  They could be transmitting at different rates, that is ok, and this
is not difficult to handle.

With this, you avoid the initial problem (problem of occasionally there is
no items at one of the inputs) mentioned in this thread, which is the root
cause of your problem.
Then your problem is solved !
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] tx_time tag accuraccy

2014-06-04 Thread bob wole

Sorry for not stating the hardware earlier. I am using USRP N210, with
RFX2400 and WBX boards.

--
Bob

On Wed, Jun 4, 2014 at 11:07 PM, Marcus Leech  wrote:

> I don't know the detailed answer, but any such answer will depend very
> much on which USRP hardware you're talking about.
>
> One of the R&D people who deals with the FPGA codebase may be able to give
> a precise answer, given stated hardware.
>
>
>
>  on Jun 04, 2014, *bob wole*  wrote:
>
>  Marcus! Thanks for you comment.
>
> I think that USRP transmit FIFO is at the start of the DSP chain in FPGA
> i.e it is prior to both of the interpolation filters? right?  I am not
> talking about when the burst will be over the air, I want to know when the
> first sample of the burst will leave the transmit FIFO if it has been
> tagged as tx_time=X.
>
>
>
> --
> Bob
>
>
> On Wed, Jun 4, 2014 at 10:51 PM, Marcus Leech  wrote:
>
>> It will depend some on the effective group delay of both the
>> interpolation filters in the the FPGA and the analog group delay of the
>> analog bits of whatever daughtercard you're using.
>>
>> The only way to be sure is to measure...
>>
>>
>>   on Jun 04, 2014, *bob wole via USRP-users* 
>> wrote:
>>
>>  I am using stream tags for the transmission control. I want to know
>> what is the accuracy/precision of the tx_time tag? E.g if I tag a burst A
>> with tx_time=X, then the burst A will come out of the USRP transmit FIFO at
>> X+delta, how large the value of delta could be?
>>
>>
>> --
>> Bob
>>   --
>>
>> ___
>> USRP-users mailing list
>> usrp-us...@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNu radio examples not running

Hi All,
When i try to run any of built in examples (in .py form) with GRC,i get the
following error:

Error:
/usr/local/share/gnuradio/examples/audio/audio_fft.py:1:1:FATAL:PARSER:ERR_DOCUMENT_EMPTY:
Start tag expected, '<' not found

An example of such file is as attached.
#!/usr/bin/python
#!/usr/bin/env python
#
# Copyright 2004,2005,2007 Free Software Foundation, Inc.
#
# This file is part of GNU Radio
#
# GNU Radio is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
#
# GNU Radio is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GNU Radio; see the file COPYING.  If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.
#

from gnuradio import gr, gru, audio
from gnuradio import eng_notation
from gnuradio.eng_option import eng_option
from gnuradio.wxgui import stdgui2, fftsink2, waterfallsink2, scopesink2, form, slider
from optparse import OptionParser
import wx
import sys

class app_top_block(stdgui2.std_top_block):
def __init__(self, frame, panel, vbox, argv):
stdgui2.std_top_block.__init__(self, frame, panel, vbox, argv)

self.frame = frame
self.panel = panel

parser = OptionParser(option_class=eng_option)
parser.add_option("-W", "--waterfall", action="store_true", default=False,
  help="Enable waterfall display")
parser.add_option("-S", "--oscilloscope", action="store_true", default=False,
  help="Enable oscilloscope display")
parser.add_option("-I", "--audio-input", type="string", default="",
  help="pcm input device name.  E.g., hw:0,0 or /dev/dsp")
parser.add_option("-r", "--sample-rate", type="eng_float", default=48000,
  help="set sample rate to RATE (48000)")

(options, args) = parser.parse_args()
	sample_rate = int(options.sample_rate)

	if len(args) != 0:
parser.print_help()
sys.exit(1)

self.show_debug_info = True

# build the graph
if options.waterfall:
self.scope = \
  waterfallsink2.waterfall_sink_f (panel, fft_size=1024, sample_rate=sample_rate)
elif options.oscilloscope:
self.scope = scopesink2.scope_sink_f(panel, sample_rate=sample_rate)
else:
self.scope = fftsink2.fft_sink_f (panel, fft_size=1024, sample_rate=sample_rate, fft_rate=30,
	  ref_scale=1.0, ref_level=0, y_divs=12)

	self.src = audio.source (sample_rate, options.audio_input)

self.connect(self.src, self.scope)

self._build_gui(vbox)

# set initial values

def _set_status_msg(self, msg):
self.frame.GetStatusBar().SetStatusText(msg, 0)

def _build_gui(self, vbox):

def _form_set_freq(kv):
return self.set_freq(kv['freq'])

vbox.Add(self.scope.win, 10, wx.EXPAND)

	#self._build_subpanel(vbox)

def _build_subpanel(self, vbox_arg):
# build a secondary information panel (sometimes hidden)

# FIXME figure out how to have this be a subpanel that is always
# created, but has its visibility controlled by foo.Show(True/False)

def _form_set_decim(kv):
return self.set_decim(kv['decim'])

if not(self.show_debug_info):
return

panel = self.panel
vbox = vbox_arg
myform = self.myform

#panel = wx.Panel(self.panel, -1)
#vbox = wx.BoxSizer(wx.VERTICAL)

hbox = wx.BoxSizer(wx.HORIZONTAL)
hbox.Add((5,0), 0)

myform['decim'] = form.int_field(
parent=panel, sizer=hbox, label="Decim",
callback=myform.check_input_and_call(_form_set_decim, self._set_status_msg))

hbox.Add((5,0), 1)
myform['fs@usb'] = form.static_float_field(
parent=panel, sizer=hbox, label="Fs@USB")

hbox.Add((5,0), 1)
myform['dbname'] = form.static_text_field(
parent=panel, sizer=hbox)

hbox.Add((5,0), 1)
myform['baseband'] = form.static_float_field(
parent=panel, sizer=hbox, label="Analog BB")

hbox.Add((5,0), 1)
myform['ddc'] = form.static_float_field(
parent=panel, sizer=hbox, label="DDC")

hbox.Add((5,0), 0)
vbox.Add(hbox, 0, wx.EXPAND)


def main ():
app = stdgui2.stdapp(app_top_block, "Audio FFT", nstatus=1)
app.MainLoop()

if __name__ == '__main__':
main ()
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https:/

[Discuss-gnuradio] Doxygen documentation

How can i configure GNU Radio Companion 3.7.3 with Doxygen so taht i can
view the blocks' documentation from inside GRC?I have Doxygen installed but
its not configured with GRC.
Regards,
Ali
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] signal level

Hi Tom,
Can you tell what is the constraint for USRP B210?


On Thu, Jun 5, 2014 at 8:13 AM, Tom McDermott  wrote:

> Hi Ali - some sinks care about the amplitude, and others do not.
>
> For example, the instruments built into gnuradio (Scope, Frequency
> display, etc.) can examine a signal of almost any amplitude within
> floating-point range because you can adjust the display scale factor.
>
> However other sinks, such as a physical transmitter (USRP, HPSDR, etc.)
> are constrained in the amplitude that they can accept. Normally this must
> be less than one, and hitting or exceeding 1.00 (even just on the peak)
> can cause problems. Also a physical transmitter might have only 12 or 16
> bits fixed point dynamic range, so there may be a minimum signal amplitude
> as well.
>
> -- Tom, N5EG
>
>
>
>
> On Wed, Jun 4, 2014 at 7:33 PM, jason sam  wrote:
>
>> Hi,
>> In GRC is it necessary that we give a signal to any sink having an
>> amplitude greater than 1?
>> Regards,
>> Ali
>>
>> ___
>> 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] signal level

2014-06-04 Thread Tom McDermott

Hi Ali - some sinks care about the amplitude, and others do not.

For example, the instruments built into gnuradio (Scope, Frequency display,
etc.) can examine a signal of almost any amplitude within floating-point
range because you can adjust the display scale factor.

However other sinks, such as a physical transmitter (USRP, HPSDR, etc.) are
constrained in the amplitude that they can accept. Normally this must be
less than one, and hitting or exceeding 1.00 (even just on the peak)  can
cause problems. Also a physical transmitter might have only 12 or 16 bits
fixed point dynamic range, so there may be a minimum signal amplitude as
well.

-- Tom, N5EG

On Wed, Jun 4, 2014 at 7:33 PM, jason sam  wrote:

> Hi,
> In GRC is it necessary that we give a signal to any sink having an
> amplitude greater than 1?
> Regards,
> Ali
>
> ___
> 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] signal level

Hi,
In GRC is it necessary that we give a signal to any sink having an
amplitude greater than 1?
Regards,
Ali
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Getting overflows at 50 Msps (not sure why)

2014-06-04 Thread Ron Economos


On 6/4/2014 2:16 PM, Orin Lincoln wrote:

Hello,

I am trying to get samples from a B200 at 50 Msps into GNU Radio. The 
UHD benchmark_rate tool receives at 50 Msps without any overflows 
detected. My GNU Radio flowgraph is simply a USRP source connected to 
a null sink, and I'm still getting overflows. I've tried expanding the 
min_output_buffer for the USRP source, but that doesn't seem to help. 
I really don't know what is causing the problem. Any suggestions about 
what I should try?


Thank you,
Orin Lincoln


On bladeRF, the number of USB3.0 buffers makes a big difference
in the maximum sample rate without overruns. On the B200, you
can try the same thing by increasing the number of buffers
in the device_addr arguments.

device_addr="recv_frame_size=65536,num_recv_frames=128,"

Ron


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

Re: [Discuss-gnuradio] Getting overflows at 50 Msps (not sure why)

2014-06-04 Thread Tom Tsou

On Wed, Jun 4, 2014 at 5:16 PM, Orin Lincoln  wrote:
> I am trying to get samples from a B200 at 50 Msps into GNU Radio. The UHD
> benchmark_rate tool receives at 50 Msps without any overflows detected. My
> GNU Radio flowgraph is simply a USRP source connected to a null sink, and
> I'm still getting overflows. I've tried expanding the min_output_buffer for
> the USRP source, but that doesn't seem to help. I really don't know what is
> causing the problem. Any suggestions about what I should try?

In addition to what Marcus said, if your application allows, you can
try 8-bit samples to relieve some pressure on the USB bus.

  -TT

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

Re: [Discuss-gnuradio] Getting overflows at 50 Msps (not sure why)

2014-06-04 Thread Marcus D. Leech


On 06/04/2014 05:16 PM, Orin Lincoln wrote:

Hello,

I am trying to get samples from a B200 at 50 Msps into GNU Radio. The 
UHD benchmark_rate tool receives at 50 Msps without any overflows 
detected. My GNU Radio flowgraph is simply a USRP source connected to 
a null sink, and I'm still getting overflows. I've tried expanding the 
min_output_buffer for the USRP source, but that doesn't seem to help. 
I really don't know what is causing the problem. Any suggestions about 
what I should try?


Thank you,
Orin Lincoln

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

What is causing the problem is that your computer/OS simply cannot keep 
up.  Gnu Radio has noticeably more overhead than a hand-crafted
  program like benchmark_rate.  Being able to maintain real-time 
streaming at these rates is *challenging*, and just because benchmark_rate
  doesn't fall over, is *zero* guarantee that some *other* program, 
trying to swallow data at a similar rate, will actually be able to.


Desktop/Server operating systems (Windows, OSX, Linux, *BSD) aren't 
really optimized for dealing with high-bandwidth real-time flows.
  In any given system configuration, it's rather a crap-shoot as to 
whether your system will be able to keep up or not.


What type of computer do you have?  What OS?  How much memory?  Is it 
the fastest memory you can use on your motherboard?




--
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

[Discuss-gnuradio] Getting overflows at 50 Msps (not sure why)

2014-06-04 Thread Orin Lincoln


Hello,

I am trying to get samples from a B200 at 50 Msps into GNU Radio. The 
UHD benchmark_rate tool receives at 50 Msps without any overflows 
detected. My GNU Radio flowgraph is simply a USRP source connected to a 
null sink, and I'm still getting overflows. I've tried expanding the 
min_output_buffer for the USRP source, but that doesn't seem to help. I 
really don't know what is causing the problem. Any suggestions about 
what I should try?


Thank you,
Orin Lincoln

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

[Discuss-gnuradio] Call for Volunteers - GNU Radio Website

2014-06-04 Thread John Malsbury

Hello list!

It's been a few weeks since I've been connected/active on the list.  After
talking things over  Tom and others in the community it is apparent that
the GNU Radio "home site" is becoming more critical.  Here's some
background:

Sometime around GR Con 13, it became evident that the GNU Radio community
would benefit if we added a "customer facing" website.  While all technical
content about installing and using GNU Radio would stay in its current
form, this new site would be a place where we could highlight our
communities success, post content about conferences/meetups, and just
generally give new people a sense of what we're all about.

I volunteered to help put this together.  But I've been pretty busy for the
last 6 months, and to be completely honest *I've just dropped the ball here*.
So, I thought it would be best if I asked for help, and maybe found people
who are much better at web design than I am! =)  We're pretty open to using
any platform at this point (Wordpress, straight html, bootstrap, w/e).

*Please shoot me a message if you think you help, and I'll include you on a
group discussion sometime next week.*   I can be reached at my personal
address for the time being: jmalsbury.perso...@gmail.com.

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

Re: [Discuss-gnuradio] tx_time tag accuraccy

2014-06-04 Thread Marcus Leech

I don't know the detailed answer, but any such answer will depend very much on which USRP hardware you're talking about.
One of the R&D people who deals with the FPGA codebase may be able to give a precise answer, given stated hardware.

on Jun 04, 2014, bob wole wrote:

Marcus! Thanks for you comment.
I think that USRP transmit FIFO is at the start of the DSP chain in FPGA i.e it is prior to both of the interpolation filters? right? I am not talking about when the burst will be over the air, I want to know when the first sample of the burst will leave the transmit FIFO if it has been tagged as tx_time=X.

--
Bob

On Wed, Jun 4, 2014 at 10:51 PM, Marcus Leech wrote:

It will depend some on the effective group delay of both the interpolation filters in the the FPGA and the analog group delay of the analog bits of whatever daughtercard you're using.
The only way to be sure is to measure...

on Jun 04, 2014, bob wole via USRP-users wrote:

I am using stream tags for the transmission control. I want to know what is the accuracy/precision of the tx_time tag? E.g if I tag a burst A with tx_time=X, then the burst A will come out of the USRP transmit FIFO at X+delta, how large the value of delta could be?
--
Bob

___USRP-users mailing listusrp-us...@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

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

Re: [Discuss-gnuradio] tx_time tag accuraccy

2014-06-04 Thread bob wole

Marcus! Thanks for you comment.

I think that USRP transmit FIFO is at the start of the DSP chain in FPGA
i.e it is prior to both of the interpolation filters? right?  I am not
talking about when the burst will be over the air, I want to know when the
first sample of the burst will leave the transmit FIFO if it has been
tagged as tx_time=X.

--
Bob

On Wed, Jun 4, 2014 at 10:51 PM, Marcus Leech  wrote:

> It will depend some on the effective group delay of both the interpolation
> filters in the the FPGA and the analog group delay of the analog bits of
> whatever daughtercard you're using.
>
> The only way to be sure is to measure...
>
>
>  on Jun 04, 2014, *bob wole via USRP-users* 
> wrote:
>
> I am using stream tags for the transmission control. I want to know what
> is the accuracy/precision of the tx_time tag? E.g if I tag a burst A with
> tx_time=X, then the burst A will come out of the USRP transmit FIFO at
> X+delta, how large the value of delta could be?
>
>
> --
> Bob
>
> --
>
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] tx_time tag accuraccy

2014-06-04 Thread Marcus Leech

It will depend some on the effective group delay of both the interpolation filters in the the FPGA and the analog group delay of the analog bits of whatever daughtercard you're using.
 
The only way to be sure is to measure...
 
 

on Jun 04, 2014, bob wole via USRP-users  wrote:

I am using stream tags for the transmission control. I want to know what is the accuracy/precision of the tx_time tag? E.g if I tag a burst A with tx_time=X, then the burst A will come out of the USRP transmit FIFO at X+delta, how large the value of delta could be? 
 
 
--
Bob

___USRP-users mailing listusrp-us...@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

Please do not top post.
Refer
http://gnuradio.org/redmine/projects/gnuradio/wiki/MailingLists#Guidelines-for-posting
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

On Wed, Jun 4, 2014 at 10:25 PM, David Halls 
wrote:

> Yes, there are 3. The Source Tx, the Relay Tx, and the Relay Rx.
>

To clarify,
i).  the "Source Tx" USRP may or may not receive data at any time interval.
ii). the "Relay Tx" USRP transmit data only when the "Source Tx" USRP
receive data, and there is a delay due to signal processing
iii). the "Relay Rx" USRP will receive data only when the "Relay Tx" USRP
transmit it,

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

[Discuss-gnuradio] tx_time tag accuraccy

2014-06-04 Thread bob wole

I am using stream tags for the transmission control. I want to know what is
the accuracy/precision of the tx_time tag? E.g if I tag a burst A with
tx_time=X, then the burst A will come out of the USRP transmit FIFO at
X+delta, how large the value of delta could be?


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

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

On Wed, Jun 4, 2014 at 7:10 PM, David Halls 
wrote:

> Activecat,
>
> In fact my horrible hack doesn't work properly. Once items start arriving
> at Payload TD Tx 2, they still don't arrive as 'consistently' (for want of
> a better word), as those from the Noise Source block, and thus zeros are
> inserted when they are not required!
>
> David
>

David,

Could you please explain in details, what is this Payload TD Tx 2?
How does it generate data, is it getting data from a hardware or console,
why it sometime idle but sometime transmitting?

This is a virtual source. Where is it associated virtual sink?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

On Wed, Jun 4, 2014 at 8:53 PM, David Halls 
wrote:

> Hi Activecat,
>
> I have disconnected the rest of the flow graph because it is extremely
> complex.
>
> In the system I have a Source, a Relay (1 rx USRP, 1 tx USRP), a
> Destination. S ---> R_rx/R_tx --> D
>
> The two transmitters that you see on that flow graph snippet I sent you
> are the the Source Tx and the Relay Tx.
>
> Payload TD Tx 1 is derived from input codewords that are generated in
> MATLAB and stored in a file, then loaded into the flow graph. The payload
> is created in a similar fashion to Martin's original OFDM_tx. This is then
> transmitted from Source Tx.
>
> Until this point, no packets are received by Relay Rx but once the source
> transmits, these packets are then received by Relay Rx, and then there is a
> decode-and-forward chain of blocks, and this then creates Payload TD Tx 2.
>
> The full flow graph is attached, but may be missing many blocks for you...
>


Could you send the source code of the missing blocks to me?
I am trying hard to help you out.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

From: Activecat [active...@gmail.com]
Sent: 04 June 2014 16:13
To: David Halls
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: 
Flow graph blocking when doing 2x1 transmission

On Wed, Jun 4, 2014 at 10:52 PM, David Halls 
mailto:david.ha...@toshiba-trel.com>> wrote:
Not quite...

i). the "Source Tx" USRP has a constant stream of data, and is constantly 
transmitting. If the codewords in the file are exhausted it repeats.
ii). the "Relay Tx" USRP transmits data only when data has been received by the 
"Relay Rx" (I will use tx_time to control when the received burst is 
re-transmitted)
iii). the "Relay Rx" USRP will receive data only when the "Source Tx" USRP 
transmits (section where Relay Tx's too will be ignored),

To clarify, is it true that both the "Source TX" USRP and "Relay Tx" USRP are 
controlled by the same UHD Sink in the flowgraph?

Yes, they are both controlled by the same UHD sink. This ensures, in a simple 
fashion, that the Source Tx and Relay Tx transmissions have sample-level 
synchronicity - a must for my Quantize Map and Forward scheme.

NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

From: Activecat [active...@gmail.com]
Sent: 04 June 2014 16:02
To: David Halls
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: 
Flow graph blocking when doing 2x1 transmission

On Wed, Jun 4, 2014 at 10:52 PM, David Halls 
mailto:david.ha...@toshiba-trel.com>> wrote:
Not quite...

i). the "Source Tx" USRP has a constant stream of data, and is constantly 
transmitting. If the codewords in the file are exhausted it repeats.
ii). the "Relay Tx" USRP transmits data only when data has been received by the 
"Relay Rx" (I will use tx_time to control when the received burst is 
re-transmitted)
iii). the "Relay Rx" USRP will receive data only when the "Source Tx" USRP 
transmits (section where Relay Tx's too will be ignored),

What do you mean by "section where Relay Tx's too will be ignored" ?

I have changed the block you suggested, to avoid inserting 0's mid burst.

So does this give better results?

1) this is to avoid loop interference, the Relay Rx will ignore the received 
signal during the time that the Relay Tx is transmitting.
2) Yes avoiding adding 0's gives me pretty much the performance I require, I 
need to work on some other parts of the implementation to be sure. (it is 
definitely not the neatest way yet!!)

NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

On Wed, Jun 4, 2014 at 10:52 PM, David Halls 
wrote:

> Not quite...
>
> i). the "Source Tx" USRP has a constant stream of data, and is constantly
> transmitting. If the codewords in the file are exhausted it repeats.
> ii). the "Relay Tx" USRP transmits data only when data has been received
> by the "Relay Rx" (I will use tx_time to control when the received burst is
> re-transmitted)
> iii). the "Relay Rx" USRP will receive data only when the "Source Tx" USRP
> transmits (section where Relay Tx's too will be ignored),
>

To clarify, is it true that both the "Source TX" USRP and "Relay Tx" USRP
are controlled by the same UHD Sink in the flowgraph?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

On Wed, Jun 4, 2014 at 10:52 PM, David Halls 
wrote:

> Not quite...
>
> i). the "Source Tx" USRP has a constant stream of data, and is constantly
> transmitting. If the codewords in the file are exhausted it repeats.
> ii). the "Relay Tx" USRP transmits data only when data has been received
> by the "Relay Rx" (I will use tx_time to control when the received burst is
> re-transmitted)
> iii). the "Relay Rx" USRP will receive data only when the "Source Tx" USRP
> transmits (section where Relay Tx's too will be ignored),
>

What do you mean by "section where Relay Tx's too will be ignored" ?

> I have changed the block you suggested, to avoid inserting 0's mid burst.
>

So does this give better results?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

From: Activecat [active...@gmail.com]
Sent: 04 June 2014 15:39
To: David Halls
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: 
Flow graph blocking when doing 2x1 transmission

On Wed, Jun 4, 2014 at 10:25 PM, David Halls 
mailto:david.ha...@toshiba-trel.com>> wrote:
Yes, there are 3. The Source Tx, the Relay Tx, and the Relay Rx.

To clarify,
i).  the "Source Tx" USRP may or may not receive data at any time interval.
ii). the "Relay Tx" USRP transmit data only when the "Source Tx" USRP receive 
data, and there is a delay due to signal processing
iii). the "Relay Rx" USRP will receive data only when the "Relay Tx" USRP 
transmit it,

is this correct?

Not quite...

i). the "Source Tx" USRP has a constant stream of data, and is constantly 
transmitting. If the codewords in the file are exhausted it repeats.
ii). the "Relay Tx" USRP transmits data only when data has been received by the 
"Relay Rx" (I will use tx_time to control when the received burst is 
re-transmitted)
iii). the "Relay Rx" USRP will receive data only when the "Source Tx" USRP 
transmits (section where Relay Tx's too will be ignored),

I have changed the block you suggested, to avoid inserting 0's mid burst.

void
avoid_block_impl::forecast (int noutput_items, gr_vector_int 
&ninput_items_required)
{
ninput_items_required[0] = noutput_items;
ninput_items_required[1] = 0;
}

int
avoid_block_impl::general_work (int noutput_items,
   gr_vector_int &ninput_items,
   gr_vector_const_void_star &input_items,
   gr_vector_void_star &output_items)
{
const gr_complex *in0 = (const gr_complex*) input_items[0];
const gr_complex *in1 = (const gr_complex*) input_items[1];
gr_complex *out0 = (gr_complex*) output_items[0];
gr_complex *out1 = (gr_complex*) output_items[1];

//if(DEBUG) fprintf(stderr, " noutput_items = %d, 
ninput_items[0] = %d, ninput_items[1] = %d.\n", noutput_items, ninput_items[0], 
ninput_items[1]);

// For first input, just copy
for (int i=0; i < noutput_items; i++)
out0[i] = in0[i];

// Count number of output items
int num_out1 = 0;

// If items available for second input, copy
for (int i=0; i < ninput_items[1]; i++)
{
out1[i] = in1[i];
if(!d_burst)
{
if(DEBUG) fprintf(stderr, " Entering 
burst...\n");
d_burst = true;
}
// Number of (actual) items tx'd this call
num_out1++;
// Total number of items in burst transmitted so far
d_items_sent++;
}

// For the rest of second output, fill with zeros
if(!d_burst)
{
for (int i=ninput_items[1]; i < noutput_items ; i++)
{
// Fill zeros
out1[i] = 0.0;
// Number of (zero) items tx'd this call
num_out1++;
}
}

// Mark end of burst
if(d_items_sent >= 1280*6) //TODO change to external burst 
length parameter
{
if(DEBUG) fprintf(stderr, " Finishing burst...\n");
d_burst = false;
d_items_sent = 0;
}

consume( 0, noutput_items);
consume( 1, ninput_items[1]); // Consume all available items

produce( 0, noutput_items);
produce( 1, num_out1); // Only produce the required number of 
items

return WORK_CALLED_PRODUCE;
}

NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
-

Re: [Discuss-gnuradio] GRC uses OSS instead of ALSA??

2014-06-04 Thread Tom Rondeau

On Mon, Jun 2, 2014 at 12:54 PM, John Meloche 
wrote:

> Hi guys,
>
> My application requires that I use a multi-channel audio device as an
> audio source.  I have in my system of hardware the Presonus 1818VSL
> external USB device.  This audio source is definetely working correctly
> with Ubuntu as I can monitor the level of each channel using Ardour without
> any preconfiguration whatsoever.
>
> My problem is that I am having absolutely no luck in trying to establish a
> connection between GRC and my multi-channel sound device (Presonus 1818).
> I have uninstalled pulse audio and made the chages to the
> /etc/modprobe.d/alsa-base.conf file  as per these directions.  I know for
> fact that this did work about two months ago, at that time, I was measuring
> each audio input in GRC using a scope sink.  It was beautiful and it worked
> fantasticly) http://forums.presonus.com/posts/list/28993.page
>
> Regardless of how my multi-channel audio source is delcared (i.e. blank,
> hw:0,0 or plughw:0,0)  GRC will always report that the OSS source has no
> file or directory.  I have read that OSS was discontinued quite some time
> ago.  How can I force GRC to use only the ALSA audio source?
>
> I have attached a couple of screen shots showing my very simple flowgraph
> and the ALSA mixer info.
>
> Thanks in advance for any advise to get me rolling in the right direction.
>
> John
>

John,

Any chance you've reinstalled anything in the meantime since this was
working before? We haven't (iirc) changed anything in the gr-audio system
recently. Generally, this is a dependency problem. The gr-audio was
reworked a few years ago, but it's now less verbose about telling you what
audio subsystems are and are not being built and installed. Take a look
that libasound2-dev is installed (the's the Debian/Ubuntu name for the
package). If you don't have the alsa dev package installed, it won't be
built. So if that's the case, install the dev package, then rerun cmake and
rebuild GNU Radio to try and recover it.

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

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

From: Activecat [active...@gmail.com]
Sent: 04 June 2014 15:21
To: David Halls
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: 
Flow graph blocking when doing 2x1 transmission

On Wed, Jun 4, 2014 at 8:53 PM, David Halls 
mailto:david.ha...@toshiba-trel.com>> wrote:
Hi Activecat,

I have disconnected the rest of the flow graph because it is extremely complex.

In the system I have a Source, a Relay (1 rx USRP, 1 tx USRP), a Destination. S 
---> R_rx/R_tx --> D

The two transmitters that you see on that flow graph snippet I sent you are the 
the Source Tx and the Relay Tx.

Payload TD Tx 1 is derived from input codewords that are generated in MATLAB 
and stored in a file, then loaded into the flow graph. The payload is created 
in a similar fashion to Martin's original OFDM_tx. This is then transmitted 
from Source Tx.

Until this point, no packets are received by Relay Rx but once the source 
transmits, these packets are then received by Relay Rx, and then there is a 
decode-and-forward chain of blocks, and this then creates Payload TD Tx 2.

The full flow graph is attached, but may be missing many blocks for you...

How many USRP are controlled by this flowgraph?
It seems at least three, what is the exact number?
---

Yes, there are 3. The Source Tx, the Relay Tx, and the Relay Rx.

NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] Gardner timing sync loop quetion

2014-06-04 Thread Tom Rondeau

On Tue, Jun 3, 2014 at 4:12 AM, Tiankun Hu  wrote:

> Hi all,
> I am designing a 2 order Gardner timing sync loop(with 1 order PI loop
> filter) for QAM64.
> As Best's PLL book metioned, timing sync loop's parameter can be
> calculated by using PLL theory.
> Now I need calculate the PI loop filter's factor K1(P gain) and K2(I
> gain). According PLL theory, we can get them from Wn(nature freq) Kd(phase
> detector gain) Ko(NCO gain).
> I can get Kd from open loop simulate, and Ko equals to 1
> Wn can get from BL(noise bandwidth).
> My quetion is how to define BL, anyone can tell me how to calculate it
> from PPM(ADC's freq offset)?
>
>
> Thanks
> Tiankun
>

Take a look at this:

http://www.trondeau.com/blog/2011/8/13/control-loop-gain-values.html

I don't think it exactly answers your question, but might be helpful. Also,
we have the gr::blocks::control_loop class that you can inherit from to
make this easier for you to use. See the costas_loop_cc block for an
example of how.

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

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

On Wed, Jun 4, 2014 at 8:53 PM, David Halls 
wrote:

> Hi Activecat,
>
> I have disconnected the rest of the flow graph because it is extremely
> complex.
>
> In the system I have a Source, a Relay (1 rx USRP, 1 tx USRP), a
> Destination. S ---> R_rx/R_tx --> D
>
> The two transmitters that you see on that flow graph snippet I sent you
> are the the Source Tx and the Relay Tx.
>
> Payload TD Tx 1 is derived from input codewords that are generated in
> MATLAB and stored in a file, then loaded into the flow graph. The payload
> is created in a similar fashion to Martin's original OFDM_tx. This is then
> transmitted from Source Tx.
>
> Until this point, no packets are received by Relay Rx but once the source
> transmits, these packets are then received by Relay Rx, and then there is a
> decode-and-forward chain of blocks, and this then creates Payload TD Tx 2.
>
> The full flow graph is attached, but may be missing many blocks for you...
>

How many USRP are controlled by this flowgraph?
It seems at least three, what is the exact number?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

Activecat,

In fact my horrible hack doesn't work properly. Once items start arriving at 
Payload TD Tx 2, they still don't arrive as 'consistently' (for want of a 
better word), as those from the Noise Source block, and thus zeros are inserted 
when they are not required!

David

-Original Message-
From: David Halls
Sent: 04 June 2014 11:41
To: Activecat; discuss-gnuradio@gnu.org
Cc: Martin Braun
Subject: RE: [Discuss-gnuradio] Scheduling a block even with no input items RE: 
Flow graph blocking when doing 2x1 transmission

Hi,

Thank you for those links. Unfortunately the rates for the two ports are not an 
exact ratio, so I am not sure how this will work. Also I have

ninput_items_required[0] = noutput_items; ninput_items_required[1] = 0;

I am not quite sure how to change this... Maybe it will help to show more 
clearly what I am doing.

Attached is a flow graph that shows how I have managed to achieve what I want - 
but clearly it is a real fudge.

I am doing a 2x1 transmission, so in time-domain (TD), I have [ Header 1 (240 
samples), Header 2 (240 samples), superimposed Payload Tx1 + Tx2 (1280 samples) 
] then this repeats.

Header TD Tx1, Header TD Tx2 and Payload TD Tx1 always have items available, 
*but* Payload TD Tx2 has no items at time=0.

I would like the header data (both Tx1 and Tx2 to always be transmitted, so 
that even when Payload TD Tx2 is not available, the protocol/frame structure 
does not break down.

Regards,

David

From: Activecat [active...@gmail.com]
Sent: 04 June 2014 10:51
To: discuss-gnuradio@gnu.org
Cc: David Halls
Subject: Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: 
Flow graph blocking when doing 2x1 transmission

On Wed, Jun 4, 2014 at 4:59 PM, David Halls 
mailto:david.ha...@toshiba-trel.com>> wrote:
Hi!

This shouldn't be the case. But is there any easy way to allow different rates 
on the two streams, so I could produce more zeros on stream 1 than items on 
stream 0? Or vice versa?

David


Please stay on the list.

To have different rates on different inputs, [1]  
http://lists.gnu.org/archive/html/discuss-gnuradio/2014-05/msg00166.html
[2]  http://gnuradio.4.n7.nabble.com/set-relative-rate-td46167.html



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

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

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

Sorry – I meant to hit reply all!

From: Activecat [mailto:active...@gmail.com]
Sent: 04 June 2014 10:51
To: discuss-gnuradio@gnu.org
Cc: David Halls
Subject: Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: 
Flow graph blocking when doing 2x1 transmission

On Wed, Jun 4, 2014 at 4:59 PM, David Halls 
mailto:david.ha...@toshiba-trel.com>> wrote:
Hi!

This shouldn't be the case. But is there any easy way to allow different rates 
on the two streams, so I could produce more zeros on stream 1 than items on 
stream 0? Or vice versa?

David

Please stay on the list.
To have different rates on different inputs,
[1]  http://lists.gnu.org/archive/html/discuss-gnuradio/2014-05/msg00166.html
[2]  http://gnuradio.4.n7.nabble.com/set-relative-rate-td46167.html

NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Scheduling a block even with no input items RE: Flow graph blocking when doing 2x1 transmission

On Wed, Jun 4, 2014 at 4:59 PM, David Halls 
wrote:

>  Hi!
>
>  This shouldn't be the case. But is there any easy way to allow different
> rates on the two streams, so I could produce more zeros on stream 1 than
> items on stream 0? Or vice versa?
>
>  David
>


Please stay on the list.

To have different rates on different inputs,
[1]
http://lists.gnu.org/archive/html/discuss-gnuradio/2014-05/msg00166.html
[2]  http://gnuradio.4.n7.nabble.com/set-relative-rate-td46167.html
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] NEWSDR Event This Friday June 6 in Boston

2014-06-04 Thread Golurk Hameshta

*
* Fourth-Annual *
*   *
* New England Workshop on Software-Defined Radio*
*  NEWSDR 2014  *
*   *
* Friday, 6 June 2014, 8:30 AM - 5:30 PM*
* Boston University, Photonics Center, 9th Floor*
*Boston, MA, USA*
*   *
*  http://www.sdr-boston.org/   *
*

  INVITATION TO PARTICIPATE

You are cordially invited to the 2014 New England Workshop
on Software Defined Radio (NEWSDR 2014), which is the fourth
installment of an annual series of workshops organized by
the Boston SDR User Group (SDR-Boston). This year NEWSDR
will be held on the 9th Floor of the Photonics Center of
Boston University on Friday 6 June 2014.

NEWSDR 2014 also features two technical oral presentation
sessions, several technical poster presentation sessions,
several hardware  demonstrations and SDR test-beds, and an
industry panel discussion, all focusing on the latest
advances in software-defined radio and/or cognitive radio
technology.

Please forward this message to your colleagues that may be
interested in NEWSDR'14.  We hope to see you there!

KEYNOTE SPEAKER:

  * Professor Jeffrey Reed, Virginia Tech
INVITED SPEAKERS:

  * Dr. Tom Rondeau, Rondeau Research LLC

  * Dr. Zoran Zvonar, MediaTek Wireless Inc.
SPONSORS:

  * The MathWorks Inc.
  * National Instruments / Ettus Research
  * Analog Devices Inc.
  * MediaTek Wireless Inc.
  * Range Networks Inc.
  * Boston University, Center for Information and Systems Engineering
ORAL/POSTER PRESENTATIONS:

  * Oral and poster presentations are now being solicited
  * See link at the bottom of this email to submit your abstract
online!
REGISTRATION:

  * Free with advanced online pre-registration (lunch and parking
included)
  * Space is limited, so register soon!
  * See link at the bottom of this email to register online.
ADDITIONAL INFORMATION:

The latest information of this event can be found at the following
website: http://www.sdr-boston.org/ (under "Workshops > NEWSDR 2014").
REGISTRATION LINK:

https://docs.google.com/forms/d/14e4GfEDrOaJJ0OLFWwZU4B79aR_Oi2NWkrXETnm1ijY/viewform
ORAL/POSTER ABSTRACT SUBMISSION LINK:

https://docs.google.com/forms/d/1ScEEjxvik8qh0wnMKydudjnCSJI2UBkNhvKeGWnXuYU/viewform
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Re: something about forecast()

Hi Xianda,

1.:
Yes, that will be the case

Greetings,
Marcus

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

[Discuss-gnuradio] Fwd: Re: something about forecast()




 Original Message 
Subject:Re: [Discuss-gnuradio] something about forecast()
Date:   Wed, 4 Jun 2014 16:52:11 +0800 (CST)
From:   xianda 
To: Marcus Müller 



Hi:
   Thank you.
   1.Oh,I understand it.If i say,this is according to how many input 
ports we connct to the block.If we connect 2 input ports(connect in python 
program),then use the ninput_items_required.size (),it will tell us 2.Right?
2.Another question i want to ask.Thank you.I have check my program as you 
said"However, you should not do get_tx_stream for every sample chunk you 
transmit, but only once for every USRP, before starting to send.".But i run my 
code,it also display so many "L L L".Is the sample to send too short?Thank 
you.Any advices will be appreciated.


Best regards,







At 2014-06-04 04:34:11, "Marcus Müller"  wrote:
>Hi Xianda,
>the io_signature specifies a minimum and a maximum number of inputs, so
>this might be 1,2 or 3.
>
>Greetings,
>Marcus
>On 04.06.2014 10:24, xianda wrote:
>> Hi:
>>   Thank you so much.
>>   Now i want to ask:if we set 
>>   gr::block("c_vcvc",
>>   
>> gr::io_signature::make(1, 3, sizeof(gr_complex)*length1),
>>   
>> gr::io_signature::make(1, 1, sizeof(gr_complex)*length1))
>> then: ninput_items_required.size ()=1 or 3?
>> Thanks,
>> Best regards
>>
>>
>>
>>
>>
>> At 2014-06-04 03:10:40, "Marcus Müller"  wrote:
>> Hi Xianda,
>>
>> Easiest answer first:
>>
>> 2. You need to write a forecast if, and only if, you're using general_work. 
>> I generally try to avoid doing that.
>>
>> Then:
>> 1.
>> ninput_items_required is, as you can see in the function signature, a 
>> reference to a vector.
>> The size of the vector is the number of input ports.
>> Compare to 
>> http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a5bc118d94944d2ff71e378f807fb8d28
>>
>> Greetings,
>> Marcus
>>
>>
>> On 04.06.2014 08:22, xianda wrote:
>>
>> Hi all:
>>  I want to know something about the forecast().
>>  I have already known that forcast() can tell  scheduler how many 
>> input items are required for each output item.
>>  1.But now i have read two example:
>> The first one:
>>void your_block::forecast(int 
>> noutput_items,gr_vector_int &ninput_items_required){
>> ninput_items_required[0]=100 * 
>> noutput_items;
>>
>> ninput_items_required[1]=100 * 
>> noutput_items; } 
>>  I have already understand it.
>> But the second one:
>>  void  forecast (int noutput_items, gr_vector_int 
>> &ninput_items_required)
>>{
>>unsigned ninputs = ninput_items_required.size 
>> ();
>>  for (unsigned i = 0; i < ninputs; i++)
>>ninput_items_required[i] = 1;}
>> I can't understand since we can't know how many input 
>> items we required,why use  ninput_items_required.size ().Can someone help me?
>>  2.I want to know if we use the general_work().Is it means that 
>> we must use the forcast()?Thanks.
>> Best regards
>>
>>
>>
>>
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.orghttps://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] using uhd_fft with USRP N210

Ah, missed that. You should not disable VOLK - almost all of GNU Radio
uses that by now.

On 04.06.2014 10:41, sammy zada wrote:
> Hi,
>
> I'm trying to run uhd_fft with usrp N210, my machine run ubuntu desktop
> 12.04.4 LTS.
>
> When I try to run uhd_fft which is located in
> /usr/local/src/gnuradio-3.7.2.1/gr-uhd/apps directory, i've got the
> following message:
> root@openlab:/usr/local/src/gnuradio-3.7.2.1/gr-uhd/apps# ./uhd_fft
> Traceback (most recent call last):
>   File "./uhd_fft", line 23, in 
> from gnuradio import gr, gru
> ImportError: No module named gnuradio
>
> This is the message i've got when installing gnuradio with command: cmake
> -DENABLE_VOLK=FALSE ../
> ##
> -- # Gnuradio enabled components
> -- ##
> --   * python-support
> --   * testing-support
>
>
> ___
> 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] using uhd_fft with USRP N210

Hi Sammy,
when building, basically *everything* was not built, so you don't really
have GNU Radio installed.
This is usually due to missing a crucial dependency of GNU Radio.
How did you install?
I recommend using pyBOMBs, if you didn't, because that should take care
of installing dependencies:
http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart

Greetings,
Marcus

On 04.06.2014 10:41, sammy zada wrote:
> Hi,
>
> I'm trying to run uhd_fft with usrp N210, my machine run ubuntu desktop
> 12.04.4 LTS.
>
> When I try to run uhd_fft which is located in
> /usr/local/src/gnuradio-3.7.2.1/gr-uhd/apps directory, i've got the
> following message:
> root@openlab:/usr/local/src/gnuradio-3.7.2.1/gr-uhd/apps# ./uhd_fft
> Traceback (most recent call last):
>   File "./uhd_fft", line 23, in 
> from gnuradio import gr, gru
> ImportError: No module named gnuradio
>
> This is the message i've got when installing gnuradio with command: cmake
> -DENABLE_VOLK=FALSE ../
> ##
> -- # Gnuradio enabled components
> -- ##
> --   * python-support
> --   * testing-support
>
>
> ___
> 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] something about forecast()

Hi Xianda,
the io_signature specifies a minimum and a maximum number of inputs, so
this might be 1,2 or 3.

Greetings,
Marcus
On 04.06.2014 10:24, xianda wrote:
> Hi:
>   Thank you so much.
>   Now i want to ask:if we set 
>   gr::block("c_vcvc",
>   
> gr::io_signature::make(1, 3, sizeof(gr_complex)*length1),
>   
> gr::io_signature::make(1, 1, sizeof(gr_complex)*length1))
> then: ninput_items_required.size ()=1 or 3?
> Thanks,
> Best regards
>
>
>
>
>
> At 2014-06-04 03:10:40, "Marcus Müller"  wrote:
> Hi Xianda,
>
> Easiest answer first:
>
> 2. You need to write a forecast if, and only if, you're using general_work. I 
> generally try to avoid doing that.
>
> Then:
> 1.
> ninput_items_required is, as you can see in the function signature, a 
> reference to a vector.
> The size of the vector is the number of input ports.
> Compare to 
> http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a5bc118d94944d2ff71e378f807fb8d28
>
> Greetings,
> Marcus
>
>
> On 04.06.2014 08:22, xianda wrote:
>
> Hi all:
>  I want to know something about the forecast().
>  I have already known that forcast() can tell  scheduler how many 
> input items are required for each output item.
>  1.But now i have read two example:
> The first one:
>void your_block::forecast(int 
> noutput_items,gr_vector_int &ninput_items_required){
> ninput_items_required[0]=100 * 
> noutput_items;
>
> ninput_items_required[1]=100 * 
> noutput_items; } 
>  I have already understand it.
> But the second one:
>  void  forecast (int noutput_items, gr_vector_int 
> &ninput_items_required)
>{
>unsigned ninputs = ninput_items_required.size 
> ();
>  for (unsigned i = 0; i < ninputs; i++)
>ninput_items_required[i] = 1;}
> I can't understand since we can't know how many input 
> items we required,why use  ninput_items_required.size ().Can someone help me?
>  2.I want to know if we use the general_work().Is it means that 
> we must use the forcast()?Thanks.
> Best regards
>
>
>
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.orghttps://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] using uhd_fft with USRP N210

2014-06-04 Thread sammy zada

Hi,

I'm trying to run uhd_fft with usrp N210, my machine run ubuntu desktop
12.04.4 LTS.

When I try to run uhd_fft which is located in
/usr/local/src/gnuradio-3.7.2.1/gr-uhd/apps directory, i've got the
following message:
root@openlab:/usr/local/src/gnuradio-3.7.2.1/gr-uhd/apps# ./uhd_fft
Traceback (most recent call last):
  File "./uhd_fft", line 23, in 
from gnuradio import gr, gru
ImportError: No module named gnuradio

This is the message i've got when installing gnuradio with command: cmake
-DENABLE_VOLK=FALSE ../
##
-- # Gnuradio enabled components
-- ##
--   * python-support
--   * testing-support
-- 
-- ##
-- # Gnuradio disabled components
-- ##
--   * volk
--   * doxygen
--   * sphinx
--   * gnuradio-runtime
--   * gr-ctrlport
--   * gr-blocks
--   * gnuradio-companion
--   * gr-fec
--   * gr-fft
--   * gr-filter
--   * gr-analog
--   * gr-digital
--   * gr-atsc
--   * gr-audio
--   * gr-comedi
--   * gr-channels
--   * gr-noaa
--   * gr-pager
--   * gr-qtgui
--   * gr-trellis
--   * gr-uhd
--   * gr-utils
--   * gr-video-sdl
--   * gr-vocoder
--   * gr-fcd
--   * gr-wavelet
--   * gr-wxgui
-- 
-- Using install prefix: /usr/local
-- Building for version: 3.7.2.1 / 3.7.2.1
-- Configuring done
-- Generating done
-- Build files have been written to: /usr/local/src/gnuradio-3.7.2.1/build

Can anyone help to solve this issue

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

Re: [Discuss-gnuradio] QT Gui FFT resizing Segfault

I think it's going wrong in getActionFromSize, which easy as it
looks[1], I don't get the hang of.
Why do we need a specific QAction based on the FFT length we're setting?
And why does an FFT size of 4 lead to negative indices in a QList?

Anyway, the actual bug was on my side, as I was constantly setting an
FFT size of 4. Which seemingly doesn't work.
@LD: try
set_fft_size(max(int($fftsize),32))
instead. I was then able to change the displayed FFT on the fly using QT
Gui sliders [2].

Greetings,
Marcus

[1] gr-qtgui/include/gnuradio/qtgui/form_menus.h
[2] https://gist.github.com/marcusmueller/edfef568a92821261f9f , the
adjustable_qtgui_fft.grc file should load nicely in a 3.7.4 GNU Radio, I
think it should work with 3.7.x
On 04.06.2014 09:21, Marcus Müller wrote:
> Hi!
>
> Alfredo: Jep, did that. GDB was how I figured out things went wrong in
> FreqDisplayForm::setFFTSize() in the first place :).
> Jörg: Interesting; but the error is quite reproducibly at the same
> place; I'll try to set a breakpoint at the kernel call and see if that
> happens again. But that will require some gdb magic (so that GDB only
> interrupts program flow when the fft size changes), and that's
> definitively something that would be worthwhile to learn, however I'm
> postponing this for now for reasons of time available.
>
> Greetings,
> Marcus
>
> On 04.06.2014 08:48, Jan Krämer wrote:
>> Hey,
>>
>> I know another GSoC Student has problems with the a GT GUI sink as
>> well. It would randomly SEGFAULT in a volk multiply kernel. I think it
>> is the volk_32_fc_32f_multiply_32fc kernel used in
>> waterfall_sink_X_impl::fft(). This kernel takes the FFT size as an
>> input argument, so it could be related to your problem. I just had a
>> quick glance at it so I am not sure though. I'll ask him to post his
>> exact problem when he arrives at the lab. Maybe he can shed a bit more
>> light on this problem
>>
>> -Jan
>>
>>
>> On 04.06.2014 01:43, Alfredo Muniz wrote:
>>> On Tue, Jun 3, 2014 at 4:35 PM, Marcus Müller >> > wrote:
>>>
>>> I hope someone more familiar with the qtgui infrastructure might
>>> chime in.
>>>
>>>
>>> Hey Marcus,
>>>
>>> Did you try debugging the SEGFAULT using gdb? This is a good
>>> reference to try:
>>> http://www.unknownroad.com/rtfm/gdbtut/gdbsegfault.html
>>>
>>>
>>> ___
>>> 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] QT Gui FFT resizing Segfault

Hi!

Alfredo: Jep, did that. GDB was how I figured out things went wrong in
FreqDisplayForm::setFFTSize() in the first place :).
Jörg: Interesting; but the error is quite reproducibly at the same
place; I'll try to set a breakpoint at the kernel call and see if that
happens again. But that will require some gdb magic (so that GDB only
interrupts program flow when the fft size changes), and that's
definitively something that would be worthwhile to learn, however I'm
postponing this for now for reasons of time available.

Greetings,
Marcus

On 04.06.2014 08:48, Jan Krämer wrote:
> Hey,
>
> I know another GSoC Student has problems with the a GT GUI sink as
> well. It would randomly SEGFAULT in a volk multiply kernel. I think it
> is the volk_32_fc_32f_multiply_32fc kernel used in
> waterfall_sink_X_impl::fft(). This kernel takes the FFT size as an
> input argument, so it could be related to your problem. I just had a
> quick glance at it so I am not sure though. I'll ask him to post his
> exact problem when he arrives at the lab. Maybe he can shed a bit more
> light on this problem
>
> -Jan
>
>
> On 04.06.2014 01:43, Alfredo Muniz wrote:
>>
>> On Tue, Jun 3, 2014 at 4:35 PM, Marcus Müller > > wrote:
>>
>> I hope someone more familiar with the qtgui infrastructure might
>> chime in.
>>
>>
>> Hey Marcus,
>>
>> Did you try debugging the SEGFAULT using gdb? This is a good
>> reference to try:
>> http://www.unknownroad.com/rtfm/gdbtut/gdbsegfault.html
>>
>>
>> ___
>> 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] something about forecast()

On Wed, Jun 4, 2014 at 2:22 PM, xianda  wrote:

> Hi all:
>  I want to know something about the forecast().
>  I have already known that forcast() can tell  scheduler how many
> input items are required for each output item.
>  1.But now i have read two example:
> The first one:
>void your_block::forecast(int
> noutput_items,gr_vector_int &ninput_items_required){
>
> ninput_items_required[0]=100 * 
> noutput_items;
> ninput_items_required[1]=100 * 
> noutput_items; }
>
>
In your first example above, you have exactly two input ports.
That's why you need to specify "ninput_items_required[0]" and
"ninput_items_required[1]", there are in total 2 ports.
In fact in this example the value of "ninput_items_required.size()" is 2.
In alternative, you could also replace above two lines with:

for (unsigned i=0; i < 2; i++)
   ninput_items_required[i] = 100 * noutput_items;


Or, to be more generic, you could also use this:

   for (unsigned i=0; i < ninput_items_required.size(); i++)
   ninput_items_required[i] = 100 * noutput_items;


>
>  2.I want to know if we use the general_work().Is it means that 
> we must use the forcast()?Thanks.
> Best regards
>
>
If you use "general" block, you need to specify "forecast()".
"General" block has "general_work()" function but not "general()" function.

If you use sync block, decim, interpolation block etc, you have "work()"
but not "general_work()", and you don't need to write "forecast()".
This is very straight-forward.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] something about forecast()