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

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!!

Hi, I believe you might have a good background on signal processing and
the theory behind Sample rate. But GNU Radio is not that “easy” for
beginners at the first look. If your are using the Gnu Radio Companion
(grc), then read the following tutorials. They can help you.

  1. http://www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_tutorial1.pdf
  2. www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_tutorial2.pdf
  3. www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_tutorial3.pdf
    4 www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_tutorial4.pdf

Dominique.

— En date de: Mer 11.4.12, [email protected]
[email protected] a crit:

De: [email protected] [email protected]
Objet: Discuss-gnuradio Digest, Vol 113, Issue 12
: [email protected]
Date: Mercredi 11 avril 2012, 18h00

Send Discuss-gnuradio mailing list submissions to
[email protected]

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
[email protected]

You can reach the person managing the list at
[email protected]

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 B.)
  2. Re: swig gnuradio.i cannot find gruel_common.i in 3.6.0
    ([email protected])
  3. Re: swig gnuradio.i cannot find gruel_common.i in 3.6.0
    (Johnathan C.)
  4. Re: swig gnuradio.i cannot find gruel_common.i in 3.6.0
    ([email protected])
  5. Modifying C++ Files (sibar002)
  6. Re: swig gnuradio.i cannot find gruel_common.i in 3.6.0
    (Justin F.)
  7. Re: Data lost whe using big file sources (Johnathan C.)
  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 F.)
  12. Re: Problem in the update (Adam Nielsen)
  13. Re: Modifying C++ Files (Ben R.)
  14. Re: Problem in the update (frankist)
  15. Question about sampling rate (Javier S.)
  16. Re: Question about sampling rate (Nick F.)

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

On 04/10/2012 08:49 AM, Justin F. wrote:

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

audio_swig.i gr_freq_xlating_fir_filter_scf.i
gr_sync_decimator.i
digital_cpmmod_bc.i gri_agc_ff.i
gr_udp_source.i
digital_ofdm_insert_preamble.i gr_interp_fir_filter_fcc.i
gr_vector_source_b.i
fsm.i gr_max_ff.i
gr_xor_ss.i
gnuradio_core_runtime.i gr_msg_queue.i
noaa_hrpt_pll_cf.i
gr_add_const_vff.i gr_multiply_ff.i
qtgui_sink_c.i
gr_align_on_samplenumbers_ss.i gr_noise_source_s.i
trellis_encoder_bi.i
gr_argmax_ss.i gr_pa_2x2_phase_combiner.i
trellis_pccc_decoder_b.i
gr_check_counting_s.i gr_pfb_channelizer_ccf.i
trellis_pccc_encoder_bs.i
gr_constants.i gr_prefs.i
trellis_sccc_decoder_combined_fs.i
gr_descrambler_bb.i gr_probe_signal_vc.i
trellis_swig_doc.i
gr_endianness.i gr_rational_resampler_base_fff.i
trellis_viterbi_combined_sb.i
gr_file_sink_base.i gr_sample_and_hold_ii.i
vocoder_cvsd_decode_bs.i
gr_float_to_char.i gr_simple_framer.i
vocoder_swig.i


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Message: 2
Date: Tue, 10 Apr 2012 13:42:03 -0400
From: [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] swig gnuradio.i cannot find
gruel_common.i in 3.6.0
Message-ID: [email protected]
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 B. wrote:

On 04/10/2012 08:49 AM, Justin F. 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">[email protected])
(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 [email protected] [1]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]
_______________________________________________ Discuss-gnuradio mailing
list

[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]

Links:

[1] mailto:[email protected]
[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 C. [email protected]
To: [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] swig gnuradio.i cannot find
gruel_common.i in 3.6.0
Message-ID:
[email protected]
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 10, 2012 at 10:42, [email protected] 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: [email protected]
To: Johnathan C. [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] swig gnuradio.i cannot find
gruel_common.i in 3.6.0
Message-ID: [email protected]
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 C. 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:[email protected]
-------------- 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 [email protected]
To: [email protected]
Subject: [Discuss-gnuradio] Modifying C++ Files
Message-ID: [email protected]
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 F. [email protected]
To: [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] swig gnuradio.i cannot find
gruel_common.i in 3.6.0
Message-ID:
[email protected]
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 C. [email protected]
To: Bogdan D. [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Data lost whe using big file sources
Message-ID:
CAOVQD[email protected]domain.invalid
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 10, 2012 at 04:22, Bogdan D.
[email protected] 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 [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] Problem in the update
Message-ID: [email protected]
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:

file should not exist after the update. Looks like you did something


Discuss-gnuradio mailing list
[email protected]
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 [email protected]
To: Tom R. [email protected]
Cc: GNU Radio mailing list [email protected]
Subject: Re: [Discuss-gnuradio] [USRP-users] Gnu Radio apps freezes
(locks up)
Message-ID: [email protected]
Content-Type: text/plain; charset=us-ascii

On 31 mar 2012, at 15.43, Tom R. wrote:

This has never been a problem with earlier versions of GR/UHD, from about 6
months ago.

Rickard
Tom,
GnuRadio itself does not freeze as a whole (like the grc in the background),
just the running application, which I then need to abort.
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” [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] [USRP-users] Gnu Radio apps freezes
(locks up)
Message-ID: [email protected]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

v3.5.2.1 tag on git and try that one instead of the tarball release?

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 L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


Message: 11
Date: Tue, 10 Apr 2012 14:55:10 -0700
From: Nick F. [email protected]
To: Rickard [email protected]
Cc: GNU Radio mailing list [email protected]
Subject: Re: [Discuss-gnuradio] [USRP-users] Gnu Radio apps freezes
(locks up)
Message-ID:
[email protected]
Content-Type: text/plain; charset=“iso-8859-1”

On Tue, Apr 10, 2012 at 1:16 PM, Rickard [email protected] wrote:

Hi list,
about 6 months ago.
work(ed) flawlessly with another machine on OSX (before I tried to upgrade

(no tarballs).

This happen sooner with high sampling rate (after a few seconds with
Strangely enough, this “freezing/halting” does NOT happen when
Thanks for the data. Unfortunately, I have no idea what to make of
Tom
worked (just got a completely blank screen without any gui), so

computer (like a fft-plot), at highest possible rate 50 MSPS, 8 bit/samples
However, finding this working network state is not just a matter of
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

[email protected]
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 [email protected]
To: frankist [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Problem in the update
Message-ID: [email protected]
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 R. [email protected]
To: sibar002 [email protected], discuss-gnuradio Discussion Group
[email protected]
Subject: Re: [Discuss-gnuradio] Modifying C++ Files
Message-ID:
[email protected]
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 [email protected] wrote:

help or advice that anyone could give me. Thank you for your time and help.
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

Adam Nielsen wrote:

/usr/local/lib(64) in the computer. I wonder if this is normal
will
you start installing things yourself, so having no /usr/local/lib is not
old

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 S. [email protected]
To: [email protected]
Subject: [Discuss-gnuradio] Question about sampling rate
Message-ID:
[email protected]
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 F. [email protected]
To: Javier S. [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Question about sampling rate
Message-ID:
[email protected]invalid
Content-Type: text/plain; charset=“iso-8859-1”

On Wed, Apr 11, 2012 at 8:53 AM, Javier S. [email protected]
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–Shannon_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
[email protected]
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
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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