[Discuss-gnuradio] Failed test in 'make check'
Hi, I've been fighting to compile the gnuradio-core-2.4 from tarball on a Ubuntu distro. I'm pretty new to Linux world and it's a bit of a challenge as it's not a development distribution. (I may add sth on the wiki about the needed packages to compile the whole project) Well anyway every thing seems to be Ok but when I'm doing the 'make check' I got this message in the last section: FAIL: test_all === 1 of 1 tests failed === is it important? (all the listing is included at the end of the mail) Cheers Damien - Making check in config make[1]: Entering directory `/home/damien/gr/gnuradio-core-2.4/config' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/damien/gr/gnuradio-core-2.4/config' Making check in src make[1]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src' Making check in gen_interpolator_taps make[2]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/gen_interpolator_taps' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/home/damien/gr/gnuradio-core-2.4/src/gen_interpolator_taps' Making check in lib make[2]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/lib' Making check in missing make[3]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/lib/missing' make[3]: Nothing to be done for `check'. make[3]: Leaving directory `/home/damien/gr/gnuradio-core-2.4/src/lib/missing' Making check in runtime make[3]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/lib/runtime' make[3]: Nothing to be done for `check'. make[3]: Leaving directory `/home/damien/gr/gnuradio-core-2.4/src/lib/runtime' Making check in filter make[3]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/lib/filter' make check-am make[4]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/lib/filter' make[4]: Nothing to be done for `check-am'. make[4]: Leaving directory `/home/damien/gr/gnuradio-core-2.4/src/lib/filter' make[3]: Leaving directory `/home/damien/gr/gnuradio-core-2.4/src/lib/filter' Making check in general make[3]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/lib/general' make check-am make[4]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/lib/general' make[4]: Nothing to be done for `check-am'. make[4]: Leaving directory `/home/damien/gr/gnuradio-core-2.4/src/lib/general' make[3]: Leaving directory `/home/damien/gr/gnuradio-core-2.4/src/lib/general' Making check in g72x make[3]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/lib/g72x' make[3]: Nothing to be done for `check'. make[3]: Leaving directory `/home/damien/gr/gnuradio-core-2.4/src/lib/g72x' Making check in reed-solomon make[3]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/lib/reed-solomon' make check-TESTS make[4]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/lib/reed-solomon' Testing (3,2) RS codec...OK Testing (7,5) RS codec...OK Testing (15,11) RS codec...OK Testing (31,25) RS codec...OK Testing (63,55) RS codec...OK Testing (127,117) RS codec...OK Testing (255,223) RS codec...OK Testing (255,223) RS codec...OK All codec tests passed! PASS: rstest == All 1 tests passed == make[4]: Leaving directory `/home/damien/gr/gnuradio-core-2.4/src/lib/reed-solomon' make[3]: Leaving directory `/home/damien/gr/gnuradio-core-2.4/src/lib/reed-solomon' Making check in omnithread make[3]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/lib/omnithread' make[3]: Nothing to be done for `check'. make[3]: Leaving directory `/home/damien/gr/gnuradio-core-2.4/src/lib/omnithread' Making check in io make[3]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/lib/io' make[3]: Nothing to be done for `check'. make[3]: Leaving directory `/home/damien/gr/gnuradio-core-2.4/src/lib/io' Making check in . make[3]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/lib' make[3]: Nothing to be done for `check-am'. make[3]: Leaving directory `/home/damien/gr/gnuradio-core-2.4/src/lib' Making check in swig make[3]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/lib/swig' make check-am make[4]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/lib/swig' make[4]: Nothing to be done for `check-am'. make[4]: Leaving directory `/home/damien/gr/gnuradio-core-2.4/src/lib/swig' make[3]: Leaving directory `/home/damien/gr/gnuradio-core-2.4/src/lib/swig' make[2]: Leaving directory `/home/damien/gr/gnuradio-core-2.4/src/lib' Making check in tests make[2]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/tests' make check-TESTS make[3]: Entering directory `/home/damien/gr/gnuradio-core-2.4/src/tests' .Testing gr_vmcircbuf_sysv_shm_factory... ... gr_vmcircbuf_sysv_shm_factory: OK Testing gr_vmcircbuf_mmap_shm_open_factory... FAIL: test_all === 1 of 1 tests failed === make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/home/da
Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'PyEventBinder'
> Are you using wxPython 2.5.2.7 or later? yup i am now. i upgraded from wxpython-2.4 to wxpython-2.5.3.1 ...and after accidentally removing python altogether all is working great. cheers, = mj - m0mik hotstudent.com [are you hot enough?!] __ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp over/underrun problems
We've got a couple of USRP boards running on "embedded" ebx boards. Unfortunately, we are seeing usb overruns/underruns when we run the fsk_tx / rx example. I removed the fft from the signal chain, and we still see regular overruns on the rx side. Also cut the cordic freq. to 2e6, with the same results. I thought this might change the sampling rate. Is that so? Also, after the test runs for a few seconds many packets are lost. Finally, setting the data rate lower seems to make things much worse. Perhaps that is because the correlator runs longer? We're using fedora 3 on a 1G pentium 3, approximately. I suspect the usb isn't fast enough, but that's the hardware we're stuck with. So turning down the a/d clock would be good. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp over/underrun problems
Quoting Bob Vincent <[EMAIL PROTECTED]>: > We've got a couple of USRP boards running on "embedded" ebx boards. Great! > Unfortunately, we are seeing usb overruns/underruns when we run the fsk_tx > / rx example. I removed the fft from the signal chain, and we still see > regular overruns on the rx side. Also cut the cordic freq. to 2e6, with the > same results. I thought this might change the sampling rate. Is that so? CORDIC freq will not affect sample rate. You will get the lowest sample rate by setting the decimator rate to 256. This will give a sample rate of 64e6/256 = 250 ksamples/sec. What code are you running? > Finally, setting the data rate lower seems to make things much worse. > Perhaps that is because the correlator runs longer? What correlator? > We're using fedora 3 on a 1G pentium 3, approximately. I suspect the usb > isn't fast enough, but that's the hardware we're stuck with. So turning > down the a/d clock would be good. Are you certain that this board has USB2? Most P3's did not have USB2. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failed test in 'make check'
On Tue, Feb 15, 2005 at 07:13:39PM +1100, [EMAIL PROTECTED] wrote: > Hi, > I've been fighting to compile the gnuradio-core-2.4 from > tarball on a Ubuntu distro. > I'm pretty new to Linux world and it's a bit of a challenge as > it's not a development distribution. (I may add sth on the > wiki about the needed packages to compile the whole project) > > Well anyway every thing seems to be Ok but when I'm doing > the 'make check' I got this message in the last section: > FAIL: test_all > === > 1 of 1 tests failed > === > is it important? > (all the listing is included at the end of the mail) > > Cheers > Damien Yes it does matter. We visited this problem in the context of Debian last month. I believe it's a combination of an x86 g++ 3.3. problem in combination with libraries that were compiled with said compiler. Take a look at this thread: http://lists.gnu.org/archive/html/discuss-gnuradio/2005-01/msg00055.html Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'PyEventBinder'
On Tue, Feb 15, 2005 at 04:09:44AM -0800, mj wrote: > > > Are you using wxPython 2.5.2.7 or later? > > yup i am now. i upgraded from wxpython-2.4 to > wxpython-2.5.3.1 I'm using wxPython 2.5.3.1 on top of wxGTK 2.5.3 (dependency in Gentoo, apparntly) and Python 2.3.4. When I run "python fftsink.py" I'm getting the error below. Is fftsink.py even something I should be running by itself? Traceback (most recent call last): File "./fftsink.py", line 24, in ? from gnuradio.wxgui import stdgui File "/opt/gnuradio/lib/python2.3/site-packages/gnuradio/wxgui/stdgui.py", line 24, in ? import wx File "/opt/gnuradio/lib/python2.3/site-packages/gnuradio/wxgui/__init__.py", line 45, in ? File "/opt/gnuradio/lib/python2.3/site-packages/gnuradio/wxgui/__init__.py", line 20, in ? ImportError: No module named wxc Am I missing something? $PYTHONPATH includes /opt/gnuradio/lib/python2.3/site-packages/gnuradio Unfortunately, I don't know Python, and no one here does either. The non-GUI examples work fine, though. -Rahul -- Rahul Dhar [EMAIL PROTECTED] Actually, my goal is to have a sandwich named after me. pgpYoXFsJAM6U.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Weaver vs. Hilbert
At 06:49 AM 2/15/2005 +0100, you wrote: In hardware a Weaver modulator avoids the need for the phase shifting baseband filters. What is the reason for using a Weaver modulator (http://webpages.charter.net/cswiger/weaver_gen.py) in an SDR? Is it faster than an Hilbert transformer? (http://comsec.com/wiki?SingleSideBandModulator) Hi Thomas - no reason other than it's the only thing I've gotten to work so far ;)I tried a phasing demodulator and ran into some problems, likely from not understanding how to use the hilbert transform gr.hilbert_fc(). Putting together a weaver graph actually worked, and after combining a few parts into gr.freq_xlating_fir_filter_xxx() it really became effecient enough to use, plus sounds good.Turning to transmitting, I just took what's working so far and turned it around. Other strategies will likely work much better. The above script does work, but is very inefficient as I can't (or don't know how to) combine the rf mixers and filters and decimators, or interpolators in the transmitting case, into one processing block like in the demodulator. An instructive app note: http://www.standardproducts.philips.com/support/appnotes/analog/pdf/an1981.pdf I'll try your script out shortly. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'PyEventBinder'
On Tue, Feb 15, 2005 at 03:30:49PM -0500, Rahul Dhar wrote: > On Tue, Feb 15, 2005 at 04:09:44AM -0800, mj wrote: > > > > > Are you using wxPython 2.5.2.7 or later? > > > > yup i am now. i upgraded from wxpython-2.4 to > > wxpython-2.5.3.1 > > I'm using wxPython 2.5.3.1 on top of wxGTK 2.5.3 (dependency in Gentoo, > apparntly) and Python 2.3.4. When I run "python fftsink.py" I'm > getting the error below. Is fftsink.py even something I should be > running by itself? If you run it by itself, it has a little demo program that plots made-up data. It should run. > Traceback (most recent call last): > File "./fftsink.py", line 24, in ? > from gnuradio.wxgui import stdgui > File > "/opt/gnuradio/lib/python2.3/site-packages/gnuradio/wxgui/stdgui.py", > line 24, in ? > import wx > File > "/opt/gnuradio/lib/python2.3/site-packages/gnuradio/wxgui/__init__.py", > line 45, in ? > > File > "/opt/gnuradio/lib/python2.3/site-packages/gnuradio/wxgui/__init__.py", > line 20, in ? > > ImportError: No module named wxc > > Am I missing something? $PYTHONPATH includes > /opt/gnuradio/lib/python2.3/site-packages/gnuradio > > Unfortunately, I don't know Python, and no one here does either. The > non-GUI examples work fine, though. > Sounds like something's screwed up with your wxpython install. Do the wxpython demos work? http://www.wxpython.org Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'PyEventBinder'
hey, i had that error after i installed wxpython-2.5.3.1 over the other version. try removing wxpython and wxGTK and then installing them again. then re-emerge numeric and numarray. mj --- Rahul Dhar <[EMAIL PROTECTED]> wrote: > On Tue, Feb 15, 2005 at 04:09:44AM -0800, mj wrote: > > > > > Are you using wxPython 2.5.2.7 or later? > > > > yup i am now. i upgraded from wxpython-2.4 to > > wxpython-2.5.3.1 > > I'm using wxPython 2.5.3.1 on top of wxGTK 2.5.3 > (dependency in Gentoo, > apparntly) and Python 2.3.4. When I run "python > fftsink.py" I'm > getting the error below. Is fftsink.py even > something I should be > running by itself? > > Traceback (most recent call last): > File "./fftsink.py", line 24, in ? > from gnuradio.wxgui import stdgui > File > "/opt/gnuradio/lib/python2.3/site-packages/gnuradio/wxgui/stdgui.py", > line 24, in ? > import wx > File > "/opt/gnuradio/lib/python2.3/site-packages/gnuradio/wxgui/__init__.py", > line 45, in ? > > File > "/opt/gnuradio/lib/python2.3/site-packages/gnuradio/wxgui/__init__.py", > line 20, in ? > > ImportError: No module named wxc > > Am I missing something? $PYTHONPATH includes > /opt/gnuradio/lib/python2.3/site-packages/gnuradio > > Unfortunately, I don't know Python, and no one here > does either. The > non-GUI examples work fine, though. > > -Rahul > -- > Rahul Dhar > [EMAIL PROTECTED] > Actually, my goal is to have a sandwich named after > me. > > ATTACHMENT part 2 application/pgp-signature = mj - m0mik hotstudent.com [are you hot enough?!] __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp over/underrun problems
At 12:23 PM 2/15/2005, Matt Ettus wrote: Quoting Bob Vincent <[EMAIL PROTECTED]>: > We've got a couple of USRP boards running on "embedded" ebx boards. Great! > Unfortunately, we are seeing usb overruns/underruns when we run the fsk_tx > / rx example. I removed the fft from the signal chain, and we still see > regular overruns on the rx side. Also cut the cordic freq. to 2e6, with the > same results. I thought this might change the sampling rate. Is that so? CORDIC freq will not affect sample rate. You will get the lowest sample rate by setting the decimator rate to 256. This will give a sample rate of 64e6/256 = 250 ksamples/sec. So in fsk_*, on the rx side it's a function of data rate, while on the tx side the same calculation goes to the interpolator. Got it. Unfortunately, I get problems when I set data_rate for most of the values I've tried. It appears that both calculations have to wind up in the range 1-256. Do they need to be powers of 2? I'm not much with fpga code. What code are you running? Latest. I'm trying to get fsk to play nice. I've also put in socket for file source and sink. We're going to try to run our ad-hoc routing protocols on top of the "radio". I noticed that when you stop the app, the usrp recirculates. I presume that's what will happen when we source data from a socket as well. Do you know of any way to "stop" the usrp, apart from muxing in zeroes? I want to avoid as much coding as possible. > Finally, setting the data rate lower seems to make things much worse. > Perhaps that is because the correlator runs longer? What correlator? > We're using fedora 3 on a 1G pentium 3, approximately. I suspect the usb > isn't fast enough, but that's the hardware we're stuck with. So turning > down the a/d clock would be good. Are you certain that this board has USB2? Most P3's did not have USB2. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'PyEventBinder'
On Tue, Feb 15, 2005 at 01:44:18PM -0800, mj wrote: > > hey, i had that error after i installed > wxpython-2.5.3.1 over the other version. > > try removing wxpython and wxGTK and then installing > them again. then re-emerge numeric and numarray. FYI, we don't require numarray if you've got Numeric. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failed test in 'make check'
Ok, I switched to g++-3.4 and recompile cppunit-1.10.2 with it and it's working now. I should have checked the mailing-list archives. Cheers Damien >> Hi, >> I've been fighting to compile the gnuradio-core-2.4 from >> tarball on a Ubuntu distro. >> I'm pretty new to Linux world and it's a bit of a challenge as >> it's not a development distribution. (I may add sth on the >> wiki about the needed packages to compile the whole project) >> >> Well anyway every thing seems to be Ok but when I'm doing >> the 'make check' I got this message in the last section: >> FAIL: test_all >> === >> 1 of 1 tests failed >> === >> is it important? >> (all the listing is included at the end of the mail) >> >> Cheers >> Damien > >Yes it does matter. > >We visited this problem in the context of Debian last month. I >believe it's a combination of an x86 g++ 3.3. problem in >combination with libraries that were compiled with said compiler. > >Take a look at this thread: > >http://lists.gnu.org/archive/html/discuss-gnuradio/2005-01/msg00055.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problem with audio extraction in NTSC
Dear all, I am working on extracting the audio FM signal from the NTSC signal, and experimenting with the data file ntsc-short-complex-baseband-8MS.dat The idea seems simple: recenter the audio carrier to 0 frequency, LPF and decimate and then do standard fm demod. This is done in the attached file. Unfortunately, although I hear something like "winter storm will still going to stick around..." the signal seems highly distorted as if the audio carrier is very unstable. I tried to fix this by tracking the video carrier, but the problem gets worse. One possible reason for this is that the local oscilator used to generate the IQ signal is not stable, which unfortunately cannot be fixed... Can someone verify this problem and/or suggest any solution. Thanks Achilleas #!/usr/bin/env python from gnuradio import gr from gnuradio import audio_oss as audio from gnuradio.wxgui import stdgui from gnuradio.wxgui import fftsink, oldfftsink, oldfftsink_linear, scopesink import wx import math class test_app_flow_graph (stdgui.gui_flow_graph): def __init__(self, frame, panel, vbox, argv): stdgui.gui_flow_graph.__init__ (self, frame, panel, vbox, argv) # build our flow graph input_rate = 8.00e6 fm_decim = 25 fm_rate = input_rate / fm_decim # 320 kHz audio_decimation = 10 audio_rate = fm_rate / audio_decimation # 32 kHz filename = "ntsc-short-complex-baseband-8MS.dat" src = gr.file_source (gr.sizeof_short, filename,True) conv = gr.interleaved_short_to_complex () # Pilot extraction: #Ap= 100.0 #p_width = 100e3 #pilot_coefs = gr.firdes.band_pass (2/Ap, input_rate, 1.75e6-p_width/2, 1.75e6+p_width/2, p_width, gr.firdes.WIN_HAMMING) #pilot_filter = gr.fir_filter_ccf(1, pilot_coefs) #real = gr.complex_to_real() #imag = gr.complex_to_imag() #neg = gr.multiply_const_ff(-1.0) #conj = gr.float_to_complex() # FM signal extraction #correction = gr.multiply_cc() fm_coeffs = gr.firdes.low_pass(1.0,input_rate,100e3,50e3,gr.firdes.WIN_HAMMING) fmc = gr.freq_xlating_fir_filter_ccf (fm_decim,fm_coeffs,-2.75e6, input_rate) peak_amp = 1.0 fm_demod_gain = 1.0 / (2 * math.pi * 75e3 / peak_amp / fm_rate) volume = 0.4 fm_demod = gr.quadrature_demod_cf (volume*fm_demod_gain) # L+R processing: LPF + decimation # compute FIR filter taps for audio filter width = 1e3 audio_coefs = gr.firdes.low_pass (1.0, fm_rate, 15e3, width, gr.firdes.WIN_HAMMING) audio_filter_lpr = gr.fir_filter_fff (audio_decimation, audio_coefs) audio_sink = audio.sink (int (audio_rate)) block1, fft_win1 = oldfftsink.make_fft_sink_c (self, panel, "Data", 1024, input_rate) block2, fft_win2 = oldfftsink.make_fft_sink_c (self, panel, "Data", 512, fm_rate) block3, fft_win3 = oldfftsink.make_fft_sink_f (self, panel, "Data", 256, audio_rate) self.connect (src, conv) #self.connect (conv, pilot_filter) #self.connect (pilot_filter,real) #self.connect (pilot_filter,imag) #self.connect (imag,neg) #self.connect (real,(conj,0)) #self.connect (neg,(conj,1)) #self.connect (conv,(correction,0)) #self.connect (conj,(correction,1)) #self.connect (correction, fmc) self.connect (conv, fmc) self.connect (fmc,fm_demod) self.connect (fm_demod,audio_filter_lpr) self.connect (audio_filter_lpr,audio_sink) self.connect (conv, block1) self.connect (fmc, block2) self.connect (audio_filter_lpr, block3) vbox.Add (fft_win1, 1, wx.EXPAND) vbox.Add (fft_win2, 1, wx.EXPAND) vbox.Add (fft_win3, 1, wx.EXPAND) def main (): app = stdgui.stdapp (test_app_flow_graph, "FFT Sink Test App") app.MainLoop () if __name__ == '__main__': main () ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] LED blinking
I finally got wxPython to play nice (thanks for all the help). The next issue is that the LED doesn't seem to be blinking anymore. I'm not sure what caused it, but does that mean the USRP is fried? Is there some voodoo spell I can cast to bring it back to life? It isn't just the LED, as the board doesn't register with the USB controller. -Rahul -- Rahul Dhar [EMAIL PROTECTED] Actually, my goal is to have a sandwich named after me. pgpGb9j6vEjNC.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] LED blinking
On Tue, Feb 15, 2005 at 08:47:23PM -0500, Rahul Dhar wrote: > I finally got wxPython to play nice (thanks for all the help). The next > issue is that the LED doesn't seem to be blinking anymore. I'm not sure > what caused it, but does that mean the USRP is fried? Is there some > voodoo spell I can cast to bring it back to life? It isn't just the > LED, as the board doesn't register with the USB controller. > > -Rahul > -- Pull out your trusty ohm meter and with the board unplugged from the power supply, check continuity across the fuse F501. If you start at the power connector and follow the trace on the top, it's the first thing you run into. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem with audio extraction in NTSC
At 07:59 PM 2/15/2005 -0500, you wrote: Dear all, I am working on extracting the audio FM signal from the NTSC signal, and experimenting with the data file ntsc-short-complex-baseband-8MS.dat The idea seems simple: recenter the audio carrier to 0 frequency, LPF and decimate and then do standard fm demod. This is done in the attached file. Unfortunately, although I hear something like "winter storm will still going to stick around..." the signal seems highly distorted as if the audio carrier is very unstable. I tried to fix this by tracking the video carrier, but the problem gets worse. One possible reason for this is that the local oscilator used to generate the IQ signal is not stable, which unfortunately cannot be fixed... Can someone verify this problem and/or suggest any solution. Hi Achilleas! I just tried your script and it works fine here - slightly modified to use real signal from a local tv station. An mp3 of a short segment is here: http://webpages.charter.net/cswiger/TV_CH8.mp3 You can ... tell, it's television. Sounds like you have another winner. Here's what I used: --- #!/bin/env python from gnuradio import gr from gnuradio import audio_oss as audio from gnuradio import usrp from gnuradio.wxgui import stdgui from gnuradio.wxgui import fftsink, scopesink # oldfftsink, oldfftsink_linear import wx import math class test_app_flow_graph (stdgui.gui_flow_graph): def __init__(self, frame, panel, vbox, argv): stdgui.gui_flow_graph.__init__ (self, frame, panel, vbox, argv) # build our flow graph adc_rate = 64e6 decim = 250 input_rate = adc_rate / decim # 256 Khz fm_decim = 1 fm_rate = input_rate / fm_decim # 256 kHz audio_decimation = 8 audio_rate = fm_rate / audio_decimation # 32 kHz # filename = "ntsc-short-complex-baseband-8MS.dat" #src = "" (gr.sizeof_short, filename,True) #conv = gr.interleaved_short_to_complex () src = "" (0, decim) src.set_rx_freq(0, 28.75e6) # 28Mhz (36Mhz) + .75 audio carrier # tuner is set to 185Mhz --> 36Mhz, local channel 8 # aural carrier 185.75 src.set_pga(0,0) # Pilot extraction: #Ap= 100.0 #p_width = 100e3 #pilot_coefs = gr.firdes.band_pass (2/Ap, input_rate, 1.75e6-p_width/2, 1.75e6+p_width/2, p_width, gr.firdes.WIN_HAMMING) #pilot_filter = gr.fir_filter_ccf(1, pilot_coefs) #real = gr.complex_to_real() #imag = gr.complex_to_imag() #neg = gr.multiply_const_ff(-1.0) #conj = gr.float_to_complex() # FM signal extraction #correction = gr.multiply_cc() fm_coeffs = gr.firdes.low_pass(1.0,input_rate,100e3,50e3,gr.firdes.WIN_HAMMING) fmc = gr.freq_xlating_fir_filter_ccf (fm_decim,fm_coeffs,-2.75e6, input_rate) peak_amp = 1.0 fm_demod_gain = 1.0 / (2 * math.pi * 75e3 / peak_amp / fm_rate) volume = 0.4 fm_demod = gr.quadrature_demod_cf (volume*fm_demod_gain) # L+R processing: LPF + decimation # compute FIR filter taps for audio filter width = 1e3 audio_coefs = gr.firdes.low_pass (1.0, fm_rate, 15e3, width, gr.firdes.WIN_HAMMING) audio_filter_lpr = gr.fir_filter_fff (audio_decimation, audio_coefs) audio_sink = audio.sink (int (audio_rate)) block1, fft_win1 = fftsink.make_fft_sink_c (self, panel, "Data", 1024, input_rate) block2, fft_win2 = fftsink.make_fft_sink_c (self, panel, "Data", 512, fm_rate) block3, fft_win3 = fftsink.make_fft_sink_f (self, panel, "Data", 256, audio_rate) #self.connect (src, conv) #self.connect (conv, pilot_filter) #self.connect (pilot_filter,real) #self.connect (pilot_filter,imag) #self.connect (imag,neg) #self.connect (real,(conj,0)) #self.connect (neg,(conj,1)) #self.connect (conv,(correction,0)) #self.connect (conj,(correction,1)) #self.connect (correction, fmc) self.connect (src, fmc) self.connect (fmc,fm_demod) self.connect (fm_demod,audio_filter_lpr) self.connect (audio_filter_lpr,audio_sink) self.connect (src, block1) self.connect (fmc, block2) self.connect (audio_filter_lpr, block3) vbox.Add (fft_win1, 1, wx.EXPAND) vbox.Add (fft_win2, 1, wx.EXPAND) vbox.Add (fft_win3, 1, wx.EXPAND) def main (): app = stdgui.stdapp (test_app_flow_graph, "FFT Sink Test App") app.MainLoop ()
