[Discuss-gnuradio] gnuradio interface
hi to every onei need to know how can i interface GNU radio with wirless NIC in labtop ?please, support me with code that can do that ?thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] daughterboard xcvr2450 tx/rx
Hi everybody, I'm new in GNURadio and USRP's world. I'm working with ubuntu 8.04, USRP2, daughterboard xcvr2450, and last trunk of GNURadio. I'm trying (with GRC) to transmit and receive on the same USRP2 a sinusoidal signal. (with frequency 50 kHz). In my trasmition chain at first I generate a sinusoid with "signal source" block, after I transmit with "usrp2 sink" block, and in reception chain I receive with "usrp2 source" block and I see all with "fft sink" block. My program works correctly only if I set the frequency to 2.4GHz. If I try to shift the frequency to, for example, 2.45 GHz (or any other frequency) my program don't work correcly. What could be the problems, or What am I doing wrong? Which is the tx / rx switching rate for this daughterboard? Thank you in advance ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] audio_alsa_sink problem
When trying to use audio sink in GRC I get following error: audio: using audio_alsa audio_alsa_sink[hw:0,0]: set_period_time_near failed: Invalid argument Traceback (most recent call last): File "/home/gr/top_block.py", line 45, in tb = top_block() File "/home/gr/top_block.py", line 32, in __init__ self.audio_sink_0 = audio.sink(44100, "", True) File "/usr/local/lib64/python2.5/site-packages/gnuradio/audio_alsa.py", line 307, in sink return _audio_alsa.sink(*args, **kwargs) RuntimeError: audio_alsa_sink The audio test samples in gnuradio-examples/python/audio do work with no problems. I tried to google for further information, but found only the archive of this mail list suggesting to search the net for the solution. Looks like a recursive solution for me. :-) I am new to gnuradio stuff so it may well be my ignorance causing this, but I can not find any tutorials or manuals or documentation especially for the GRC. best regards, arto -- Arto Oksanen arto.oksa...@jklsirius.fi Muurame, Finland ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] audio_alsa_sink problem
On Sun, Mar 01, 2009 at 09:38:31PM +0200, Arto Oksanen wrote: > When trying to use audio sink in GRC I get following error: > > audio: using audio_alsa > audio_alsa_sink[hw:0,0]: set_period_time_near failed: Invalid argument > Traceback (most recent call last): > File "/home/gr/top_block.py", line 45, in > tb = top_block() > File "/home/gr/top_block.py", line 32, in __init__ > self.audio_sink_0 = audio.sink(44100, "", True) > File "/usr/local/lib64/python2.5/site-packages/gnuradio/audio_alsa.py", > line 307, in sink > return _audio_alsa.sink(*args, **kwargs) > RuntimeError: audio_alsa_sink > > > The audio test samples in gnuradio-examples/python/audio do work with > no problems. > > I tried to google for further information, but found only the archive > of this mail list suggesting to search the net for the solution. Looks > like a recursive solution for me. :-) Thanks for searching first! > I am new to gnuradio stuff so it may well be my ignorance causing > this, but I can not find any tutorials or manuals or documentation > especially for the GRC. I've seen the error before (but not on my h/w). Can you try using plughw:0,0 instead of hw:0,0 and see if that changes anything? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] SIGINT.ccc.de 2009 Call for Proposals
FYI, http://sigint.ccc.de/sigint/2009/wiki/Call_for_Proposals/English Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Hacking at Random: Dutch outdoor technology-conference
FYI, These outdoor European hacker get-togethers are a fabulous time! I highly recommend them! August 13-16, near Vierhouten, NL. https://har2009.org https://wiki.har2009.org/page/Main_Page Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] audio_alsa_sink problem
Using plughw:0,0 does not change anything. The error is the same. arto 2009/3/1 Eric Blossom : > On Sun, Mar 01, 2009 at 09:38:31PM +0200, Arto Oksanen wrote: >> When trying to use audio sink in GRC I get following error: >> >> audio: using audio_alsa >> audio_alsa_sink[hw:0,0]: set_period_time_near failed: Invalid argument >> Traceback (most recent call last): >> File "/home/gr/top_block.py", line 45, in >> tb = top_block() >> File "/home/gr/top_block.py", line 32, in __init__ >> self.audio_sink_0 = audio.sink(44100, "", True) >> File "/usr/local/lib64/python2.5/site-packages/gnuradio/audio_alsa.py", >> line 307, in sink >> return _audio_alsa.sink(*args, **kwargs) >> RuntimeError: audio_alsa_sink >> >> >> The audio test samples in gnuradio-examples/python/audio do work with >> no problems. >> >> I tried to google for further information, but found only the archive >> of this mail list suggesting to search the net for the solution. Looks >> like a recursive solution for me. :-) > > Thanks for searching first! > >> I am new to gnuradio stuff so it may well be my ignorance causing >> this, but I can not find any tutorials or manuals or documentation >> especially for the GRC. > > I've seen the error before (but not on my h/w). Can you try using > plughw:0,0 instead of hw:0,0 and see if that changes anything? > > Eric > -- Arto Oksanen arto.oksa...@jklsirius.fi Muurame, Finland ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-radar-mono file output
I just had a question regarding the log file this program produces. As far as I can tell, the samples are of the type gr-complex. I've tried using the file reading matlab script provided in the utils folder, but I can't arrange and display the data in a meaningful way. Could someone perhaps provide some guidance on the correct way to read and display the data from the echo output file produced by the gr-radar code? Regards Lance ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] audio_alsa_sink problem
im having the same problem dial tone in GRC crashes with the same error but the python dialtone example works fine running svn trunk on ubuntu 8.10 64bit standard install with a gigabyte ga-ep45-ud3r onboard audio... if you figure it out let me know... thanks.. On Sun, Mar 1, 2009 at 4:29 PM, Arto Oksanen wrote: > Using plughw:0,0 does not change anything. The error is the same. > > arto > > 2009/3/1 Eric Blossom : >> On Sun, Mar 01, 2009 at 09:38:31PM +0200, Arto Oksanen wrote: >>> When trying to use audio sink in GRC I get following error: >>> >>> audio: using audio_alsa >>> audio_alsa_sink[hw:0,0]: set_period_time_near failed: Invalid argument >>> Traceback (most recent call last): >>> File "/home/gr/top_block.py", line 45, in >>> tb = top_block() >>> File "/home/gr/top_block.py", line 32, in __init__ >>> self.audio_sink_0 = audio.sink(44100, "", True) >>> File "/usr/local/lib64/python2.5/site-packages/gnuradio/audio_alsa.py", >>> line 307, in sink >>> return _audio_alsa.sink(*args, **kwargs) >>> RuntimeError: audio_alsa_sink >>> >>> >>> The audio test samples in gnuradio-examples/python/audio do work with >>> no problems. >>> >>> I tried to google for further information, but found only the archive >>> of this mail list suggesting to search the net for the solution. Looks >>> like a recursive solution for me. :-) >> >> Thanks for searching first! >> >>> I am new to gnuradio stuff so it may well be my ignorance causing >>> this, but I can not find any tutorials or manuals or documentation >>> especially for the GRC. >> >> I've seen the error before (but not on my h/w). Can you try using >> plughw:0,0 instead of hw:0,0 and see if that changes anything? >> >> Eric >> > > > > -- > Arto Oksanen > arto.oksa...@jklsirius.fi > Muurame, Finland > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Hacking at Random: Dutch outdoor technology-conference
Eric Blossom wrote: > FYI, > > These outdoor European hacker get-togethers are a fabulous time! > I highly recommend them! August 13-16, near Vierhouten, NL. > > https://har2009.org > https://wiki.har2009.org/page/Main_Page > > Eric I can also highly recommend it. HAR2009 is the followup on What-The-Hack 2005 which was a great success. If you get your tickets now, you can still get a big early-order discount. I will be there, together with Pascal Schiks, a new Dutch GnuRadio contributor. Maybe we can setup a GnuRadio village. Greetings, Martin > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: OpenBTS compilation error
Jane Chen wrote: > Hi, > > I also encountered the same errors. > USRPDevice.h:42: error: ‘usrp_standard_rx_sptr’ does not name a type > USRPDevice.h:43: error: ‘usrp_standard_tx_sptr’ does not name a type > > Where can I get the "attached patch"??? It was in my original reply: Here you have the complete patch inline: <<>>> Index: Transceiver/USRPDevice.h === --- Transceiver/USRPDevice.h(revision 10235) +++ Transceiver/USRPDevice.h(working copy) @@ -19,8 +19,8 @@ */ +#define HAVE_BYTESWAP_H - #include "usrp_standard.h" #include "usrp_bytesex.h" #include "usrp_prims.h" <<>> Greetings, Martin > > Thank you, > Jane > > > > Martin Dvh wrote: >> T. W. wrote: >>> Windows XP machine. >>> ".deps/radioInterface.Tpo" -c >>> .libs/radioInterface.o >>> In file included from USRPDevice.h:25, >>> from radioInterface.h:25, >>> from radioInterface.cpp:23: >>> /usr/local/include/usrp_bytesex.h:37:2: warning: #warning Using >>> non-portable cod >>> e (likely wrong other than ILP32). >> This is a known bug. >> A temporary workaround can be done by using attached patch. >> >> See description below. >> >> Martin DvH wrote: >>> I haven't gotten to implementing the configure stuff yet. >>> >>> >>> This patch should be changed to use configure stuff to check for byteswap.h. >>> But for people wanting a quick-and-dirty hack it can be used. >>> >>> >>> Greetings, >>> Martin >>> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Modifications in benchmark_rx.py for USRP2
Smith L. wrote: Hi, I have been trying to use USRP2 as a receiver and USRP1 as a transmitter. The benchmark_tx.py file is working well for USRP1 but I did some modifications to benchmark_rx.py so that it can work on USRP2. But it didnt worked out. Can anyone help me with this modifcations so that I can establish communication between USRP1 and USRP2. Thanks in advance. You have to watch out for the different sample rates. When you set the sample rate in benchmark_tx/rx, it finds the closest sampling rate it can get through the interpolation/decimation factor in the USRP. Since the USRP and USRP2 have different speed DACs/ADCs, the exact values are going to be different. Run both with the -v option to see what the actual sample rate both the tx and rx side are using. To fix this, either try to find a rate that works for both USRP and USRP2, or, and this is a better solution, use a blks2.rational_resampler_ccf to resample to achieve closer sampling rates in both tx and rx. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] audio_alsa_sink problem
The audio sink in GRC has 3 parameters: sample_rate, device_name, ok_to_block The generated code looks like this: audio.sink(sample_rate, device_name, ok_to_block) If entering plughw:0,0 for the device_name does not fix the problem, I am unsure about what is wrong... GRC generates the code, we can always compare this to the code in a working example. Is the GRC block missing an extra (4th) parameter to audio.sink? -Josh davek wrote: im having the same problem dial tone in GRC crashes with the same error but the python dialtone example works fine running svn trunk on ubuntu 8.10 64bit standard install with a gigabyte ga-ep45-ud3r onboard audio... if you figure it out let me know... thanks.. On Sun, Mar 1, 2009 at 4:29 PM, Arto Oksanen wrote: Using plughw:0,0 does not change anything. The error is the same. arto 2009/3/1 Eric Blossom : On Sun, Mar 01, 2009 at 09:38:31PM +0200, Arto Oksanen wrote: When trying to use audio sink in GRC I get following error: audio: using audio_alsa audio_alsa_sink[hw:0,0]: set_period_time_near failed: Invalid argument Traceback (most recent call last): File "/home/gr/top_block.py", line 45, in tb = top_block() File "/home/gr/top_block.py", line 32, in __init__ self.audio_sink_0 = audio.sink(44100, "", True) File "/usr/local/lib64/python2.5/site-packages/gnuradio/audio_alsa.py", line 307, in sink return _audio_alsa.sink(*args, **kwargs) RuntimeError: audio_alsa_sink The audio test samples in gnuradio-examples/python/audio do work with no problems. I tried to google for further information, but found only the archive of this mail list suggesting to search the net for the solution. Looks like a recursive solution for me. :-) Thanks for searching first! I am new to gnuradio stuff so it may well be my ignorance causing this, but I can not find any tutorials or manuals or documentation especially for the GRC. I've seen the error before (but not on my h/w). Can you try using plughw:0,0 instead of hw:0,0 and see if that changes anything? Eric -- Arto Oksanen arto.oksa...@jklsirius.fi Muurame, Finland ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Hacking at Random: Dutch outdoor technology-conference
On Mon, Mar 02, 2009 at 12:56:12AM +0100, Martin Dvh wrote: > Eric Blossom wrote: > > FYI, > > > > These outdoor European hacker get-togethers are a fabulous time! > > I highly recommend them! August 13-16, near Vierhouten, NL. > > > > https://har2009.org > > https://wiki.har2009.org/page/Main_Page > > > > Eric > > I can also highly recommend it. > > HAR2009 is the followup on What-The-Hack 2005 which was a great success. > > If you get your tickets now, you can still get a big early-order discount. > > I will be there, together with Pascal Schiks, a new Dutch GnuRadio > contributor. That's great. I'm planning on being there too. > Maybe we can setup a GnuRadio village. Either that, or hook up with the folks in the Wireless village. They had a lot of infrastructure (big tents, kitchen, ...) at CCC camp. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Testing Whether USRP Can Transmit
I am working with a USRP1. I eventually will want to transmit and receive data packets between USRP1s, but right now I am getting to grips with the system. I am currently trying out the benchmark_tx, benchmark_rx programs. I call benchmark_rx on my USRP1's LFRX-LF daughterboard and leave it running, sudo python benchmark_rx.py -f 10M -R A --rx-gain=70 -v -r 500k -d 128 bits per symbol = 1 M&M clock recovery omega = 2.00 M&M clock recovery gain mu = 0.175000 M&M clock recovery mu = 0.50 M&M clock recovery omega rel. limit = 0.005000 frequency error = 0.00 Receive Path: Using RX d'board A: Flex 2400 Rx MIMO B Rx gain: 70 modulation: gmsk_demod bitrate: 250kb/s samples/symbol:2 decim: 128 Rx Frequency:10M I then call benchmark_tx on my USRP1's LFTX-LF daughterboard, sudo python benchmark_tx.py -TA -f 10M -r 500k -v --tx-amplitude=2 >>> gr_fir_fff: using SSE bits per symbol = 1 Gaussian filter bt = 0.35 Using TX d'board A: Flex 2400 Tx MIMO B Tx amplitude 2.0 modulation: gmsk_mod bitrate: 500kb/s samples/symbol:2 interp: 128 Tx Frequency:10M This prints out .. etc signifying packets are apparently being transmitted. However when I flip over to the benchmark_rx console no packet notifications are being displayed. Is the USRP transmitting data? Why is it not receiving this data if it is transmitting? Furthermore is there a test/example program just for testing whether the USRP is transmitting through its antenna? For instance a program that gets the USRP to produce an audible tone out of its antenna? -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Testing Whether USRP Can Transmit
On Mon, Mar 02, 2009 at 02:59:40AM +0100, William Sherman wrote: > I am working with a USRP1. I eventually will want to transmit and > receive data packets between USRP1s, but right now I am getting to grips > with the system. > > I am currently trying out the benchmark_tx, benchmark_rx programs. > > I call benchmark_rx on my USRP1's LFRX-LF daughterboard and leave it > running, > > sudo python benchmark_rx.py -f 10M -R A --rx-gain=70 -v -r 500k -d 128 > > bits per symbol = 1 > M&M clock recovery omega = 2.00 > M&M clock recovery gain mu = 0.175000 > M&M clock recovery mu = 0.50 > M&M clock recovery omega rel. limit = 0.005000 > frequency error = 0.00 > > Receive Path: > Using RX d'board A: Flex 2400 Rx MIMO B > Rx gain: 70 > modulation: gmsk_demod > bitrate: 250kb/s > samples/symbol:2 > decim: 128 > Rx Frequency:10M Note that your -d 128 is overriding your -r 500k, resulting in a rx bitrate of 250kb/s. Leave out the -d option. > I then call benchmark_tx on my USRP1's LFTX-LF daughterboard, > > sudo python benchmark_tx.py -TA -f 10M -r 500k -v --tx-amplitude=2 > > >>> gr_fir_fff: using SSE > bits per symbol = 1 > Gaussian filter bt = 0.35 > Using TX d'board A: Flex 2400 Tx MIMO B > Tx amplitude 2.0 > modulation: gmsk_mod > bitrate: 500kb/s > samples/symbol:2 > interp: 128 > Tx Frequency:10M Since you're using only the -r 500k option, you get the right answer, 500kb/s. > This prints out .. etc signifying packets are apparently being > transmitted. > > However when I flip over to the benchmark_rx console no packet > notifications are being displayed. > > Is the USRP transmitting data? Why is it not receiving this data if it > is transmitting? > > Furthermore is there a test/example program just for testing whether the > USRP is transmitting through its antenna? For instance a program that > gets the USRP to produce an audible tone out of its antenna? usrp_siggen.py Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] audio_alsa_sink problem
putting plughw:0,0 in as the hardware name for the audio sink worked for me, the default was blank... On Sun, Mar 1, 2009 at 7:48 PM, Josh Blum wrote: > The audio sink in GRC has 3 parameters: > sample_rate, device_name, ok_to_block > > The generated code looks like this: > audio.sink(sample_rate, device_name, ok_to_block) > > If entering plughw:0,0 for the device_name does not fix the problem, I am > unsure about what is wrong... GRC generates the code, we can always compare > this to the code in a working example. > > Is the GRC block missing an extra (4th) parameter to audio.sink? > > -Josh > > davek wrote: >> >> im having the same problem >> dial tone in GRC crashes with the same error >> but the python dialtone example works fine >> running svn trunk on ubuntu 8.10 64bit standard install with a >> gigabyte ga-ep45-ud3r onboard audio... >> if you figure it out let me know... >> thanks.. >> >> >> On Sun, Mar 1, 2009 at 4:29 PM, Arto Oksanen >> wrote: >>> >>> Using plughw:0,0 does not change anything. The error is the same. >>> >>> arto >>> >>> 2009/3/1 Eric Blossom : On Sun, Mar 01, 2009 at 09:38:31PM +0200, Arto Oksanen wrote: > > When trying to use audio sink in GRC I get following error: > > audio: using audio_alsa > audio_alsa_sink[hw:0,0]: set_period_time_near failed: Invalid argument > Traceback (most recent call last): > File "/home/gr/top_block.py", line 45, in > tb = top_block() > File "/home/gr/top_block.py", line 32, in __init__ > self.audio_sink_0 = audio.sink(44100, "", True) > File > "/usr/local/lib64/python2.5/site-packages/gnuradio/audio_alsa.py", > line 307, in sink > return _audio_alsa.sink(*args, **kwargs) > RuntimeError: audio_alsa_sink > > > The audio test samples in gnuradio-examples/python/audio do work with > no problems. > > I tried to google for further information, but found only the archive > of this mail list suggesting to search the net for the solution. Looks > like a recursive solution for me. :-) Thanks for searching first! > I am new to gnuradio stuff so it may well be my ignorance causing > this, but I can not find any tutorials or manuals or documentation > especially for the GRC. I've seen the error before (but not on my h/w). Can you try using plughw:0,0 instead of hw:0,0 and see if that changes anything? Eric >>> >>> >>> -- >>> Arto Oksanen >>> arto.oksa...@jklsirius.fi >>> Muurame, Finland >>> >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] (old) USRP schematics
G'day, can someone point me to the schematics of the old USRP in PDF or PS format? I had a browse in usrp-hw couldn't identify anything useful in there. Thanks, cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] audio_alsa_sink problem
this is from the working dial_tone.py dst = audio.sink (sample_rate, options.audio_output) and this is from GRC generated code: self.audio_sink_0 = audio.sink(44100, "plughw:0,0", True) For me it looks like the generated code has an extra parameter.. arto 2009/3/2 Josh Blum : > The audio sink in GRC has 3 parameters: > sample_rate, device_name, ok_to_block > > The generated code looks like this: > audio.sink(sample_rate, device_name, ok_to_block) > > If entering plughw:0,0 for the device_name does not fix the problem, I am > unsure about what is wrong... GRC generates the code, we can always compare > this to the code in a working example. > > Is the GRC block missing an extra (4th) parameter to audio.sink? > > -Josh > > davek wrote: >> >> im having the same problem >> dial tone in GRC crashes with the same error >> but the python dialtone example works fine >> running svn trunk on ubuntu 8.10 64bit standard install with a >> gigabyte ga-ep45-ud3r onboard audio... >> if you figure it out let me know... >> thanks.. >> >> >> On Sun, Mar 1, 2009 at 4:29 PM, Arto Oksanen >> wrote: >>> >>> Using plughw:0,0 does not change anything. The error is the same. >>> >>> arto >>> >>> 2009/3/1 Eric Blossom : On Sun, Mar 01, 2009 at 09:38:31PM +0200, Arto Oksanen wrote: > > When trying to use audio sink in GRC I get following error: > > audio: using audio_alsa > audio_alsa_sink[hw:0,0]: set_period_time_near failed: Invalid argument > Traceback (most recent call last): > File "/home/gr/top_block.py", line 45, in > tb = top_block() > File "/home/gr/top_block.py", line 32, in __init__ > self.audio_sink_0 = audio.sink(44100, "", True) > File > "/usr/local/lib64/python2.5/site-packages/gnuradio/audio_alsa.py", > line 307, in sink > return _audio_alsa.sink(*args, **kwargs) > RuntimeError: audio_alsa_sink > > > The audio test samples in gnuradio-examples/python/audio do work with > no problems. > > I tried to google for further information, but found only the archive > of this mail list suggesting to search the net for the solution. Looks > like a recursive solution for me. :-) Thanks for searching first! > I am new to gnuradio stuff so it may well be my ignorance causing > this, but I can not find any tutorials or manuals or documentation > especially for the GRC. I've seen the error before (but not on my h/w). Can you try using plughw:0,0 instead of hw:0,0 and see if that changes anything? Eric >>> >>> >>> -- >>> Arto Oksanen >>> arto.oksa...@jklsirius.fi >>> Muurame, Finland >>> >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Arto Oksanen arto.oksa...@jklsirius.fi Muurame, Finland ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] audio_alsa_sink problem
I will add a note to the documentation in grc audio blocks about plughw. Can you edit the generated code and test the following 2 combinations: self.audio_sink_0 = audio.sink(44100, "plughw:0,0", False) self.audio_sink_0 = audio.sink(44100, "plughw:0,0") Let me know. -Josh Arto Oksanen wrote: this is from the working dial_tone.py dst = audio.sink (sample_rate, options.audio_output) and this is from GRC generated code: self.audio_sink_0 = audio.sink(44100, "plughw:0,0", True) For me it looks like the generated code has an extra parameter.. arto 2009/3/2 Josh Blum : The audio sink in GRC has 3 parameters: sample_rate, device_name, ok_to_block The generated code looks like this: audio.sink(sample_rate, device_name, ok_to_block) If entering plughw:0,0 for the device_name does not fix the problem, I am unsure about what is wrong... GRC generates the code, we can always compare this to the code in a working example. Is the GRC block missing an extra (4th) parameter to audio.sink? -Josh davek wrote: im having the same problem dial tone in GRC crashes with the same error but the python dialtone example works fine running svn trunk on ubuntu 8.10 64bit standard install with a gigabyte ga-ep45-ud3r onboard audio... if you figure it out let me know... thanks.. On Sun, Mar 1, 2009 at 4:29 PM, Arto Oksanen wrote: Using plughw:0,0 does not change anything. The error is the same. arto 2009/3/1 Eric Blossom : On Sun, Mar 01, 2009 at 09:38:31PM +0200, Arto Oksanen wrote: When trying to use audio sink in GRC I get following error: audio: using audio_alsa audio_alsa_sink[hw:0,0]: set_period_time_near failed: Invalid argument Traceback (most recent call last): File "/home/gr/top_block.py", line 45, in tb = top_block() File "/home/gr/top_block.py", line 32, in __init__ self.audio_sink_0 = audio.sink(44100, "", True) File "/usr/local/lib64/python2.5/site-packages/gnuradio/audio_alsa.py", line 307, in sink return _audio_alsa.sink(*args, **kwargs) RuntimeError: audio_alsa_sink The audio test samples in gnuradio-examples/python/audio do work with no problems. I tried to google for further information, but found only the archive of this mail list suggesting to search the net for the solution. Looks like a recursive solution for me. :-) Thanks for searching first! I am new to gnuradio stuff so it may well be my ignorance causing this, but I can not find any tutorials or manuals or documentation especially for the GRC. I've seen the error before (but not on my h/w). Can you try using plughw:0,0 instead of hw:0,0 and see if that changes anything? Eric -- Arto Oksanen arto.oksa...@jklsirius.fi Muurame, Finland ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Import Error with usrp2
Hello, Yc Park I think that maybe you forget to set PYTHONPATH. Shih-Shen Yc Park wrote: > Last week, I succeed to get a response from my usrp2. > > After that, however, when I try usrp2_fft.py, or anything *.py related > with usrp2, I get the "Import Error with usrp2" error. > > (But when I try something *.py with usrp, it shows no error with usrp > library though it fails to work since no usrp is connected.) > > I guess it fails to find the usrp2 library in the python code. > > Can you guys help me with this error? > > > Young C. Park -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] audio_alsa_sink problem
What is needed IMHO is not extra documentation about GRC but to NOT USE plughw or require it when it is not needed. For those of us with sound cards like Delta or other many channeled things, this causes unnecessary burden on the complexity. Bob Josh Blum wrote: I will add a note to the documentation in grc audio blocks about plughw. Can you edit the generated code and test the following 2 combinations: self.audio_sink_0 = audio.sink(44100, "plughw:0,0", False) self.audio_sink_0 = audio.sink(44100, "plughw:0,0") Let me know. -Josh Arto Oksanen wrote: this is from the working dial_tone.py dst = audio.sink (sample_rate, options.audio_output) and this is from GRC generated code: self.audio_sink_0 = audio.sink(44100, "plughw:0,0", True) For me it looks like the generated code has an extra parameter.. arto ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] audio_alsa_sink problem
The grc dialtone flowgraph py would work ONLY if i changed BOTH self.audio_sink_0 = audio.sink(44100, "hw:0,0", True) to self.audio_sink_0 = audio.sink(32000, "plughw:0,0", True) and self.samp_rate = samp_rate = 44100 to self.samp_rate = samp_rate = 32000 not sure what to make of that... looks like I was stumbling on 2 different things, device name syntax and sample rate ( hardware limitation ? ) not sure... On Mon, Mar 2, 2009 at 2:09 AM, Bob McGwier wrote: > What is needed IMHO is not extra documentation about GRC but to NOT USE > plughw or require it when it is not needed. For those of us with sound > cards like Delta or other many channeled things, this causes unnecessary > burden on the complexity. > > Bob > > > Josh Blum wrote: >> >> I will add a note to the documentation in grc audio blocks about plughw. >> >> Can you edit the generated code and test the following 2 combinations: >> >> self.audio_sink_0 = audio.sink(44100, "plughw:0,0", False) >> self.audio_sink_0 = audio.sink(44100, "plughw:0,0") >> >> Let me know. -Josh >> >> Arto Oksanen wrote: >>> >>> this is from the working dial_tone.py >>> >>> dst = audio.sink (sample_rate, options.audio_output) >>> >>> and this is from GRC generated code: >>> >>> self.audio_sink_0 = audio.sink(44100, "plughw:0,0", True) >>> >>> For me it looks like the generated code has an extra parameter.. >>> >>> arto >>> >>> > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Import Error with usrp2
Which version of GNU Radio are you using? USRP2 support isn't in 3.1.3. Kieran On Mon, Feb 23, 2009 at 12:04 AM, Yc Park wrote: > Last week, I succeed to get a response from my usrp2. > > After that, however, when I try usrp2_fft.py, or anything *.py related > with usrp2, I get the "Import Error with usrp2" error. > > (But when I try something *.py with usrp, it shows no error with usrp > library though it fails to work since no usrp is connected.) > > I guess it fails to find the usrp2 library in the python code. > > Can you guys help me with this error? > > > Young C. Park > -- > Posted via http://www.ruby-forum.com/. > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
