[Discuss-gnuradio] Reading from USRP
Hey guys, I've been trying to read from the USRP by simply doing u-read(buf, 512, overrun). I used the usrp_inband_usb_packet class to extract the payload size and the payload from each USB packet received. As I understand, the USB packets contain pairs of I and Q for each (I didn't change the format from the default). I was expecting the payload size then to be a multiple of 4, since it is 2 shorts. I frequently see payload sizes such as 7, 13, etc. What is going on here? Are there examples of getting the data from a dbsrx using this method and processing it? I found the test_standard_rx example, but it doesn't do any processing and just reads. Thank you. -- Cheers, Timur ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM modulator o/p sampling rate
i am trying to transmit sound through OFDM system using the USRP i was able to transmit and receive audio in OFDM system without the USRP and also was able to transmit and receive audio using the USRP without OFDM when i try to merge the 2 system using the scope i see that there is a signal before the OFDM demod and no signal exactly after it and receive a timeout message i am thinking that this happen because the sampling rate before the USRP is not adjusted right for transmission(i am using 1 USRP and transmit and receive using a basic Tx and a basic Rx) so is there a way to know the output sampling rate exactly after the ofdm modulation? and if this was not the problem what may cause this problem? the ofdm modulator parameters fft length: 512 occupied tones:200 cyclic prefix:128 payload:0 (0=automatic) and the i/p is 32000 samples ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem in executing GRC
Hi
I figured out the error!
In addition to the PYTHONPATH i had
i needed to add the commands in this site:
https://radioware.nd.edu/documentation/install-guides/mac-os-x/preliminaries#section-3
and it worked
Udaya
udadidd wrote:
Hi
I have deleted al gnuradio/ files from /usr/local/{directories}
-and again started from bootstrap
-ran grc
Now I get the error:
Xlib: extension RANDR missing on display /tmp/launch-zFqALC/:0.
Traceback (most recent call last):
File /usr/local/bin/grc, line 33, in module
from gnuradio.grc import VERSION
ImportError: No module named grc
Johnathan Corgan-2 wrote:
On Sun, Jul 5, 2009 at 18:05, udadidduyedd...@ece.uic.edu wrote:
Do i have to configure, make and make install?
What may have happened here is fallout from a reorganization of the
grc directories in the source/install tree on the trunk. You're best
best is to manually go through /usr/local/{bin,lib,...} and remove all
traces of gnuradio, then go back to your gnuradio source tree and
start from the bootstrap step.
That's a bit of overkill, but should clear the issue up.
Johnathan
___
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/Problem-in-Installing-gnuradio-3.2-tp22518659p24449854.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] Having a higher samples per symbol (greater than 7) with lower bitrate
= the maximum samples per symbol value that benchmark_tx has is 7. What happens if I change it to a higher value and reduce the bitrate such that the usrp constraints are still met. I read somewhere that having a sample per symbol value greater than 7 is impractical. Why? From a strictly 'seat of the pants' point of view, it seems to work fine. You can edit the array (I think in pick_bitrate.py) that limits the search space for bitrates to a sps less than 7. You can add your own like, 50 and 60 for example, and pick_bitrate will then allow for you to use the very low data rates associated. As for why this might be bad, I have no idea, we did it mainly as a 'look what we can do' for testing out a large range of bitrates. When we took experimental data over a range of SNRs using a channel emulator to set the SNR via additive noise we found that the empirical measurements very closely matched the theoretical limits expected from BPSK. Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reading from USRP
On Sunday 12 July 2009 08:09:24 Timur Alperovich wrote: Hey guys, I've been trying to read from the USRP by simply doing u-read(buf, 512, overrun). I used the usrp_inband_usb_packet class to extract the payload size and the payload from each USB packet received. As I understand, the USB packets contain pairs of I and Q for each (I didn't change the format from the default). I was expecting the payload size then to be a multiple of 4, since it is 2 shorts. I frequently see payload sizes such as 7, 13, etc. What is going on here? Are there examples of getting the data from a dbsrx using this method and processing it? I found the test_standard_rx example, but it doesn't do any processing and just reads. If you want to use the inband code, of course you have to use the inband firmware as well. Most probably, you use the standard firmware, and the payload size you see is a normal sample. USB packets produced by the standard firmware always contain 512 bytes/128 complex samples (as long as you stick to standard sample resolution of 16 bit per component). The inband firmware will produce packets containing 504 bytes of payload (126 samples), and it will accept shorter packets. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reading from USRP
On Sunday 12 July 2009 08:09:24 Timur Alperovich wrote: Hey guys, I've been trying to read from the USRP by simply doing u-read(buf, 512, overrun). I used the usrp_inband_usb_packet class to extract the payload size and the payload from each USB packet received. As I understand, the USB packets contain pairs of I and Q for each (I didn't change the format from the default). I was expecting the payload size then to be a multiple of 4, since it is 2 shorts. I frequently see payload sizes such as 7, 13, etc. What is going on here? Are there examples of getting the data from a dbsrx using this method and processing it? I found the test_standard_rx example, but it doesn't do any processing and just reads. If you want to use the inband code, of course you have to use the inband firmware as well. Most probably, you use the standard firmware, and the payload size you see is a normal sample. Thank you Stefan. That definitely explains it! What is the advantage/reason for using the inband firmware? I was working on adapting some of the OpenBTS code for what I'm trying to do and I didn't realize they're using the inband firmware and didn't realize the differences in the data returned by the different firmware. Searching gnuradio.org, I couldn't find anything on the wiki about it. USB packets produced by the standard firmware always contain 512 bytes/128 complex samples (as long as you stick to standard sample resolution of 16 bit per component). The inband firmware will produce packets containing 504 bytes of payload (126 samples), and it will accept shorter packets. Regards, Stefan -- Cheers, Timur ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reading from USRP
On Sun, Jul 12, 2009 at 2:55 PM, Timur Alperovichtimur...@umich.edu wrote: On Sunday 12 July 2009 08:09:24 Timur Alperovich wrote: Hey guys, I've been trying to read from the USRP by simply doing u-read(buf, 512, overrun). I used the usrp_inband_usb_packet class to extract the payload size and the payload from each USB packet received. As I understand, the USB packets contain pairs of I and Q for each (I didn't change the format from the default). I was expecting the payload size then to be a multiple of 4, since it is 2 shorts. I frequently see payload sizes such as 7, 13, etc. What is going on here? Are there examples of getting the data from a dbsrx using this method and processing it? I found the test_standard_rx example, but it doesn't do any processing and just reads. If you want to use the inband code, of course you have to use the inband firmware as well. Most probably, you use the standard firmware, and the payload size you see is a normal sample. Thank you Stefan. That definitely explains it! What is the advantage/reason for using the inband firmware? I was working on adapting some of the OpenBTS code for what I'm trying to do and I didn't realize they're using the inband firmware and didn't realize the differences in the data returned by the different firmware. Searching gnuradio.org, I couldn't find anything on the wiki about it. Ok, I found the information about in-band signaling, which render my other questions moot: http://gnuradio.org/trac/wiki/InBandSignaling. Thanks for the help again. USB packets produced by the standard firmware always contain 512 bytes/128 complex samples (as long as you stick to standard sample resolution of 16 bit per component). The inband firmware will produce packets containing 504 bytes of payload (126 samples), and it will accept shorter packets. Regards, Stefan -- Cheers, Timur ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio and python 2.6
On Sat, Jul 11, 2009 at 11:40:29AM +0600, ali siddiqi wrote: Hi all, Does gnuradio work with python 2.6? If yes would I need to first uninstall my gnuradio and python 2.5 first and then install python 2.6 and gnuradio again? I am currently on ubuntu 8.04. Would I need to upgrade to 9.04? Waiting for a quick reply! GNU Radio works with 2.5 and 2.6 (and most of it works with 2.3 and 2.4 too) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio and python 2.6
Hi, --- On Mon, 7/13/09, Eric Blossom e...@comsec.com wrote: +0600, ali siddiqi wrote: Hi all, Does gnuradio work with python 2.6? If yes would I need to first uninstall my gnuradio and python 2.5 first and then install python 2.6 and gnuradio again? I am currently on ubuntu 8.04. Would I need to upgrade to 9.04? Waiting for a quick reply! GNU Radio works with 2.5 and 2.6 (and most of it works with 2.3 and 2.4 too) Eric The Current GNURadio Binary packages cannot installed on Ubuntu 8.04 because for some reason (may be Johnathan know) it needs python 2.6 which is not available for Ubuntu below 9.04. Best Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] sending periodic signals in tunnel.py
Hi all, Memory: 1008.6MiB CPU: Processor 0: 2.8GHz and Processor 1:2.8GHz OS: 2.6.27.23-78.2.50.fc.i686 (Fedora 9) GNU Radio: neither 3.1.3 nor 3.2. (I download the gnuradio in the trunk several months ago.) I have two machines, A and B ( the same systems as shown above). I would like to send out signals periodically (every 4.5ms) from A to B in the MAClayer of the tunnel.py in the gnuradio-examples folder. I implemented this idea after the “while 1” in the “main_loop” for MAC. It took a while (a few hundreds millisecond) to repeat the loop. I think that Python might be too slow to be implemented the periodic signals so that the tunnel.py could not send the signal every 4.5ms. Right? Can anyone give me some hints to let me know if I can send out the signal every 4.5ms in tunnel.py? I would really appreciate any suggestions.. Thank you, Jane Codes in tunnel.py: while 1: now=datetime.datetime.now() now_second=now.second now_usecond=now.microsecond now_time=(now_second)*100+now.microsecond print While_1 now_time = %d % (now_time) # send out a packet to a client here Results of Print: While_1 now_time = 20754893 microsecond While_1 now_time = 20755001 While_1 now_time = 20951609 While_1 now_time = 20952030 While_1 now_time = 20979402 While_1 now_time = 20979804 While_1 now_time = 21202578 While_1 now_time = 21453420 While_1 now_time = 21486651 While_1 now_time = 21653691 While_1 now_time = 22124831 While_1 now_time = 22284597 While_1 now_time = 22485948 While_1 now_time = 22682929 While_1 now_time = 22683291 While_1 now_time = 22800091 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
