Re: [Discuss-gnuradio] Unable to receive using USRP N210, XCVR2450 daughterboards running benchmark programs
On 31/01/12 09:53 PM, shantharam balasubramanian wrote: > When the transmitter was producing the dots, are you 100% sure that > the packets were gettting transmitted in the first place? > > cause i used spectrum analyser and i ran uhd_fft.py, and saw that no > signals were peaking up on that particular frequency. Even Tom had the > same doubt when he visited my lab today, and told me to check if the > transmitter was transmitting the packets. I dont think it does. > So, why not use uhd_siggen.py or similar to produce a simple single-tone, at a desired frequency, and look for *that*. Debug using the simplest tools at your disposal, not the most complicated ones. -- 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
Re: [Discuss-gnuradio] Unable to receive using USRP N210, XCVR2450 daughterboards running benchmark programs
When the transmitter was producing the dots, are you 100% sure that the packets were gettting transmitted in the first place? cause i used spectrum analyser and i ran uhd_fft.py, and saw that no signals were peaking up on that particular frequency. Even Tom had the same doubt when he visited my lab today, and told me to check if the transmitter was transmitting the packets. I dont think it does. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unable to receive using USRP N210, XCVR2450 daughterboards running benchmark programs
Hi Dhrubojyoti, I also observed the same experimental results, i.e., (1) fail to receive packets using benchmark programs; (2) 1MHz shift with XCVR2450 daughterboard. Sometimes, the wider bandwidth (or higher sample rate) and shifted central frequency help. Regards, Lizhao 2012/1/9 Dhrubojyoti Roy > Hi All, > > I´m new to GNUradio and have run into the basic problem of the receiver > USRP device not being able to decode the senderś transmission. For our > experiments, we used GNUradio (MAJOR_VERSION=3, API_COMPAT=5, > MINOR_VERSION=1) and USRP N210 with XCVR2450 daughterboards, and the > benchmark_tx/rx programs for both narrowband and ofdm. We used the > following transmitter arguments and got the result below: > > *./benchmark_tx.py -f 2.4G -r 2M -M 10 -v > * > linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.000-f2388c0 > > >>> gr_fir_ccf: using SSE > > Modulator: > bits per symbol: 4 > RRC roll-off factor: 0.35 > -- Opening a USRP2/N-Series device... > -- Current recv frame size: 1472 bytes > -- Current send frame size: 1472 bytes > > No gain specified. > Setting gain to 17.50 (from [0.00, 35.00]) > > UHD Transmitter: > Args: > Freq:2.4GHz > Gain:17.50 dB > Sample Rate: 1Msps > Antenna: None > Subdev Sec: None > > Modulator: > bits per symbol: 4 > RRC roll-off factor: 0.35 > Tx amplitude 0.25 > modulation: psk_mod > bitrate: 2Mb/s > samples/symbol: 2. > Differential:True > ...(sending the > data) > > We invoked the receiver as follows: > > *./benchmark_rx.py -f 2.4G -r 2M -v* > > linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.000-f2388c0 > > >>> gr_fir_ccf: using SSE > > Demodulator: > bits per symbol: 4 > RRC roll-off factor: 0.35 > FLL bandwidth: 6.28e-02 > Timing bandwidth:6.28e-02 > Phase bandwidth: 6.28e-02 > -- Opening a USRP2/N-Series device... > -- Current recv frame size: 1472 bytes > -- Current send frame size: 1472 bytes > > No gain specified. > Setting gain to 49.50 (from [0.00, 99.00]) > > UHD Receiver: > UHD Args: > Freq:2.4GHz > Gain:49.50 dB > Sample Rate: 1Msps > Antenna: None > Spec:None > > Demodulator: > bits per symbol: 4 > RRC roll-off factor: 0.35 > FLL bandwidth: 6.28e-02 > Timing bandwidth:6.28e-02 > Phase bandwidth: 6.28e-02 > > Receive Path: > modulation: psk_demod > bitrate: 2Mb/s > samples/symbol: 2. > Differential:True > > At this point, even with the transmitter running, the receiver program > pauses for about a minute before bursting into a string of ´O´s. We found > that our transmission was being detected by the receiving USRP, using the > uhd_fft.py program. However, an interesting observation was that our signal > was detected at center frequency 2.401GHz (screenshot attached). We doubt > if this is due to oscillator differences, since switching the transmitter > and receiver devices also resulted in detection at the same 2.401GHz center > frequency. > > We tried variations to the above programs by making the > *benchmark_rx.py*listen in th 2.401GHz frequency, other modulation schemes > such as qam, > different transmission gains and also the OFDM benchmarks with similar > variations, but there was no output on the receiver. Could it be possible > that the receiver can detect but cannot decode the signal? Your valuable > advice in this regard would be sincerely appreciated. > > Thanks and Regards, > Dhrubojyoti. > > -- > Dhrubojyoti Roy > 1655, North 4th Street, Apt-D > Columbus, OH-43201 > Contact no.: +1-740-417-5890 > > > ___ > 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
Re: [Discuss-gnuradio] Unable to receive using USRP N210, XCVR2450 daughterboards running benchmark programs
Dhrubojyoti, In ur program u have set the Bitrate rate to 2MB/s. It exceeds the computing power of ur PC that is why u are getting "". These 'O' means overflow i.e. USRP is producing data at faster rate than the ability of PC to process Try changing bitrate to 100-500 KB/s -Adeel On Sun, Jan 8, 2012 at 4:01 PM, Dhrubojyoti Roy wrote: > Hi All, > > I´m new to GNUradio and have run into the basic problem of the receiver > USRP device not being able to decode the senderś transmission. For our > experiments, we used GNUradio (MAJOR_VERSION=3, API_COMPAT=5, > MINOR_VERSION=1) and USRP N210 with XCVR2450 daughterboards, and the > benchmark_tx/rx programs for both narrowband and ofdm. We used the > following transmitter arguments and got the result below: > > *./benchmark_tx.py -f 2.4G -r 2M -M 10 -v > * > linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.000-f2388c0 > > >>> gr_fir_ccf: using SSE > > Modulator: > bits per symbol: 4 > RRC roll-off factor: 0.35 > -- Opening a USRP2/N-Series device... > -- Current recv frame size: 1472 bytes > -- Current send frame size: 1472 bytes > > No gain specified. > Setting gain to 17.50 (from [0.00, 35.00]) > > UHD Transmitter: > Args: > Freq:2.4GHz > Gain:17.50 dB > Sample Rate: 1Msps > Antenna: None > Subdev Sec: None > > Modulator: > bits per symbol: 4 > RRC roll-off factor: 0.35 > Tx amplitude 0.25 > modulation: psk_mod > bitrate: 2Mb/s > samples/symbol: 2. > Differential:True > ...(sending the > data) > > We invoked the receiver as follows: > > *./benchmark_rx.py -f 2.4G -r 2M -v* > > linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.000-f2388c0 > > >>> gr_fir_ccf: using SSE > > Demodulator: > bits per symbol: 4 > RRC roll-off factor: 0.35 > FLL bandwidth: 6.28e-02 > Timing bandwidth:6.28e-02 > Phase bandwidth: 6.28e-02 > -- Opening a USRP2/N-Series device... > -- Current recv frame size: 1472 bytes > -- Current send frame size: 1472 bytes > > No gain specified. > Setting gain to 49.50 (from [0.00, 99.00]) > > UHD Receiver: > UHD Args: > Freq:2.4GHz > Gain:49.50 dB > Sample Rate: 1Msps > Antenna: None > Spec:None > > Demodulator: > bits per symbol: 4 > RRC roll-off factor: 0.35 > FLL bandwidth: 6.28e-02 > Timing bandwidth:6.28e-02 > Phase bandwidth: 6.28e-02 > > Receive Path: > modulation: psk_demod > bitrate: 2Mb/s > samples/symbol: 2. > Differential:True > > At this point, even with the transmitter running, the receiver program > pauses for about a minute before bursting into a string of ´O´s. We found > that our transmission was being detected by the receiving USRP, using the > uhd_fft.py program. However, an interesting observation was that our signal > was detected at center frequency 2.401GHz (screenshot attached). We doubt > if this is due to oscillator differences, since switching the transmitter > and receiver devices also resulted in detection at the same 2.401GHz center > frequency. > > We tried variations to the above programs by making the > *benchmark_rx.py*listen in th 2.401GHz frequency, other modulation schemes > such as qam, > different transmission gains and also the OFDM benchmarks with similar > variations, but there was no output on the receiver. Could it be possible > that the receiver can detect but cannot decode the signal? Your valuable > advice in this regard would be sincerely appreciated. > > Thanks and Regards, > Dhrubojyoti. > > -- > Dhrubojyoti Roy > 1655, North 4th Street, Apt-D > Columbus, OH-43201 > Contact no.: +1-740-417-5890 > > > ___ > 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
