--- On Mon, 3/22/10, discuss-gnuradio-requ...@gnu.org <discuss-gnuradio-requ...@gnu.org> wrote:
> From: discuss-gnuradio-requ...@gnu.org <discuss-gnuradio-requ...@gnu.org> > Subject: Discuss-gnuradio Digest, Vol 88, Issue 22 > To: discuss-gnuradio@gnu.org > Date: Monday, March 22, 2010, 11:00 AM > Send Discuss-gnuradio mailing list > submissions to > discuss-gnuradio@gnu.org > > 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 > discuss-gnuradio-requ...@gnu.org > > You can reach the person managing the list at > discuss-gnuradio-ow...@gnu.org > > 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" <mle...@ripnet.com> > Subject: [Discuss-gnuradio] Scope sink: multiple inputs > To: discuss-gnuradio@gnu.org > Message-ID: <4ba64762.9020...@ripnet.com> > 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 <j...@joshknows.com> > Subject: Re: [Discuss-gnuradio] Scope sink: multiple > inputs > To: discuss-gnuradio@gnu.org > Message-ID: <4ba64b6a.50...@joshknows.com> > 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 <m...@ettus.com> > Subject: Re: [Discuss-gnuradio] MA (Memory Acceleration) > and SR-DVB in > Karlsruhe, @ WSR10 > To: Sylvain Munaut <t...@246tnt.com> > Cc: discuss-gnuradio <Discuss-gnuradio@gnu.org> > Message-ID: <4ba663f7.8000...@ettus.com> > 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 <jcor...@corganenterprises.com> > Subject: Re: [Discuss-gnuradio] Is gr-gpio broken? > To: j...@sgo.fi > Cc: discuss-gnuradio@gnu.org, > Drew Read <andrew.r...@tait.co.nz> > Message-ID: > <72dcf3af1003211507y51434717h5fe9063b8b278...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Thu, Mar 18, 2010 at 03:39, Juha Vierinen <jvier...@gmail.com> > 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 <dsch...@cs.uni-kl.de> > Subject: [Discuss-gnuradio] building gnuradio's gr-qtgui > with qt 4.6 > To: discuss-gnuradio@gnu.org > Message-ID: > <a240e1de1003211644n57e86fd9gbc56382e2ac39...@mail.gmail.com> > 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: > i...@heusinger:~/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 <cbwangm...@163.com> > Subject: [Discuss-gnuradio] a problem about USRP > To: discuss-gnuradio <discuss-gnuradio@gnu.org> > Message-ID: <10f1dd3.ad6d.12783e08d08.coremail.cbwangm...@163.com> > 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 <azim...@gmail.com> > Subject: [Discuss-gnuradio] USRP mod for serial below 500 > To: DiscussGnuRadio <discuss-gnuradio@gnu.org> > Message-ID: > <36265bc21003220140u34ff5293h7dd2036e4266d...@mail.gmail.com> > 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" <chbr...@btinternet.com> > Subject: [Discuss-gnuradio] Hardware sampling rates > To: <discuss-gnuradio@gnu.org> > Message-ID: > <2f6fdf836ac74771a0134f6968049...@pavillionii> > 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 <makm...@gmail.com> > Subject: [Discuss-gnuradio] Demodulate pam signal > To: discuss-gnuradio@gnu.org > Message-ID: > <2fd9c3661003220452j18c334a7l959703c336917...@mail.gmail.com> > 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 <jasonu...@gmail.com> > Subject: Re: [Discuss-gnuradio] a problem about USRP > To: cbwangmail <cbwangm...@163.com>, > discuss-gnuradio@gnu.org > Message-ID: > <7a650e2c1003220511g2bdfdb1xac58180626d40...@mail.gmail.com> > 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 <jcor...@corganenterprises.com> > Subject: Re: [Discuss-gnuradio] USRP mod for serial below > 500 > To: Dimitrios Symeonidis <azim...@gmail.com> > Cc: DiscussGnuRadio <discuss-gnuradio@gnu.org> > Message-ID: > <72dcf3af1003220751p12fbee76o59f7fe2ca6299...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 22, 2010 at 01:40, Dimitrios Symeonidis <azim...@gmail.com> > 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 <jcor...@corganenterprises.com> > Subject: Re: [Discuss-gnuradio] Hardware sampling rates > To: Charles Brain <chbr...@btinternet.com> > Cc: discuss-gnuradio@gnu.org > Message-ID: > <72dcf3af1003220747q4eec1a82t5a2a87ba30d1b...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 22, 2010 at 01:49, Charles Brain <chbr...@btinternet.com> > 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 > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > End of Discuss-gnuradio Digest, Vol 88, Issue 22 > ************************************************ > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
