Re: [Discuss-gnuradio] phase coherence for N210 and SBX

2015-04-24 Thread Marcus Müller
Hi Marcus, hi Pengyu,

I'd like to make an addition to that:
modern gr-uhd uses a timed command to start streaming samples, so the
CORDICs in both USRPs should be aligned. But:
It doesn't inherently use timed commands for tuning; you should do
something like:

usrp_source0.set_command_time(uhd_source0.get_time_now()+0.1)
usrp_source0.set_center_freq(frequency)
usrp_source0.clear_command_time()
time.sleep(0.15)

after you configured your usrp_source and before your top_block is
.start()ed.

Generally, I like
http://files.ettus.com/manual/page_sync.html
because it explains a bit why and how things work.

Greetings,
Marcus


On 04/24/2015 12:28 AM, Marcus D. Leech wrote:
> On 04/23/2015 06:23 PM, Pengyu Zhang wrote:
>> Thanks for the inspiring tips. I did not use the WX GUI scope for
>> checking the phase offset. Instead, I log the baseband signal
>> received by each RX antenna. Then, I plot the IQ constellation of the
>> received baseband for checking their phase offset.
>>
>> Can you be a bit more specific when you say the "multi_usrp object"
>> and the "timed commands"? Are there tutorials that I can follow step
>> by step for using the two functions you mentioned? Your comments are
>> very helpful :)
>>
> A source/sink block in Gnu Radio uses an underlying multi_usrp object,
> so all you have to do is configure your source block for two channels,
> with
>   two devices, and use
>
> addr0=
>
> In the device arguments.
>
> Also, recent gr-uhd (3.7.6.1 and newer at least) use timed commands,
> so phase-zeroing will happen after a tune automatically, without you
> having
>   to do anything.
>
>
> The top of the UHD manual is here:
>
> http://files.ettus.com/manual/page_devices.htmlhttp://files.ettus.com/manual/page_devices.html
>
>
> The Doxygen docs are here:
>
> http://files.ettus.com/manual/page_coding.html
>
> The documents for gr-uhd are part of the Gnu Radio documentation:
>
> http://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.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


Re: [Discuss-gnuradio] Asking help about "gr-ieee802-11"

2015-04-24 Thread Bastian Bloessl



On 04/24/2015 03:00 AM, Activecat wrote:

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x815afb70 (LWP 4891)]
 0xb2fc302e in ofdm_decode_signal_impl::general_work(int,
std::vector >&, std::vector >&, std::vector
 >&) ()
from /usr/local/lib/libgnuradio-ieee802_11.so
 (gdb)


I think I placed a tag at a wrong offset. I don't know if this can cause 
a segfault, but maybe you can try the current version.


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


Re: [Discuss-gnuradio] I & Q channels in source module

2015-04-24 Thread Tom Rondeau
On Thu, Apr 23, 2015 at 3:09 PM, Yile Ku  wrote:

> I am writing a source module/block and I generate 16 bit signed I and Q
> values.  There is first a 16 bit I value then a 16 bit Q value repeated
> 1024 times.
>
> In my source module I have:
>
> usbradio_impl::usbradio_impl()
>   : gr::sync_block("usbradio",
>   gr::io_signature::make(1, 1, sizeof(short)),
>   gr::io_signature::make(1, 1, sizeof(short)))
> {
>state = 0;
>cnt = 0;
>set_max_noutput_items(1);
>set_max_output_buffer(2);
> }
>

Why are you using set_max_noutput_items and set_max_output_buffer like
this? Those numbers don't make any sense. These are fairly advanced
features that you should only use if you know /exactly/ what you are doing
with them. These lines will make assumptions about the flow of data that
will likely hurt how you process things in the work function.

Tom



> /*
>  * Our virtual destructor.
>  */
> usbradio_impl::~usbradio_impl()
> {
> }
>
> int
> usbradio_impl::work(int noutput_items,
>   gr_vector_const_void_star &input_items,
>   gr_vector_void_star &output_items)
> {
> short  *out = (short *) output_items[0];
>
> // Do <+signal processing+>
> stuff_output(out);
>
> // Tell runtime system how many output items we produced.
> return 1024;
> }
>
> The stuff_output(out) function will stuff an I value then a Q value 512
> times.
>
> Is that the correct way to present I & Q values?
>
> Thx,
> Y-
>
> ___
> 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] Correlation Estimation Block Oddity

2015-04-24 Thread Andy Walls
Hi Richard,

>  From: 
> Richard Bell
>   Subject: 
> Re: [Discuss-gnuradio] Correlation
> Estimation Block Oddity
>  Date: 
> Thu, 23 Apr 2015 15:38:38 -0700
> 
> __
> I have another question on tag placement for the correlation
> estimation block. In the screenshot I've attached, you'll see that the
> corr_start tag is placed well before the preamble actually starts.

OK.  That's the first thing you should try to fix.  You are crossing the
correlation threshold too early.

Either

a. Get rid of leading 0's in the correlation sequence that you are
using,
b. Set the threshold on the corr_est block to something higher than the
default 0.9 (90%), or
c. make the correlation sequence "more unique" somehow, e.g. make it
longer.

As I mentioned in my previous email, the "corr_start" tags is placed at
the length of your matched filter samples before where the correlation
peak was detected.

You can eyeball how the correlation is going by plotting the Magnitude^2
of the "corr" output on top of the output signal (use a tag_gate block
to block the tags coming out of the "corr" output).  The output signal
is delayed by the length of the matched filter, so you can see the
correlation peak and the "corr_start" tag line up.

See the attached screen shot of an AIS preamble and the scaled magnitude
squared of the correlator output.


>  If I use the 'delay tag' field to move it to the end of the preamble
> where I need it, it stops delaying, no matter how big I make the
> delay,

Yup, the code forces a maximum delay.  You can delay it to the end of
your matched filter and no further:
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/corr_est_cc_impl.cc#L65

The code does this because GnuRadio will not let us tag samples outside
of the window of samples passed to the current call to work.  By setting
the bound of the marking delay to the start and end of the matched
filter, with other mechanisms in the block, we are guaranteed to be able
to mark the sample.

>  before it reaches the end of the preamble.

Well as far as the block is concerned, you are able to mark to the end
of the matched filter where the correlation peak occurred (but no
further), which should be the end of your preamble.  Your problem is
that the block declared a correlation too early.


>  This is shown in the picture. I need this tag to denote the start of
> the header for the Header Payload Demux block. 

Out of curiosity, what's doing timing recovery, i.e. finding the optimal
bit sampling times?  I use the tagging delay out of the corr_est block
to mark the center of the first bit in the preamble, to tell downstream
bit timing recovery blocks to reset/realign at that point.

Regards,
Andy

> 
> My question is, given the situation in the screenshot, is there a way
> I can delay just the tag in grc using a block? I'm not sure how to get
> the tag positioned where I need it at this point. 
> 
> 
> Help is greatly appreciated
> 
> 
> v/r,
> 
> Rich
> 
> 
> 

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


Re: [Discuss-gnuradio] GRCon15: Hotels

2015-04-24 Thread Ben Reynwar
There are also two hostels nearby for about $35/night.

https://www.google.com/maps/search/hostel+near+Center+for+Strategic+and+International+Studies/@38.9065175,-77.0376912,15z

On Thu, Apr 23, 2015 at 9:41 AM, Michael Dickens 
wrote:

> In case folks are wondering, there are quite a few hotels and other
> lodging places within easy walking distance of the GRCon15 venue: the
> Center for Strategic and International Studies [1]. For whatever reason,
> places of lodging near the CSIS are quite reasonably priced for
> Washington, DC right now: typically $110 to $180 / night before taxes &
> such [2]. There will be no conference-sponsored group-rate hotels, given
> these prices. So, knowing that GRCon15 is August 24 through 28, book
> your lodging sooner rather than later to lock in these prices! We will
> also include this information on the GRCon15 website, which we're
> actively working on. - MLD
>
> Suggested Hotels:
>
> a) Courtyard Washington Embassy Row
> 1600 Rhode Island Avenue, NW, Washington, DC 20036
> Rates starting at $169/night
> <
>
> http://www.marriott.com/hotels/travel/wasem-courtyard-washington-embassy-row/
> >
>
> b) The Beacon Hotel
> 1615 Rhode Island Avenue, NW, Washington, DC 20036
> Rates starting at $140/night.  Book 45 days in advance for the best
> rate.
> <
>
> http://www.beaconhotelwdc.com/default.aspx?pg=home&hid=587&vl=516d3e7f-095e-4f30-9ea9-2d59b250405f
> >
>
> [1] CSIS, 1616 Rhode Island Avenue NW, Washington, DC
> < http://csis.org/about-us/conference-center-csis/ >
>
> [2] Google Maps: hotels near CSIS with prices for August 23 -> 29
> <
>
> https://www.google.com/maps/search/hotels/@38.906542,-77.0377236,17z/data=!4m9!2m8!3m3!1shotels!2s1616+Rhode+Island+Ave+NW,+Washington,+DC+20036!3s0x89b7b7c09fe71ec7:0x3b622617cab9f901!5m3!5m2!1s2015-08-23!2i6
> >
>
> ___
> 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] uhd version

2015-04-24 Thread Pengyu Zhang
Hi,

I meet problems when I try to upgrade UHD to a version higher than 3.7.6.1.

I follow these UHD installation instructions shown in the following link.

sudo bash -c 'echo "deb
http://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/`lsb_release -cs`
`lsb_release -cs` main" > /etc/apt/sources.list.d/ettus.list'
sudo apt-get update
sudo apt-get install -t `lsb_release -cs` uhd

http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Linux

Then I check the version of installed UHD using the following command. It
looks like that I have installed UHD 3.8.0.

$ dpkg -s uhd
Package: uhd
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 133399
Maintainer: Ettus Research 
Architecture: amd64
Version: 003.008.000-release
Depends: libboost-all-dev
Recommends: python, python-tk
Description: Ettus Research - USRP Hardware Driver

However, when I run a flow graph, I get the following messages, which seems
to suggest that I am running 3.5.5.0 instead of 3.8.0. Any tips on how to
fix this problem? Thanks.

$ python top_block.py
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown

Attached is the flow graph I am running...

Pengyu
#!/usr/bin/env python
##
# Gnuradio Python Flow Graph
# Title: Top Block
# Generated: Thu Apr 23 15:10:01 2015
##

from gnuradio import analog
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import uhd
from gnuradio import wxgui
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from gnuradio.wxgui import scopesink2
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import time
import wx

class top_block(grc_wxgui.top_block_gui):

def __init__(self):
grc_wxgui.top_block_gui.__init__(self, title="Top Block")
_icon_path = "/usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png"
self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))

##
# Variables
##
self.samp_rate = samp_rate = 100

##
# Blocks
##
self.wxgui_scopesink2_1 = scopesink2.scope_sink_f(
	self.GetWin(),
	title="amp scope",
	sample_rate=samp_rate,
	v_scale=0,
	v_offset=0,
	t_scale=0,
	ac_couple=True,
	xy_mode=False,
	num_inputs=2,
	trig_mode=wxgui.TRIG_MODE_AUTO,
	y_axis_label="Counts",
)
self.Add(self.wxgui_scopesink2_1.win)
self.uhd_usrp_source_0_0 = uhd.usrp_source(
	device_addr="addr=192.168.10.3",
	stream_args=uhd.stream_args(
		cpu_format="fc32",
		channels=range(1),
	),
)
self.uhd_usrp_source_0_0.set_clock_source("external", 0)
self.uhd_usrp_source_0_0.set_time_source("external", 0)
self.uhd_usrp_source_0_0.set_subdev_spec("A:0", 0)
self.uhd_usrp_source_0_0.set_time_unknown_pps(uhd.time_spec())
self.uhd_usrp_source_0_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0_0.set_center_freq(91500, 0)
self.uhd_usrp_source_0_0.set_gain(10, 0)
self.uhd_usrp_source_0_0.set_auto_dc_offset(0,0)
self.uhd_usrp_source_0_0.set_antenna("RX2", 0)
self.uhd_usrp_source_0_0.set_bandwidth(200, 0)
self.uhd_usrp_source_0 = uhd.usrp_source(
	device_addr="addr=192.168.10.2",
	stream_args=uhd.stream_args(
		cpu_format="fc32",
		channels=range(1),
	),
)
self.uhd_usrp_source_0.set_clock_source("external", 0)
self.uhd_usrp_source_0.set_time_source("external", 0)
self.uhd_usrp_source_0.set_subdev_spec("A:0", 0)
self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_center_freq(91500, 0)
self.uhd_usrp_source_0.set_gain(10, 0)
self.uhd_usrp_source_0.set_auto_dc_offset(0,0)
self.uhd_usrp_source_0.set_antenna("RX2", 0)
self.uhd_usrp_source_0.set_bandwidth(200, 0)
self.uhd_usrp_sink_0 = uhd.usrp_sink(
	device_addr="addr0=192.168.10.3",
	stream_args=uhd.stream_args(
		cpu_format="fc32",
		channels=range(1),
	),
)
self.uhd_usrp_sink_0.set_clock_source("external", 0)
self.uhd_usrp_sink_0.set_time_source("external", 0)
self.uhd_usrp_sink_0.set_subdev_spec("A:0", 0)
self.uhd_usrp_sink_0.set_time_unknown_pps(uhd.time_spec())
self.uhd_usrp_sink_0.set_samp_rate(samp_rate)
self.uhd_usrp_sink_0.set_center_freq(91500, 0)
self.uhd_usrp_sink_0.set_gain(10, 0)
self.uhd

Re: [Discuss-gnuradio] uhd version

2015-04-24 Thread Marcus D. Leech

On 04/24/2015 03:15 PM, Pengyu Zhang wrote:

Hi,

I meet problems when I try to upgrade UHD to a version higher than 
3.7.6.1.


I follow these UHD installation instructions shown in the following link.
sudo bash -c 'echo "debhttp://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/`lsb_release  
  -cs` `lsb_release -cs` 
main" > /etc/apt/sources.list.d/ettus.list'
sudo apt-get update
sudo apt-get install -t `lsb_release -cs` uhd
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Linux

Then I check the version of installed UHD using the following command. 
It looks like that I have installed UHD 3.8.0.


$ dpkg -s uhd
Package: uhd
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 133399
Maintainer: Ettus Research mailto:supp...@ettus.com>>
Architecture: amd64
Version: 003.008.000-release
Depends: libboost-all-dev
Recommends: python, python-tk
Description: Ettus Research - USRP Hardware Driver

However, when I run a flow graph, I get the following messages, which 
seems to suggest that I am running 3.5.5.0 instead of 3.8.0. Any tips 
on how to fix this problem? Thanks.


$ python top_block.py
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown

Attached is the flow graph I am running...

Pengyu


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Use your package tool, apt-get to erase the existing UHD, which was 
probably installed from your distributions package repo,

  and try the install again from the Ettus repository.


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


Re: [Discuss-gnuradio] phase coherence for N210 and SBX

2015-04-24 Thread Pengyu Zhang
Hi Marcus,

I updated the flow graph (attached) as you suggested. It would be great if
you can help check and let me know if I am wrong...

For upgrading the UHD, I followed this link. UHD is installed successfully.
However, it seems that gnuradio does not call the latest UHD. Instead, it
still calls uhd-host which is combined in the gnuradio package. Do you have
suggestions about how to solve this problem? Thanks.

Pengyu

On Thu, Apr 23, 2015 at 6:28 PM, Marcus D. Leech  wrote:

> On 04/23/2015 06:23 PM, Pengyu Zhang wrote:
>
>> Thanks for the inspiring tips. I did not use the WX GUI scope for
>> checking the phase offset. Instead, I log the baseband signal received by
>> each RX antenna. Then, I plot the IQ constellation of the received baseband
>> for checking their phase offset.
>>
>> Can you be a bit more specific when you say the "multi_usrp object" and
>> the "timed commands"? Are there tutorials that I can follow step by step
>> for using the two functions you mentioned? Your comments are very helpful :)
>>
>>  A source/sink block in Gnu Radio uses an underlying multi_usrp object,
> so all you have to do is configure your source block for two channels, with
>   two devices, and use
>
> addr0=
>
> In the device arguments.
>
> Also, recent gr-uhd (3.7.6.1 and newer at least) use timed commands, so
> phase-zeroing will happen after a tune automatically, without you having
>   to do anything.
>
>
> The top of the UHD manual is here:
>
>
> http://files.ettus.com/manual/page_devices.htmlhttp://files.ettus.com/manual/page_devices.html
>
> The Doxygen docs are here:
>
> http://files.ettus.com/manual/page_coding.html
>
> The documents for gr-uhd are part of the Gnu Radio documentation:
>
> http://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html
>
>
>


mimo_signal.grc
Description: Binary data
#!/usr/bin/env python
##
# Gnuradio Python Flow Graph
# Title: Top Block
# Generated: Fri Apr 24 16:18:47 2015
##

from gnuradio import analog
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import uhd
from gnuradio import wxgui
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from gnuradio.wxgui import scopesink2
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import time
import wx

class top_block(grc_wxgui.top_block_gui):

def __init__(self):
grc_wxgui.top_block_gui.__init__(self, title="Top Block")
_icon_path = "/usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png"
self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))

##
# Variables
##
self.samp_rate = samp_rate = 10

##
# Blocks
##
self.wxgui_scopesink2_1 = scopesink2.scope_sink_f(
	self.GetWin(),
	title="amp scope",
	sample_rate=samp_rate,
	v_scale=0,
	v_offset=0,
	t_scale=0,
	ac_couple=True,
	xy_mode=False,
	num_inputs=2,
	trig_mode=wxgui.TRIG_MODE_AUTO,
	y_axis_label="Counts",
)
self.Add(self.wxgui_scopesink2_1.win)
self.uhd_usrp_source_0 = uhd.usrp_source(
	device_addr="addr0=192.168.10.2, addr1=192.168.10.3",
	stream_args=uhd.stream_args(
		cpu_format="fc32",
		channels=range(2),
	),
)
self.uhd_usrp_source_0.set_clock_source("external", 0)
self.uhd_usrp_source_0.set_time_source("external", 0)
self.uhd_usrp_source_0.set_subdev_spec("A:0", 0)
self.uhd_usrp_source_0.set_clock_source("external", 1)
self.uhd_usrp_source_0.set_time_source("external", 1)
self.uhd_usrp_source_0.set_subdev_spec("A:0", 1)
self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_center_freq(91500, 0)
self.uhd_usrp_source_0.set_gain(10, 0)
self.uhd_usrp_source_0.set_antenna("RX2", 0)
self.uhd_usrp_source_0.set_bandwidth(200, 0)
self.uhd_usrp_source_0.set_center_freq(91500, 1)
self.uhd_usrp_source_0.set_gain(10, 1)
self.uhd_usrp_source_0.set_antenna("RX2", 1)
self.uhd_usrp_source_0.set_bandwidth(200, 1)
self.uhd_usrp_sink_0 = uhd.usrp_sink(
	device_addr="addr0=192.168.10.3",
	stream_args=uhd.stream_args(
		cpu_format="fc32",
		channels=range(1),
	),
)
self.uhd_usrp_sink_0.set_clock_source("external", 0)
self.uhd_usrp_sink_0.set_time_source("external", 0)
self.uhd_usrp_sink_0.set_subdev_spec("A:0", 0)
self.uhd_usrp_sink_0.set_ti

Re: [Discuss-gnuradio] phase coherence for N210 and SBX

2015-04-24 Thread Marcus D. Leech

On 04/24/2015 04:27 PM, Pengyu Zhang wrote:

Hi Marcus,

I updated the flow graph (attached) as you suggested. It would be 
great if you can help check and let me know if I am wrong...


For upgrading the UHD, I followed this link. UHD is installed 
successfully. However, it seems that gnuradio does not call the latest 
UHD. Instead, it still calls uhd-host which is combined in the 
gnuradio package. Do you have suggestions about how to solve this 
problem? Thanks.


Pengyu

On Thu, Apr 23, 2015 at 6:28 PM, Marcus D. Leech > wrote:


On 04/23/2015 06:23 PM, Pengyu Zhang wrote:

Thanks for the inspiring tips. I did not use the WX GUI scope
for checking the phase offset. Instead, I log the baseband
signal received by each RX antenna. Then, I plot the IQ
constellation of the received baseband for checking their
phase offset.

Can you be a bit more specific when you say the "multi_usrp
object" and the "timed commands"? Are there tutorials that I
can follow step by step for using the two functions you
mentioned? Your comments are very helpful :)

A source/sink block in Gnu Radio uses an underlying multi_usrp
object, so all you have to do is configure your source block for
two channels, with
  two devices, and use

addr0=

In the device arguments.

Also, recent gr-uhd (3.7.6.1 and newer at least) use timed
commands, so phase-zeroing will happen after a tune automatically,
without you having
  to do anything.


The top of the UHD manual is here:


http://files.ettus.com/manual/page_devices.htmlhttp://files.ettus.com/manual/page_devices.html

The Doxygen docs are here:

http://files.ettus.com/manual/page_coding.html

The documents for gr-uhd are part of the Gnu Radio documentation:

http://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html



Uninstall all your uhd and gnuradio packages, and re-install, following 
the guide here:


http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki/GNU_Radio_UHD


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


Re: [Discuss-gnuradio] phase coherence for N210 and SBX

2015-04-24 Thread Pengyu Zhang
I got the same UHD version (shown below) when I use apt-get for
installation. I will try the PyBOMBS now...

$ python top_block.py
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown

$ apt-get install gnuradio


On Fri, Apr 24, 2015 at 4:48 PM, Marcus D. Leech  wrote:

>  On 04/24/2015 04:27 PM, Pengyu Zhang wrote:
>
> Hi Marcus,
>
>  I updated the flow graph (attached) as you suggested. It would be great
> if you can help check and let me know if I am wrong...
>
>  For upgrading the UHD, I followed this link. UHD is installed
> successfully. However, it seems that gnuradio does not call the latest UHD.
> Instead, it still calls uhd-host which is combined in the gnuradio package.
> Do you have suggestions about how to solve this problem? Thanks.
>
>  Pengyu
>
> On Thu, Apr 23, 2015 at 6:28 PM, Marcus D. Leech 
> wrote:
>
>> On 04/23/2015 06:23 PM, Pengyu Zhang wrote:
>>
>>> Thanks for the inspiring tips. I did not use the WX GUI scope for
>>> checking the phase offset. Instead, I log the baseband signal received by
>>> each RX antenna. Then, I plot the IQ constellation of the received baseband
>>> for checking their phase offset.
>>>
>>> Can you be a bit more specific when you say the "multi_usrp object" and
>>> the "timed commands"? Are there tutorials that I can follow step by step
>>> for using the two functions you mentioned? Your comments are very helpful :)
>>>
>>>  A source/sink block in Gnu Radio uses an underlying multi_usrp object,
>> so all you have to do is configure your source block for two channels, with
>>   two devices, and use
>>
>> addr0=
>>
>> In the device arguments.
>>
>> Also, recent gr-uhd (3.7.6.1 and newer at least) use timed commands, so
>> phase-zeroing will happen after a tune automatically, without you having
>>   to do anything.
>>
>>
>> The top of the UHD manual is here:
>>
>>
>> http://files.ettus.com/manual/page_devices.htmlhttp://files.ettus.com/manual/page_devices.html
>>
>> The Doxygen docs are here:
>>
>> http://files.ettus.com/manual/page_coding.html
>>
>> The documents for gr-uhd are part of the Gnu Radio documentation:
>>
>> http://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html
>>
>>
>>
>  Uninstall all your uhd and gnuradio packages, and re-install, following
> the guide here:
>
>
> http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki/GNU_Radio_UHD
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] phase coherence for N210 and SBX

2015-04-24 Thread Neel Pandeya
Hello Pengyu:

I'll send you my build instructions document. I think that will help guide
you.

--Neel



On 24 April 2015 at 14:23, Pengyu Zhang  wrote:

> I got the same UHD version (shown below) when I use apt-get for
> installation. I will try the PyBOMBS now...
>
> $ python top_block.py
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown
>
> $ apt-get install gnuradio
>
>
> On Fri, Apr 24, 2015 at 4:48 PM, Marcus D. Leech 
> wrote:
>
>>  On 04/24/2015 04:27 PM, Pengyu Zhang wrote:
>>
>> Hi Marcus,
>>
>>  I updated the flow graph (attached) as you suggested. It would be great
>> if you can help check and let me know if I am wrong...
>>
>>  For upgrading the UHD, I followed this link. UHD is installed
>> successfully. However, it seems that gnuradio does not call the latest UHD.
>> Instead, it still calls uhd-host which is combined in the gnuradio package.
>> Do you have suggestions about how to solve this problem? Thanks.
>>
>>  Pengyu
>>
>> On Thu, Apr 23, 2015 at 6:28 PM, Marcus D. Leech 
>> wrote:
>>
>>> On 04/23/2015 06:23 PM, Pengyu Zhang wrote:
>>>
 Thanks for the inspiring tips. I did not use the WX GUI scope for
 checking the phase offset. Instead, I log the baseband signal received by
 each RX antenna. Then, I plot the IQ constellation of the received baseband
 for checking their phase offset.

 Can you be a bit more specific when you say the "multi_usrp object" and
 the "timed commands"? Are there tutorials that I can follow step by step
 for using the two functions you mentioned? Your comments are very helpful 
 :)

  A source/sink block in Gnu Radio uses an underlying multi_usrp
>>> object, so all you have to do is configure your source block for two
>>> channels, with
>>>   two devices, and use
>>>
>>> addr0=
>>>
>>> In the device arguments.
>>>
>>> Also, recent gr-uhd (3.7.6.1 and newer at least) use timed commands, so
>>> phase-zeroing will happen after a tune automatically, without you having
>>>   to do anything.
>>>
>>>
>>> The top of the UHD manual is here:
>>>
>>>
>>> http://files.ettus.com/manual/page_devices.htmlhttp://files.ettus.com/manual/page_devices.html
>>>
>>> The Doxygen docs are here:
>>>
>>> http://files.ettus.com/manual/page_coding.html
>>>
>>> The documents for gr-uhd are part of the Gnu Radio documentation:
>>>
>>> http://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html
>>>
>>>
>>>
>>  Uninstall all your uhd and gnuradio packages, and re-install, following
>> the guide here:
>>
>>
>> http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki/GNU_Radio_UHD
>>
>>
>>
>
> ___
> 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] Two rtl2832 dongles in a GRC project

2015-04-24 Thread Kevin Reid
On Apr 23, 2015, at 3:32, Игорь Попов  wrote:

> I try to make project with two dongles rtl2832+r820.
> 
> In GNU Radio Companion v3.7.6.1-58-g620817ed I made simple project with two 
> equal channels containing rtl2832_source block and blocks_ctrlport_probe2. 
> And I have an error. The output of programm is:
[...]
> libusb error: unknown return code [-6] (int 
> rtl2832::demod::find_device():446) "libusb_claim_interface(devh, 0)"

I'm not familiar with this particular block you're using, but I highly 
recommend you use gr-osmosdr's source block instead. It is widely used and 
works with rtl-sdr devices, and I can confirm that it handles multiple devices 
well.

With gr-osmosdr, you can use the device string to specify two RTL dongles 
generically:

   osmosdr.source('rtl=0')
   osmosdr.source('rtl=1')

or using their EEPROM serials instead, which is useful for consistent 
selection. (Note that most dongles come from the factory with a serial number 
like '01', so you'll have to use the rtl_eeprom tool to rewrite them to 
unique text of your choice.)

-- 
Kevin Reid  


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


[Discuss-gnuradio] GRCon15> Website & Registration

2015-04-24 Thread Michael Dickens
We have a basic website up for GRCon15 <
http://www.trondeau.com/gnu-radio-conference-2015/ >, which includes
EventBright registration for the New Developers Day (Monday, August 24)
and the Developers Conference (Tuesday, August 24 - Friday, August 27).
We are updating the website as information becomes available, and will
post to this list when significant information is added or changed.

Best Regards,

John Malsbury
Michael Dickens
Tom Rondeau

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


[Discuss-gnuradio] UHD: USRP Source

2015-04-24 Thread Gerome Jan L
Hello,

I'm trying to receive a 6 MHz TV signal. What frequency should I set
my UHD: USRP Source in the GRC?
Thanks.

*Gerome Jan M. Llames *
Engineering Research and Development for Technology (ERDT) Scholar
University of San Carlos - Technological Campus
Nasipit Talamban, Cebu City, Philippines, 6000
Mobile: +639271525124
Email: geromejanlla...@gmail.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] How do I use the Gnuradio GRC XML RPC client or server components?

2015-04-24 Thread numeric
Thank you Marcus for your reply.

Yes; to answer your question. The Linux version is Freepascal with the
Lazarus IDE. It is very much like Delphi with a useful exception. No BDE
(Borland Database Engine) is required. 

You have given me an idea for a plan to solve my question. If the XMLPRC is
a DLL then freepascal can directly import the DLL and gain access to it's
functions. No need to pipe the string to a convertor. 
Today my USB drive got messed up. I have to re-load Linux, gnuradio and
Lazarus to continue the effort. A day or two should complete the
restoration; the "BOSS " (not the boss at work) permitting.

Rob 





Marcus Müller-3 wrote
> Now, for almost any language out there exist XML-RPC implementations, I
> guess -- however, if that is the case for Pascal (I guess you're using
> freepascal?), I don't know. 
> 
> 
> 
> Maybe you'll have to swallow the pill and
> either write a "Pascal-writes-stuff-into-a-pipe" to XML-RPC converter in
> your language of choice (in python, that would be but this much code,
> approximately, untested:
> 
> #!/usr/bin/python2
> import xmlrpclib
> s = xmlrpclib.Server('http://localhost:8080')
> commanddict = { "frequency": lambda x: s.set_freq(float(x))  ,
> "gain": lambda x: s.set_gain(float(x)),
> "taps": lambda x:
> s.set_filtertaps(list(map(float,x.split(",",
> "stop": lambda x: s.stop()
>   }
> inputfile = open("/path/to/the/fifo", "r")
> while True:
> line = inputfile.readline()
> if line.lower().startswith("exit"):
> break
> command, valuestring = line.split(":")
> #now, get command from dictionary and apply it to string
> try:
> commanddict[command](valuestring)
> except: #this happens if the command is not in the dict, or
> something went wrong doing RPC
> pass # don't do anything, just wait for the next command
> 
> Now, of you'll need to
> mkfifo /path/to/the/fifo
> 
> and have your pascal program write lines of the scheme
> 
> gain:34
> taps:1,2,3,4.0
> stop:nowtheflowgraphdiesandthiscommandjustneedsaparameter
> exit
> 
> to that filename.
> 
> I assume things are equally easy in C++, but I've never tried XML-RPC
> from C++, and all the string-juggling really gets easy in python, imho.
> 
> Best regards,
> Marcus





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/How-do-I-use-the-Gnuradio-GRC-XML-RPC-client-or-server-components-tp53427p53471.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