[Discuss-gnuradio] Error Is OpenBTS going to support USRP2?
muhammadjunaid@ubuntu:~/OpenBts/openbts-uhd/public-trunk/apps$ ./OpenBTS OpenBTS, Copyright 2008-2010 Free Software Foundation, Inc. Release 2.6PUBLIC built Apr 19 2012 "OpenBTS" is a trademark of Kestrel Signal Processing, Inc., regsitered with the US Patent and Trademark Office. Contributors: Kestrel Signal Processing, Inc.: David Burgess, Harvind Samra, Raffi Sevlian, Roshan Baliga GNU Radio: Johnathan Corgan Others: Anne Kwong, Jacob Appelbaum, Joshua Lackey, Alon Levy Alexander Chemeris, Alberto Escudero-Pascual Incorporated GPL libraries and components: libosip2, liportp2, readline This program comes with ABSOLUTELY NO WARRANTY. This is free software; you are welcome to redistribute it under the terms of AGPLv3. Please see the COPYING file in the source code for information about the AGPLv3 license and recommended procedures for compliance with the Affero requirements of that license. Use of this software may be subject to other legal restrictions, including patent licsensing and radio spectrum licensing. All users of this software are expected to comply with applicable regulations and laws. Starting the system... 1339182654.2386 ALARM 3074128576 OpenBTS.cpp:517:main: OpenBTS starting, ver 2.6PUBLIC build date Jun 6 2012 linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.000-1156d9b 1339182654.2560 FORCE 3052370400 Logger.cpp:196:gLogInit: Setting initial global logging level to NOTICE 1339182655.3935 ALARM 3052370400 UHDDevice.cpp:335:set_rates: Cannot set clock rate on this device 1339182655.3936 ALARM 3052370400 UHDDevice.cpp:336:set_rates: Please compile with host resampling support 1339182662.2433 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339182665.2448 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339182668.2481 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339182671.2508 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339182674.2541 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339182677.2574 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339182680.2589 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339182683.2622 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339182686.2628 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339182689.2631 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339182689.2726 ALARM 3074128576 TRXManager.cpp:273:sendCommandPacket: lost control link to transceiver 1339182689.2728 ALARM 3074128576 OpenBTS.cpp:672:main: Uncaught exception. Shutting down. exiting... -- View this message in context: http://old.nabble.com/Is-OpenBTS-going-to-support-USRP2--tp22425805p33985231.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] full form of GNU
hi all, can anybody please tell me the full form of GNU. please excuse me if it is a basic question but i couldn't find answer in net ..thats why m posting here. thanks, sravya. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] full form of GNU
I guess this signal processing package i.e. gnuradio is distributed under the terms of the GNU General Public License hence its called gnuradio. sravya reddy wrote: > > hi all, > > can anybody please tell me the full form of GNU. please excuse me if it is > a basic question but i couldn't find answer in net ..thats why m posting > here. > > thanks, > sravya. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > - Sumit Kr. Research Assistant Communication Research center IIIT Hyderabad India -- View this message in context: http://old.nabble.com/full-form-of-GNU-tp33985988p33986143.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
Re: [Discuss-gnuradio] Simple FM receiver - one last question
gr_freq_xlating_fir_filter_xxx_0 is not connected, connect it to something. On Sat, Jun 9, 2012 at 1:35 AM, Phil wrote: > Thank you for reading this. > > I have one last error to overcome: > > Error 0: > Block - gr_freq_xlating_fir_filter_xxx_0 - Frequency Xlating FIR > Filter(gr_freq_xlating_fir_filter_xxx): > Sink - in(0): > Port is not connected. > > Can anyone offer a suggestion that will sort this out? > > -- > Regards, > Phil > > ___ > 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] Simple FM receiver - one last question
gr_freq_xlating_fir_filter_xxx_0 is not connected, connect it to something. It's not connected probably because his gr-osmosdr stuff isn't installed, and that filter is connected to the gr-osmosdr source in that flow-graph. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble with gnuradio and AMD32
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
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
>> 29namespace 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-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> I guess I haven't really checked on things here for a while. I compiled
> 3.5.3.2 (3.6.0 is having issues building, not sure why yet but I don't
> have time right now to dig any deeper.) and gqrx and get the same sort
> of error as Igor with gnuradio_companion and gqrx. Gqrx and grc run
> fine on my intel atom 32 bit system. On any of my AMD32 machines, I get
> this error.
>
> Below is the output of grc:
>
> Using Volk machine: generic
> Traceback (most recent call last):
> File "/home/fred/gnuradio/top_block.py", line 154, in
> tb = top_block()
> File "/home/fred/gnuradio/top_block.py", line 9
Re: [Discuss-gnuradio] Tunning USRP From Seperate C++ Block?
Sorry for the time between replies. I've been taking exams and packing up. Timing the frequency changes is not terribly critical, as long as they stay in rough order with the incoming samples. Our current way involves a separate script which generates RPC packets for the XML-RPC server to change a variable for the frequency. This has actually worked ok in testing but I'm concerned that the timing between GNURadio and the separate python script could drift during extended tests, causing the incoming samples to be correlated with the wrong frequencies. Doing everything in C++ would still not give a true time base, but at least if I called the frequency changes from the work function it would correlate directly to the samples. Will take note of the set_command_time function as it could definitely prove useful for this project. Great job on the Gr-extras Josh! The PMT passing definitely seems much more straightforward than feval. Even still, I'm leaning a bit towards C++ for this project. That should allow me to simply pass a pointer of the UHD Sink block to the block which is going to change it's frequency. This same method would probably prove useful for other aspects of this project as well. It would make it really easy to pass data between blocks. I also have a lot more experience with C++ than I do with Python. Problem is, I can't seem to find any documentation or examples on constructing a flowgraph in C++. I'm not even sure which libraries would need to be included. Is there somewhere that I can look for C++ examples/tutorials? Thanks! On 6/6/2012 2:10 PM, Josh Blum wrote: So, no matter how you solve this, there different timebase thing is an issue. On the N210/N200, there is a set_command_time. You will want to use this to coordinate when tunes occur in relation to the samples. http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#a191b78b00d051d3d51c2f719361c1fb5 1) Now, something that I would like to do is create a message sink block that turns an arbitrary PMT message into a function name + args and calls this function in python on a block's methods; obviously this is all from the context of a python flow graph. On your end, in c++ you would add a message port to your block that posts these control message to its message source output. So thats possible given the project here (see message section): https://github.com/guruofquality/grextras/wiki You should be able to implement something on the c++ and python end with the messages. But, I hope to make something like this more strait-forward with the arbitration block described above. 2) If thats not feasible, there are these gr_msg_queue objects (unrelated to the link above) that let you pass binary blobs around. You can push into the queue in c++, and pop the message in a python thread, call the setting... I'd say either option is easier than implementing a wrapper of some sort or using feval. Bringing it into c++ may not be too bad though... -josh ___ 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?
On 06/09/2012 04:58 PM, Daniel Labarowski wrote: > Sorry for the time between replies. I've been taking exams and packing > up. Timing the frequency changes is not terribly critical, as long as > they stay in rough order with the incoming samples. Our current way > involves a separate script which generates RPC packets for the XML-RPC > server to change a variable for the frequency. This has actually worked > ok in testing but I'm concerned that the timing between GNURadio and the > separate python script could drift during extended tests, causing the > incoming samples to be correlated with the wrong frequencies. Doing > everything in C++ would still not give a true time base, but at least if > I called the frequency changes from the work function it would correlate > directly to the samples. Will take note of the set_command_time function > as it could definitely prove useful for this project. > 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. > Great job on the Gr-extras Josh! The PMT passing definitely seems much > more straightforward than feval. Even still, I'm leaning a bit towards > C++ for this project. That should allow me to simply pass a pointer of > the UHD Sink block to the block which is going to change it's frequency. > This same method would probably prove useful for other aspects of this > project as well. It would make it really easy to pass data between > blocks. I also have a lot more experience with C++ than I do with 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 :-) > Python. Problem is, I can't seem to find any documentation or examples > on constructing a flowgraph in C++. I'm not even sure which libraries > would need to be included. Is there somewhere that I can look for C++ > examples/tutorials? > 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
Re: [Discuss-gnuradio] full form of GNU
If you are asking for the definition of the acronym "GNU" GNU's not Unix.: https://en.wikipedia.org/wiki/GNU On Jun 9, 2012, at 6:01 AM, Sravya Reddy wrote: > hi all, > > can anybody please tell me the full form of GNU. please excuse me if it is a > basic question but i couldn't find answer in net ..thats why m posting here. > > thanks, > sravya. > ___ > 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
