Re: [Discuss-gnuradio] question about print out of overrun and under run indication
On Fri, Jun 8, 2012 at 11:27 PM, Stephen wrote:
>
> Hi,
>
> I have a couple of questions about the print out of the overrun and
> underun indications.
>
> Is it possible to turn off the output of those indications?
Not yet. I'm actually working on something that should help us control
this information better. I can't guarantee a time on its availability,
though.
> And second is gnuradio doing anything with stdout that would affect
> redirecting stdout?
>
> This is the text output I normally see in a shell window.
> (I don't see the - lines that just to separate the text)
>
> ---
>
> -- USRP-B100 clock control: 10
> -- r_counter: 2
> -- a_counter: 0
> -- b_counter: 20
> -- prescaler: 8
> -- vco_divider: 5
> -- chan_divider: 5
> -- vco_rate: 1600.00MHz
> -- chan_rate: 320.00MHz
> -- out_rate: 64.00MHz
> --
>
> UHD Warning:
> Unable to set the thread priority. Performance may be negatively
> affected.
> Please see the general application notes in the manual for instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
>
> UHD Warning:
> The hardware does not support the requested RX sample rate:
> Target sample rate: 2.50 MSps
> Actual sample rate: 2.461538 MSps
gr_fir_ccc: using SSE
gr_fir_fff: using SSE
> Using Volk machine: sse4_1_64_orc
>
>
>
> In my application I redirect stdout to a different buffer. Which works
> at first. I get the following redirected to my buffer
>
>
>
> -- USRP-B100 clock control: 10
> -- r_counter: 2
> -- a_counter: 0
> -- b_counter: 20
> -- prescaler: 8
> -- vco_divider: 5
> -- chan_divider: 5
> -- vco_rate: 1600.00MHz
> -- chan_rate: 320.00MHz
> -- out_rate: 64.00MHz
> --
>
>
>
> after that nothing is redirected and everything goes back to being
> output in the shell window. I'm not an expert on redirecting stdout but
> is there anything in gnuradio that would make that stop working?
>
> stephen
There is also stderr, where a lot of this information is printed, too.
You'll want to redirect both stdout and stderr together to suppress
everything ("program &> /dev/null" will do it or "program > /dev/null
2>&1").
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Shared Sources
Tom Rondeau wrote on 2012-06-05 02:47: > On Mon, Jun 4, 2012 at 3:08 PM, Martin Braun wrote: >> On Mon, Jun 04, 2012 at 12:37:31PM -0400, Andrew Davis wrote: >>> I would recommend file sources, you can filter, graph and demod them >>> w/o hardware. >> >> Check out http://gnuradio.org/redmine/projects/gnuradio/wiki/SampleData >> for prerecorded stuff. It's not much, though. >> >> MB > > There are also some files here: > http://gnuradio.org/data/ > > I think we should start a real collection of some useful data files > for different projects. We can't go crazy with this, but there's > plenty of space on our web server for a good collection. I think it would be helpfull to have good metadata with the recordings, maybe some naming scheme, which gives consistant information about the recording, allong with some info text, that describes the setting of the recording and the identified signals. Moreover I think there should be bigger and smaller files. Not everyone needs 8MHz recordings which yield gigibytes of data within seconds, not everyone has the space and connection bandwidth to store them or the computing power to process them. Small is beautiful, narrow band and short recordings can fulfill most demands. Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematics, Graz Univ. of Technology, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble with gnuradio and AMD32
On Sat, Jun 9, 2012 at 7:40 PM, Josh Blum wrote:
> FYI, in case you want to test this fix. But I think its pretty strait
> forward:
>
> http://gnuradio.org/cgit/jblum.git/commit/?h=fix_alignment_issue
>
> -Josh
Josh,
I decided to go with your original recommendation of using std::max(1,
alignment) for each block calling set_alignment. It's not really the
set_alignment functions job to make a decision on what the caller
meant when they passed in a number; it just protects against incorrect
values. The guy that calls the set_alignment function should make sure
it's passing the right value.
It's a bit more work this way (although mostly I expect people to
copy-and-paste), but this makes more sense.
Thanks,
Tom
> On 06/05/2012 07:18 AM, Frederick Stevens wrote:
>> On 06/01/2012 02:12 PM, Igor Volodin wrote:
>>> Hello, all
>>>
>>> My configuration:
>>> Linux Xubuntu 12.04
>>> AMD Athlon XP 2400
>>> Linux ghost32 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:51:22 UTC
>>> 2012 i686 athlon i386 GNU/Linux
>>>
>>>
>>>
>>> I am compiled latest version of gnuradio, and tried to run simple grc
>>> file: http://superkuh.com/simplest.grc , and got following error:
>>>
>>>
>>> (python:3350): GLib-GObject-CRITICAL **: g_param_spec_double:
>>> assertion `default_value >= minimum && default_value <= maximum' failed
>>>
>>> (python:3350): GLib-GObject-CRITICAL **:
>>> g_object_class_install_property: assertion `G_IS_PARAM_SPEC (pspec)'
>>> failed
>>>
>>> (python:3350): GLib-GObject-WARNING **: g_object_notify: object class
>>> `GdkScreenX11' has no property named `resolution'
>>> Using Volk machine: generic
>>> Traceback (most recent call last):
>>> File "./top_block.py", line 131, in
>>> tb = top_block()
>>> File "./top_block.py", line 79, in __init__
>>> peak_hold=False,
>>> File
>>> "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/fftsink_gl.py",
>>> line 89, in __init__
>>> win=win,
>>> File
>>> "/usr/local/lib/python2.7/dist-packages/gnuradio/blks2impl/logpwrfft.py",
>>> line 57, in __init__
>>> c2magsq = gr.complex_to_mag_squared(fft_size)
>>> File
>>> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core_general.py",
>>> line 3838, in complex_to_mag_squared
>>> return _gnuradio_core_general.complex_to_mag_squared(vlen)
>>> RuntimeError: gr_block::set_alignment_multiple
>>> [Inferior 1 (process 3350) exited with code 01]
>>>
>>> Then I compiled the program with debugging symbols, and started in the
>>> debugger:
>>>
>>> (gdb) s
>>> Single stepping until exit from function Py_Main,
>>> which has no line number information.
>>> 0x0805e78b in main ()
>>> (gdb) bt
>>> #0 0x0805e78b in main ()
>>> (gdb) l
>>> 11 // detail/sp_counted_base_gcc_x86.hpp - g++ on 486+ or AMD64
>>> 12 //
>>> 13 // Copyright (c) 2001, 2002, 2003 Peter Dimov and Multi Media Ltd.
>>> 14 // Copyright 2004-2005 Peter Dimov
>>> 15 //
>>> 16 // Distributed under the Boost Software License, Version 1.0. (See
>>> 17 // accompanying file LICENSE_1_0.txt or copy at
>>> 18 // http://www.boost.org/LICENSE_1_0.txt)
>>> 19 //
>>> 20 //
>>> (gdb) n
>>> Single stepping until exit from function main,
>>> which has no line number information.
>>> 0x006b94d3 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
>>> (gdb) l
>>> 21 // Lock-free algorithm by Alexander Terekhov
>>> 22 //
>>> 23 // Thanks to Ben Hitchings for the #weak + (#shared != 0)
>>> 24 // formulation
>>> 25 //
>>> 26
>>> 27 #include
>>> 28
>>> 29 namespace boost
>>> 30 {
>>> (gdb) n
>>> Single stepping until exit from function __libc_start_main,
>>> which has no line number information.
>>> [Inferior 1 (process 3367) exited with code 01]
>>>
>>> My problem is like this:
>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2012-03/msg00294.html
>>> Then i run volk_profile, and got this errors:
>>>
>>> Using Volk machine: generic
>>> RUN_VOLK_TESTS: volk_32fc_s32fc_rotatorpuppet_32fc_a
>>> no architectures to test
>>> RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
>>> no architectures to test
>>> RUN_VOLK_TESTS: volk_16ic_deinterleave_real_8i_a
>>> no architectures to test
>>> RUN_VOLK_TESTS: volk_16ic_deinterleave_16i_x2_a
>>> no architectures to test
>>> RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_32f_x2_a
>>> no architectures to test
>>> RUN_VOLK_TESTS: volk_16ic_deinterleave_real_16i_a
>>> no architectures to test
>>> RUN_VOLK_TESTS: volk_16ic_magnitude_16i_a
>>> no architectures to test
>>> RUN_VOLK_TESTS: volk_16ic_s32f_magnitude_32f_a
>>> no architectures to test
>>> RUN_VOLK_TESTS: volk_16i_s32f_convert_32f_a
>>> no architectures to test
>>> RUN_VOLK_TESTS: volk_16i_s32f_convert_32f_u
>>> no architectures to test
>>> RUN_VOLK_TESTS: volk_16i_convert_8i_a
>>> no architectures to test
>>> RUN_VOLK_TESTS: volk_16i_convert_8i_u
>>>
>>>
>>> Best regards, Igor
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnur
Re: [Discuss-gnuradio] question about print out of overrun and under run indication
On 06/10/2012 08:32 AM, Tom Rondeau wrote: > On Fri, Jun 8, 2012 at 11:27 PM, Stephen wrote: >> >> Hi, >> >> I have a couple of questions about the print out of the overrun and >> underun indications. >> >> Is it possible to turn off the output of those indications? > You can shut if off with a simple library call, but there is no hook for it from python. http://files.ettus.com/uhd_docs/manual/html/general.html#disabling-or-redirecting-prints-to-stdout > Not yet. I'm actually working on something that should help us control > this information better. I can't guarantee a time on its availability, > though. > Being able to forward IO into a gnuradio controlled printf'sh system would be quite awesome. Then we can simply use standard gnuradio hooks to control the IO. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Magnitude == RSSI?
I've noticed that some dboards have RSSI sensors while others don't. Since I'm using a SBX (rev 3) which doesn't seem to have such a sensor, I'm wondering if it's also correct to use the magnitude of the samples as an indicator for the RSS or is this value somehow "distorted"? Cheers, Matthias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] question about print out of overrun and under run indication
On 6/10/2012 2:37 PM, Josh Blum wrote: > > > You can shut if off with a simple library call, but there is no hook for > it from python. > > http://files.ettus.com/uhd_docs/manual/html/general.html#disabling-or-redirecting-prints-to-stdout > cool thanks. I'm doing everything in c++ so thats not a problem. stephen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] question about print out of overrun and under run indication
On 6/10/2012 10:32 AM, Tom Rondeau wrote:
>
> There is also stderr, where a lot of this information is printed, too.
> You'll want to redirect both stdout and stderr together to suppress
> everything ("program &> /dev/null" will do it or "program > /dev/null
> 2>&1").
>
> Tom
>
I'm redirecting it so I can put the output into a log window of a gui.
There is something related to the setup of the flow graph that is
causing the issue. If I redirect stdout I see everything sent to stdout
get redirected. Until somewhere in the process of making a top block and
a usrp source block and connecting the flow graph together. Doing that
causes my redirection to stop working. If I create the blocks and
connect them together first and then redirect stdout it stays redirected.
stephen
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tunning USRP From Seperate C++ Block?
Josh, The RPC-PMT block is definitely a great idea. Whether I go the python route or not, I will keep that tool in my back pocket. IMO, this solves the problem in a much more accessible manner than feval. Still, C++ may be better suited for this project. I'm going to be out of town so I'll have some time to read over the resources that you've sent me and decide which is the best. You guys will probably here from me again when I pick this project back up in a couple weeks. Thanks again for all of the support that you provide for Gnuradio Josh, both in the form of code as well as answering questions on this mailing list. -Dan On 6/9/2012 10:54 PM, Josh Blum wrote: Well, whatever works is the right answer. :-) Even calling tune from the work function of your block is still going to have time ambiguity with the samples. You never know how much is buffered in the kernel or in a gr stream. I suppose an indirection of RPC would add some latency and possibly exacerbate the problem. I can't say by how much. Timed commands aside, the next safest thing you can do is shut off the streaming (start/stop methods of the source block) if you dont want any ambiguously tuned samples. BTW, I just produced a PMT RPC block, code here: https://github.com/guruofquality/grextras/blob/master/python/pmt_rpc.py You can stick this block in a python flow graph and it will parse its incoming messages and make calls on the flow graph. You can produce the messages for the RPC block in python or C++ work() function. I'm not pressuring you to use it or anything, but your inquiry did spark a neat idea :-) Here is a blocks coding guide I wrote for GNU Radio: http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide And here is the equivalent document for GrExtras: https://github.com/guruofquality/grextras/wiki/Blocks-Coding-Guide Looks like I left the top_block part of the guide as TODO, but here is a good example for that: http://gnuradio.org/cgit/gnuradio.git/tree/gr-audio/examples/c++/dial_tone.cc -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] b100 error
Yesyterday I installed gnuradio using script by Marcus. While running usrp_spectrum_sense.py it it is throwing following error UHD Error: Got a data packet with unknown SID 336593408 UHD Error: Got a data packet with unknown SID 336593408 UHD Error: Got a data packet with unknown SID 336593408 UHD Error: Got a data packet with unknown SID 336593408 UHD Error: Got a data packet with unknown SID 336593408 the SID keeps changing although .. While I saw I similar problem earlier in this thread(http://old.nabble.com/uhd-b100-problems-td33345827.html#a33345827 ) but I am afraid that the problem still persists :( my UHD version is uhd-images_003.004.001-109-g6ca39ad9 Thanks - Sumit Kr. Research Assistant Communication Research center IIIT Hyderabad India -- View this message in context: http://old.nabble.com/b100-error-tp33991288p33991288.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
