[Discuss-gnuradio] Re: Basic RX. - usrp_wfm_rcv.py
Rita's pfc wrote am 2008-07-25 17:39: First of all, I've run the dial_tone.py example, and it was ok. Then, I wanted to use the USRP, so the next example I wanted to test was the usrp_wfm_rcv.py. I've connected a Basic Rx daughterboard to RXB. I write ./usrp_wfm_rcv.py -f 100, I get an error message: FYI: No powermate or Contour Knob found; http://www.nabble.com/file/p18654189/error_fm.jpg This is more an information message than error. The Powermate and the Contour knob, if present, are used for more convenient usage, but the program still runs without any of them. You can use the interface with the mouse without a drawback. Regarding your problem: The option "-f 100" in your command instructs your program to listen FM at a frequency of 100Hz. The option takes magnitude suffixes, so you'd rather want "-f 100M". Choose a frequency of a strong radio station in your area. You will not be able to listen so FM radio without a adequate antenna. For a dipole the receiving length of your antenna should be in the order of lambda/2, that is c/f/2 = 3*10^8/1*10^8/2=1.5m. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Beagle board available now
http://beagleboard.org/ It's not plug and play (for gnuradio at least) but it has great potential. Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to change the USRP output data format to char??
Hi all: I am writing some C programs to read data from the USRP. Currently the output data format from the USRP is short. I want to change the output data format to char to give me a higher sample frequency. Can I do this? where should I change the setting of the USRP?? Thanks! -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN 802.11 bbn_80211b_rx.py
What does "combination of the LO in the front end and the digital downconverter" mean please? Eric Blossom wrote: > > On Fri, Jul 25, 2008 at 10:11:34AM -0700, Y. Zhuang wrote: >> http://en.wikipedia.org/wiki/List_of_WLAN_channels >> >> Is it because the channel for 802.11 in 2.432G there, so the front end >> was tuned to 2.432G? But there is 2.437G as well. >> Or the font end is just picking the strongest channel it finds? Thanks >> >> Y > > None of the above. I'm just decoding the details of how the usrp was > tuned using a combination of the LO in the front end and the digital > downconverter. The command line shows -f 2.437G. See the excellent > USRP FAQ for additional info. http://gnuradio.org/trac/wiki/UsrpFAQ > > Eric > > >> >> 2008/7/25 Eric Blossom <[EMAIL PROTECTED]>: >> > On Fri, Jul 25, 2008 at 07:46:58AM -0400, Greg Troxel wrote: >> >> BTW, what does that guy mean "Not sure when you updated, but we have >> changed >> >> the checked in code to default to 2437, and run it like this (as a >> NetBSD >> >> rc.d start script)", following the above link? >> >> >> >> details if you care, but surely they have little to do with your >> issues. >> >> >> >> http://www.netbsd.org/docs/guide/en/chap-rc.html >> >> >> >> about your output: >> >> >> >> ./bbn_80211b_rx.py -f 2.437G -v -b >> >> Bits Per Encoded Sample = 8 >> >> adc frequency = 6400 >> >> decimation frequency = 16 >> >> input_rate = 400 >> >> gain = 45.0 >> >> desired freq = 243700.0 >> >> baseband frequency 243200.0 >> >> dxc frequency -500.0 >> >> Samples per data bit = 8 >> >> >>> gr_fir_ccf: using SSE >> >> >> >> 2.432G is used instead of 2.437G. Also the dxc frequency is >> negative. And >> >> no packets get printed out. >> >> >> >> I am unclear on dxc. >> > >> > That part is fine. dxc = digital down converter (DDC) or DUC depending >> on the context. >> > In this case he wanted 2.437G. The front end was tuned to 2.432G, thus >> > the DDC needed to be set to -5M to get the desired frequency translated >> > to 0 Hz in the complex baseband. >> > >> > Eric >> > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://www.nabble.com/BBN-802.11-bbn_80211b_rx.py-tp18642793p18693934.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] Basic RX. - usrp_wfm_rcv.py
Thank you for the answer. I did what you told me about "-f 100M", but it happened the same. I tried to do with usrp_wfm_rcv_nogui.py and it happened the same. About the antenna, I supposed that just a simple peace of metal hooked on the daughterboard would be enough. Should I buy a specific antenna for any frequency in FM band that I wanted to listen with the Basic RX? Maybe it's a stupid question. Sorry for that. Thank you -- View this message in context: http://www.nabble.com/Basic-RX.-tp18654189p18694956.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 802.11 bbn_80211b_rx.py
On Mon, Jul 28, 2008 at 12:28 PM, yyzhuang <[EMAIL PROTECTED]> wrote: > > What does "combination of the LO in the front end and the digital > downconverter" mean please? For general radio architecture, please see: http://en.wikipedia.org/wiki/Superheterodyne Generally, the LO/synthesizer has some discrete step size (12.5kHz, 250kHz, etc). To get down to baseband, the resultant signal is then shifted in frequency down using the digital downconverter: http://en.wikipedia.org/wiki/Digital_Down_Converter Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Basic RX. - usrp_wfm_rcv.py
Rita's pfc wrote am 2008-07-28 19:03: Thank you for the answer. I did what you told me about "-f 100M", but it happened the same. I tried to do with usrp_wfm_rcv_nogui.py and it happened the same. About the antenna, I supposed that just a simple peace of metal hooked on the daughterboard would be enough. Should I buy a specific antenna for any frequency in FM band that I wanted to listen with the Basic RX? Maybe it's a stupid question. No Stupid Question. Yes, a FM antenna should do, but you have to look for an adaptor, could be tricky. Your screenshot just hides the relevant information from the console, but moreover it's more useful to have a text copy of what's going on on your terminal. Seems like the application is kind of hung. Tell us more about your setup: OS? Distribution? Version? Version of GNU Radio you are using? Hardware: RAM, CPU? Open a system monitor before starting the application and watch memory and CPU consumptions. I can hardly listen to FM with my PII 450MHz. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possible residual carrier not reported correctly
Eric,
I have answered you questions inline:
>>Are you seeing any over or underruns ("uOuO" or "uUuU") on the console?
Occasionally, I see "u0" on the rx. But, even if i post process data
offline, i still get the "flip"
>> How wide is the signal you're trying to send?
The rx interp is 256 and the tx interp is 512 giving a BW=250Khz. Since I
am just sending random samples, I am using the whole band.
>> What interpolation and decimation values are you using?
See above.
>> Try sending it at 10MHz.
I did. The Rx cannot see my signal anymore; a PSD confirms this. Not
sure why.. maybe an antenna issue.
>> What version of GNU Radio are you using?
I do not know what version the radios are. How do i find this out? The
serial numbers are 1460 and 1461 and there is a date on the sticker that
says 4/16/07.
>> Have you isolated the problem to the Tx or Rx path?
I believe it is in the Rx path. The TX path simply reads up a data file
of samples and sends them to the USRP... very simple. The RX path receives
the data and attempts to correlate on the samples I sent. However, I am
noticing that the correlation is postive, then negative, and continues this
way alternating about every 1000 samples or so.
Isaac
--
View this message in context:
http://www.nabble.com/Possible-residual-carrier-not-reported-correctly-tp18659713p18696655.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] Basic RX. - usrp_wfm_rcv.py
I've installed Windows XP, and for an easier installation of GNU Radio, I have installed a virtual machine (VM) with Ubuntu 6.1. The PC is a Pentium 3 GHz, with 2 GB RAM, but for Ubuntu I've 1 GB. Do you think is this enough? or maybe I must let Ubuntu the hole RAM of my PC. I took the binary packages from http://gnuradio.org/trac/wiki/UbuntuInstall Thanks a lot. -- View this message in context: http://www.nabble.com/Basic-RX.-tp18654189p18696911.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] Possible residual carrier not reported correctly
On Mon, Jul 28, 2008 at 11:34:01AM -0700, isaacgerg wrote:
>
> Eric,
> I have answered you questions inline:
>
> >>Are you seeing any over or underruns ("uOuO" or "uUuU") on the console?
> Occasionally, I see "u0" on the rx. But, even if i post process data
> offline, i still get the "flip"
>
> >> How wide is the signal you're trying to send?
> The rx interp is 256 and the tx interp is 512 giving a BW=250Khz. Since I
> am just sending random samples, I am using the whole band.
>
> >> What interpolation and decimation values are you using?
> See above.
>
> >> Try sending it at 10MHz.
> I did. The Rx cannot see my signal anymore; a PSD confirms this. Not
> sure why.. maybe an antenna issue.
>
> >> What version of GNU Radio are you using?
> I do not know what version the radios are. How do i find this out? The
> serial numbers are 1460 and 1461 and there is a date on the sticker that
> says 4/16/07.
Sorry, not the board, the GNU Radio software you're running on the host.
There was a problem in the FPGA code that was fixed quite a while
ago (6 or 9 months) where there was some kind of flipping.
> >> Have you isolated the problem to the Tx or Rx path?
> I believe it is in the Rx path. The TX path simply reads up a data file
> of samples and sends them to the USRP... very simple. The RX path receives
> the data and attempts to correlate on the samples I sent. However, I am
> noticing that the correlation is postive, then negative, and continues this
> way alternating about every 1000 samples or so.
>
> Isaac
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possible residual carrier not reported correctly
Eric,
I pulled GNU Radio from the SVN repository no more than 3 months ago.
What do you mean the FPGA had a flipping problem? Wouldnt this affect my
USRP hardware or does the GNU Radio code correct for it?
Isaac
Eric Blossom wrote:
>
> On Mon, Jul 28, 2008 at 11:34:01AM -0700, isaacgerg wrote:
>>
>> Eric,
>> I have answered you questions inline:
>>
>> >>Are you seeing any over or underruns ("uOuO" or "uUuU") on the console?
>> Occasionally, I see "u0" on the rx. But, even if i post process data
>> offline, i still get the "flip"
>>
>> >> How wide is the signal you're trying to send?
>> The rx interp is 256 and the tx interp is 512 giving a BW=250Khz.
>> Since I
>> am just sending random samples, I am using the whole band.
>>
>> >> What interpolation and decimation values are you using?
>> See above.
>>
>> >> Try sending it at 10MHz.
>> I did. The Rx cannot see my signal anymore; a PSD confirms this. Not
>> sure why.. maybe an antenna issue.
>>
>> >> What version of GNU Radio are you using?
>> I do not know what version the radios are. How do i find this out? The
>> serial numbers are 1460 and 1461 and there is a date on the sticker that
>> says 4/16/07.
>
>
> Sorry, not the board, the GNU Radio software you're running on the host.
>
> There was a problem in the FPGA code that was fixed quite a while
> ago (6 or 9 months) where there was some kind of flipping.
>
>
>> >> Have you isolated the problem to the Tx or Rx path?
>> I believe it is in the Rx path. The TX path simply reads up a data
>> file
>> of samples and sends them to the USRP... very simple. The RX path
>> receives
>> the data and attempts to correlate on the samples I sent. However, I am
>> noticing that the correlation is postive, then negative, and continues
>> this
>> way alternating about every 1000 samples or so.
>>
>> Isaac
>
> Eric
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
View this message in context:
http://www.nabble.com/Possible-residual-carrier-not-reported-correctly-tp18659713p18697521.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] Possible residual carrier not reported correctly
On Mon, Jul 28, 2008 at 12:27:22PM -0700, isaacgerg wrote:
>
> Eric,
> I pulled GNU Radio from the SVN repository no more than 3 months ago.
> What do you mean the FPGA had a flipping problem? Wouldnt this affect my
> USRP hardware or does the GNU Radio code correct for it?
>
> Isaac
I was thinking of ticket:179
http://gnuradio.org/trac/ticket/179
It was fixed in r6764 on the trunk on 10/31/2007.
> Eric Blossom wrote:
> >
> > On Mon, Jul 28, 2008 at 11:34:01AM -0700, isaacgerg wrote:
> >>
> >> Eric,
> >> I have answered you questions inline:
> >>
> >> >>Are you seeing any over or underruns ("uOuO" or "uUuU") on the console?
> >> Occasionally, I see "u0" on the rx. But, even if i post process data
> >> offline, i still get the "flip"
If you're getting "uO" your machine is not keeping up. This would
cause a discontinuity in the received data, post-processed or not.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possible residual carrier not reported correctly
Eric,
I read the ticket. We are just sending float data and it doesnt appear
that the arms are getting flipped, but that over time, their phase is
changing. Our correlation peaks go from being very positive to being very
negative over a gradient.
Any ideas?
Isaac
Eric Blossom wrote:
>
> On Mon, Jul 28, 2008 at 12:27:22PM -0700, isaacgerg wrote:
>>
>> Eric,
>> I pulled GNU Radio from the SVN repository no more than 3 months ago.
>> What do you mean the FPGA had a flipping problem? Wouldnt this affect my
>> USRP hardware or does the GNU Radio code correct for it?
>>
>> Isaac
>
> I was thinking of ticket:179
> http://gnuradio.org/trac/ticket/179
> It was fixed in r6764 on the trunk on 10/31/2007.
>
>> Eric Blossom wrote:
>> >
>> > On Mon, Jul 28, 2008 at 11:34:01AM -0700, isaacgerg wrote:
>> >>
>> >> Eric,
>> >> I have answered you questions inline:
>> >>
>> >> >>Are you seeing any over or underruns ("uOuO" or "uUuU") on the
>> console?
>> >> Occasionally, I see "u0" on the rx. But, even if i post process data
>> >> offline, i still get the "flip"
>
> If you're getting "uO" your machine is not keeping up. This would
> cause a discontinuity in the received data, post-processed or not.
>
> Eric
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
View this message in context:
http://www.nabble.com/Possible-residual-carrier-not-reported-correctly-tp18659713p18699572.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] Possible residual carrier not reported correctly
Eric,
When you talk about the FPGA, do you mean that I can repull and reinstall
the FPGA code for the USRP? This I have never done since the radio has been
purchased 2 years ago.
Isaac
Eric Blossom wrote:
>
> On Mon, Jul 28, 2008 at 12:27:22PM -0700, isaacgerg wrote:
>>
>> Eric,
>> I pulled GNU Radio from the SVN repository no more than 3 months ago.
>> What do you mean the FPGA had a flipping problem? Wouldnt this affect my
>> USRP hardware or does the GNU Radio code correct for it?
>>
>> Isaac
>
> I was thinking of ticket:179
> http://gnuradio.org/trac/ticket/179
> It was fixed in r6764 on the trunk on 10/31/2007.
>
>> Eric Blossom wrote:
>> >
>> > On Mon, Jul 28, 2008 at 11:34:01AM -0700, isaacgerg wrote:
>> >>
>> >> Eric,
>> >> I have answered you questions inline:
>> >>
>> >> >>Are you seeing any over or underruns ("uOuO" or "uUuU") on the
>> console?
>> >> Occasionally, I see "u0" on the rx. But, even if i post process data
>> >> offline, i still get the "flip"
>
> If you're getting "uO" your machine is not keeping up. This would
> cause a discontinuity in the received data, post-processed or not.
>
> Eric
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
View this message in context:
http://www.nabble.com/Possible-residual-carrier-not-reported-correctly-tp18659713p18699807.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] Possible residual carrier not reported correctly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 28, 2008, at 2:09 PM, isaacgerg wrote: Eric, When you talk about the FPGA, do you mean that I can repull and reinstall the FPGA code for the USRP? This I have never done since the radio has been purchased 2 years ago. Isaac The FPGA code is dynamically loaded when the USRP is initialized. As long as you have an installed copy of GNU radio newer than 10/2007 you should already be using the updated RBF file which is the FPGA code image. - -Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkiONz8ACgkQy9GYuuMoUJ7eawCfQJpQOh+bxylHBQkopBXtfZ1E gWcAnjeboTx3qzehHKDJ2nEVxo3fIOAh =kqM2 -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP Problems with decim_rate = 4
Hi I think the USRP can provide the minimum decimate rate of 4. So I changed the output data format from short to char. With 8-bit I & Q decim = 4 ->64M/4= 16MS/sec ,I&Q -> 32MB/sec. That is within the range of my USB speed. In the make_format() function I set the width = 8, shift = 8. Then the out put of USRP will be char data. But when I read the data from the USRP, I found all of them are just 0s. When I change the decim_rate = 8, then I can get the right results. So I want to know what is wrong in my method? How can I get data with decim_rate = 4? -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN 802.11 bbn_80211b_rx.py
Thanks.
When I use "./bbn_80211b_rx.py -f 2.44G -v -b ", no packets get printed out.
But the output of "./bbn_80211b_rx.py -f 2.462G -d 8 -b -v " is normal, we
got a bunch of packets:
Bits Per Encoded Sample = 8
adc frequency = 6400
decimation frequency = 8
input_rate = 800
gain = 45.0
desired freq = 246200.0
baseband frequency 246000.0
dxc frequency -200.0
Samples per data bit = 8
>>> gr_fir_ccf: using SSE
PKT: len=77, rssi=-22, src=00:13:46:16:28:AA, time=557560, rate=1 Mbps
PKT: len=77, rssi=-29, src=00:13:46:16:28:AA, time=1786312, rate=1 Mbps
PKT: len=77, rssi=-26, src=00:13:46:16:28:AA, time=1991192, rate=1 Mbps
...
I checked the code:
parser.add_option("-d", "--decim", type="int", default=16,
help="set fgpa decimation rate to DECIM
[default=%default]")
parser.add_option("-b", "--barker", action="store_true",
default=False,
help="Use Barker Spreading [default=%default]")
-d 8 is setting the fpga decimation rate to 8, and -b means Use Barker
Spreading. How should we know what decimation rate and spreading to use?
Thanks.
BTW, if one ursp for tx and one for rx, we dont have to specify these
options:
on the sending side: ./bbn_80211b_rx.py -f 2.44G -v -b
Using TX d'board A: Flex 2400 Tx MIMO B
>>> gr_fir_ccf: using SSE
spb: 8
interp: 32
(spb = samples/baud, default 8; interp = fpga interpolation rate, default 32
)
on the receiving side: ./bbn_80211b_tx.py -f 2.44G
Bits Per Encoded Sample = 8
adc frequency = 6400
decimation frequency = 16
input_rate = 400
gain = 45.0
desired freq = 244000.0
baseband frequency 243600.0
dxc frequency -400.0
Samples per data bit = 8
>>> gr_fir_ccf: using SSE
PKT: len=1477, rssi=-10, src=20:61:6e:64:20:73, time=16024824, rate=1 Mbps
PKT: len=1477, rssi=-12, src=20:61:6e:64:20:73, time=16036920, rate=1 Mbps
PKT: len=1477, rssi=-11, src=20:61:6e:64:20:73, time=16049016, rate=1 Mbps
PKT: len=1477, rssi=-13, src=20:61:6e:64:20:73, time=16061112, rate=1 Mbps
Thanks!
Brian Padalino wrote:
>
> On Mon, Jul 28, 2008 at 12:28 PM, yyzhuang <[EMAIL PROTECTED]> wrote:
>>
>> What does "combination of the LO in the front end and the digital
>> downconverter" mean please?
>
> For general radio architecture, please see:
>
> http://en.wikipedia.org/wiki/Superheterodyne
>
> Generally, the LO/synthesizer has some discrete step size (12.5kHz,
> 250kHz, etc). To get down to baseband, the resultant signal is then
> shifted in frequency down using the digital downconverter:
>
> http://en.wikipedia.org/wiki/Digital_Down_Converter
>
> Brian
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
View this message in context:
http://www.nabble.com/BBN-802.11-bbn_80211b_rx.py-tp18642793p18700741.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 802.11 bbn_80211b_rx.py
802.11b standard use barker spreading, So if you want to receive data
from a standard 802.11b transmitter you have to use barker. For
decimation it should be as high as possible because 802.11b receiver
needs more more than 22M complex sample per sec to work correctly. But
USB cannot handle that much bit-rate so we have to downsample it to
8McSps. This reduces SNR which reduces receiver performance and range
of activity.
regards,
hamed
Quoting yyzhuang <[EMAIL PROTECTED]>:
Thanks.
When I use "./bbn_80211b_rx.py -f 2.44G -v -b ", no packets get printed out.
But the output of "./bbn_80211b_rx.py -f 2.462G -d 8 -b -v " is normal, we
got a bunch of packets:
Bits Per Encoded Sample = 8
adc frequency = 6400
decimation frequency = 8
input_rate = 800
gain = 45.0
desired freq = 246200.0
baseband frequency 246000.0
dxc frequency -200.0
Samples per data bit = 8
gr_fir_ccf: using SSE
PKT: len=77, rssi=-22, src=00:13:46:16:28:AA, time=557560, rate=1 Mbps
PKT: len=77, rssi=-29, src=00:13:46:16:28:AA, time=1786312, rate=1 Mbps
PKT: len=77, rssi=-26, src=00:13:46:16:28:AA, time=1991192, rate=1 Mbps
...
I checked the code:
parser.add_option("-d", "--decim", type="int", default=16,
help="set fgpa decimation rate to DECIM
[default=%default]")
parser.add_option("-b", "--barker", action="store_true",
default=False,
help="Use Barker Spreading [default=%default]")
-d 8 is setting the fpga decimation rate to 8, and -b means Use Barker
Spreading. How should we know what decimation rate and spreading to use?
Thanks.
BTW, if one ursp for tx and one for rx, we dont have to specify these
options:
on the sending side: ./bbn_80211b_rx.py -f 2.44G -v -b
Using TX d'board A: Flex 2400 Tx MIMO B
gr_fir_ccf: using SSE
spb: 8
interp: 32
(spb = samples/baud, default 8; interp = fpga interpolation rate, default 32
)
on the receiving side: ./bbn_80211b_tx.py -f 2.44G
Bits Per Encoded Sample = 8
adc frequency = 6400
decimation frequency = 16
input_rate = 400
gain = 45.0
desired freq = 244000.0
baseband frequency 243600.0
dxc frequency -400.0
Samples per data bit = 8
gr_fir_ccf: using SSE
PKT: len=1477, rssi=-10, src=20:61:6e:64:20:73, time=16024824, rate=1 Mbps
PKT: len=1477, rssi=-12, src=20:61:6e:64:20:73, time=16036920, rate=1 Mbps
PKT: len=1477, rssi=-11, src=20:61:6e:64:20:73, time=16049016, rate=1 Mbps
PKT: len=1477, rssi=-13, src=20:61:6e:64:20:73, time=16061112, rate=1 Mbps
Thanks!
Brian Padalino wrote:
On Mon, Jul 28, 2008 at 12:28 PM, yyzhuang <[EMAIL PROTECTED]> wrote:
What does "combination of the LO in the front end and the digital
downconverter" mean please?
For general radio architecture, please see:
http://en.wikipedia.org/wiki/Superheterodyne
Generally, the LO/synthesizer has some discrete step size (12.5kHz,
250kHz, etc). To get down to baseband, the resultant signal is then
shifted in frequency down using the digital downconverter:
http://en.wikipedia.org/wiki/Digital_Down_Converter
Brian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
View this message in context:
http://www.nabble.com/BBN-802.11-bbn_80211b_rx.py-tp18642793p18700741.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
- End forwarded message -
--
Mohammad Hamed Firooz
ECE Department, U of Utah
Salt Lake City
UT, 48112
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Channel measurements?
That is not always true, actually it depends on when and where you are going to measure a channel, For example in a office during a day, channel could change several times in a second. So for indoor applications a channel sounder should be as fast as possible. I can refer you to these papers to study more channe behavior: K.Pahlavan, et.al. Indoor Geolocation Science and Technology N.Patwari, et.al. Robust Location Distinction using Temporal Link Signatures you can also see our website for more information and papers: http://span.ece.utah.edu/pmwiki/pmwiki.php?n=Main.PHY-basedDistinction regards, hamed Quoting Nikhil <[EMAIL PROTECTED]>: On Fri, Jul 25, 2008 at 9:57 PM, Johnathan Corgan < [EMAIL PROTECTED]> wrote: On Fri, Jul 25, 2008 at 6:12 PM, Nikhil <[EMAIL PROTECTED]> wrote: > I'm curious -- in a channel sounder application what benefit, if any is > there to performing the cross-correlation on the FPGA? This is assuming > you are continuously transmitting the PRBS and computing the impulse > response at the receive end at a rate that is consistent with variations in > the channel (i.e. not continuously). The channel sounder transmitter is sending the PRNG modulated BPSK at 32 Mchips/sec. You need to do the correlation at this speed; it's not possible to send that much data over the USB to the host. I was thinking that since you don't need to probe the channel at the Rx continuously as it does not change that fast, one solution would be to buffer a sequence length (~2kB for a 511 bit m-seq) and then transfer it over the USB link at a slower rate. A channel sounder in software would work for chip rates less than 4 Mchip/sec. But that limits the resolution of your impulse response to about 250 ns per bin, or 75 meters per bin in the spatial domain. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN 802.11 bbn_80211b_rx.py
But when I use one usrp for tx and another for rx, no need to specify "-d 8".
Could you tell me why is this? Thanks
Mohammad Hamed Firooz wrote:
>
> 802.11b standard use barker spreading, So if you want to receive data
> from a standard 802.11b transmitter you have to use barker. For
> decimation it should be as high as possible because 802.11b receiver
> needs more more than 22M complex sample per sec to work correctly. But
> USB cannot handle that much bit-rate so we have to downsample it to
> 8McSps. This reduces SNR which reduces receiver performance and range
> of activity.
>
> regards,
> hamed
>
> Quoting yyzhuang <[EMAIL PROTECTED]>:
>
>>
>> Thanks.
>>
>> When I use "./bbn_80211b_rx.py -f 2.44G -v -b ", no packets get printed
>> out.
>> But the output of "./bbn_80211b_rx.py -f 2.462G -d 8 -b -v " is normal,
>> we
>> got a bunch of packets:
>>
>> Bits Per Encoded Sample = 8
>> adc frequency = 6400
>> decimation frequency = 8
>> input_rate = 800
>> gain = 45.0
>> desired freq = 246200.0
>> baseband frequency 246000.0
>> dxc frequency -200.0
>> Samples per data bit = 8
> gr_fir_ccf: using SSE
>> PKT: len=77, rssi=-22, src=00:13:46:16:28:AA, time=557560, rate=1 Mbps
>> PKT: len=77, rssi=-29, src=00:13:46:16:28:AA, time=1786312, rate=1 Mbps
>> PKT: len=77, rssi=-26, src=00:13:46:16:28:AA, time=1991192, rate=1 Mbps
>> ...
>>
>> I checked the code:
>>
>> parser.add_option("-d", "--decim", type="int", default=16,
>> help="set fgpa decimation rate to DECIM
>> [default=%default]")
>> parser.add_option("-b", "--barker", action="store_true",
>> default=False,
>> help="Use Barker Spreading [default=%default]")
>>
>> -d 8 is setting the fpga decimation rate to 8, and -b means Use Barker
>> Spreading. How should we know what decimation rate and spreading to use?
>> Thanks.
>>
>> BTW, if one ursp for tx and one for rx, we dont have to specify these
>> options:
>> on the sending side: ./bbn_80211b_rx.py -f 2.44G -v -b
>> Using TX d'board A: Flex 2400 Tx MIMO B
> gr_fir_ccf: using SSE
>> spb: 8
>> interp: 32
>> (spb = samples/baud, default 8; interp = fpga interpolation rate, default
>> 32
>> )
>>
>> on the receiving side: ./bbn_80211b_tx.py -f 2.44G
>> Bits Per Encoded Sample = 8
>> adc frequency = 6400
>> decimation frequency = 16
>> input_rate = 400
>> gain = 45.0
>> desired freq = 244000.0
>> baseband frequency 243600.0
>> dxc frequency -400.0
>> Samples per data bit = 8
> gr_fir_ccf: using SSE
>> PKT: len=1477, rssi=-10, src=20:61:6e:64:20:73, time=16024824, rate=1
>> Mbps
>> PKT: len=1477, rssi=-12, src=20:61:6e:64:20:73, time=16036920, rate=1
>> Mbps
>> PKT: len=1477, rssi=-11, src=20:61:6e:64:20:73, time=16049016, rate=1
>> Mbps
>> PKT: len=1477, rssi=-13, src=20:61:6e:64:20:73, time=16061112, rate=1
>> Mbps
>>
>> Thanks!
>>
>>
>> Brian Padalino wrote:
>>>
>>> On Mon, Jul 28, 2008 at 12:28 PM, yyzhuang <[EMAIL PROTECTED]> wrote:
What does "combination of the LO in the front end and the digital
downconverter" mean please?
>>>
>>> For general radio architecture, please see:
>>>
>>> http://en.wikipedia.org/wiki/Superheterodyne
>>>
>>> Generally, the LO/synthesizer has some discrete step size (12.5kHz,
>>> 250kHz, etc). To get down to baseband, the resultant signal is then
>>> shifted in frequency down using the digital downconverter:
>>>
>>> http://en.wikipedia.org/wiki/Digital_Down_Converter
>>>
>>> Brian
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/BBN-802.11-bbn_80211b_rx.py-tp18642793p18700741.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
>>
>
>
>
> - End forwarded message -
>
>
> --
> Mohammad Hamed Firooz
> ECE Department, U of Utah
> Salt Lake City
> UT, 48112
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
View this message in context:
http://www.nabble.com/BBN-802.11-bbn_80211b_rx.py-tp18642793p18701054.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 802.11 bbn_80211b_rx.py
802.11b standard uses 11 chip barker code for spreading. It means each
bit is converted to 11 bits and for DBPSK and QBPSK modulation it leads
to a signal with 11MHz bandwidth. When you downsample data with 8 (-d
8) it means you cut the frequency to 4Mhz (instead of 11MHz) and it
means you reduce your signal strength.
BBN transmitter code doesn't use barker spreading. They use raised
cosine and its spreading factor (or gain) is less than 11. So receiver
doesn't have to cut the frequency and it works fine.
Did I get your question right?
Quoting yyzhuang <[EMAIL PROTECTED]>:
But when I use one usrp for tx and another for rx, no need to specify "-d 8".
Could you tell me why is this? Thanks
Mohammad Hamed Firooz wrote:
802.11b standard use barker spreading, So if you want to receive data
from a standard 802.11b transmitter you have to use barker. For
decimation it should be as high as possible because 802.11b receiver
needs more more than 22M complex sample per sec to work correctly. But
USB cannot handle that much bit-rate so we have to downsample it to
8McSps. This reduces SNR which reduces receiver performance and range
of activity.
regards,
hamed
Quoting yyzhuang <[EMAIL PROTECTED]>:
Thanks.
When I use "./bbn_80211b_rx.py -f 2.44G -v -b ", no packets get printed
out.
But the output of "./bbn_80211b_rx.py -f 2.462G -d 8 -b -v " is normal,
we
got a bunch of packets:
Bits Per Encoded Sample = 8
adc frequency = 6400
decimation frequency = 8
input_rate = 800
gain = 45.0
desired freq = 246200.0
baseband frequency 246000.0
dxc frequency -200.0
Samples per data bit = 8
gr_fir_ccf: using SSE
PKT: len=77, rssi=-22, src=00:13:46:16:28:AA, time=557560, rate=1 Mbps
PKT: len=77, rssi=-29, src=00:13:46:16:28:AA, time=1786312, rate=1 Mbps
PKT: len=77, rssi=-26, src=00:13:46:16:28:AA, time=1991192, rate=1 Mbps
...
I checked the code:
parser.add_option("-d", "--decim", type="int", default=16,
help="set fgpa decimation rate to DECIM
[default=%default]")
parser.add_option("-b", "--barker", action="store_true",
default=False,
help="Use Barker Spreading [default=%default]")
-d 8 is setting the fpga decimation rate to 8, and -b means Use Barker
Spreading. How should we know what decimation rate and spreading to use?
Thanks.
BTW, if one ursp for tx and one for rx, we dont have to specify these
options:
on the sending side: ./bbn_80211b_rx.py -f 2.44G -v -b
Using TX d'board A: Flex 2400 Tx MIMO B
gr_fir_ccf: using SSE
spb: 8
interp: 32
(spb = samples/baud, default 8; interp = fpga interpolation rate, default
32
)
on the receiving side: ./bbn_80211b_tx.py -f 2.44G
Bits Per Encoded Sample = 8
adc frequency = 6400
decimation frequency = 16
input_rate = 400
gain = 45.0
desired freq = 244000.0
baseband frequency 243600.0
dxc frequency -400.0
Samples per data bit = 8
gr_fir_ccf: using SSE
PKT: len=1477, rssi=-10, src=20:61:6e:64:20:73, time=16024824, rate=1
Mbps
PKT: len=1477, rssi=-12, src=20:61:6e:64:20:73, time=16036920, rate=1
Mbps
PKT: len=1477, rssi=-11, src=20:61:6e:64:20:73, time=16049016, rate=1
Mbps
PKT: len=1477, rssi=-13, src=20:61:6e:64:20:73, time=16061112, rate=1
Mbps
Thanks!
Brian Padalino wrote:
On Mon, Jul 28, 2008 at 12:28 PM, yyzhuang <[EMAIL PROTECTED]> wrote:
What does "combination of the LO in the front end and the digital
downconverter" mean please?
For general radio architecture, please see:
http://en.wikipedia.org/wiki/Superheterodyne
Generally, the LO/synthesizer has some discrete step size (12.5kHz,
250kHz, etc). To get down to baseband, the resultant signal is then
shifted in frequency down using the digital downconverter:
http://en.wikipedia.org/wiki/Digital_Down_Converter
Brian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
View this message in context:
http://www.nabble.com/BBN-802.11-bbn_80211b_rx.py-tp18642793p18700741.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
- End forwarded message -
--
Mohammad Hamed Firooz
ECE Department, U of Utah
Salt Lake City
UT, 48112
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
View this message in context:
http://www.nabble.com/BBN-802.11-bbn_80211b_rx.py-tp18642793p18701054.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
--
Mohammad Hamed Firooz
ECE Department, U of
Re: [Discuss-gnuradio] BBN 802.11 bbn_80211b_rx.py
Yes!
"The problem we are overcoming is the USB data rate bottleneck, which is
limited to 32 MBps. Although this bit rate is high enough for many
applications of gnuradio, for an 802.11b receiver it is not sufficient,
because of the signal's bandwidth. The RF bandwidth of an 802.11b signal is
11 MHz. The minimum possible sampling rate (due to the Nyquist sampling
criteria) is 22 Msamples/sec. Assuming a resolution of 8 bits for each I and
Q sample, we require 2*22M = 44 MBps through the USB, which is clearly over
the limit. Because of these limits, the current gnuradio receiver
implementation of 802.11b (credit to BBN) reduced the signal bandwidth to 4
MHz prior to sending it through the USB. Effectively, the sub-sampled signal
arrives at the PC with very low SNR. Typically, 802.11b packets transmitted
at the 1 Mbps rate can be received, but only at short range."
This is why the output of the script is all 1Mbps.
If we modify the script a bit, can we tune gnuradio to an 802.11b channel
and pick up all available access points (and their 1 mbps comm with wireless
clients)? Do we have 802.11g implementation right now?
Thanks a lot for help
Mohammad Hamed Firooz wrote:
>
> 802.11b standard uses 11 chip barker code for spreading. It means each
> bit is converted to 11 bits and for DBPSK and QBPSK modulation it leads
> to a signal with 11MHz bandwidth. When you downsample data with 8 (-d
> 8) it means you cut the frequency to 4Mhz (instead of 11MHz) and it
> means you reduce your signal strength.
>
> BBN transmitter code doesn't use barker spreading. They use raised
> cosine and its spreading factor (or gain) is less than 11. So receiver
> doesn't have to cut the frequency and it works fine.
>
> Did I get your question right?
>
> Quoting yyzhuang <[EMAIL PROTECTED]>:
>
>>
>> But when I use one usrp for tx and another for rx, no need to specify "-d
>> 8".
>> Could you tell me why is this? Thanks
>>
>>
>> Mohammad Hamed Firooz wrote:
>>>
>>> 802.11b standard use barker spreading, So if you want to receive data
>>> from a standard 802.11b transmitter you have to use barker. For
>>> decimation it should be as high as possible because 802.11b receiver
>>> needs more more than 22M complex sample per sec to work correctly. But
>>> USB cannot handle that much bit-rate so we have to downsample it to
>>> 8McSps. This reduces SNR which reduces receiver performance and range
>>> of activity.
>>>
>>> regards,
>>> hamed
>>>
>>> Quoting yyzhuang <[EMAIL PROTECTED]>:
>>>
Thanks.
When I use "./bbn_80211b_rx.py -f 2.44G -v -b ", no packets get printed
out.
But the output of "./bbn_80211b_rx.py -f 2.462G -d 8 -b -v " is normal,
we
got a bunch of packets:
Bits Per Encoded Sample = 8
adc frequency = 6400
decimation frequency = 8
input_rate = 800
gain = 45.0
desired freq = 246200.0
baseband frequency 246000.0
dxc frequency -200.0
Samples per data bit = 8
>>> gr_fir_ccf: using SSE
PKT: len=77, rssi=-22, src=00:13:46:16:28:AA, time=557560, rate=1 Mbps
PKT: len=77, rssi=-29, src=00:13:46:16:28:AA, time=1786312, rate=1 Mbps
PKT: len=77, rssi=-26, src=00:13:46:16:28:AA, time=1991192, rate=1 Mbps
...
I checked the code:
parser.add_option("-d", "--decim", type="int", default=16,
help="set fgpa decimation rate to DECIM
[default=%default]")
parser.add_option("-b", "--barker", action="store_true",
default=False,
help="Use Barker Spreading
[default=%default]")
-d 8 is setting the fpga decimation rate to 8, and -b means Use Barker
Spreading. How should we know what decimation rate and spreading to
use?
Thanks.
BTW, if one ursp for tx and one for rx, we dont have to specify these
options:
on the sending side: ./bbn_80211b_rx.py -f 2.44G -v -b
Using TX d'board A: Flex 2400 Tx MIMO B
>>> gr_fir_ccf: using SSE
spb: 8
interp: 32
(spb = samples/baud, default 8; interp = fpga interpolation rate,
default
32
)
on the receiving side: ./bbn_80211b_tx.py -f 2.44G
Bits Per Encoded Sample = 8
adc frequency = 6400
decimation frequency = 16
input_rate = 400
gain = 45.0
desired freq = 244000.0
baseband frequency 243600.0
dxc frequency -400.0
Samples per data bit = 8
>>> gr_fir_ccf: using SSE
PKT: len=1477, rssi=-10, src=20:61:6e:64:20:73, time=16024824, rate=1
Mbps
PKT: len=1477, rssi=-12, src=20:61:6e:64:20:73, time=16036920, rate=1
Mbps
PKT: len=1477, rssi=-11, src=20:61:6e:64:20:73, time=16049016, rate=1
Mbps
PKT: len=1477, rssi=-13, src=20:61:6e:64:20:73, time=16061112, rate=1
Mbps
Thanks!
Brian Padalino wrote:
>
> On Mon, Jul 2
Re: [Discuss-gnuradio] USRP Problems with decim_rate = 4
Hi, You can use USRP with decim_rate = 4 only if you use FPGA image std_4rx_0tx.rbf (no half band filter). See: http://gnuradio.org/trac/wiki/UsrpFAQ/DDC Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flipping problem
isaacgerg wrote: I am sending a known sequence of samples from one USRP to another using the Basix RX/TX d'boards setting the frequency to 24e6. When I rx the sequence, the correlation of it keeps flipping, but not in a way that suggests residual carrier. It seems as if I am experiencing an instantaneous flip. My gain on both the RX and TX is set to 500. The signal amplitude I rx is ~1200. When I run the GRC model, the Rx says I have no residual carrier, invert is set to false, the dxc frequency is set to -24e6 and the baseband to zero. On the TX side, I have these same values with the exception of the dxc freq, it is not set to 24e6. Why the flip?? What do all these things mean??? Is 24e6 a bad freq to use with the basic TX/Rx? Thanks in advance! I believe what you are seeing here is that the two USRPs are on two different frequencies. This is not a fault of the USRP. No two oscillators will be on exactly the same frequency, and so in any practical receiver you must synchronize. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
