[Discuss-gnuradio] Increasing the number of DSP motherboards in one USRP in GRC
Hi, In gnu-radio-companion, in one UHD-USRP2 device, I can have a maximum of four motherboards. How can I increase them to eight in one usrp device? Thanks, Khalid. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problems with benchmark_ofdm and N210
On Tue, Jun 7, 2011 at 5:31 PM, Morgan Redfield wrote: > On Tue, Jun 7, 2011 at 1:50 PM, Tom Rondeau > wrote: > > On Tue, Jun 7, 2011 at 3:24 PM, Morgan Redfield > wrote: > >> > >> On Tue, Jun 7, 2011 at 7:38 AM, Tom Rondeau > >> wrote: > >> > On Mon, Jun 6, 2011 at 8:33 PM, Morgan Redfield > >> > wrote: > >> >> > >> >> Hi Everyone, > >> >> > >> >> I've been playing around with GNURadio and a couple of USRPs lately, > >> >> but I've run into some problems. I'm using a modified version of the > >> >> benchmark_ofdm_tx.py and benchmark_ofdm_rx.py scripts. I updated them > >> >> to use uhd, and I'm using them with two N210s. Each N210 has a WBX > >> >> daughterboard, and they're placed about a meter apart right now. > >> >> > >> >> I'm attempting to send data from one USRP to the other, but using > >> >> tunnel.py or the benchmark_ofdm files doesn't seem to work. I never > >> >> receive any packets correctly. > >> >> > >> >> With the benchmark_ofdm files, if I start receiving before I start > >> >> transmitting then I just get TIMEOUTs. If I start transmitting before > >> >> I start receiving, I get the following: > >> >> > >> >> $ python benchmark_ofdm_rx.py -f 650M -v --rate=1M > >> >> Mac OS; GNU C++ version 4.0.1 (Apple Inc. build 5490); Boost_104601; > >> >> UHD_003.001.000-4eb4025 > >> >> > >> >> -- Opening a USRP2/N-Series device... > >> >> -- Current recv frame size: 1472 bytes > >> >> -- Current send frame size: 1472 bytes > >> >> -- mboard0 is MIMO master > >> >> >>> gr_fir_ccf: using SSE > >> >> >>> gr_fir_fff: using SSE > >> >> > >> >> OFDM Demodulator: > >> >> Modulation Type: bpsk > >> >> FFT length: 512 > >> >> Occupied Tones: 200 > >> >> CP length: 128 > >> >> ok: Falsepktno: 21611n_rcvd: 1 n_right: 0 > >> >> ok: Falsepktno: 43626n_rcvd: 2 n_right: 0 > >> >> ok: Falsepktno: 21611n_rcvd: 3 n_right: 0 > >> >> ok: Falsepktno: 37548n_rcvd: 4 n_right: 0 > >> >> ok: Falsepktno: 21909n_rcvd: 5 n_right: 0 > >> >> ok: Falsepktno: 4473 n_rcvd: 6 n_right: 0 > >> >> ok: Falsepktno: 27253n_rcvd: 7 n_right: 0 > >> >> ok: Falsepktno: 38378n_rcvd: 8 n_right: 0 > >> >> ok: Falsepktno: 21909n_rcvd: 9 n_right: 0 > >> >> ok: Falsepktno: 38486n_rcvd: 10 n_right: 0 > >> >> ok: Falsepktno: 54634n_rcvd: 11 n_right: 0 > >> >> ok: Falsepktno: 21909n_rcvd: 12 n_right: 0 > >> >> ok: Falsepktno: 39158n_rcvd: 13 n_right: 0 > >> >> ok: Falsepktno: 27237n_rcvd: 14 n_right: 0 > >> >> ok: Falsepktno: 42410n_rcvd: 15 n_right: 0 > >> >> ok: Falsepktno: 21909n_rcvd: 16 n_right: 0 > >> >> ok: Falsepktno: 21994n_rcvd: 17 n_right: 0 > >> >> ok: Falsepktno: 21652n_rcvd: 18 n_right: 0 > >> >> ok: Falsepktno: 21097n_rcvd: 19 n_right: 0 > >> >> ok: Falsepktno: 43626n_rcvd: 20 n_right: 0 > >> >> ok: Falsepktno: 21909n_rcvd: 21 n_right: 0 > >> >> TIMEOUT > >> >> TIMEOUT > >> >> > >> >> I think those timeouts at the end there are from when the transmitter > >> >> stopped transmitting data. It looks like I'm receiving a few packets > >> >> (far fewer than I should), and all the packets I do receive are not > >> >> correct. > >> >> > >> >> Does anyone have any idea what's causing this? > >> >> > >> >> Thanks > >> >> Morgan > >> > > >> > TIMEOUTs occur when a preamble has been detected, but then the signal > is > >> > lost. > >> > My thinking is that you are too far off frequency and so the received > >> > signal > >> > is outside the bandwidth of the receiver. Look at the signal in a FFT > >> > plot > >> > and see if you can adjust the transmitter's frequency to close the > gap. > >> > Tom > >> > > >> > >> I tried measuring the frequency offset of the USRPs by generating a > >> 100KHz sine wave and mixing it up to my rf frequency (650MHz). When I > >> used uhd_fft.py to look at the signal at the receiving N210, I see the > >> peak pretty close to where it should be at 650.1MHz. I doubt the > >> signal is off by more than 3KHz. Could such a small frequency offset > >> really be causing me so many problems? > >> > >> I also tried looking at my OFDM signal in uhd_fft.py, but it was > >> pretty messy and bounced around a lot as packets were transmitted. I'm > >> not sure how I would go about adjusting the transmitter's frequency > >> from just looking at that. Could you please give me a few more > >> details? > >> > >> Morgan > > > > You can use the averaging in the uhd_fft plot to help smooth out the > signal > > to see if it's centered. The OFDM transmitter we have notches out the > center > > two subcarriers, so you will hopefully be able to see a small gap in the > > middle of the signal. > > You might have the transmitter power set too high. OFDM really needs to >
[Discuss-gnuradio] Mainlining FPGA modifications
Hi all, On Sat, May 28, 2011 at 21:30, Alexander Chemeris wrote: > On Sat, May 28, 2011 at 21:04, Marcus D. Leech wrote: >>> Hi all, >>> >>> I'm not sure whether to post this to GnuRadio or to USRP-users, so I >>> post it here. >>> >>> We've started a project to implement a custom SDR hardware (which we >>> plan to open-source later) and we want to reuse as much of USRP FPGA >>> code as possible. But it will require a good deal of customization as >>> well. >>> >>> So, we're looking for an advice on how to structure our relations with >>> the upstream (i.e. GnuRadio/USRP) the best way. I.e. where should we >>> place our code and how to ensure our code will be accepted to the >>> mainline, etc? >>> >> I can't answer the questions about where to best place the code in the tree, >> but maintaining compatibility with the >> UHD wire protocol and API would really help make it easy to integrate into >> Gnu Radio. Matt can comment on >> UHD licensing for projects like this, I'm sure. > > To make it more clear - we intend to keep all VRT/UHD related FPGA > code in place and just replace/change interaction with RF part. May be > we'll have to slightly extend VRT/UHD code for our specific purposes, > but it will be minor changes. > > In other words - all our changes will be to support a new platform > seamlessly with existing UHD code. Could anyone comment on this topic after all? Tom, Josh, Philip - I'm not sure who should I bug about this? PS I've changed subject to a more meaningful. Sorry for messed subject line in the original e-mail. -- Regards, Alexander Chemeris. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ranging (measure distance) between two radios
I think it is going to be a challenging project. Note that I only happen to know a bit about ranging, but I have no experience at all implementing this on GNU Radio/USRP, so I may be off-base at some points. Your basic idea (correlating against a PN sequence) could work well as a first step (detecting time of arrival, but it is only one component of what would be needed. Time of arrival alone will not give you the distance without the precise time of transmission. Your options are Time of Arrival (ToA)/Time Difference of Arrival (TDoA), Angle of Arrival (AoA), Received Signal Strength (RSS)-based distance estimation, or Two-Way ToA/Ranging (TW-ToA). It seems to me that you essentially have to use TW-ToA, basically measuring the "time of flight" of the signal to and from both radios like a ping. You cannot use ToA or TDoA because they assume the time of transmission is precisely known, and you would not have sufficiently synchronized clocks. (Unless you use the same clock reference for both USRPs, in which case its not really practical for ranging since both USRPs are basically stuck next to each other.) For AoA you would need directional antennas, and it does not give range anyway. For RSS-based distance estimation, you would need a lot of training data to correlate RSS readings with distances. So suppose you need to measure the time difference in both directions, i.e. radio A transmits at T1, radio B detects and responds, radio A detects the response at T2, and range ~= c*(T2 - T1)/2. This is where I think you will have complications... the processing delay introduced by GNU Radio while detecting and responding will lead to severe inaccuracies, because at the speed of light even a fraction of a microsecond results in an error of dozens of meters. Using in-band signaling and transmit and receive timestamps could alleviate this problem... However, each USRP should know what the processing delay is between receiving a ping and responding to it. Maybe it can be kept constant, so that one USRP does not need to inform the other one how much processing time was spent? Just a thought. As for references, I think it may be worthwhile to look at IEEE 802.15.4a. It defines a precision wireless ranging protocol using TW-ToA, to an error of about ~1m. It may be helpful to look at that. Googling for "IEEE 802.15.4a ranging" turned up a few interesting papers. The MERL report looked pretty good. Kunal On Tue, Jun 7, 2011 at 10:28 AM, Mario Ruz wrote: > Hello, > > This is my first post in the community. I have been thinking about doing > this question, but after having reviewed some of the theory with digital > signal processing, usrp architecture and some approaches for > positioning/raning, I think I need to ask to the expert community, mainly to > find a line of work and to know the restrictions for the application we want > to carry out. > > I would like to measure the distance between two radios at short distances > (we have two UN-210 and two XCVR2450 or 1 WBX and 1 DBSRX2, let's say to 1 > m, 2mup to for example 20 meters), starting from off-line experiments > and finishing with real time measures in line of sight. My questions are: > > - What would be, from your experience, the best approach to do this > (transmitted signal and digital processing in the receiver part), what > accuracy should I expect in line of sight? > > I am looking mainly for a starting point, the signal structure to transmit > and the receiver structure. For example, one of the thoughts I have is a > correlation in the receiver of a pseudorandom (spread spectrum) transmited > signal, this approach could serve to measure time of arrival by measuring > the delay of the pseudo-noise code signal, when comparing it with an exact > copy at the receiver. Another approach I have seen is the estimation of the > Channel impulse response (CIR), that maybe (as far as i know) could serve > also for estimating distances. I have seen that there is some code to do a > correlation inside the FPGA of the USRP1. > > So far my references are (which maybe can be helpul for those who are > working in the same field): > > - "Advancing Wireless Link Signatures for Location Distinction". Here, they > do not carry out ranging/positioning, but a change in the transmitter > position is detected. In my case (in the case ranging is not possible), to > detect if a distance is crossed would be my objective (e.g. the transmitter > go closer than 1 meter to the receiver). > > - "RF Ranging for Location Awareness". In this dissertation they use an > arquitecture similar to the USRP hardware. > > As you can see what I am looking for is for some sort of radar/ranging > application and some starting point. Also, my questions are very generic for > now and I apologize for it, mainly because I am still looking how to focus > the problem. > > Then, any help (references, similar work done) will be very useful. > > Kind regards, > > Mario > > _
Re: [Discuss-gnuradio] problems with benchmark_ofdm and N210
On Tue, Jun 7, 2011 at 3:24 PM, Morgan Redfield wrote: > On Tue, Jun 7, 2011 at 7:38 AM, Tom Rondeau > wrote: > > On Mon, Jun 6, 2011 at 8:33 PM, Morgan Redfield > wrote: > >> > >> Hi Everyone, > >> > >> I've been playing around with GNURadio and a couple of USRPs lately, > >> but I've run into some problems. I'm using a modified version of the > >> benchmark_ofdm_tx.py and benchmark_ofdm_rx.py scripts. I updated them > >> to use uhd, and I'm using them with two N210s. Each N210 has a WBX > >> daughterboard, and they're placed about a meter apart right now. > >> > >> I'm attempting to send data from one USRP to the other, but using > >> tunnel.py or the benchmark_ofdm files doesn't seem to work. I never > >> receive any packets correctly. > >> > >> With the benchmark_ofdm files, if I start receiving before I start > >> transmitting then I just get TIMEOUTs. If I start transmitting before > >> I start receiving, I get the following: > >> > >> $ python benchmark_ofdm_rx.py -f 650M -v --rate=1M > >> Mac OS; GNU C++ version 4.0.1 (Apple Inc. build 5490); Boost_104601; > >> UHD_003.001.000-4eb4025 > >> > >> -- Opening a USRP2/N-Series device... > >> -- Current recv frame size: 1472 bytes > >> -- Current send frame size: 1472 bytes > >> -- mboard0 is MIMO master > >> >>> gr_fir_ccf: using SSE > >> >>> gr_fir_fff: using SSE > >> > >> OFDM Demodulator: > >> Modulation Type: bpsk > >> FFT length: 512 > >> Occupied Tones: 200 > >> CP length: 128 > >> ok: Falsepktno: 21611n_rcvd: 1 n_right: 0 > >> ok: Falsepktno: 43626n_rcvd: 2 n_right: 0 > >> ok: Falsepktno: 21611n_rcvd: 3 n_right: 0 > >> ok: Falsepktno: 37548n_rcvd: 4 n_right: 0 > >> ok: Falsepktno: 21909n_rcvd: 5 n_right: 0 > >> ok: Falsepktno: 4473 n_rcvd: 6 n_right: 0 > >> ok: Falsepktno: 27253n_rcvd: 7 n_right: 0 > >> ok: Falsepktno: 38378n_rcvd: 8 n_right: 0 > >> ok: Falsepktno: 21909n_rcvd: 9 n_right: 0 > >> ok: Falsepktno: 38486n_rcvd: 10 n_right: 0 > >> ok: Falsepktno: 54634n_rcvd: 11 n_right: 0 > >> ok: Falsepktno: 21909n_rcvd: 12 n_right: 0 > >> ok: Falsepktno: 39158n_rcvd: 13 n_right: 0 > >> ok: Falsepktno: 27237n_rcvd: 14 n_right: 0 > >> ok: Falsepktno: 42410n_rcvd: 15 n_right: 0 > >> ok: Falsepktno: 21909n_rcvd: 16 n_right: 0 > >> ok: Falsepktno: 21994n_rcvd: 17 n_right: 0 > >> ok: Falsepktno: 21652n_rcvd: 18 n_right: 0 > >> ok: Falsepktno: 21097n_rcvd: 19 n_right: 0 > >> ok: Falsepktno: 43626n_rcvd: 20 n_right: 0 > >> ok: Falsepktno: 21909n_rcvd: 21 n_right: 0 > >> TIMEOUT > >> TIMEOUT > >> > >> I think those timeouts at the end there are from when the transmitter > >> stopped transmitting data. It looks like I'm receiving a few packets > >> (far fewer than I should), and all the packets I do receive are not > >> correct. > >> > >> Does anyone have any idea what's causing this? > >> > >> Thanks > >> Morgan > > > > TIMEOUTs occur when a preamble has been detected, but then the signal is > > lost. > > My thinking is that you are too far off frequency and so the received > signal > > is outside the bandwidth of the receiver. Look at the signal in a FFT > plot > > and see if you can adjust the transmitter's frequency to close the gap. > > Tom > > > > I tried measuring the frequency offset of the USRPs by generating a > 100KHz sine wave and mixing it up to my rf frequency (650MHz). When I > used uhd_fft.py to look at the signal at the receiving N210, I see the > peak pretty close to where it should be at 650.1MHz. I doubt the > signal is off by more than 3KHz. Could such a small frequency offset > really be causing me so many problems? > > I also tried looking at my OFDM signal in uhd_fft.py, but it was > pretty messy and bounced around a lot as packets were transmitted. I'm > not sure how I would go about adjusting the transmitter's frequency > from just looking at that. Could you please give me a few more > details? > > Morgan > You can use the averaging in the uhd_fft plot to help smooth out the signal to see if it's centered. The OFDM transmitter we have notches out the center two subcarriers, so you will hopefully be able to see a small gap in the middle of the signal. You might have the transmitter power set too high. OFDM really needs to operate in the linear range of the transmitter, so keeping the power down helps. I thought of this when you said "messy," which could be influenced by this factor. In general, though, no, 3 kHz offset should not be a problem for this. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problems with benchmark_ofdm and N210
On Tue, Jun 7, 2011 at 7:38 AM, Tom Rondeau wrote: > On Mon, Jun 6, 2011 at 8:33 PM, Morgan Redfield wrote: >> >> Hi Everyone, >> >> I've been playing around with GNURadio and a couple of USRPs lately, >> but I've run into some problems. I'm using a modified version of the >> benchmark_ofdm_tx.py and benchmark_ofdm_rx.py scripts. I updated them >> to use uhd, and I'm using them with two N210s. Each N210 has a WBX >> daughterboard, and they're placed about a meter apart right now. >> >> I'm attempting to send data from one USRP to the other, but using >> tunnel.py or the benchmark_ofdm files doesn't seem to work. I never >> receive any packets correctly. >> >> With the benchmark_ofdm files, if I start receiving before I start >> transmitting then I just get TIMEOUTs. If I start transmitting before >> I start receiving, I get the following: >> >> $ python benchmark_ofdm_rx.py -f 650M -v --rate=1M >> Mac OS; GNU C++ version 4.0.1 (Apple Inc. build 5490); Boost_104601; >> UHD_003.001.000-4eb4025 >> >> -- Opening a USRP2/N-Series device... >> -- Current recv frame size: 1472 bytes >> -- Current send frame size: 1472 bytes >> -- mboard0 is MIMO master >> >>> gr_fir_ccf: using SSE >> >>> gr_fir_fff: using SSE >> >> OFDM Demodulator: >> Modulation Type: bpsk >> FFT length: 512 >> Occupied Tones: 200 >> CP length: 128 >> ok: False pktno: 21611 n_rcvd: 1 n_right: 0 >> ok: False pktno: 43626 n_rcvd: 2 n_right: 0 >> ok: False pktno: 21611 n_rcvd: 3 n_right: 0 >> ok: False pktno: 37548 n_rcvd: 4 n_right: 0 >> ok: False pktno: 21909 n_rcvd: 5 n_right: 0 >> ok: False pktno: 4473 n_rcvd: 6 n_right: 0 >> ok: False pktno: 27253 n_rcvd: 7 n_right: 0 >> ok: False pktno: 38378 n_rcvd: 8 n_right: 0 >> ok: False pktno: 21909 n_rcvd: 9 n_right: 0 >> ok: False pktno: 38486 n_rcvd: 10 n_right: 0 >> ok: False pktno: 54634 n_rcvd: 11 n_right: 0 >> ok: False pktno: 21909 n_rcvd: 12 n_right: 0 >> ok: False pktno: 39158 n_rcvd: 13 n_right: 0 >> ok: False pktno: 27237 n_rcvd: 14 n_right: 0 >> ok: False pktno: 42410 n_rcvd: 15 n_right: 0 >> ok: False pktno: 21909 n_rcvd: 16 n_right: 0 >> ok: False pktno: 21994 n_rcvd: 17 n_right: 0 >> ok: False pktno: 21652 n_rcvd: 18 n_right: 0 >> ok: False pktno: 21097 n_rcvd: 19 n_right: 0 >> ok: False pktno: 43626 n_rcvd: 20 n_right: 0 >> ok: False pktno: 21909 n_rcvd: 21 n_right: 0 >> TIMEOUT >> TIMEOUT >> >> I think those timeouts at the end there are from when the transmitter >> stopped transmitting data. It looks like I'm receiving a few packets >> (far fewer than I should), and all the packets I do receive are not >> correct. >> >> Does anyone have any idea what's causing this? >> >> Thanks >> Morgan > > TIMEOUTs occur when a preamble has been detected, but then the signal is > lost. > My thinking is that you are too far off frequency and so the received signal > is outside the bandwidth of the receiver. Look at the signal in a FFT plot > and see if you can adjust the transmitter's frequency to close the gap. > Tom > I tried measuring the frequency offset of the USRPs by generating a 100KHz sine wave and mixing it up to my rf frequency (650MHz). When I used uhd_fft.py to look at the signal at the receiving N210, I see the peak pretty close to where it should be at 650.1MHz. I doubt the signal is off by more than 3KHz. Could such a small frequency offset really be causing me so many problems? I also tried looking at my OFDM signal in uhd_fft.py, but it was pretty messy and bounced around a lot as packets were transmitted. I'm not sure how I would go about adjusting the transmitter's frequency from just looking at that. Could you please give me a few more details? Morgan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSM not detecting station, USRP1, FA-SY1, WBX, DBS
On Tue, Jun 7, 2011 at 3:28 AM, Paul Lambert wrote: > Hello list, > > I'm having a lot of trouble here while trying to make openBTS work with my > USRP1 > to play with GSMs. This question belongs on the OpenBTS list. > First of all, a little description of my setup: > Software: > openbts-2.6.0Mamou > gnuradio v3.4.0git-130-g207a2ae7 > UHD from git > OS: ubuntu 11.04 > > # sudo lsusrp > USRP 0 serial number 4c76a203 > RX d'board A: WBX NG RX > RX d'board B: DBS Rx > TX d'board A: WBX NG TX > TX d'board B: The combination of version 2.6.0-Mamou and WBX isn't supported. Official releases and the mainline tree only support operation with dual RFX900/1800 d'boards. Understandably, this can be easily missed when browsing the wiki page. The FAQ, however, makes this clear and provides a solution for the WBX. http://gnuradio.org/redmine/wiki/gnuradio/OpenBTSFAQ > /usr/local/share/gnuradio/examples/usrp/usrp_benchmark_usb.py > Max USB/USRP throughput = 32MB/sec > > I'm using a FA-SY clock to get 52Mhz and I followed the guide in [1] > I didn't modify any of the code, since I'm using gnuradio 3.4. (But I > adapted my OpenBTS.config) > When I start openBTS I get the following output: > http://pastebin.com/raw.php?i=nKbG4j3z (I pasted the whole output) These messages are normal. Read the TRX log and you might find a RXTUNE error, which will be the only sign that something is wrong. > Here is the openBTS config I use: > http://pastebin.com/raw.php?i=aUQfYWGu > (This is the last I used, but I tried several other configs) Nothing wrong here. > I would be glad if somebody had an idea where I could look next. http://gnuradio.org/redmine/wiki/1/OpenBTSUHD http://lists.sourceforge.net/lists/listinfo/openbts-discuss Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] using custom signal processing module
I used the tutorial on http://gnuradio.org/redmine/wiki/gnuradio/Basic_block gr-my-blocks-template as a template folder. Mehmet. 2011/6/7, Tom Rondeau : > On Tue, Jun 7, 2011 at 5:19 AM, mehmet kabasakal > <85kabasa...@gmail.com>wrote: > >> Hi, >> >> I had the same problem and i find a temporary solution for it. >> When you sudo make install a folder with the same name of your module >> should appear on the path usr/local/include/"your module name". But >> instead the folders name becomes MyModule. If you change its name >> using nautilus it works. And also you should go to >> /usr/local/lib/python2.6/MyModule and cut all the _init_ files and >> paste them into the folder "your module name". After these >> modifications my block run succesfully. Hope this helps. >> >> Mehmet. >> > > > That doesn't sound right. Did you use the > create-gnuradio-out-of-tree-project utility? Or did you copy the > gr-howto-write-a-block directory? Neither of these will produce what you > experienced here. If you did it by hand, it sounds like a copy-and-paste > error. > > Tom > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problems with benchmark_ofdm and N210
On Mon, Jun 6, 2011 at 8:33 PM, Morgan Redfield wrote: > Hi Everyone, > > I've been playing around with GNURadio and a couple of USRPs lately, > but I've run into some problems. I'm using a modified version of the > benchmark_ofdm_tx.py and benchmark_ofdm_rx.py scripts. I updated them > to use uhd, and I'm using them with two N210s. Each N210 has a WBX > daughterboard, and they're placed about a meter apart right now. > > I'm attempting to send data from one USRP to the other, but using > tunnel.py or the benchmark_ofdm files doesn't seem to work. I never > receive any packets correctly. > > With the benchmark_ofdm files, if I start receiving before I start > transmitting then I just get TIMEOUTs. If I start transmitting before > I start receiving, I get the following: > > $ python benchmark_ofdm_rx.py -f 650M -v --rate=1M > Mac OS; GNU C++ version 4.0.1 (Apple Inc. build 5490); Boost_104601; > UHD_003.001.000-4eb4025 > > -- Opening a USRP2/N-Series device... > -- Current recv frame size: 1472 bytes > -- Current send frame size: 1472 bytes > -- mboard0 is MIMO master > >>> gr_fir_ccf: using SSE > >>> gr_fir_fff: using SSE > > OFDM Demodulator: > Modulation Type: bpsk > FFT length: 512 > Occupied Tones: 200 > CP length: 128 > ok: Falsepktno: 21611n_rcvd: 1 n_right: 0 > ok: Falsepktno: 43626n_rcvd: 2 n_right: 0 > ok: Falsepktno: 21611n_rcvd: 3 n_right: 0 > ok: Falsepktno: 37548n_rcvd: 4 n_right: 0 > ok: Falsepktno: 21909n_rcvd: 5 n_right: 0 > ok: Falsepktno: 4473 n_rcvd: 6 n_right: 0 > ok: Falsepktno: 27253n_rcvd: 7 n_right: 0 > ok: Falsepktno: 38378n_rcvd: 8 n_right: 0 > ok: Falsepktno: 21909n_rcvd: 9 n_right: 0 > ok: Falsepktno: 38486n_rcvd: 10 n_right: 0 > ok: Falsepktno: 54634n_rcvd: 11 n_right: 0 > ok: Falsepktno: 21909n_rcvd: 12 n_right: 0 > ok: Falsepktno: 39158n_rcvd: 13 n_right: 0 > ok: Falsepktno: 27237n_rcvd: 14 n_right: 0 > ok: Falsepktno: 42410n_rcvd: 15 n_right: 0 > ok: Falsepktno: 21909n_rcvd: 16 n_right: 0 > ok: Falsepktno: 21994n_rcvd: 17 n_right: 0 > ok: Falsepktno: 21652n_rcvd: 18 n_right: 0 > ok: Falsepktno: 21097n_rcvd: 19 n_right: 0 > ok: Falsepktno: 43626n_rcvd: 20 n_right: 0 > ok: Falsepktno: 21909n_rcvd: 21 n_right: 0 > TIMEOUT > TIMEOUT > > I think those timeouts at the end there are from when the transmitter > stopped transmitting data. It looks like I'm receiving a few packets > (far fewer than I should), and all the packets I do receive are not > correct. > > Does anyone have any idea what's causing this? > > Thanks > Morgan > TIMEOUTs occur when a preamble has been detected, but then the signal is lost. My thinking is that you are too far off frequency and so the received signal is outside the bandwidth of the receiver. Look at the signal in a FFT plot and see if you can adjust the transmitter's frequency to close the gap. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] using custom signal processing module
On Tue, Jun 7, 2011 at 5:19 AM, mehmet kabasakal <85kabasa...@gmail.com>wrote: > Hi, > > I had the same problem and i find a temporary solution for it. > When you sudo make install a folder with the same name of your module > should appear on the path usr/local/include/"your module name". But > instead the folders name becomes MyModule. If you change its name > using nautilus it works. And also you should go to > /usr/local/lib/python2.6/MyModule and cut all the _init_ files and > paste them into the folder "your module name". After these > modifications my block run succesfully. Hope this helps. > > Mehmet. > That doesn't sound right. Did you use the create-gnuradio-out-of-tree-project utility? Or did you copy the gr-howto-write-a-block directory? Neither of these will produce what you experienced here. If you did it by hand, it sounds like a copy-and-paste error. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] using custom signal processing module
I used the tutorial on http://gnuradio.org/redmine/wiki/gnuradio/Basic_block and gr-my-blocks-template as a template folder. 2011/6/7, mehmet kabasakal <85kabasa...@gmail.com>: > I used the tutorial on > http://gnuradio.org/redmine/wiki/gnuradio/Basic_block > gr-my-blocks-template as a template folder. > > Mehmet. > > 2011/6/7, Tom Rondeau : >> On Tue, Jun 7, 2011 at 5:19 AM, mehmet kabasakal >> <85kabasa...@gmail.com>wrote: >> >>> Hi, >>> >>> I had the same problem and i find a temporary solution for it. >>> When you sudo make install a folder with the same name of your module >>> should appear on the path usr/local/include/"your module name". But >>> instead the folders name becomes MyModule. If you change its name >>> using nautilus it works. And also you should go to >>> /usr/local/lib/python2.6/MyModule and cut all the _init_ files and >>> paste them into the folder "your module name". After these >>> modifications my block run succesfully. Hope this helps. >>> >>> Mehmet. >>> >> >> >> That doesn't sound right. Did you use the >> create-gnuradio-out-of-tree-project utility? Or did you copy the >> gr-howto-write-a-block directory? Neither of these will produce what you >> experienced here. If you did it by hand, it sounds like a copy-and-paste >> error. >> >> Tom >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] using custom signal processing module
On Tue, Jun 7, 2011 at 10:48 AM, mehmet kabasakal <85kabasa...@gmail.com>wrote: > I used the tutorial on > http://gnuradio.org/redmine/wiki/gnuradio/Basic_block and > gr-my-blocks-template as a template folder. > My guess is that this needs to be updated. I'm also not sure what it does that create-gnuradio-out-of-tree-project doesn't do; if there is something in particular here, we can probably add it to the project. What's nice about the create- script is that it checks out the latest code from the repo, so everything should stay up-to-date. Tom > 2011/6/7, mehmet kabasakal <85kabasa...@gmail.com>: > > I used the tutorial on > > http://gnuradio.org/redmine/wiki/gnuradio/Basic_block > > gr-my-blocks-template as a template folder. > > > > Mehmet. > > > > 2011/6/7, Tom Rondeau : > >> On Tue, Jun 7, 2011 at 5:19 AM, mehmet kabasakal > >> <85kabasa...@gmail.com>wrote: > >> > >>> Hi, > >>> > >>> I had the same problem and i find a temporary solution for it. > >>> When you sudo make install a folder with the same name of your module > >>> should appear on the path usr/local/include/"your module name". But > >>> instead the folders name becomes MyModule. If you change its name > >>> using nautilus it works. And also you should go to > >>> /usr/local/lib/python2.6/MyModule and cut all the _init_ files and > >>> paste them into the folder "your module name". After these > >>> modifications my block run succesfully. Hope this helps. > >>> > >>> Mehmet. > >>> > >> > >> > >> That doesn't sound right. Did you use the > >> create-gnuradio-out-of-tree-project utility? Or did you copy the > >> gr-howto-write-a-block directory? Neither of these will produce what you > >> experienced here. If you did it by hand, it sounds like a copy-and-paste > >> error. > >> > >> Tom > >> > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error executing usrp2_wfm_rcv.py
On 07/06/2011 9:58 AM, Eduardo Lloret Fuentes wrote: Hello. Can this variable "step_size" have an arbitrary value? I tried several times and I always get this message: (python:3293): Gtk-CRITICAL **: IA__gtk_range_set_range: assertion `min < max' failed and nothing at the USRP2 output (around -400 dB) By the way, I am using BasicRX. The step size can be small, but in this case, the GTK package is complaining that the "MIN" and "MAX" values on the slider are reversed, or don't conform to the required "MIN < MAX" requirement. Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with new signal processing block
On Mon, Jun 6, 2011 at 3:52 PM, Felipe Fideles wrote: > I was just trying to execute tem example How to Square, available at > gr-howto-write-a-block-3.3.0.tar.gz. > When I use the make check command, It fails. What version of GNU Radio are you using? Make sure you don't have multiple conflicting versions (say in both /usr and /usr/local). Without more detail, that's the best explanation I can think of. Tom > > 2011/5/31 Tom Rondeau > >> On Tue, May 31, 2011 at 5:02 PM, Felipe Fideles wrote: >> >>> Hello, >>> >>> I got this error when I did the last make check comand, trying to test a >>> new signal processing block: >>> >>> File "/usr/lib/python2.6/unittest. >>> py", line 457, in run >>>for test in self._tests: >>> >>> TypeError: in method 'delete_gr_basic_block_sptr', argument 1 of type >>> 'boost::shared_ptr< gr_basic_block > *' >>> >>> Does anyone know how to fix it? >>> >>> Thanks, >>> -- >>> Felipe Fideles >>> Electrical Engineering Undergraduate >>> Universidade Federal de Campina Grande - Brazil >>> >> >> That's unfamiliar to me, but strikes me as a syntax error in your code. >> You're probably going to have to provide more details. >> >> Tom >> >> > > > > -- > Felipe Fideles > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Ranging (measure distance) between two radios
Hello, This is my first post in the community. I have been thinking about doing this question, but after having reviewed some of the theory with digital signal processing, usrp architecture and some approaches for positioning/raning, I think I need to ask to the expert community, mainly to find a line of work and to know the restrictions for the application we want to carry out. I would like to measure the distance between two radios at short distances (we have two UN-210 and two XCVR2450 or 1 WBX and 1 DBSRX2, let's say to 1 m, 2mup to for example 20 meters), starting from off-line experiments and finishing with real time measures in line of sight. My questions are: - What would be, from your experience, the best approach to do this (transmitted signal and digital processing in the receiver part), what accuracy should I expect in line of sight? I am looking mainly for a starting point, the signal structure to transmit and the receiver structure. For example, one of the thoughts I have is a correlation in the receiver of a pseudorandom (spread spectrum) transmited signal, this approach could serve to measure time of arrival by measuring the delay of the pseudo-noise code signal, when comparing it with an exact copy at the receiver. Another approach I have seen is the estimation of the Channel impulse response (CIR), that maybe (as far as i know) could serve also for estimating distances. I have seen that there is some code to do a correlation inside the FPGA of the USRP1. So far my references are (which maybe can be helpul for those who are working in the same field): - "Advancing Wireless Link Signatures for Location Distinction". Here, they do not carry out ranging/positioning, but a change in the transmitter position is detected. In my case (in the case ranging is not possible), to detect if a distance is crossed would be my objective (e.g. the transmitter go closer than 1 meter to the receiver). - "RF Ranging for Location Awareness". In this dissertation they use an arquitecture similar to the USRP hardware. As you can see what I am looking for is for some sort of radar/ranging application and some starting point. Also, my questions are very generic for now and I apologize for it, mainly because I am still looking how to focus the problem. Then, any help (references, similar work done) will be very useful. Kind regards, Mario ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to use gr_clock_recovery_mm_cc
On Tue, Jun 7, 2011 at 9:13 AM, Shen Wenbo wrote: > Hi All, > > In the gmsk.py, the gr.clock_recovery_mm_ff is used. > > I want to use gr.clock_recovery_mm_cc (float omega, float gain_omega, > float mu, float gain_mu) (which implements Mueller and Müller (M&M) based > clock recovery block with complex input, complex output) to replace the > gr.clock_recovery_mm_ff > > I have done these in two steps: > 1. use the same parameters (used to init gr.clock_recovery_mm_ff) to init > gr.clock_recovery_mm_cc. > omege=2.00, gain_omega=0.000625, mu=0.05, gain_mu=0.05, > omega_relative_limit=0.005000 > > 2. move the clock recovery block forward before demod block > self.connect(self, self.clock_recovery, self.fmdemod, self.slicer, self) > > Before modification, if I run the benchmark program using gmsk, receive > rate is almost 100%, but after my modification, receive rate drops to 0%. > > Does my method have problem, any help is appreciated! > > -- > Wenbo > You HAVE to use the clock recovery after the demod. Pre demodulation, you don't have the right type of signal to lock against. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error executing usrp2_wfm_rcv.py
On 07/06/2011 9:58 AM, Eduardo Lloret Fuentes wrote: Hello. Can this variable "step_size" have an arbitrary value? I tried several times and I always get this message: (python:3293): Gtk-CRITICAL **: IA__gtk_range_set_range: assertion `min < max' failed and nothing at the USRP2 output (around -400 dB) By the way, I am using BasicRX. OK, found the problem. The problem is that for a BASIC_RX, the available settable gain range is [0,0], since it has no settable gain elements. Which means the slider won't work properly. Perhaps one could put in a conditional prior to creation of the slider that checks for [0,0]. And doesn't create the slider at all if there is no usable gain range. Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error executing usrp2_wfm_rcv.py
Hello. Can this variable "step_size" have an arbitrary value? I tried several times and I always get this message: (python:3293): Gtk-CRITICAL **: IA__gtk_range_set_range: assertion `min < max' failed and nothing at the USRP2 output (around -400 dB) By the way, I am using BasicRX. Thanks! Eduardo. 2011/6/6 Nick Foster > On Mon, 2011-06-06 at 18:42 +0200, Eduardo Lloret Fuentes wrote: > > Hello to everybody. > > > > First of all, I am working with Ubuntu 10.10 and GNU Radio 3.4.0. I > > tried to run the usrp2_wfm_rcv.py graph but I got the following error: > > > > > > Traceback (most recent call last): > >File "./usrp2_wfm_rcv.py", line 289, in > > app = stdgui2.stdapp (wfm_rx_block, "USRP2 WFM RX") > >File > > "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py", > > line 36, in __init__ > > wx.App.__init__ (self, redirect=False) > >File > > "/usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", > > line 7978, in __init__ > > self._BootstrapApp() > >File > > "/usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", > > line 7552, in _BootstrapApp > > return _core_.PyApp__BootstrapApp(*args, **kwargs) > >File > > "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py", > > line 39, in OnInit > > frame = stdframe (self.top_block_maker, self.title, > > self._nstatus) > >File > > "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py", > > line 60, in __init__ > > self.panel = stdpanel (self, self, top_block_maker) > >File > > "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py", > > line 81, in __init__ > > self.top_block = top_block_maker (frame, self, vbox, sys.argv) > >File "./usrp2_wfm_rcv.py", line 118, in __init__ > > self._build_gui(vbox, usrp_rate, demod_rate, audio_rate) > >File "./usrp2_wfm_rcv.py", line 201, in _build_gui > > callback=self.set_gain) > >File > > "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/form.py", line > > 225, in __init__ > > nsteps = int((self.max-self.min)/self.step_size) > > ZeroDivisionError: float division > > make the step size of your slider something besides zero > > > > > > > > > I read in the mailing list that this problem could be related to the > > setting up of the gain slider control but I don't know how to fix it. > > Could anybody help me? > > > > A lot of thanks! > > > > Regards. > > > > Eduardo. > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] how to use gr_clock_recovery_mm_cc
Hi All, In the gmsk.py, the gr.clock_recovery_mm_ff is used. I want to use gr.clock_recovery_mm_cc (float omega, float gain_omega, float mu, float gain_mu) (which implements Mueller and Müller (M&M) based clock recovery block with complex input, complex output) to replace the gr.clock_recovery_mm_ff I have done these in two steps: 1. use the same parameters (used to init gr.clock_recovery_mm_ff) to init gr.clock_recovery_mm_cc. omege=2.00, gain_omega=0.000625, mu=0.05, gain_mu=0.05, omega_relative_limit=0.005000 2. move the clock recovery block forward before demod block self.connect(self, self.clock_recovery, self.fmdemod, self.slicer, self) Before modification, if I run the benchmark program using gmsk, receive rate is almost 100%, but after my modification, receive rate drops to 0%. Does my method have problem, any help is appreciated! -- Wenbo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSM not detecting station, USRP1, FA-SY1, WBX, DBS
On Tue, Jun 7, 2011 at 2:02 PM, Marcus D. Leech wrote: > This isn't really the correct mailing list for OpenBTS questions, but I > have a couple of suggestions: I wasn't sure it's a an openBTS question... as I said I don't know where I should look first since I tried so much. > > o what happens if you undo the clock modifications? > o what do you get if you use something like: > > uhd_fft.py --s 1.0e6 --freq 950e6 > > Do you get an error, or do you get some kind of reasonable-looking > spectral display? I cannot find any uhd_fft.py, I have: usrp_fft.py but it isn't aware of any flag that could be similar to --s... Where can I find that tool? Thanks for the reply ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSM not detecting station, USRP1, FA-SY1, WBX, DBS
> > Hello list, > > I'm having a lot of trouble here while trying to make openBTS work with my > USRP1 > to play with GSMs. > First of all, a little description of my setup: > Software: > openbts-2.6.0Mamou > gnuradio v3.4.0git-130-g207a2ae7 > UHD from git > OS: ubuntu 11.04 > > # sudo lsusrp > USRP 0 serial number 4c76a203 > RX d'board A: WBX NG RX > RX d'board B: DBS Rx > TX d'board A: WBX NG TX > TX d'board B: > > /usr/local/share/gnuradio/examples/usrp/usrp_benchmark_usb.py > Max USB/USRP throughput = 32MB/sec > > I'm using a FA-SY clock to get 52Mhz and I followed the guide in [1] > I didn't modify any of the code, since I'm using gnuradio 3.4. (But I > adapted my OpenBTS.config) > When I start openBTS I get the following output: > http://pastebin.com/raw.php?i=nKbG4j3z (I pasted the whole output) > > Here is the openBTS config I use: > http://pastebin.com/raw.php?i=aUQfYWGu > (This is the last I used, but I tried several other configs) > > My phones cannot find the network, I'm trying with a Motorolla C123, > Nokia 3510i and Nokia E71. I'm not sure where I should search next, I > google'd a lot an read documentation, tried out the fixes described in > forums etc. > Strange behaviour (maybe normal, but not sure): > "sudo usrp_siggen.py --sine > Press Enter to quit: " > No more output... > > I would be glad if somebody had an idea where I could look next. > > With best regards, > Marc > > [1]: http://gnuradio.org/redmine/wiki/1/OpenBTSClockModifications > > ___ > This isn't really the correct mailing list for OpenBTS questions, but I have a couple of suggestions: o what happens if you undo the clock modifications? o what do you get if you use something like: uhd_fft.py --s 1.0e6 --freq 950e6 Do you get an error, or do you get some kind of reasonable-looking spectral display? > -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GSM not detecting station, USRP1, FA-SY1, WBX, DBS
Hello list, I'm having a lot of trouble here while trying to make openBTS work with my USRP1 to play with GSMs. First of all, a little description of my setup: Software: openbts-2.6.0Mamou gnuradio v3.4.0git-130-g207a2ae7 UHD from git OS: ubuntu 11.04 # sudo lsusrp USRP 0 serial number 4c76a203 RX d'board A: WBX NG RX RX d'board B: DBS Rx TX d'board A: WBX NG TX TX d'board B: /usr/local/share/gnuradio/examples/usrp/usrp_benchmark_usb.py Max USB/USRP throughput = 32MB/sec I'm using a FA-SY clock to get 52Mhz and I followed the guide in [1] I didn't modify any of the code, since I'm using gnuradio 3.4. (But I adapted my OpenBTS.config) When I start openBTS I get the following output: http://pastebin.com/raw.php?i=nKbG4j3z (I pasted the whole output) Here is the openBTS config I use: http://pastebin.com/raw.php?i=aUQfYWGu (This is the last I used, but I tried several other configs) My phones cannot find the network, I'm trying with a Motorolla C123, Nokia 3510i and Nokia E71. I'm not sure where I should search next, I google'd a lot an read documentation, tried out the fixes described in forums etc. Strange behaviour (maybe normal, but not sure): "sudo usrp_siggen.py --sine Press Enter to quit: " No more output... I would be glad if somebody had an idea where I could look next. With best regards, Marc [1]: http://gnuradio.org/redmine/wiki/1/OpenBTSClockModifications ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] using custom signal processing module
Hi, I had the same problem and i find a temporary solution for it. When you sudo make install a folder with the same name of your module should appear on the path usr/local/include/"your module name". But instead the folders name becomes MyModule. If you change its name using nautilus it works. And also you should go to /usr/local/lib/python2.6/MyModule and cut all the _init_ files and paste them into the folder "your module name". After these modifications my block run succesfully. Hope this helps. Mehmet. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
