Re: [Discuss-gnuradio] USRP1 cannot transmit/receive a OFDM packet discontinuously sometimes
Hi Tom,
Thanks for your suggestion. I will take your advice and try it out.
But recently I connect two USRP1 with the cable not through the antennas,
hoping to remove the channel effect in this experiment. At the receiver,
using the usrp_fft.py to observe the spectrum of received signal which is
discontinuously transmitted from transmitter. The result shows that
sometimes the spectrum doesn't get rise when transmitter send a packet.Is it
possible that the transmitted packet doesn't transmit from USRP1? If
possible, how do I examine this problem?
Sorry, I'm not very expert in hardware implementation, but I will do my best
to get familiar with USRP.
Fisheep
Tom Rondeau wrote:
On Tue, Sep 14, 2010 at 12:52 AM, Fisheep fisheep0...@gmail.com wrote:
Hi,
My problem is that I try to discontinuously send a OFDM packet by using
time.sleep() on USRP1, but fail to successfully receive this OFDM packet
at
the receiver sometimes.
Brief Setting Description:
Code : gnuradio-example/python/ofdm/benchmark_ofdm_tx{rx}.py
Daughterboard : FLEX900
OS : Ubuntu 8.10
Tx :
send_pkt(data) - time.sleep(1) - send_pkt(data) - time.sleep(1) -
...
Rx :
ok = False , pktno = 65537,
ok = True , pktno = 1 ,
...
I have surveyed about this discussion on the forum. Using discontinuous
transmission is to ensure the transmitter successly sending a packet and
receiver will receive this packet. And I try this scheme on single
carrier
case like benchmark_tx{rx}.py on digital file, every packet is successful
receive at receiver. But when changing to OFDM, not every packet is
successful receive.
Is it that fft consumes lots of time and causes the transmitter doesn't
send
this packet?
I think this is the main different between single carrier and OFDM.
If anyone have any idea about this problem, please let me know.
I am deeply appreciative.
Fisheep
Fisheep,
I don't think anyone has actually tried doing this. I know when Matt
and I put the system together, we were concerned only with the
continuous case. We have some improvements to the OFDM pieces that are
on my todo list, though, and once the continuous case is finished,
we'll work on the discontinuous. Until then, though, I'm afraid the
only advice I could give would be completely speculative.
My first thought would be to see how the synchronization is behaving;
that's almost certainly where the problem is. We have the
gr_plot_ofdm.py script that helps to visualize what's happening with
the received symbols (you'll need to turn logging on and have scipy
and matplotlib installed). Play with that in loopback mode to
understand what you're seeing, then see what happens with your
over-the-air tests.
If you figure out ways to make it better, I'd love to hear it!
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
View this message in context:
http://old.nabble.com/USRP1-cannot-transmit-receive-a-OFDM-packet-discontinuously-sometimes-tp29705204p29715560.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] want to achieve the symbol rate to 270.833kb/s
hi all: I want to make the symbol rate of the data which is transmited by the USRP at the 270.833kb/s.I know the OpenBTS had already make it come true. but what I want to know is that can I use the resampler block to make this happen? (put the resampler block after the GMSK Mod block )and the value of the interpolation and decimation of the resampler block can be the same as them in the OpenBTS which are 65 and 96.and the interpolation of the USRP is 320 which is make the sample rate of the usrp is 400k.I have not do it now ,just want to ask here if it is possible. Thank you in advence ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio via MacPorts Updated
i compiled from scratch wxWidgets 2.9.1, but python is still using mac's 2.8 version. How do i tell python to use the locally installed version? --- On Wed, 9/15/10, Elvis Dowson elvis.dow...@mac.com wrote: From: Elvis Dowson elvis.dow...@mac.com Subject: Re: [Discuss-gnuradio] GNU Radio via MacPorts Updated To: discuss-gnuradio Discussion Group discuss-gnuradio@gnu.org Date: Wednesday, September 15, 2010, 2:54 AM Hi Michael, On Sep 15, 2010, at 1:12 AM, Michael Dickens wrote: Hi Dave - We're just discussing this issue (32-bit execution) on the MacPorts' lists. The quick end-result is: With the current MacPorts' provided python2.6 or older, the PREFER_32_BIT stuff does not work because 'python' is actually just a wrapper around 'exec' and the bit-preferences are no passed through. Apple's python2.6 -does- work, as does python2.7 and newer, because this command was moved to posix_spawn; see http://www.opensource.apple.com/source/python/python-44.1/2.6/ for the source code and changes Apple made (somewhere in there). I can confirm that apple's default python-2.6 works in 32-bit mode. As to your actual error when running usrp_fft.py: Apparently WX is not installed as 64-bit. I haven't gotten this far in my testing (lots on my queue already), but my memory is that this has been an issue for a -long- time still isn't resolved. I don't remember the exact root cause any longer. For the wxWidgets/wxPython issue, here's what I've found out so far: a. wxWidgets/wxPython 2.9.2 and higher builds and works under cocoa 64-bits. I've tested the non-OpenGL vesions of the widgets in gr-wxgui, and that appears to be working. However, for the OpenGL versions of these widgets, there are some breaking API changes between wxWidgets 2.8.x and 2.9.x. The changes are documented in the wxWidgets OpenGL cube example. b. Robin Dunn provides a synchronized release of his sources for wxWidgets/wxPython 2.9.x, since we usually have the problem of version mismatches, and re-swigging. You can find a link to the download in this discussion thread: http://groups.google.com/group/wxPython-dev/browse_thread/thread/dd7ff9dfb5d99686?pli=1 c. Under Mac OS X 10.6.4, you already have an installation of wxWidgets 2.8.8.1 $ export VERSIONER_PYTHON_PREFER_32_BIT=yes $ python Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type help, copyright, credits or license for more information. import wx wx.VERSION_STRING '2.8.8.1' exit() At the moment, I'm slowly building all the dependent libraries for i386 and x86_64 architectures, and bring it up to the wxWidgets/wxPython dependencies. This way, I can simultaneously try a couple of permutations/combinations with say wxWidgets/wxPython 2.8.x and Carbon/32-bits and GNU Radio at 32-bits, or if I solve the OpenGL context issue, wxWidgets/wxPython 2.9.x Cocoa/64-bits and GNU Radio at 64-bits. Best regards, Elvis ___ 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] GNU Radio via MacPorts Updated
HI Dave,
Just some info, not directly related but useful to keep in
mind... wxPython and wxWidgets 2.8.1.1 is already installed on Mac OS X 10.6.4.
However, for some reason the GNU Radio configure process is not able to detect
the wxPython installation. But that would be for 32-bit carbon.
On Sep 15, 2010, at 1:41 PM, dave k wrote:
i compiled from scratch wxWidgets 2.9.1, but python is still using mac's 2.8
version. How do i tell python to use the locally installed version?
For 64-bit cocoa support, you'll need to install both wxWidgets-2.9.1 and
wxPython-2.9.1 from sources, and more specifically from Robin Dunn's workspace,
since the two are synchronized with each other, and then update your .profile
path.
I'm not using Mac Ports, so you'll have to point the environment variables to
the Mac Ports installed location, which is in /opt, or to the wxPython
installed location from sources.
Here are the contents of my .profile file.
# wxWidgets
export WXWIN=/Users/elvis/Tool/wxWidgets
# GNU Radio
export PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:$PATH
export
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig:/usr/X11R6/lib/pkgconfig:$PKG_CONFIG_PATH
export MANPATH=/usr/local/share/man:/usr/share/man:/usr/X11R6/man:$MANPATH
export INFOPATH=/usr/local/share/info:/usr/share/info:$INFOPATH
export LDFLAGS=
# setup PYTHON variables, depending on what's first in the $path
export PYTHON_VERSION=`python -V 21 | sed -e 's...@\.@ @2' | awk '{ print $2
}'`
export PYTHON_ROOT=`which python | sed -e 's@/bin/python@@g'`
export PYTHONPATH=${PYTHON_ROOT}/lib/python${PYTHON_VERSION}/site-packages
if [ ${PYTHON_ROOT} != /usr/include ]; then
export
PYTHONPATH=${PYTHONPATH}:/Library/Python/2.6/site-packages:/usr/local/lib/python${PYTHON_VERSION}/site-packages
fi
# User entries
export DYLD_LIBRARY_PATH=/usr/local/lib:$DYLD_LIBRARY_PATH
Not sure if this is going to work, but you could give it a shot. I'm working on
this too, at the moment, and should have some results in a couple of days.
Best regards,
Elvis
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] want to achieve the symbol rate to 270.833kb/s
2010/9/15 intermilan tianxia...@hotmail.com: hi all: I want to make the symbol rate of the data which is transmited by the USRP at the 270.833kb/s.I know the OpenBTS had already make it come true. but what I want to know is that can I use the resampler block to make this happen? (put the resampler block after the GMSK Mod block )and the value of the interpolation and decimation of the resampler block can be the same as them in the OpenBTS which are 65 and 96.and the interpolation of the USRP is 320 which is make the sample rate of the usrp is 400k.I have not do it now ,just want to ask here if it is possible. You should be able to use the gr.pfb_arb_resampler_ccf block to accomplish this. It's an arbitrary resampler and so doesn't rely on integer relationships. It can be a bit tricky to use, so look at the examples in gnuradio-examples/src/python/pfb for help in designing the filter for it. ... One of these days, I need to make a convenience wrapper for this block that designs the filter for the half sample rate automatically... Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] a issue about usrp underrun
Hi all, These days I encountered the problem of usrp underrun . The phenomenon is that I have two usrps, one is a sender and another is a receiver, the modulation is dqpsk. If the data rate of sender is low , the uU comes and the receiver lose lots of packet , and if the data rate of sender is high , all things are right. I think the reason for the lost packet may be the underrun of usrp. So I search for underrun. I get the reason of underrun is there is not enough data for usrp. I think the reason is right because the underrun comes up only when the data rate is low. I want to know whether there is any method to avoid the underrun when the data rate is low. And will the underrun of sender affect the receiver? Any advice is welcome! Thank you very much! -- Thanks, Jianfei BUAA ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio via MacPorts Updated
On Sep 14, 2010, at 5:12 PM, Michael Dickens wrote: We're just discussing this issue (32-bit execution) on the MacPorts' lists. The quick end-result is: With the current MacPorts' provided python2.6 or older, the PREFER_32_BIT stuff does not work because 'python' is actually just a wrapper around 'exec' and the bit-preferences are no passed through. Apple's python2.6 -does- work, as does python2.7 and newer, because this command was moved to posix_spawn; see http://www.opensource.apple.com/source/python/python-44.1/2.6/ for the source code and changes Apple made (somewhere in there). The above is correct as stated. That said, for the continued discussion on the MP-dev list: The way around this issue with MacPorts' Python 2.6 is to specify the whole path to the executable: $ arch -i386 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python -c 'import sys; print(sys.maxsize)' will print out: 2147483647. While $ arch -x86_64 will print out: 9223372036854775807. Of course, this mean that in order to execute a python script (e.g., usrp_fft.py), one needs to specify both the Python with full path as well as the script with full path (or '' or './' if in the current directory) $ arch -i386 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python /path/to/usrp_fft.py [options] We shouldn't be allows to have this much fun! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem connection USRP2
HI! I have two usrp2 , both work ok in my old PC. Now I want to use one usrps2 in a new PC. I have install gnuradio But the PC will not detect de usrp2. When I conect the ethernet cable... the PC dont detect noting. The SD is OK because works OK in the other PC The cable is OK the new PC have a gigabit ethernet. the adapter is: Atheros COmmunications Atheros AR8132 / L1c Gigabit Ethernet Adapter what happens?? any problem with my Ethernet card¿¿ Regards -- View this message in context: http://old.nabble.com/Problem-connection-USRP2-tp29718699p29718699.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] Problem connection USRP2
I have the same problem. I tried some advices which didn't work. To get communication between my USRP2 and my host computer I need to set the ethernet interface in promiscuous mode: sudo ifconfig eth0 promisc up Tell me if it works and if you find a way to solve it, we are pleased to hear the solution. Jorge. Laser_s wrote: HI! I have two usrp2 , both work ok in my old PC. Now I want to use one usrps2 in a new PC. I have install gnuradio But the PC will not detect de usrp2. When I conect the ethernet cable... the PC dont detect noting. The SD is OK because works OK in the other PC The cable is OK the new PC have a gigabit ethernet. the adapter is: Atheros COmmunications Atheros AR8132 / L1c Gigabit Ethernet Adapter what happens?? any problem with my Ethernet card¿¿ Regards -- View this message in context: http://old.nabble.com/Problem-connection-USRP2-tp29718699p29718990.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] Lyric probability CPU
Hi, I think these GP5s will have some interesting applications in signal processing as well... http://www.hardwarecentral.com/hardwarecentral/news/article.php/3899206 [...] After LEC, Lyric said its next focus is the development of a general-purpose programmable probability processing platform that it calls GP5. It will run code written in Lyric's own probability programming language called Probability Synthesis to Bayesian Logic (PSBL), which Lyric said is an expressive computer programming language for working with probability-based computations. Lyric aims to begin sampling the first GP5 in 2013. [...] Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 Basic receiver. Unexpected behavior
Hello, After running my USRP2 with the GRC software I got some results that I didn't expect. My configuration was is simple as an USRP2 source followed by a FFT sink to see the spectrum (around MHz with a 75cm antenna), but: 1) I can only see the sprectrum up to 100MHz. I thought that the LTC2284 ADC had a dynamic range of 575MHzWhy can I only see the spectrum lower than 100 MHz? (When I say that I can not see the spectrum I mean that at 100MHz I get a mirror of the spectrum between 0-100MHz). 2)The spectrum I can see is much more clear around 98MHz, where I can see a lot of carriers corresponding to FM radio stations that I cannot see for instance around 90Mhz. 3) What is the minimum decimation I can set in the USRP2 block? Experimentally I saw it is 5 but I don't understand why. My specific configuration of GRC is: USRP Source block: Decimation=5, Frequency=(tunable to cover FM band) FFT sink: sample rate=21MHz (105M/5), fft size: 512 In fact when I run my FM receiver (also made in GRC), I can only listen to 89MHz and 108MHz radio stations. I expected to receive the whole FM spectrum. If some of you have a answers to my questions I will be very glad because I want to understand USRP2 and GNU Radio as soon as possible to became an active member of this community! Regards, Jorge. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem connection USRP2
Hi!!! thanks But I have the same problem :S When I connect the USRP2... nothing happens... any more idea?? jmiggal wrote: I have the same problem. I tried some advices which didn't work. To get communication between my USRP2 and my host computer I need to set the ethernet interface in promiscuous mode: sudo ifconfig eth0 promisc up Tell me if it works and if you find a way to solve it, we are pleased to hear the solution. Jorge. Laser_s wrote: HI! I have two usrp2 , both work ok in my old PC. Now I want to use one usrps2 in a new PC. I have install gnuradio But the PC will not detect de usrp2. When I conect the ethernet cable... the PC dont detect noting. The SD is OK because works OK in the other PC The cable is OK the new PC have a gigabit ethernet. the adapter is: Atheros COmmunications Atheros AR8132 / L1c Gigabit Ethernet Adapter what happens?? any problem with my Ethernet card¿¿ Regards -- View this message in context: http://old.nabble.com/Problem-connection-USRP2-tp29718699p29720061.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] Stuff that makes you go hmmmm
I've been working on a system for observing cosmic radio noise, over a broad beamwidth, at the low-end of VHF (around 30-40MHz), using a USRP2 and a BASIC_RX. The application measures RMS power over a small bandwidth (between 100KHz and 750KHz, depending on user input). Yesterday, I discovered that I at some point blew up one of more of my mini-circuits ZFL-500 amplifiers, so while I'm waiting for replacements, I thought I'd do a quick experiment. I plugged the crossed-dipole antenna directly into the USRP2, with a 5th-order Butterworth low-pass filter with a corner frequency of 48MHz between the antenna and the USRP2. I fully expected to get *nothing* when I plugged in the antenna, or perhaps a minor increase in output. But, quite the contrary, plugging in the antenna produced a roughly 15dB increase in detected power across a 250KHz selected bandwidth. So, I thought that the BASIC_RX had *zero* gain, but I'm surprised that the A/D in the USRP2 is sensitive enough to plug directly into a low-VHF antenna without any gain. Does this match other peoples observations of the Basic_RX? Have people been able to use the Basic_RX as an HF/low-VHF receiver with no gain at all? -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Firmware issue: Send a constant signal with the xcvr2450 dboard
On Wed, Sep 15, 2010 at 05:55:12PM +0200, Matthias Schäfer wrote:
Hi List,
I'm currently working on a standalone firmware app for USRP2. My
goal is to send a constant signal with the xcvr2450 dboard. I
skipped the tuning via firmware by doing this prior from a host
using the simple_usrp c++ interface:
uhd::usrp::simple_usrp::sptr sdev = uhd::usrp::simple_usrp::make(args);
uhd::device::sptr dev = sdev-get_device();
sdev-set_tx_rate(rate);
sdev-set_tx_freq(freq);
sdev-set_tx_gain(gain);
===
So back to the firmware. Assuming the tuning of the dboard is
properly done from host, I basically understood the way sending is
done as follows:
1. Wait for the buffer pool to become idle:
while((buffer_pool_status-status BPS_IDLE(DSP_TX_BUF_0)) == 0)
;
2. Copy the data which should be send to the DSP into the DSP tx-buffer:
uint32_t *p = buffer_ram(DSP_TX_BUF_0);
uint32_t sample = (32000 16) | 0; // for example
for (i = 0; i BP_NLINE; i++) {
p[i] = sample;
}
3. Send the data to the DSP:
bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
4. Wait until transaction is done or an error occured
while((buffer_pool_status-status (BPS_DONE(DSP_TX_BUF_0) |
BPS_ERROR(DSP_TX_BUF_0))) == 0)
;
5. Clear the status flags and redo the whole procedure
bp_clear_buf(DSP_TX_BUF_0);
// goto 1.
===
Unfortunately this doesn't work for me like expected. I tried it in
several variations and listened with another usrp2 for a signal but
nothing happens. I think I understood something wrong and forgot
something but it's hard for me to see the problem.
So maybe you guys can help me out with that.
Thanks in advance!
Cheers,
Matthias
A couple of things. 32000 is likely to be too big and will probably
result in clipping. Try 3200 to start with.
It's unlikely that f/w can write samples to the buffer fast enough to
keep the data streaming. However in your case, you only need to
initialize the samples in the buffer once, then you can just keep
sending it over and over.
Do (2) once.
// Start in known good state (IDLE)
bp_clear_buf(DSP_TX_BUF_0);
// start first buffer xfer
bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
while (1){
// wait for xfer to complete
while ((buffer_pool_status-status
(BPS_DONE(DSP_TX_BUF_0) | BPS_ERROR(DSP_TX_BUF_0))) == 0)
;
// Reset flags
bp_clear_buf(DSP_TX_BUF_0);
// start next xfer
bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
}
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
