Re: [Discuss-gnuradio] 16 digital I/O lines to control external devices like antenna switches
On 05/21/2010 01:37 AM, Matt Ettus wrote: > > > Each daughterboard connector has 16 GPIOs. Some of them are used by > the daughterboards, but others are available for your use. On the > WBX, io_tx[14:8] are available for you to use, and they come to the > connector on the grand-daughterboard. > > If you need to synchronize the action of these pins precisely, the > bets way to do this is by modifying the FPGA. If you just need to > turn them on and off from software, you can do that with the API. > > Matt > > The schematic for WBX makes it look like a couple of the io_rx are available as well--are they not? -- 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] 16 digital I/O lines to control external devices like antenna switches
On 05/20/2010 10:45 PM, Marcus D. Leech wrote: On 05/21/2010 01:37 AM, Matt Ettus wrote: Each daughterboard connector has 16 GPIOs. Some of them are used by the daughterboards, but others are available for your use. On the WBX, io_tx[14:8] are available for you to use, and they come to the connector on the grand-daughterboard. If you need to synchronize the action of these pins precisely, the bets way to do this is by modifying the FPGA. If you just need to turn them on and off from software, you can do that with the API. Matt The schematic for WBX makes it look like a couple of the io_rx are available as well--are they not? Yes, some others are available as well. You need to look at both the wbx and grandaughterboard schematics. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 16 digital I/O lines to control external devices like antenna switches
On 05/18/2010 06:57 PM, Harley Myler wrote: Hi all, Now that I have the USRP2 playing the university NPR station in my office, it is now time to get down to serious work. Could someone please, in a nutshell, explain one of the features of the WBX (as one of the transceiver series) daughterboard that states: /16 digital I/O lines to control external devices like antenna switches/ I would greatly appreciate just a nudge in the right direction, such as, where are these (connector?)? How are they accessed (Python script, FPGA re-write, etc.)? What I need to do is cycle through a set of receiving antennas, sampling signal from each one in a scan operation. If anyone has already done this I would dearly love to know your process. Each daughterboard connector has 16 GPIOs. Some of them are used by the daughterboards, but others are available for your use. On the WBX, io_tx[14:8] are available for you to use, and they come to the connector on the grand-daughterboard. If you need to synchronize the action of these pins precisely, the bets way to do this is by modifying the FPGA. If you just need to turn them on and off from software, you can do that with the API. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN 80211b Transmitter with GNURadio 3.2.2 and USRP1
I do not remember specifically what I used at the command line to get the two USRP2s to talk to each other. I know I had it working for 1 and 2 Mbps. I think something must be messed up with the spreading sequence. George, wasn't there a discussion on that sometime ago? I remember there were plots being exchanged on the mail list. It was on a project I worked on a year ago so its a little foggy. Sorta random, the guy who wrote a lot of the SPAN code ended up in the same lab I'm in now. On Thu, May 20, 2010 at 8:27 PM, George Nychis wrote: > > > On Thu, May 20, 2010 at 11:08 PM, Smith L. wrote: > >> >> Thanks George for your inputs. >> >> I have closely been monitoring cgran website. However, every project seems >> to be focusing on how well one can use USRP1 or USRP2 as 80211b receiver. >> But my goal is to communicate between two USRPs (whether USRP1s or USRP2s) >> using bbn 80211b code. >> >> From the previous discussions on this forum, it seems that quite a few >> people were able to communicate and decode packets correctly using two >> USRP2s and usrp2_version bbn 80211b code. I am trying to know whether the >> usrp2_version code needs any modification or specific command line >> arguments. >> > > No problem! Maybe check the date/time of a post to the board in which > someone reported success and try to grab a version from SVN relevant to that > timestamp. Maybe something changed in between breaking something. I have > two USRP2s hooked up, I can try the code out myself tomorrow. > > - George > > ___ > 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] help req finding files
hi I am using wbx duaghterboard with usrp1, revision 4.5, serial number 4599, when I am trying to run usrp_fft.py, this board is being detected by the program, but when I am trying to run OpenBTS, it is not transmitting any data. Please let me know that gnuradio or usrp needs any special configuration to run this board, what should I do to use 2 dbrx db on single usrp. your reply is appreciated. Thank you On 5/21/10, jack william wrote: > > Hi, > I wanted to ask that where can i find the .c files of different built in > modules of gnuradio? > e.g. for gr.channel_model i have been able to locate gr.channel_model.cc > ,gr.channel_model.h file but not gr.channel_model.c file. > Thanks. > Cheers. > > > _ > Hotmail is redefining busy with tools for the New Busy. Get more from your > inbox. > http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2 -- Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] help req finding files
Hi, I wanted to ask that where can i find the .c files of different built in modules of gnuradio? e.g. for gr.channel_model i have been able to locate gr.channel_model.cc ,gr.channel_model.h file but not gr.channel_model.c file. Thanks. Cheers. _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN 80211b Transmitter with GNURadio 3.2.2 and USRP1
On Thu, May 20, 2010 at 11:08 PM, Smith L. wrote: > > Thanks George for your inputs. > > I have closely been monitoring cgran website. However, every project seems > to be focusing on how well one can use USRP1 or USRP2 as 80211b receiver. > But my goal is to communicate between two USRPs (whether USRP1s or USRP2s) > using bbn 80211b code. > > From the previous discussions on this forum, it seems that quite a few > people were able to communicate and decode packets correctly using two > USRP2s and usrp2_version bbn 80211b code. I am trying to know whether the > usrp2_version code needs any modification or specific command line > arguments. > No problem! Maybe check the date/time of a post to the board in which someone reported success and try to grab a version from SVN relevant to that timestamp. Maybe something changed in between breaking something. I have two USRP2s hooked up, I can try the code out myself tomorrow. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] description of coding
salam, self.txpath=transmit_path(modulator, options) # self.txpath receive n hold pointer from transmit_path() function self.connect(self.txpath) #call function self.connect() which hold pointer class my_top_block(gr.top_block): # new class created def __init__(self, modulator, options): # __init__ method initialization with object variable declaration gr.top_block.__init__(self)# parent/father constructor is called #__init__ method passes modulator and options arguments/parameter to function whose call it. class my_top_block(gr.top_block): def __init__(self): gr.top_block.__init__(self) sample_rate = 32000 # local variable, no need to declare in python ampl = 0.1 ma 2 cent understanding, regards, kaeroul -- View this message in context: http://old.nabble.com/description-of-coding-tp28593068p28629271.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] BBN 80211b Transmitter with GNURadio 3.2.2 and USRP1
Thanks George for your inputs. I have closely been monitoring cgran website. However, every project seems to be focusing on how well one can use USRP1 or USRP2 as 80211b receiver. But my goal is to communicate between two USRPs (whether USRP1s or USRP2s) using bbn 80211b code. >From the previous discussions on this forum, it seems that quite a few people were able to communicate and decode packets correctly using two USRP2s and usrp2_version bbn 80211b code. I am trying to know whether the usrp2_version code needs any modification or specific command line arguments. gnychis wrote: > > On Thu, May 20, 2010 at 9:29 PM, Smith L. wrote: > >> >> Hi Colby, >> >> Were you able to communicate between two USRP2s using bbn 80211 >> usrp2_version code? >> >> I am not able to receive packets using USRP2 receiver even when other >> USRP2 >> is transmitting. Can you please let me know if there are any changes >> required to be made in the usrp2_version code or any specific command >> line >> parameters to make this work (i.e. to receive 80211b packets with USRP2 >> with >> another USRP2 transmitting). >> >> Currently, I can only receive beacons from nearby access points using >> USRP2. >> >> > Not an answer to your questions... but another project to suggest: > https://www.cgran.org/wiki/SPAN80211b > > They had pretty good luck at receiving 802.11b transmissions on USRP1 by > putting the despreading in the FPGA. No transmit code though from what I > remember. > > - George > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/BBN-80211b-Transmitter-with-GNURadio-3.2.2-and-USRP1-tp28623863p28629240.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] BBN 80211b Transmitter with GNURadio 3.2.2 and USRP1
On Thu, May 20, 2010 at 9:29 PM, Smith L. wrote: > > Hi Colby, > > Were you able to communicate between two USRP2s using bbn 80211 > usrp2_version code? > > I am not able to receive packets using USRP2 receiver even when other USRP2 > is transmitting. Can you please let me know if there are any changes > required to be made in the usrp2_version code or any specific command line > parameters to make this work (i.e. to receive 80211b packets with USRP2 > with > another USRP2 transmitting). > > Currently, I can only receive beacons from nearby access points using > USRP2. > > Not an answer to your questions... but another project to suggest: https://www.cgran.org/wiki/SPAN80211b They had pretty good luck at receiving 802.11b transmissions on USRP1 by putting the despreading in the FPGA. No transmit code though from what I remember. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN 80211b Transmitter with GNURadio 3.2.2 and USRP1
Hi Colby, Were you able to communicate between two USRP2s using bbn 80211 usrp2_version code? I am not able to receive packets using USRP2 receiver even when other USRP2 is transmitting. Can you please let me know if there are any changes required to be made in the usrp2_version code or any specific command line parameters to make this work (i.e. to receive 80211b packets with USRP2 with another USRP2 transmitting). Currently, I can only receive beacons from nearby access points using USRP2. Any input on this issue is appreciated. Thanks, Smith Colby Boyer-2 wrote: > > Cool to hear about the OFDM 802.11 project. > > When I was working with the USRP2 version, I was only able to get two > USRP2s > to talk to each other. I can't remember if I was able to get it to decode > packets from a chipset, that was a year ago. > > I do remember that sometime ago, there was further discussion on getting > the > spreading waveform correct since it was not matching the 802.11 roll off > specs. My first guess is to check the match filter being used (if you can > capture the chipset's waveform). > > On Thu, May 20, 2010 at 1:08 PM, George Nychis wrote: > >> >> >> On Thu, May 20, 2010 at 3:14 PM, Smith L. wrote: >> >>> >>> Thanks for the help, Doug. >>> >>> I do have two USRP2s and hence was also working on the usrp2_version >>> code. >>> I >>> have both the transmitter and receiver code individually working >>> correctly >>> with USRP2. However, the receiver is not able to receive the packets >>> correctly from the transmitter (i.e in case of USRP2). I always get bad >>> CRC >>> message. >>> >>> I have looked up the forum and everybody seem to stuck with the same >>> problem. Is there any work around to solve this problem? >>> >>> From the forum discussion, it seems that one of the issues is the >>> preamble. >>> >>> Any idea how to make synchronize the receiver so that it can receive the >>> packets from USRP2 transmitter using bbn code. >>> >>> >> I struggled with this for quite a while. I never understood exactly >> where >> a standard card was not able to decode it. Large frequency offset maybe? >> I >> never got a single packet through. >> >> Can I suggest something? Try out this 802.11 project: >> https://www.cgran.org/wiki/ftw80211ofdmtx >> >> They definitely claim that a standard NIC can decode the packets, but I >> never personally got around to trying it. The code seemed pretty clean, >> and >> I was able to use it to generate proper packet signatures... so the >> modulation is definitely correct. >> >> - George >> >> ___ >> 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 > > -- View this message in context: http://old.nabble.com/BBN-80211b-Transmitter-with-GNURadio-3.2.2-and-USRP1-tp28623863p28628773.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
[Discuss-gnuradio] A big THANK YOU!
Hi All, Just wanted to thank everyone who helped me successfully install GNURADIO on windows XP. A very, very big thank you to DON WARD, who patiently kept suggesting me what was going wrong in my basic installation. Many of his suggestions were priceless and I can't find enough words to thank him. I got an A in my course of GNU RADIO all because of the help I got from him. Its very tough for any newbie to get genuine help when starting off and Don provided me with just the same. Thank you once again.For all those who think, that helping newbies is a waste of time, I just wanted to tell them that, someone has been kind to me by helping me out, this will reflect as a chain and I am surely going to help if some other newbie asks me any doubt. It takes a lot to stick to anyone in times of trouble. So do not get frustrated if you have to help anyone,even if it means that you will be helping without expecting anything in return.Thank you once again.Regards,Reena ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN 80211b Transmitter with GNURadio 3.2.2 and USRP1
Cool to hear about the OFDM 802.11 project. When I was working with the USRP2 version, I was only able to get two USRP2s to talk to each other. I can't remember if I was able to get it to decode packets from a chipset, that was a year ago. I do remember that sometime ago, there was further discussion on getting the spreading waveform correct since it was not matching the 802.11 roll off specs. My first guess is to check the match filter being used (if you can capture the chipset's waveform). On Thu, May 20, 2010 at 1:08 PM, George Nychis wrote: > > > On Thu, May 20, 2010 at 3:14 PM, Smith L. wrote: > >> >> Thanks for the help, Doug. >> >> I do have two USRP2s and hence was also working on the usrp2_version code. >> I >> have both the transmitter and receiver code individually working correctly >> with USRP2. However, the receiver is not able to receive the packets >> correctly from the transmitter (i.e in case of USRP2). I always get bad >> CRC >> message. >> >> I have looked up the forum and everybody seem to stuck with the same >> problem. Is there any work around to solve this problem? >> >> From the forum discussion, it seems that one of the issues is the >> preamble. >> >> Any idea how to make synchronize the receiver so that it can receive the >> packets from USRP2 transmitter using bbn code. >> >> > I struggled with this for quite a while. I never understood exactly where > a standard card was not able to decode it. Large frequency offset maybe? I > never got a single packet through. > > Can I suggest something? Try out this 802.11 project: > https://www.cgran.org/wiki/ftw80211ofdmtx > > They definitely claim that a standard NIC can decode the packets, but I > never personally got around to trying it. The code seemed pretty clean, and > I was able to use it to generate proper packet signatures... so the > modulation is definitely correct. > > - George > > ___ > 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] Git commit for 3.2.2 release?
Hi, I'm trying to create a patch that applies cleanly onto a 3.2.2 tarball. I would like to maintain my changes in the form of a Git branch. I can't seem to find a commit that matches up with the 3.2.2 release. The best I've been able to do is about 3000 lines of diff, which still feels quite big. Are the releases made from the git://gnuradio.org/gnuradio.git repo? Thanks, Catalin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: USRP2 and FLEX900
Thanks, does your response mean that I can use usrp2 (with usrp2 driver) in full duplex mode, its just that I have no control over the ports...so if receive or xmit only yes, note the following: * if you receive only, then TX/RX is the receive antenna port. * if you transmit and receive, then RX2 is the receive antenna port. the switching is done automatically by the fpga's ATR registers. tx/rx port is used (and I make no calls to set_antenna or set_rx_antenna) and if doing duplex tx/rx is used for xmit and rx2 is used for receive? Also, does this work for both wbx and rfx900. yes, same for wbx and rfx series. You can do full duplex. Or does it mean I cant do duplex unless I use UHD? The main difference as far as antenna switching is concerned is that the UHD lets you select the RX antenna when doing a receive only. The same rules above apply when transmitting. http://www.ettus.com/uhd_docs/manual/html/dboards.html#rfx-series -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN 80211b Transmitter with GNURadio 3.2.2 and USRP1
On Thu, May 20, 2010 at 3:14 PM, Smith L. wrote: > > Thanks for the help, Doug. > > I do have two USRP2s and hence was also working on the usrp2_version code. > I > have both the transmitter and receiver code individually working correctly > with USRP2. However, the receiver is not able to receive the packets > correctly from the transmitter (i.e in case of USRP2). I always get bad CRC > message. > > I have looked up the forum and everybody seem to stuck with the same > problem. Is there any work around to solve this problem? > > From the forum discussion, it seems that one of the issues is the preamble. > > Any idea how to make synchronize the receiver so that it can receive the > packets from USRP2 transmitter using bbn code. > > I struggled with this for quite a while. I never understood exactly where a standard card was not able to decode it. Large frequency offset maybe? I never got a single packet through. Can I suggest something? Try out this 802.11 project: https://www.cgran.org/wiki/ftw80211ofdmtx They definitely claim that a standard NIC can decode the packets, but I never personally got around to trying it. The code seemed pretty clean, and I was able to use it to generate proper packet signatures... so the modulation is definitely correct. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN 80211b Transmitter with GNURadio 3.2.2 and USRP1
Thanks for the help, Doug. I do have two USRP2s and hence was also working on the usrp2_version code. I have both the transmitter and receiver code individually working correctly with USRP2. However, the receiver is not able to receive the packets correctly from the transmitter (i.e in case of USRP2). I always get bad CRC message. I have looked up the forum and everybody seem to stuck with the same problem. Is there any work around to solve this problem? >From the forum discussion, it seems that one of the issues is the preamble. Any idea how to make synchronize the receiver so that it can receive the packets from USRP2 transmitter using bbn code. Thanks, Smith Douglas Geiger-2 wrote: > > You probably want to take a look at the usrp2_version branch to see > how to get the transmit code working with the hier_block2 API, and > then modify it to work with the USRP1. Two things: you cannot transmit > the 802.11b waveform through the USRP1 (you don't have enough > bandwidth - in the original code base I believe they simply skipped > the DSSS step, and transmitted the pulse-shaped DPSK-modulated > signal), also I believe the usrp2_version branch transmit code fixed > some of the bugs in the original transmit code (i.e. using a USRP2, > the transmit code could send a standard-compliant waveform). > Doug > > On Thu, May 20, 2010 at 12:47 PM, Smith L. wrote: >> >> Hello all, >> >> I am trying to use bbn 80211b transmitter code (douggeiger version from >> cgran website) with GNU Radio 3.2.2 with USRP1. However, it seems like >> the >> Tx code has not been modified completely to work with hier_block2 APIs. I >> tried to make changes on my own and ended up with an error that I do not >> know how to solve? >> I am having a Itemsize mismatch error for message source and >> bbn_80211_bb_mod. >> >> I am using Ubuntu 8.04, Gnuradio 3.2.2, Python 2.6 and USRP1s. I looked >> up >> the mailing list and I found very little information for Tx code as >> everybody seems to be working on the receiver code. >> >> Does any one have a working copy of bbn_80211b_tx.py of douggeiger >> version >> that works with GNURadio 3.2.2 and USRP1. >> >> Any help would be greatly appreciated. >> >> Thanks >> Smith >> -- >> View this message in context: >> http://old.nabble.com/BBN-80211b-Transmitter-with-GNURadio-3.2.2-and-USRP1-tp28623863p28623863.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 >> > > > > -- > Doug Geiger > doug.gei...@bioradiation.net > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/BBN-80211b-Transmitter-with-GNURadio-3.2.2-and-USRP1-tp28623863p28625684.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
[Discuss-gnuradio] Soft-SFN (GPS independent, Fully SDR Single Frequency Network) Works :-)
Hi fellow GNURadioers, I'd really like to share with you a demonstration video about something I consider rather cool. http://www.youtube.com/watch?v=mQ6YorV4VKE An ETSI DVB-T Single Frequency Network (SFN) tested within the lab but ready for geographical deployment, implemented by using none of those ultra high-end, GPS-synced SFN hardware modulators but only two ordinary computers and 2 USRP2s. The lab setup reproduces an SFN collision area between two neighboring transmitters (i.e. the worst case a receiver can fall into when operating within an sfn environment). Time and frequency synchronization are delivered to SFN transmitters without relying upon GPS/GALILEO infrastructure but through ordinary (not dedicated) packet switched networks carrying loads of concurrent traffic. I'm not sure this was done before, please let me know in case there is some info I'm missing. thank you and reagards vincenzo -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: USRP2 and FLEX900
Hi Josh,
Thanks, does your response mean that I can use usrp2 (with usrp2 driver) in
full duplex
mode, its just that I have no control over the ports...so if receive or xmit
only
tx/rx port is used (and I make no calls to set_antenna or set_rx_antenna)
and if
doing duplex tx/rx is used for xmit and rx2 is used for receive? Also, does
this work for both wbx and rfx900.
Or does it mean I cant do duplex unless I use UHD?
Thanks,
Sharif
- Original Message -
From: "Josh Blum"
To:
Sent: Thursday, May 20, 2010 11:55 AM
Subject: Re: [Discuss-gnuradio] Re: USRP2 and FLEX900
The sent antenna feature is not implemented for the RFX boards when using
the gnuradio usrp2 driver. However, this functionality has been
implemented in the UHD:
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki
What you are seeing is that when receiving-only (no transmit), the TX/RX
port is selected for receive.
When transmitting (or simultaneously transmitting and receiving), the
TX/RX port is selected for transmit, and the RX2 port is selected for
receive.
-josh
On 05/20/2010 07:50 AM, Sharif Shaher wrote:
Hi Matt,
The first step to getting duplex to work is to make sure I can switch
between RX/TX and RX2 on the
rfx900. So that is what I am trying to do now.
I have given this a shot and determined that I am not sure if I am
calling this correctly. I have
the new firmware (you pointed us to) and I running with gnuradio
3.3.0-rc0.
From python (usrp2_fft.py), the only function that allows the python
script
to work is
self.u.set_antenna(X), where X is an integer. I am not sure what the
value of X should be if
I am want to use TX/RX or if I a want to use RX2...can you please let me
know?
From C++, I call it as follows:
u2->set_rx_antenna('RX2')
it only takes integers, and those are character quotes.
This compiles, don't know if it works (currently trying to test), if I
want to go back to TX/RX can
you tell me how I would call it from c++, also is calling it with 'RX2'
correct?
Any help would be greatly appreciated.
Thanks,
Sharif
- Original Message - From: "Matt Ettus"
To: "Marcus D Leech"
Cc: "Sharif Shaher"
Sent: Wednesday, April 14, 2010 12:35 PM
Subject: Re: USRP2 and FLEX900
Yes, this is supported now in the latest USRP2 firmware. You can get
it from:
http://gnuradio.org/releases/usrp2-bin/trunk/
Matt
On 02/26/2010 03:23 PM, Marcus D Leech wrote:
I'll let Matt comment on your proposed firmware changes
I think the next usrp2 firmware major rev will support switching my
default
--
Principal Investigator
Shirleys Bay Radio
Astronomy Consortium
http://www.sbrac.org
On Feb 26, 2010, at 5:01 PM, "Sharif Shaher" mailto:ssha...@steelriver.com>> wrote:
Hello,
I have an application that requires me to continuously recieve a
signal, while
continuously transmitting a delayed version of that recieved signal.
As a result
I need full duplex. I have a USRP2 and the rfx900 daughter board. My
plan
is to use the TX/RX port to transmit while using the RX2 port to
recieve. However,
I can not seem to get anything to listen/recieve on port RX2. For
example when
I run usrp2_fft.py and insert
self.subdev.select_rx_antenna('RX2).
this gives the error shown below. By searching discuss-gnuradio II see
where someone
has suggested that I rebuild the firmware by making these changes (for
the rfx_900),
.base.atr_txval=0 --> .base.atr_txval=MIX_EN | ANT_SW
.base.atr_rxval= MIX_EN > base.atr_rxval= MIX_EN | ANT_SW
2 Questions:
--
However, will the above a) work, that is allow me to use the RX2 port
to recieve and b)
will it fix the problem shown below when I insert the call to
self.subdev.select_rx_antenna('RX2).
Any help would be greatly appreciated.
Traceback (most recent call last):
File "./usrp2_fft.py", line 275, in
main ()
File "./usrp2_fft.py", line 271, in main
app = stdgui2.stdapp(app_top_block, "USRP2 FFT", nstatus=1)
File
"/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line 36, in __init__
wx.App.__init__ (self, redirect=False)
File
"/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line 7836, in __init__
self._BootstrapApp()
File
"/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line 7433, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
File
"/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line 39, in OnInit
frame = stdframe (self.top_block_maker, self.title, self._nstatus)
File
"/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line 60, in __init__
self.panel = stdpanel (self, self, top_block_maker)
File
"/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line 81, in __init__
self.top_block = top_block_maker (frame, self, vbox, sys.argv)
File "./usrp2_fft.py", line 112, in __init__
self.subdev.select_rx_antenna('RX2')
File
"/usr/local/lib/python2.5/site-packages/gnuradio/gr/top_block.py",
line 94, in __getattr__
Re: [Discuss-gnuradio] BBN 80211b Transmitter with GNURadio 3.2.2 and USRP1
You probably want to take a look at the usrp2_version branch to see how to get the transmit code working with the hier_block2 API, and then modify it to work with the USRP1. Two things: you cannot transmit the 802.11b waveform through the USRP1 (you don't have enough bandwidth - in the original code base I believe they simply skipped the DSSS step, and transmitted the pulse-shaped DPSK-modulated signal), also I believe the usrp2_version branch transmit code fixed some of the bugs in the original transmit code (i.e. using a USRP2, the transmit code could send a standard-compliant waveform). Doug On Thu, May 20, 2010 at 12:47 PM, Smith L. wrote: > > Hello all, > > I am trying to use bbn 80211b transmitter code (douggeiger version from > cgran website) with GNU Radio 3.2.2 with USRP1. However, it seems like the > Tx code has not been modified completely to work with hier_block2 APIs. I > tried to make changes on my own and ended up with an error that I do not > know how to solve? > I am having a Itemsize mismatch error for message source and > bbn_80211_bb_mod. > > I am using Ubuntu 8.04, Gnuradio 3.2.2, Python 2.6 and USRP1s. I looked up > the mailing list and I found very little information for Tx code as > everybody seems to be working on the receiver code. > > Does any one have a working copy of bbn_80211b_tx.py of douggeiger version > that works with GNURadio 3.2.2 and USRP1. > > Any help would be greatly appreciated. > > Thanks > Smith > -- > View this message in context: > http://old.nabble.com/BBN-80211b-Transmitter-with-GNURadio-3.2.2-and-USRP1-tp28623863p28623863.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 > -- Doug Geiger doug.gei...@bioradiation.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] BBN 80211b Transmitter with GNURadio 3.2.2 and USRP1
Hello all, I am trying to use bbn 80211b transmitter code (douggeiger version from cgran website) with GNU Radio 3.2.2 with USRP1. However, it seems like the Tx code has not been modified completely to work with hier_block2 APIs. I tried to make changes on my own and ended up with an error that I do not know how to solve? I am having a Itemsize mismatch error for message source and bbn_80211_bb_mod. I am using Ubuntu 8.04, Gnuradio 3.2.2, Python 2.6 and USRP1s. I looked up the mailing list and I found very little information for Tx code as everybody seems to be working on the receiver code. Does any one have a working copy of bbn_80211b_tx.py of douggeiger version that works with GNURadio 3.2.2 and USRP1. Any help would be greatly appreciated. Thanks Smith -- View this message in context: http://old.nabble.com/BBN-80211b-Transmitter-with-GNURadio-3.2.2-and-USRP1-tp28623863p28623863.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] Re: USRP2 and FLEX900
The sent antenna feature is not implemented for the RFX boards when
using the gnuradio usrp2 driver. However, this functionality has been
implemented in the UHD:
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki
What you are seeing is that when receiving-only (no transmit), the TX/RX
port is selected for receive.
When transmitting (or simultaneously transmitting and receiving), the
TX/RX port is selected for transmit, and the RX2 port is selected for
receive.
-josh
On 05/20/2010 07:50 AM, Sharif Shaher wrote:
Hi Matt,
The first step to getting duplex to work is to make sure I can switch
between RX/TX and RX2 on the
rfx900. So that is what I am trying to do now.
I have given this a shot and determined that I am not sure if I am
calling this correctly. I have
the new firmware (you pointed us to) and I running with gnuradio 3.3.0-rc0.
From python (usrp2_fft.py), the only function that allows the python
script
to work is
self.u.set_antenna(X), where X is an integer. I am not sure what the
value of X should be if
I am want to use TX/RX or if I a want to use RX2...can you please let me
know?
From C++, I call it as follows:
u2->set_rx_antenna('RX2')
it only takes integers, and those are character quotes.
This compiles, don't know if it works (currently trying to test), if I
want to go back to TX/RX can
you tell me how I would call it from c++, also is calling it with 'RX2'
correct?
Any help would be greatly appreciated.
Thanks,
Sharif
- Original Message - From: "Matt Ettus"
To: "Marcus D Leech"
Cc: "Sharif Shaher"
Sent: Wednesday, April 14, 2010 12:35 PM
Subject: Re: USRP2 and FLEX900
Yes, this is supported now in the latest USRP2 firmware. You can get
it from:
http://gnuradio.org/releases/usrp2-bin/trunk/
Matt
On 02/26/2010 03:23 PM, Marcus D Leech wrote:
I'll let Matt comment on your proposed firmware changes
I think the next usrp2 firmware major rev will support switching my
default
--
Principal Investigator
Shirleys Bay Radio
Astronomy Consortium
http://www.sbrac.org
On Feb 26, 2010, at 5:01 PM, "Sharif Shaher" mailto:ssha...@steelriver.com>> wrote:
Hello,
I have an application that requires me to continuously recieve a
signal, while
continuously transmitting a delayed version of that recieved signal.
As a result
I need full duplex. I have a USRP2 and the rfx900 daughter board. My
plan
is to use the TX/RX port to transmit while using the RX2 port to
recieve. However,
I can not seem to get anything to listen/recieve on port RX2. For
example when
I run usrp2_fft.py and insert
self.subdev.select_rx_antenna('RX2).
this gives the error shown below. By searching discuss-gnuradio II see
where someone
has suggested that I rebuild the firmware by making these changes (for
the rfx_900),
.base.atr_txval=0 --> .base.atr_txval=MIX_EN | ANT_SW
.base.atr_rxval= MIX_EN > base.atr_rxval= MIX_EN | ANT_SW
2 Questions:
--
However, will the above a) work, that is allow me to use the RX2 port
to recieve and b)
will it fix the problem shown below when I insert the call to
self.subdev.select_rx_antenna('RX2).
Any help would be greatly appreciated.
Traceback (most recent call last):
File "./usrp2_fft.py", line 275, in
main ()
File "./usrp2_fft.py", line 271, in main
app = stdgui2.stdapp(app_top_block, "USRP2 FFT", nstatus=1)
File
"/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line 36, in __init__
wx.App.__init__ (self, redirect=False)
File
"/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line 7836, in __init__
self._BootstrapApp()
File
"/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line 7433, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
File
"/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line 39, in OnInit
frame = stdframe (self.top_block_maker, self.title, self._nstatus)
File
"/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line 60, in __init__
self.panel = stdpanel (self, self, top_block_maker)
File
"/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line 81, in __init__
self.top_block = top_block_maker (frame, self, vbox, sys.argv)
File "./usrp2_fft.py", line 112, in __init__
self.subdev.select_rx_antenna('RX2')
File
"/usr/local/lib/python2.5/site-packages/gnuradio/gr/top_block.py",
line 94, in __getattr__
return getattr(self._tb, name)
AttributeError: 'gr_top_block_sptr' object has no attribute 'subdev'
___
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] error report usrp_fft.py
Sorry i've done it but i no wrote it in my post, the error appears after that! some other idea!?!? I can't upgrade ubuntu cause other persons decide to use same machine and to no change distribution...with the normal problem of a test machine with more different utent! I'll try to change release and use a i can try installable binary packages. Thanks Domenico Johnathan Corgan-2 wrote: > > On Thu, May 20, 2010 at 07:45, meco1982 wrote: > >> First error in find_usrps was: >> find_usrps: error while loading shared libraries: >> libusrp2.so.0.cannot >> open shared object file: No such file or directory > > It's likely you need to run; > > $ sudo ldconfig > > ...in order for the system to know where all the newly installed > libraries are located. > > If you are only interested in installing and using GNU Radio and not > to actually hack on GNU Radio itself, and release 3.2 is sufficient, I > recommend you upgrade your Ubuntu workstation to 10.04, which has GNU > Radio 3.2.2 as installable binary packages. > > Johnathan > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/error-report-usrp_fft.py-tp28622262p28623212.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] USRP2 and ISE 12
The problem is not the aeMB, it is how ISE is synthesizing it. We have been working on this problem and are very close to having a solution. Matt On 05/20/2010 08:22 AM, Tiago Rogério Mück wrote: Well, it seems the aeMB guys are working on a new version of the the core. Maybe the new core will perform better. Em 14 de maio de 2010 18:17, Brian Padalino mailto:bpadal...@gmail.com>> escreveu: 2010/5/14 Tiago Rogério Mück mailto:ti...@lisha.ufsc.br>>: > Hello, > > It seems that everyone is having troubles with ISE 11.x, but has anyone > tried the new ISE 12 ? > > We have successfully synthesized the USRP2 fpga code with ISE 12.1, but we > got a timing error and the bitstream didn't seem to work: find_usrps didn't > find anything and the leds didn't flash. > > We are using the latest code from the repositories for both fpga and > firmware. > > Is there anyone who has tried ISE 12 and want to share the experience ? I am not building the USRP2 FPGA, or have experience with ISE 12, but the errors you have are all related to BRAM feeding the aeMB CPU - more specifically RAM output -> Mux -> Adder -> FF, mostly with 7 to 10 layers of logic inbetween. Good luck debugging that portion of the CPU. Hopefully you can achieve timing closure. Brian ___ 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] USRP2 and ISE 12
Well, it seems the aeMB guys are working on a new version of the the core. Maybe the new core will perform better. Em 14 de maio de 2010 18:17, Brian Padalino escreveu: > 2010/5/14 Tiago Rogério Mück : > > Hello, > > > > It seems that everyone is having troubles with ISE 11.x, but has anyone > > tried the new ISE 12 ? > > > > We have successfully synthesized the USRP2 fpga code with ISE 12.1, but > we > > got a timing error and the bitstream didn't seem to work: find_usrps > didn't > > find anything and the leds didn't flash. > > > > We are using the latest code from the repositories for both fpga and > > firmware. > > > > Is there anyone who has tried ISE 12 and want to share the experience ? > > I am not building the USRP2 FPGA, or have experience with ISE 12, but > the errors you have are all related to BRAM feeding the aeMB CPU - > more specifically RAM output -> Mux -> Adder -> FF, mostly with 7 to > 10 layers of logic inbetween. > > Good luck debugging that portion of the CPU. Hopefully you can > achieve timing closure. > > Brian > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] error report usrp_fft.py
On Thu, May 20, 2010 at 07:45, meco1982 wrote: > First error in find_usrps was: > find_usrps: error while loading shared libraries: libusrp2.so.0.cannot > open shared object file: No such file or directory It's likely you need to run; $ sudo ldconfig ...in order for the system to know where all the newly installed libraries are located. If you are only interested in installing and using GNU Radio and not to actually hack on GNU Radio itself, and release 3.2 is sufficient, I recommend you upgrade your Ubuntu workstation to 10.04, which has GNU Radio 3.2.2 as installable binary packages. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: USRP2 and FLEX900
Hi Matt,
The first step to getting duplex to work is to make sure I can switch
between RX/TX and RX2 on the
rfx900. So that is what I am trying to do now.
I have given this a shot and determined that I am not sure if I am calling
this correctly. I have
the new firmware (you pointed us to) and I running with gnuradio 3.3.0-rc0.
From python (usrp2_fft.py), the only function that allows the python script
to work is
self.u.set_antenna(X), where X is an integer. I am not sure what the value
of X should be if
I am want to use TX/RX or if I a want to use RX2...can you please let me
know?
From C++, I call it as follows:
u2->set_rx_antenna('RX2')
This compiles, don't know if it works (currently trying to test), if I want
to go back to TX/RX can
you tell me how I would call it from c++, also is calling it with 'RX2'
correct?
Any help would be greatly appreciated.
Thanks,
Sharif
- Original Message -
From: "Matt Ettus"
To: "Marcus D Leech"
Cc: "Sharif Shaher"
Sent: Wednesday, April 14, 2010 12:35 PM
Subject: Re: USRP2 and FLEX900
Yes, this is supported now in the latest USRP2 firmware. You can get it
from:
http://gnuradio.org/releases/usrp2-bin/trunk/
Matt
On 02/26/2010 03:23 PM, Marcus D Leech wrote:
I'll let Matt comment on your proposed firmware changes
I think the next usrp2 firmware major rev will support switching my
default
--
Principal Investigator
Shirleys Bay Radio
Astronomy Consortium
http://www.sbrac.org
On Feb 26, 2010, at 5:01 PM, "Sharif Shaher" mailto:ssha...@steelriver.com>> wrote:
Hello,
I have an application that requires me to continuously recieve a
signal, while
continuously transmitting a delayed version of that recieved signal.
As a result
I need full duplex. I have a USRP2 and the rfx900 daughter board. My
plan
is to use the TX/RX port to transmit while using the RX2 port to
recieve. However,
I can not seem to get anything to listen/recieve on port RX2. For
example when
I run usrp2_fft.py and insert
self.subdev.select_rx_antenna('RX2).
this gives the error shown below. By searching discuss-gnuradio II see
where someone
has suggested that I rebuild the firmware by making these changes (for
the rfx_900),
.base.atr_txval=0 --> .base.atr_txval=MIX_EN | ANT_SW
.base.atr_rxval= MIX_EN > base.atr_rxval= MIX_EN | ANT_SW
2 Questions:
--
However, will the above a) work, that is allow me to use the RX2 port
to recieve and b)
will it fix the problem shown below when I insert the call to
self.subdev.select_rx_antenna('RX2).
Any help would be greatly appreciated.
Traceback (most recent call last):
File "./usrp2_fft.py", line 275, in
main ()
File "./usrp2_fft.py", line 271, in main
app = stdgui2.stdapp(app_top_block, "USRP2 FFT", nstatus=1)
File
"/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line 36, in __init__
wx.App.__init__ (self, redirect=False)
File
"/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line 7836, in __init__
self._BootstrapApp()
File
"/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line 7433, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
File
"/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line 39, in OnInit
frame = stdframe (self.top_block_maker, self.title, self._nstatus)
File
"/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line 60, in __init__
self.panel = stdpanel (self, self, top_block_maker)
File
"/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py",
line 81, in __init__
self.top_block = top_block_maker (frame, self, vbox, sys.argv)
File "./usrp2_fft.py", line 112, in __init__
self.subdev.select_rx_antenna('RX2')
File
"/usr/local/lib/python2.5/site-packages/gnuradio/gr/top_block.py",
line 94, in __getattr__
return getattr(self._tb, name)
AttributeError: 'gr_top_block_sptr' object has no attribute 'subdev'
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] error report usrp_fft.py
Ubuntu 8.10 Intrepid Gnuradio git tarball 3.3.0 rc0 no problem in configure,make make install but... First error in find_usrps was: find_usrps: error while loading shared libraries: libusrp2.so.0.cannot open shared object file: No such file or directory I've searched on web and in the forum and I tried to add python -c "import gnuradio" and no error BOOST_PREFIX=/opt/boost_1_37_0 export LD_LIBRARY_PATH=$BOOST_PREFIX/lib export PYTHONPATH=/usr/local/lib/python2.5/site-packages Now error is r...@irlanda:/# find_usrps find_usrps: error while loading shared libraries: libboost_thread-gcc43-mt-1_37.so.1.37.0: cannot open shared object file: No such file or directory i searched in web but no helps found...someone have an idea? Thanks... Domenico -- View this message in context: http://old.nabble.com/error-report-usrp_fft.py-tp28622262p28622262.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] Re:usrp1 benchmark_ofdm.py
I've met the same problem. At the tail of each burst, the ofdm waveform always becomes a constant line. So the last several ofdm symbols are always error received. I guess it is caused by the RF part, but I'm not sure. My solution is to add some padding bits in the tail of each burst. -Lin 在 2010年5月20日 下午12:10，weizhongshan 写道： > I'm a newer to USRP ,I'm testing the benchmark_ofdm.py module,and find the > last packet is not been received.I wonder why >best wishes > wei > > > > 网易为中小企业免费提供企业邮箱（自主域名） > ___ > 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] Rx and Tx on same antenna
Hello,
I'm starting to play around with gnuradio and the USRP1. I have the
RFX400 daughterboard but only one antenna. I used the examples
usrp_wfm_rcv.py and usrp_nbfm_rcv.py for testing and it worked (I only
had to change the center frequencies for the use with the FRX400). For
emitting I used gnuradio-companion and the WBFM transmit block that also
worked fine. Now, I'm trying to set up a transceiver that uses for both
the receive and emit path the TX/RX antenna of the RFX400. I made a
first (simple) flowgraph using different classes for the Rx and Tx paths
(classes copied from working grc flowgraphs). I used the same parameters
than for the receiver and emitter alone but I set the transmit parameter
of the USRP sink to Auto T/R. Now, my plan is to remain in the reception
mode all the time and to switch to transmission mode only if I want to
speak. In order to do this, I added this code to my python script:
if __name__ == '__main__':
parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
(options, args) = parser.parse_args()
tr = usrp_wbfm_receive_nogui()
tt = usrp_wbfm_emit_rfx400()
while 1:
tr.start()
raw_input('Press Enter to emit: ')
tr.stop()
tt.start()
raw_input('Press Enter to stop emitting ')
tt.stop()
And both the reception and transmission seem to work in first place. But
if I press Enter the second time, I get this error message:
RuntimeError: top_block::start: top block already running or wait() not
called after previous stop()
Assuming that it's impossible to restart a block after stopping it
without executing the wait() call, I added tr.wait() and tt.wait() after
the respective stop calls. But then I get another error message:
audio_alsa_sink[plughw:0,0]: snd_pcm_hw_params failed: File descriptor
in bad state
RuntimeError: check topology failed on audio_alsa_sink(1) using
ninputs=1, noutputs=0
It seems to be linked to the fact that the alsa driver won't switch back
to it's receive config after the transmission. Is there a possibility to
make my script work or am I doing it all the wrong way?
Thanks for your help
Mirko
PS: I've joined the complete code to show the context of my script
#!/usr/bin/env python
##
# Gnuradio Python Flow Graph
# Title: USRP WBFM Receive no gui
# Author: Example
# Description: WBFM Receive with RFX400
# Generated: Thu May 20 11:44:32 2010
##
from gnuradio import audio
from gnuradio import blks2
from gnuradio import gr
from gnuradio.eng_option import eng_option
from grc_gnuradio import usrp as grc_usrp
from optparse import OptionParser
class usrp_wbfm_receive_nogui(gr.top_block):
def __init__(self):
gr.top_block.__init__(self, "USRP WBFM Receive no gui")
##
# Blocks
##
self.audio_out = audio.sink(32000, "plughw:0,0", True)
self.u_source = grc_usrp.simple_source_c(which=0, side="A", rx_ant="TX/RX")
self.u_source.set_decim_rate(200)
self.u_source.set_frequency(43350, verbose=True)
self.u_source.set_gain(20)
self.wfm_demod = blks2.wfm_rcv(
quad_rate=32,
audio_decimation=10,
)
##
# Connections
##
self.connect((self.u_source, 0), (self.wfm_demod, 0))
self.connect((self.wfm_demod, 0), (self.audio_out, 0))
class usrp_wbfm_emit_rfx400(gr.top_block):
def __init__(self):
gr.top_block.__init__(self, "USRP WBFM transmit")
##
# Blocks
##
self.audio_out = audio.source(32000, "plughw:0,0", True)
self.multiply = gr.multiply_const_vcc((9000, ))
self.u_sink = grc_usrp.simple_sink_c(which=0, side="A")
self.u_sink.set_interp_rate(400)
self.u_sink.set_frequency(43350, verbose=True)
self.u_sink.set_gain(0)
self.u_sink.set_enable(True)
self.wbfm_mod = blks2.wfm_tx(
audio_rate=32000,
quad_rate=32,
tau=50e-6,
max_dev=75e3,
)
##
# Connections
##
self.connect((self.multiply, 0), (self.u_sink, 0))
self.connect((self.wbfm_mod, 0), (self.multiply, 0))
self.connect((self.audio_out, 0), (self.wbfm_mod, 0))
if __name__ == '__main__':
parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
(options, args) = parser.parse_args()
tr = usrp_wbfm_receive_nogui()
tt = usrp_wbfm_emit_rfx400()
while 1:
#tr.start()
#raw_input('Press Enter to emit: ')
#tr.stop()
#tr.wait()
tt.start()
raw_input('Press Enter to stop emitting ')
tt.stop()
tt.wait()
tr.start()
raw_input('Press Enter to emit: ')
tr.stop()
