[Discuss-gnuradio] Re : Discuss-gnuradio Digest, Vol 113, Issue 12

Send Discuss-gnuradio mailing list submissions to
    address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
    address@hidden

You can reach the person managing the list at
    address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."

Today's Topics:

   1. Re: swig gnuradio.i cannot find gruel_common.i in 3.6.0
(Josh Blum)
   2. Re: swig gnuradio.i cannot find gruel_common.i in 3.6.0
(address@hidden)
   3. Re: swig gnuradio.i cannot find gruel_common.i    in 3.6.0
(Johnathan Corgan)
   4. Re: swig gnuradio.i cannot find gruel_common.i in 3.6.0
(address@hidden)
   5. Modifying C++ Files (sibar002)
   6. Re: swig gnuradio.i cannot find gruel_common.i    in 3.6.0
(Justin Ford)
   7. Re: Data lost whe using big file sources (Johnathan Corgan)
   8. Re: Problem in the update (frankist)
   9. Re: [USRP-users] Gnu Radio apps freezes (locks    up) (Rickard)
10. Re: [USRP-users] Gnu Radio apps freezes (locks up)
(Marcus D. Leech)
11. Re: [USRP-users] Gnu Radio apps freezes (locks    up) (Nick Foster)
12. Re: Problem in the update (Adam Nielsen)
13. Re: Modifying C++ Files (Ben Reynwar)
14. Re: Problem in the update (frankist)
15. Question about sampling rate (Javier Suarez)
16. Re: Question about sampling rate (Nick Foster)

----------------------------------------------------------------------

Message: 1
Date: Tue, 10 Apr 2012 10:27:15 -0700
From: Josh Blum <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] swig gnuradio.i cannot find
    gruel_common.i in 3.6.0
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

On 04/10/2012 08:49 AM, Justin Ford wrote:
> I'm trying to build an existing tool against gnuradio 3.6.0 (master
> branch 3.6.0git-7-g779d8c67). I'm getting the following error from
> make when gnuradio.i is included by swig:
> /usr/local/include/gnuradio/swig/gnuradio.i:28: Error: Unable to find
> 'gruel_common.i'
>
> I have attached gnuradio.i from my build, line 28 is trying to include
> gruel_common.i. I found gruel_common.i in
> /usr/local/include/gruel/swig/, but I think it's expected to be in
> /usr/local/include/gnuradio/swig/.
>
> Is this an issue with my build? Or does a change in the more recent
> master branch version require a patch to gnuradio.i?
>

This looks to be a recent change. The gruel swig stuff was moved to a
new install path include/gruel/swig.

> Should I just copy (or link) the contents of
> /usr/local/include/gruel/swig/ to /usr/local/include/gnuradio/swig/ as
> a workaround?
>

You should add this path to the swig search path for your application.

-josh

> Thanks for any guidance!
> Justin
>
> $ cat /proc/version
> Linux version 2.6.32-220.7.1.el6.x86_64
> (address@hidden) (gcc version 4.4.6 20110731
> (Red Hat 4.4.6-3) (GCC) ) #1 SMP Fri Feb 10 15:22:22 EST 2012
>
> $ gnuradio-config-info -v
> 3.6.0git-7-g779d8c67
>
> $ ls /usr/local/include/gruel/swig/
> gr_intrusive_ptr.i gruel_common.i pmt_swig_doc.i pmt_swig.i
>
> $ ls /usr/local/include/gnuradio/swig/
> atsc.i    gr_freq_xlating_fir_filter_fcc.i
> gr_stream_to_vector.i
> atsc_swig_doc.i gr_freq_xlating_fir_filter_fcf.i
> gr_stretch_ff.i
> audio_swig_doc.i    gr_freq_xlating_fir_filter_scc.i
> gr_sub_cc.i
> audio_swig.i    gr_freq_xlating_fir_filter_scf.i
> gr_sub_ff.i
> complex_vec_test.i    gr_glfsr_source_b.i
> gr_sub_ii.i
> digital_binary_slicer_fb.i    gr_glfsr_source_f.i
> gr_sub_ss.i
> digital_clock_recovery_mm_cc.i    gr_goertzel_fc.i
> gr_swig_block_magic.i
> digital_clock_recovery_mm_ff.i    gr_head.i
> gr_sync_block.i
> digital_cma_equalizer_cc.i    gr_hier_block2.i
> gr_sync_decimator.i
> digital_constellation_decoder_cb.i   gr_hilbert_fc.i
> gr_sync_interpolator.i
> digital_constellation.i gr_histo_sink.i
> gr_tagged_file_sink.i
> digital_constellation_receiver_cb.i gri_agc2_cc.i
> gr_tags.i
> digital_correlate_access_code_bb.i   gri_agc2_ff.i
> gr_test.i
> digital_costas_loop_cc.i    gri_agc_cc.i
> gr_threshold_ff.i
> digital_cpmmod_bc.i gri_agc_ff.i
> gr_throttle.i
> digital_crc32.i gri_control_loop.i
> gr_top_block.i
> digital_fll_band_edge_cc.i    gr_iir_filter_ffd.i
> gr_transcendental.i
> digital_gmskmod_bc.i    gr_integrate_cc.i
> gr_uchar_to_float.i
> digital_kurtotic_equalizer_cc.i gr_integrate_ff.i
> gr_udp_sink.i
> digital_lms_dd_equalizer_cc.i gr_integrate_ii.i
> gr_udp_source.i
> digital_mpsk_receiver_cc.i    gr_integrate_ss.i
> gr_unpacked_to_packed_bb.i
> digital_mpsk_snr_est_cc.i gr_interleaved_short_to_complex.i
> gr_unpacked_to_packed_ii.i
> digital_ofdm_cyclic_prefixer.i    gr_interleave.i
> gr_unpacked_to_packed_ss.i
> digital_ofdm_frame_acquisition.i    gr_interp_fir_filter_ccc.i
> gr_unpack_k_bits_bb.i
> digital_ofdm_frame_sink.i gr_interp_fir_filter_ccf.i
> gr_vco_f.i
> digital_ofdm_insert_preamble.i    gr_interp_fir_filter_fcc.i
> gr_vector_sink_b.i
> digital_ofdm_mapper_bcv.i gr_interp_fir_filter_fff.i
> gr_vector_sink_c.i
> digital_ofdm_sampler.i    gr_interp_fir_filter_fsf.i
> gr_vector_sink_f.i
> digital_probe_mpsk_snr_est_c.i    gr_interp_fir_filter_scc.i
> gr_vector_sink_i.i
> digital_swig_doc.i    gr_int_to_float.i
> gr_vector_sink_s.i
> digital_swig.i    gr_io_signature.i
> gr_vector_source_b.i
> fcd_swig_doc.i    gr_iqcomp_cc.i
> gr_vector_source_c.i
> fcd_swig.i    gr_keep_one_in_n.i
> gr_vector_source_f.i
> filter_generated.i    gr_kludge_copy.i
> gr_vector_source_i.i
> filter.i    gr_lfsr_32k_source_s.i
> gr_vector_source_s.i
> filter_swig_doc.i gr_map_bb.i
> gr_vector_to_stream.i
> fsm.i gr_max_ff.i
> gr_vector_to_streams.i
> general.i gr_max_ii.i
> gr_wavfile_sink.i
> general_swig_doc.i    gr_max_ss.i
> gr_wavfile_source.i
> gengen_generated.i    gr_message.i
> gr_xor_bb.i
> gengen.i    gr_message_sink.i
> gr_xor_ii.i
> gengen_swig_doc.i gr_message_source.i
> gr_xor_ss.i
> gnuradio_core_filter.i    gr_moving_average_cc.i
> hier.i
> gnuradio_core_general.i gr_moving_average_ff.i
> hier_swig_doc.i
> gnuradio_core_gengen.i    gr_moving_average_ii.i
> interleaver.i
> gnuradio_core_hier.i    gr_moving_average_ss.i
> io.i
> gnuradio_core_io.i    gr_msg_handler.i
> io_swig_doc.i
> gnuradio_core_runtime.i gr_msg_queue.i
> microtune_4702_eval_board.i
> gnuradio.i    gr_multiply_cc.i
> microtune_4937_eval_board.i
> gr_adaptive_fir_ccc.i gr_multiply_conjugate_cc.i
> microtune_xxxx_eval_board.i
> gr_adaptive_fir_ccf.i gr_multiply_const_cc.i
> noaa_hrpt_decoder.i
> gr_add_cc.i gr_multiply_const_ff.i
> noaa_hrpt_deframer.i
> gr_add_const_cc.i gr_multiply_const_ii.i
> noaa_hrpt_pll_cf.i
> gr_add_const_ff.i gr_multiply_const_ss.i
> noaa_swig_doc.i
> gr_add_const_ii.i gr_multiply_const_vcc.i
> noaa_swig.i
> gr_add_const_sf.i gr_multiply_const_vff.i
> pager_flex_deinterleave.i
> gr_add_const_ss.i gr_multiply_const_vii.i
> pager_flex_frame.i
> gr_add_const_vcc.i    gr_multiply_const_vss.i
> pager_flex_parse.i
> gr_add_const_vff.i    gr_multiply_ff.i
> pager_flex_sync.i
> gr_add_const_vii.i    gr_multiply_ii.i
> pager_slicer_fb.i
> gr_add_const_vss.i    gr_multiply_ss.i
> pager_swig_doc.i
> gr_add_ff.i gr_mute_cc.i
> pager_swig.i
> gr_add_ii.i gr_mute_ff.i
> ppio.i
> gr_additive_scrambler_bb.i    gr_mute_ii.i
> qtgui_sink_c.i
> gr_add_ss.i gr_mute_ss.i
> qtgui_sink_f.i
> gr_agc2_cc.i    gr_nlog10_ff.i
> qtgui_swig_doc.i
> gr_agc2_ff.i    gr_noise_source_c.i
> qtgui_swig.i
> gr_agc_cc.i gr_noise_source_f.i
> qtgui_time_sink_c.i
> gr_agc_ff.i gr_noise_source_i.i
> qtgui_time_sink_f.i
> gr_align_on_samplenumbers_ss.i    gr_noise_source_s.i
> runtime.i
> gr_and_bb.i gr_nop.i
> runtime_swig_doc.i
> gr_and_const_bb.i gr_not_bb.i
> sdr_1000.i
> gr_and_const_ii.i gr_not_ii.i
> trellis_constellation_metrics_cf.i
> gr_and_const_ss.i gr_not_ss.i
> trellis_encoder_bb.i
> gr_and_ii.i gr_null_sink.i
> trellis_encoder_bi.i
> gr_and_ss.i gr_null_source.i
> trellis_encoder_bs.i
> gr_annotator_1to1.i gr_or_bb.i
> trellis_encoder_ii.i
> gr_annotator_alltoall.i gr_or_ii.i
> trellis_encoder_si.i
> gr_argmax_fs.i    gr_or_ss.i
> trellis_encoder_ss.i
> gr_argmax_is.i    gr_oscope_sink.i
> trellis_generated.i
> gr_argmax_ss.i    gr_pa_2x2_phase_combiner.i
> trellis.i
> gr_basic_block.i    gr_packed_to_unpacked_bb.i
> trellis_metrics_c.i
> gr_bin_statistics_f.i gr_packed_to_unpacked_ii.i
> trellis_metrics_f.i
> gr_block_detail.i gr_packed_to_unpacked_ss.i
> trellis_metrics_i.i
> gr_block.i    gr_packet_sink.i
> trellis_metrics_s.i
> gr_buffer.i gr_peak_detector2_fb.i
> trellis_pccc_decoder_b.i
> gr_burst_tagger.i gr_peak_detector_fb.i
> trellis_pccc_decoder_combined_cb.i
> gr_bytes_to_syms.i    gr_peak_detector_ib.i
> trellis_pccc_decoder_combined_ci.i
> gr_channel_model.i    gr_peak_detector_sb.i
> trellis_pccc_decoder_combined_cs.i
> gr_char_to_float.i    gr_pfb_arb_resampler_ccf.i
> trellis_pccc_decoder_combined_fb.i
> gr_char_to_short.i    gr_pfb_arb_resampler_fff.i
> trellis_pccc_decoder_combined_fi.i
> gr_check_counting_s.i gr_pfb_channelizer_ccf.i
> trellis_pccc_decoder_combined_fs.i
> gr_check_lfsr_32k_s.i gr_pfb_clock_sync_ccf.i
> trellis_pccc_decoder_i.i
> gr_chunks_to_symbols_bc.i gr_pfb_clock_sync_fff.i
> trellis_pccc_decoder_s.i
> gr_chunks_to_symbols_bf.i gr_pfb_decimator_ccf.i
> trellis_pccc_encoder_bb.i
> gr_chunks_to_symbols_ic.i gr_pfb_interpolator_ccf.i
> trellis_pccc_encoder_bi.i
> gr_chunks_to_symbols_if.i gr_pfb_synthesizer_ccf.i
> trellis_pccc_encoder_bs.i
> gr_chunks_to_symbols_sc.i gr_phase_modulator_fc.i
> trellis_pccc_encoder_ii.i
> gr_chunks_to_symbols_sf.i gr_pll_carriertracking_cc.i
> trellis_pccc_encoder_si.i
> gr_complex_to_interleaved_short.i gr_pll_freqdet_cf.i
> trellis_pccc_encoder_ss.i
> gr_complex_to_xxx.i gr_pll_refout_cc.i
> trellis_permutation.i
> gr_conjugate_cc.i gr_pn_correlator_cc.i
> trellis_sccc_decoder_b.i
> gr_constants.i    gr_prefs.i
> trellis_sccc_decoder_combined_cb.i
> gr_copy.i gr_probe_avg_mag_sqrd_cf.i
> trellis_sccc_decoder_combined_ci.i
> gr_correlate_access_code_tag_bb.i gr_probe_avg_mag_sqrd_c.i
> trellis_sccc_decoder_combined_cs.i
> gr_cpfsk_bc.i gr_probe_avg_mag_sqrd_f.i
> trellis_sccc_decoder_combined_fb.i
> gr_cpm.i    gr_probe_density_b.i
> trellis_sccc_decoder_combined_fi.i
> gr_ctcss_squelch_ff.i gr_probe_signal_b.i
> trellis_sccc_decoder_combined_fs.i
> gr_dc_blocker_cc.i    gr_probe_signal_c.i
> trellis_sccc_decoder_i.i
> gr_dc_blocker_ff.i    gr_probe_signal_f.i
> trellis_sccc_decoder_s.i
> gr_decode_ccsds_27_fb.i gr_probe_signal_i.i
> trellis_sccc_encoder_bb.i
> gr_deinterleave.i gr_probe_signal_s.i
> trellis_sccc_encoder_bi.i
> gr_delay.i    gr_probe_signal_vb.i
> trellis_sccc_encoder_bs.i
> gr_descrambler_bb.i gr_probe_signal_vc.i
> trellis_sccc_encoder_ii.i
> gr_diff_decoder_bb.i    gr_probe_signal_vf.i
> trellis_sccc_encoder_si.i
> gr_diff_encoder_bb.i    gr_probe_signal_vi.i
> trellis_sccc_encoder_ss.i
> gr_diff_phasor_cc.i gr_probe_signal_vs.i
> trellis_siso_combined_f.i
> gr_dispatcher.i gr_pwr_squelch_cc.i
> trellis_siso_f.i
> gr_divide_cc.i    gr_pwr_squelch_ff.i
> trellis_swig_doc.i
> gr_divide_ff.i    gr_quadrature_demod_cf.i
> trellis_viterbi_b.i
> gr_divide_ii.i    gr_rail_ff.i
> trellis_viterbi_combined_cb.i
> gr_divide_ss.i    gr_rational_resampler_base_ccc.i
> trellis_viterbi_combined_ci.i
> gr_dpll_bb.i    gr_rational_resampler_base_ccf.i
> trellis_viterbi_combined_cs.i
> gr_encode_ccsds_27_bb.i gr_rational_resampler_base_fcc.i
> trellis_viterbi_combined_fb.i
> gr_endianness.i gr_rational_resampler_base_fff.i
> trellis_viterbi_combined_fi.i
> gr_error_handler.i    gr_rational_resampler_base_fsf.i
> trellis_viterbi_combined_fs.i
> gr_fake_channel_coder_pp.i    gr_rational_resampler_base_scc.i
> trellis_viterbi_combined_ib.i
> gr_feedforward_agc_cc.i gr_realtime.i
> trellis_viterbi_combined_ii.i
> gr_feval.i    gr_regenerate_bb.i
> trellis_viterbi_combined_is.i
> gr_fft_filter_ccc.i gr_remez.i
> trellis_viterbi_combined_sb.i
> gr_fft_filter_fff.i gr_repeat.i
> trellis_viterbi_combined_si.i
> gr_fft_vcc.i    gr_rms_cf.i
> trellis_viterbi_combined_ss.i
> gr_fft_vfc.i    gr_rms_ff.i
> trellis_viterbi_i.i
> gr_file_descriptor_sink.i gr_sample_and_hold_bb.i
> trellis_viterbi_s.i
> gr_file_descriptor_source.i gr_sample_and_hold_ff.i
> uhd_swig_doc.i
> gr_file_sink_base.i gr_sample_and_hold_ii.i
> uhd_swig.i
> gr_file_sink.i    gr_sample_and_hold_ss.i
> vocoder_alaw_decode_bs.i
> gr_file_source.i    gr_scrambler_bb.i
> vocoder_alaw_encode_sb.i
> gr_filter_delay_fc.i    gr_shared_ptr.i
> vocoder_codec2_decode_ps.i
> gr_firdes.i gr_short_to_char.i
> vocoder_codec2_encode_sp.i
> gr_fir_filter_ccc.i gr_short_to_float.i
> vocoder_cvsd_decode_bs.i
> gr_fir_filter_ccf.i gr_sig_source_c.i
> vocoder_cvsd_encode_sb.i
> gr_fir_filter_fcc.i gr_sig_source_f.i
> vocoder_g721_decode_bs.i
> gr_fir_filter_fff.i gr_sig_source_i.i
> vocoder_g721_encode_sb.i
> gr_fir_filter_fsf.i gr_sig_source_s.i
> vocoder_g723_24_decode_bs.i
> gr_fir_filter_scc.i gr_simple_correlator.i
> vocoder_g723_24_encode_sb.i
> gr_float_to_char.i    gr_simple_framer.i
> vocoder_g723_40_decode_bs.i
> gr_float_to_complex.i gr_simple_squelch_cc.i
> vocoder_g723_40_encode_sb.i
> gr_float_to_int.i gr_single_pole_iir_filter_cc.i
> vocoder_gsm_fr_decode_ps.i
> gr_float_to_short.i gr_single_pole_iir_filter_ff.i
> vocoder_gsm_fr_encode_sp.i
> gr_float_to_uchar.i gr_single_threaded_scheduler.i
> vocoder_swig_doc.i
> gr_fmdet_cf.i gr_skiphead.i
> vocoder_swig.i
> gr_fractional_interpolator_cc.i gr_squelch_base_cc.i
> vocoder_ulaw_decode_bs.i
> gr_fractional_interpolator_ff.i gr_squelch_base_ff.i
> vocoder_ulaw_encode_sb.i
> gr_framer_sink_1.i    gr_stream_mux.i
> wavelet_swig_doc.i
> gr_frequency_modulator_fc.i gr_streams_to_stream.i
> wavelet_swig.i
> gr_freq_xlating_fir_filter_ccc.i    gr_streams_to_vector.i
> gr_freq_xlating_fir_filter_ccf.i    gr_stream_to_streams.i
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

------------------------------

Message: 2
Date: Tue, 10 Apr 2012 13:42:03 -0400
From: address@hidden
To: <address@hidden>
Subject: Re: [Discuss-gnuradio] swig gnuradio.i cannot find
    gruel_common.i in 3.6.0
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"

There was a 3-line patch that I had to add to CMakelists.txt in the
"swig" subdir to get my gr-pocsag module to build with the latest Gnu
Radio.

I wonder if the latest howto-write-a-block-cmake has been
updated to include that patch?

On Tue, 10 Apr 2012 10:27:15 -0700,
Josh Blum wrote:

> On 04/10/2012 08:49 AM, Justin Ford wrote:
>> I'm
trying to build an existing tool against gnuradio 3.6.0 (master branch
3.6.0git-7-g779d8c67). I'm getting the following error from make when
gnuradio.i is included by swig:
/usr/local/include/gnuradio/swig/gnuradio.i:28: Error: Unable to find
'gruel_common.i' I have attached gnuradio.i from my build, line 28 is
trying to include gruel_common.i. I found gruel_common.i in
/usr/local/include/gruel/swig/, but I think it's expected to be in
/usr/local/include/gnuradio/swig/. Is this an issue with my build? Or
does a change in the more recent master branch version require a patch
to gnuradio.i?
> This looks to be a recent change. The gruel swig stuff
was moved to a new install path include/gruel/swig.
>
>> Should I just
copy (or link) the contents of /usr/local/include/gruel/swig/ to
/usr/local/include/gnuradio/swig/ as a workaround?
> You should add this
path to the swig search path for your application. -josh Thanks for any
gu
>
>>
86-002.build.bos.redhat.com">address@hidden)
(gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) ) #1 SMP Fri Feb 10
15:22:22 EST 2012 $ gnuradio-config-info -v 3.6.0git-7-g779d8c67 $ ls
/usr/local/include/gruel/swig/ gr_intrusive_ptr.i gruel_common.i
pmt_swig_doc.i pmt_swig.i $ ls /usr/local/include/gnuradio/swig/ atsc.i
gr_freq_xlating_fir_filter_fcc.i gr_stream_to_vector.i atsc_swig_doc.i
gr_freq_xlating_fir_filter_fcf.i gr_stretch_ff.i audio_swig_doc.i
gr_freq_xlating_fir_filter_scc.i gr_sub_cc.i audio_swig.i
gr_freq_xlating_fir_filter_scf.i gr_sub_ff.i complex_vec_test.i
gr_glfsr_source_b.i gr_sub_ii.i digital_binary_slicer_fb.i
gr_glfsr_source_f.i gr_sub_ss.i digital_clock_recovery_mm_cc.i
gr_goertzel_fc.i gr_swig_block_magic.i digital_clock_recovery_mm_ff.i
gr_head.i gr_sync_block.i digital_cma_equalizer_cc.i gr_hier_block2.i
gr_sync_decimator.i digital_constellation_decoder_cb.i gr_hilbert_fc.i
gr_sync_interpolator.i digital_constellation.i gr_histo_sink.i
gr_tagged_file_sink.i digital_constellation_receiver_cb.i gri_agc2_cc.i
gr_tags.i digital_correlate_access_code_bb.i gri_agc2_ff.i gr_test.i
digital_costas_loop_cc.i gri_agc_cc.i gr_threshold_ff.i
digital_cpmmod_bc.i gri_agc_ff.i gr_throttle.i digital_crc32.i
gri_control_loop.i gr_top_block.i digital_fll_band_edge_cc.i
gr_iir_filter_ffd.i gr_transcendental.i digital_gmskmod_bc.i
gr_integrate_cc.i gr_uchar_to_float.i digital_kurtotic_equalizer_cc.i
gr_integrate_ff.i gr_udp_sink.i digital_lms_dd_equalizer_cc.i
gr_integrate_ii.i gr_udp_source.i digital_mpsk_receiver_cc.i
gr_integrate_ss.i gr_unpacked_to_packed_bb.i digital_mpsk_snr_est_cc.i
gr_interleaved_short_to_complex.i gr_unpacked_to_packed_ii.i
digital_ofdm_cyclic_prefixer.i gr_interleave.i
gr_unpacked_to_packed_ss.i digital_ofdm_frame_acquisition.i
gr_interp_fir_filter_ccc.i gr_unpack_k_bits_bb.i
digital_ofdm_frame_sink.i gr_interp_fir_filter_ccf.i gr_vco_f.i
digital_ofdm_insert_preamble.i gr_interp_fir_filter_fcc.i
gr_vector_sink_b.i digital_ofdm_mapper_bcv.i gr_interp_fir_filter_fff.i
gr_vector_sink_c.i digital_ofdm_sampler.i gr_interp_fir_filter_fsf.i
gr_vector_sink_f.i digital_probe_mpsk_snr_est_c.i
gr_interp_fir_filter_scc.i gr_vector_sink_i.i digital_swig_doc.i
gr_int_to_float.i gr_vector_sink_s.i digital_swig.i gr_io_signature.i
gr_vector_source_b.i fcd_swig_doc.i gr_iqcomp_cc.i gr_vector_source_c.i
fcd_swig.i gr_keep_one_in_n.i gr_vector_source_f.i filter_generated.i
gr_kludge_copy.i gr_vector_source_i.i filter.i gr_lfsr_32k_source_s.i
gr_vector_source_s.i filter_swig_doc.i gr_map_bb.i gr_vector_to_stream.i
fsm.i gr_max_ff.i gr_vector_to_streams.i general.i gr_max_ii.i
gr_wavfile_sink.i general_swig_doc.i gr_max_ss.i gr_wavfile_source.i
gengen_generated.i gr_message.i gr_xor_bb.i gengen.i gr_message_sink.i
gr_xor_ii.i gengen_swig_doc.i gr_message_source.i gr_xor_ss.i
gnuradio_core_filter.i gr_moving_average_cc.i hier.i
gnuradio_core_general.i gr_moving_average_ff.i hier_swig_doc.i
gnuradio_core_gengen.i gr_moving_average_ii.i interleaver.i
gnuradio_core_hier.i gr_moving_average_ss.i io.i gnuradio_core_io.i
gr_msg_handler.i io_swig_doc.i gnuradio_core_runtime.i gr_msg_queue.i
microtune_4702_eval_board.i gnuradio.i gr_multiply_cc.i
microtune_4937_eval_board.i gr_adaptive_fir_ccc.i
gr_multiply_conjugate_cc.i microtune_xxxx_eval_board.i
gr_adaptive_fir_ccf.i gr_multiply_const_cc.i noaa_hrpt_decoder.i
gr_add_cc.i gr_multiply_const_ff.i noaa_hrpt_deframer.i
gr_add_const_cc.i gr_multiply_const_ii.i noaa_hrpt_pll_cf.i
gr_add_const_ff.i gr_multiply_const_ss.i noaa_swig_doc.i
gr_add_const_ii.i gr_multiply_const_vcc.i noaa_swig.i gr_add_const_sf.i
gr_multiply_const_vff.i pager_flex_deinterleave.i gr_add_const_ss.i
gr_multiply_const_vii.i pager_flex_frame.i gr_add_const_vcc.i
gr_multiply_const_vss.i pager_flex_parse.i gr_add_const_vff.i
gr_multiply_ff.i pager_flex_sync.i gr_add_const_vii.i gr_multiply_ii.i
pager_slicer_fb.i gr_add_const_vss.i gr_multiply_ss.i pager_swig_doc.i
gr_add_ff.i gr_mute_cc.i pager_swig.i gr_add_ii.i gr_mute_ff.i ppio.i
gr_additive_scrambler_bb.i gr_mute_ii.i qtgui_sink_c.i gr_add_ss.i
gr_mute_ss.i qtgui_sink_f.i gr_agc2_cc.i gr_nlog10_ff.i qtgui_swig_doc.i
gr_agc2_ff.i gr_noise_source_c.i qtgui_swig.i gr_agc_cc.i
gr_noise_source_f.i qtgui_time_sink_c.i gr_agc_ff.i gr_noise_source_i.i
qtgui_time_sink_f.i gr_align_on_samplenumbers_ss.i gr_noise_source_s.i
runtime.i gr_and_bb.i gr_nop.i runtime_swig_doc.i gr_and_const_bb.i
gr_not_bb.i sdr_1000.i gr_and_const_ii.i gr_not_ii.i
trellis_constellation_metrics_cf.i gr_and_const_ss.i gr_not_ss.i
trellis_encoder_bb.i gr_and_ii.i gr_null_sink.i trellis_encoder_bi.i
gr_and_ss.i gr_null_source.i trellis_encoder_bs.i gr_annotator_1to1.i
gr_or_bb.i trellis_encoder_ii.i gr_annotator_alltoall.i gr_or_ii.i
trellis_encoder_si.i gr_argmax_fs.i gr_or_ss.i trellis_encoder_ss.i
gr_argmax_is.i gr_oscope_sink.i trellis_generated.i gr_argmax_ss.i
gr_pa_2x2_phase_combiner.i trellis.i gr_basic_block.i
gr_packed_to_unpacked_bb.i trellis_metrics_c.i gr_bin_statistics_f.i
gr_packed_to_unpacked_ii.i trellis_metrics_f.i gr_block_detail.i
gr_packed_to_unpacked_ss.i trellis_metrics_i.i gr_block.i
gr_packet_sink.i trellis_metrics_s.i gr_buffer.i gr_peak_detector2_fb.i
trellis_pccc_decoder_b.i gr_burst_tagger.i gr_peak_detector_fb.i
trellis_pccc_decoder_combined_cb.i gr_bytes_to_syms.i
gr_peak_detector_ib.i trellis_pccc_decoder_combined_ci.i
gr_channel_model.i gr_peak_detector_sb.i
trellis_pccc_decoder_combined_cs.i gr_char_to_float.i
gr_pfb_arb_resampler_ccf.i trellis_pccc_decoder_combined_fb.i
gr_char_to_short.i gr_pfb_arb_resampler_fff.i
trellis_pccc_decoder_combined_fi.i gr_check_counting_s.i
gr_pfb_channelizer_ccf.i trellis_pccc_decoder_combined_fs.i
gr_check_lfsr_32k_s.i gr_pfb_clock_sync_ccf.i trellis_pccc_decoder_i.i
gr_chunks_to_symbols_bc.i gr_pfb_clock_sync_fff.i
trellis_pccc_decoder_s.i gr_chunks_to_symbols_bf.i
gr_pfb_decimator_ccf.i trellis_pccc_encoder_bb.i
gr_chunks_to_symbols_ic.i gr_pfb_interpolator_ccf.i
trellis_pccc_encoder_bi.i gr_chunks_to_symbols_if.i
gr_pfb_synthesizer_ccf.i trellis_pccc_encoder_bs.i
gr_chunks_to_symbols_sc.i gr_phase_modulator_fc.i
trellis_pccc_encoder_ii.i gr_chunks_to_symbols_sf.i
gr_pll_carriertracking_cc.i trellis_pccc_encoder_si.i
gr_complex_to_interleaved_short.i gr_pll_freqdet_cf.i
trellis_pccc_encoder_ss.i gr_complex_to_xxx.i gr_pll_refout_cc.i
trellis_permutation.i gr_conjugate_cc.i gr_pn_correlator_cc.i
trellis_sccc_decoder_b.i gr_constants.i gr_prefs.i
trellis_sccc_decoder_combined_cb.i gr_copy.i gr_probe_avg_mag_sqrd_cf.i
trellis_sccc_decoder_combined_ci.i gr_correlate_access_code_tag_bb.i
gr_probe_avg_mag_sqrd_c.i trellis_sccc_decoder_combined_cs.i
gr_cpfsk_bc.i gr_probe_avg_mag_sqrd_f.i
trellis_sccc_decoder_combined_fb.i gr_cpm.i gr_probe_density_b.i
trellis_sccc_decoder_combined_fi.i gr_ctcss_squelch_ff.i
gr_probe_signal_b.i trellis_sccc_decoder_combined_fs.i
gr_dc_blocker_cc.i gr_probe_signal_c.i trellis_sccc_decoder_i.i
gr_dc_blocker_ff.i gr_probe_signal_f.i trellis_sccc_decoder_s.i
gr_decode_ccsds_27_fb.i gr_probe_signal_i.i trellis_sccc_encoder_bb.i
gr_deinterleave.i gr_probe_signal_s.i trellis_sccc_encoder_bi.i
gr_delay.i gr_probe_signal_vb.i trellis_sccc_encoder_bs.i
gr_descrambler_bb.i gr_probe_signal_vc.i trellis_sccc_encoder_ii.i
gr_diff_decoder_bb.i gr_probe_signal_vf.i trellis_sccc_encoder_si.i
gr_diff_encoder_bb.i gr_probe_signal_vi.i trellis_sccc_encoder_ss.i
gr_diff_phasor_cc.i gr_probe_signal_vs.i trellis_siso_combined_f.i
gr_dispatcher.i gr_pwr_squelch_cc.i trellis_siso_f.i gr_divide_cc.i
gr_pwr_squelch_ff.i trellis_swig_doc.i gr_divide_ff.i
gr_quadrature_demod_cf.i trellis_viterbi_b.i gr_divide_ii.i gr_rail_ff.i
trellis_viterbi_combined_cb.i gr_divide_ss.i
gr_rational_resampler_base_ccc.i trellis_viterbi_combined_ci.i
gr_dpll_bb.i gr_rational_resampler_base_ccf.i
trellis_viterbi_combined_cs.i gr_encode_ccsds_27_bb.i
gr_rational_resampler_base_fcc.i trellis_viterbi_combined_fb.i
gr_endianness.i gr_rational_resampler_base_fff.i
trellis_viterbi_combined_fi.i gr_error_handler.i
gr_rational_resampler_base_fsf.i trellis_viterbi_combined_fs.i
gr_fake_channel_coder_pp.i gr_rational_resampler_base_scc.i
trellis_viterbi_combined_ib.i gr_feedforward_agc_cc.i gr_realtime.i
trellis_viterbi_combined_ii.i gr_feval.i gr_regenerate_bb.i
trellis_viterbi_combined_is.i gr_fft_filter_ccc.i gr_remez.i
trellis_viterbi_combined_sb.i gr_fft_filter_fff.i gr_repeat.i
trellis_viterbi_combined_si.i gr_fft_vcc.i gr_rms_cf.i
trellis_viterbi_combined_ss.i gr_fft_vfc.i gr_rms_ff.i
trellis_viterbi_i.i gr_file_descriptor_sink.i gr_sample_and_hold_bb.i
trellis_viterbi_s.i gr_file_descriptor_source.i gr_sample_and_hold_ff.i
uhd_swig_doc.i gr_file_sink_base.i gr_sample_and_hold_ii.i uhd_swig.i
gr_file_sink.i gr_sample_and_hold_ss.i vocoder_alaw_decode_bs.i
gr_file_source.i gr_scrambler_bb.i vocoder_alaw_encode_sb.i
gr_filter_delay_fc.i gr_shared_ptr.i vocoder_codec2_decode_ps.i
gr_firdes.i gr_short_to_char.i vocoder_codec2_encode_sp.i
gr_fir_filter_ccc.i gr_short_to_float.i vocoder_cvsd_decode_bs.i
gr_fir_filter_ccf.i gr_sig_source_c.i vocoder_cvsd_encode_sb.i
gr_fir_filter_fcc.i gr_sig_source_f.i vocoder_g721_decode_bs.i
gr_fir_filter_fff.i gr_sig_source_i.i vocoder_g721_encode_sb.i
gr_fir_filter_fsf.i gr_sig_source_s.i vocoder_g723_24_decode_bs.i
gr_fir_filter_scc.i gr_simple_correlator.i vocoder_g723_24_encode_sb.i
gr_float_to_char.i gr_simple_framer.i vocoder_g723_40_decode_bs.i
gr_float_to_complex.i gr_simple_squelch_cc.i vocoder_g723_40_encode_sb.i
gr_float_to_int.i gr_single_pole_iir_filter_cc.i
vocoder_gsm_fr_decode_ps.i gr_float_to_short.i
gr_single_pole_iir_filter_ff.i vocoder_gsm_fr_encode_sp.i
gr_float_to_uchar.i gr_single_threaded_scheduler.i vocoder_swig_doc.i
gr_fmdet_cf.i gr_skiphead.i vocoder_swig.i
gr_fractional_interpolator_cc.i gr_squelch_base_cc.i
vocoder_ulaw_decode_bs.i gr_fractional_interpolator_ff.i
gr_squelch_base_ff.i vocoder_ulaw_encode_sb.i gr_framer_sink_1.i
gr_stream_mux.i wavelet_swig_doc.i gr_frequency_modulator_fc.i
gr_streams_to_stream.i wavelet_swig.i gr_freq_xlating_fir_filter_ccc.i
gr_streams_to_vector.i gr_freq_xlating_fir_filter_ccf.i
gr_stream_to_streams.i _______________________________________________
Discuss-gnuradio mailing list address@hidden [1]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]
_______________________________________________ Discuss-gnuradio mailing
list
> address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]

Links:
------
[1] mailto:address@hidden
[2]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[3]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120410/17ac5fa9/attachment.html>

------------------------------

Message: 3
Date: Tue, 10 Apr 2012 11:11:42 -0700
From: Johnathan Corgan <address@hidden>
To: address@hidden
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] swig gnuradio.i cannot find
    gruel_common.i    in 3.6.0
Message-ID:
    <CAOVQDDMg6g_J0HhoJq0re=address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 10, 2012 at 10:42, <address@hidden> wrote:

> There was a 3-line patch that I had to add to CMakelists.txt in the "swig"
> subdir to get my gr-pocsag module to build with the latest Gnu Radio.
>
> I wonder if the latest howto-write-a-block-cmake has been updated to include
> that patch?

Probably not. Please send. Also, on the new master branch, the howto
no longer has 'cmake' in the directory name.

Johnathan

------------------------------

Message: 4
Date: Tue, 10 Apr 2012 14:15:03 -0400
From: address@hidden
To: Johnathan Corgan <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] swig gnuradio.i cannot find
    gruel_common.i in 3.6.0
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"

OK, I'll snarfle through my stuff sometime this evening and send a
patch. I got the original patch from the OSMOCOM folks in .DE, when they
tried to build gr-pocsag on the very-latest, and it failed.

On Tue, 10
Apr 2012 11:11:42 -0700, Johnathan Corgan wrote:

> On Tue, Apr 10,
2012 at 10:42, wrote:
>
>> There was a 3-line patch that I had to add
to CMakelists.txt in the "swig" subdir to get my gr-pocsag module to
build with the latest Gnu Radio. I wonder if the latest
howto-write-a-block-cmake has been updated to include that patch?
>
Probably not. Please send. Also, on the new master branch, the howto no
longer has 'cmake' in the directory name. Johnathan

Links:
------
[1] mailto:address@hidden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120410/4f3b4cb5/attachment.html>

------------------------------

Message: 5
Date: Tue, 10 Apr 2012 11:34:20 -0700 (PDT)
From: sibar002 <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Modifying C++ Files
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

Hello,

I am attempting to modify the bpsk.py file in order to obtain OOK
modulation. I would like to change my constellation points to 1+0i and 0+0i.
I understand that the digital_costellation.cc file is being used to set
these parameters. I have tried to modify the digitial_constellation.cc file
in the gr-digital folder, but I am not able to see any changes. I have made
sure that I make and make install every time I change the file. I was hoping
someone could tell me what I am doing wrong. I would greatly appreciate any
help or advice that anyone could give me. Thank you for your time and help.

Sam

--
View this message in context: http://old.nabble.com/Modifying-C%2B%2B-Files-tp33663518p33663518.html
Sent from the GnuRadio mailing list archive at Nabble.com.

------------------------------

Message: 6
Date: Tue, 10 Apr 2012 12:55:58 -0600
From: Justin Ford <address@hidden>
To: address@hidden
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] swig gnuradio.i cannot find
    gruel_common.i    in 3.6.0
Message-ID:
    <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

Thanks, Josh. That got me past the swig error. Now I've got new
trouble but it's not clear what the issue is yet...

I appreciate your help!
Justin

>> Should I just copy (or link) the contents of
>> /usr/local/include/gruel/swig/ to /usr/local/include/gnuradio/swig/ as
>> a workaround?
>>
>
> You should add this path to the swig search path for your application.
>
> -josh
>

------------------------------

Message: 7
Date: Tue, 10 Apr 2012 11:55:48 -0700
From: Johnathan Corgan <address@hidden>
To: Bogdan Diaconescu <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Data lost whe using big file sources
Message-ID:
    <CAOVQDDP=kq-kF-jJBkr7-g-6O9h9dSMPi=8+SuEmOXZKWn=address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 10, 2012 at 04:22, Bogdan Diaconescu <address@hidden> wrote:

> I never had time to look into this but I always speculated that the code that takes the data from the files does not expect the data to be available.

Can you elaborate on this?

Does the data that you are getting incorrectly, resemble any other
portion of the file, is it random garbage, flipped bits, or something
else?

Do you have the repeat option set to true or false?

Are you calling consume_each() with the proper individual values for
what was available from each of the inputs and what you processed out
of each?

FYI, I've successfully used file sources on tens of gigabyte size
input capture files with no issues. Not saying there isn't any, but
this is a fairly widely exercised bit of code.

You might want to start printing or writing to a disk file the values
of all the parameters given to the general_work() function when it is
called, the values given to consume_each(), and the return value from
general_work(), then look for a pattern for when there is corrupted
input data.

Johnathan

------------------------------

Message: 8
Date: Tue, 10 Apr 2012 11:59:29 -0700 (PDT)
From: frankist <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Problem in the update
Message-ID: <address@hidden>
Content-Type: text/plain; charset=UTF-8

Ok got it.

Now I am trying to uninstall gnuradio. I am a bit nervous because it is my
first uninstall and the computer isn't mine.

I am doing as http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ tells
me, however, I can't find anything with the name gnuradio or similar in
these folders: /usr/bin, /usr/lib(64). Furthermore, I don't have the folder
/usr/local/lib(64) in the computer. I wonder if this is normal

I just want to check before starting deleting files. I don't want things to
get worse than they are right now

Marcus D. Leech wrote:
>
>
>
> It removes anything that was installed from binary *packages*. But
> if you have a previous source install, it doesn't go around trying to
> hunt down all the artifacts from that install and try to remove them.
> That would be really hard, because the new gnuradio source pack won't
> include uninstall instructions for the old install, and the old install
> source lump may not be lying around, so there's no "manifest" for it to
> work from.
>
> -Marcus
>
> On Tue, 10 Apr 2012 08:29:38 -0700 (PDT),
> frankist wrote:
>
>> Yeah. I used the build-gnuradio script that says
> that it removes the old
>> versions. Probably there was some error in the
> installation that I didn't
>> notice...
>>
>> Martin Braun-4 wrote:
>>> On
> Tue, Apr 10, 2012 at 08:13:56AM -0700, frankist wrote:
>>>
>>>>>>
> File
>>>>
> "/usr/local/lib/python2.6/dist-packages/gnuradio/blks2impl/gmsk.py",
>>>
> In fact, I should have responded to this line in the first place. This
> file should *not* exist after the update. Looks like you did something
> wrong while removing the old files before updating. 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 [1] KIT -- University of the State of Baden-W?rttemberg
> and National Laboratory of the Helmholtz Association
> _______________________________________________ Discuss-gnuradio mailing
> list address@hidden [2]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]
>
>
>
>
> Links:
> ------
> [1] http://www.cel.kit.edu
> [2]
> mailto:address@hidden
> [3]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
View this message in context: http://old.nabble.com/Problem-in-the-update-tp33661146p33663653.html
Sent from the GnuRadio mailing list archive at Nabble.com.

------------------------------

Message: 9
Date: Tue, 10 Apr 2012 22:16:54 +0200
From: Rickard <address@hidden>
To: Tom Rondeau <address@hidden>
Cc: GNU Radio mailing list <address@hidden>
Subject: Re: [Discuss-gnuradio] [USRP-users] Gnu Radio apps freezes
    (locks    up)
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

On 31 mar 2012, at 15.43, Tom Rondeau wrote:

> On Thu, Mar 29, 2012 at 6:04 AM, Rickard Radio <address@hidden> wrote:
>>
>> On Mar 29, 2012, at 3:26 AM, Tom Rondeau wrote:
>>
>>> On Wed, Mar 28, 2012 at 10:02 AM, Rickard Radio <address@hidden> wrote:
>>>> Hi list,
>>>>
>>>> After I upgraded to latest Gnu Radio 3.5.2, and latest UHD (and images), GR applications just freeze when running. No warnings, error messages or overflows etc. Just freeze.
>>>> A simple FFT plot directly on received samples from the USRPN210 just freezes after some seconds, or minutes (depending on the sample rate), although the load on the machine is not high. Need to kill GR-app and restart it, with the same problem occurring again.
>>>>
>>>> This has never been a problem with earlier versions of GR/UHD, from about 6 months ago.
>>>> The freezing happens quicker with high sample rate setting but also with lower, eventually. No overflows happen (which was possible to get before with too high sample rates or load, etc.)
>>>>
>>>> The USRPN210 stops sending samples to the computer at the same moment as GnuRadio freezes (as observed on the system monitor).
>>>>
>>>> Same thing happen on two identical laptops running Ubuntu 10.10 (also upgraded it from 10.04). Not sure if its a strict GnuRadio problem (since it worked before), UHD, or some problem with the Ubuntu Linux 10.10. It work(ed) flawlessly with another machine on OSX (before I tried to upgrade GR on it but then got stuck...) with identical UHD version and images.
>>>>
>>>> Installation of UHD+GnuRadio with the automatic linux script runs without any problems, as before, no errors or warnings.
>>>>
>>>> Any de-freezing help or clues appreciated!
>>>>
>>>> Rickard
>>>
>>> Rickard,
>>>
>>> Just to be clear. When you install 3.5.2 from the tarball, it freezes.
>>> When you use the build-gnuradio, everything works fine?
>>>
>>> What's your machine?
>>>
>>> Tom
>>
>> Tom,
>>
>> The installation with build-gnuradio script works just fine, as before (no tarballs).
>> Same result on both laptops, Acer Aspire TimelineX with i3 processors (2.26 GHz), running Ubuntu 10.10.
>> I did not have this problem earlier with Ubuntu 10.04. Or on a Mac with OS X (with the source from git). Could Ubuntu 10.10 cause the problem somehow?
>>
>> Note: Halting/freezing only happens when running an application (with the N210) as a receiver. (Not transmitter, see below.)
>> The flow of receiving samples just halts after a while and the application freezes/halts (as a consequence).
>> This happen sooner with high sampling rate (after a few seconds with 25MSPS), but eventually also with a bit lower sample rates. The CPU's are not overwhelmed (< 50%).
>> It happens even if the UHD usrp source is connected directly to a null sink only. I do not get any overflows before the halt.
>> In fact, I cannot even provoke a continuos stream of overflows since the reception just halts instead of producing overflows, which was the result earlier.
>> GnuRadio itself does not freeze as a whole (like the grc in the background), just the running application, which I then need to abort.
>>
>> Strangely enough, this "freezing/halting" does NOT happen when transmitting, correspondingly, even with high transmit sample rates such as 25 MSPS (or now possible even with 50MSPS with 8 bit/samples!). Then it works just fine - even without underruns (when using just a file source).
>>
>>
>> / Rickard
>
>
> Rickard,
>
> Thanks for the data. Unfortunately, I have no idea what to make of
> this. There isn't that much difference between the last release
> (3.5.2.1) and what you get using the build-gnuradio script. That just
> grabs the latest master version from our git repo, and we haven't done
> all that much since the release. That really doesn't make a lot of
> sense.
>
> How's your git? If you're comfortable doing so, can you check out the
> v3.5.2.1 tag on git and try that one instead of the tarball release?
>
> Thanks,
> Tom

Thanks for your info. My current take on this interrupt issue:

The problem may not be gnuradio or uhd's "fault", I now suspect. Instead somehow the network connection and its settings might cause the interrupts. However, I am no linux guru so I am learning at the same time as I am doing.

First, I've updated Ubuntu, from release 10.10 to 11.04, but then nothing worked (just got a completely blank screen without any gui), so fast-forward upgraded to 11.10 and then both laptops came right back on track. I then also updated the gnuradio+uhd to latest (3.6.0) version using the excellent build-gnuradio script (as before), which itself went just fine (also as before).

Unfortunately, the exact same problem with interrupts (total halt) in the receiver at high sample rates persists. Note, as before, this happens (only?) with very high rates over the Ethernet (about 400 mbit/s or more, the higher rate the sooner it halts, typically just a few secs) although the computer display no overruns or other errors.

Then by jacking around with the MTU setting (100,500, 1500,5000, etc), increasing the default too low (and initially also gnuradio complaining) buffer settings (net.core.rmem_max, net.core.wmem_max), disabling the Ubuntu network manager (via the menu) and removing the automatic network configuration when USRPN210 connects and instead setting up the network connection manually with "sudo ifconfig eth1 192.168.10.1" , I *sometimes* can get the Ethernet connection into a state to work with the N210 at high sampling rates without any interruptions at all !

In that case, a beautiful continuous flow of samples to the crunching computer (like a fft-plot), at highest possible rate 50 MSPS, 8 bit/samples over the wire. This *can* happen with a MTU above 1500 (or more), buffers increased to recommended settings by UHD, and when this works the Ubuntu system manager tells me that some 834 Mbit/samples flows through the Ethernet cable, and about 50% load on the CPU-cores, very nice. Then it also works for repeated runs, not just one "lucky" one, and for a prolonged period of time (more than an hour). In the working network state I can also easily provoke nice expected overruns, strings of 'ooooooooooo':hs, which isn't possible when the Ethernet connection is in the "wrong" and "interrupted" state - since then it just halts/stops without further info.

However, finding this working network state is not just a matter of setting the particular network parameters as I hoped it to be... I suspect some other things are happening behind the scenes, maybe some other settings etc (I do not yet have full knowledge of ethernets full functionality and behavior, there may be more influencing parameters ?) which prevent me finding the working network state in a consistent manner. Quite weird.

I have USRP-N210 rev2 (says sticker on the back) but now noticed that when I burned the latest fw and fpga images with the net burner tool it prints "Hardware type: n210_r3" although I selected the fpga version image for rev2 corresponding to my version. Could this be related to my issue? Haven't noticed that inconsistent message earlier, though.

If some of this rings any bells, please give me some further advise.
Sorry for long post.

Thanks,
Rickard

------------------------------

Message: 10
Date: Tue, 10 Apr 2012 16:51:21 -0400
From: "Marcus D. Leech" <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] [USRP-users] Gnu Radio apps freezes
    (locks up)
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

> Rickard,
>
> Thanks for the data. Unfortunately, I have no idea what to make of
> this. There isn't that much difference between the last release
> (3.5.2.1) and what you get using the build-gnuradio script. That just
> grabs the latest master version from our git repo, and we haven't done
> all that much since the release. That really doesn't make a lot of
> sense.
>
> How's your git? If you're comfortable doing so, can you check out the
> v3.5.2.1 tag on git and try that one instead of the tarball release?
>
> Thanks,
> Tom
>
>
> Thanks for your info. My current take on this interrupt issue:
>
> The problem may not be gnuradio or uhd's "fault", I now suspect. Instead somehow the network connection and its settings might cause the interrupts. However, I am no linux guru so I am learning at the same time as I am doing.
>
> First, I've updated Ubuntu, from release 10.10 to 11.04, but then nothing worked (just got a completely blank screen without any gui), so fast-forward upgraded to 11.10 and then both laptops came right back on track. I then also updated the gnuradio+uhd to latest (3.6.0) version using the excellent build-gnuradio script (as before), which itself went just fine (also as before).
>
> Unfortunately, the exact same problem with interrupts (total halt) in the receiver at high sample rates persists. Note, as before, this happens (only?) with very high rates over the Ethernet (about 400 mbit/s or more, the higher rate the sooner it halts, typically just a few secs) although the computer display no overruns or other errors.
>
> Then by jacking around with the MTU setting (100,500, 1500,5000, etc), increasing the default too low (and initially also gnuradio complaining) buffer settings (net.core.rmem_max, net.core.wmem_max), disabling the Ubuntu network manager (via the menu) and removing the automatic network configuration when USRPN210 connects and instead setting up the network connection manually with "sudo ifconfig eth1 192.168.10.1" , I *sometimes* can get the Ethernet connection into a state to work with the N210 at high sampling rates without any interruptions at all !
>
> In that case, a beautiful continuous flow of samples to the crunching computer (like a fft-plot), at highest possible rate 50 MSPS, 8 bit/samples over the wire. This *can* happen with a MTU above 1500 (or more), buffers increased to recommended settings by UHD, and when this works the Ubuntu system manager tells me that some 834 Mbit/samples flows through the Ethernet cable, and about 50% load on the CPU-cores, very nice. Then it also works for repeated runs, not just one "lucky" one, and for a prolonged period of time (more than an hour). In the working network state I can also easily provoke nice expected overruns, strings of 'ooooooooooo':hs, which isn't possible when the Ethernet connection is in the "wrong" and "interrupted" state - since then it just halts/stops without further info.
>
> However, finding this working network state is not just a matter of setting the particular network parameters as I hoped it to be... I suspect some other things are happening behind the scenes, maybe some other settings etc (I do not yet have full knowledge of ethernets full functionality and behavior, there may be more influencing parameters ?) which prevent me finding the working network state in a consistent manner. Quite weird.
>
> I have USRP-N210 rev2 (says sticker on the back) but now noticed that when I burned the latest fw and fpga images with the net burner tool it prints "Hardware type: n210_r3" although I selected the fpga version image for rev2 corresponding to my version. Could this be related to my issue? Haven't noticed that inconsistent message earlier, though.
>
> If some of this rings any bells, please give me some further advise.
> Sorry for long post.
>
> Thanks,
> Rickard
>
>
>

Rickard:

I have run 50Msps/8-bit for hours on end with my system here, which is
Fedora 14, and using cheap RTL-based network cards.

There *is* a known *hardware* problem with certain Intel 1GiGe
chipsets--the 82577LM and 82579LM have problems that sound similar
   to what you're reporting at high sample rates.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

------------------------------

Message: 11
Date: Tue, 10 Apr 2012 14:55:10 -0700
From: Nick Foster <address@hidden>
To: Rickard <address@hidden>
Cc: GNU Radio mailing list <address@hidden>
Subject: Re: [Discuss-gnuradio] [USRP-users] Gnu Radio apps freezes
    (locks    up)
Message-ID:
    <CALALHJVhBW=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

On Tue, Apr 10, 2012 at 1:16 PM, Rickard <address@hidden> wrote:

>
> On 31 mar 2012, at 15.43, Tom Rondeau wrote:
>
> > On Thu, Mar 29, 2012 at 6:04 AM, Rickard Radio <address@hidden>
> wrote:
> >>
> >> On Mar 29, 2012, at 3:26 AM, Tom Rondeau wrote:
> >>
> >>> On Wed, Mar 28, 2012 at 10:02 AM, Rickard Radio <
> address@hidden> wrote:
> >>>> Hi list,
> >>>>
> >>>> After I upgraded to latest Gnu Radio 3.5.2, and latest UHD (and
> images), GR applications just freeze when running. No warnings, error
> messages or overflows etc. Just freeze.
> >>>> A simple FFT plot directly on received samples from the USRPN210 just
> freezes after some seconds, or minutes (depending on the sample rate),
> although the load on the machine is not high. Need to kill GR-app and
> restart it, with the same problem occurring again.
> >>>>
> >>>> This has never been a problem with earlier versions of GR/UHD, from
> about 6 months ago.
> >>>> The freezing happens quicker with high sample rate setting but also
> with lower, eventually. No overflows happen (which was possible to get
> before with too high sample rates or load, etc.)
> >>>>
> >>>> The USRPN210 stops sending samples to the computer at the same moment
> as GnuRadio freezes (as observed on the system monitor).
> >>>>
> >>>> Same thing happen on two identical laptops running Ubuntu 10.10 (also
> upgraded it from 10.04). Not sure if its a strict GnuRadio problem (since
> it worked before), UHD, or some problem with the Ubuntu Linux 10.10. It
> work(ed) flawlessly with another machine on OSX (before I tried to upgrade
> GR on it but then got stuck...) with identical UHD version and images.
> >>>>
> >>>> Installation of UHD+GnuRadio with the automatic linux script runs
> without any problems, as before, no errors or warnings.
> >>>>
> >>>> Any de-freezing help or clues appreciated!
> >>>>
> >>>> Rickard
> >>>
> >>> Rickard,
> >>>
> >>> Just to be clear. When you install 3.5.2 from the tarball, it freezes.
> >>> When you use the build-gnuradio, everything works fine?
> >>>
> >>> What's your machine?
> >>>
> >>> Tom
> >>
> >> Tom,
> >>
> >> The installation with build-gnuradio script works just fine, as before
> (no tarballs).
> >> Same result on both laptops, Acer Aspire TimelineX with i3 processors
> (2.26 GHz), running Ubuntu 10.10.
> >> I did not have this problem earlier with Ubuntu 10.04. Or on a Mac with
> OS X (with the source from git). Could Ubuntu 10.10 cause the problem
> somehow?
> >>
> >> Note: Halting/freezing only happens when running an application (with
> the N210) as a receiver. (Not transmitter, see below.)
> >> The flow of receiving samples just halts after a while and the
> application freezes/halts (as a consequence).
> >> This happen sooner with high sampling rate (after a few seconds with
> 25MSPS), but eventually also with a bit lower sample rates. The CPU's are
> not overwhelmed (< 50%).
> >> It happens even if the UHD usrp source is connected directly to a null
> sink only. I do not get any overflows before the halt.
> >> In fact, I cannot even provoke a continuos stream of overflows since
> the reception just halts instead of producing overflows, which was the
> result earlier.
> >> GnuRadio itself does not freeze as a whole (like the grc in the
> background), just the running application, which I then need to abort.
> >>
> >> Strangely enough, this "freezing/halting" does NOT happen when
> transmitting, correspondingly, even with high transmit sample rates such as
> 25 MSPS (or now possible even with 50MSPS with 8 bit/samples!). Then it
> works just fine - even without underruns (when using just a file source).
> >>
> >>
> >> / Rickard
> >
> >
> > Rickard,
> >
> > Thanks for the data. Unfortunately, I have no idea what to make of
> > this. There isn't that much difference between the last release
> > (3.5.2.1) and what you get using the build-gnuradio script. That just
> > grabs the latest master version from our git repo, and we haven't done
> > all that much since the release. That really doesn't make a lot of
> > sense.
> >
> > How's your git? If you're comfortable doing so, can you check out the
> > v3.5.2.1 tag on git and try that one instead of the tarball release?
> >
> > Thanks,
> > Tom
>
>
>
> Thanks for your info. My current take on this interrupt issue:
>
> The problem may not be gnuradio or uhd's "fault", I now suspect. Instead
> somehow the network connection and its settings might cause the interrupts.
> However, I am no linux guru so I am learning at the same time as I am doing.
>
> First, I've updated Ubuntu, from release 10.10 to 11.04, but then nothing
> worked (just got a completely blank screen without any gui), so
> fast-forward upgraded to 11.10 and then both laptops came right back on
> track. I then also updated the gnuradio+uhd to latest (3.6.0) version using
> the excellent build-gnuradio script (as before), which itself went just
> fine (also as before).
>
> Unfortunately, the exact same problem with interrupts (total halt) in the
> receiver at high sample rates persists. Note, as before, this happens
> (only?) with very high rates over the Ethernet (about 400 mbit/s or more,
> the higher rate the sooner it halts, typically just a few secs) although
> the computer display no overruns or other errors.
>
> Then by jacking around with the MTU setting (100,500, 1500,5000, etc),
> increasing the default too low (and initially also gnuradio complaining)
> buffer settings (net.core.rmem_max, net.core.wmem_max), disabling the
> Ubuntu network manager (via the menu) and removing the automatic network
> configuration when USRPN210 connects and instead setting up the network
> connection manually with "sudo ifconfig eth1 192.168.10.1" , I *sometimes*
> can get the Ethernet connection into a state to work with the N210 at high
> sampling rates without any interruptions at all !
>
> In that case, a beautiful continuous flow of samples to the crunching
> computer (like a fft-plot), at highest possible rate 50 MSPS, 8 bit/samples
> over the wire. This *can* happen with a MTU above 1500 (or more), buffers
> increased to recommended settings by UHD, and when this works the Ubuntu
> system manager tells me that some 834 Mbit/samples flows through the
> Ethernet cable, and about 50% load on the CPU-cores, very nice. Then it
> also works for repeated runs, not just one "lucky" one, and for a prolonged
> period of time (more than an hour). In the working network state I can
> also easily provoke nice expected overruns, strings of 'ooooooooooo':hs,
> which isn't possible when the Ethernet connection is in the "wrong" and
> "interrupted" state - since then it just halts/stops without further info.
>
> However, finding this working network state is not just a matter of
> setting the particular network parameters as I hoped it to be... I suspect
> some other things are happening behind the scenes, maybe some other
> settings etc (I do not yet have full knowledge of ethernets full
> functionality and behavior, there may be more influencing parameters ?)
> which prevent me finding the working network state in a consistent manner.
> Quite weird.
>
> I have USRP-N210 rev2 (says sticker on the back) but now noticed that when
> I burned the latest fw and fpga images with the net burner tool it prints
> "Hardware type: n210_r3" although I selected the fpga version image for
> rev2 corresponding to my version. Could this be related to my issue?
> Haven't noticed that inconsistent message earlier, though.
>
> If some of this rings any bells, please give me some further advise.
> Sorry for long post.
>
> Thanks,
> Rickard
>

My first guess is that network-manager sucks, and it's cutting your
connection. I've seen this on Ubuntu on a semi-regular basis even on my own
laptop, when using ifconfig to set the adapter address manually, sometimes
network-manager decides to bring the interface down just because. To
diagnose this, look to see the network light on the N210 go out after the
samples stop coming. The solution is to go into the network configuration
and set eth0 (or whatever network adapter it is) to use a static IP address
instead of "auto".

--n

>
>
>
>
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120410/33d253a7/attachment.html>

------------------------------

Message: 12
Date: Wed, 11 Apr 2012 10:13:59 +1000
From: Adam Nielsen <address@hidden>
To: frankist <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Problem in the update
Message-ID: <address@hidden>
Content-Type: text/plain; charset=UTF-8; format=flowed

> Now I am trying to uninstall gnuradio. I am a bit nervous because it is my
> first uninstall and the computer isn't mine.
>
> I am doing as http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ tells
> me, however, I can't find anything with the name gnuradio or similar in
> these folders: /usr/bin, /usr/lib(64). Furthermore, I don't have the folder
> /usr/local/lib(64) in the computer. I wonder if this is normal
>
> I just want to check before starting deleting files. I don't want things to
> get worse than they are right now

If you want to get every last file, and you know exactly how the old version
was compiled (ideally down to the ./configure command) then you could always
download that old version, compile it, then run 'make uninstall'. This will
remove all the files that would have been installed, so if it matches your
original config, every last file in your existing gnuradio installation will
be removed.

Of course that's probably overkill, and if you just move the files to another
folder instead of deleting them, then you can always move them back if
something breaks. In answer to your question, often /usr/local is empty until
you start installing things yourself, so having no /usr/local/lib is not unusual.

But if you're going to do the install on lab computers (where presumably there
are a number of identical ones) you'd probably be better off taking the
opportunity to make a package for whatever OS you're running. Then you can
install the same package on all your machines quickly, and when the time comes
to do the next update the package manager will take care of removing the old
files for you.

Cheers,
Adam.

------------------------------

Message: 13
Date: Tue, 10 Apr 2012 19:09:44 -0700
From: Ben Reynwar <address@hidden>
To: sibar002 <address@hidden>,     discuss-gnuradio Discussion Group
    <address@hidden>
Subject: Re: [Discuss-gnuradio] Modifying C++ Files
Message-ID:
    <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

Hi Sam,

In bpsk.py you'll see the line

constellation = digital_swig.constellation_bpsk()

If you change this to:

constellation = digital.constellation_calcdist((1+0i, 0+0i), [], 1, 1)

, you should get the change in modulation you want.

You only need to mess with the digital_constellation.cc file if you
want to implement an efficient non-generic
decision maker for this modulation.

To know why what you're doing isn't working, I'd need to know what
modifications you're making to the .cc file. It sounds like you're
doing everything right.

Cheers,
Ben

On Tue, Apr 10, 2012 at 11:34 AM, sibar002 <address@hidden> wrote:
>
> Hello,
>
> I am attempting to modify the bpsk.py file in order to obtain OOK
> modulation. I would like to change my constellation points to 1+0i and 0+0i.
> I understand that the digital_costellation.cc file is being used to set
> these parameters. I have tried to modify the digitial_constellation.cc file
> in the gr-digital folder, but I am not able to see any changes. I have made
> sure that I make and make install every time I change the file. I was hoping
> someone could tell me what I am doing wrong. I would greatly appreciate any
> help or advice that anyone could give me. Thank you for your time and help.
>
> Sam
>
> --
> View this message in context: http://old.nabble.com/Modifying-C%2B%2B-Files-tp33663518p33663518.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

------------------------------

Message: 14
Date: Wed, 11 Apr 2012 06:50:39 -0700 (PDT)
From: frankist <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Problem in the update
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

Adam Nielsen wrote:
>
>> Now I am trying to uninstall gnuradio. I am a bit nervous because it is
>> my
>> first uninstall and the computer isn't mine.
>>
>> I am doing as http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ
>> tells
>> me, however, I can't find anything with the name gnuradio or similar in
>> these folders: /usr/bin, /usr/lib(64). Furthermore, I don't have the
>> folder
>> /usr/local/lib(64) in the computer. I wonder if this is normal
>>
>> I just want to check before starting deleting files. I don't want things
>> to
>> get worse than they are right now
>
> If you want to get every last file, and you know exactly how the old
> version
> was compiled (ideally down to the ./configure command) then you could
> always
> download that old version, compile it, then run 'make uninstall'. This
> will
> remove all the files that would have been installed, so if it matches your
> original config, every last file in your existing gnuradio installation
> will
> be removed.
>
> Of course that's probably overkill, and if you just move the files to
> another
> folder instead of deleting them, then you can always move them back if
> something breaks. In answer to your question, often /usr/local is empty
> until
> you start installing things yourself, so having no /usr/local/lib is not
> unusual.
>
> But if you're going to do the install on lab computers (where presumably
> there
> are a number of identical ones) you'd probably be better off taking the
> opportunity to make a package for whatever OS you're running. Then you
> can
> install the same package on all your machines quickly, and when the time
> comes
> to do the next update the package manager will take care of removing the
> old
> files for you.
>
> Cheers,
> Adam.
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

Ok. Thanks for the tips.

I had to remove gnuradio manually because no make uninstall was working.

Right now, I am trying to install the old version. That might seem odd but
the program I have to show working friday, which wasn't made by me, only
works for the old version. I tried to adapt it to the new version and it
runs however, it doesn't have the same behavior has it had for the old
installation. Since it wasn't me who did the code I feel safer using the old
version for now.

I've found the gnuradio installation folder used by someone before me. I
installed the 3.4.1 version with it. However it didn't install the uhd.

The instructions I found for installing the uhd seem to install the newer
version. However, I want the version that works with 3.4.1. Any suggestion?
--
View this message in context: http://old.nabble.com/Problem-in-the-update-tp33661146p33668780.html
Sent from the GnuRadio mailing list archive at Nabble.com.

------------------------------

Message: 15
Date: Wed, 11 Apr 2012 10:53:58 -0500
From: Javier Suarez <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Question about sampling rate
Message-ID:
    <CAD4x-E_OaCE-1_o9OC80y3Zko-53ZKQ_dm_B4We8qmpMJe+address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

Hi everyone...
I am getting confused about the use of the parameter of sampling rate in
GNU RADIO.
I really need to understand the sampling rate of the uhd sink and source
and the sampling rate of the blocks in the flow graph and how to choose
those sampling rates.

Thanks a lot for you help!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120411/00cf1861/attachment.html>

------------------------------

Message: 16
Date: Wed, 11 Apr 2012 08:58:08 -0700
From: Nick Foster <address@hidden>
To: Javier Suarez <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Question about sampling rate
Message-ID:
    <CALALHJVtxwaynv3i28xtFOHZ=fbB4NYAb=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

On Wed, Apr 11, 2012 at 8:53 AM, Javier Suarez <address@hidden> wrote:

> Hi everyone...
> I am getting confused about the use of the parameter of sampling rate in
> GNU RADIO.
> I really need to understand the sampling rate of the uhd sink and source
> and the sampling rate of the blocks in the flow graph and how to choose
> those sampling rates.
>
> Thanks a lot for you help!!
>

Sample rate is a fundamental parameter of digital signal processing. Try an
introductory DSP textbook, or the following articles:
http://en.wikipedia.org/wiki/Discrete_signal
http://en.wikipedia.org/wiki/Sampling_rate
http://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem
http://en.wikipedia.org/wiki/Sampling_(signal_processing)
http://en.wikipedia.org/wiki/Aliasing

Without a basic understanding of sampling theory or DSP you will have
difficulty progressing with Gnuradio.

--n

>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120411/7e6cbe33/attachment.html>

------------------------------

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

End of Discuss-gnuradio Digest, Vol 113, Issue 12
*************************************************

From:	guelord ingala
Subject:	[Discuss-gnuradio] Re : Discuss-gnuradio Digest, Vol 113, Issue 12
Date:	Thu, 12 Apr 2012 07:21:56 +0100 (BST)