On 12/07/2013 12:30 AM, John Blommers wrote:
> In gnuradio-companion, from time to time, it becomes necessary to
> copy and paste the parameters from one block to another block’s
In case this helps: you can copy and paste blocks in the flowgraph
editor, and all parameters will be duplicated into
On 12/05/2013 12:41 PM, Aylons Hazzud wrote:
> I have been experimenting with the stream selector in gnuradio
> companion, but am stuck in situation.
>
> First, how do I change a variable after N samples? I want the signal
> to switch from a filter to another at a fixed rate, but blks2.selector
On 01/27/2014 11:19 PM, Marco Bosco wrote:
> Hi all!
>
> I have a simple flowgraph: a signal source, a throttle and a
> waterfall plot. I'd like to change the frequency of the signal source
> during runtime using the output of a python script. The output of the
> python script is time-varying, t
On 10/05/2014 04:25 AM, Gisle Vanem wrote:
> Since my previous message seems to be ignored, here is something simpler
> for you to comment on.
>
> In gr-blocks/lib/stream_pdu_base.cc, the read() and write() functions
> are used on sockets. This doesn't work well on Windows as you're
> probably a
On 12/11/2011 08:26 PM, Nowlan, Sean wrote:
> I'm not sure whether this is a GNU radio or USRP issue, so I'm
> posting to both lists. I played around with GNU radio's stream
> tagging feature and managed to implement something that does timed
> bursts (partially by taking a lead from tag_source_d
On 12/12/2011 08:40 AM, Justin Ford wrote:
>
> Are errors expected on the first attempt of cmake or could the errors
> indicate an underlying dependency issue? I have other build issues and I'm
> trying to rule out all the possibilities.
>
> When I first attempt cmake I get errors:
>
> -- U
On 12/12/2011 09:59 AM, Justin Ford wrote:
>
>
>
>
>> Date: Mon, 12 Dec 2011 08:44:48 -0800
>> From: j...@ettus.com
>> To: discuss-gnuradio@gnu.org
>> Subject: Re: [Discuss-gnuradio] cmake errors on first attempt with master
>> branch
>>
>>
>> Cant tel
On 12/12/2011 05:10 PM, Paul Miller wrote:
>
> On Wed, Dec 7, 2011 at 2:03 PM, Josh Blum wrote:
>> I cant say yet as to why, but at least its reproducible.
>
> I spent a few hours source diving today and gdb-stepping. I
> could not figure it out, but I did find that
On 12/12/2011 08:14 PM, Phone Naing MYINT wrote:
> Hi,
>
> I'm using USRP2 with RFX2400 daughter board. I'm using GRC. By default which
> antenna are used for USRP-source and USRP-sink?
http://files.ettus.com/uhd_docs/manual/html/dboards.html#rfx-series
-josh
On 12/12/2011 08:25 PM, Phone Naing MYINT wrote:
> Hi,
>
> TX is clear, defaulted to TX/RX. RX default to direct conversion, what does
> it mean?
RFX2400 is a direct conversion receiver *and* a direct conversion
transmitter. What the docs really should say:
1) When you tune the transmit chain
On 12/13/2011 09:02 AM, osama mohamed wrote:
>
> hi nick, thanks for your reply i tried the same command line
> arguments you gave me but the problem that there is always an under
> run error even if i change the args i tried several combinations but
> none of them worked any suggestions abou
On 12/13/2011 09:17 AM, Evan Merewether wrote:
> I would like to say that I just received a new N210 and am very happy with
> the quality and performance of the device. I have started to familiarize
> myself with the included utilities and have run the uhd_cal_* routines.
>
>
>
Thanks!
> M
On 12/14/2011 08:07 AM, Urban Kuhar wrote:
> Hi guys!
>
> I have problems with writing a processing block in python. I looked at the
> examples here
> http://gnuradio.org/redmine/projects/gnuradio/wiki/WriteBlocksInPython but
> when I try to create a new class that inherits gr.sync_block (or any
On 12/14/2011 01:55 PM, Evan Merewether wrote:
> I have been looking more at the performance of the udh_cal_* routines to try
> and understand the operation of my N210 and the SBX card. I found the cal
> files that I had previously generated and moved them into a separate
> directory to prevent
On 12/15/2011 02:57 AM, Matthias Schäfer wrote:
> Hi,
> still have the error with the latest git of uhd:
>
> matze@matze-Studio-XPS-435MT:~/Downloads/uhd/firmware/fx2/usrp1$
> uhd_usrp_probe
> linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.004.000-4f40325
>
> -- Loading firmware image:
> /
On 12/18/2011 11:18 AM, Achilleas Anastasopoulos wrote:
> Matt,
>
> I wanted to test your python file.
> I first commented out the lock/unlock and the program continuously
> prints "noflow". Is this the expected behavior?
>
> My understainding is that after every flushing of the message queue a
On 12/19/2011 07:58 AM, Paul Miller wrote:
> If I'm doing something dumb, I can't find it. Happens all the
> time though. I'm using the python_blocks branch
> 5cd66eef8ab8a81589dc08a134457d15b431434e .
>
> I made a really simple sync_block that square-waves an input
> signal. I have a fancy b
> could you please give us a link to the relevant branch? Josh sends so
> many git-URLs around, it's a bit hard to keep track :)
>
Browse here:
http://gnuradio.org/cgit/jblum.git/tree/gr-blocks?h=gr_blocks
http://gnuradio.org/cgit/jblum.git/tree/gr-filter?h=gr_blocks
-Josh
__
On 12/20/2011 04:39 AM, osama mohamed wrote:
>
> hi all,
>
> Q1:can any one tell me the common mistakes that lead to the underrun problem
> occurrence while transmission
>
http://files.ettus.com/uhd_docs/manual/html/general.html#overflow-underflow-notes
> Q2:also what are the recommended
On 12/23/2011 04:44 AM, John L DuBois wrote:
> Just curious: what is the meaning of the different colors of the
> parameter entry blocks in the various grc modules ??
>
Each color is a data type. You can mouse over a particular parameter
box. A tool top window pops up to describe the parameter
On 12/30/2011 12:16 PM, Andrew Davis wrote:
> Very true, all of it, GNUradio is quite the hodgepodge of different APIs,
> Languages, and Ideas.
> And that's not always a bad thing, it can allow great flexibility, but
> sadly it is currently doing the opposite. With required versions of SWIG,
> Py
> The move to Python 3.0 is going to be significant, and we probably
> don't want to support both.
>
FWIW, you can write code for python 3.0 new standards that work on 2.6
and 2.7 (not 2.5). That is, 2.6 and 2.7, for the most part have a
superset of the language.
The issues I mostly ran into wer
On 12/30/2011 03:12 PM, LRK wrote:
> On Fri, Dec 30, 2011 at 12:41:48PM -0800, Josh Blum wrote:
>>
>> And please, tell us the errors you get on FreeBSD. They may be simple or
>> easily fixable. Let us know!
>
>
> I am rebuilding today on my FreeBSD 8.2 machine
On 12/12/2011 06:56 PM, Paul Miller wrote:
> On Mon, Dec 12, 2011 at 05:19:13PM -0800, Josh Blum wrote:
>> Its weird that feval works ok, I tried for a bit, but I couldnt figure
>> out what was different about my blocks. This will take more effort to
>> figure out if tha
On 12/30/2011 05:20 PM, LRK wrote:
> On Fri, Dec 30, 2011 at 12:41:48PM -0800, Josh Blum wrote:
>>
>> And please, tell us the errors you get on FreeBSD. They may be simple or
>> easily fixable. Let us know!
>
>
> This is where the UHD build stops. I have not ru
On 12/31/2011 11:28 PM, dave k wrote:
> usrp b100
> Ubuntu 10.04.3 LTS
> tried gnuradio install via script
>
> $ uhd_find_devices
> linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.000-6795022
>
> No UHD Devices Found
>
Does "sudo uhd_find_devices" discover a device? If so, might be
On 01/01/2012 06:16 AM, osama mohamed wrote:
>
> hi all ,
>
> i am trying to run the tx_waveforms.cpp example but i have the following
> problem:
>
> The signal SIGINT is never received and so the signal handler
> "signal_int_handler" is never called and the "stop_signal_called" flag
> rema
On 01/05/2012 07:52 AM, LRK wrote:
>
> The current GnuRadio now builds under FreeBSD using my script. Volk
> is disabled in my script because it did not build and I have not looked
> into that.
>
What was the error and what is the git hash of your build?
I had a build error with the cpu typ
> Best I can make out the cmake stuff, if it doesn't find libusb-1.0 it
> does not build. Never looks for any libusb libraries in /usr/lib/ or
> /usr/local/lib.
>
Since there is no pc file, you have to manually point cmake to the
libusb1.0 install. You might try this (I assume thats the correct
On 01/06/2012 06:27 AM, LRK wrote:
> On Thu, Jan 05, 2012 at 03:18:02PM -0800, Josh Blum wrote:
>>
>>> Best I can make out the cmake stuff, if it doesn't find libusb-1.0 it
>>> does not build. Never looks for any libusb libraries in /usr/lib/ or
>>> /
Ok, all of gnuradio from the current master builds on freebsd 8.2 with
all dependencies installed from pkg_add. Now here are the little snags
(mostly relating to the graphical appliances in gnuradio)
1) qtgui tweaks
http://gnuradio.org/cgit/jblum.git/commit/?h=freebsd_tweaks&id=ca3868256079060993e
On 01/08/2012 11:29 AM, Andrew Davis wrote:
> Also I'm trying to make UHD install with ports, this will be useful to
> projects that use USRP hardware without GNUradio and the GNUradio port can
> pull this in as a dependency so it can be made with it, but I cant find
> where the tarballs are at,
On 01/08/2012 10:39 AM, Volker Schroer wrote:
> Hi !
>
> I'm using gentoo linux with multilib support and did a fresh git clone
> from the repository.
>
> running ./bootstrap results in
>
>
>
> configure.ac:39: installing `./install-sh'
> configure.ac:39: installing `./missing'
> gnuradio-co
On 01/11/2012 06:55 AM, LRK wrote:
>
> I do not find anything in the README about qt4 or qwt but they seem
> to be required for gr-qtgui.
>
> I used portinstall to install py27-qt4 and several hours and 57 packages
> later, cmake could find qt4.
>
> Then I installed py27-pyqwt and it als
On 01/11/2012 01:39 PM, Ed Criscuolo wrote:
> Tom,
>
> I was just trying to install the GnuRadio 3.5.1 release tarball, and I
> found two problems:
>
> 1. The tarball does not appear to contain the CMakeLists.txt file.
>This forces the use of the autotools instead of cmake.
>
I dont think
On 01/11/2012 03:56 PM, Armando Rocha wrote:
> Dear all
>
> I am using USRP1 with two basic RX daughter boards and two input signals
> (one at each Basic RX) with the same frequency.
>
> The two 10. 7 MHz signals cartesian components:
> - (I1, Q1) from one channel of the 1st Basic RX card
> - (
On 01/12/2012 03:54 AM, smith mark wrote:
> Hi,
>
> 1) I got my USRP 1 and RFX900 and 1800 daughterboards. The LED on the
> USRP flashes when its powered on. I wanted to test the USRP but when I
> ran the follwowing command
>
>>> ./usrp_probe or sudo ./usrp_probe
>
> I got the following error
On 01/12/2012 10:53 AM, Ed Criscuolo wrote:
> On 1/11/12 4:59 PM, Josh Blum wrote:
>> I dont think this is a tarball of the source tree. Rather, its a tarball
>> produced by autotools with only files listed by makefile.ams or
>> generated in autotools.
>
> But what
>
> However, since I imagine there are plenty of people who don't really
> want to go through the additional step of dealing with git (if they're
> used to building from tarballs), I believe cmake has the ability to
> create them using the make package_source command, but I admit I've
> never tr
On 01/12/2012 08:50 PM, Joshua Stahl wrote:
> Hello,
> I have created a block in c++ which needs to retune after a certain number
> of samples have passed through. To accomplish this I am passing a
> uhd_usrp_sink block to my block from python and then I am attempting to
> retune after a certain
On 01/13/2012 08:11 AM, André Selva wrote:
> Hi!
>
> I've been working on the development of a Digital TV transmitter on GNU
> Radio.
> The problem is that the information flow is bufferized before "entering"
> the blocks, but the information i need to process is too large to be
> bufferized.
>
On 01/13/2012 11:01 AM, Marcus D. Leech wrote:
> Observe the following directory listing:
>
> [mleech@localhost ~]$ ls -l /usr/local/lib/libgnuradio-core*
> lrwxrwxrwx 1 root root 34 2012-01-13 13:56
> /usr/local/lib/libgnuradio-core-3.5.2git.so.0 ->
> libgnuradio-core-3.5.2git.so.0.0.0
> l
On 01/13/2012 11:34 AM, Marcus D. Leech wrote:
> On 13/01/12 02:21 PM, Josh Blum wrote:
>>
>> On 01/13/2012 11:01 AM, Marcus D. Leech wrote:
>>
>>> Observe the following directory listing:
>>>
>>> [mleech@localhost ~]$ ls -l /usr/local/lib/libg
> To reduce the computation load of the processor, I tried two methods:
> 1) modify the gr.quadrature_demod_cf block, replace some multiplication
> operations with volk-based operations (gr.multiply and gr.multiply_const
> modules in gr_blocks);
I like it. Make sure to contribute patches like tha
On 01/13/2012 11:59 AM, Scott Johnston wrote:
> Hi Josh,
>
> I am attempting to do what you described below, but I am seeing two
> problems. First, I see a power difference of about 30 dB going from one
> channel to two. Second, when I tune the second channel 100kHz away from
> the first, the fi
On 01/16/2012 01:17 PM, mle...@ripnet.com wrote:
>
>
> On Mon, 16 Jan 2012 14:49:20 -0600, LRK wrote:
>
> UHD needs to make
> certain that the FPGA image is compatible with the parameters supplied,
> so I *think* and Josh can confirm, that it reloads the FPGA imagee very
> time, although it
On 01/17/2012 05:16 AM, Sara Akbarzadeh wrote:
> Thanks for any information provided about the following case:
>
> I would like to reconfigure the "UHD's rx/tx buffer size" from inside
> gnuradio. I couldn't find how can I have access to this parameter.
>
>
Can you be more specific. I'm not s
On 01/17/2012 07:36 AM, mle...@ripnet.com wrote:
>
>
> I've made it a habit to always be explicit about which device (or
> device class, at least) I'm going for when I use UHD tools.
>
> So, I
> *always* either specify "--args type=usrp1" or --args
> "addr=192.168.10.2" to UHD tools, so tha
> With GNU Radio, very large item sizes do not work that well since the
> inter-block buffers are shared between threads and therefore, max size
> is limited by the OS. I'm sure you know what I mean :)
>
So your machine has enough memory, but the special "shared-memory/
doubly-mapped" buffers us
On 01/16/2012 09:51 AM, ziyang wrote:
> On 01/13/2012 09:30 PM, Josh Blum wrote:
>>> To reduce the computation load of the processor, I tried two methods:
>>> 1) modify the gr.quadrature_demod_cf block, replace some multiplication
>>> operations with volk-bas
>> You can time individual work functions by adding some code before an
>> after. We have some high resolution timers in
>> gruel/include/gruel/high_res_timers.h
>>
>
> So I call the timer functions of high_res_timers.h before and after the
> operation in the work function, is that right?
>
Yes
> Spoke too soon. Worked from power down for uhd_rx_nogui.py but not for
> uhd_usrp_probe:
>
> FreeBSD 8; GNU C++ version 4.2.2 20070831 prerelease [FreeBSD]; Boost_104500;
> UH
> D_003.004.000-b071cbc
>
> -- Loading firmware image: /usr/home/gr/gr352/usrp1_fw.ihx... done
> Error: LookupError:
> I still do not understand the logic. If uhd_find_devices is there to
> find devices, it seems that it should identify any device it understands
> and tell the user it's status. Instead, if it finds a USRP1, it looks for
> the firmware and errors off if it is not found. The USRP1 may be loaded
>
On 01/23/2012 10:02 AM, Khalid Jamil wrote:
> I have eight-channel synchronized N210 system on ubuntu 11.04 with i7+8GB
> computer. I have updated system with latest versions of gnuradio and uhd
> software.
>
> My flowgraph is an eight-channel multi-usrp source connected to eight data
> file sin
On 01/24/2012 07:41 AM, Iain Young, G7III wrote:
> Hi Guys,
>
> I have a USRP1, with a two WBX boards installed. I'm trying to use the
> UHD source to get a stream from both WBX boards at the same time in
> grc.
>
> Do I need two UHD sources in my flow graph ? Or is there a way to get
> a singl
On 01/24/2012 10:42 AM, André Selva wrote:
> Hello!
>
> I'm developing a TV enconder, and I need to extract information from my
> input data, and this will be used to determine the parameters of other
> blocks on the flow graph.
> How can I change the value of a variable of the python (or grc) e
>
> I see that there are some work on the SIMD optimized math blocks in
> gr-blocks. I am wondering what kind of computer is used for your test
> regarding this SIMD optimization.
>
>
Code has been re-based and moved to this branch, BTW:
http://gnuradio.org/cgit/jblum.git/log/?h=new_blocks
T
ks guys. There was a DNS issue. -Josh
> Philip
>
>>
>> B.R.
>> Changchun (Alex) Zhang
>>
>>
>> -邮件原件-
>> 发件人: Josh Blum [mailto:j...@joshknows.com]
>> 发送时间: Friday, January 27, 2012 12:56 PM
>> 收件人: Alex
>> 抄送: discuss-gnu
> export LD_LIBRARY_PATH=/opt/local/lib:$LD_LIBRARY_PATH
>
I believe OSX uses DYLD_LIBRARY_PATH
-Josh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On 01/30/2012 09:41 AM, shantharam balasubramanian wrote:
> Hi
>
> I was trying to run the benchmark_rx and benchmark_tx programs in the
> gnuradio 3.5.0 version, in my college lab. But I saw that when I am running
> the benchmark_rx in one of the wireless nodes, it shows the 'O'.
>
> there are
>>
> Just the frequency option (-f 2440M).
>
> -Shalabh
I am suspecting a possible issue with an initialized variable. Do you
mind trying this little patch: http://www.pastebucket.com/1402
-Josh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gn
On 01/31/2012 02:48 PM, Florian Schlembach wrote:
> Ok, that definitely makes sense if there is no error correction is
> implemented.
>
> We are now trying to establish an TCP/IP connection between both USRP2s
> with the tunnel.py script.
> Unfortunately, it says "Destination Host unreachable"
> I have a necessity to integrate the qtgui window to a parent Qt
> Application.Please let me know if i use the existing function
>
If it helps, you can use gnuradio-companion to generate a pyqt
application with this qtgui sink. Use the generated python code as an
example. See the Generate Opti
On 02/03/2012 01:20 PM, Jiri Pittner wrote:
> Hi Ben,
>
> thanks for the hint - with cmake, I compiled it without any problem,
> including volk, using the boost-1.47.0 version. I do not have USRP
> at hand over the weekend, so I remain curious whether the runtime crash
> disappears, too.
>
> Ho
On 02/03/2012 01:34 PM, Jiri Pittner wrote:
>
> Hi Josh,
>
> On Fri, 3 Feb 2012, Josh Blum wrote:
>
>>
>>
>> On 02/03/2012 01:20 PM, Jiri Pittner wrote:
>>> Hi Ben,
>>>
>>> thanks for the hint - with cmake, I compiled it without any
On 02/03/2012 01:23 PM, Ebtisam Ahmed wrote:
> hi all,
>
> I have been using a usrp1 device for some time now and i have been
> recommended to upgrade to uhd drivers for better support. I want to
> ask is there much difference in using uhd driver as im very much
> familiar with previous drivers
further in time,
> until I was back to "normal". I had to regress my GIT tree back to:
>
> commit 2ed887b69a3b15840830998c4e6157176d427f60
> Author: Josh Blum
> Date: Sat Dec 31 13:06:01 2011 -0800
>
> In order to get decent performance again.
>
> I have no
On 02/04/2012 04:29 AM, You Lizhao wrote:
> I'm also interested in this problem.
>
> I have tried to setup a UHD sink and a UHD source using one USRP2 +
> XCVR2450 daughterboard like tunnel.py. The flowgraph is like this: (1) Tx
> Path: self.connect(self.txpath, self.sink); (2) Rx Path:
> self.c
On 02/06/2012 06:13 PM, George Nychis wrote:
> I am trying to read incoming RX timestamps from the UHD sample stream. I'd
> like to calculate the approximate time a preamble is received in the OFDM
> code.
>
> The issue is that, despite getting incoming frames and preambles, I do not
> seem to
On 02/07/2012 06:51 AM, Zhonghua wrote:
> Hi every one,
>
> I am trying to control the open and close state of the flow graph which
> implements transmission and receiving tasks. I would not like to use
> start() and stop() pair to do that because the construction time is too
> long. What I expe
On 02/13/2012 08:21 AM, rmsrms1987 wrote:
>
> Hello Everyone,
>
> I am a relatively new user to the USRP2 and currently would like to make
> some changes to how an external PPS signal is deciphered. As of now, I
> believe that once the first rising edge of a PPS signal is detected, the
> USRP
If this helps, you can precisely time transmit packets using stream
tags. If you know the time when a transmit occurs, you can intelligently
mute your receiver. See notes in uhd_usrp_sink.h
Also, it has just occurred to me that my stream selector block does not
forward stream tags. - Mental note t
> You would have:
>
> for(size_t i = 1; i < input_items.size(); i++)
> volk_32fc_x2_multiply_32fc(is_unaligned(), out, out,
> (gr_complex*)input_items[i], noi);
>
> You halve the amount of code in gnuradio blocks which to my opinion
> makes it much more maintainable.
>
Here is a possible sol
On 02/15/2012 04:22 PM, Jason Bonior wrote:
> I am trying to create a block using gr.gr_sync_block which will select
> a value from an input vector, pass that value to output, and discard
> the rest of the vector:
>
> !/usr/bin/env python
>
> from gnuradio import gr
> import numpy
>
> class ve
On 02/16/2012 08:39 AM, Martin Braun wrote:
> Hi (most likely Josh),
>
> I was wondering if it's a big deal to give gnuradio-companion a switch
> to just compile a .grc file without firing up the GUI.
>
> Specifically, I was hoping to have unit tests for GRC files, so I wanted
> to automaticall
> Also, you never want to work on the smallest amount of memory possible.
> This is covered in my discussion on my blog. Making arbitrarily small calls
> to work functions causes much more overhead than just running the unaligned
> version of a Volk call. I found this out pretty quickly when I sta
On 02/16/2012 11:24 AM, Tom Rondeau wrote:
> On Thu, Feb 16, 2012 at 2:08 PM, Josh Blum wrote:
>
>>
>>> Also, you never want to work on the smallest amount of memory possible.
>>> This is covered in my discussion on my blog. Making arbitrarily small
>> cal
On 02/16/2012 11:32 AM, Josh Blum wrote:
>
>
> On 02/16/2012 11:24 AM, Tom Rondeau wrote:
>> On Thu, Feb 16, 2012 at 2:08 PM, Josh Blum wrote:
>>
>>>
>>>> Also, you never want to work on the smallest amount of memory possible.
>>>&g
On 02/16/2012 01:30 PM, Douglas Geiger wrote:
> On Thu, Feb 16, 2012 at 2:08 PM, Josh Blum wrote:
>>
>> Perhaps this is because you have a processor that doesn't penalize you
>> for unaligned loads/stores.
>>
>> -Josh
>
> Which suggests this
On 02/16/2012 02:10 PM, Nowlan, Sean wrote:
> Actually, what's the difference between "-march=armv7-a -mtune=cortex-a8" and
> "-mcpu=cortex-a8"?
I think the second is a deprecated way to say the first.
-Josh
>
> -Original Message-
> From: discuss-gnuradio-bounces+sean.nowlan=gtri.gat
>
> and thought usrp->get_mboard_sensor is the function that I need. But I don't
> know how to use this function in GNURadio. It seems that the code is written
> in C++. So can I use it directly in GNURadio?
>
>
All the functions are brought into python via swig, so:
http://gnuradio.org/cgit/
-- From:
> discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org]
> On Behalf Of Josh Blum Sent: Friday, February 17, 2012 12:55 PM To:
> discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] How to get
> time f
Hello list,
A bunch of great work has been merged into the master. For those
following the work on the master branch, and not a release, you will
need to update your firmware and FPGA images:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Binary-downloads
http://files.ettus.com/uhd_release
On 02/16/2012 01:27 PM, Achilleas Anastasopoulos wrote:
> I also noticed the following in the cmake ../
>
> -- Found SWIG: /usr/bin/swig (found version "2.0.4")
> -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES)
> -- Found PythonInterp: /usr/bin/python2.7
>
>
> what is the significanc
On 02/18/2012 04:25 PM, Achilleas Anastasopoulos wrote:
> I installed swig 1.3.40 and i have the same problem!
>
> is there any other way i can check if the required PyhtonLibs
> are indeed available in my system?
> The fact that gnuradio trunk builds without a problem makes me g
On 02/19/2012 03:02 AM, Wu Ting wrote:
> Hi all,
>
>
>
> I have two questions for using GPSDO. First, I'm now using
> usrp_source.get_time_now().get_frac_secs() to get a time value like this:
>
> 0.53928493
>
> My question is how accurate is this value. I don't know much about
On 02/19/2012 10:41 AM, Achilleas Anastasopoulos wrote:
> Josh,
>
> Unfortunately the patch did not solve the problem...
>
> Achilleas
Can you post the full output when you configure, starting w/ an empty
build directory. I guess with that patch applied too
This is the output on my PC: http:/
On 02/20/2012 12:39 AM, Martin Braun wrote:
> On Sun, Feb 19, 2012 at 04:07:37PM -0500, A. Maitland Bottoms wrote:
>>> 724a3ff8798d
>> ...
>>> It also has a workaround for a bug
>>> (http://gnuradio.org/redmine/issues/485) in GRC. Probably should have
>>> been two commits.
>>
>> The horrible, ugl
>
> How to solve this issue?
>
Build with cmake instead :-)
http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork
-josh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On 02/21/2012 03:30 PM, Marcus D. Leech wrote:
> On 02/21/2012 06:18 PM, Iain Young, G7III wrote:
>>
>> They was within the same GRC File, although not linked (IE separate
>> RX and TX chains)
>>
> Yup, the precipitating characteristic appears to be that both TX and RX
> facilities are in use on
> The problem I am having right now is that the timing information is not
> matching up to the signal I am inputting to the PPS port. I started off
> with inputting a signal that has an IPP of 1ms, but each PPS Trigger output
> incremented in values of 5ms. I made additional changes to the input
On 02/26/2012 08:27 PM, Ahmad Zaki Yaacob wrote:
> Hi,
>
> I'm running on Debian 5.0 Lenny. My device is USRP2. I have installed UHD
> 003.003.001. Boost 10400. GNU C++ version 4.6.2. I'm having problem to get
> uhd_find_devices working.
>
> The error message is
> UHD Error:
> Cannot open UDP t
On 02/27/2012 05:30 PM, George Nychis wrote:
> It's be good if you can chime in here, Josh :)
>
> It seems like this is something that should be fixed about tunnel.py in
> future GNU Radio releases for use with UHD.
>
Like removing it altogether :-)
> That is clearly documented as control of
On 02/27/2012 08:48 PM, Jon Phil wrote:
> Is there a way so that one can pass the output of a custom gnuradio block as
> parameter to another block?
>
>
Take a look at the function probe block in gnuradio companion (and using
it with the probe signal block).
Periodically probe a function and
On 03/01/2012 09:23 AM, Rafael Diniz wrote:
> Hi there people,
> I'm helping some friends here at work, they are doing an experiment with
> the N210 and grabbing the data as 16bit complex samples.
> The maximum symbol rate they are achieving is 25MS/s.
> Is this correct? At 33.3 and 50 the uhd_ff
>
> Does the packet encoder needs to continuously have samples at its input to
> generate a packet? Or can we send information to the packet encoder at very
> low rate, and the packet encoder will just generate one packet and sleep
> again until the next information comes in?
>
>
If you have
> cmake --DREDHAT --DLIB_SUFFIX=64 ..
>
> Still installs in lib instead of lib64.
>
I think its the double dashes. Try -DLIB_SUFFIX=64
-josh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gn
On 03/05/2012 01:13 AM, Jiao Xianjun wrote:
> I can run uhd_usrp_probe --args="addr=192.168.10.2" to get correct output
> now, but still get "No UHD Devices Found" error...
> linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.004.000-307-gb61f4ad6
>
What about uhd_find_devices --args="addr=192
On 03/04/2012 11:48 AM, John Coppens wrote:
> On Sun, 04 Mar 2012 09:20:07 -0800
> Josh Blum wrote:
>
>>> Still installs in lib instead of lib64.
>>>
>>
>> I think its the double dashes. Try -DLIB_SUFFIX=64
>
> Yes! Thanks... But why the doubl
On 03/05/2012 08:10 AM, labarowski wrote:
>
> I'm using an Ettus N210. I have a simple block diagram in GRC with a cosine
> signal source feeding a throttle feeding the usrp sink. All share the
- dont use a throttle, the usrp sink *is* back-pressuring the stream
- use this new signal source on
1 - 100 of 2074 matches
Mail list logo
