[Discuss-gnuradio] GRC Message Source/Sink and Packet Source
Hi! I'm trying to integrate an existing Packet Source into GRC. I have some trouble understanding how this is supposed to work: In order to send a packet I need to use the gr_message_queue. How do I call a function to add a message to a queue from GRC? My Packet Source is supposed to define a message. A Message Sink takes one input. I connect that input with a Message Source. I understand that in this case the Sink accepts data. A packet is a byte data structure. So I want to send bytes to Message Sink. How can I return a byte structure into the message sink now? Is there any code that does that with GRC block? I know that transmit_path.py or benchmark_tx.py do that, but they are not separated. Therefore it's by far simpler here. Best, Marius ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] pulse signal generation
You can use UHD: USRP_Source an UHD:USRP_Sink block. You can define the center frequency of transmission in that block. Thanks, Nazmul On Tue, Jun 5, 2012 at 1:20 AM, S'dir wrote: > Hi Roberts, > > Greetings. Thank you for your input. > > I am able to bring up my system with Ubuntu 10.10 and with latest gnuradio > as well able to run the grc file successfully and see the output on screen. > > However, would like to know how the same to integrate and generate and > take the signal from USRP1 do I need to add any UHD blocks? (Typically how > to interface with USRP1) > > Regds, > Sudhir. > > On Fri, May 11, 2012 at 11:07 PM, wayne roberts > wrote: > >> Something to try: byte file source with one byte of 0xff, and the other 9 >> is 0x00. >> >> grc is attatched, but Gaussian filter is very strongly filtering it and i >> really dont understand it very well, which is needed for bandwidth limiting. >> But if you dont want any filtering, you could feed file source directly >> to real input of float-to-complex (with only type conversion). >> >> also attached is file you can use xxd to convert binary file to & from >> text file. >> I dont know if binary file attaches to email, but you can put this into >> xxd -r: >> 000: ff00 >> >> >> >> On Thu, May 10, 2012 at 11:50 PM, S'dir wrote: >> >>> Hi, >>> >>> I am a starter. How to generate 100Hz (10% duty) pulsed signal using >>> gnuradio & usrp1 >>> >>> Any help would be highly appreciated. >>> >>> Thanks & Regds, >>> Sudhir. >>> >>> > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Muhammad Nazmul Islam Graduate Student Electrical & Computer Engineering Wireless Information & Networking Laboratory Rutgers, USA. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] crashes, memory errors and valgrind
On Mon, Jun 4, 2012 at 2:18 PM, Tom Rondeau wrote: > On Sun, Jun 3, 2012 at 2:22 PM, Patrick Strasser > wrote: >> Hi Tom, >> >> Tom Rondeau wrote on 2012-06-03 17:12: >>> On Sat, Jun 2, 2012 at 5:50 AM, Patrick Strasser >>> Patrick, >>> >>> It looks like you're problem is in the rational_resampler code. I >>> wonder if there's something about the resampling rate being used >>> that's causing something to go out of bounds here. Can you dig into >>> the code and figure out what interpolation and decimation rates are >>> being used? >> >> Interpolation is 1, decimation is 2. >> >> I compiled GNU Radio branch v3.6.0 with >> $ cmake -DCMAKE_BUILD_TYPE=Debug .. >> which resulted in a compile with flags -g -O2 . >> I tried to track what's happening in gdb, in gr_fir_fff_simd::set_taps, >> but -O2 was not helping, a lot optimized out, loops unrolled. >> >> Full valgrind log in >> http://pastebin.com/7GCs3bWy >> >> regards >> >> Patrick > > I was hoping you'd say the interpolation and/or decimation were some > ridiculously large numbers. Since the block is only actually > decimating, could you replace it in the code with an fir_filter_fff > (or fft_filter_fff) just for testing purposes? That'll help us see if > it's the rational resampler itself or something more general. Patrick: You can now try my own osmosdr branch from https://github.com/csete/gqrx I have made many changes since I told you to stay away few days ago and I think it is slightly usable now. This code adds proper multirate support by using the arbitrary PFB resamplers on both the quadrature and the audio end. It also takes advantage of the device discovery API in gr-osmosdr so you really just plug in your devices and go :-) It still works very well with the Funcube Dongle and is supposed to work with UHD devices but I really haven't had time to debug that part yet. Gr-osmosdr source works though with UHD devices in GRC, so it's a gqrx issue if it doesn't work. Concerning the original topic of this thread: I can't dismiss that it's a rarely seen bug in the GR code, but keep in mind that the fork was made when much of my code assumed 96ksps input rate and 48ksps audio rate. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about OpenBTS
On 2012/6/4 23:28, Thomas Tsou wrote: On Sun, Jun 3, 2012 at 9:49 AM, Pan, Luyuan wrote: Hello, I want to set up the OpenBTS, and I want to know which board is better, USRP1 or USRP2? Or any other suggestion? Thank you. Both USRP1 and USRP2 work with OpenBTS and neither can be considered "better" without describing your requirements. USRP2 / N2xx will support higher bandwidths with the GigE interface if that is important to you. USRP1 (or B100) will be cheaper. For stable clocking, the USRP1 requires hardware modification to support an external 52MHz clock signal. Other devices can use a more accessible internal or external 10 MHz reference source. Also, OpenBTS is not gnuradio, and the openbts-discuss or usrp-users lists may be better sources for that type of information. http://lists.sourceforge.net/lists/listinfo/openbts-discuss http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com Thomas Sorry, This may not the proper place to ask question about OpenBTS, But I just want to ask one more questions. My scenario is : I want to set up a BTS, scan the user nearby and get their IMSI, then attract them to my fake BTS and broadcast them a message. 1. I want to use USRP1 to do the project, Is it enough? (I have both of USRP1 and USRP2 at hand) 2. Is it that SMS-CB a better choice for me? (my ultimate goal is to broadcast some messages) Thank you for your help! -- Best regards, Pan, Luyuan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] crashes, memory errors and valgrind
Tom Rondeau wrote on 2012-06-04 14:18: > On Sun, Jun 3, 2012 at 2:22 PM, Patrick Strasser > wrote: >> Hi Tom, >> >> Tom Rondeau wrote on 2012-06-03 17:12: >>> On Sat, Jun 2, 2012 at 5:50 AM, Patrick Strasser >>> Patrick, >>> >>> It looks like you're problem is in the rational_resampler code. I >>> wonder if there's something about the resampling rate being used >>> that's causing something to go out of bounds here. Can you dig into >>> the code and figure out what interpolation and decimation rates are >>> being used? >> >> Interpolation is 1, decimation is 2. >> Full valgrind log in >> http://pastebin.com/7GCs3bWy > > I was hoping you'd say the interpolation and/or decimation were some > ridiculously large numbers. Since the block is only actually > decimating, could you replace it in the code with an fir_filter_fff > (or fft_filter_fff) just for testing purposes? That'll help us see if > it's the rational resampler itself or something more general. What seems strange to me is the allocation of a buffer of a non by 8 dividable size, that is accessed in blocks of 8 bytes. So the last read always either does not touch the end of the buffer, or it reads beyond the end. I'm a little sparse at time until Sunday evening. I tried to write some mini program starting from dial_tone.cc which uses a filter, have to convince cmake to compile it... learning ;-) 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 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 95, in __init__
self.gr_multiply_xx_1 = gr.multiply_vff(1)
File
"/usr/lib/python2.6/site-packages/gnuradio/gr/gnuradio_core_general.py",
line 8642, in multiply_ff
return _gnuradio_core_general.multiply_ff(vlen)
RuntimeError: gr_block::set_alignment_multiple
Here is the output from gqrx:
>>> gr_fir_ccc: using 3DNow!Ext
Using Volk machine: generic
terminate called after throwing an instance of 'std::invalid_argument'
what(): gr_block::set_alignment_multiple
Aborted
volk_profile gives the same error as previous.
Cheers,
Fred
Re: [Discuss-gnuradio] gqrx branch osmosdr
On Tue, Jun 5, 2012 at 4:02 PM, Patrick Strasser wrote: > > I tried it, pulled the latest from rtl-sdr and gr-osmosdr and gqrx > branch osmosdr. > % git describe > v2.1-git-61-g7bf22e9 > > Built fine, but I could not get it running. It seems to hit an uncought > execption and dumps core: > > % ./gqrx > linux; GNU C++ version 4.6.3; Boost_104900; UHD_003.004.002-0-g7f44d838 > > gr-osmosdr supported device types: file fcd rtl rtl_tcp uhd gr_fir_ccf: using SSE gr_fir_ccc: using SSE > Using Volk machine: sse4_2_64 gr_fir_fff: using SSE > New filter offset: 0 Hz > Loading configuration from: "default.conf" > Configuration file: "/home/past/.config/gqrx/default.conf" > terminate called after throwing an instance of 'std::runtime_error' > what(): meta-range cannot be empty > [1] 8188 abort (core dumped) ./gqrx > ... > > gain_rel is 0.5. I deleted an old ~/.config/gqrx/default.conf, still the > same. My device is a Terratec NOXON DAB stick rev1, but it does not make > a difference if the stick is connected or disconnected. > > A problem in libosmosdr? > > ps: Would be nice to have a replay functionality, mirroring the IQ > recording functionality. I guess that needs some extensions in the > startup device setup code... Thanks for the feedback. It was a lack of check in gqrx. You can try to pull & build again. And yes, good idea to delete old default.conf file. Also note that saving and loading configuration under different names is not quite robust yet. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error -- intel_do_flush_locked with V3.6.1git on Ubuntu 12.04
Hello list readers, i tried to install on fresh LinuxMInt13 (a version of Ubuntu 12.04) to compile and install with the build_gnuradio-script the new 3.6.1git version out of the git archives. (not josh) it seems to me a good idea to add the prereqs liborc-0.4-dev. This works really fine. Every thing seems to be ok, simple examples did work (i.e. tone generator) But examples with FunCube Dongle or RTL-DVB-TStick showed a "hard" error which closes the the actual running grc-program at start up time.. Example: fcd_nbfm_rx.grc gives Using Volk machine: sse2_32_orc >>> gr_fir_fff: using SSE intel_do_flush_locked failed: Invalid argument >>> Done I had another installation based on SUSE 11.4 (self compiled packet) which works fine with FCD and RTL. As I did not find any solution for this reported error, I like to ask the "knowledge base" list readers ;-) Does anybody now of similar errors is it a new problem? Is there any advice to solve the error Does anybody know of a workaround for gnuradio since this error is reported with different other applications and system software. Your tips are very welcome Thanks in advance M. Hartje -- Prof. Dr.-Ing. Michael Hartje Labor Hochspannungstechnik / Labor elektrische Messtechnik Neustadtswall 30; D-28199 Bremen Tel +49 421 5905-3444FAX +49 421 5905-3476 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error -- intel_do_flush_locked with V3.6.1git on Ubuntu 12.04
On Tue, Jun 5, 2012 at 4:39 PM, Michael Hartje wrote: > Hello list readers, > > i tried to install on fresh LinuxMInt13 (a version of Ubuntu 12.04) to > compile and install with the build_gnuradio-script the new 3.6.1git > version out of the git archives. (not josh) > > it seems to me a good idea to add the prereqs liborc-0.4-dev. That wouldn't work with e.g. Ubuntu 11.04 because it has only orc 0.4.11 and both UHD and GNU Radio requires a version strictly greater than 0.4.11 > This works really fine. Every thing seems to be ok, simple examples did > work (i.e. tone generator) > > But examples with FunCube Dongle or RTL-DVB-TStick showed a "hard" error > which closes the the actual running grc-program at start up time.. > > Example: fcd_nbfm_rx.grc gives > Using Volk machine: sse2_32_orc gr_fir_fff: using SSE > intel_do_flush_locked failed: Invalid argument I haven't seen this error but I can assure you that the Funcube Dongle source will not work on systems with libusb-1.0.9. I will submit a patch for that soon - until then stick to the RTL device. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error -- intel_do_flush_locked with V3.6.1git on Ubuntu 12.04
> intel_do_flush_locked failed: Invalid argument This is a problem with Intel graphics drivers. Switching to a software graphics stack ( Mesa ) worked for me. On Tue, Jun 5, 2012 at 10:48 AM, Alexandru Csete wrote: > On Tue, Jun 5, 2012 at 4:39 PM, Michael Hartje > wrote: >> Hello list readers, >> >> i tried to install on fresh LinuxMInt13 (a version of Ubuntu 12.04) to >> compile and install with the build_gnuradio-script the new 3.6.1git >> version out of the git archives. (not josh) >> >> it seems to me a good idea to add the prereqs liborc-0.4-dev. > > That wouldn't work with e.g. Ubuntu 11.04 because it has only orc > 0.4.11 and both UHD and GNU Radio requires a version strictly greater > than 0.4.11 > > >> This works really fine. Every thing seems to be ok, simple examples did >> work (i.e. tone generator) >> >> But examples with FunCube Dongle or RTL-DVB-TStick showed a "hard" error >> which closes the the actual running grc-program at start up time.. >> >> Example: fcd_nbfm_rx.grc gives >> Using Volk machine: sse2_32_orc > gr_fir_fff: using SSE >> intel_do_flush_locked failed: Invalid argument > > I haven't seen this error but I can assure you that the Funcube Dongle > source will not work on systems with libusb-1.0.9. I will submit a > patch for that soon - until then stick to the RTL device. > > Alex > > ___ > 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] benchmark_rx n_right always 0
I am using benchmark_tx/benchmark_rx to transmit data on 2.41GHz: *./benchmark_rx.py -f 2.41G* *./benchmark_tx.py -f 2.41G* While I can receive packages at the rx end, the n_right field of every package is always 0. I know it means the package failed the CRC check. What might be the cause? I am using two USRP N210s and daughter boards are XCVR2450. The following are the displayed message at rx end: *belltestbed@belltestbed-OptiPlex-790:~/Desktop/gnuradio/gr-digital/exales/narrowband$ ./benchmark_rx.py -f 2.41G * *linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.002-128-g12f7a5c9* * * *>>> gr_fir_ccf: using SSE* *-- Opening a USRP2/N-Series device...* *-- Current recv frame size: 1472 bytes* *-- Current send frame size: 1472 bytes* * * *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* * * *No gain specified.* *Setting gain to 49.50 (from [0.00, 99.00])* * * *UHD Warning:* *The hardware does not support the requested RX sample rate:* *Target sample rate: 0.05 MSps* *Actual sample rate: 0.195312 MSps* * * *Symbol Rate: 25000.00* *Requested sps: 2.00* *Given sample rate: 195312.50* *Actual sps for rate: 7.812500* * * *Requested sample rate: 5.00* *Actual sample rate: 195312.50* *Warning: Failed to enable realtime scheduling.* *Using Volk machine: avx_32* *ok = False pktno = 65 n_rcvd =1 n_right =0* *ok = False pktno = 67 n_rcvd =2 n_right =0* *ok = False pktno = 68 n_rcvd =3 n_right =0* *ok = False pktno = 69 n_rcvd =4 **n_right =0* *ok = False pktno = 70 n_rcvd =5 **n_right =0* *ok = False pktno = 71 n_rcvd =6 **n_right =0* *ok = False pktno = 72 n_rcvd =7 **n_right =0* *ok = False pktno = 73 n_rcvd =8 **n_right =0* *ok = False pktno = 74 n_rcvd =9 **n_right =0* *ok = False pktno = 75 n_rcvd = 10 **n_right =0* *ok = False pktno = 76 n_rcvd = 11 **n_right =0* *ok = False pktno = 189 n_rcvd = 12 **n_right =0* -- Regards, Weixian Zhou ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-howto-write-a-block new documentation
Hello all, Just one quick question. Does anybody know if we have a documentation for the gr-howto-write-a-block with the new folder structure and cmake? The link given on the gnuradio.org is old. http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html Thanks! Regards Pranav Sakulkar Student Assistant Lehrstuhl für Theoretische Informationstechnik RWTH Aachen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC Message Source/Sink and Packet Source
On 06/05/2012 03:17 AM, Marius wrote: > Hi! > > I'm trying to integrate an existing Packet Source into GRC. I have > some trouble understanding how this is supposed to work: > Actually, this packet sink is integrated into GRC and the design is actually as regrettable as you can imagine: http://gnuradio.org/cgit/gnuradio.git/tree/grc/grc_gnuradio/blks2/packet.py http://gnuradio.org/cgit/gnuradio.git/tree/grc/blocks/blks2_packet_encoder.xml http://gnuradio.org/cgit/gnuradio.git/tree/grc/blocks/blks2_packet_decoder.xml The blocks have stream IO all the way, which means there is code slicing up the stream and feeding the message queue; yes, and spitting it back out to stream for the decoder. It probably would be better to have offered a message queue as the input or output, but these were written before GRC supported message queues. I also created a version of this packet framer/deframer which uses the PMT message passing feature instead, there is a nice screenshot in the message section: https://github.com/guruofquality/grextras/wiki -josh > In order to send a packet I need to use the gr_message_queue. How do I > call a function to add a message to a queue from GRC? > > My Packet Source is supposed to define a message. A Message Sink takes > one input. I connect that input with a Message Source. I understand > that in this case the Sink accepts data. > A packet is a byte data structure. So I want to send bytes to Message > Sink. How can I return a byte structure into the message sink now? Is > there any code that does that with GRC block? I know that > transmit_path.py or benchmark_tx.py do that, but they are not > separated. Therefore it's by far simpler here. > > Best, > Marius > > ___ > 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] Trouble with gnuradio and AMD32
>> 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 Looks like volk isnt detecting your machine right... hmmm curious. gr_fir_ccc: using 3DNow!Ext > Using Volk machine: generic > terminate called after throwing an instance of 'std::invalid_argument' > what(): gr_block::set_alignment_multiple > Aborted And the volk alignment width must somehow be returning zero? I think thats the only way to make that function unhappy. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gqrx branch osmosdr
Alexandru Csete wrote on 2012-06-05 16:36: > On Tue, Jun 5, 2012 at 4:02 PM, Patrick Strasser >> v2.1-git-61-g7bf22e9 >> >> Built fine, but I could not get it running. > > Thanks for the feedback. It was a lack of check in gqrx. You can try > to pull & build again. Much better. The device selection dialog is nice. Works now. Again, could crash it: I started gqrx, run the receiver. When opening the device selection dialog again and selecting the same device with a different sampling rate, the program quits, command line output says: % ./gqrx linux; GNU C++ version 4.6.3; Boost_104900; UHD_003.004.002-0-g7f44d838 gr-osmosdr supported device types: file fcd rtl rtl_tcp uhd >>> gr_fir_ccf: using SSE >>> gr_fir_ccc: using SSE Using Volk machine: sse4_2_64 >>> gr_fir_fff: using SSE New filter offset: 0 Hz Loading configuration from: "default.conf" Configuration file: "/home/past/.config/gqrx/default.conf" gr-osmosdr supported device types: file fcd rtl rtl_tcp uhd Using device #0: Terratec NOXON DAB/DAB+ USB dongle (rev 1) Found Fitipower FC0013 tuner Changing NB_RX quad rate: 96000 -> 1.6e+06 Requested sample rate: 160 Actual sample rate : "160.00" Gain start/stop/rel/abs:-6.3/19.7/0.5/6.7 AVG I/Q: -0.00109374/-0.00117664 AVG I/Q: 0.000537707/0.0022715 [...Lots of following left out: No audio FFT data. AVG I/Q: -0.00246447/2.69753e-05...] Configure I/O devices. AVG I/Q: 0.00371283/0.00201518 CIoConfig : Available input devices: 0 : "Unknown" CIoConfig : Available output devices: 0 : "Built-in Audio Analog Stereo" 1 : "USB Audio Analog Stereo" No audio FFT data. AVG I/Q: -0.00246447/2.69753e-05 AVG I/Q: -0.00109965/-0.00466416 [...Lots of following left out: No audio FFT data. AVG I/Q: -0.00246447/2.69753e-05...] saveConfig Selected output device is 'default' (not saving) Loading configuration from: "/home/past/.config/gqrx/default.conf" Configuration file: "/home/past/.config/gqrx/default.conf" gr-osmosdr supported device types: file fcd rtl rtl_tcp uhd AVG I/Q: -3.42441e-05/-0.00127908 Using device #0: Terratec NOXON DAB/DAB+ USB dongle (rev 1) usb_claim_interface error -6 Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there. terminate called after throwing an instance of 'std::runtime_error' what(): Failed to open rtlsdr device. [1]5834 abort (core dumped) ./gqrx selected output device is 'default' (not saving) Loading configuration from: "/home/past/.config/gqrx/default.conf" Configuration file: "/home/past/.config/gqrx/default.conf" gr-osmosdr supported device types: file fcd rtl rtl_tcp uhd Using device #0: Terratec NOXON DAB/DAB+ USB dongle (rev 1) usb_claim_interface error -6 Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there. terminate called after throwing an instance of 'std::runtime_error' what(): Failed to open rtlsdr device. Backtrace: (gdb) bt #0 0x74613475 in *__GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x746166f0 in *__GI_abort () at abort.c:92 #2 0x74e6568d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x74e63796 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x74e637c3 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #5 0x74e63a36 in __cxa_rethrow () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #6 0x754a347c in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #7 0x754a8277 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #8 0x00418fc7 in main (argc=1, argv=0x7fffdbe8) at applications/gqrx/main.cpp:59 > And yes, good idea to delete old default.conf file. > Also note that saving and loading configuration under different names > is not quite robust yet. Thought so ;-) In comparison to the rtlsdr fork I see you added FM-W. FM-N in comparison sounds more clipped, FM-W is clipped with a narrow filter, but noisy with a wide filter. With a filter that has no clipping, noise is clearly audible. I'm not sure if this is bound by the low dynamic sampling range (8 bit) in combination with big bandwith which means a lot more noise energy with wide filters. Anyway, gqrx gets greater every time! 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
[Discuss-gnuradio] Error -- intel_do_flush_locked with V3.6.1git on Ubuntu 12.04 (addition)
I like make an addition to my last observation with Gnuradio V 3.6.1git on Ubuntu 12.04 when I started the fcd_nbfm.grc direct on the Ubuntu12.04, I got the already mentioned error after shortly opening the window and a few hundred milliseconds of sound.. When I contact via ssh -C -X from my opensuse 11.4 machine, the start of gnuradio-companion brings the window to the opensuse-machine-desktop (as expected). Starting the fcd_nbfm.grc opens the window and sound is on the ubuntu-machine (as expected). But there is _no_ spectrum view -- and when I made some other test there is no oscilloscope view inside the window. This leads me to the conclusion: there is an incompatibility between these two X11 implementations or a missing library on the ubuntu-machine in addition to this: it could be a solution for the error, when i tried to work on the ubuntu-machine? Does anybody made similar observations? Any helpful advices are very welcome to reduce or solve the problem. Michael ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gqrx branch osmosdr
On Tue, Jun 5, 2012 at 6:51 PM, Patrick Strasser wrote: > Alexandru Csete wrote on 2012-06-05 16:36: >> On Tue, Jun 5, 2012 at 4:02 PM, Patrick Strasser >>> v2.1-git-61-g7bf22e9 >>> >>> Built fine, but I could not get it running. >> >> Thanks for the feedback. It was a lack of check in gqrx. You can try >> to pull & build again. > > Much better. The device selection dialog is nice. Works now. > > Again, could crash it: > I started gqrx, run the receiver. > When opening the device selection dialog again and selecting the same > device with a different sampling rate, the program quits, command line > output says: Yes, I know about this problem. > > In comparison to the rtlsdr fork I see you added FM-W. FM-N in > comparison sounds more clipped, FM-W is clipped with a narrow filter, > but noisy with a wide filter. With a filter that has no clipping, noise > is clearly audible. I'm not sure if this is bound by the low dynamic > sampling range (8 bit) in combination with big bandwith which means a > lot more noise energy with wide filters. Anyway, gqrx gets greater every > time! There is no audio filter yet (except de-emphasis) so you get pretty much 48 kHz worth of noise, including stereo pilot tone and whatever crap they include in a broadcast FM channel these days. Alex ___ 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 06/05/2012 09:39 AM, Josh Blum wrote: > >>> 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 > > Looks like volk isnt detecting your machine right... hmmm curious. All, we dont have an sse machine generated since there are no sse only kernels. So that should be expected. > > gr_fir_ccc: using 3DNow!Ext >> Using Volk machine: generic >> terminate called after throwing an instance of 'std::invalid_argument' >> what(): gr_block::volk_get_alignment >> Aborted > so volk_get_alignment() should be returning 1. Would that be a problem for volk_get_alignment in this particular block, Tom? -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] /usr/local/include/gnuradio/swig/gnuradio.i:31: Error: Unable to find 'gruel_common.i'
Thanks a lot Josh. I changed swigincludedir to
swigincludedir =
$(grincludedir)/swig -I/usr/local/include/gruel/swig
Now I get these errors
wlab@ubuntu:~/gr-ieee802-15-4$ make
make all-recursive
make[1]: Entering directory `/home/wlab/gr-ieee802-15-4'
Making all in config
make[2]: Entering directory `/home/wlab/gr-ieee802-15-4/config'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/wlab/gr-ieee802-15-4/config'
Making all in src
make[2]: Entering directory `/home/wlab/gr-ieee802-15-4/src'
Making all in lib
make[3]: Entering directory `/home/wlab/gr-ieee802-15-4/src/lib'
make all-am
make[4]: Entering directory `/home/wlab/gr-ieee802-15-4/src/lib'
/bin/bash ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I../.. -I/usr/local/include/gnuradio -I/usr/local/include
-I/usr/include/python2.7-g -O2 -Wall -Woverloaded-virtual -pthread -MT
ucla.lo -MD -MP -MF .deps/ucla.Tpo -c -o ucla.lo ucla.cc
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../..
-I/usr/local/include/gnuradio -I/usr/local/include -I/usr/include/python2.7 -g
-O2 -Wall -Woverloaded-virtual -pthread -MT ucla.lo -MD -MP -MF .deps/ucla.Tpo
-c ucla.cc -fPIC -DPIC -o .libs/ucla.o
ucla.cc:3123:13: error: 'ptrdiff_t' does not name a type
ucla.cc:3160:21: error: expected ';' at end of member declaration
ucla.cc:3160:39: error: expected ')' before 'n'
ucla.cc:3175:34: error: declaration of 'operator+=' as non-function
ucla.cc:3175:30: error: expected ';' at end of member declaration
ucla.cc:3175:44: error: expected ')' before 'n'
ucla.cc:3180:34: error: declaration of 'operator-=' as non-function
ucla.cc:3180:30: error: expected ';' at end of member declaration
ucla.cc:3180:44: error: expected ')' before 'n'
ucla.cc:3185:33: error: declaration of 'operator+' as non-function
ucla.cc:3185:30: error: expected ';' at end of member declaration
ucla.cc:3185:43: error: expected ')' before 'n'
ucla.cc:3190:33: error: declaration of 'operator-' as non-function
ucla.cc:3190:30: error: expected ';' at end of member declaration
ucla.cc:3190:43: error: expected ')' before 'n'
ucla.cc:3195:5: error: 'ptrdiff_t' does not name a type
ucla.cc:3563:15: error: 'swig::check_index' declared as an 'inline' variable
ucla.cc:3563:15: error: 'ptrdiff_t' was not declared in this scope
ucla.cc:3563:15: note: suggested alternatives:
/usr/include/c++/4.6/x86_64-linux-gnu/./bits/c++config.h:156:28: note:
'std::ptrdiff_t'
/usr/include/c++/4.6/x86_64-linux-gnu/./bits/c++config.h:156:28: note:
'std::ptrdiff_t'
ucla.cc:3563:35: error: expected primary-expression before 'size'
ucla.cc:3563:41: error: expected primary-expression before 'bool'
ucla.cc:3563:60: error: expression list treated as compound expression in
initializer [-fpermissive]
ucla.cc:3563:62: error: expected ',' or ';' before '{' token
In file included from /usr/include/boost/detail/sp_typeinfo.hpp:109:0,
from
/usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:27,
from
/usr/include/boost/smart_ptr/detail/sp_counted_base.hpp:36,
from /usr/include/boost/smart_ptr/detail/shared_count.hpp:29,
from /usr/include/boost/smart_ptr/shared_ptr.hpp:32,
from /usr/include/boost/shared_ptr.hpp:17,
from /usr/local/include/gnuradio/gr_types.h:27,
from /usr/local/include/gnuradio/gr_runtime_types.h:27,
from /usr/local/include/gnuradio/gr_basic_block.h:27,
from /usr/local/include/gnuradio/gr_block.h:27,
from ucla_cc1k_correlator_cb.h:25,
from ucla.cc:4114:
/usr/include/c++/4.6/typeinfo:42:37: error: expected '}' before end of line
/usr/include/c++/4.6/typeinfo:42:37: error: expected declaration before end of
line
make[4]: *** [ucla.lo] Error 1
make[4]: Leaving directory `/home/wlab/gr-ieee802-15-4/src/lib'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/wlab/gr-ieee802-15-4/src/lib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/wlab/gr-ieee802-15-4/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/wlab/gr-ieee802-15-4'
make: *** [all] Error 2
I think some libraries and dependencies are still missing. Any help will do
from your end.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG, current gr-howto structure and exception specifiers
On Sun, Jun 03, 2012 at 10:22:14AM -0400, Tom Rondeau wrote: > On the other hand, I thought all standard exceptions were passed > properly through SWIG to Python already. I was under the impression > that if you're header file declares that it throws, then you can catch > it in Python. If that's not the case, then we should try to figure out > an easy way to handle that. Hi Tom and rest, so, I didn't do my research properly (partly): Exceptions *are* caught by SWIG, *but* they always end up as RuntimeErrors, regardless of what the exception type was in C++. So, for future reference: If you throw a std::invalid_argument in a block constructor, it ends up as a RuntimeError in Python. If you hand-edit the SWIG file and add an exception specifier, it ends up as a ValueError, which I think is the better behaviour, and it would be great if SWIG did this automatically. But frankly, I don't think this is that big a deal, I'll just catch RuntimeErrors instead of ValueErrors. Or edit .i-files. There's just no "clean" way to do this, because you'd either have to specify the exceptions in the header (which is deprecated C++), write a .i (redundant) or lose the exception type. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GrExtras - write blocks in python, message passing, misc features...
On Sat, Jun 02, 2012 at 10:52:50AM -0700, Josh Blum wrote: > Message passing builds on top of the existing GNU Radio stream tags - to > give the user an API to simply pass tags (without the streams) as > messages between blocks. The user can use this feature to implement a > packet layer in gnuradio, or even do control plane stuff - but all the > while, sticking to the standard block flow graph model that users are > familiar with. Hi Josh, this is nice stuff. I'll be definitely playing around with it. One question on the messages: is there a reason messages can't be passed upstream? That might come in handy on occasions. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GrExtras - write blocks in python, message passing, misc features...
On 06/05/2012 01:17 PM, Martin Braun wrote: > On Sat, Jun 02, 2012 at 10:52:50AM -0700, Josh Blum wrote: >> Message passing builds on top of the existing GNU Radio stream tags - to >> give the user an API to simply pass tags (without the streams) as >> messages between blocks. The user can use this feature to implement a >> packet layer in gnuradio, or even do control plane stuff - but all the >> while, sticking to the standard block flow graph model that users are >> familiar with. > > Hi Josh, > > this is nice stuff. I'll be definitely playing around with it. > Cool thanks! > One question on the messages: is there a reason messages can't be passed > upstream? That might come in handy on occasions. > Actually, I think that should work just fine. I haven't created a control-plane sort of demo, I guess I should make that a mini project this weekend. But in theory, if block A feeds block B a stream, block B could have a message source that feeds a message sink on block A. That shouldnt violate any of gnuradio's circular link checks when it flattens the hierarchy, because the message part of the blocks are actually separate blocks internally. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using external clock references in GRC environment
Hello, I am running two USRP2's with a 10 MHz external clock. I am using gnuradio-companion to transmit data between the USRP's. I have changed the *clock source* option as 'external' in the UHD:USRP Source & Sinc blocks. I kept the time source and clock rate block as default since I am not providing any external pps. Unfortunately, I am getting unexpected and wrong outputs. Do I need to make any other changes in the USRP Source & Sink options? Thanks, Nazmul -- Muhammad Nazmul Islam Graduate Student Electrical & Computer Engineering Wireless Information & Networking Laboratory Rutgers, USA. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gqrx branch osmosdr
Alexandru Csete wrote on 2012-06-05 19:06: > On Tue, Jun 5, 2012 at 6:51 PM, Patrick Strasser >> In comparison to the rtlsdr fork I see you added FM-W. FM-N in >> comparison sounds more clipped, FM-W is clipped with a narrow filter, >> but noisy with a wide filter. With a filter that has no clipping, noise >> is clearly audible. I'm not sure if this is bound by the low dynamic >> sampling range (8 bit) in combination with big bandwith which means a >> lot more noise energy with wide filters. Anyway, gqrx gets greater every >> time! > > There is no audio filter yet (except de-emphasis) so you get pretty > much 48 kHz worth of noise, including stereo pilot tone and whatever > crap they include in a broadcast FM channel these days. It's AM and some special BPSK. Nice ensemble of different analogue and digital schemes, maybe we'll use it as an demonstration in one of our lectures here at University. Anyway, my ears have a builtin filter that cuts dramatically everything above some 18kHz, not sure if I can hear the pilot tone. If you are not doing dirty tricks every decimating filter should prevent aliasing, so no effect of everything that's higher than half the sampling rate. With 48 kHz you should not get even close to the higher energy parts of AM at arround 38kHz. I guess where noise comes in is before FM demodulation: the bigger the sampled frequency bandwidth, the more noise energy. With the limited dynamic range this decreases the signal (FM) to noise (background) ratio, which opposes good demodulation results. Per design and regulation a FM radio signal has mono 180 kHz bandwidth and stere 300 kHz, but I do not know of a station sending in mono here in Austria. Maybe a kind of matched filter would be best: you can expect that the wider fare a frequency is from center frequency, the less energy it has. Maybe thirds would work: < -150 kHz stop, up to -50 kHz transition, -50 to +50 kHz pass, +50 up to +150 transition, and then again stop. Frequency deviation is specified as 75 kHz. 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] /usr/local/include/gnuradio/swig/gnuradio.i:31: Error: Unable to find 'gruel_common.i'
On 06/05/2012 11:00 AM, Baidoo-Williams, Henry E wrote:
> Thanks a lot Josh. I changed swigincludedir to
> swigincludedir =
> $(grincludedir)/swig -I/usr/local/include/gruel/swig
> Now I get these errors
>
> wlab@ubuntu:~/gr-ieee802-15-4$ make
> make all-recursive
> make[1]: Entering directory `/home/wlab/gr-ieee802-15-4'
> Making all in config
> make[2]: Entering directory `/home/wlab/gr-ieee802-15-4/config'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory `/home/wlab/gr-ieee802-15-4/config'
> Making all in src
> make[2]: Entering directory `/home/wlab/gr-ieee802-15-4/src'
> Making all in lib
> make[3]: Entering directory `/home/wlab/gr-ieee802-15-4/src/lib'
> make all-am
> make[4]: Entering directory `/home/wlab/gr-ieee802-15-4/src/lib'
> /bin/bash ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
> -I../.. -I/usr/local/include/gnuradio -I/usr/local/include
> -I/usr/include/python2.7-g -O2 -Wall -Woverloaded-virtual -pthread -MT
> ucla.lo -MD -MP -MF .deps/ucla.Tpo -c -o ucla.lo ucla.cc
> libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../..
> -I/usr/local/include/gnuradio -I/usr/local/include -I/usr/include/python2.7
> -g -O2 -Wall -Woverloaded-virtual -pthread -MT ucla.lo -MD -MP -MF
> .deps/ucla.Tpo -c ucla.cc -fPIC -DPIC -o .libs/ucla.o
> ucla.cc:3123:13: error: 'ptrdiff_t' does not name a type
You are missing an include like cstdlib perhaps
> ucla.cc:3160:21: error: expected ';' at end of member declaration
> ucla.cc:3160:39: error: expected ')' before 'n'
> ucla.cc:3175:34: error: declaration of 'operator+=' as non-function
> ucla.cc:3175:30: error: expected ';' at end of member declaration
> ucla.cc:3175:44: error: expected ')' before 'n'
> ucla.cc:3180:34: error: declaration of 'operator-=' as non-function
> ucla.cc:3180:30: error: expected ';' at end of member declaration
> ucla.cc:3180:44: error: expected ')' before 'n'
> ucla.cc:3185:33: error: declaration of 'operator+' as non-function
> ucla.cc:3185:30: error: expected ';' at end of member declaration
> ucla.cc:3185:43: error: expected ')' before 'n'
> ucla.cc:3190:33: error: declaration of 'operator-' as non-function
> ucla.cc:3190:30: error: expected ';' at end of member declaration
> ucla.cc:3190:43: error: expected ')' before 'n'
> ucla.cc:3195:5: error: 'ptrdiff_t' does not name a type
> ucla.cc:3563:15: error: 'swig::check_index' declared as an 'inline' variable
> ucla.cc:3563:15: error: 'ptrdiff_t' was not declared in this scope
> ucla.cc:3563:15: note: suggested alternatives:
> /usr/include/c++/4.6/x86_64-linux-gnu/./bits/c++config.h:156:28: note:
> 'std::ptrdiff_t'
> /usr/include/c++/4.6/x86_64-linux-gnu/./bits/c++config.h:156:28: note:
> 'std::ptrdiff_t'
> ucla.cc:3563:35: error: expected primary-expression before 'size'
> ucla.cc:3563:41: error: expected primary-expression before 'bool'
> ucla.cc:3563:60: error: expression list treated as compound expression in
> initializer [-fpermissive]
> ucla.cc:3563:62: error: expected ',' or ';' before '{' token
> In file included from /usr/include/boost/detail/sp_typeinfo.hpp:109:0,
> from
> /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:27,
> from
> /usr/include/boost/smart_ptr/detail/sp_counted_base.hpp:36,
> from /usr/include/boost/smart_ptr/detail/shared_count.hpp:29,
> from /usr/include/boost/smart_ptr/shared_ptr.hpp:32,
> from /usr/include/boost/shared_ptr.hpp:17,
> from /usr/local/include/gnuradio/gr_types.h:27,
> from /usr/local/include/gnuradio/gr_runtime_types.h:27,
> from /usr/local/include/gnuradio/gr_basic_block.h:27,
> from /usr/local/include/gnuradio/gr_block.h:27,
> from ucla_cc1k_correlator_cb.h:25,
> from ucla.cc:4114:
> /usr/include/c++/4.6/typeinfo:42:37: error: expected '}' before end of line
> /usr/include/c++/4.6/typeinfo:42:37: error: expected declaration before end
> of line
> make[4]: *** [ucla.lo] Error 1
> make[4]: Leaving directory `/home/wlab/gr-ieee802-15-4/src/lib'
> make[3]: *** [all] Error 2
> make[3]: Leaving directory `/home/wlab/gr-ieee802-15-4/src/lib'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/home/wlab/gr-ieee802-15-4/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/wlab/gr-ieee802-15-4'
> make: *** [all] Error 2
>
> I think some libraries and dependencies are still missing. Any help will do
> from your end.
>
>
>
>
>
>
>
> ___
> 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] benchmark_rx n_right always 0
On Tue, Jun 5, 2012 at 11:47 AM, Weixian Zhou wrote: > I am using benchmark_tx/benchmark_rx to transmit data on 2.41GHz: > ./benchmark_rx.py -f 2.41G > ./benchmark_tx.py -f 2.41G > > While I can receive packages at the rx end, the n_right field of every > package is always 0. I know it means the package failed the CRC check. What > might be the cause? I am using two USRP N210s and daughter boards are > XCVR2450. The following are the displayed message at rx end: > belltestbed@belltestbed-OptiPlex-790:~/Desktop/gnuradio/gr-digital/exales/narrowband$ > ./benchmark_rx.py -f 2.41G > linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.002-128-g12f7a5c9 Hi Weixian, Remember that these benchmark examples have no error correcting codes in them, so a single bit error will cause the packet CRC check to fail. Likely reasons for this include low SNR, nonlinearities in the receiver/transmitter chain, and multipath channels. You might also have a frequency offset between the two USRPs that's just a bit outside of the channel filter's bandwidth such that you are distorting it enough to cause errors but not so much that many of the bits are still getting through. Tom ___ 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 Tue, Jun 5, 2012 at 1:49 PM, Josh Blum wrote:
>
>
> On 06/05/2012 09:39 AM, Josh Blum wrote:
>>
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
>>
>> Looks like volk isnt detecting your machine right... hmmm curious.
>
> All, we dont have an sse machine generated since there are no sse only
> kernels. So that should be expected.
>
>>
>> gr_fir_ccc: using 3DNow!Ext
>>> Using Volk machine: generic
>>> terminate called after throwing an instance of 'std::invalid_argument'
>>> what(): gr_block::volk_get_alignment
>>> Aborted
>>
>
> so volk_get_alignment() should be returning 1. Would that be a problem
> for volk_get_alignment in this particular block, Tom?
>
> -josh
Yep, it would cause this problem. That block uses VOLK, so it will try
to set the alignment property for the scheduler, which calls
set_alignment. That function checks to see if the multiple is less
than 1 and throws a: "throw std::invalid_argument
("gr_block::set_alignment_multiple");"
So yeah, with VOLK not handling that processor correctly, it looks
like it can't get the alignment right, either.
Would patching VOLK to return a minimum of 1 work, or is that just
masking a larger issue for these older processors?
Tom
___
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 06/05/2012 04:29 PM, Tom Rondeau wrote:
> On Tue, Jun 5, 2012 at 1:49 PM, Josh Blum wrote:
>>
>>
>> On 06/05/2012 09:39 AM, Josh Blum wrote:
>>>
> 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
>>>
>>> Looks like volk isnt detecting your machine right... hmmm curious.
>>
>> All, we dont have an sse machine generated since there are no sse only
>> kernels. So that should be expected.
>>
>>>
>>> gr_fir_ccc: using 3DNow!Ext
Using Volk machine: generic
terminate called after throwing an instance of 'std::invalid_argument'
what(): gr_block::volk_get_alignment
Aborted
>>>
>>
>> so volk_get_alignment() should be returning 1. Would that be a problem
>> for volk_get_alignment in this particular block, Tom?
>>
>> -josh
>
> Yep, it would cause this problem. That block uses VOLK, so it will try
> to set the alignment property for the scheduler, which calls
> set_alignment. That function checks to see if the multiple is less
> than 1 and throws a: "throw std::invalid_argument
> ("gr_block::set_alignment_multiple");"
>
> So yeah, with VOLK not handling that processor correctly, it looks
> like it can't get the alignment right, either.
>
> Would patching VOLK to return a minimum of 1 work, or is that just
> masking a larger issue for these older processors?
>
volk is fine, but this gives a 0
volk_get_alignment() / sizeof(gr_complex)
needs some std::max somewhere
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Regarding MIMO examples in TOM's Repo
On Tue, Jun 5, 2012 at 1:53 AM, bharadwaj desikan wrote: > Hi all, > > I am implementing a 2X2 mimo system using usrp2s. While looking through the > mail archives, > i came across a reference to a mimo system based on 'benchmark_ofdm_mimo' > from Tom Rondeau's > repository. How do i access this repository? > > Thanks in advance > > Regards > > Bharadwaj D Bharadwaj, Once you've git cloned gnuradio from gnuradio.org, you'll have to set up a remote for https://github.com/trondeau/gnuradio.git. You can then check out the 'ofdm' branch on that remote repo. (if you aren't very familiar with git, read this to see how the above is done: http://gnuradio.org/redmine/projects/gnuradio/wiki/DevelopingWithGit) Be cautioned that it's not in a stable or complete state. I believe others have worked on it and been successful in the past, though. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] crashes, memory errors and valgrind
On Tue, Jun 5, 2012 at 10:06 AM, Patrick Strasser wrote: > Tom Rondeau wrote on 2012-06-04 14:18: >> On Sun, Jun 3, 2012 at 2:22 PM, Patrick Strasser >> wrote: >>> Hi Tom, >>> >>> Tom Rondeau wrote on 2012-06-03 17:12: On Sat, Jun 2, 2012 at 5:50 AM, Patrick Strasser Patrick, It looks like you're problem is in the rational_resampler code. I wonder if there's something about the resampling rate being used that's causing something to go out of bounds here. Can you dig into the code and figure out what interpolation and decimation rates are being used? >>> >>> Interpolation is 1, decimation is 2. > >>> Full valgrind log in >>> http://pastebin.com/7GCs3bWy >> >> I was hoping you'd say the interpolation and/or decimation were some >> ridiculously large numbers. Since the block is only actually >> decimating, could you replace it in the code with an fir_filter_fff >> (or fft_filter_fff) just for testing purposes? That'll help us see if >> it's the rational resampler itself or something more general. > > What seems strange to me is the allocation of a buffer of a non by 8 > dividable size, that is accessed in blocks of 8 bytes. So the last read > always either does not touch the end of the buffer, or it reads beyond > the end. Sorry, Patrick, I think there was a typo or something in your first sentence, and I'm not sure I understood. But from the gist of it, yes, if the items used in a block have size 8, then the buffer allocation should be sized enough to handle an integer number of items. This is true because the scheduler sends the block noutput_items, which are the number of items to process (so the buffer size would be 8*noutput_items). > I'm a little sparse at time until Sunday evening. I tried to write some > mini program starting from dial_tone.cc which uses a filter, have to > convince cmake to compile it... learning ;-) > > Regards > > Patrick Thanks. Let us know how it goes. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-howto-write-a-block new documentation
On Tue, Jun 5, 2012 at 12:22 PM, wrote: > Hello all, > > Just one quick question. Does anybody know if we have a documentation for > the gr-howto-write-a-block with the new folder structure and cmake? > > The link given on the gnuradio.org is old. > http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html > > Thanks! > > Regards > Pranav Sakulkar > Student Assistant > Lehrstuhl für Theoretische Informationstechnik > RWTH Aachen Pranav, Thanks for pointing that out. Yes, that needs to be updated. We'll try to get to it soon. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG, current gr-howto structure and exception specifiers
On Tue, Jun 5, 2012 at 2:58 PM, Martin Braun wrote: > On Sun, Jun 03, 2012 at 10:22:14AM -0400, Tom Rondeau wrote: >> On the other hand, I thought all standard exceptions were passed >> properly through SWIG to Python already. I was under the impression >> that if you're header file declares that it throws, then you can catch >> it in Python. If that's not the case, then we should try to figure out >> an easy way to handle that. > > Hi Tom and rest, > > so, I didn't do my research properly (partly): Exceptions *are* caught by > SWIG, *but* they always end up as RuntimeErrors, regardless of what the > exception type was in C++. > > So, for future reference: > If you throw a std::invalid_argument in a block constructor, it ends > up as a RuntimeError in Python. If you hand-edit the SWIG file and add > an exception specifier, it ends up as a ValueError, which I think is the > better behaviour, and it would be great if SWIG did this automatically. > > But frankly, I don't think this is that big a deal, I'll just catch > RuntimeErrors instead of ValueErrors. Or edit .i-files. > > There's just no "clean" way to do this, because you'd either have to > specify the exceptions in the header (which is deprecated C++), write a > .i (redundant) or lose the exception type. > > MB Yeah, I remember looking at this a while ago (since there is still an error where FreeBSD treats one particular exception incorrectly). There are a few exceptions that are handled by SWIG, but mostly the C++ ones just get smashed into one or maybe two different exceptions in Python. I'm of the opinion that I agree that it's not a big deal. An exception might now be technically incorrect, but I think we can translate as needed. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using external clock references in GRC environment
On 06/05/2012 04:53 PM, Nazmul Islam wrote: > I have attached a screenshot that shows that way I am using the USRP:UHD > Sink block. I am running both of my USRP's with the same 10 MHz clock > signal. The clock signal is coming from a function generator. Therefore, I > have changed the clock source option in the USRP Sink block to be external. > > Unfortunately, I am getting wrong/strange outputs due to this change. Do I > need to make any other change in the flowgraph to make it work with > external clock source? > Please define "wrong/strange outputs". Is the device locked to the reference? ie, is the ref lock light on? http://files.ettus.com/uhd_docs/manual/html/usrp2.html#front-panel-leds > Thanks, > > Nazmul > > On Tue, Jun 5, 2012 at 4:31 PM, Nazmul Islam > wrote: > >> Hello, >> >> I am running two USRP2's with a 10 MHz external clock. I am using >> gnuradio-companion to transmit data between the USRP's. I have changed the >> *clock source* option as 'external' in the UHD:USRP Source & Sinc >> blocks. I kept the time source and clock rate block as default since I am >> not providing any external pps. >> >> Unfortunately, I am getting unexpected and wrong outputs. Do I need to >> make any other changes in the USRP Source & Sink options? >> >> >> Thanks, >> >> Nazmul >> >> >> >> >> -- >> Muhammad Nazmul Islam >> >> Graduate Student >> Electrical & Computer Engineering >> Wireless Information & Networking Laboratory >> Rutgers, USA. >> >> > > > > > ___ > 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] Question about OpenBTS
On 6/5/2012 10:01 PM, Pan, Luyuan wrote: On 2012/6/4 23:28, Thomas Tsou wrote: On Sun, Jun 3, 2012 at 9:49 AM, Pan, Luyuan wrote: Hello, I want to set up the OpenBTS, and I want to know which board is better, USRP1 or USRP2? Or any other suggestion? Thank you. Both USRP1 and USRP2 work with OpenBTS and neither can be considered "better" without describing your requirements. USRP2 / N2xx will support higher bandwidths with the GigE interface if that is important to you. USRP1 (or B100) will be cheaper. For stable clocking, the USRP1 requires hardware modification to support an external 52MHz clock signal. Other devices can use a more accessible internal or external 10 MHz reference source. Also, OpenBTS is not gnuradio, and the openbts-discuss or usrp-users lists may be better sources for that type of information. http://lists.sourceforge.net/lists/listinfo/openbts-discuss http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com Thomas Sorry, This may not the proper place to ask question about OpenBTS, But I just want to ask one more questions. My scenario is : I want to set up a BTS, scan the user nearby and get their IMSI, then attract them to my fake BTS and broadcast them a message. 1. I want to use USRP1 to do the project, Is it enough? (I have both of USRP1 and USRP2 at hand) 2. Is it that SMS-CB a better choice for me? (my ultimate goal is to broadcast some messages) Thank you for your help! Is it legal to do that? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] I thought we had squashed this one
Got a core dump this evening from this evenings GIT build. On a Fedora 12 machine (I know, horbly obsolete), on a Centrino M CPU: #0 0x003bb409 in volk_32fc_x2_multiply_32fc_a_sse3 () from /usr/local/lib/libvolk.so.0.0.0 #1 0x00396415 in get_volk_32fc_x2_multiply_32fc_a () from /usr/local/lib/libvolk.so.0.0.0 #2 0x0096b7e7 in gri_fft_filter_ccc_generic::filter(int, std::complex const*, std::complex*) () from /usr/local/lib/libgnuradio-core-3.6.1git.so.0.0.0 #3 0x00972a5b in gr_fft_filter_ccc::work(int, std::vector >&, std::vector >&) () from /usr/local/lib/libgnuradio-core-3.6.1git.so.0.0.0 #4 0x00942187 in gr_sync_decimator::general_work(int, std::vector >&, std::vector >&, std::vector >&) () from /usr/local/lib/libgnuradio-core-3.6.1git.so.0.0.0 #5 0x00929455 in gr_block_executor::run_one_iteration() () from /usr/local/lib/libgnuradio-core-3.6.1git.so.0.0.0 #6 0x00944bb3 in gr_tpb_thread_body::gr_tpb_thread_body(boost::shared_ptr, int) () from /usr/local/lib/libgnuradio-core-3.6.1git.so.0.0.0 #7 0x0093eecc in boost::detail::function::void_function_obj_invoker0, void>::invoke(boost::detail::function::function_buffer&) () from /usr/local/lib/libgnuradio-core-3.6.1git.so.0.0.0 #8 0x0031084c in boost::function0::operator()() const () from /usr/local/lib/libgruel-3.6.1git.so.0.0.0 Here's /proc/cpuinfo processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 14 model name: Genuine Intel(R) CPU T2400 @ 1.83GHz stepping: 8 cpu MHz: 1833.000 cache size: 2048 KB physical id: 0 siblings: 2 core id: 0 cpu cores: 2 apicid: 0 initial apicid: 0 fdiv_bug: no hlt_bug: no f00f_bug: no coma_bug: no fpu: yes fpu_exception: yes cpuid level: 10 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm bogomips: 3657.43 clflush size: 64 cache_alignment: 64 address sizes: 32 bits physical, 32 bits virtual power management: processor: 1 vendor_id: GenuineIntel cpu family: 6 model: 14 model name: Genuine Intel(R) CPU T2400 @ 1.83GHz stepping: 8 cpu MHz: 1833.000 cache size: 2048 KB physical id: 0 siblings: 2 core id: 1 cpu cores: 2 apicid: 1 initial apicid: 1 fdiv_bug: no hlt_bug: no f00f_bug: no coma_bug: no fpu: yes fpu_exception: yes cpuid level: 10 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm bogomips: 3657.52 clflush size: 64 cache_alignment: 64 address sizes: 32 bits physical, 32 bits virtual power management: Seems to have been provoked by replacing a regular FIR filter with an FFT filter (or rather, replacing 3 FIR filters with 3 FFT filters with the same "shape" as the FIR filters). Curiously enough, on Ubuntu 12.04 on *exactly the same hardware*, I don't have this problem, even with this evening's build. -- 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] Question about OpenBTS
If it's with his own phones it's a grey area, for others obviously it's not legal. USRP's can get into a grey area when not used as "Testing Equipment" pursuant to http://www.law.cornell.edu/cfr/text/47/15.121 . To answer your question, both USRP1 & 2 can handle the signal, so it's up to your preference. SMS-CB would most likely work for simple messages. On Tue, Jun 5, 2012 at 2:17 PM, hOWARD wONG wrote: > On 6/5/2012 10:01 PM, Pan, Luyuan wrote: >> >> On 2012/6/4 23:28, Thomas Tsou wrote: >>> >>> On Sun, Jun 3, 2012 at 9:49 AM, Pan, Luyuan wrote: Hello, I want to set up the OpenBTS, and I want to know which board is better, USRP1 or USRP2? Or any other suggestion? Thank you. >>> >>> Both USRP1 and USRP2 work with OpenBTS and neither can be considered >>> "better" without describing your requirements. USRP2 / N2xx will >>> support higher bandwidths with the GigE interface if that is important >>> to you. USRP1 (or B100) will be cheaper. For stable clocking, the >>> USRP1 requires hardware modification to support an external 52MHz >>> clock signal. Other devices can use a more accessible internal or >>> external 10 MHz reference source. >>> >>> Also, OpenBTS is not gnuradio, and the openbts-discuss or usrp-users >>> lists may be better sources for that type of information. >>> >>> http://lists.sourceforge.net/lists/listinfo/openbts-discuss >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>> Thomas >> >> Sorry, This may not the proper place to ask question about OpenBTS, But I >> just want to ask one more questions. My scenario is : I want to set up a >> BTS, scan the user nearby and get their IMSI, then attract them to my fake >> BTS and broadcast them a message. >> 1. I want to use USRP1 to do the project, Is it enough? (I have both of >> USRP1 and USRP2 at hand) >> 2. Is it that SMS-CB a better choice for me? (my ultimate goal is to >> broadcast some messages) >> Thank you for your help! > > > Is it legal to do that? > > > ___ > 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] gqrx branch osmosdr
Alexandru Csete wrote on 2012-06-05 19:06: > There is no audio filter yet (except de-emphasis) so you get pretty > much 48 kHz worth of noise, including stereo pilot tone and whatever > crap they include in a broadcast FM channel these days. I put in some debugging code near the filter tap calculations to see the resulting filters. Would be nice to display the real filter curve in the spectrum, with some infos like the cutoff frequencies, transistion width and number of taps (complexity), maybe next week I can play on that. Printing out the taps, pasting into an octave instance, fft and plotting was straigth forward. I love it when a plan comes together! 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] GRC - converting complex stream to vector for FFT
On 06/05/2012 11:38 PM, John Shields wrote: > Hi Josh, > It turns out I was using the block I think you were recommending. Here is a > picture of the flowgraph with the red arrow which would appear to be an issue > as, with it present, the flow graph will not execute. > vec length should be 1, thats referring to the input size. set num items to be the fft length > Kind Regards, > > John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC - converting complex stream to vector for FFT
On 06/06/12 18:40, Josh Blum wrote: On 06/05/2012 11:38 PM, John Shields wrote: Hi Josh, It turns out I was using the block I think you were recommending. Here is a picture of the flowgraph with the red arrow which would appear to be an issue as, with it present, the flow graph will not execute. vec length should be 1, thats referring to the input size. set num items to be the fft length Kind Regards, John Sorry Josh - had it backwards. When reversed, as you suggest, it works like charm. Thanks very much, Slainte, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
