Re: [Discuss-gnuradio] Native Interface between MATLAB/Simulink and USRP available
Hello Dominik, Dominik Auras schrieb: > Did you test this with Linux? Are there any plans to support Linux/GCC > etc.? Nope, we have not done anything on Linux with this interface. If somebody wants to maintain a Linux-Version of simulink-usrp, we could add this as a project on e.g. SourceForge (see below). So if anybody is interested in porting this to Linux _and_ maintaining the Linux-specific parts, please let us know. Enno P.S.: A short remark about why we are not adding this to CGRAN (which was proposed in one mail we received): since simulink-usrp does not have to do too much with GNU Radio (except for using libusrp, of course) we feel that it would be inappropriate to use CGRAN for hosting of this project. I think that CGRAN should be left for "real" GNU Radio applications. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] DBSRX filter efficiency?
Dear Gnuradio hackers, I have problems with the DBSRX module of the USRP: I see GSM on all frequencies. I hope somebody can answer my questions: Is there an antialiasing filter somewhere in the design? If so, what is its nominal efficiency? Where can I find data sheets for the MAX211x chips? Thanks in advance, Andreas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Unable to find USRP#0
Hi Can anyone please help me? I am using gnuradio3.1.3. When I try to run usrp_benchmark_usb.py, I get the a RuntimeError: Unable to find USRP #0. When I issue ls -lR /dev/bus/usb | grep usrp, I didn't get any message. This is the first time that I connect USRP board to PC. Please help me. Thanks a lot. Teodora This is a log: Testing 2MB/sec... Traceback (most recent call last): File "./usrp_benchmark_usb.py", line 106, in main () File "./usrp_benchmark_usb.py", line 96, in main ok = run_test (rate, verbose) File "./usrp_benchmark_usb.py", line 63, in run_test usrp_tx = usrp.sink_s (0, tx_interp) File "/usr/local/lib/python2.5/site-packages/gnuradio/usrp.py", line 229, in __init__ _ensure_rev2(which) File "/usr/local/lib/python2.5/site-packages/gnuradio/usrp.py", line 85, in _ensure_rev2 v = _look_for_usrp(which) File "/usr/local/lib/python2.5/site-packages/gnuradio/usrp.py", line 79, in _look_for_usrp raise RuntimeError, "Unable to find USRP #%d" % (which,) RuntimeError: Unable to find USRP #0 -- 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] Want to record Fm samples
Hello, I want to record a FM sample that I am receiving from my USRP.I have attached a file_sink block in the grc to the fm receiver simulation.The file extension that I am using is .dat.When I convert this .dat file to mp3 using sox or lame,my sample is highly degraded than the sample I can hear form the Fm receiver.Can someone suggest to me how to save samples without degradation.? Thanks for your help Mayur -- View this message in context: http://www.nabble.com/Want-to-record-Fm-samples-tp23595821p23595821.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unable to find USRP#0
On Mon, May 18, 2009 at 4:28 AM, Teodora Petrovic wrote: > Can anyone please help me? I am using gnuradio3.1.3. > When I try to run usrp_benchmark_usb.py, I get the a RuntimeError: > Unable to find USRP #0. > > When I issue > > ls -lR /dev/bus/usb | grep usrp, > > I didn't get any message. It is likely that you do not have the permissions set correctly to allow your user account to have access to the USRP hardware. Try running as root; if everything works, then this is the case. To allow a non-root user to access the USRP, follow the instructions here: http://gnuradio.org/trac/wiki/UdevConfig Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] half USRP
Hello This is for Matt. I'm not aware about USRP requirement's history, hence I'm asking. I apologise immediately if the question is stupid enough... :-) have you ever think about a simplified USRP, or 1/2 USRP, having only 1 side TX and RX? Would it make a cost difference (maybe on a large volume basis)? Would it save some space? Reason for asking is that many (most?) applications are 1+1 channel, and saving space may allow more compact boxes, etc etc. Thanks for your answer alberto. E' arrivato Tiscali Mobile! Acquista la tua SIM Tiscali a soli €5 e scopri la semplicità e la convenienza del nuovo servizio per il tuo cellulare. Passa a Tiscali Mobile http://abbonati.tiscali.it/promo/tiscalimobile/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] half USRP
Hi Alberto, the USRP2 is only 1xTX and 1xRX. However, the USRP2 costs more than the USRP1 because of its bigger FPGA and faster ADC/DAC (in addition to SDRAM and other hardware). In short, the cost savings are minimal if you would remove one RX and one TX from the USRP1 (you might be able to choose a smaller ADC/DAC, and save some connectors). However, you could save quiet some space (half of the board). Hope that helps. Cheers, Thomas On Mon, May 18, 2009 at 8:33 AM, Alberto Trentadue wrote: > Hello > This is for Matt. > I'm not aware about USRP requirement's history, hence I'm asking. > I apologise immediately if the question is stupid enough... :-) > > have you ever think about a simplified USRP, or 1/2 USRP, having only 1 side > TX and RX? > Would it make a cost difference (maybe on a large volume basis)? Would it > save some space? > Reason for asking is that many (most?) applications are 1+1 channel, and > saving space may allow more compact boxes, > etc etc. > > Thanks for your answer > > alberto. > > > E' arrivato Tiscali Mobile! Acquista la tua SIM Tiscali a soli €5 e scopri la > semplicità e la convenienza del nuovo servizio per il tuo cellulare. Passa a > Tiscali Mobile http://abbonati.tiscali.it/promo/tiscalimobile/ > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- "Don't complain; Just work harder" - Randy Pausch Thomas Schmid, Ph.D. Candidate Networked & Embedded Systems Laboratory (NESL) University of California, Los Angeles (UCLA) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Native Interface between MATLAB/Simulink and USRP available
Hi Enno, If somebody wants to maintain a Linux-Version of simulink-usrp, we could add this as a project on e.g. SourceForge (see below). So if anybody is interested in porting this to Linux _and_ maintaining the Linux-specific parts, please let us know. I already ported it to linux today, however don't want to maintain it. The main change was to use a Makefile (which ideally will be generated by Automake, but isn't till now) and to note that matlab under linux passes strings as characters, not wide characters (to whatever reason). There were a few M$-specific code parts, too. Though no big change was necessary. Thanks for the great program! Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't stop the top_block which contain transmit_path with GNU Radio version 11001
On Sun, May 17, 2009 at 07:34:16PM -0700, Ling Huang wrote: > > > < To get it to stop, send it a message with > > > I set transmit path message with type = 1, but it still not work, it hang in > wait() either. > > Will the USRP block the system? No. You can find out where it's hung by running gdb. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DBSRX filter efficiency?
On Mon, May 18, 2009 at 12:08:01PM +0200, Andreas Bogk wrote: > Dear Gnuradio hackers, > > I have problems with the DBSRX module of the USRP: I see GSM on all > frequencies. I hope somebody can answer my questions: Is there an > antialiasing filter somewhere in the design? If so, what is its nominal > efficiency? Where can I find data sheets for the MAX211x chips? > > Thanks in advance, > Andreas Hi Andreas! Welcome! Try turning the Rx gain down. The datasheets should be on Maxim's site, though I think they're discontinuing the part. If you can't locate them, let me know and I'll see if I can't find one for you. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DBSRX filter efficiency?
Eric Blossom wrote: Hi Andreas! Welcome! Thanks! :) Try turning the Rx gain down. Been there, done that. It doesn't get rid of the images. The datasheets should be on Maxim's site, though I think they're discontinuing the part. If you can't locate them, let me know and I'll see if I can't find one for you. I can't find them, and googling for MAX211x only brings me to Gnuradio related information. Is there a magic part number I need to know? I'd appreciate the datasheets, or alternatively the information that the filters are indeed in the chip and not tunable. Cheers, Andreas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DBSRX filter efficiency?
On Mon, May 18, 2009 at 07:11:43PM +0200, Andreas Bogk wrote: > Eric Blossom wrote: >> Hi Andreas! Welcome! >> > > Thanks! :) > >> Try turning the Rx gain down. >> > > Been there, done that. It doesn't get rid of the images. > >> The datasheets should be on Maxim's site, though I think they're >> discontinuing the part. If you can't locate them, let me know and >> I'll see if I can't find one for you. >> > I can't find them, and googling for MAX211x only brings me to Gnuradio > related information. Is there a magic part number I need to know? I'd > appreciate the datasheets, OK, I'll look for them later on today. > or alternatively the information that the > filters are indeed in the chip and not tunable. The chip has a controllable IF-filter bandwidth. It can be controlled using the set_bw method on the daugherboard subdevice. Pass it the desired bandwith in Hz. The DBSRX code will accept a value between 1e6 and 33e6, though the chip's only spec'd down to 4e6. By default we're running it wide open (33e6). Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] half USRP
> have you ever think about a simplified USRP, or 1/2 USRP, having only 1 side > TX and RX? > Would it make a cost difference (maybe on a large volume basis)? Would it > save some space? > Reason for asking is that many (most?) applications are 1+1 channel, and > saving space may allow more compact boxes, > etc etc. How about a 64 x USRP? It would be cool if there was a USRP that had many receiver channels, and it would also have a simple beam-former built into the FPGA. juha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DBSRX filter efficiency?
Eric Blossom wrote: [datasheets] OK, I'll look for them later on today. Matt sent me the correct part number (MAX2118), and I've found the data sheet. The chip has a controllable IF-filter bandwidth. It can be controlled using the set_bw method on the daugherboard subdevice. Pass it the desired bandwith in Hz. The DBSRX code will accept a value between 1e6 and 33e6, though the chip's only spec'd down to 4e6. By default we're running it wide open (33e6). I'm going to play with this, thanks for the info! Andreas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DBSRX filter efficiency?
Eric Blossom wrote: > Hi Andreas! Welcome! > > Try turning the Rx gain down. > > The datasheets should be on Maxim's site, though I think they're > discontinuing the part. If you can't locate them, let me know and > I'll see if I can't find one for you. > > Eric > > > Arh! I knew it had to happen some day. What happens to DBS_RX when MAX2118s aren't available any more? -- Marcus Leech Principal Investigator, Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DBSRX filter efficiency?
Marcus D. Leech wrote: Eric Blossom wrote: Hi Andreas! Welcome! Try turning the Rx gain down. The datasheets should be on Maxim's site, though I think they're discontinuing the part. If you can't locate them, let me know and I'll see if I can't find one for you. Eric Arh! I knew it had to happen some day. What happens to DBS_RX when MAX2118s aren't available any more? We have plenty of chips and boards for the near future. They make a replacement chip (MAX2112), which will require a board spin. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] half USRP
>> have you ever think about a simplified USRP, or 1/2 USRP, having only 1 side >> TX and RX? > How about a 64 x USRP? It would be cool if there was a USRP that had > many receiver channels, and it would also have a simple beam-former > built into the FPGA. All of the schematics for the USRP and daughter boards are available in the usrp-hw branch (http://www.gnuradio.org/trac/browser/usrp-hw/trunk). You are free to build a 1/2 USRP, just remove the components you don't need, or, if you wish, put a 1/2 USRP and a dedicated daughter board on the same PCB, it's up to you. The problem with asking matt or one of the other gnuradio contributors to do this is that it's not as simple as it sounds on the surface: You would need to remove the extraneous components on the USRP boards, re-do the layout, then fab and test a new board. Then you also have to re-write the FGPA firmware and sink/source blocks in gnuradio. It's definitely do-able, but it's not a "while you're at it" type of project. There was a very recent discussion on the board regarding a 'hand held' sized usrp where we discussed these same issues. Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP1 USB I/F failure & repair
About a month ago, our USRP1 Rev. 4.5 (Ser. #2728) became erratic in it USB connection and communications. A short while after, USB failed altogether. I put scope probes on the USB + and - data lines and observed that one of the signals had a much different sort of signal than the other. Following advice from Matt Ettus given to others who had experienced USB failure, I ordered a replacement USB chip along with a Chipquik SMD removal kit. Replacement of the chip had no effect, so I was forced to look more carefully for a cause. It turns out that one of the 0603 capacitors installed near the USB receptacle (C73, C74) was shorted, and removal of these 2 capacitors restored USB function. I'm posting this description of my experiences for the benefit of others on the list. I suspect that C73 and C74 (which I can't find in various schematics and BOMs for USRP1) were added in the hope that they would provide a path for electrostatic discharges, which is ironic. In my experience, low-capacitance avalanche breakdown devices are more suitable for this purpose. I can highly recommend ChipQuik. Paul Mathews ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 USB I/F failure & repair
Paul Mathews wrote: About a month ago, our USRP1 Rev. 4.5 (Ser. #2728) became erratic in it USB connection and communications. A short while after, USB failed altogether. I put scope probes on the USB + and - data lines and observed that one of the signals had a much different sort of signal than the other. Following advice from Matt Ettus given to others who had experienced USB failure, I ordered a replacement USB chip along with a Chipquik SMD removal kit. Replacement of the chip had no effect, so I was forced to look more carefully for a cause. It turns out that one of the 0603 capacitors installed near the USB receptacle (C73, C74) was shorted, and removal of these 2 capacitors restored USB function. I'm posting this description of my experiences for the benefit of others on the list. I suspect that C73 and C74 (which I can't find in various schematics and BOMs for USRP1) were added in the hope that they would provide a path for electrostatic discharges, which is ironic. In my experience, low-capacitance avalanche breakdown devices are more suitable for this purpose. Paul, Thanks for your analysis of the situation. C73 and C74 are not actually capacitors, they are, as you say, electrostatic discharge protectors, part number PESD0402-060. I have not seen any fail in the manor you mention, but I suppose enough static could cause that. Has anyone else seen this failure mode? Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] USRP1 USB I/F failure & repair
Thanks for the clarification about C73, C74. The Raychem datasheet doesn't say so directly, I'm guessing that these parts are some form of varistor. In my experience, varistors are less reliable than silicon clamping devices, both in terms of their dynamic clamping characteristics and their ultimate failure characteristics. http://www.conformity.com/artman/publish/printer_211.shtml http://www.nxp.com/acrobat_download/applicationnotes/AN10753_1.pdf I work in a high humidity environment, and I'd be surprised if ESD was the cause of failure of these parts, anyway. I suspect that flexing of the circuit board during USB plugging/unplugging caused cracking. The large solder fillets on the parts may have contributed to the problem. Paul Mathews -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Monday, May 18, 2009 4:01 PM To: o...@whidbey.com Cc: 'GNURadio Discussion List' Subject: Re: [Discuss-gnuradio] USRP1 USB I/F failure & repair Paul Mathews wrote: > About a month ago, our USRP1 Rev. 4.5 (Ser. #2728) became erratic in > it USB connection and communications. A short while after, USB failed > altogether. I put scope probes on the USB + and - data lines and > observed that one of the signals had a much different sort of signal > than the other. Following advice from Matt Ettus given to others who > had experienced USB failure, I ordered a replacement USB chip along > with a Chipquik SMD removal kit. Replacement of the chip had no > effect, so I was forced to look more carefully for a cause. It turns > out that one of the 0603 capacitors installed near the USB receptacle > (C73, C74) was shorted, and removal of these 2 capacitors restored USB > function. I'm posting this description of my experiences for the > benefit of others on the list. > > I suspect that C73 and C74 (which I can't find in various schematics > and BOMs for USRP1) were added in the hope that they would provide a > path for electrostatic discharges, which is ironic. In my experience, > low-capacitance avalanche breakdown devices are more suitable for this > purpose. Paul, Thanks for your analysis of the situation. C73 and C74 are not actually capacitors, they are, as you say, electrostatic discharge protectors, part number PESD0402-060. I have not seen any fail in the manor you mention, but I suppose enough static could cause that. Has anyone else seen this failure mode? Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 USB I/F failure & repair
Matt Ettus wrote: > Paul Mathews wrote: > > Paul, > > Thanks for your analysis of the situation. C73 and C74 are not > actually capacitors, they are, as you say, electrostatic discharge > protectors, part number PESD0402-060. I have not seen any fail in the > manor you mention, but I suppose enough static could cause that. > > Has anyone else seen this failure mode? > > Matt > > Aren't ESD protectors usually MOVs, and don't MOVs usually fail by shorting? They can absorb so many joules of ESD, and after that they short out. In live electrical power lines, this usually causes the breaker to trip. The other type are GDTs, which fail open. But they don't fail very often. -- Marcus Leech Principal Investigator, Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Fwd: Re: [Discuss-gnuradio] USRP1 USB I/F failure & repair
On Mon, 18 May 2009 19:26:58 -0400, Marcus D. Leech wrote: Matt Ettus wrote: Paul Mathews wrote: Paul, Thanks for your analysis of the situation. C73 and C74 are not actually capacitors, they are, as you say, electrostatic discharge protectors, part number PESD0402-060. I have not seen any fail in the manor you mention, but I suppose enough static could cause that. Has anyone else seen this failure mode? Matt Aren't ESD protectors usually MOVs, and don't MOVs usually fail by shorting? They can absorb so many joules of ESD, and after that they short out. In live electrical power lines, this usually causes the breaker to trip. The other type are GDTs, which fail open. But they don't fail very often. I used to work on power supplies some time ago. We had one particular version with ESD protection on the output. They failed quite often, and yes, they do short when they fail. I was never convinced that the devices actually failed due to ESD, but more likely faulty manufacturing process. Ryan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't stop the top_block which contain transmit_path with GNU Radio version 11001
sorry, I'm not familiar with gdb, I can't get many useful infomation from that. The topblock start 6 threads (exept the mainloop) . After tb.stop(), five threads has exited, but leaving one. Here is the gdb infomation after tb.stop() gdb- (gdb) bt #0 0xb7f87430 in __kernel_vsyscall () #1 0xb7f41075 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb7bd7e17 in boost::condition_variable::wait (this=0x97285f0, m...@0xbff885b0) at /usr/include/boost/thread/pthread/condition_variable.hpp:35 #3 0xb7a3a1f2 in boost::thread::join () from /usr/lib/libboost_thread-mt-d.so.1.35.0 #4 0xb7a4b223 in gruel::thread_group::join_all (this=0x9728224) at thread_group.cc:78 #5 0xb7bcf4a0 in gr_scheduler_tpb::wait (this=0x9728220) at gr_scheduler_tpb.cc:94 #6 0xb7bd57c9 in gr_top_block_impl::wait (this=0x9684a18) at gr_top_block_impl.cc:124 #7 0xb7bd5080 in gr_top_block::wait (this=0x96aab50) at gr_top_block.cc:71 #8 0xb7bd5168 in ~gr_top_block (this=0x96aab50) at gr_top_block.cc:51 #9 0xb7c6fc58 in boost::detail::sp_counted_impl_p::dispose ( this=0x97095c0) at /usr/include/boost/checked_delete.hpp:34 #10 0xb7c5bd30 in _wrap_delete_gr_top_block_sptr (args=0xb595ea6c) at /usr/include/boost/detail/sp_counted_base_gcc_x86.hpp:145 #11 0x08062646 in PyObject_CallFunctionObjArgs () #12 0xb7c471b9 in PySwigObject_dealloc (v=0xb5b9de60) at gnuradio_swig_py_runtime.cc:1452 #13 0x08088e54 in ?? () #14 0x0809ff8b in ?? () #15 0x08088e54 in ?? () #16 0x0809ff8b in ?? () #17 0x081161cf in ?? () #18 0x080cfc13 in PyEval_EvalFrameEx () #19 0x080d0345 in PyEval_EvalCodeEx () #20 0x080d0557 in PyEval_EvalCode () #21 0x080edf8f in PyRun_FileExFlags () #22 0x080ee25a in PyRun_SimpleFileExFlags () #23 0x080595e7 in Py_Main () #24 0x08058962 in main () Eric Blossom wrote: > > > No. > > You can find out where it's hung by running gdb. > > Eric > > > > -- View this message in context: http://www.nabble.com/Can%27t-stop-the-top_block-which-contain-transmit_path-with-GNU-Radio-version-11001-tp23569318p23608703.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can't stop the top_block which contain transmit_path with GNU Radio version 11001
And here is the gdb after tb.wait() ---gdb wait--- #0 0xb7f1f430 in __kernel_vsyscall () #1 0xb7e1bdf1 in select () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7efbbc9 in ?? () from /usr/lib/python2.5/lib-dynload/time.so #3 0x080cea39 in PyEval_EvalFrameEx () #4 0x080d0345 in PyEval_EvalCodeEx () #5 0x080ce728 in PyEval_EvalFrameEx () #6 0x080d0345 in PyEval_EvalCodeEx () #7 0x080ce728 in PyEval_EvalFrameEx () #8 0x080cfbf5 in PyEval_EvalFrameEx () #9 0x080cfbf5 in PyEval_EvalFrameEx () #10 0x080cfbf5 in PyEval_EvalFrameEx () #11 0x080d0345 in PyEval_EvalCodeEx () #12 0x080d0557 in PyEval_EvalCode () #13 0x080edf8f in PyRun_FileExFlags () #14 0x080ee25a in PyRun_SimpleFileExFlags () #15 0x080595e7 in Py_Main () #16 0x08058962 in main () -- View this message in context: http://www.nabble.com/Can%27t-stop-the-top_block-which-contain-transmit_path-with-GNU-Radio-version-11001-tp23569318p23608871.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Python bindings for "config_mimo", "sync_every_pps"
On Sat, 2009-05-16 at 03:44 +0200, Changkyu Seol wrote: > It will be grateful if python bindings for "config_mimo", > "sync_every_pps" are added to usrp2_base.h and usrp2.i in gr-usrp2. These calls are now visible (as of trunk r11050) in the Python API as: from gnuradio import usrp2 u = usrp2.source_32fc() # any of the sinks or sources u.sync_every_pps(True) # False to disable u.config_mimo(usrp2.MC_WE_LOCK_TO_SMA) For the C++ API, the MC_* constants are now visible in the usrp2 namespace: usrp2::MC_WE_LOCK_TO_SMA ... You can see the definitions in , though it is automatically included for you. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 schematic files
Hi, Could you please inform about when we can access USRP2 schematic files. Thanks in advance. Regds, Sudhir ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Python bindings for "config_mimo", "sync_every_pps"
Johnathan Corgan wrote: > On Sat, 2009-05-16 at 03:44 +0200, Changkyu Seol wrote: > > These calls are now visible (as of trunk r11050) in the Python API as: > > from gnuradio import usrp2 > > u = usrp2.source_32fc() # any of the sinks or sources > u.sync_every_pps(True) # False to disable > u.config_mimo(usrp2.MC_WE_LOCK_TO_SMA) > > For the C++ API, the MC_* constants are now visible in the usrp2 > namespace: > > usrp2::MC_WE_LOCK_TO_SMA > ... > > You can see the definitions in , though it is > automatically included for you. > > Johnathan Thank you very much! Changkyu Seol -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
