Re: [Discuss-gnuradio] Missing gr_plot_ofdm.py
On Mon, Jun 20, 2011 at 15:21, John Andrews wrote: > > http://vps.gnuradio.org/redmine/repositories/entry/gnuradio/gnuradio-examples/python/ofdm/gr_plot_ofdm.py?rev=ab6cf111c1d00b22d9016524b31cfcc6b09ffdc7 > That URL points to the (now) old gnuradio.org webserver, with the new one that came online in the last day it is: http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/entry/gnuradio-examples/python/ofdm/gr_plot_ofdm.py Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Missing gr_plot_ofdm.py
http://vps.gnuradio.org/redmine/repositories/entry/gnuradio/gnuradio-examples/python/ofdm/gr_plot_ofdm.py?rev=ab6cf111c1d00b22d9016524b31cfcc6b09ffdc7 On Mon, Jun 20, 2011 at 1:21 PM, smith mark wrote: > Hi all > I want to plot the .dat files that are created by the benchmark_ofdm code. > But I didn't find the "gr_plot_ofdm.py" > file anywhere in the my gnuradio directory. I am using gnuradio 3.3.0. I > did find the "plot_ofdm.m" file but I want to > use python only. I downloaded gnuradio3.2.2 but didn't find the file there > too. > > Please tell me from where I can download this file.. > > Regards > Usman Haider > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information
http://gnuradio.org/redmine/wiki/gnuradio On Mon, Jun 20, 2011 at 12:24 PM, bilel mnassri wrote: > HI to all of you, > > > I am a new user of GNUradio companion and i am seraching for > examples using USRP blocks and employing some advances signal processing > techniques such as MIMO. > please help me. i am in a big problem !!! > > have a nice day. > Bilel > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Receive GPS L1 Signal
On Sat, Jun 11, 2011 at 11:12 AM, Eddie Sun wrote: > Hi all, > > I have a USRP N210 and DBSRX2 daughter board, running on Ubuntu 10.04, and > I would like to get the L1 signal by > > using Gnuradio Companion to draw a GPS receiver flow graph (I have a GPS > Antenna), and I just need to get the IF signal into File > > Sink to get the .dat so I can use MATLAB to deal with the data, I have a > book "A Software-Defined GPS and Galileo Receiver: A > > Signal-Frequency Approach", This is the best book for software GPS. > there is a GNSS L1 front-end digram at p.55 (that is my only reference), > but I have no idea how to > > translate it into GNUradio Blocks.There is a ADC on that diagram, should I > just ignore it, or I need some blocks to complete that ADC? > ADC. Do you know what ADC means? If you do then you already have an ADC, which is the USRP. ;-) > > (There is no blocks called ADC)And there is several Band-Pass Filter in the > diagram with center frequency and 3dB Bandwidth, but I > > don't know how to translate it to the information that blocks needed.(Like > Low or High cutoff frequency, transition width ...etc) > A USRP is a baseband IF receiver. Tune it to the GPS L1 frequency with the right decimation rate so that you have your band of interest selected. This should give you the IF signal. > > Can anyone help me? Or has an example .grc or some website for related > information? > > > > Thanks, > > Eddie > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Muliple top_block()
On Mon, Jun 20, 2011 at 11:03, smith mark wrote: > As far as the result is concerned it seems right. But, I want to know that > whether this type of thing is conceptually right or not ?? > It is functionally correct, as you noted, but using GNU Radio this way is not very common except perhaps in automated QA code. Typically, flowgraphs run continuously, with data being injected into the graph via one or more sources and being removed via one or more sinks, and don't get started and stopped or re-run except in response to some application level event (like startup and shutdown, or for flowgraph reconfiguration). I think your use case would be better served by connecting your two flowgraphs using a message sink and a message source that share a common message queue, or even merging the two together, but it is hard to say without more information about what you are trying to accomplish. > I read that there must be only one top_block(). Please guide me in this.. > Having more than one top block is fine since release series 3.3, but requires more attention to detail as you have to use the start()/stop()/wait() sequence on each instead of the simpler run(). Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Muliple top_block()
Hi Thanks for the reply. I used tb1.start() and tb2.run() and I think that is working. The two blocks don't have connections with each other. The flow is like: tb1=gr.top_block() 1. tb1.start() 2. Some variable declaration... Repeat step 3 and 4, five times 3. A function that creates tb2 and runs it and return the result --- tb2=gr.top_block() --- vector source--->convolution coding->destination --- tb2.run() --- return destination.data() 4. send the result to the tb1 for processing 5 . tb1.wait() As far as the result is concerned it seems right. But, I want to know that whether this type of thing is conceptually right or not ?? I read that there must be only one top_block(). Please guide me in this.. Regards Smith ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Information
HI to all of you, I am a new user of GNUradio companion and i am seraching for examples using USRP blocks and employing some advances signal processing techniques such as MIMO. please help me. i am in a big problem !!! have a nice day. Bilel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Missing gr_plot_ofdm.py
Hi all I want to plot the .dat files that are created by the benchmark_ofdm code. But I didn't find the "gr_plot_ofdm.py" file anywhere in the my gnuradio directory. I am using gnuradio 3.3.0. I did find the "plot_ofdm.m" file but I want to use python only. I downloaded gnuradio3.2.2 but didn't find the file there too. Please tell me from where I can download this file.. Regards Usman Haider ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Muliple top_block()
On Mon, Jun 20, 2011 at 03:59, Mike Clark wrote: > try tb1.start() and tb2.start(). That should run them in separate threads. > The start() function kicks off the GNU Radio thread scheduler for a flowgraph top block, but immediately returns to the foreground thread. You'll be able to do other things in your application while GNU Radio runs "in the background." Typically this is used even for a single top block in GUI programs to start GNU Radio running and then enter the GUI library event loop in the foreground thread. However, you'll need at some point to call tb1.stop(), tb2.stop(), tb1.wait(), tb2.wait() before the program exits, in order to properly clean up GNU Radio created resources. Finally, depending on the application, you might need to hook SIGINT so you can do the above as part of a proper shutdown if the user hits ^C or otherwise kills the process. Martin's suggestion of placing the flowgraphs each into their own port-less hierarchical block and then putting those into a single top block makes sense if the two flowgraphs must always be started and stopped together. It used to be the only way to do it, but as of 3.3 you could run multiple, independent top blocks in a single process via the start()/stop()/wait() sequence on each instead of run(). Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM on USRP2
On 20/06/2011 10:05 AM, vanITA1082 wrote: I am going more deeply into the OFDM example, however I cannot figure out which is the bit rate of the usrp. I mean, I know and I can set the bit rate of my application but how fast the packets are sent out by the usrp? How can I evaluate the throughput on the wireless link? Thanks Vanessa The USRP knows nothing about packets or modulation or any of the higher-level concepts you seek. The USRP/USRP2/N2XX are, conceptually, digitizers that digitize the baseband output of the RF chain, and present it to the host at a fixed sample rate. Conversely, they take digital samples from the host, and convert them into baseband analog signals for the RF hardware to transmit. Any given modulation waveform (whether it's OFDM, or BPSK, or NBFM, or whatever) occupies a certain *bandwidth*, and you chose the sample rate to accomodate the bandwidth of the signal. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD last in git unable to recv
Its fine, just see the --help before running. And thanks for the patch. -Josh On 06/20/2011 05:29 AM, Gaetano Mendola wrote: > Hi all, > I got last version from git compiled and installed, installed the > images UHD-images-003.001.002.tar.gz > as well. The device is a USRP N210 with a WBX. > > It seems now the device is unable to receive any data, the > benchmark_rate example gives > > ./benchmark_rate > linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.001.002-bc87971 > > > Creating the usrp device with: ... > -- Opening a USRP2/N-Series device... > -- Current recv frame size: 1472 bytes > -- Current send frame size: 1472 bytes > -- mboard0 is MIMO master > Using Device: Single USRP: > Device: USRP2/N Series device > Mboard 0: USRP-N210 mboard > RX Channel: 0 > RX DSP: USRP-N210 ddc0 > RX Dboard: USRP-N210 dboard (rx unit) > RX Subdev: WBX RX + Simple GDB > TX Channel: 0 > TX DSP: USRP-N210 duc0 > TX Dboard: USRP-N210 dboard (tx unit) > TX Subdev: WBX TX + Simple GDB > > > Benchmark rate summary: > Num received samples:0 > Num dropped samples: 0 > Num overflows detected: 0 > Num transmitted samples: 0 > Num sequence errors: 0 > Num underflows detected: 0 > > > Done! > > > I have also noticed that the led "B" now is on, is it normal ? > > Regards > Gaetano > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Strange uhd::device::send execution times
On Sun, Jun 19, 2011 at 8:44 PM, Gaetano Mendola wrote: > I have 12 cores on my server, and I fear the kernel is juggling that thread > around. I have solved the issue but still I'm not happy at all with what is going on. The samples I'm feeding with the USRP N210 are stored on a disk, my sample rate is 12.5 mega samples per second so in order to maintain that rate for hours I have a thread performing I/O from disk and a thread feeding the radio device. The server is a dual socket xeon system and when the two threads are scheduled on the same socket then the uhd::device::send some time lasts too much (some time even 2 seconds vs the 0.0036 extimated). To solve the issue I had to perform a cpu affinity for the thread inside the UHD library and a cpu affinity for my own thread in order to have those two threads on different sockets (core 7 for uhd thread and core 2 for my own thread). Unfortunaly there is no way to specify at the time of the device on which core the thread has to run, I'll see if I can submit a patch that will permit to build a device like this: "address=127.0.0.1,send_buff_size=100e6,lockcore=7" Regards Gaetano Mendola -- cpp-today.blogspot.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM on USRP2
I am going more deeply into the OFDM example, however I cannot figure out which is the bit rate of the usrp. I mean, I know and I can set the bit rate of my application but how fast the packets are sent out by the usrp? How can I evaluate the throughput on the wireless link? Thanks Vanessa Morgan Redfield-2 wrote: > > On Thu, Jun 9, 2011 at 1:24 AM, vanITA1082 > wrote: >> >> Thank you! >> >> I found 2 errors in benchmark_ofdm_tx.py: >> >> line 63 should be "sink" >> line 69 should be "samp_rate" >> >> Thanks again >> Vanessa >> >> > > Hi Vanessa, > > One thing you might also have to change is the tx-amplitude in > transmit_path.py. I wasn't having any success until I changed the > range from 0 <= AMPL < 32768 to 0 <= AMPL <= 1. > > I'm interested in whether you have any success with this. I'm > currently able to send something that looks like OFDM, but unable to > demodulate it. > > Thanks, > Morgan > > >> Nick Foster-4 wrote: >>> >>> On Wed, 2011-06-01 at 00:50 -0700, vanITA1082 wrote: Yes, but they do not work with UHD which is the only way to use my USRP N210 >>> >>> I just pushed a branch with UHD versions of the OFDM apps: >>> >>> git://github.com/bistromath/gnuradio.git >>> >>> It's in the uhd_ofdm branch. This is untested code, so use at your own >>> risk. I just wanted to illustrate to people how easy it is to move stuff >>> over to UHD. Check the git diffs for a guide on the things that change. >>> Basically the largest change is saying "uhd.usrp_source" instead of >>> "usrp_source", and use sample rate instead of decimation/interpolation >>> factors. These changes apply to ALL the USRP examples, not just the OFDM >>> stuff. >>> >>> Note that this doesn't fix any lingering bitrot which may be in there -- >>> I haven't tried the OFDM examples in a while. I'll get a chance to test >>> them in a day or so. >>> >>> --n >>> Marcus D. Leech wrote: > > On 05/31/2011 10:15 AM, vanITA1082 wrote: >> Thanks. >> >> However we are trying to transmit a packet from a usrp n210 to another >> usrp >> n210 and we are searching for examples do to this simple operation. >> >> How is it possible that are not out there? Do you know any source of >> simple >> examples? >> >> >> Thanks >> >> Vanessa >> >> > Dont know what state they're in: > > ./gnuradio-examples/python/ofdm > ./gnuradio-examples/python/ofdm/ofdm_mod_demod_test.py > ./gnuradio-examples/python/ofdm/plot_ofdm.m > ./gnuradio-examples/python/ofdm/ofdm_sync.m > ./gnuradio-examples/python/ofdm/benchmark_ofdm_rx.py > ./gnuradio-examples/python/ofdm/benchmark_ofdm_tx.py > ./gnuradio-examples/python/ofdm/gr_plot_ofdm.py > ./gnuradio-examples/python/ofdm/benchmark_ofdm.py > ./gnuradio-examples/python/ofdm/ofdm_sync_pn.m > > > >>> > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > >>> >>> >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/OFDM-on-USRP2-tp30638994p31807479.html >> Sent from the GnuRadio mailing list archive at Nabble.com. >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/OFDM-on-USRP2-tp30638994p31885976.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD last in git unable to recv
Hi all, I got last version from git compiled and installed, installed the images UHD-images-003.001.002.tar.gz as well. The device is a USRP N210 with a WBX. It seems now the device is unable to receive any data, the benchmark_rate example gives ./benchmark_rate linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.001.002-bc87971 Creating the usrp device with: ... -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes -- mboard0 is MIMO master Using Device: Single USRP: Device: USRP2/N Series device Mboard 0: USRP-N210 mboard RX Channel: 0 RX DSP: USRP-N210 ddc0 RX Dboard: USRP-N210 dboard (rx unit) RX Subdev: WBX RX + Simple GDB TX Channel: 0 TX DSP: USRP-N210 duc0 TX Dboard: USRP-N210 dboard (tx unit) TX Subdev: WBX TX + Simple GDB Benchmark rate summary: Num received samples:0 Num dropped samples: 0 Num overflows detected: 0 Num transmitted samples: 0 Num sequence errors: 0 Num underflows detected: 0 Done! I have also noticed that the led "B" now is on, is it normal ? Regards Gaetano -- cpp-today.blogspot.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] typo in usrp2_impl.cpp
I believe there is a typo in that file (last git version), patch inline.
--- a/host/lib/usrp/usrp2/usrp2_impl.cpp
+++ b/host/lib/usrp/usrp2/usrp2_impl.cpp
@@ -249,7 +249,7 @@ usrp2_impl::usrp2_impl(const device_addr_t &_device_addr){
//extract the user's requested MTU size or default
mtu_result_t user_mtu;
user_mtu.recv_mtu =
size_t(device_addr.cast("recv_frame_size", udp_simple::mtu));
-user_mtu.send_mtu =
size_t(device_addr.cast("recv_frame_size", udp_simple::mtu));
+user_mtu.send_mtu =
size_t(device_addr.cast("send_frame_size", udp_simple::mtu));
try{
//calculate the minimum send and recv mtu of all devices
--
cpp-today.blogspot.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Muliple top_block()
On Mon, Jun 20, 2011 at 03:34:55PM +0500, smith mark wrote: > Hi all, > > I wanted to know that whether one can have multiple gr.top_block() or not? > > for example > > tb1=gr.top_block() > > tb2=gr.top_block() > > tb1.run() > > tb2.run() > > and have them running at the same time. This definitely works: Create several hier_blocks, each containing a full flow graph (w/ zero input and output signatures), then put each of these into one top_block. For an example, see usrp_nbfm_ptt.py. Cheers, MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpatgQhd84Oy.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Muliple top_block()
try tb1.start() and tb2.start(). That should run them in separate threads. Mike On Mon, Jun 20, 2011 at 6:34 AM, smith mark wrote: > Hi all, > I wanted to know that whether one can have multiple gr.top_block() or not? > for example > tb1=gr.top_block() > tb2=gr.top_block() > tb1.run() > tb2.run() > and have them running at the same time. > Regards > Smith > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Muliple top_block()
Hi all, I wanted to know that whether one can have multiple gr.top_block() or not? for example tb1=gr.top_block() tb2=gr.top_block() tb1.run() tb2.run() and have them running at the same time. Regards Smith ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to remove/suppress gr_buffer::allocate_buffer: warning:
On Fri, Jun 17, 2011 at 05:08:31PM +0200, Johannes Schmitz wrote: > Hello Martin, > I will check my code to find out why it is so big. > > Is there an easy way to somehow suppress this warning in case I am > willing to ignore it? Not without changing the code (gnuradio-core/src/lib/runtime/gr_buffer.cc). Of course, you can redirect stderr if you're sure nothing else is going wrong. MB > > Johannes > > 2011/6/17 Martin Braun : > > On Fri, Jun 17, 2011 at 03:42:07PM +0200, Johannes Schmitz wrote: > >> I am getting the following warning when running my script: > >> > >> gr_buffer::allocate_buffer: warning: tried to allocate > >> 4 items of size 88192. Due to alignment requirements > >> 32 were allocated. If this isn't OK, consider padding > >> your structure to a power-of-two bytes. > >> On this platform, our allocation granularity is 4096 bytes. > >> > >> Can somebody tell me how to solve this problem or suppress this warning? > >> > >> I found it has to do something with fft-size that is not power of 2.. > > > > Buffers between blocks are always an integer multiple of the > > item-size (in your case 88192) and 4096. The LCM of 88192 and 4096 > > is pretty large, and tadaa, you get a warning. > > > > It's just a warning. If everything works fine... just ignore it. But > > it's a waste of memory. If you want to optimize this, change your > > itemsize. You will normally have to adapt the way the data is handled, > > e.g., you could pad the input to 90112=22*4096 and then discard > > 90112-88192=1920 Bytes of every input vector. > > > > Personally, I usually just ignore it, since it rarely turns up in less > > unusual applications. > > > > MB > > > > -- > > Karlsruhe Institute of Technology (KIT) > > Communications Engineering Lab (CEL) > > > > Dipl.-Ing. Martin Braun > > Research Associate > > > > Kaiserstraße 12 > > Building 05.01 > > 76131 Karlsruhe > > > > Phone: +49 721 608-43790 > > Fax: +49 721 608-46071 > > www.cel.kit.edu > > > > KIT -- University of the State of Baden-Württemberg and > > National Laboratory of the Helmholtz Association > > > > -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpJo2pqGIDCe.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
