Re: [Discuss-gnuradio] RFX 900 200mW
Vincenzo Pellegrini wrote: Hi everybody, just a simple question: does the RFX900 provide 200mW just out of the box? Do I have to take care of something in particular in order to obtain them? Actually, what are the appropriate gain values that I should pass to subdev.set_gain() n order to maximize correctly the output power? Sorry for bthering the list with such questions but I was unable to have them answered in the RFX900 section of the wiki.. maybe I'll add them myself once I'll have fully understood the issue.. That is a saturated power level. For any linear signal you will need to back off a bit. In any case, you control the output power by controlling the amplitude of the signal you send to the USRP. +/-32767 will be the max power but will result in RF clipping. You will need to find the max power you can get with your particular signal and still maintain enough linearity. If you need a dB or 2 more, you can bypass the ISM band filter with a cap of about 100pF and then cut the traces to the filter. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] New Book on GNU Radio
Just came across this while surfing around... http://www.mhprofessional.com/product.php?isbn=0071498834 ___ 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
> "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 not true. Remember when you have complex samples the sample rate IS the bandwidth. So 802.11b can be covered with 11 Msps 8-bit I and Q or 22 MByte/s. So in 8-bit mode the 16 Msps standard USRP configuration can capture the signal. I had done this previously though I modified my oscillator to be 44 MHz instead of 64 MHz because (a) the 4x symbol rate interpolation was easier and (b) to ease the datarate over the USB. I was able to demodulate all the 802.11b modes including the 11 mbps packets. -Clark _ Stay in touch when you're away with Windows Live Messenger. http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_messenger2_072008 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flipping problem
If this is true, why is it that the residual carrier is reported as zero? Are you suggesting that this value is not correct? Isaac Matt Ettus wrote: > > 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 > > -- View this message in context: http://www.nabble.com/Flipping-problem-tp18614309p18711285.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] Flipping problem
On Tue, Jul 29, 2008 at 8:42 AM, isaacgerg <[EMAIL PROTECTED]> wrote: > > If this is true, why is it that the residual carrier is reported as zero? > Are you suggesting that this value is not correct? I think all Matt is saying is that the two receivers are working off of different local oscillators which cause a frequency offset causing your correlation phasor to spin around. Chances are if you plot phase of the correlation over time along with the magnitude over time, you will see the magnitude doesn't get smaller and the phase should smoothly rotate around at the rate which your frequencies are off. Does that make sense? Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flipping problem
On Tue, Jul 29, 2008 at 5:42 AM, isaacgerg <[EMAIL PROTECTED]> wrote: > If this is true, why is it that the residual carrier is reported as zero? > Are you suggesting that this value is not correct? What GRC is reporting as "residual carrier" is not what you seem to think it is. It refers to how close the software was able to tune the USRP to your requested frequency. Usually this is in the millihertz range, or zero, which is what you are seeing. However, the tuning calculation assumes the USRP clock is exactly 64 MHz, which it never is. Each USRP clock will be slightly different in frequency, depending on manufacturing tolerances, temperature, age, and other factors. That is why it is rated at 20 ppm (parts per million), which means the actual frequency can be anywhere from -20 ppm to +20 ppm away from 64 MHz, or +-1280 Hz. At 24 MHz center frequency, the USRP/BasicRX can actually be tuned to +-480 Hz around that frequency. And it's not even fixed; it will still drift within this range, primarily due to thermal transients. This difference from exactly 24 MHz is *not* what the "residual carrier" term is reporting, and there is no way for the software to "know" what this offset is. So even if two USRPs are tuned to what they each think is 24 MHz, and their tune functions report a "residual carrier" of 0, one will be receiving at a slightly different frequency that the other is transmitting, perhaps even a a kilohertz away (2*480 Hz). As many have mentioned, this will cause your received data to rotate in phase at the difference in frequency, resulting in "flipped bits". (The effect is dependent on which type of modulation you are using, however.) Thus, your USRP is working, and 24 MHz is an okay frequency to tune the BasicRx. You just haven't implemented any receiver synchronization in your software. -- 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] Basic RX. - usrp_wfm_rcv.py
Hello, I've started again from the begining. I have installed Ubuntu 7.1, not in a virtual machine. In a Pentium IV, 3 GHz, with 2 GBytes of RAM. I have done all this steps - http://gnuradio.org/trac/wiki/DebianPackages - . I run the dial_tone.py and it sounds ok, so I suppose that GNU Radio is installed ok. Then I run " ./usrp_wfm_rcv_nogui.py -f 40M -O plughw:0,0" and it's sounds with noise, but I think this is because of the antenna. When I try to run "./usrp_wfm_rcv.py -f 102.4M -O plughw:0,0" I get this: *Traceback (most recent call last): File "./usrp_wfm_rcv.py", line 290, in app = stdgui2.stdapp (wfm_rx_block, "USRP WFM RX") File "/usr/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 36, in __init__ wx.App.__init__ (self, redirect=False) File "/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode/wx/_core.py", line 7700, in __init__ self._BootstrapApp() File "/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode/wx/_core.py", line 7352, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) SystemError: wxEntryStart failed, unable to initialize wxWidgets! (Is DISPLAY set properly?) Fallo de segmentación (core dumped) *I have been reading other forums, but I don't know how to solve it. I know that it's something wxWidgets, but ... Thanks ___ 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
On Tue, Jul 29, 2008 at 11:01 AM, rita pfc <[EMAIL PROTECTED]> wrote: > Hello, > I've started again from the begining. I have installed Ubuntu 7.1, not in a > virtual machine. In a Pentium IV, 3 GHz, with 2 GBytes of RAM. I have done > all this steps - http://gnuradio.org/trac/wiki/DebianPackages - . I run the > dial_tone.py and it sounds ok, so I suppose that GNU Radio is installed ok. > Then I run " ./usrp_wfm_rcv_nogui.py -f 40M -O plughw:0,0" and it's sounds > with noise, but I think this is because of the antenna. When I try to run > "./usrp_wfm_rcv.py -f 102.4M -O plughw:0,0" I get this: > Traceback (most recent call last): > File "./usrp_wfm_rcv.py", line 290, in > app = stdgui2.stdapp (wfm_rx_block, "USRP WFM RX") > File "/usr/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line > 36, in __init__ > wx.App.__init__ (self, redirect=False) > File "/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode/wx/_core.py", > line 7700, in __init__ > self._BootstrapApp() > File "/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode/wx/_core.py", > line 7352, in _BootstrapApp > return _core_.PyApp__BootstrapApp(*args, **kwargs) > SystemError: wxEntryStart failed, unable to initialize wxWidgets! (Is > DISPLAY set properly?) > Fallo de segmentación (core dumped) I hate to just repeat the error, but is DISPLAY set properly? You can check this by typing echo $DISPLAY. If you don't see something like localhost:0.0, then I don't think it is set properly. It appears as if the software is unable to find your X-server. Are you running X locally? Can you run other X programs from the same terminal? Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Flipping problem
I agree with this analysis unless Isaac tells us he has a carrier and baud synchronizer in his system. If he is looking at raw output from the USRP, indeed the two oscillators (as they would in any real system) shift frequency over time and drift in and out of any phase relationship. Bob ARRL SDR Working Group Chair Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. "Trample the slow Hurdle the dead" -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Ettus Sent: Tuesday, July 29, 2008 2:40 AM To: isaacgerg Cc: Discuss-gnuradio@gnu.org Subject: 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Channel measurements?
On Mon, Jul 28, 2008 at 6:14 PM, Mohammad Hamed Firooz <[EMAIL PROTECTED]>wrote: > > 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. > That's correct Hamed. I don't disagree with what you just wrote. By "consistent with variations in the channel" in the message prior to the last one, I was implying at a meaningful rate. So probing an indoor channel 1000 times a second at peak people-traffic times is more than adequate. And between successive "probes" you have enough time to transfer the captured sequence over the USB at a slower rate than the max. sampling rate of 64 MSamples per second in the Rx. But this assumes you can store about 2kB of data on the FPGA. Nikhil > 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 > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RFX 900 200mW
Thanks Matt! really precious answer.. actually, transmitting an 8 MHz wide signal at 820MHz without bypassing the ISM filter.. what kind of attenuation should I expect? ..I mean.. just a rough estimate of its magnitude.. thanks vincenzo On Tue, 2008-07-29 at 00:06 -0700, Matt Ettus wrote: > Vincenzo Pellegrini wrote: > > > > Hi everybody, > > just a simple question: > > does the RFX900 provide 200mW just out of the box? Do I have to take > > care of something in particular in order to obtain them? > > > > Actually, what are the appropriate gain values that I should pass to > > subdev.set_gain() n order to maximize correctly the output power? > > > > Sorry for bthering the list with such questions but I was unable to > > have them answered in the RFX900 section of the wiki.. maybe I'll add > > them myself once I'll have fully understood the issue.. > > > That is a saturated power level. For any linear signal you will need to > back off a bit. In any case, you control the output power by > controlling the amplitude of the signal you send to the USRP. +/-32767 > will be the max power but will result in RF clipping. You will need to > find the max power you can get with your particular signal and still > maintain enough linearity. If you need a dB or 2 more, you can bypass > the ISM band filter with a cap of about 100pF and then cut the traces to > the filter. > > Matt > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question on OFDM
Hi All, I am trying to do a multi-carrier transmission. I went through the benchmark_ofdm_tx.py and benchmark_ofdm_rx.py files. How can I set the specific subcarrier? Say, -d 32 --fft-length=512 --occupied-tones=200. What I understand is that a 2M bandwidth is divided into 512 subcarriers, and 200 subcarriers are used. How are these 200 used subcarriers allocated? How I should do if I only want to use the first and the last subcarrier or other specific subcarrier? Thanks, Brook Lin -- View this message in context: http://www.nabble.com/Question-on-OFDM-tp18718309p18718309.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] modelsim help using megacells
Hi all, I am having trouble running a testbench in ModelSim which uses megacells. I added megacells such as fifo_4kx16_dc.v and fifo_1kx16.v, but when trying to simulate I get errors such as: Error: (vsim-3033) Z:/gnychis/fpga/usrp/fpga/megacells/fifo_4kx16_dc.v(89): Instantiation of 'dcfifo' failed. The design unit was not found. I can find dcfifo in the altera_mf library, and it builds just fine. I'm not sure how linking goes in ModelSim? I added altera_mf to my search and still get an error: # ** Error: (vsim-3033) Z:/gnychis/fpga/usrp/fpga/megacells/fifo_4kx16_dc.v(89): Instantiation of 'dcfifo' failed. The design unit was not found. # Region: /tb_timestamps/rx_buffer/rx_usb_fifo # Searched libraries: # C:/altera/72sp2/quartus/eda/sim_lib/altera_mf # work I'd greatly appreciate any help. Thanks! George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] modelsim help using megacells
George Nychis wrote: Hi all, I am having trouble running a testbench in ModelSim which uses megacells. I added megacells such as fifo_4kx16_dc.v and fifo_1kx16.v, but when trying to simulate I get errors such as: Error: (vsim-3033) Z:/gnychis/fpga/usrp/fpga/megacells/fifo_4kx16_dc.v(89): Instantiation of 'dcfifo' failed. The design unit was not found. I can find dcfifo in the altera_mf library, and it builds just fine. I'm not sure how linking goes in ModelSim? I added altera_mf to my search and still get an error: # ** Error: (vsim-3033) Z:/gnychis/fpga/usrp/fpga/megacells/fifo_4kx16_dc.v(89): Instantiation of 'dcfifo' failed. The design unit was not found. # Region: /tb_timestamps/rx_buffer/rx_usb_fifo # Searched libraries: # C:/altera/72sp2/quartus/eda/sim_lib/altera_mf # work I'd greatly appreciate any help. I think I survived with: vsim -L altera_mf work.tb_timestamps Thanks! George ___ 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
Brian Padalino wrote am 2008-07-29 17:07: On Tue, Jul 29, 2008 at 11:01 AM, rita pfc <[EMAIL PROTECTED]> wrote: Hello, I've started again from the begining. I have installed Ubuntu 7.1, not in a virtual machine. In a Pentium IV, 3 GHz, with 2 GBytes of RAM. Much better, we do not support VMware. SystemError: wxEntryStart failed, unable to initialize wxWidgets! (Is DISPLAY set properly?) Fallo de segmentación (core dumped) I hate to just repeat the error, but is DISPLAY set properly? Did you use sudo? sudo sometimes has problems to get the X settings like DISPLAY and authority right. If you are not really know what certain commands do, quote it in your messages. Even subtle or innocent looking things can be important for your problem, so tell us as much and as exact as possible what you did. Otherwise we are not able to reproduce the problem and find the missing or wrong part. 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] bbn_80211b_rx.py: how is the received packet handled please?
Hello,
In the BBN 802.11 package, I see the scripts for receiver, and some lines of
code for packet handling as well.
==
def rx_callback(ok, payload):
size = struct.calcsize("@qHBB");
packet_data = payload[size:];
hdr = struct.unpack("@qHbB", payload[0:size]);
if len(packet_data) > 16:
data_hdr = struct.unpack("@BB", packet_data[10:16])
mac_str = "%02x:%02x:%02x:%02x:%02X:%02X" % \
(data_hdr[0], data_hdr[1], data_hdr[2],
data_hdr[3], data_hdr[4], data_hdr[5],)
else:
mac_str = "UNKNOWN"
print "PKT: len=%d, rssi=%d, src=%s, time=%ld, rate=%d Mbps" \
% (hdr[1], hdr[2], mac_str, hdr[0], hdr[3]/ 10.0)
===
What does the struct.unpack do? Is it for formatting the packet for display?
coz when I tried to do this: print "payload: %s" % payload, what got
displayed on the screen is like this:
payload: �,Q
���F(�F(�p��j{Yd!
䀹
0H
*2$`l�
And what exactly the "time" is? As I see in the script, is it in ticks?
means the time instance, or the inter-arrival time?
--
View this message in context:
http://www.nabble.com/bbn_80211b_rx.py%3A-how-is-the-received-packet-handled-please--tp18720769p18720769.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bbn_80211b_rx.py: how is the received packet handled please?
Inlined responses:
Quoting yyzhuang <[EMAIL PROTECTED]>:
Hello,
Hi,
In the BBN 802.11 package, I see the scripts for receiver, and some lines of
code for packet handling as well.
==
def rx_callback(ok, payload):
size = struct.calcsize("@qHBB");
packet_data = payload[size:];
hdr = struct.unpack("@qHbB", payload[0:size]);
if len(packet_data) > 16:
data_hdr = struct.unpack("@BB", packet_data[10:16])
What does the struct.unpack do? Is it for formatting the packet for display?
Pretty much -- though it does more than that as well.
http://docs.python.org/lib/module-struct.html
struct.unpack() is also used by the mainline gnuradio code (see
gnuradio-examples/python/(digital|ofdm)/benchmark_* for instance).
coz when I tried to do this: print "payload: %s" % payload, what got
displayed on the screen is like this:
payload:
That's because the 'payload' string isn't ascii- or unicode-formatted;
it's raw binary data packed into a string because that's how python
handles things that would be stored in a c struct.
If you unpack it with an appropriate format string, you can display
the actual data received. (something close to but less ugly than
struct.unpack('!' + `len(payload)` + 'B',payload)
depending on what you want to see.)
And what exactly the "time" is? As I see in the script, is it in ticks?
means the time instance, or the inter-arrival time?
I'll defer to someone who's familiar with the BBN code.
--Mason
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] What's wrong with this constellation?
Howdy list, My partner and I have been working on getting a QAM demodulator working on the gnuradio; the current patch, with lots of debugging spew still present, is located at http://www.cae.wisc.edu/~masond/gr-qam-patch-rev7.diff . The current problem: When the constellation 'locks', it looks like the following: http://www.cae.wisc.edu/~masond/figure3.png (for qam16) http://www.cae.wisc.edu/~masond/figure4.png http://www.cae.wisc.edu/~masond/figure4.png (for qam8) The red Xes are the true constellation points, and the black dots are the output of the receiver. The amplitude of the receiver output seems to spray out pretty widely from the constellation point intended. Any ideas what could be causing this amplitude distortion? I've tried increasing the number of stages in the feedforward AGC to 40 or 60 (as many as my receiver can bear without underruns) and it doesn't seem to impact it. The amplitude noise is present with a variety of mus and costas alphas (the ones used in those figures were alpha~.015 and gain-mu~.05-.075). I've also tried with several different --tx-amplitudes to see if it was a matter of some clipping or other artifact to no luck. I know that for digital radio purposes the constellation doesn't have to be perfect, but rather 'good enough', so I would be inclined to let this go except for point 2: --The receiver frequently cycle-slips, with the longest string of un-slipped packets somewhere in the 2000 range on our USRPs. I think that this is being hurt by the amplitude noise pushing received points into neighboring constellation points and causing the receiver to correct for that. I'm running out of ideas (I've tried only using the corner points as the patch does, using all points with weighting based on distance, weighting only the costas loop portion, weighting only the m&m timing portion...) and could use some suggestions or obvious things I may have overlooked. --Mason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bbn_80211b_rx.py: how is the received packet handled please?
At 04:33 PM 7/29/2008, yyzhuang wrote: And what exactly the "time" is? As I see in the script, is it in ticks? means the time instance, or the inter-arrival time? "time" is a packet arrival timestamp, in microseconds, relative to the time the receiver is started. It is calculated by counting received samples so it based off a clock in the USRP, not a clock in the PC. By comparing the timestamps of two received packets you should be able to determine difference in actual arrival times to with a couple microseconds. -Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bbn_80211b_rx.py: how is the received packet handled please?
Quoting "Y. Zhuang" <[EMAIL PROTECTED]>: Thanks very much for help. So "@qHBB" and "@qHbB" actually mean the format that we should unpack this string, right? What is the differences between "@qHBB" and "@qHbB" then? and "@BB"? Thank you Yes. Basically, to summarize the python doc I linked, if you have binary data stored in a string you want to decode, each character in the python format string corresponds to one or more of the bytes in it (with the exception of the @ at the beginning. @ tells the byte order and alignment to use -- the system default in this case). Then q would be a long long, H an unsigned short, and B being an unsigned char. Also, @BB can be written as @6B, and you can construct the formatting strings dynamically if needed (if transmitting a variable length packet). The difference between qHbB and qHBB is that the lowercase b in the middle is signed and the capital B is unsigned. (i.e. is the number stored in two's-complement.) Of course, what that means for the code is up to the coder. --Mason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bbn_80211b_rx.py: how is the received packet handled please?
Thanks. I think it should be something from the 802.11 frame over the wireless link. Since I see the time and other stuff are got from the packet, could you tell me how is the packet received from usrp (by sampling in the usrp?), what is its format? and for how we can actually do with it, is unpack the packet according to its format enough? Thanks again Daniel Sumorok wrote: > > At 04:33 PM 7/29/2008, yyzhuang wrote: > >>And what exactly the "time" is? As I see in the script, is it in ticks? >>means the time instance, or the inter-arrival time? > > "time" is a packet arrival timestamp, in microseconds, relative to the > time > the receiver is started. It is calculated by counting received samples so > it based off a clock in the USRP, not a clock in the PC. By comparing the > timestamps of two received packets you should be able to determine > difference in actual arrival times to with a couple microseconds. > > -Dan > > > > ___ > 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_80211b_rx.py%3A-how-is-the-received-packet-handled-please--tp18720769p18724383.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bbn_80211b_rx.py: how is the received packet handled please?
That's the point. But to unpack a packet, we have to know exactly its format. Hope someone can tell what format of the packet is. And what information can we get from the packets. Thanks everybody =^D Mason-29 wrote: > > Quoting "Y. Zhuang" <[EMAIL PROTECTED]>: > >> Thanks very much for help. So "@qHBB" and "@qHbB" actually mean the >> format that we should unpack this string, right? What is the >> differences between "@qHBB" and "@qHbB" then? and "@BB"? >> >> Thank you >> > > Yes. Basically, to summarize the python doc I linked, if you have > binary data stored in a string you want to decode, each character in > the python format string corresponds to one or more of the bytes in it > (with the exception of the @ at the beginning. @ tells the byte order > and alignment to use -- the system default in this case). Then q would > be a long long, H an unsigned short, and B being an unsigned char. > Also, @BB can be written as @6B, and you can construct the > formatting strings dynamically if needed (if transmitting a variable > length packet). > > The difference between qHbB and qHBB is that the lowercase b in > the middle is signed and the capital B is unsigned. (i.e. is the > number stored in two's-complement.) Of course, what that means for the > code is up to the coder. > > --Mason > > > > > ___ > 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_80211b_rx.py%3A-how-is-the-received-packet-handled-please--tp18720769p18724417.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bbn_80211b_rx.py: how is the received packet handled please?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 29, 2008, at 6:14 PM, yyzhuang wrote: That's the point. But to unpack a packet, we have to know exactly its format. Hope someone can tell what format of the packet is. And what information can we get from the packets. The 802.11 packet format is non-trivial. You'll want to look at the spec for that. It's available for free download @ http://standards.ieee.org/getieee802/ If I had one piece of advice, it would be "be careful of endianness" - -Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkiPwhoACgkQy9GYuuMoUJ7wbACfUJsoUULKhZWR0oe8tL7y4aPQ m5cAoLsdscdjvGVao6OHUMEkaE908QgB =FQ73 -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RFX 900 200mW
Vincenzo wrote: Thanks Matt! really precious answer.. actually, transmitting an 8 MHz wide signal at 820MHz without bypassing the ISM filter.. what kind of attenuation should I expect? ..I mean.. just a rough estimate of its magnitude.. What I meant was that if you are working WITHIN the ISM band (902-928 MHz) you could get a couple extra dB by bypassing the filter. If you are outside of the band, you MUST bypass it. You could be getting as much as 30 dB off attenuation there. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What's wrong with this constellation?
Hi Mason, ... The amplitude of the receiver output seems to spray out pretty widely from the constellation point intended. It could be an AGC issue---is the AGC time constant long compared with a symbol? Is the distribution of constellation points uniform (each is picked with equal probability)? One thing you could try, if the channel permits, is to temporarily hold the AGC fixed to see if that gives a better constellation (perhaps at the wrong size; or if you're using decision feedback, try to get it to the right size :-) ). Cheers, Peter Monta ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] decimate by less than 8 in standard FPGA of USRP
Hi, 1) Just use USRP FPGA file (firmware) that contains no halfband filter as in the following example: decim = 4 set_fpga_filename="std_4rx_0tx.rbf" # This FPGA firmware contains 4 Rx paths without halfbands and 0 tx paths. u = usrp.source_c(0, decim_rate=decim, fpga_filename=set_fpga_filename) 2) See: usrp_fft.py Note: In this case (decimation by 4), you must use 8 bit data format (see the option -8 in usrp_fft.py) to avoid saturating the USB bus. Firas -- View this message in context: http://www.nabble.com/decimate-by-less-than-8-in-standard-FPGA-of-USRP-tp18718542p18726094.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
