[Discuss-gnuradio] benchmark_tx.py BPSK Signal Details
Hello all, I want to know how I could possibly find out the complete details about the BPSK-Signal generated by the benchmark_tx.py GNU Radio script. Should I look at the code and at which file respectively? Thanks in advance. -Sebastian- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Duration of Calculations in Python scripts
On Thu, 23 Feb 2012 10:29:02 -0500 Tom Rondeau t...@trondeau.com wrote: On Thu, Feb 23, 2012 at 4:39 AM, Sebastian Döring sdoer...@rhrk.uni-kl.dewrote: Hello, in the context of spectrum sensing in the 2.4 GHz band using a modified version of the usrp_spectrum_sense.py script, I am having problems with high latency times. Since the time for recording samples and all the tuning stuff is supposed to be much less than what I am currently dealing with (something around 88ms between two center frequencies), I was wondering if this might be a problem of some additional calculations the python script is doing with every message I get from the c++ code. In particular these calculations contain summing up the vector I get from the queue of the source and comparing the sum to a previously calculated threshold wrapped into some if-statements Any statements highly appreciated. Thanks. -Sebastian If it's latency in the flowgraph, you can try and use the new max_noutput_items (pass this value to tb.start(N) or tb.run(N), whichever is being used). The smaller this number, the faster blocks will pass data between eachother, but also the harder your computer is going to have to work to keep up. If you think that the latency is due to Python calculations, you can think about finding a more efficient scipy implementation of the calculations. If one doesn't exist, you can write some C code and look at the f2py program that comes with Python; it's a simpler wrapper generator than SWIG that converts from FORTAN to Python, but I believe it nicely supports C functions as well. Just a couple of thoughts. Tom Thanks Tom, I have proofed your suggestions, but none of them seemed to help much. I also ran the script under cProfile to get a better timing analysis and it turns out that gr_py_msg_queue__delete_head is the real evildoer. According to cProfile it takes 94ms per call. Since cProfile produces some overhead itself, this is pretty much what fits into these almost 90ms I measured myself. Does anyone have an idea if and how this could be speeded up? Thanks -Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Duration of Calculations in Python scripts
Hello, in the context of spectrum sensing in the 2.4 GHz band using a modified version of the usrp_spectrum_sense.py script, I am having problems with high latency times. Since the time for recording samples and all the tuning stuff is supposed to be much less than what I am currently dealing with (something around 88ms between two center frequencies), I was wondering if this might be a problem of some additional calculations the python script is doing with every message I get from the c++ code. In particular these calculations contain summing up the vector I get from the queue of the source and comparing the sum to a previously calculated threshold wrapped into some if-statements Any statements highly appreciated. Thanks. -Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] fft monitoring of more than one channel
Hello list, I modified the usrp_spectrum_sense.py to work as an energy detector based on the Neyman-Pearson Theorem. So basically the algorithm is supposed to tell me if a certain part of the spectrum is occupied or not. I simply wrote the output into a text file to see I it is working at all, but right now I am trying to find a way to somehow monitor the it in a large plot, that dynamically changes with the current detection results. That means that if I am sensing the spectrum for example between 2.4 and 2.5GHz in steps of 20MHz, I want the the whole bandwidth to be graphically displayed in some kind of plot (x-Axis = frequency, y-Axis = 0/1), which is divided into parts of 20MHz. The channel states are supposed to get updated every time the channel is sensed again, just like the output is already doing. I first thought that gtgui_sink_x might be the right thing, but since I am peridically changing the frequency and the sink is designed to look at a single center frequency, I don know how to append several frequency windows to a large one. I dont know if what I am planning to do is even possible using gnu radio only. I higly appreciate any suggestions. Thanks in advance. -Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_spectrum_sense.py segmentation fault problem
On Tue, 20 Dec 2011 20:24:28 -0500 Tom Rondeau trondeau1...@gmail.com wrote: On Tue, Dec 20, 2011 at 11:02 AM, Thomas Tsou tt...@vt.edu wrote: On Tue, Dec 20, 2011 at 5:11 AM, Sebastian Döring sdoer...@rhrk.uni-kl.de wrote: -- #0 0x0013a455 in sem_post@@GLIBC_2.1 () from /lib/tls/i686/cmov/libpthread.so.0 #1 0x0810ab61 in PyThread_release_lock (lock=0x0) at ../Python/thread_pthread.h:374 #2 0x080dbad3 in PyEval_ReleaseLock () at ../Python/ceval.c:262 #3 0x00fa6073 in gr_py_feval_dd::calleval(double) () This is likely a similar issue with the Python GIL (global interpreter lock) that occurred previously on the E100. In that case the final cause was a missing ctypes library. http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-June/001479.html To find out, try this thread hack. The patch is old, so you will probably need to apply manually against the current master. diff --git a/uhd_spectrum_sense_sum.py b/uhd_spectrum_sense_sum.py index 70f530f..31bf458 100644 --- a/uhd_spectrum_sense_sum.py +++ b/uhd_spectrum_sense_sum.py @@ -32,7 +32,11 @@ import sys import math import struct import time +import threading +class ThreadClass(threading.Thread): +def run(self): +return class tune(gr.feval_dd): @@ -306,6 +310,9 @@ def main_loop(tb): if __name__ == '__main__': +t = ThreadClass() +t.start() + tb = my_top_block() try: tb.start() # start executing flow graph in another thread... Thomas Please let us know if this patch works. I think this has been an outstanding issue in GNU Radio for a while. It'd be good to get a fix for it in. Thanks, Tom Thank you guys - it worked! The line positions have a changed a bit and so I simply attached the new code (gnuradio build 20.12.2011). --- a/usrp_spectrum_sense.py 2011-12-20 12:44:55.0 +0100 +++ b/usrp_spectrum_sense.py 2011-12-21 14:26:19.252873684 +0100 @@ -28,9 +28,14 @@ import sys import math import struct +import threading sys.stderr.write(Warning: this is known to have issues on some machines+Python version combinations to seg fault due to the callback in bin_statitics. If you figure out why, we'd love to hear about it!\n) +class ThreadClass(threading.Thread): +def run(self): +return + class tune(gr.feval_dd): This class allows C++ code to callback into python. @@ -240,6 +245,9 @@ if __name__ == '__main__': +t = ThreadClass() +t.start() + tb = my_top_block() try: tb.start() Regards Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp_spectrum_sense.py segmentation fault problem
Hello list, since I got no answer to my last post, I guess what I wrote wasn´t that helpful. I apologize for whatever I did not understand, but I am not familiar with error logs in the context of the problem I have here. I would really appreciate any help with this. Once again my problem: I am getting the famous segmentation fault when trying to launch the usrp_spectrum_sense.py-script. When asked for an error log, I simply launched it in GDB and copy pasted the output plus backtrace. My OS is Ubuntu 10.04, running on a 32-bit machine. Default python version is 2.6. My hardware is the USRP N210 with XCVR2450. I tried to change my default python version (tried 2.5 and 2.7) but it did not help ( but I am also not sure if I have changed all the necessary paths correctly). Nevertheless I returned to 2.6 and have even reinstalled the GNUraduio package (using the build-script) -- nothing changed. uhd_fft.py and so on is working but I really need to get the above mentioned script running, to modify it later on. Thanks in advance for your answers. -Sebastian On Thu, 15 Dec 2011 12:40:02 +0100 Sebastian Döring sdoer...@rhrk.uni-kl.de wrote: On Wed, 14 Dec 2011 08:28:57 -0500 Marcus D. Leech mle...@ripnet.com wrote: On 14/12/11 08:05 AM, Sebastian Döring wrote: Thanks a lot. Code really looks like what I am looking for. Concerning the machine+Python version combinations that cause seg faults: Is there a known combination that works? Seems like mine doesn't. -Sebastian Could you expand on that a bit, please? Perhaps with an error log, and what you were trying to do when you got a segfault? -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org I was simply trying to test the script (usrp_spectrum_sense.py 2.4G 2.41G). I have reproduced the error using gdb and this is what I get: -- Starting program: /usr/bin/python usrp_spectrum_sense.py 2.4G 2.41G [Thread debugging using libthread_db enabled] linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.000-71810ad Warning: this is known to have issues on some machines+Python version combinations to seg fault due to the callback in bin_statitics. If you figure out why, we'd love to hear about it! -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes [New Thread 0xb6afbb70 (LWP 8791)] [New Thread 0xb62fab70 (LWP 8792)] gain = 49.5 [New Thread 0xb5a99b70 (LWP 8793)] [New Thread 0xb5298b70 (LWP 8794)] [New Thread 0xb4a56b70 (LWP 8795)] [New Thread 0xb40ffb70 (LWP 8796)] [New Thread 0xb38feb70 (LWP 8797)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb38feb70 (LWP 8797)] 0x0013a455 in sem_post@@GLIBC_2.1 () from /lib/tls/i686/cmov/libpthread.so.0 -- The backtrace says: -- #0 0x0013a455 in sem_post@@GLIBC_2.1 () from /lib/tls/i686/cmov/libpthread.so.0 #1 0x0810ab61 in PyThread_release_lock (lock=0x0) at ../Python/thread_pthread.h:374 #2 0x080dbad3 in PyEval_ReleaseLock () at ../Python/ceval.c:262 #3 0x00fa6073 in gr_py_feval_dd::calleval(double) () from /usr/local/lib/python2.6/dist-packages/gnuradio/gr/_gnuradio_core_general.so #4 0x0083a6cd in gr_bin_statistics_f::enter_tune_delay() () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #5 0x0083a788 in gr_bin_statistics_f::work(int, std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #6 0x007d70e7 in gr_sync_block::general_work(int, std::vectorint, std::allocatorint , std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #7 0x007ba475 in gr_block_executor::run_one_iteration() () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #8 0x007da549 in gr_tpb_thread_body::gr_tpb_thread_body(boost::shared_ptrgr_block) () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #9 0x007d3fcd in boost::detail::function::void_function_obj_invoker0gruel::thread_body_wrappertpb_container, void::invoke(boost::detail::function::function_buffer) () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #10 0x009515f5 in boost::detail::thread_databoost::function0void ::run() () from /usr/local/lib/libgruel-3.5.0rc0.so.0.0.0 #11 0x009db7c5 in thread_proxy () from /usr/lib/libboost_thread.so.1.40.0 #12 0x0013396e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #13 0x003f1a4e in clone () from /lib/tls/i686/cmov/libc.so.6
Re: [Discuss-gnuradio] usrp_spectrum_sense.py segmentation fault problem
On Tue, 20 Dec 2011 11:39:39 +0100 Matthias Wilhelm wilh...@informatik.uni-kl.de wrote: Hello, judging from the log, it seems that a value conversion to float is going wrong, but my (uneducated) guess the root cause is a race between threads (this script starts quite a number of threads ..?). I would try to enter larger values for the delays (tune, dwelling delay) and see whether it changes something. This should reduce the probability that two threads want to do different things at the same time. Thanks for your answer but unfortunately this did not work either. I tried it with up to almost 100 times the actual values but the result remains the same. --Matthias Am 20.12.2011 um 11:11 schrieb Sebastian Döring: Hello list, since I got no answer to my last post, I guess what I wrote wasn´t that helpful. I apologize for whatever I did not understand, but I am not familiar with error logs in the context of the problem I have here. I would really appreciate any help with this. Once again my problem: I am getting the famous segmentation fault when trying to launch the usrp_spectrum_sense.py-script. When asked for an error log, I simply launched it in GDB and copy pasted the output plus backtrace. My OS is Ubuntu 10.04, running on a 32-bit machine. Default python version is 2.6. My hardware is the USRP N210 with XCVR2450. I tried to change my default python version (tried 2.5 and 2.7) but it did not help ( but I am also not sure if I have changed all the necessary paths correctly). Nevertheless I returned to 2.6 and have even reinstalled the GNUraduio package (using the build-script) -- nothing changed. uhd_fft.py and so on is working but I really need to get the above mentioned script running, to modify it later on. Thanks in advance for your answers. -Sebastian On Thu, 15 Dec 2011 12:40:02 +0100 Sebastian Döring sdoer...@rhrk.uni-kl.de wrote: On Wed, 14 Dec 2011 08:28:57 -0500 Marcus D. Leech mle...@ripnet.com wrote: On 14/12/11 08:05 AM, Sebastian Döring wrote: Thanks a lot. Code really looks like what I am looking for. Concerning the machine+Python version combinations that cause seg faults: Is there a known combination that works? Seems like mine doesn't. -Sebastian Could you expand on that a bit, please? Perhaps with an error log, and what you were trying to do when you got a segfault? -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org I was simply trying to test the script (usrp_spectrum_sense.py 2.4G 2.41G). I have reproduced the error using gdb and this is what I get: -- Starting program: /usr/bin/python usrp_spectrum_sense.py 2.4G 2.41G [Thread debugging using libthread_db enabled] linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.000-71810ad Warning: this is known to have issues on some machines+Python version combinations to seg fault due to the callback in bin_statitics. If you figure out why, we'd love to hear about it! -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes [New Thread 0xb6afbb70 (LWP 8791)] [New Thread 0xb62fab70 (LWP 8792)] gain = 49.5 [New Thread 0xb5a99b70 (LWP 8793)] [New Thread 0xb5298b70 (LWP 8794)] [New Thread 0xb4a56b70 (LWP 8795)] [New Thread 0xb40ffb70 (LWP 8796)] [New Thread 0xb38feb70 (LWP 8797)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb38feb70 (LWP 8797)] 0x0013a455 in sem_post@@GLIBC_2.1 () from /lib/tls/i686/cmov/libpthread.so.0 -- The backtrace says: -- #0 0x0013a455 in sem_post@@GLIBC_2.1 () from /lib/tls/i686/cmov/libpthread.so.0 #1 0x0810ab61 in PyThread_release_lock (lock=0x0) at ../Python/thread_pthread.h:374 #2 0x080dbad3 in PyEval_ReleaseLock () at ../Python/ceval.c:262 #3 0x00fa6073 in gr_py_feval_dd::calleval(double) () from /usr/local/lib/python2.6/dist-packages/gnuradio/gr/_gnuradio_core_general.so #4 0x0083a6cd in gr_bin_statistics_f::enter_tune_delay() () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #5 0x0083a788 in gr_bin_statistics_f::work(int, std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #6 0x007d70e7 in gr_sync_block::general_work(int, std::vectorint, std::allocatorint , std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #7 0x007ba475 in gr_block_executor::run_one_iteration() () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #8 0x007da549 in gr_tpb_thread_body::gr_tpb_thread_body(boost
Re: [Discuss-gnuradio] duration of uhd_rx_cfile script
On Wed, 14 Dec 2011 08:28:57 -0500 Marcus D. Leech mle...@ripnet.com wrote: On 14/12/11 08:05 AM, Sebastian Döring wrote: Thanks a lot. Code really looks like what I am looking for. Concerning the machine+Python version combinations that cause seg faults: Is there a known combination that works? Seems like mine doesn't. -Sebastian Could you expand on that a bit, please? Perhaps with an error log, and what you were trying to do when you got a segfault? -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org I was simply trying to test the script (usrp_spectrum_sense.py 2.4G 2.41G). I have reproduced the error using gdb and this is what I get: -- Starting program: /usr/bin/python usrp_spectrum_sense.py 2.4G 2.41G [Thread debugging using libthread_db enabled] linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.000-71810ad Warning: this is known to have issues on some machines+Python version combinations to seg fault due to the callback in bin_statitics. If you figure out why, we'd love to hear about it! -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes [New Thread 0xb6afbb70 (LWP 8791)] [New Thread 0xb62fab70 (LWP 8792)] gain = 49.5 [New Thread 0xb5a99b70 (LWP 8793)] [New Thread 0xb5298b70 (LWP 8794)] [New Thread 0xb4a56b70 (LWP 8795)] [New Thread 0xb40ffb70 (LWP 8796)] [New Thread 0xb38feb70 (LWP 8797)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb38feb70 (LWP 8797)] 0x0013a455 in sem_post@@GLIBC_2.1 () from /lib/tls/i686/cmov/libpthread.so.0 -- The backtrace says: -- #0 0x0013a455 in sem_post@@GLIBC_2.1 () from /lib/tls/i686/cmov/libpthread.so.0 #1 0x0810ab61 in PyThread_release_lock (lock=0x0) at ../Python/thread_pthread.h:374 #2 0x080dbad3 in PyEval_ReleaseLock () at ../Python/ceval.c:262 #3 0x00fa6073 in gr_py_feval_dd::calleval(double) () from /usr/local/lib/python2.6/dist-packages/gnuradio/gr/_gnuradio_core_general.so #4 0x0083a6cd in gr_bin_statistics_f::enter_tune_delay() () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #5 0x0083a788 in gr_bin_statistics_f::work(int, std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #6 0x007d70e7 in gr_sync_block::general_work(int, std::vectorint, std::allocatorint , std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #7 0x007ba475 in gr_block_executor::run_one_iteration() () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #8 0x007da549 in gr_tpb_thread_body::gr_tpb_thread_body(boost::shared_ptrgr_block) () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #9 0x007d3fcd in boost::detail::function::void_function_obj_invoker0gruel::thread_body_wrappertpb_container, void::invoke(boost::detail::function::function_buffer) () from /usr/local/lib/libgnuradio-core-3.5.0rc0.so.0.0.0 #10 0x009515f5 in boost::detail::thread_databoost::function0void ::run() () from /usr/local/lib/libgruel-3.5.0rc0.so.0.0.0 #11 0x009db7c5 in thread_proxy () from /usr/lib/libboost_thread.so.1.40.0 #12 0x0013396e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #13 0x003f1a4e in clone () from /lib/tls/i686/cmov/libc.so.6 -- -Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] duration of uhd_rx_cfile script
Hello all, I just measured the time the execution of uhd_rx_cfile.py takes all together. I used N=2, samp-rate=1M and the rest was left to the default values. In theory the taking of the samples should take T=N/B=20ms but I had to discover that the whole process is taking about 2s. Does anybody know what exactly is taking so long and if there is a way to speed it up? Since I am actually planning to somehow use this script (or parts of it) in the context of spectrum sensing/monitoring for dynamic access, 2 seconds is definitely taking to long. Thanks in advance. Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] duration of uhd_rx_cfile script
On Wed, 14 Dec 2011 07:36:38 -0500 Marcus D. Leech mle...@ripnet.com wrote: On 14/12/11 03:21 AM, Sebastian Döring wrote: Hello all, I just measured the time the execution of uhd_rx_cfile.py takes all together. I used N=2, samp-rate=1M and the rest was left to the default values. In theory the taking of the samples should take T=N/B=20ms but I had to discover that the whole process is taking about 2s. Does anybody know what exactly is taking so long and if there is a way to speed it up? Since I am actually planning to somehow use this script (or parts of it) in the context of spectrum sensing/monitoring for dynamic access, 2 seconds is definitely taking to long. Thanks in advance. Sebastian ___ Well, there's loading the Python interpreter, and the shared libraries it immediately relies on. Then there's loading all of the gnuradio and other stuff that is imported into your running Python image. Then there's creating and starting the flow-graph. Then there's the setting-up of the hardware that UHD has to do on startup. Yup, I can see that taking 2 seconds or more. If what you want to do is set frequency, record some data for awhile, change to a new frequency, rinse, repeat, then you're better off writing a custom flow-graph that does that, rather than trying to script something like uhd_rx_file.py. Once a flow-graph is setup and created, the overhead drops quite a bit. I think: gnuradio/gr-uhd/examples/usrp_spectrum_sense.py Already does a lot of what you want. -- 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 Thanks a lot. Code really looks like what I am looking for. Concerning the machine+Python version combinations that cause seg faults: Is there a known combination that works? Seems like mine doesn't. -Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Architecture of *_rx_cfile.py output vector
On Mon, 28 Nov 2011 10:32:28 -0500 Marcus D. Leech mle...@ripnet.com wrote: On 28-11-2011 10:21 AM, Sebastian Döring wrote: Hello List, just wanted to know exactly how the output vector of ..._rx_cfile.py is structured. Is the first element of the complex vector v[0] the one at the desired frequency sprecified by -f FREQ? Thanks Sebastian ' It's just raw complex-float samples in native-binary format. The first item is I the second is Q then I then Q, etc. They're time-series samples, not FFT outputs. Uh ok - explains a lot... Since the data is getting recorded as 32-bit complex float, is read_complex_binary() the right octave method to put it into a vector I can use for further processing? I found a gnuradio page that says read_short_binary() is supposed to be the right method, but the output vector does not make any sense to me... Regards Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Architecture of *_rx_cfile.py output vector
Hello List, just wanted to know exactly how the output vector of ..._rx_cfile.py is structured. Is the first element of the complex vector v[0] the one at the desired frequency sprecified by -f FREQ? Thanks Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] N210, About Decimation Rate
Hello List, I have a short question about the decimation rate of the USRP N210 : Since I know that the decimation rate of the N-Series is supposed to be programmable and that one was able to change it using the usrp_rx_cfile.py-script, why is this option missing in the UHD-Version of this script? Regards Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Keeping GNU Radio up-to-date
Hello, I used to do the following and it seemed to work quite well: sudo make uninstall make clean git pull ./configure make make check sudo make install -- (I think the path is ~/username/gnuradio/ if you used the script) Regards Sebastian On Wed, 16 Nov 2011 20:53:19 +0900 Songsong Gee gee.songs...@gmail.com wrote: I've installed GNU Radio with *build-gnuradio* script by Marcus Leech, Now, I have a question If I wanted to update GNU Radio, how should I do it? 1. re-download the script and run again. or 2. remove installed GNU Radio and UHD in *SOMEHOW* and do procedure (1.) For a Linux newbie, it is very confusing one. -- Seokseong Jeon, PhD Candidate Communication Networks Lab IT Convergence Engineering (ITCE), POSTECH, Korea +82 10 8338 1229, gee.songsong at gmail . com ___ 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] Problem running GRC
Hello, thanks for the help. The build script by Marcus Leech finally solved my problem. Regards Sebastian On Thu, 10 Nov 2011 07:08:53 -0800 Josh Blum j...@joshknows.com wrote: On 11/10/2011 03:55 AM, sdoer...@rhrk.uni-kl.de wrote: Hello list, I have already found this topic in an older post, but it ended after two mails. I have installed the latest gnuradio version via git on Ubuntu 11.10. Everything else is just the same like in the older post I just found except the version of GNURadio: [quote] I have the following exports added to bash.bashrc: # GNU Radio installation export PATH=$PATH:/usr/local/bin export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.6/site-packages Ubuntu 11.10 doesnt use python 2.6, perhaps that explains it? I recommend you clean out all gnuradio installs first. http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#The-problem-of-multiple-installs (I have checked that these default paths exist) When I try to launch grc from the terminal, I get a popup saying: cannot import gnuradio. Are your PYTHONPATH and LD_LIBRARY_PATH set correctly? [quote] The top of the popup is saying: /usr/local/lib/libgnuradio-core-3.5git.so.0: unde... [quote] When I try python -c import gnuradio i the terminal window, I get no error messages. [quote] When I run python -c from gnuradio import gr I get an import error (.../usr/local/lib/libgnuradio-core-3.5.0rc0.so.0: undefined symbol: _ZTIN5gruel12msg_accepterE). sudo ldconfig does not change anything. I would really appreciate your help. Regards Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
