[Discuss-gnuradio] question on howto write a new block
hi all: I am writing a new simple signal processing block following the tutorial under the directory /gnuradio-3.2.2/gr-howto-write-a-block-3.2.2(there is no gr-howto-write-a-block-3.2.2 at the beginning,and this one is I downloaded and copied to this directory)and named 'howto_add_ff' block. I've created howto_add_ff.h and howto_add_ff.cc file under /gnuradio-3.2.2/gr-howto-write-a-block-3.2.2/src/lib.Then I modified howto.i and Makefile.am in the same directory. After that I run the following command under the directory /gnuradio-3.2.2/gr-howto-write-a-block-3.2.2: ./bootstrap ./configure make Then I got a error said thers is no rules for all-am to creat the required target howto_add_ff.h.STOP.( I translate the error into english beacause I do no use engliah as the language of my Ununtu). Can anyone tell me how to fix it? Thank you in advance ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] question on howto write a new block
On Tue, Nov 09, 2010 at 05:33:15PM +0800, intermilan wrote: hi all: I am writing a new simple signal processing block following the tutorial under the directory /gnuradio-3.2.2/gr-howto-write-a-block-3.2.2(there is no gr-howto-write-a-block-3.2.2 at the beginning,and this one is I downloaded and copied to this directory)and named 'howto_add_ff' block. I've created howto_add_ff.h and howto_add_ff.cc file under /gnuradio-3.2.2/ gr-howto-write-a-block-3.2.2/src/lib.Then I modified howto.i and Makefile.am in the same directory. After that I run the following command under the directory /gnuradio-3.2.2/ gr-howto-write-a-block-3.2.2: ./bootstrap ./configure make Then I got a error said thers is no rules for all-am to creat the required target howto_add_ff.h.STOP.( I translate the error into english beacause I do no use engliah as the language of my Ununtu). Can anyone tell me how to fix it? You've probably not adapted the Makefiles properly. Have a look where howto_square_ff.* is referenced (it's a couple of places). I recommend using gr_modtool.py (you can get it from https://www.cgran.org/wiki/devtools), this automatically does all the edits for you. 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-3790 Fax: +49 721 608-6071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpOrz2kdVSxX.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Pipelined processing with the Thread-Per-Block scheduler?
On Tue, Nov 09, 2010 at 04:34:42PM +1100, Balint Seeber wrote: Dear all, I conducted a simple experiment (using GRC) to test the TPB scheduler's performance, and following a search here, I cannot find any definitive information that would explain the observed behaviour. I kindly request your thoughts on the matter: Three flow graphs were created in separate GRC documents. No graph uses throttling. Tests were run on a dual-core Linux machine using a 3.3git release. 1) One graph: a high-rate signal source connected to a resampler, which is in turn connected to a null sink. 2) Two identical disconnected sub-graphs: each contains a high-rate signal source connected to a resampler, which is in turn connected to a null sink (i.e. as above, just twice). 3) One graph: one high-rate signal source whose output is connected to the input of two separate resamplers, each of which is connected to its own null sink. 'High-rate' means a few Msps, and the resamplers output data at a similar rate (e.g. 8MHz, decim/interp=4:3). Thanks to the TPB scheduler, (2) uses 100% CPU (max load on both cores) as the sub-graphs are disconnected. However when running (1) and (3), only 50% utilisation is observed. I also placed 'Copy' and 'Kludge Copy' blocks before the resampler inputs in (3), but this did not increase performance (which makes sense given the assumed flow model below). I am not aware of the intricacies of the asynchronous flow model used, or the TPB scheduler (I only skimmed the source), but I wonder why (1) and (3) do not use more than 50% CPU? What kind of hardware are you running this on? (Pls be specific.) How may core does the kernel say you have? cat /proc/cpuinfo If these are i5's or i7's (or anything else with hyperthreading) please remember that half of the cores shown by the kernel aren't really cores, and that there are substantial resources shared between them. I've achieved near linear speed up, up to 24 cores, with certain flow graphs so I'm pretty sure that the implementation is sound. Feel free to send me the grc file off list and I'll take a look at it. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] question on howto write a new block
On Tue, Nov 09, 2010 at 03:23:35PM +0100, Martin Braun wrote: On Tue, Nov 09, 2010 at 05:33:15PM +0800, intermilan wrote: hi all: I am writing a new simple signal processing block following the tutorial under the directory /gnuradio-3.2.2/gr-howto-write-a-block-3.2.2(there is no gr-howto-write-a-block-3.2.2 at the beginning,and this one is I downloaded and copied to this directory)and named 'howto_add_ff' block. I've created howto_add_ff.h and howto_add_ff.cc file under /gnuradio-3.2.2/ gr-howto-write-a-block-3.2.2/src/lib.Then I modified howto.i and Makefile.am in the same directory. After that I run the following command under the directory /gnuradio-3.2.2/ gr-howto-write-a-block-3.2.2: ./bootstrap ./configure make Then I got a error said thers is no rules for all-am to creat the required target howto_add_ff.h.STOP.( I translate the error into english beacause I do no use engliah as the language of my Ununtu). Can anyone tell me how to fix it? You've probably not adapted the Makefiles properly. Have a look where howto_square_ff.* is referenced (it's a couple of places). I recommend using gr_modtool.py (you can get it from https://www.cgran.org/wiki/devtools), this automatically does all the edits for you. Cheers, MB I'd also suggest starting with 3.3.0 (or git master) instead of 3.2.2, and use the $ create-gnuradio-out-of-tree-project my-module-name command to get you started. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] HELP! Is it a defective USRP1?
Hi All: I am experiencing something strange with USRP1 and already tried a lot of approaches to diagnose where the problem is, but no luck so far. We have two USRP1, each of which has a RXF 2400 daughter board and an antenna connected to the Tx/Rx port. When we run benchmark (benchmark_tx.py and benchmark_rx.py), the packet loss/corrupted rate is very random (from 0% to 99%). We've tried several approaches to diagnose where the problem, including (1) connect the Tx/Rx ports of two USRP by a SMA connector (2) try both sides of the mother board (A and B) , (3) use different central frequency from 2.4G to 2.48G, (4) adjust the carrier threshold (20 to 50), tx amplitude (0 to 1) and rx gain (0 to 90), (5) place the radios in different locations, (6) use different versions of gnuradio (stable release version 3.3.0 as well as the latest repository code) (7) place a fft sink at the rx to observe the spectrum, I can see the signal spectrum showing up when tx is transmitting something. Unfortunately, nothing really helps. Is it possible that it is a defective USRP? I really appreciate if anyone of you could guide me with this problem because I have a deadline to make in around 2.5 weeks. Thanks very much! Rachel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] HELP! Is it a defective USRP1?
On 11/09/2010 05:34 PM, Rachel Li wrote: Hi All: I am experiencing something strange with USRP1 and already tried a lot of approaches to diagnose where the problem is, but no luck so far. We have two USRP1, each of which has a RXF 2400 daughter board and an antenna connected to the Tx/Rx port. When we run benchmark (benchmark_tx.py and benchmark_rx.py), the packet loss/corrupted rate is very random (from 0% to 99%). We've tried several approaches to diagnose where the problem, including (1) connect the Tx/Rx ports of two USRP by a SMA connector (2) try both sides of the mother board (A and B) , (3) use different central frequency from 2.4G to 2.48G, (4) adjust the carrier threshold (20 to 50), tx amplitude (0 to 1) and rx gain (0 to 90), (5) place the radios in different locations, (6) use different versions of gnuradio (stable release version 3.3.0 as well as the latest repository code) (7) place a fft sink at the rx to observe the spectrum, I can see the signal spectrum showing up when tx is transmitting something. Unfortunately, nothing really helps. Is it possible that it is a defective USRP? I really appreciate if anyone of you could guide me with this problem because I have a deadline to make in around 2.5 weeks. Thanks very much! Rachel My suggestion is that you use a more basic diagnostic. Do both USRPs have roughly the same sensitivity and output power? If you transmit on one, and receive on the other with a FFT, with an attenuator between them, can the Rx side see the other side, use increasing levels of attenuation until the Rx can't see the transmitted signal anymore. -- 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] HELP! Is it a defective USRP1?
Try a higher rate (spectrally wider symbols). Maybe its an issue of frequency offset. -Josh On 11/09/2010 02:34 PM, Rachel Li wrote: Hi All: I am experiencing something strange with USRP1 and already tried a lot of approaches to diagnose where the problem is, but no luck so far. We have two USRP1, each of which has a RXF 2400 daughter board and an antenna connected to the Tx/Rx port. When we run benchmark (benchmark_tx.py and benchmark_rx.py), the packet loss/corrupted rate is very random (from 0% to 99%). We've tried several approaches to diagnose where the problem, including (1) connect the Tx/Rx ports of two USRP by a SMA connector (2) try both sides of the mother board (A and B) , (3) use different central frequency from 2.4G to 2.48G, (4) adjust the carrier threshold (20 to 50), tx amplitude (0 to 1) and rx gain (0 to 90), (5) place the radios in different locations, (6) use different versions of gnuradio (stable release version 3.3.0 as well as the latest repository code) (7) place a fft sink at the rx to observe the spectrum, I can see the signal spectrum showing up when tx is transmitting something. Unfortunately, nothing really helps. Is it possible that it is a defective USRP? I really appreciate if anyone of you could guide me with this problem because I have a deadline to make in around 2.5 weeks. Thanks very much! Rachel ___ 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] flowgraph for commercial FM radio TX/RX
Hi Steve, on my webpage I collected a number of receive and transmit flowgraphs for all sorts of modulations, but also FM: http://www.dl8rds.de/index.php/GNURadio_and_USRP2 I also own the USRP2 and the WBX board and I am testing them step by step. Please also consider these documents: http://www.snowymtn.ca/GNURadio/GNURAdioDoc-7.pdf http://www.linuxjournal.com/article/7505 For a nice receiver there's this neat little Python program from Michel Barbeau: http://people.scs.carleton.ca/~barbeau/SDR/Python/radio.py ...which you might download right away with wget. BR Markus DL8RDS Am Dienstag, den 09.11.2010, 17:33 -0800 schrieb Steve Mcmahon: Hello: Does anyone have a flowgraph that could be run on a USRP2 with a WBX daughterboard for either transmit or receive of commercial FM radio (88 MHz to 108 MHz U.S.)? In the transmit case, I would like to read raw PCM audio from a file and modulate it and transmit it in the commercial FM band, to be received by a standard FM radio. In the receive case, I would like to capture and demodulate commercial FM radio and save the raw PCM audio data to a file for playback. This is for academic, proof-of-concept, very low-power purposes. I am not using it to operate a pirate FM radio station. I appreciate your help. Thanks. Steve McMahon ___ 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
[Discuss-gnuradio] external ref
Does any alteration to code or firmware need to be made in order to get a USRP2 to lock to an external 10MHz reference? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] external ref
Clarification to last- I see it can be done in Python with UHD, but without, do I need to put clocks_mimo_config(*MC_WE_LOCK_TO_SMA*); in clocks.c- perhaps in place of WC_WE_DONT_LOCK on like 52 or is there a way to do it in python for non UHD? On 11/09/2010 11:44 PM, Brett L. Trotter wrote: Does any alteration to code or firmware need to be made in order to get a USRP2 to lock to an external 10MHz reference? ___ 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] external ref
On Wed, Nov 10, 2010 at 12:44 AM, Brett L. Trotter br...@webtrotter.com wrote: Does any alteration to code or firmware need to be made in order to get a USRP2 to lock to an external 10MHz reference? No firmware changes with UHD. Code looks something like this. uhd::clock_config_t clock_config; clock_config.ref_source = uhd::clock_config_t::REF_SMA; clock_config.pps_source = uhd::clock_config_t::PPS_SMA; clock_config.pps_polarity = uhd::clock_config_t::PPS_NEG; dev = uhd::usrp::single_usrp::make(dev_addr); dev-set_clock_config(clock_config); Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] LO of the USRP2 motherboard
Hi, I have an easy question. When I use my basic T/Rx daughterboards I can tune the receiver to an specific frequency. Since the basic T/Rx doesn't have any LO, I would like to know where is physically that LO in the USRP2 motherboard. I cannot find anything in the schematics. Where is it? Is that LO the one which translates from IF (coming from the daughterboards) to real base band? Thanks in advance, Jorge ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] LO of the USRP2 motherboard
On 11/10/2010 02:20 AM, Jorge Miguel wrote: Hi, I have an easy question. When I use my basic T/Rx daughterboards I can tune the receiver to an specific frequency. Since the basic T/Rx doesn't have any LO, I would like to know where is physically that LO in the USRP2 motherboard. I cannot find anything in the schematics. Where is it? Is that LO the one which translates from IF (coming from the daughterboards) to real base band? Thanks in advance, Jorge There is no LO, per-se on the USRP2 motherboard, only the various digital clocks used by parts on the motherboard, including the ADCs/DACs, and the FPGA. When you're using a BASIC_RX/LF_RX and you tune, the FPGA uses a DDC (Digital Downconverter) to digitally downconvert your desired frequency range to baseband. On the USRP2, the BASIC_RX or LF_RX is sampled at 100MHz, so the FPGA sees from roughly DC to roughly 50MHz. Within that range, the FPGA DDC converts whatever you ask it to into a complex baseband, which is what the host computer sees. -- 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
