[Discuss-gnuradio] Re: Discuss-gnuradio Digest, Vol 88, Issue 22

[Juan Quiroz]

--- On Mon, 3/22/10, address@hidden <address@hidden> wrote:

> From: address@hidden <address@hidden>
> Subject: Discuss-gnuradio Digest, Vol 88, Issue 22
> To: address@hidden
> Date: Monday, March 22, 2010, 11:00 AM
> Send Discuss-gnuradio mailing list
> submissions to
>     address@hidden
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>     http://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. Scope sink: multiple inputs (Marcus D.
> Leech)
>    2. Re: Scope sink: multiple inputs (Josh
> Blum)
>    3. Re: MA (Memory Acceleration)
> and    SR-DVB   
> in    Karlsruhe, @ WSR10
>       (Matt Ettus)
>    4. Re: Is gr-gpio broken? (Johnathan
> Corgan)
>    5. building gnuradio's gr-qtgui with qt
> 4.6 (Gregor Dschung)
>    6. a problem about USRP (cbwangmail)
>    7. USRP mod for serial below 500
> (Dimitrios Symeonidis)
>    8. Hardware sampling rates (Charles
> Brain)
>    9. Demodulate pam signal (Makmur
> Hidayat)
>   10. Re: a problem about USRP (Jason Uher)
>   11. Re: USRP mod for serial below 500 (Johnathan
> Corgan)
>   12. Re: Hardware sampling rates (Johnathan Corgan)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sun, 21 Mar 2010 09:20:50 -0700
> From: "Marcus D. Leech" <address@hidden>
> Subject: [Discuss-gnuradio] Scope sink: multiple inputs
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> I'm using the scopesink2 from within GRC.  How do I
> get it to actually
> display more than channel 1?
> 
> 
> -- 
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
> 
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Sun, 21 Mar 2010 09:38:02 -0700
> From: Josh Blum <address@hidden>
> Subject: Re: [Discuss-gnuradio] Scope sink: multiple
> inputs
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1;
> format=flowed
> 
> Change the "num inputs" parameter, or highlight the block
> and use the 
> plus hotkey.
> 
> -Josh
> 
> On 03/21/2010 09:20 AM, Marcus D. Leech wrote:
> > I'm using the scopesink2 from within GRC.  How do
> I get it to actually
> > display more than channel 1?
> >
> >
> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Sun, 21 Mar 2010 11:22:47 -0700
> From: Matt Ettus <address@hidden>
> Subject: Re: [Discuss-gnuradio] MA (Memory Acceleration)
> and    SR-DVB    in
>     Karlsruhe, @ WSR10
> To: Sylvain Munaut <address@hidden>
> Cc: discuss-gnuradio <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> On 03/15/2010 01:51 AM, Sylvain Munaut wrote:
> > Hi,
> >
> >> Both SR-DVB and OpenBTS wrote their own code from
> scratch,
> >> even though major parts of the computation could
> have been handled by
> >> GNU Radio processing blocks.  Why?
> >
> > OpenBTS makes uses of inband signaling to maintain
> strict TX/RX sync,
> > AFAIK this is not supported in the standard blocks.
> >
> > They also tweak the way the RFX are tuned, trying to
> put the TX carrier
> > inside a notch of the RX IF filter (at least that's
> what the docs says).
> >
> > Not using the standard libs for tuning is however
> quite annoying because
> > when you deviate from the standard 2*RFX setup (like 1
> RFX or a
> > RFX+DBSRX or WBX), you have to change a lot of code
> :(
> 
> The universal driver project will make this a lot easier,
> since it will 
> encapsulate all the daughterboard control code.
> 
> Matt
> 
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Sun, 21 Mar 2010 15:07:01 -0700
> From: Johnathan Corgan <address@hidden>
> Subject: Re: [Discuss-gnuradio] Is gr-gpio broken?
> To: address@hidden
> Cc: address@hidden,
> Drew Read <address@hidden>
> Message-ID:
>     <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Thu, Mar 18, 2010 at 03:39, Juha Vierinen <address@hidden>
> wrote:
> 
> > It's not broken. Remove the line import gpio_swig from
> the gpio.py file.
> >
> > I think I sent a patch for this, but the line probably
> gets added
> > automatically...
> 
> This has been fixed in the latest git master.
> 
> Johnathan
> 
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Mon, 22 Mar 2010 00:44:52 +0100
> From: Gregor Dschung <address@hidden>
> Subject: [Discuss-gnuradio] building gnuradio's gr-qtgui
> with qt 4.6
> To: address@hidden
> Message-ID:
>     <address@hidden>
> Content-Type: text/plain; charset=windows-1252
> 
> Hi,
> 
> I'm trying to build gnuradio 3.2.2 under openSUSE 11.2,
> 32bit. I've
> installed the latest KDE4 release, so this packages are
> installed:
> address@hidden:~/local/src/gnuradio-3.2.2> rpm -qa | grep
> libqt4
> libqt4-qt3support-4.6.2-3.1.i586
> libqt4-devel-doc-data-4.6.2-5.1.noarch
> libqt4-devel-doc-4.6.2-5.1.i586
> libqt4-sql-mysql-4.6.2-5.1.i586
> libqt4-sql-sqlite-4.6.2-3.1.i586
> libqt4-4.6.2-3.1.i586
> libqt4-sql-4.6.2-3.1.i586
> libqt4-x11-4.6.2-3.1.i586
> libqt4-devel-4.6.2-3.1.i586
> 
> The make process exists with the errors appended to this
> mail. I hope
> this report is useful for somebody. For now, I'm building
> with
> --disable-gr-qtgui.
> 
> Regards,
> Gregor
> 
> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../..
> -DOMNITHREAD_POSIX=1 -I/usr/include
> -I/home/ich/local/src/gnuradio-3.2.2/omnithread
> -I/home/ich/local/src/gnuradio-3.2.2/gnuradio-core/src/lib/runtime
> -I/home/ich/local/src/gnuradio-3.2.2/gnuradio-core/src/lib/general
> -I/home/ich/local/src/gnuradio-3.2.2/gnuradio-core/src/lib/general
> -I/home/ich/local/src/gnuradio-3.2.2/gnuradio-core/src/lib/gengen
> -I/home/ich/local/src/gnuradio-3.2.2/gnuradio-core/src/lib/gengen
> -I/home/ich/local/src/gnuradio-3.2.2/gnuradio-core/src/lib/filter
> -I/home/ich/local/src/gnuradio-3.2.2/gnuradio-core/src/lib/filter
> -I/home/ich/local/src/gnuradio-3.2.2/gnuradio-core/src/lib/missing
> -I/home/ich/local/src/gnuradio-3.2.2/gnuradio-core/src/lib/reed-solomon
> -I/home/ich/local/src/gnuradio-3.2.2/gnuradio-core/src/lib/viterbi
> -I/home/ich/local/src/gnuradio-3.2.2/gnuradio-core/src/lib/io
> -I/home/ich/local/src/gnuradio-3.2.2/gnuradio-core/src/lib/g72x
> -I/home/ich/local/src/gnuradio-3.2.2/gnuradio-core/src/lib/swig
> -I/home/ich/local/src/gnuradio-3.2.2/gnuradio-core/src/lib/hier
> -I/home/ich/local/src/gnuradio-3.2.2/gnuradio-core/src/lib/swig
> -I/home/ich/local/src/gnuradio-3.2.2/gruel/src/include
> -I/home/ich/local/src/gnuradio-3.2.2/gruel/src/include
> -I/usr/include/python2.6 -I/usr/include/qwt
> -I/usr/include/qwtplot3d
> -DQT_SHARED -I/usr/include/QtCore -DQT_SHARED
> -I/usr/include/QtGui
> -I/usr/include/QtCore -I. -g -O2 -Wall -Woverloaded-virtual
> -pthread
> -MT FrequencyDisplayPlot_moc.lo -MD -MP -MF
> .deps/FrequencyDisplayPlot_moc.Tpo -c
> FrequencyDisplayPlot_moc.cc
> -fPIC -DPIC -o .libs/FrequencyDisplayPlot_moc.o
> TimeDomainDisplayPlot_moc.cc:14:2: error: #error "This file
> was
> generated using the moc from 4.5.0. It"
> TimeDomainDisplayPlot_moc.cc:15:2: error: #error "cannot be
> used with
> the include files from this version of Qt."
> TimeDomainDisplayPlot_moc.cc:16:2: error: #error "(The moc
> has changed
> too much.)"
> FrequencyDisplayPlot_moc.cc:14:2: error: #error "This file
> was
> generated using the moc from 4.5.0. It"
> FrequencyDisplayPlot_moc.cc:15:2: error: #error "cannot be
> used with
> the include files from this version of Qt."
> FrequencyDisplayPlot_moc.cc:16:2: error: #error "(The moc
> has changed
> too much.)"
> spectrumdisplayform_moc.cc:14:2: error: #error "This file
> was
> generated using the moc from 4.5.0. It"
> spectrumdisplayform_moc.cc:15:2: error: #error "cannot be
> used with
> the include files from this version of Qt."
> spectrumdisplayform_moc.cc:16:2: error: #error "(The moc
> has changed too much.)"
> In file included from TimeDomainDisplayPlot.h:11,
>                  from
> TimeDomainDisplayPlot_moc.cc:10:
> /usr/include/qwt/qwt_plot_picker.h:106: warning: ‘virtual
> void
> QwtPlotPicker::move(const QPoint&)’ was hidden
> /usr/include/qwt/qwt_plot_zoomer.h:88: warning:   by
> ‘virtual void
> QwtPlotZoomer::move(double, double)’
> make[5]: *** [TimeDomainDisplayPlot_moc.lo] Fehler 1
> make[5]: *** Warte auf noch nicht beendete Prozesse...
> In file included from FrequencyDisplayPlot.h:11,
>                  from
> FrequencyDisplayPlot_moc.cc:10:
> /usr/include/qwt/qwt_plot_picker.h:106: warning: ‘virtual
> void
> QwtPlotPicker::move(const QPoint&)’ was hidden
> /usr/include/qwt/qwt_plot_zoomer.h:88: warning:   by
> ‘virtual void
> QwtPlotZoomer::move(double, double)’
> make[5]: *** [FrequencyDisplayPlot_moc.lo] Fehler 1
> In file included from ./FrequencyDisplayPlot.h:11,
>                  from
> spectrumdisplayform_ui.h:13,
>                  from
> spectrumdisplayform.h:4,
>                  from
> spectrumdisplayform_moc.cc:10:
> /usr/include/qwt/qwt_plot_picker.h:106: warning: ‘virtual
> void
> QwtPlotPicker::move(const QPoint&)’ was hidden
> /usr/include/qwt/qwt_plot_zoomer.h:88: warning:   by
> ‘virtual void
> QwtPlotZoomer::move(double, double)’
> In file included from ./Waterfall3DDisplayPlot.h:7,
>                  from
> spectrumdisplayform_ui.h:30,
>                  from
> spectrumdisplayform.h:4,
>                  from
> spectrumdisplayform_moc.cc:10:
> /usr/include/qwtplot3d/qwt3d_function.h:30: warning:
> ‘virtual bool
> Qwt3D::Function::create(Qwt3D::SurfacePlot&)’ was
> hidden
> ./waterfallGlobalData.h:56: warning:   by ‘virtual
> bool
> Waterfall3DData::create()’
> In file included from
> /usr/include/qwtplot3d/qwt3d_colorlegend.h:7,
>                  from
> /usr/include/qwtplot3d/qwt3d_coordsys.h:5,
>                  from
> /usr/include/qwtplot3d/qwt3d_plot.h:4,
>                  from
> /usr/include/qwtplot3d/qwt3d_surfaceplot.h:4,
>                  from
> ./Waterfall3DDisplayPlot.h:8,
>                  from
> spectrumdisplayform_ui.h:30,
>                  from
> spectrumdisplayform.h:4,
>                  from
> spectrumdisplayform_moc.cc:10:
> /usr/include/qwtplot3d/qwt3d_color.h:22: warning:
> ‘virtual Qwt3D::RGBA
> Qwt3D::Color::operator()(const Qwt3D::Triple&) const’
> was hidden
> /usr/include/qwtplot3d/qwt3d_color.h:44: warning:   by
> ‘virtual
> Qwt3D::RGBA Qwt3D::StandardColor::operator()(double,
> double, double)
> const’
> In file included from spectrumdisplayform_ui.h:30,
>                  from
> spectrumdisplayform.h:4,
>                  from
> spectrumdisplayform_moc.cc:10:
> /usr/include/qwtplot3d/qwt3d_color.h:22: warning:
> ‘virtual Qwt3D::RGBA
> Qwt3D::Color::operator()(const Qwt3D::Triple&) const’
> was hidden
> ./Waterfall3DDisplayPlot.h:18: warning:   by ‘virtual
> Qwt3D::RGBA
> Waterfall3DColorMap::operator()(double, double, double)
> const’
> make[5]: *** [spectrumdisplayform_moc.lo] Fehler 1
> make[5]: Leaving directory
> `/home/ich/local/src/gnuradio-3.2.2/gr-qtgui/src/lib'
> make[4]: *** [all] Fehler 2
> make[4]: Leaving directory
> `/home/ich/local/src/gnuradio-3.2.2/gr-qtgui/src/lib'
> make[3]: *** [all-recursive] Fehler 1
> make[3]: Leaving directory
> `/home/ich/local/src/gnuradio-3.2.2/gr-qtgui/src'
> make[2]: *** [all-recursive] Fehler 1
> make[2]: Leaving directory
> `/home/ich/local/src/gnuradio-3.2.2/gr-qtgui'
> make[1]: *** [all-recursive] Fehler 1
> make[1]: Leaving directory
> `/home/ich/local/src/gnuradio-3.2.2'
> make: *** [all] Fehler 2
> 
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Mon, 22 Mar 2010 11:18:03 +0800 (CST)
> From: cbwangmail <address@hidden>
> Subject: [Discuss-gnuradio] a problem about USRP
> To: discuss-gnuradio <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="gbk"
> 
> hi!
> i bought  a new usrp ,  when i test it ,there is
> something wrong with it .i just put  "sudo python
> benchmark_tx.py -f 420M -i 128" in the terminal£¬but the
> terminal give me some error . 
> that is 
> "gr_fir_fff: using SSE
> terminate called after throwing an instance of
> 'std::runtime_error'
>   what():  No suitable daughterboard found!
> ºöÂÔ"
> i can't realize the reason. could someone give me some
> advice and help me solve it?
> thanks  in advance !
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> http://lists.gnu.org/pipermail/discuss-gnuradio/attachments/20100322/f9c1715c/attachment.html
> 
> ------------------------------
> 
> Message: 7
> Date: Mon, 22 Mar 2010 09:40:23 +0100
> From: Dimitrios Symeonidis <address@hidden>
> Subject: [Discuss-gnuradio] USRP mod for serial below 500
> To: DiscussGnuRadio <address@hidden>
> Message-ID:
>     <address@hidden>
> Content-Type: text/plain; charset=UTF-8
> 
> Dear list,
> 
> as you know, USRPs with a serial number below 500 cannot
> use newer
> daughterboards because they fail to send the motherboard
> clock to the
> daughterboard. There's a very simple modification that can
> work around
> this, and allow these old USRPs to use both old and new
> daughterboards.
> 
> This mod is described on this page of our wiki:
> http://gnuradio.org/redmine/wiki/gnuradio/USRPSerialBelow500
> 
> Best regards
> 
> Dimitrios Symeonidis
> "If you think you're too small to make a difference, try
> sleeping with
> a mosquito!" - Amnesty International
> 
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Mon, 22 Mar 2010 08:49:14 -0000
> From: "Charles Brain" <address@hidden>
> Subject: [Discuss-gnuradio] Hardware sampling rates
> To: <address@hidden>
> Message-ID:
> <address@hidden>
> Content-Type: text/plain; format=flowed;
> charset="iso-8859-1";
>     reply-type=original
> 
> Hi,
> 
> Would it be possible (now)/( or in the future) to be able
> to change the 
> sampling rate of the DAC in the USRP2 using an external
> clock? 
> I am working on stuff that is pushing what is possible in
> software 
> and not having to add extra overhead simply to do up/down 
> interpolation to get to something that divides into 100M
> would be really useful. I have tried the fractional
> interpolator and it
> just sucks too many CPU cycles.
> 
> - Charles
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 9
> Date: Mon, 22 Mar 2010 22:22:04 +1030
> From: Makmur Hidayat <address@hidden>
> Subject: [Discuss-gnuradio] Demodulate pam signal
> To: address@hidden
> Message-ID:
>     <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Dear all,
> 
> I want to demodulate pam signal using gnu radio. But in GRC
> and in C++ API
> doc, I didn't find the class for demodulating the pam
> signal.
> Therefore, do I have to make new class?
> 
> Thank you for your suggestion
> Makmur
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> http://lists.gnu.org/pipermail/discuss-gnuradio/attachments/20100322/eb6bf54c/attachment.html
> 
> ------------------------------
> 
> Message: 10
> Date: Mon, 22 Mar 2010 07:11:21 -0500
> From: Jason Uher <address@hidden>
> Subject: Re: [Discuss-gnuradio] a problem about USRP
> To: cbwangmail <address@hidden>,
> address@hidden
> Message-ID:
>     <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> > terminate called after throwing an instance of
> 'std::runtime_error'
> >   what():  No suitable daughterboard found!
> 
> a) Which daughterboard do you have installed, and which
> side is it on (A or B)
> b) What does usrp_print_db.py return?
> 
> Jason
> 
> 
> 
> 
> ------------------------------
> 
> Message: 11
> Date: Mon, 22 Mar 2010 07:51:05 -0700
> From: Johnathan Corgan <address@hidden>
> Subject: Re: [Discuss-gnuradio] USRP mod for serial below
> 500
> To: Dimitrios Symeonidis <address@hidden>
> Cc: DiscussGnuRadio <address@hidden>
> Message-ID:
>     <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Mon, Mar 22, 2010 at 01:40, Dimitrios Symeonidis <address@hidden>
> wrote:
> 
> > as you know, USRPs with a serial number below 500
> cannot use newer
> > daughterboards because they fail to send the
> motherboard clock to the
> > daughterboard. There's a very simple modification that
> can work around
> > this, and allow these old USRPs to use both old and
> new
> > daughterboards.
> >
> > This mod is described on this page of our wiki:
> > http://gnuradio.org/redmine/wiki/gnuradio/USRPSerialBelow500
> 
> Excellent.  My oldest USRP is #316, time to melt
> solder!
> 
> Johnathan
> 
> 
> 
> 
> ------------------------------
> 
> Message: 12
> Date: Mon, 22 Mar 2010 07:47:29 -0700
> From: Johnathan Corgan <address@hidden>
> Subject: Re: [Discuss-gnuradio] Hardware sampling rates
> To: Charles Brain <address@hidden>
> Cc: address@hidden
> Message-ID:
>     <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Mon, Mar 22, 2010 at 01:49, Charles Brain <address@hidden>
> wrote:
> 
> > I have tried the fractional interpolator and it just
> sucks too many CPU cycles.
> 
> There is one more thing you can try--use the polyphase
> resampler.
> This is a new block by Tom Rondeau based on the Harris
> book.  It
> hasn't gotten a lot of use yet, but it is working so far
> and is very
> efficient.
> 
> gr.pfb_arb_resampler_ccf(resample_rate, taps, size)
> 
> 'resample_rate' is your desired interpolation rate
> 'taps' is the vector of FIR taps to use as the
> interpolation filter
> 'size' is the number of phases to use in resampler
> (default=32)
> 
> You can use gr.firdes.* to design a filter to create
> 'taps'; but the
> sample rates to use require special calculation. 
> See:
> 
> http://gnuradio.org/redmine/repositories/entry/gnuradio/gnuradio-examples/python/pfb/interpolate.py
> 
> ...for an example using both the polyphase integral
> interpolator and
> the polyphase arbitrary resampler.
> 
> In your case, if I recall correctly, your final output
> filter is a
> root-raised-cosine filter.  So you'd use the arbitrary
> resampler to
> upsample to your final output sample rate, and use the RRC
> tap
> generator to create the taps for it.
> 
> Johnathan
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> End of Discuss-gnuradio Digest, Vol 88, Issue 22
> ************************************************
>