Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
Hi Michael, I noticed something weird, and was wondering if you've come across this already when using qt-4.7 cocoa 32-bit only, qwt, qwtplot3d, sip and pyqt4, and building gnuradio, the linker incorrectly attempts to link to the Carbon libraries, h ../../../libtool --tag=CXX --mode=link g++ -g -O1 -Wno-strict-aliasing -Wno-parentheses -D_THREAD_SAFE -module -avoid-version-o _qtgui.la -rpath /usr/local/lib/python2.6/site-packages/gnuradio/qtgui _qtgui_la-qtgui.lo -lstdc++ libgnuradio-qtgui.la libtool: link: g++ -Wl,-undefined -Wl,dynamic_lookup -o .libs/_qtgui.so -bundle .libs/_qtgui_la-qtgui.o ./.libs/libgnuradio-qtgui.dylib -L/usr/local/lib -L/Developer/Applications/Qt-4.7/lib /Users/elvis/Tool/gnuradio/gnuradio-core/src/lib/.libs/libgnuradio-core.dylib /Users/elvis/Tool/gnuradio/gruel/src/lib/.libs/libgruel.dylib -lboost_thread /usr/local/lib/libfftw3f.dylib /usr/local/lib/libgsl.dylib /usr/local/lib/libgslcblas.dylib -lcblas -lstdc++ -lqwt -lqwtplot3d -lz -lm -Wl,-dylib_file -Wl,/usr/local/lib/libgnuradio-core-3.4git.0.dylib:/Users/elvis/Tool/gnuradio/gnuradio-core/src/lib/.libs/libgnuradio-core.dylib -Wl,-dylib_file -Wl,/usr/local/lib/libgruel-3.4git.0.dylib:/Users/elvis/Tool/gnuradio/gruel/src/lib/.libs/libgruel.dylib -Wl,-dylib_file -Wl,/usr/local/lib/libgruel-3.4git.0.dylib:/Users/elvis/Tool/gnuradio/gruel/src/lib/.libs/libgruel.dylib -framework QtOpenGL -framework QtGui -framework QtCore -framework AppKit -framework Carbon -framework OpenGL -framework AGL -framework ApplicationServices However, prior to the build, gnuradio configure correctly detects qwt headers checking /usr/local/include/qwt/qwt.h usability... yes checking /usr/local/include/qwt/qwt.h presence... yes checking for /usr/local/include/qwt/qwt.h... yes checking for main in -lqwt... yes checking /usr/local/include/qwtplot3d/qwt3d_plot.h usability... yes checking /usr/local/include/qwtplot3d/qwt3d_plot.h presence... yes checking for /usr/local/include/qwtplot3d/qwt3d_plot.h... yes checking for main in -lqwtplot3d-qt4... no checking for main in -lqwtplot3d... yes Now, thinking perhaps carbon was needed somehow, I rebuilt qt-4.7, qwt, qwtplot3d, sip and pyqt4 using carbon 32-bit only, but this time around it doesn't detect the qwt headers !! checking /usr/local/include/qwt/qwt.h usability... no checking /usr/local/include/qwt/qwt.h presence... no checking for /usr/local/include/qwt/qwt.h... no Could not find qwt headers Best regards, Elvis Dowson___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
Hi, Where can I control linker architecture flags to prevent the following errors? I've built qt, qwt and qwtplot3d for 32-bit mode, and with cocoa support. However, at link time, gnuradio is trying to link to x86_64. A little futher down, it is trying to link to the Carbon framework, whereas I've only built the Cocoa framework. libtool: link: g++ -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libgnuradio-qtgui-3.4git.0.dylib .libs/FrequencyDisplayPlot.o .libs/TimeDomainDisplayPlot.o .libs/WaterfallDisplayPlot.o .libs/Waterfall3DDisplayPlot.o .libs/waterfallGlobalData.o .libs/ConstellationDisplayPlot.o .libs/spectrumdisplayform.o .libs/SpectrumGUIClass.o .libs/spectrumUpdateEvents.o .libs/plot_waterfall.o .libs/qtgui_sink_c.o .libs/qtgui_sink_f.o /Users/elvis/Tool/gnuradio/gnuradio-core/src/lib/.libs/libgnuradio-core.dylib -L/usr/local/lib /Users/elvis/Tool/gnuradio/gruel/src/lib/.libs/libgruel.dylib -lboost_thread /usr/local/lib/libfftw3f.dylib /usr/local/lib/libgsl.dylib /usr/local/lib/libgslcblas.dylib -lcblas -lstdc++ -lqwt -lqwtplot3d -framework QtOpenGL -framework QtGui -framework QtCore -framework AppKit -framework Carbon -framework OpenGL -framework AGL -framework ApplicationServices -L/Developer/Applications/Qt-4.7/lib -lz -lm -F/Developer/Applications/Qt-4.7/lib -Wl,-dylib_file -Wl,/usr/local/lib/libgruel-3.4git.0.dylib:/Users/elvis/Tool/gnuradio/gruel/src/lib/.libs/libgruel.dylib -framework QtOpenGL -framework QtGui -framework QtCore -framework AppKit -framework Carbon -framework OpenGL -framework AGL -framework ApplicationServices -install_name /usr/local/lib/libgnuradio-qtgui-3.4git.0.dylib -compatibility_version 1 -current_version 1.0 -Wl,-single_module ld: warning: in /usr/local/lib/libqwt.dylib, file was built for i386 which is not the architecture being linked (x86_64) /bin/sh ../../../libtool --tag=CXX --mode=link g++ -g -O1 -Wno-strict-aliasing -Wno-parentheses -D_THREAD_SAFE -module -avoid-version -o _qtgui.la -rpath /usr/local/lib/python2.6/site-packages/gnuradio/qtgui _qtgui_la-qtgui.lo -lstdc++ libgnuradio-qtgui.la libtool: link: g++ -Wl,-undefined -Wl,dynamic_lookup -o .libs/_qtgui.so -bundle .libs/_qtgui_la-qtgui.o ./.libs/libgnuradio-qtgui.dylib -L/usr/local/lib -L/Developer/Applications/Qt-4.7/lib /Users/elvis/Tool/gnuradio/gnuradio-core/src/lib/.libs/libgnuradio-core.dylib /Users/elvis/Tool/gnuradio/gruel/src/lib/.libs/libgruel.dylib -lboost_thread /usr/local/lib/libfftw3f.dylib /usr/local/lib/libgsl.dylib /usr/local/lib/libgslcblas.dylib -lcblas -lstdc++ -lqwt -lqwtplot3d -lz -lm -Wl,-dylib_file -Wl,/usr/local/lib/libgnuradio-core-3.4git.0.dylib:/Users/elvis/Tool/gnuradio/gnuradio-core/src/lib/.libs/libgnuradio-core.dylib -Wl,-dylib_file -Wl,/usr/local/lib/libgruel-3.4git.0.dylib:/Users/elvis/Tool/gnuradio/gruel/src/lib/.libs/libgruel.dylib -Wl,-dylib_file -Wl,/usr/local/lib/libgruel-3.4git.0.dylib:/Users/elvis/Tool/gnuradio/gruel/src/lib/.libs/libgruel.dylib -framework QtOpenGL -framework QtGui -framework QtCore -framework AppKit -framework Carbon -framework OpenGL -framework AGL -framework ApplicationServices ld: framework not found QtOpenGL collect2: ld returned 1 exit status Best regards, Elvis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-trellis : problem in using viterbi decoder
you will have to make the constellation a 2D array (essentially representing
the 2 BPSK symbols).
It is all explained in the examples and the documentation of gr-trellis and
in the examples...
please read it; i spend a lot of time writing it...
Achilleas
On Mon, Jul 19, 2010 at 8:19 PM, Raman O wrote:
> Hello Achilleas,
>
> I made changes to vector source and sink, encoding works fine with
> awgn1o2_128.fsm.
>
> But the result of encoder is 2 bit packed and is not suitable for me.
> Since i want to employ BPSK modulation (0-> -1 / 1 ->1), I need encoder
> output 1 bit at a time.
>
> Since awgn1o2_128.fsm dictates numInputbits: 2 andnumOutputbits: 4 ,
> Modulator throws following error. If i am not wrong it says, constellation
> length is not enough.
>
> lt-director: gr_chunks_to_symbols_sf.cc:66: virtual int
> gr_chunks_to_symbols_sf::work(int, gr_vector_const_void_star&,
> gr_vector_void_star&): Assertion `((unsigned int)in[i]*d_D+d_D) <=
> d_symbol_table.size()' failed.
> Aborted
>
> I am using following Constellation:
> std::vector constellation;
>
>constellation.push_back(1);
>constellation.push_back(-1);
>
> So how do i achieve BPSK modulation with encoder using generator poly in
> awgn1o2_128.fsm.
>
> Many many thanks,
> Ram
>
>
>
> --- On *Mon, 19/7/10, Achilleas Anastasopoulos * wrote:
>
>
> From: Achilleas Anastasopoulos
> Subject: Re: [Discuss-gnuradio] gr-trellis : problem in using viterbi
> decoder
> To: "Raman O" , discuss-gnuradio@gnu.org
> Date: Monday, 19 July, 2010, 9:50 PM
>
>
> As I mentioned in my earlier email, you have misunderstood the
> functionality of the
>
> gr_make_vector_source_s(vec,false)
>
> block. It takes a vector "vec" as an argument and produces A STREAM OF
> SHORTS at its output!!!
> It is NOT producing a stream of vectors at its output...unless you specify
> this as the third parameter,
> which has nothing to do with the size of the input vector "vec" you are
> using...
>
> Please remove both stream2vector and vector2stream from your code and
> modify the statement
>
> gr_vector_source_s_sptr bit_src = gr_make_vector_source_s(in_bits,false,K );
>
> as
>
> gr_vector_source_s_sptr bit_src = gr_make_vector_source_s(in_bits,false);
>
> Please see the python program test_tcm1.py in the gr-trellis/src/examples
> directory to see
> how the blocks are arranged...
>
> best,
> Achilleas
>
>
> On Mon, Jul 19, 2010 at 4:19 PM, Raman O
> http://mc/compose?to=gnuma...@yahoo.com>
> > wrote:
>
>> Hello Achilleas,
>>
>> Thanks for your response.
>> I have connected encoder block , it disappeared during editing mail by
>> mistake.
>>
>> Input is in the form of an array of size K and vector2stream feeds encoder
>> bit a time ,so i am using following syntax :
>>
>> gr_vector_source_s_sptr bit_src = gr_make_vector_source_s(in_bits,false,K );
>>
>> gr_vector_to_stream_sptr vector2stream =
>> gr_make_vector_to_stream(sizeof(short),K)
>>
>>
>>
>>
>> int K=100;
>> short inputbits[100]={ contains bits };
>> std::vector in_bits;
>>
>> for (int i = 0; i > of bits
>> in_bits.push_back(inputbits[i]); // input bits
>> }
>> std::vector constellation; // BPSK mapping
>>
>> constellation.push_back(1);
>>constellation.push_back(-1);
>>
>>
>>
>> gr_vector_source_s_sptr bit_src =
>> gr_make_vector_source_s(in_bits,false,K );
>>
>>
>> gr_vector_to_stream_sptr vector2stream=
>> gr_make_vector_to_stream(sizeof(short),K);
>>
>>
>> // encoder
>>fsm f=
>> fsm("../../../gr-trellis/src/examples/fsm_files/awgn1o2_128.fsm");
>>trellis_encoder_ss_sptr encoder = trellis_make_encoder_ss (f, 0);
>>
>> // modulate
>> gr_chunks_to_symbols_sf_sptr mod = gr_make_chunks_to_symbols_sf
>>
>> (constellation, 1);
>>
>> // --- ideal channel -
>>
>> // decoder
>>
>> trellis_metric_type_t type= TRELLIS_EUCLIDEAN;
>> trellis_metrics_f_sptr metrics = trellis_make_metrics_f (f.O(), 1,
>> constellation, type);
>>
>> trellis_viterbi_s_sptr viterbi =trellis_make_viterbi_s ( f,K, 0,-1);
>>
>> gr_stream_to_vector_sptr stream2vector=
>> gr_make_stream_to_vector(sizeof(short), K);
>> d_dst = gr_make_vector_sink_s (K);
>>
>>
>> connect( bit_src , 0, vector2stream, 0);
>>
>> connect( vector2stream , 0,encoder, 0);
>> connect( encoder , 0,mod, 0);
>>
>> connect(mod, 0,metrics,
>>
>> 0);
>> connect(metrics, 0, viterbi, 0);
>> connect( viterbi, 0,stream2vector, 0);
>> connect(stream2vector, 0, d_dst, 0);
>>
>>
>>
>>
>> --- On *Mon, 19/7/10, Achilleas Anastasopoulos
>> http://mc/compose?to=anas...@umich.edu>
>> >* wrote:
>>
>>
>> From: Achilleas Anastasopoulos
>> http://mc/compose?to=anas...@umich.edu>
>> >
>> Subject: Re: [Discuss-gnuradio] gr-trellis : problem in using
[Discuss-gnuradio] gr-trellis : problem in using viterbi decoder
Hello Achilleas,
I made changes to vector source and sink, encoding works fine with
awgn1o2_128.fsm.
But the result of encoder is 2 bit packed and is not suitable for me.
Since i want to employ BPSK modulation (0-> -1 / 1 ->1), I need encoder output
1 bit at a time.
Since awgn1o2_128.fsm dictates numInputbits: 2 and numOutputbits: 4 ,
Modulator throws following error. If i am not wrong it says, constellation
length is not enough.
lt-director: gr_chunks_to_symbols_sf.cc:66: virtual int
gr_chunks_to_symbols_sf::work(int, gr_vector_const_void_star&,
gr_vector_void_star&): Assertion `((unsigned int)in[i]*d_D+d_D) <=
d_symbol_table.size()' failed.
Aborted
I am using following Constellation:
std::vector constellation;
constellation.push_back(1);
constellation.push_back(-1);
So how do i achieve BPSK modulation with encoder using generator poly in
awgn1o2_128.fsm.
Many many thanks,
Ram
--- On Mon, 19/7/10, Achilleas Anastasopoulos wrote:
From: Achilleas Anastasopoulos
Subject: Re: [Discuss-gnuradio] gr-trellis : problem in using viterbi decoder
To: "Raman O" , discuss-gnuradio@gnu.org
Date: Monday, 19 July, 2010, 9:50 PM
As I mentioned in my earlier email, you have misunderstood the functionality of
the
gr_make_vector_source_s(vec,false)
block. It takes a vector "vec" as an argument and produces A STREAM OF SHORTS
at its output!!!
It is NOT producing a stream of vectors at its output...unless you specify this
as the third parameter,
which has nothing to do with the size of the input vector "vec" you are using...
Please remove both stream2vector and vector2stream from your code and modify
the statement
gr_vector_source_s_sptr bit_src = gr_make_vector_source_s(in_bits,false,K );
as
gr_vector_source_s_sptr bit_src = gr_make_vector_source_s(in_bits,false);
Please see the python program test_tcm1.py in the gr-trellis/src/examples
directory to see
how the blocks are arranged...
best,
Achilleas
On Mon, Jul 19, 2010 at 4:19 PM, Raman O wrote:
Hello Achilleas,
Thanks for your response.
I have connected encoder block , it disappeared during editing mail by mistake.
Input is in the form of an array of size K and vector2stream feeds encoder bit
a time ,so i am using following syntax :
gr_vector_source_s_sptr bit_src = gr_make_vector_source_s(in_bits,false,K );
gr_vector_to_stream_sptr vector2stream =
gr_make_vector_to_stream(sizeof(short),K)
int K=100;
short inputbits[100]={ contains bits };
std::vector in_bits;
for (int i = 0; i constellation; // BPSK mapping
constellation.push_back(1);
constellation.push_back(-1);
gr_vector_source_s_sptr bit_src =
gr_make_vector_source_s(in_bits,false,K );
gr_vector_to_stream_sptr vector2stream=
gr_make_vector_to_stream(sizeof(short),K);
// encoder
fsm f=
fsm("../../../gr-trellis/src/examples/fsm_files/awgn1o2_128.fsm");
trellis_encoder_ss_sptr encoder = trellis_make_encoder_ss (f, 0);
// modulate
gr_chunks_to_symbols_sf_sptr mod = gr_make_chunks_to_symbols_sf
(constellation, 1);
// --- ideal channel -
// decoder
trellis_metric_type_t type= TRELLIS_EUCLIDEAN;
trellis_metrics_f_sptr metrics = trellis_make_metrics_f (f.O(), 1,
constellation, type);
trellis_viterbi_s_sptr viterbi =trellis_make_viterbi_s ( f,K, 0,-1);
gr_stream_to_vector_sptr stream2vector=
gr_make_stream_to_vector(sizeof(short), K);
d_dst = gr_make_vector_sink_s (K);
connect( bit_src , 0, vector2stream, 0);
connect( vector2stream , 0,encoder, 0);
connect( encoder , 0,mod, 0);
connect(mod, 0,metrics,
0);
connect(metrics, 0, viterbi, 0);
connect( viterbi, 0,stream2vector, 0);
connect(stream2vector, 0, d_dst, 0);
--- On Mon, 19/7/10, Achilleas Anastasopoulos wrote:
From: Achilleas Anastasopoulos
Subject: Re: [Discuss-gnuradio] gr-trellis : problem in using viterbi decoder
To: "gnuradio
mailing list" , gnuma...@yahoo.com
Date: Monday, 19 July, 2010, 6:47 PM
I also realized that the way you call
gr_make_vector_source_s(in_bits,false,K );
is incorrect.
I think you have misunderstood what this block does.
You should
use:
gr_make_vector_source_s(in_bits,false,1 );
or simply
gr_make_vector_source_s(in_bits,false);
and you really don't need the vector2stream block.
Achilleas
-
In your code the "encoder" block is not connected to any other block...
It should be:
info bits -> encoder -> modulator -> channel -> metrics -> viterbi
Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Inband signaling and m-blocks for Frequency Hopping
Hi, All, In my current design, frequency hopping is designed to happen over 32MHz bandwidth, as fast as possible. (although I admit that by using USRP1, it may not be that fast as I expected). However, I am not very clear about how to do so. I checked the implementation of bluetooth (gr-bluetooth-0.4) but did not get any ideas/examples/instances of FH. (Someone interested in bluetooth is recommended to have a look at this.) I did create a piece of code (as shown below) following usrp_spectrum_sense.py. However, .tune() gives me a huge and unfavorable delay time. Is there any better way to impalement FH? . def set_freq(self): target_freq = 900e6 + 3.2e6 * random.randint(1, 10) self.rx.tune(0, self.rx_subdev, target_freq) while 1: time.sleep(0.3) # Wait fg.set_freq() . BTW, I read considerable messages from the Mail Archive, and realized that inband signaling and m-blocks is an ideal solution for FH. Does anyone have any examples/codes/documents/suggestions regarding the inband signaling and m-blocks for FH? Thanks a lot! -- -- Best Regards (Raullen) Qi Chai The highest excellence is like that of water! www.raullen.net -- -- Best Regards (Raullen) Qi Chai The highest excellence is like that of water! www.raullen.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to change C++ source code and add to binary library
Hi, I have installed the GNU Radio Debian binary library (3.2.2) on my laptop running Ubuntu 10.04. Is there an easy way for me to make minor changes to the C++ source codes and add it to the binary library? Thank you, Tuan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM receiver on USRP2
Sorry for bringing up an old thread. I was having the same problem of not receiving packets using benchmark_ofdm_* and changing the receiver frequency to tune to the transmitter frequency indeed solved the problem. However, if I have to manually do it every time, I don't see how I can get ofdm tunnel to work. In tunnel, each USRP is both transmitter and receiver. The frequency offset of one USRP (A) transmitting to the other (B) will be different than B transmitting to A. Since the frequency offset can't be set at run time, I don't see how to manually tune after running tunnel on both USRPs. Can anyone show me how to make tunnel work? Thank you very much, Tuan On 2/20/2010 7:43 PM, Srinivas wrote: Hi Tom, I tried increasing the bandwidth of the filter and also tried changing the window type to KAISER, but it didn't improve on the offset error. I am getting a constant frequency offset value "-10". Currently, I am just compensating for the offset at the receiver or specifying a minimum BW to be used for that pair of USRP2s. Thanks a lot for your time. Srinivas Changing the window type isn't going to help much with this problem. What I was suggesting was that the filter is too small, not the wrong type. Also, the only way to change the offset value is to actually move the frequency. I was just suggesting that you see what that value is to see how many bins you are off by (i.e., calculate the bandwidth of a subcarrier and multiply that by 10; that's you're coarse offset). You can use that to see how much bigger to make the channel filter's bandwidth. Tom On Thu, Feb 18, 2010 at 9:45 AM, Tom Rondeau wrote: > On Thu, Feb 18, 2010 at 12:49 AM, Srinivas wrote: > > Hi Tom, Matt > > > > replied inline: > > > > On Wed, Feb 17, 2010 at 10:26 AM, Tom Rondeau > > wrote: > >> > >> On Tue, Feb 16, 2010 at 5:45 PM, Srinivas wrote: > >> > Matt, > >> > > >> > Thanks for verifying the data rate calculation! > >> > > >> > I tried the other solutions that you suggested, namely, > >> > > >> > - increasing the data rate by a factor of 2 or 4 > >> > It works. > >> > > >> > - modifying the OFDM code to widen the search range - How do I widen > the > >> > search range ? > >> > Should I be looking in the "ofdm_sync_" blocks in "blks2impl" folder ? > >> > If > >> > yes, which synchronizer is currently used with ofdm_examples ? > >> > >> You need to add an argument to gr.ofdm_frame_acquisition in > >> ofdm_receiver.py (in python/gnuradio/blks2impl). > >> > >> In the current Git master, this is located on line 109 of > >> ofdm_receiver.py. After the "ks[0]" argument, you can put in an > >> integer. This is the maximum number of bins the receiver will search > >> over for correlation. It defaults to 10. > >> > > I added this extra argument and tried changing the values from 10 to 100. > I > > also tried with "int(0.5*occupied_tones) " as the argument, but it > doesn't > > receive for lower data rates (< 1M). Only when I increase the data rate > > > 1.2M, I start receiving some pkts. > > > > As mentioned before, when I compensate for the frequency offset at the > > receiver it starts receiving packets successfully too. > > For small bandwidths, it's possible that the frequency offset has > pushed you outside of the channel filter. The filter is probably > specified too tight and is really supposed to cover only the occupied > tones, so if you're too far away from the center frequency, the > filter's already hitting it and no amount of frequency correction > after that will work. > > In ofdm_receiver.py, try making the bandwidth term (bw on line 66) > wider and see what that does for you. > > Also, you can print out d_coarse_freq calculated on line 130 in > gr_ofdm_frame_acquisition.cc. This is the number of bins you're off by > that you can use to get a feel for how far away in frequency you are. > > If opening up the filter works for you, please let us know. We might > want to either parameterize the bandwidth or just set it wider by > default. > > Tom > -- Srinivas WINLAB, Rutgers University New Jersey ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-trellis : problem in using viterbi decoder
As I mentioned in my earlier email, you have misunderstood the functionality
of the
gr_make_vector_source_s(vec,false)
block. It takes a vector "vec" as an argument and produces A STREAM OF
SHORTS at its output!!!
It is NOT producing a stream of vectors at its output...unless you specify
this as the third parameter,
which has nothing to do with the size of the input vector "vec" you are
using...
Please remove both stream2vector and vector2stream from your code and modify
the statement
gr_vector_source_s_sptr bit_src = gr_make_vector_source_s(in_bits,false,K );
as
gr_vector_source_s_sptr bit_src = gr_make_vector_source_s(in_bits,false);
Please see the python program test_tcm1.py in the gr-trellis/src/examples
directory to see
how the blocks are arranged...
best,
Achilleas
On Mon, Jul 19, 2010 at 4:19 PM, Raman O wrote:
> Hello Achilleas,
>
> Thanks for your response.
> I have connected encoder block , it disappeared during editing mail by
> mistake.
>
> Input is in the form of an array of size K and vector2stream feeds encoder
> bit a time ,so i am using following syntax :
>
> gr_vector_source_s_sptr bit_src = gr_make_vector_source_s(in_bits,false,K );
>
> gr_vector_to_stream_sptr vector2stream =
> gr_make_vector_to_stream(sizeof(short),K)
>
>
>
>
> int K=100;
> short inputbits[100]={ contains bits };
> std::vector in_bits;
>
> for (int i = 0; i of bits
> in_bits.push_back(inputbits[i]); // input bits
> }
> std::vector constellation; // BPSK mapping
>
> constellation.push_back(1);
>constellation.push_back(-1);
>
>
> gr_vector_source_s_sptr bit_src =
> gr_make_vector_source_s(in_bits,false,K );
>
> gr_vector_to_stream_sptr vector2stream=
> gr_make_vector_to_stream(sizeof(short),K);
>
> // encoder
>fsm f=
> fsm("../../../gr-trellis/src/examples/fsm_files/awgn1o2_128.fsm");
>trellis_encoder_ss_sptr encoder = trellis_make_encoder_ss (f, 0);
>
> // modulate
> gr_chunks_to_symbols_sf_sptr mod = gr_make_chunks_to_symbols_sf
> (constellation, 1);
>
> // --- ideal channel -
>
> // decoder
>
> trellis_metric_type_t type= TRELLIS_EUCLIDEAN;
> trellis_metrics_f_sptr metrics = trellis_make_metrics_f (f.O(), 1,
> constellation, type);
> trellis_viterbi_s_sptr viterbi =trellis_make_viterbi_s ( f,K, 0,-1);
>
> gr_stream_to_vector_sptr stream2vector=
> gr_make_stream_to_vector(sizeof(short), K);
> d_dst = gr_make_vector_sink_s (K);
>
> connect( bit_src , 0, vector2stream, 0);
>
> connect( vector2stream , 0,encoder, 0);
> connect( encoder , 0,mod, 0);
>
> connect(mod, 0,metrics,
> 0);
> connect(metrics, 0, viterbi, 0);
> connect( viterbi, 0,stream2vector, 0);
> connect(stream2vector, 0, d_dst, 0);
>
>
>
>
> --- On *Mon, 19/7/10, Achilleas Anastasopoulos * wrote:
>
>
> From: Achilleas Anastasopoulos
> Subject: Re: [Discuss-gnuradio] gr-trellis : problem in using viterbi
> decoder
> To: "gnuradio mailing list" , gnuma...@yahoo.com
> Date: Monday, 19 July, 2010, 6:47 PM
>
>
>
>
> I also realized that the way you call
> gr_make_vector_source_s(in_bits,false,K );
> is incorrect.
> I think you have misunderstood what this block does.
>
> You should use:
> gr_make_vector_source_s(in_bits,false,1 );
> or simply
> gr_make_vector_source_s(in_bits,false);
> and you really don't need the vector2stream block.
>
> Achilleas
>
>
>
> -
> In your code the "encoder" block is not connected to any other block...
>
> It should be:
>
> info bits -> encoder -> modulator -> channel -> metrics -> viterbi
>
> Achilleas
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
On Jul 20, 2010, at 12:56 AM, Michael Dickens wrote: > (1) On Jul 19, 2010, at 12:57 PM, Elvis Dowson wrote: >> One of the things that the guys working on GTK+ mentioned was that you >> should completely uninstall MacPorts ... > > versus (2) < http://sourceforge.net/apps/trac/gtk-osx/wiki/Build > > >> If you have MacPorts or Fink installed, you must remove all traces of them >> from your environment > > * "Removing all traces from your environment" means configuring your terminal > shell so that it does not use MacPorts or Fink in any capacity. In general, > that means removing /opt/local or /sw from all environment variables -- or, > as they recommend, just started from a fresh user setup since it won't > reference /opt or /sw . > > * "Completely uninstall MacPorts" mean (effectively) "sudo rm -rf > /opt/local", which is a draconian solution just to get gtk2 running under > quartz. I think most of us OSX developers rely to some degree on MacPorts or > Fink, so this isn't a practical solution. > You're right, of course :-) I didn't think of that! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
Ah; a subtle, but important, difference in phrasing between that needs
to be pointed out for those who might be thinking of doing GTK2+Quartz
on OSX:
(1) On Jul 19, 2010, at 12:57 PM, Elvis Dowson wrote:
One of the things that the guys working on GTK+ mentioned was that
you should completely uninstall MacPorts ...
versus (2) < http://sourceforge.net/apps/trac/gtk-osx/wiki/Build >
If you have MacPorts or Fink installed, you must remove all traces
of them from your environment
* "Removing all traces from your environment" means configuring your
terminal shell so that it does not use MacPorts or Fink in any
capacity. In general, that means removing /opt/local or /sw from all
environment variables -- or, as they recommend, just started from a
fresh user setup since it won't reference /opt or /sw .
* "Completely uninstall MacPorts" mean (effectively) "sudo rm -rf /opt/
local", which is a draconian solution just to get gtk2 running under
quartz. I think most of us OSX developers rely to some degree on
MacPorts or Fink, so this isn't a practical solution.
---
also of note, if you do use MacPorts, you can do "port info gtk2
+quartz +no_x11":
{{{
gtk2 @2.20.1
Variants: +no_x11, +quartz, universal, x11
Description: This is GTK+ version 2.x. GTK+, which stands for
Gimp
ToolKit, is a library for creating GUIs for the
X Windows
System.
Homepage: http://www.gtk.org/
Build Dependencies: pkgconfig
Library Dependencies: tiff, jasper, atk, pango, gettext
Runtime Dependencies: shared-mime-info
}}}
which certainly implies to me that the MacPorts folks have figured out
a way to get the quartz version working without either of the options
mentioned above. I haven't tried this variant of GTK2, but it's good
to know that it's there & maybe I will try it in the future sometime.
- MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 write_gpio() command
On Mon, Jul 19, 2010 at 12:18:06PM -0600, Ryan L. Buffington wrote:
> I'm trying to use one of the GPIO pins on my USRP 2 / WBX daughtercard to
> control an external antenna selector box. I've created a simple GUI with a
> USRP2 source feeding into a graphical FFT sink, and I'm able to change the
> state of io_tx_14 using the following code:
>
> #this code is called when the program is started
> self.gr_null_sink_0 = gr.null_sink(gr.sizeof_gr_complex*1)
> self.howto_rx_gpio_0 = usrp2.source_32fc()
> self.howto_rx_gpio_0.set_decim(decimation)
> self.howto_rx_gpio_0.set_center_freq(frequency)
> self.howto_rx_gpio_0.set_gain(daughtercard_gain)
> self.howto_rx_gpio_0.set_gpio_ddr(0x, 0b0100) #set the DDR
> self.howto_rx_gpio_0.set_gpio_sels(".s..") #set the output
> selection register
>
>
>
> #this code is called when the checkbox on the GUI is changed
> def set_check(self, check):
> self.check = check
> self._check_check_box.set_value(self.check)
> self.howto_rx_gpio_0.write_gpio(self.check * 2**14, 0x)
The above line sets the value of 16-bits, most likely screwing up the
daughterboard configuration.
You most likely want something like:
self.howto_rx_gpio_0.write_gpio(self.check * 2**14, 1 << 14)
Note, I haven't looked to see if bit 14 is a valid user bit on the
daughterboard you're using. You should :-)
> The problem is that whenever I change the value of the checkbox, the
> FFT sink freezes and stops displaying new values, or it begins
> displaying garbage at like -300 dB. The pin continues to change from
> high to low just fine even after the FFT sink stops updating. I've
> tried restarting the source using the stop() and start() commands,
> but this does not help. The problem is not unique to the FFT sink -
> applying the same code to a working NBFM receiver causes the audio
> sink to start playing popping sounds. I considered using gr-gpio,
> but this requires custom firmware, and I'm already running custom
> firmware to support my WBX daughtercard. Does anyone have any ideas?
> -- Ryan
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
Hi, On Jul 19, 2010, at 11:48 PM, Michael Dickens wrote: > Use the provided 'bootstrap' routine, but remember to change the 'libtoolize' > call to 'glibtoolize' or whatever you named that function on the version you > installed yourself. If you used MacPorts to install GNU Libtool (of which > 'libtoolize' is a part), then it prepended the 'g' for you. I downloaded and installed GNU M4, and switched to autoconf-2.65 running the ./bootstrap routine worked, and now ./configure is build fine. Best regards, Elvis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] debugging code for seeing what threads are created
On Mon, Jul 19, 2010 at 06:46:05PM +0100, Alex wrote: > Hi, > my name is Alexandru Buda, and I'm doing a project in college based on > GNU Radio. > > I'm using the environment variable GR_SCHEDULER to enable/disable > multi-threading > for benchmarking purposes and also the linux command "ps" to see the > threads created. > This unfortunately only gives me the number of threads and no more > detail as to what > each one is doing. Please read the ps man page and pick options that will show you detail information on all the threads. > A few years ago my supervisor did some work with GNU Radio (3.1.2 and > 3.1.3) and used the variable > GR_TOP_BLOCK_IMPL_DEBUG from > gnuradio-core/src/lib/runtime/gr_top_block_impl.cc > to see what threads are created but it seems that the code using > GR_TOP_BLOCK_IMPL_DEBUG > has been removed. > > Is there any debugging variables that I can enable or how do I see > extra information available about my running > waveform? > Or is there a linux/python tool that will give me more information > about the threads? Not exactly sure what you're looking for, but when using the thread-per-block scheduler, there will be one thread created per block. > Not sure if this is relevant but I'm using GNU Radio 3.2.2 built from > source on Ubuntu 10.04 32bit > > > Any information would be greatly appreciated > > Thank you > Alex Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-trellis : problem in using viterbi decoder
Hello Achilleas,
Thanks for your response.
I have connected encoder block , it disappeared during editing mail by mistake.
Input is in the form of an array of size K and vector2stream feeds encoder bit
a time ,so i am using following syntax :
gr_vector_source_s_sptr bit_src = gr_make_vector_source_s(in_bits,false,K );
gr_vector_to_stream_sptr vector2stream =
gr_make_vector_to_stream(sizeof(short),K)
int K=100;
short inputbits[100]={ contains bits };
std::vector in_bits;
for (int i = 0; i constellation; // BPSK mapping
constellation.push_back(1);
constellation.push_back(-1);
gr_vector_source_s_sptr bit_src =
gr_make_vector_source_s(in_bits,false,K );
gr_vector_to_stream_sptr vector2stream=
gr_make_vector_to_stream(sizeof(short),K);
// encoder
fsm f=
fsm("../../../gr-trellis/src/examples/fsm_files/awgn1o2_128.fsm");
trellis_encoder_ss_sptr encoder = trellis_make_encoder_ss (f, 0);
// modulate
gr_chunks_to_symbols_sf_sptr mod = gr_make_chunks_to_symbols_sf
(constellation, 1);
// --- ideal channel -
// decoder
trellis_metric_type_t type= TRELLIS_EUCLIDEAN;
trellis_metrics_f_sptr metrics = trellis_make_metrics_f (f.O(), 1,
constellation, type);
trellis_viterbi_s_sptr viterbi =trellis_make_viterbi_s ( f,K, 0,-1);
gr_stream_to_vector_sptr stream2vector=
gr_make_stream_to_vector(sizeof(short), K);
d_dst = gr_make_vector_sink_s (K);
connect( bit_src , 0, vector2stream, 0);
connect( vector2stream , 0,encoder, 0);
connect( encoder , 0,mod, 0);
connect(mod, 0,metrics,
0);
connect(metrics, 0, viterbi, 0);
connect( viterbi, 0,stream2vector, 0);
connect(stream2vector, 0, d_dst, 0);
--- On Mon, 19/7/10, Achilleas Anastasopoulos wrote:
From: Achilleas Anastasopoulos
Subject: Re: [Discuss-gnuradio] gr-trellis : problem in using viterbi decoder
To: "gnuradio mailing list" , gnuma...@yahoo.com
Date: Monday, 19 July, 2010, 6:47 PM
I also realized that the way you call
gr_make_vector_source_s(in_bits,false,K );
is incorrect.
I think you have misunderstood what this block does.
You should
use:
gr_make_vector_source_s(in_bits,false,1 );
or simply
gr_make_vector_source_s(in_bits,false);
and you really don't need the vector2stream block.
Achilleas
-
In your code the "encoder" block is not connected to any other block...
It should be:
info bits -> encoder -> modulator -> channel -> metrics -> viterbi
Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Understanding USRP2 flow control
On Sun, Jul 18, 2010 at 06:50:47PM +0200, OE1RSA wrote: > Dear All! > > I am starting to learn my new USRP2 device. > I bought a reasonable fast quad core PC and > a recommended ethernet board. > > I wanted to find out if I can get the interpolation 4 > working in my environment. I just connect a sine > oszillator to the usrp2 sink. > > I am observing the signal on a connected scope. > > Everything works fine for a while, but then suddenly > the output becomes heavily distorted. > > I can see from the resource watch of the system > monitor that my PC putting out data at a sustained > rate of more than 800 Mbits/sec. > > I started to try to understand the code in > gnuradio/usrp2/host/lib and expected some flow control > when the usrp2 input buffers are nearly full . > Unfortunately I was not able to understand how this > is implemented. > > Is there any flow control at all? > If not, what is supposed to happen, if the PC is > sending (slightly) too fast? > > Appreciating any information on this subject, > Roland Flow control is handled at the link level using ethernet PAUSE frames. Be sure to enable real-time scheduling by calling if gr.enable_realtime_scheduling() != gr.RT_OK: print "Note: failed to enable realtime scheduling, continuing" before starting or running the flow graph. If you haven't already, ensure that /etc/security/limits.conf contains this line: @usrp- rtprio 50 and that you are a member of group "usrp". [...@octo ~]$ groups eb wheel dialout usrp Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
Hi Michael, On Jul 19, 2010, at 11:55 PM, Michael Dickens wrote: > On Jul 19, 2010, at 12:57 PM, Elvis Dowson wrote: >> One of the things that the guys working on GTK+ mentioned was that you >> should completely uninstall MacPorts, to do the GTK+ installation. The GTK+ >> installation has a whole bunch of dependencies, so I will try that last. >> That part I think is only related to GRC. > > Is their mentioning somewhere on a Wiki or whatever online? Or was this a > private email? I'm a MacPorts developer, and I'd like to know the reasoning > so that I can either quit doing MacPorts or augment it so-as to overcome > whatever deficiency they have found. If it's just a matter of selecting > configure options or patching code, MacPorts can handle whatever workaround > is necessary. If it's a matter of personal opinion, well, that's OK too -- > we're each entitled to what we want to think and use. - MLD It's mentioned in the following wiki link: http://sourceforge.net/apps/trac/gtk-osx/wiki/Build See the pre-requisites section, highlighted If you have MacPorts or Fink installed, you must remove all traces of them from your environment before you try to run jhbuild. The easiest way is to create a new user and run jhbuild while logged in as that user. Mixing Fink/MacPorts and GTK-OSX will fail. Best regards, Elvis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
Use the provided 'bootstrap' routine, but remember to change the 'libtoolize' call to 'glibtoolize' or whatever you named that function on the version you installed yourself. If you used MacPorts to install GNU Libtool (of which 'libtoolize' is a part), then it prepended the 'g' for you. On Jul 19, 2010, at 1:06 PM, Elvis Dowson wrote: Would someone happen to know the procedure to update gnuradio to use newer versions of autoconf-2.66 (perhaps I can revert this to 2.65, since Michael mentioned that 2.66 had issues) and libtool-2.2.10. I've got 2 Mac OS X 10.6.4 installations, one with Mac ports installed and the other, which I am building completely from the sources. The mac ports version uses autoconf-2.65 and libtool-2.2.10, so I would like to update gnuradio to also work with those versions. Here is the build error that I'm getting right now: ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
On Jul 19, 2010, at 12:57 PM, Elvis Dowson wrote: One of the things that the guys working on GTK+ mentioned was that you should completely uninstall MacPorts, to do the GTK+ installation. The GTK+ installation has a whole bunch of dependencies, so I will try that last. That part I think is only related to GRC. Is their mentioning somewhere on a Wiki or whatever online? Or was this a private email? I'm a MacPorts developer, and I'd like to know the reasoning so that I can either quit doing MacPorts or augment it so-as to overcome whatever deficiency they have found. If it's just a matter of selecting configure options or patching code, MacPorts can handle whatever workaround is necessary. If it's a matter of personal opinion, well, that's OK too -- we're each entitled to what we want to think and use. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
Hi, Would someone happen to know the procedure to update gnuradio to use newer versions of autoconf-2.66 (perhaps I can revert this to 2.65, since Michael mentioned that 2.66 had issues) and libtool-2.2.10. I've got 2 Mac OS X 10.6.4 installations, one with Mac ports installed and the other, which I am building completely from the sources. The mac ports version uses autoconf-2.65 and libtool-2.2.10, so I would like to update gnuradio to also work with those versions. Here is the build error that I'm getting right now: $ make cd . && /bin/sh /Users/elvis/Tool/gnuradio/missing --run autoheader aclocal.m4:17: error: this file was generated for autoconf 2.61. You have another version of autoconf. If you want to use that, you should regenerate the build system entirely. aclocal.m4:17: the top level autom4te: /usr/bin/m4 failed with exit status: 63 autoheader: '/usr/local/bin/autom4te' failed with exit status: 63 WARNING: `autoheader' is probably too old. You should only need it if you modified `acconfig.h' or `configure.ac'. You might want to install the `Autoconf' and `GNU m4' packages. Grab them from any GNU archive site. rm -f stamp-h1 touch config.h.in cd . && /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged make all-recursive Making all in config make[2]: Nothing to be done for `all'. Making all in gruel Making all in src Making all in lib Making all in pmt PYTHONPATH=../../../../gruel/src/lib/pmt srcdir=. /usr/bin/python ./generate_unv.py GUILE_LOAD_PATH="/Users/elvis/Tool/gnuradio/gruel/src/scheme" /usr/local/bin/guile -e main -s ./../../scheme/gnuradio/gen-serial-tags.scm ./../../scheme/gnuradio/pmt-serial-tags.scm /Users/elvis/Tool/gnuradio/gruel/src/include/gruel/pmt_serial_tags.h make all-am /bin/sh ../../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../.. -I/usr/local/include -I/usr/local/include -I/Users/elvis/Tool/gnuradio/gruel/src/include -I/Users/elvis/Tool/gnuradio/gruel/src/include -g -O2 -Wall -Woverloaded-virtual -D_THREAD_SAFE -MT pmt.lo -MD -MP -MF .deps/pmt.Tpo -c -o pmt.lo pmt.cc libtool: Version mismatch error. This is libtool 2.2.10, but the libtool: definition of this LT_INIT comes from libtool 2.2.4. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.10 libtool: and run autoconf again. make[6]: *** [pmt.lo] Error 63 make[5]: *** [all] Error 2 make[4]: *** [all-recursive] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Best regards, Elvis Dowson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
Hi Alex, On Jul 19, 2010, at 10:47 PM, Alexandru Csete wrote: > You'll find some examples in the source tree under gr-qtgui/src/python/ > I don't think they are installed in the installation directory. I haven't been able to build it yet, just processing and building all the required packages one by one. I now have some build error with gnuradio, relating to the fact that I am using newer versions of autoconf and libtool, that cause the build process to fail > > May I ask, Is this build you just finished completely without using macports? Yes, completely without using macports. The interesting thing is that the latest version of GTK+ supports a native Mac look and feel. Also PyQt4 works very nicely. This opens up the possibility of having a native look and feel for GNU Radio under Mac OS X. One of the things that the guys working on GTK+ mentioned was that you should completely uninstall MacPorts, to do the GTK+ installation. The GTK+ installation has a whole bunch of dependencies, so I will try that last. That part I think is only related to GRC. Best regards, Elvis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-trellis : problem in using viterbi decoder
I also realized that the way you call gr_make_vector_source_s(in_bits,false,K ); is incorrect. I think you have misunderstood what this block does. You should use: gr_make_vector_source_s(in_bits,false,1 ); or simply gr_make_vector_source_s(in_bits,false); and you really don't need the vector2stream block. Achilleas - In your code the "encoder" block is not connected to any other block... It should be: info bits -> encoder -> modulator -> channel -> metrics -> viterbi Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
On 19 July 2010 20:31, Elvis Dowson wrote: > Hi Michael, > I've managed to get gr-qtgui to pass all > configuration checks for building on Mac OS X 10.6.4. > What do you think I should do next ? Is there a simple gnuradio example that > I can run to test if the gr-qtgui component is working? Hi Elvis, You'll find some examples in the source tree under gr-qtgui/src/python/ I don't think they are installed in the installation directory. May I ask, Is this build you just finished completely without using macports? Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
Hi Michael, I've managed to get gr-qtgui to pass all configuration checks for building on Mac OS X 10.6.4. What do you think I should do next ? Is there a simple gnuradio example that I can run to test if the gr-qtgui component is working?For the qwt3dplot-0.2.7 sources, use the attached qmake pro file, to install it to /usr/local folder. The default pro file doesn't have the installation directives. qwtplot3d.pro Description: Binary data Here is the result of gnuradio ./configure. ...checking for PyQt4 for Qt4... yeschecking for QTCORE... yeschecking for QTGUI... yeschecking for QTOPENGL... yeschecking qwt/qwt.h usability... yeschecking qwt/qwt.h presence... yeschecking for qwt/qwt.h... yeschecking for main in -lqwt... yeschecking qwtplot3d/qwt3d_plot.h usability... yeschecking qwtplot3d/qwt3d_plot.h presence... yeschecking for qwtplot3d/qwt3d_plot.h... yeschecking for main in -lqwtplot3d-qt4... nochecking for main in -lqwtplot3d... yesComponent gr-qtgui passed configuration checks; building. ...*The following GNU Radio components have been successfully configured:configgruelgnuradio-coregr-msdd6000gr-audio-osxgr-atscgr-cvsd-vocodergr-gsm-fr-vocodergr-noaagr-pagergr-radio-astronomygr-trellisgr-video-sdlgr-wxguigr-qtguignuradio-examplesdocsBest regards,Elvis Dowson___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 write_gpio() command
I'm trying to use one of the GPIO pins on my USRP 2 / WBX daughtercard to
control an external antenna selector box. I've created a simple GUI with a
USRP2 source feeding into a graphical FFT sink, and I'm able to change the
state of io_tx_14 using the following code:
#this code is called when the program is started
self.gr_null_sink_0 = gr.null_sink(gr.sizeof_gr_complex*1)
self.howto_rx_gpio_0 = usrp2.source_32fc()
self.howto_rx_gpio_0.set_decim(decimation)
self.howto_rx_gpio_0.set_center_freq(frequency)
self.howto_rx_gpio_0.set_gain(daughtercard_gain)
self.howto_rx_gpio_0.set_gpio_ddr(0x, 0b0100) #set the DDR
self.howto_rx_gpio_0.set_gpio_sels(".s..") #set the output
selection register
#this code is called when the checkbox on the GUI is changed
def set_check(self, check):
self.check = check
self._check_check_box.set_value(self.check)
self.howto_rx_gpio_0.write_gpio(self.check * 2**14, 0x)
The problem is that whenever I change the value of the checkbox, the FFT sink
freezes and stops displaying new values, or it begins displaying garbage at
like -300 dB. The pin continues to change from high to low just fine even after
the FFT sink stops updating. I've tried restarting the source using the stop()
and start() commands, but this does not help. The problem is not unique to the
FFT sink - applying the same code to a working NBFM receiver causes the audio
sink to start playing popping sounds. I considered using gr-gpio, but this
requires custom firmware, and I'm already running custom firmware to support my
WBX daughtercard. Does anyone have any ideas?
-- Ryan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-trellis : problem in using viterbi decoder
In your code the "encoder" block is not connected to any other block... It should be: info bits -> encoder -> modulator -> channel -> metrics -> viterbi Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] debugging code for seeing what threads are created
Hi, my name is Alexandru Buda, and I'm doing a project in college based on GNU Radio. I'm using the environment variable GR_SCHEDULER to enable/disable multi-threading for benchmarking purposes and also the linux command "ps" to see the threads created. This unfortunately only gives me the number of threads and no more detail as to what each one is doing. A few years ago my supervisor did some work with GNU Radio (3.1.2 and 3.1.3) and used the variable GR_TOP_BLOCK_IMPL_DEBUG from gnuradio-core/src/lib/runtime/gr_top_block_impl.cc to see what threads are created but it seems that the code using GR_TOP_BLOCK_IMPL_DEBUG has been removed. Is there any debugging variables that I can enable or how do I see extra information available about my running waveform? Or is there a linux/python tool that will give me more information about the threads? Not sure if this is relevant but I'm using GNU Radio 3.2.2 built from source on Ubuntu 10.04 32bit Any information would be greatly appreciated Thank you Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
Hi, On Jul 19, 2010, at 9:23 PM, Elvis Dowson wrote: > I updated my .profile accordingly > > export PKG_CONFIG_PATH=/Developer/Applications/Qt-4.7/lib:$PKG_CONFIG_PATH I had to explicitly put the full path, and it worked, thanks, Michael export PKG_CONFIG_PATH=/Developer/Applications/Qt-4.7/lib/pkgconfig:$PKG_CONFIG_PATH checking for PyQt4 for Qt4... yes checking for QTCORE... yes checking for QTGUI... yes checking for QTOPENGL... yes checking qwt/qwt.h usability... yes checking qwt/qwt.h presence... yes checking for qwt/qwt.h... yes checking for main in -lqwt... yes checking qwtplot3d/qwt3d_plot.h usability... no checking qwtplot3d/qwt3d_plot.h presence... no checking for qwtplot3d/qwt3d_plot.h... no checking qwtplot3d-qt4/qwt3d_plot.h usability... no checking qwtplot3d-qt4/qwt3d_plot.h presence... no checking for qwtplot3d-qt4/qwt3d_plot.h... no Could not find qwtplot3d headers Not building component gr-qtgui. Now onto the remaining components ... I think using Python and Qt is really a good way to build these user interfaces. It might be worth getting up and running, plus porting GRC to support gr-qtgui. Best regards, Elvis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
Hi,On Jul 19, 2010, at 8:59 PM, Michael Dickens wrote:Hi Elvis - GNU Radio's configure script is looking for the PKG_CONFIG installed files for QtCore.pc & so forth. Those need to be in the PKG_CONFIG_PATH, and I'd bet that they're not right now otherwise they would have been found.I can see a QtCore.pc file in my installation directory /Developer/Applications/Qt-4.7/lib/pkgconfig/QtCore.pcI updated my .profile accordinglyexport PKG_CONFIG_PATH=/Developer/Applications/Qt-4.7/lib:$PKG_CONFIG_PATHLooking at grc_gr_qtgui.m4, I see the following entry PYTHON_CHECK_MODULE([PyQt4.QtCore], [PyQt4 for Qt4], \ [passed=yes], [passed=no], \ [PyQt4.QtCore.PYQT_VERSION >= 26])I tested the PyQt4 installation, just to see if it is working, and the installation is correct, but something in the gnuradio scripts is preventing it from being recognized$ python>>> import sys>>> from PyQt4.QtGui import *>>> app = QApplication(sys.argv)>>> button = QPushButton("Hello World", None)>>> button.show()>>> app.exec_()>>> from PyQt4 import QtCore>>> s = QtCore.QString()>>> s = "Hello World">>> print sHello World>>> Best regards,Elvis___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] grc file source
the file source block can read any file extension, the only thing the data has to be formatted properly, i.e. it has to store either binary data, complex numbers, integers, floats and so on. On Fri, Jul 16, 2010 at 5:59 PM, mehmet kabasakal <85kabasa...@gmail.com> wrote: > Hi guys, > > I want to learn that what kind of File source block in GRC can read? > For ex. can this block read the .mat files. I see that it can send > .bin files but are there any other file types. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
Hi, I've got Qt-4.7 installed, and the paths set in my .profile. I've also run and tested PyQt4 and it works with the Qt-4.7 installation. When I run gnuradio configure, I get the following message: checking for PyQt4 for Qt4... yes checking for QTCORE... no gr-qtgui requires libQtCore >= 4.2. checking for QTGUI... no gr-qtgui requires libQtGui >= 4.2. checking for QTOPENGL... no gr-qtgui requires libQtOpenGL >- 4.2. These libraries are available on my system, e.g. libQtCore.dylib, etc What can I do to make it accept the built libraries? Best regards, Elvis Dowson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to stop a hier_block2?
I was thinking of putting them in different top blocks, but maybe that's not possible, I don't know. Alex On 19 July 2010 17:11, killoqg wrote: > > Thanks for your response Alex. > > The hier_block2 blocks do not have start/stop methods, and I can not stop > my top_block because I have another hier_block that I need to be running > (one hier_block2 sensing and x hier_block2 transmitting dynamically). > > > Alexandru Csete-3 wrote: >> >> On 19 July 2010 16:18, killoqg wrote: >>> >>> Hello, >>> >>> I've defined a hier_block2 to transmit a signal and I need to start/stop >>> it >>> under certain conditions. The problem is that I'm not able to stop it. I >>> tried it calling the top_block.disconnect(my_hier_block) method. Then I >>> tried calling the my_hier_block.disconnect_all() method but none of them >>> works. Is that possible or does exist another way to achieve that? >> >> Maybe try the start(), stop(), ... methods >> http://gnuradio.org/redmine/wiki/gnuradio/TutorialsWritePythonApplications >> -> Controlling flow graphs >> >> Alex >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > -- > View this message in context: > http://old.nabble.com/How-to-stop-a-hier_block2--tp29205188p29205737.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
Hi Michael, On Jul 19, 2010, at 6:51 PM, Michael Dickens wrote: > > That flag is for GNU Radio's 'configure' script, and it should work for you > given where the PC file was installed. Thanks, that worked now. checking for USB... yes checking libusb-1.0/libusb.h usability... yes checking libusb-1.0/libusb.h presence... yes checking for libusb-1.0/libusb.h... yes checking for libusb_bulk_transfer in -lusb-1.0... yes Best regards, Elvis Dowson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to stop a hier_block2?
Thanks for your response Alex. The hier_block2 blocks do not have start/stop methods, and I can not stop my top_block because I have another hier_block that I need to be running. Alexandru Csete-3 wrote: > > On 19 July 2010 16:18, killoqg wrote: >> >> Hello, >> >> I've defined a hier_block2 to transmit a signal and I need to start/stop >> it >> under certain conditions. The problem is that I'm not able to stop it. I >> tried it calling the top_block.disconnect(my_hier_block) method. Then I >> tried calling the my_hier_block.disconnect_all() method but none of them >> works. Is that possible or does exist another way to achieve that? > > Maybe try the start(), stop(), ... methods > http://gnuradio.org/redmine/wiki/gnuradio/TutorialsWritePythonApplications > -> Controlling flow graphs > > Alex > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/How-to-stop-a-hier_block2--tp29205188p29205737.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to stop a hier_block2?
On 19 July 2010 16:18, killoqg wrote: > > Hello, > > I've defined a hier_block2 to transmit a signal and I need to start/stop it > under certain conditions. The problem is that I'm not able to stop it. I > tried it calling the top_block.disconnect(my_hier_block) method. Then I > tried calling the my_hier_block.disconnect_all() method but none of them > works. Is that possible or does exist another way to achieve that? Maybe try the start(), stop(), ... methods http://gnuradio.org/redmine/wiki/gnuradio/TutorialsWritePythonApplications -> Controlling flow graphs Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
Hi Michael, On Jul 19, 2010, at 5:45 PM, Michael Dickens wrote: > Hi Elvis - Did you try "configure --with-fusb-tech=libusb1"? You have to > specify that you want to use LIBUSB version 1; config/usrp_libusb.m4 checks > to see if you've specified this on the CLI & if not then doesn't check for > this version of LIBUSB. I downloaded libusb-1.0.8 from http://www.libusb.org/ and it doesn't recognize the --with-fusb-tech=libusb1 configure option $ ./configure --with-fusb-tech=libusb1 configure: WARNING: unrecognized options: --with-fusb-tech I also checked the older legacy libusb-0.1.12, and that also didn't have the --with-fusb-tech=libusb1 option, if you list it with ./configure --help, however, the legacy version accepts this as a parameter and for this warning are being treated as errors and it fails compilation: gcc -DHAVE_CONFIG_H -I. -Werror -no-cpp-precomp -g -O2 -g -Wall -MT descriptors.lo -MD -MP -MF .deps/descriptors.Tpo -c descriptors.c -o descriptors.o >/dev/null 2>&1 cc1: warnings being treated as errors darwin.c: In function ‘usb_get_next_device’: darwin.c:257: warning: passing argument 5 of ‘IOCreatePlugInInterfaceForService’ from incompatible pointer type darwin.c: In function ‘claim_interface’: darwin.c:560: warning: passing argument 5 of ‘IOCreatePlugInInterfaceForService’ from incompatible pointer type darwin.c: In function ‘rw_completed’: darwin.c:772: warning: cast from pointer to integer of different size darwin.c:772: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 4 has type ‘unsigned int’ darwin.c:774: warning: cast from pointer to integer of different size darwin.c: In function ‘usb_os_find_devices’: darwin.c:1067: warning: format ‘%08lx’ expects type ‘long unsigned int’, but argument 3 has type ‘UInt32’ darwin.c:1095: warning: format ‘%08lx’ expects type ‘long unsigned int’, but argument 5 has type ‘UInt32’ make[2]: *** [darwin.lo] Error 1 make[2]: *** Waiting for unfinished jobs g++ -DHAVE_CONFIG_H -I. -g -O2 -MT usbpp.lo -MD -MP -MF .deps/usbpp.Tpo -c usbpp.cpp -o usbpp.o >/dev/null 2>&1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Best regards, Elvis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RD pin of CY7C68013 ON USRP board
So the RD pin is floated, right? Matt Ettus wrote: > > On 07/18/2010 05:40 AM, zhdiamond wrote: >> >> when I see the USRP board, the U412:CY7C68013 has the RD PIN connected >> GND. >> but the spec said that, it's a output pin, and the default state is high. >> So I wonder to know if the RD PIN should not connected to the GND ? > > > It is not connected to ground. > > Matt > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/RD-pin-of-CY7C68013-ON-USRP-board-tp29196831p29205278.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to stop a hier_block2?
Hello, I've defined a hier_block2 to transmit a signal and I need to start/stop it under certain conditions. The problem is that I'm not able to stop it. I tried it calling the top_block.disconnect(my_hier_block) method. Then I tried calling the my_hier_block.disconnect_all() method but none of them works. Is that possible or does exist another way to achieve that? Thanks in advance. -- View this message in context: http://old.nabble.com/How-to-stop-a-hier_block2--tp29205188p29205188.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD example
On 07/19/2010 07:25 AM, Elvis Dowson wrote: Hi Josh, I hope you're doing fine! I was wondering if you have an UHD example that you can share with me? I couldn't find any such example on the net, and I just need a simple starting point, to bring data from the USRP2 using UHD. Do these help: http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/repository/revisions/master/show/host/examples Philip best regards, Elvis Dowson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio on osx 10.6.4
Hi Elvis - Did you try "configure --with-fusb-tech=libusb1"? You have
to specify that you want to use LIBUSB version 1; config/
usrp_libusb.m4 checks to see if you've specified this on the CLI & if
not then doesn't check for this version of LIBUSB.
If you did try that command line, then you'll need to track down where
the PKG_CONFIG file was installed and under what name. Default is
into "${prefix}/lib/pkgconfig", with ${prefix} being "/usr/local", and
"libusb-1.0.pc". Assuming that your shell's PKG_CONFIG_PATH variable
is set with the default path, then you'll need to make sure the PC
file name is correct. I've only installed LIBUSB (legacy or 1.0) from
MacPorts, so I have no idea if it tweaks the install names.
Good luck! - MLD
On Jul 18, 2010, at 11:55 PM, Elvis Dowson wrote:
checking for USB... no
checking for USB... no
checking usb.h usability... no
checking usb.h presence... no
checking for usb.h... no
USRP requires libusb header 'usb.h' which was not found or was not
usable. See http://www.libusb.org
Unable to find dependency libusb.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] analog TV modulation (NTSC or PAL)
Hi people, Now that we have the WBX (and now I have mine!), it's possible to transmit in any of the available TV channels, in VHF or UHF. Do anyone have written any code that does NTSC or PAL modulation? Best Regards, Rafael Diniz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 on MacPorts
On Mon, Jul 19, 2010 at 14:22, Ninja wrote: > Just trying install gnuradio using macports, everything is ok. But it seems > USRP2 is not supported? > > $ sudo port installed | grep gnuradio > gnuradio @3.2.2_1+python26 (active) > gnuradio-audio-jack @3.2.2_1+python26 (active) > gnuradio-audio-osx @3.2.2_1+python26 (active) > gnuradio-audio-portaudio @3.2.2_1+python26 (active) > gnuradio-core @3.2.2_1+python26 (active) > gnuradio-cvsd-vocoder @3.2.2_1+python26 (active) > gnuradio-examples @3.2.2_1+python26 (active) > gnuradio-gpio @3.2.2_1+python26 (active) > gnuradio-grc @3.2.2_1+python26 (active) > gnuradio-gruel @3.2.2_1+python26 (active) > gnuradio-gsm-fr-vocoder @3.2.2_1+python26 (active) > gnuradio-omnithread @3.2.2_1+python26 (active) > gnuradio-pager @3.2.2_1+python26 (active) > gnuradio-radar-mono @3.2.2_1+python26 (active) > gnuradio-radio-astronomy @3.2.2_1+python26 (active) > gnuradio-sounder @3.2.2_1+python26 (active) > gnuradio-trellis @3.2.2_1+python26 (active) > gnuradio-usrp @3.2.2_1+python26 (active) > gnuradio-utils @3.2.2_1+python26 (active) > gnuradio-video-sdl @3.2.2_1+python26 (active) > gnuradio-wxgui @3.2.2_1+python26 (active) > > is gnuradio-usrp above include USRP2 support?or USRP2 currently only support > linux? Support for the USRP2 under Mac OS X is only possible with UHD and needs the gr-uhd block which is still under development and isn't in any release yet. You have to get it from the next branch. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 on MacPorts
Just trying install gnuradio using macports, everything is ok. But it seems USRP2 is not supported? $ sudo port installed | grep gnuradio gnuradio @3.2.2_1+python26 (active) gnuradio-audio-jack @3.2.2_1+python26 (active) gnuradio-audio-osx @3.2.2_1+python26 (active) gnuradio-audio-portaudio @3.2.2_1+python26 (active) gnuradio-core @3.2.2_1+python26 (active) gnuradio-cvsd-vocoder @3.2.2_1+python26 (active) gnuradio-examples @3.2.2_1+python26 (active) gnuradio-gpio @3.2.2_1+python26 (active) gnuradio-grc @3.2.2_1+python26 (active) gnuradio-gruel @3.2.2_1+python26 (active) gnuradio-gsm-fr-vocoder @3.2.2_1+python26 (active) gnuradio-omnithread @3.2.2_1+python26 (active) gnuradio-pager @3.2.2_1+python26 (active) gnuradio-radar-mono @3.2.2_1+python26 (active) gnuradio-radio-astronomy @3.2.2_1+python26 (active) gnuradio-sounder @3.2.2_1+python26 (active) gnuradio-trellis @3.2.2_1+python26 (active) gnuradio-usrp @3.2.2_1+python26 (active) gnuradio-utils @3.2.2_1+python26 (active) gnuradio-video-sdl @3.2.2_1+python26 (active) gnuradio-wxgui @3.2.2_1+python26 (active) is gnuradio-usrp above include USRP2 support?or USRP2 currently only support linux? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD example
Hi Josh, I hope you're doing fine! I was wondering if you have an UHD example that you can share with me? I couldn't find any such example on the net, and I just need a simple starting point, to bring data from the USRP2 using UHD. best regards, Elvis Dowson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Segmentation fault in usrp_siggen.py hier_block
Hi all, I'm trying to define a hier_block with the same functionality as the usrp_siggen top_block. The main idea is to use this new block in a dynamic way changing the frequency and/or the amplitude of the signal. I did "copy/paste" of the code of usrp_siggen.py and I put it on a hier_block2 (changing the init definition, putting the gr.io_signature(0,0,0), etc.). When I execute my program, I obtain a segmentation fault error in the self.lock() instruction. If I remove this line (and the self.unlock() it works properly. Does anybody know/suspect why? I'm using gnuradio 3.2.2 and as I said, I copied the code wich works perfectly in the usrp_siggen.py application. Thanks in advance. -- View this message in context: http://old.nabble.com/Segmentation-fault-in-usrp_siggen.py-hier_block-tp29203307p29203307.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio Companion and WxWidgets 2.9.0 on Mac OS X 10.6.4
Hi, On Jul 19, 2010, at 2:08 AM, Michael Dickens wrote: > My bad: GRC uses GTK2 for the GUI, not wxPython -- right Josh? Apparently a newer vesion of GTK supports Mac OS X's quartz backend, bypassing X11, so that the applications will look like a Mac app, rather than an X11 app. See the following link for some screenshots: http://gtk-osx.sourceforge.net/ I'm going to try and install that, and see if it satisfies all GRC dependencies. http://sourceforge.net/apps/trac/gtk-osx/wiki/Build Best regards, Elvis Dowson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to set default ethernet interface to eth2
> > How can I tell GNU Radio to only use the eth2 interface for all > communications with the USRP2, instead of eth0? > For python scripts you change the defaults by modifying: gnuradio/gr-usrp2/src/usrp2.i For the four blocks change std::string ifc="eth0" to std::string ifc="eth2" and recompile This assumes the script doesn't explicitly state eth0 Cheers, Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
