Re: [Discuss-gnuradio] questions about USRP2 sink block and upconversion
Hi Marcus, thanks a lot for sending the flowgraph. I completely understand it and I am very confident that I can get this going. Only thing, I currently don't have an external 3,5mm plugged microphone :-) BR Markus DL8RDS Am Mittwoch, den 03.11.2010, 23:54 -0400 schrieb Marcus D. Leech: On 11/03/2010 11:11 PM, Markus Heller M.A. (relix GmbH) wrote: Hi Marcus, great, now I know what was wrong. I didn't expect my dummy load to be so safe. It was a real signal lock :-) For all the others, here's a short experiment report: Here are the parameters: * Sample rate 200k * Signal source at 1 KHz, amplitude at a minimum of 0.001 - to make sure that a bad SWR does no harm. BTW, this is a good counter check that you can really influence the output power! * USRP2 sink: interpolation 500, frequency 14 MHz Result: I hear a clear signal at 14.000 MHz, +/- 1 kHz Thanks very much! In the spirit of a conspiracy of Mar[ck]uses: http://www.sbrac.org/files/ssb_xmitter.grc It's not actually connected to USRP2, but to an FFT sink, but it samples at 200KHz, so one could easily replace that FFT block with an USRP2 block. It uses an audio source sampled at 20KHz, and then uses a bandpass filter after interpolating up to 200KHz to pick off either the upper or lower side-bands, which are limited to a roughly 2.7KHz bandwidth: LSB: -3KHz to -300Hz and USB: 300Hz to 3KHz. Audio and baseband signal levels will need to be adjusted, etc, but it's a good starting point. It uses a 0Hz carrier, which happens to work perfectly when you're dealing with a complex baseband signal. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] time stamped transmission with usrp1 supported in UHD?
I know time stamped tx/rx with usrp2 is supported in uhd. According to past posts, support for usrp1 was worked on. Could anyone give an update on that progress? Is it already done? Regards Kyle ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Preamble
Hi, I found the appended THread in the archive. That time, there was no answer to this mail. But I have exactly the same problem to understand the architecture of the packets. It would be nice, if anyone could write a short explanation why the \x55 and the preamble are added to the packet. Thanks a lot. Regards, Tobias Hi all, I was going through the pkt.py and packet_utils.py just to try and understand how packets are generated. Is it right to say that preamble has not being added to the payload? (packed_preamble, _*ignore*_) = conv_1_0_string_to_packed_binary_string(preamble) If it is being added how is it helpful on the receiver side because i don't see where it has been used or extracted. I know that it can be used to contain the training sequence for channel estimation but i doubt it has been used for the same here. I can only see the access code correlator to mark the beginning of payload and no correlator for the preamble. Is it right to assume that the access code correlator alone can be suffice? What is the significance of _*'\x55'*_ at the end of the packet before introducing usrp pad? I am asking because according to my understanding it should make the end of payload(post amble) but I don't see a correlator for it. Kind regards, Nelson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] throttle blocks and GUI responsiveness
On Tue, Nov 2, 2010 at 8:24 PM, Dan Harasty dhara...@telcordia.com wrote: Hello, all. I'm still getting up to speed on gnuradio (does that make me a gnoob? or maybe a gnuub?)... ;-) Anyway, to learn how to instrument a simple flowgraph with a wxPython GUI elements, I conceived of something simple to just play audible tones. Like a simple monotone piano keyboard. The good news is I found getting wxPython working was not as difficult as I thought it would be. However, I've found that there is a pretty big lag between GUI button clicks and hearing the tone go on, off, or change pitch. Say: about a second. So I know enough GR to surmise that lots of samples are getting buffered, and that is the cause of the perceived lag. I don't need micro-second level synchronizing between GUI button keypress events and tone output but getting it to under a tenth of a second would be good. Some of you probably already know exactly what I need to do (and I look forward to your reply). For the rest of you, I'll give you the blow-by-blow of what I tried, anyways. The basic graph is the same as the dialtone.py example: Tone 1 --- + Adder --- Audio Sync Tone 2 --- + Yes I said it was a monotone keyboard. But what I mean by that is you can only play one NOTE at a time. We'll assume the note has two components, and I need to add them. 1) So first I tried starting and stopping the graph upon keydown / keyup from the GUI. I would set the tones' frequency value before starting the graphs. Alas, this seemed to crash the graph. 2) So I figured in addition to setting the frequency, I would set the tone's amplitude. Now I notice a big lag between keydown and tone starting, and keyup and tone stopping. 3) Ah... just add a throttle block, and control the amplitude after the throttle. Tone 1 --- + Adder --- Throttle --- Mult by Constant --- Audio Sync Tone 2 --- + I have keydown set the mult. const. to 1, and keyup set it to 0. Keydown also sets the tones' frequencies. OK, now my tone starts and stop in close sync with the GUI button but the upon keydown, I still hear a burst of the former frequency... again, because the samples have been buffered. 4) So next I got really confused, and wrote this. I worked hard to think of where I could put the throttle block to ensure that there are no buffered samples at the previous frequency. And, well, it doesn't seem there IS anyplace. For example, I considered this: Tone 1 --- Throttle --- + Adder --- Mult by Constant --- Audio Sync Tone 2 --- Throttle --- + but a) doesn't solve the problem that the tone blocks can still buffer lots of on the throttle inputs, and b) it gives me pause to have two throttle blocks (even at the same rate). What's the right answer here? -- Dan Harasty You never need to use two throttle blocks in a flow graph. Also, if you have anything else that clocks the samples, you don't need a throttle block. In your case, if you have an audio output block, that's going to determine the sample rate of the entire system, so there is no need for a throttle. Throttle is _only_ necessary if you have nothing else that limits the sample rate (eg, a USRP or audio source/sink) and when you want to limit the CPU. Mostly, this tends to be useful for running with graphical sinks. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] throttle blocks and GUI responsiveness
Tom, Thanks for the input. I follow your philosophical point: multiple rate limiting blocks are at best redundant, and at worst may cause problems. But in my case, I'm trying get something nearly synchronized with a user-interface action: a button press. Thus, all the buffering is working against my purposes and I figured throttle blocks may be the answer. (It sort of worked a little bit.) Perhaps I'll have more luck just starting and stopping the flowgraph (if I can figure out why it seemed to crash when I first tried that). Or I've heard of another method to limit the amount of buffered data: messing with buffer sizes. I'm not sure how to do that, or if it would work. Was hoping someone could give me the recipe, if it is a viable approach. -- Dan On 11/4/2010 10:05 AM, Tom Rondeau wrote: On Tue, Nov 2, 2010 at 8:24 PM, Dan Harastydhara...@telcordia.com wrote: Hello, all. I'm still getting up to speed on gnuradio (does that make me a gnoob? or maybe a gnuub?)... ;-) Anyway, to learn how to instrument a simple flowgraph with a wxPython GUI elements, I conceived of something simple to just play audible tones. Like a simple monotone piano keyboard. The good news is I found getting wxPython working was not as difficult as I thought it would be. However, I've found that there is a pretty big lag between GUI button clicks and hearing the tone go on, off, or change pitch. Say: about a second. So I know enough GR to surmise that lots of samples are getting buffered, and that is the cause of the perceived lag. I don't need micro-second level synchronizing between GUI button keypress events and tone output but getting it to under a tenth of a second would be good. Some of you probably already know exactly what I need to do (and I look forward to your reply). For the rest of you, I'll give you the blow-by-blow of what I tried, anyways. The basic graph is the same as the dialtone.py example: Tone 1 --- + Adder --- Audio Sync Tone 2 --- + Yes I said it was a monotone keyboard. But what I mean by that is you can only play one NOTE at a time. We'll assume the note has two components, and I need to add them. 1) So first I tried starting and stopping the graph upon keydown / keyup from the GUI. I would set the tones' frequency value before starting the graphs. Alas, this seemed to crash the graph. 2) So I figured in addition to setting the frequency, I would set the tone's amplitude. Now I notice a big lag between keydown and tone starting, and keyup and tone stopping. 3) Ah... just add a throttle block, and control the amplitude after the throttle. Tone 1 --- + Adder --- Throttle --- Mult by Constant --- Audio Sync Tone 2 --- + I have keydown set the mult. const. to 1, and keyup set it to 0. Keydown also sets the tones' frequencies. OK, now my tone starts and stop in close sync with the GUI button but the upon keydown, I still hear a burst of the former frequency... again, because the samples have been buffered. 4) So next I got really confused, and wrote this. I worked hard to think of where I could put the throttle block to ensure that there are no buffered samples at the previous frequency. And, well, it doesn't seem there IS anyplace. For example, I considered this: Tone 1 --- Throttle --- + Adder --- Mult by Constant --- Audio Sync Tone 2 --- Throttle --- + but a) doesn't solve the problem that the tone blocks can still buffer lots of on the throttle inputs, and b) it gives me pause to have two throttle blocks (even at the same rate). What's the right answer here? -- Dan Harasty You never need to use two throttle blocks in a flow graph. Also, if you have anything else that clocks the samples, you don't need a throttle block. In your case, if you have an audio output block, that's going to determine the sample rate of the entire system, so there is no need for a throttle. Throttle is _only_ necessary if you have nothing else that limits the sample rate (eg, a USRP or audio source/sink) and when you want to limit the CPU. Mostly, this tends to be useful for running with graphical sinks. Tom attachment: dharasty.vcf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Ubuntu 10.04 LTS
I just followed the build instructions for GnuRadio 3.3.0 on Ubuntu 10.04 LTS. All the dependencies updated/installed without trouble, and the ./configure make sudo make install worked fine. However, trying to run gnuradio-compainion failed, and produced a misleading suggestion to check the PYTHONPATH environment variable. The real solution was to run sudo ldconfig. After this, everytning ran without problems. Perhaps the 10.04 build instructions should be updated. In any event, it would seem that the make install target should include running ldconfig at the end. @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: ATSC decoding - Now Working!
On Thu, Nov 04, 2010 at 12:30:51AM -0400, Achilleas Anastasopoulos wrote: Nick and others, I have decoded a capture of ATSC that Nick provided (many thanks). Here are some numbers for double-checking: 3) the output of the field_sync_demux (pipe_5) is ~455MB which i don't know what it corresponds to since i do not know the atsc_soft_data_segment data structure details (btw, where is it defined?) It's in atsc_types.h At this point i don't know if i am getting what i am supposed to get. For one thing, the equalizer output (stream 0) does not look like a nice 8-PAM signal Also, i don't know how to view the mpeg stream; VLC does not like it... I haven't tried in a long time, but I used to use xine to play the mpeg transport stream. It could be that VLC is just missing a plugin for it. I'm guessing that mplayer will play it too. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gcc 4.5 and GNU Radio 3.3.0
It took me a while to get some time to go back to my openSUSE 11.3 machine and regenerate the error message. Sorry, I should have done this when I made the initial post. So I successfully installed the following from source under openSUSE 11.3: Cheetah-2.4.2.1.tar.gz Markdown-2.0.3.tar.gz cppunit-1.12.1.tar.gz fftw-3.2.2.tar.gz gsl-1.14.tar.gz numpy-1.4.1.tar.gz sdcc-2.9.0-i386-unknown-linux2.5.tar.bz2 swig-1.3.40.tar.gz Then I do a ./configure for GNU Radio 3.3.0, and it runs fine, and it reports it's going to build everything that I need/that it should. However, when I do a make, it runs for a while, but then I get these errors: libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../.. -I/opt/pkgs/gnuradio-3.3.0/usrp2/host/include -I/opt/pkgs/gnuradio-3.3.0/usrp2/firmware/include -I/usr/include -I/usr/include -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/runtime -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/general -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/general -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/gengen -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/gengen -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/filter -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/filter -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/missing -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/reed-solomon -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/viterbi -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/io -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/g72x -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/swig -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/hier -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/swig -I/usr/local/include -I/usr/local/include -I/opt/pkgs/gnuradio-3.3.0/gruel/src/include -I/opt/pkgs/gnuradio-3.3.0/gruel/src/include -I/usr/local/include -I/opt/pkgs/gnuradio-3.3.0/gruel/src/include -I/opt/pkgs/gnuradio-3.3.0/gruel/src/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT usrp2.lo -MD -MP -MF .deps/usrp2.Tpo -c usrp2.cc -fPIC -DPIC -o .libs/usrp2.o usrp2.cc:41:33: error: type/value mismatch at argument 1 in template parameter list for ‘templateclass T class boost::weak_ptr’ usrp2.cc:41:33: error: expected a type, got ‘usrp2::usrp2::usrp2’ usrp2.cc:43:75: error: type/value mismatch at argument 1 in template parameter list for ‘templateclass T class boost::weak_ptr’ usrp2.cc:43:75: error: expected a type, got ‘usrp2::usrp2::usrp2’ usrp2.cc: In static member function ‘static usrp2::usrp2::sptr usrp2::usrp2::find_existing_or_make_new(const std::string, usrp2::props*, size_t)’: usrp2.cc:60:20: error: request for member ‘expired’ in ‘p.__gnu_cxx::__normal_iterator_Iterator, _Container::operator- [with _Iterator = usrp2::usrp_table_entry*, _Container = std::vectorusrp2::usrp_table_entry, __gnu_cxx::__normal_iterator_Iterator, _Container::pointer = usrp2::usrp_table_entry*]()-usrp2::usrp_table_entry::value’, which is of non-class type ‘int’ usrp2.cc:64:31: error: no matching function for call to ‘boost::shared_ptrusrp2::usrp2::shared_ptr(int)’ /usr/include/boost/smart_ptr/shared_ptr.hpp:182:5: note: candidates are: boost::shared_ptr template-parameter-1-1 ::shared_ptr() [with T = usrp2::usrp2] /usr/include/boost/smart_ptr/shared_ptr.hpp:169:1: note: boost::shared_ptrusrp2::usrp2::shared_ptr(const boost::shared_ptrusrp2::usrp2) usrp2.cc:73:23: error: expected type-specifier usrp2.cc:73:23: error: expected ‘)’ usrp2.cc:74:30: error: no matching function for call to ‘usrp2::usrp_table_entry::usrp_table_entry(std::string, usrp2::usrp2::sptr)’ usrp2.cc:43:5: note: candidates are: usrp2::usrp_table_entry::usrp_table_entry(const std::string, int) usrp2.cc:38:27: note: usrp2::usrp_table_entry::usrp_table_entry(const usrp2::usrp_table_entry) In file included from /usr/include/boost/shared_ptr.hpp:17:0, from /opt/pkgs/gnuradio-3.3.0/usrp2/host/include/usrp2/usrp2.h:22, from usrp2.cc:23: /usr/include/boost/smart_ptr/shared_ptr.hpp: In constructor ‘boost::shared_ptr template-parameter-1-1 ::shared_ptr(Y*) [with Y = int, T = usrp2::usrp2]’: usrp2.cc:73:56: instantiated from here /usr/include/boost/smart_ptr/shared_ptr.hpp:187:50: error: cannot convert ‘int*’ to ‘usrp2::usrp2*’ in initialization make[4]: *** [usrp2.lo] Error 1 make[4]: Leaving directory `/opt/pkgs/gnuradio-3.3.0/usrp2/host/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/opt/pkgs/gnuradio-3.3.0/usrp2/host' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/pkgs/gnuradio-3.3.0/usrp2' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/opt/pkgs/gnuradio-3.3.0' make: *** [all] Error 2 It looks like a problem with the Boost library. I don't have this problem in openSUSE 11.2 (which bundles gcc 4.4.1 and Boost 1.39), but it is not working for me with openSUSE 11.3 (which bundles gcc 4.5.0 and Boost 1.42). On this particular machine, I need
[Discuss-gnuradio] USRP2+WBX RX gain problems
Dear all! Myself and my colaborators have 2 USRP2+WBX boards. We use them in the 500-700 MHz band. The boards worked just fine until today, when we have used a stronger input signal generated by an Agilent signal generator connected directly via cable. The generated signal, a 2 MHz - large wideband signal had a maximum power of -16 dBm which was never exceeded. Most probably after using this signal, the board started to have problems, the sensibility being now much lower. We are forced now to raise the gain of the board to the maximum factor allowed (31.5) in order to see some valid signal at the input. The SNR ratio seems to be the same, but the signals which we previously detected with an external antenna around -40 dBm have now a level around -80 dBm. We never tried to use the board as a transmitter so we don't know if the problem is also on the TX branch. We would really appreciate any time of hint or tip regarding this problem. Also is there a general hardware reset, except the power off? Thank you very much! Vlad. -- View this message in context: http://old.nabble.com/USRP2%2BWBX-RX-gain-problems-tp30134322p30134322.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] gcc 4.5 and GNU Radio 3.3.0
You don't need to build everything by your own. Just download the RPMs from http://software.opensuse.org, put them on your usb-stick and install them with rpm -Uvh blablub.rpm As I mentioned above, it's no big deal to install and use an older gcc-version. Alternatively, you could try to patch the stable 3.3.0 version, so you can compile with gcc45. An approach would be to diff the appropriate files with their equivalent from the next-branch As the next-branch compiles without problems under openSUSE 11.3 and gcc45, there should be something changed in the sources. But just to use the older gcc is the easier way. Or you switch to the next-branch, which isn't unstable (at least for me). Gregor 2010/11/4 Steve Mcmahon steve.mcmaho...@yahoo.com: It took me a while to get some time to go back to my openSUSE 11.3 machine and regenerate the error message. Sorry, I should have done this when I made the initial post. So I successfully installed the following from source under openSUSE 11.3: Cheetah-2.4.2.1.tar.gz Markdown-2.0.3.tar.gz cppunit-1.12.1.tar.gz fftw-3.2.2.tar.gz gsl-1.14.tar.gz numpy-1.4.1.tar.gz sdcc-2.9.0-i386-unknown-linux2.5.tar.bz2 swig-1.3.40.tar.gz Then I do a ./configure for GNU Radio 3.3.0, and it runs fine, and it reports it's going to build everything that I need/that it should. However, when I do a make, it runs for a while, but then I get these errors: libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../.. -I/opt/pkgs/gnuradio-3.3.0/usrp2/host/include -I/opt/pkgs/gnuradio-3.3.0/usrp2/firmware/include -I/usr/include -I/usr/include -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/runtime -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/general -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/general -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/gengen -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/gengen -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/filter -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/filter -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/missing -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/reed-solomon -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/viterbi -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/io -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/g72x -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/swig -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/hier -I/opt/pkgs/gnuradio-3.3.0/gnuradio-core/src/lib/swig -I/usr/local/include -I/usr/local/include -I/opt/pkgs/gnuradio-3.3.0/gruel/src/include -I/opt/pkgs/gnuradio-3.3.0/gruel/src/include -I/usr/local/include -I/opt/pkgs/gnuradio-3.3.0/gruel/src/include -I/opt/pkgs/gnuradio-3.3.0/gruel/src/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT usrp2.lo -MD -MP -MF .deps/usrp2.Tpo -c usrp2.cc -fPIC -DPIC -o .libs/usrp2.o usrp2.cc:41:33: error: type/value mismatch at argument 1 in template parameter list for ‘templateclass T class boost::weak_ptr’ usrp2.cc:41:33: error: expected a type, got ‘usrp2::usrp2::usrp2’ usrp2.cc:43:75: error: type/value mismatch at argument 1 in template parameter list for ‘templateclass T class boost::weak_ptr’ usrp2.cc:43:75: error: expected a type, got ‘usrp2::usrp2::usrp2’ usrp2.cc: In static member function ‘static usrp2::usrp2::sptr usrp2::usrp2::find_existing_or_make_new(const std::string, usrp2::props*, size_t)’: usrp2.cc:60:20: error: request for member ‘expired’ in ‘p.__gnu_cxx::__normal_iterator_Iterator, _Container::operator- [with _Iterator = usrp2::usrp_table_entry*, _Container = std::vectorusrp2::usrp_table_entry, __gnu_cxx::__normal_iterator_Iterator, _Container::pointer = usrp2::usrp_table_entry*]()-usrp2::usrp_table_entry::value’, which is of non-class type ‘int’ usrp2.cc:64:31: error: no matching function for call to ‘boost::shared_ptrusrp2::usrp2::shared_ptr(int)’ /usr/include/boost/smart_ptr/shared_ptr.hpp:182:5: note: candidates are: boost::shared_ptr template-parameter-1-1 ::shared_ptr() [with T = usrp2::usrp2] /usr/include/boost/smart_ptr/shared_ptr.hpp:169:1: note: boost::shared_ptrusrp2::usrp2::shared_ptr(const boost::shared_ptrusrp2::usrp2) usrp2.cc:73:23: error: expected type-specifier usrp2.cc:73:23: error: expected ‘)’ usrp2.cc:74:30: error: no matching function for call to ‘usrp2::usrp_table_entry::usrp_table_entry(std::string, usrp2::usrp2::sptr)’ usrp2.cc:43:5: note: candidates are: usrp2::usrp_table_entry::usrp_table_entry(const std::string, int) usrp2.cc:38:27: note: usrp2::usrp_table_entry::usrp_table_entry(const usrp2::usrp_table_entry) In file included from /usr/include/boost/shared_ptr.hpp:17:0, from /opt/pkgs/gnuradio-3.3.0/usrp2/host/include/usrp2/usrp2.h:22, from usrp2.cc:23: /usr/include/boost/smart_ptr/shared_ptr.hpp: In constructor ‘boost::shared_ptr template-parameter-1-1 ::shared_ptr(Y*) [with Y = int, T = usrp2::usrp2]’:
[Discuss-gnuradio] CPU Utilization and USRP2
Hi All, I've noticed that the C++ interfaces provided in gnu-radio and UHD for usrp2 data streaming are CPU-intensive (UHD moreso than gnu-radio). I am wondering if there are easy ways to mitigate this or are there plans in the future to diminish these. For UHD a decimate by 16 process chews up 75% of a CPU just on the uhd::device::recv functiion (not much less even when I use RECV_MODE_FULL_BUFF and size the buffer to be 100x the size of a single packet). For gnuradio's the CPU utilization is more like 36% - still a lot. I may try to recode some of the lower-level interfaces in UHD if there is not an easy way to help improve CPU utilization. Thanks for your help, David ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CPU Utilization and USRP2
Well, there is extra overhead. A pirate thread in the the receive path spins on the socket and inspects the contents. The packet may be an asynchronous message packet for flow control or destined for the user. Or it may be a data packet, in which case it is placed into a queue to be popped off by the device::recv() call. No extra memcopies, its just managing pointers. Could this pirate thread be removed? If the async messages came in over a different UDP port, and the multi-device buffer alignment logic was re-written to be event driven (when recv() is called). Then yes. And I will probably implement this when I get the time. :-) So, my best guess is that you are mostly seeing the overhead of the thread inspecting the packets. Of course there is also additional overhead added by using UDP, parsing VRT packets, parsing inline message packets. Thanks for testing it out BTW! -Josh On 11/04/2010 10:46 AM, David Campbell wrote: Hi All, I've noticed that the C++ interfaces provided in gnu-radio and UHD for usrp2 data streaming are CPU-intensive (UHD moreso than gnu-radio). I am wondering if there are easy ways to mitigate this or are there plans in the future to diminish these. For UHD a decimate by 16 process chews up 75% of a CPU just on the uhd::device::recv functiion (not much less even when I use RECV_MODE_FULL_BUFF and size the buffer to be 100x the size of a single packet). For gnuradio's the CPU utilization is more like 36% - still a lot. I may try to recode some of the lower-level interfaces in UHD if there is not an easy way to help improve CPU utilization. Thanks for your help, David ___ 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] CPU Utilization and USRP2
This reminds me of a question. What do you guys use for profiling native code on Linux? I have a lot more experience on Mac OS where we have Shark, Instruments and the like. -Marc On Nov 4, 2010, at 2:23 PM, Josh Blum wrote: Well, there is extra overhead. A pirate thread in the the receive path spins on the socket and inspects the contents. The packet may be an asynchronous message packet for flow control or destined for the user. Or it may be a data packet, in which case it is placed into a queue to be popped off by the device::recv() call. No extra memcopies, its just managing pointers. Could this pirate thread be removed? If the async messages came in over a different UDP port, and the multi-device buffer alignment logic was re-written to be event driven (when recv() is called). Then yes. And I will probably implement this when I get the time. :-) So, my best guess is that you are mostly seeing the overhead of the thread inspecting the packets. Of course there is also additional overhead added by using UDP, parsing VRT packets, parsing inline message packets. Thanks for testing it out BTW! -Josh On 11/04/2010 10:46 AM, David Campbell wrote: Hi All, I've noticed that the C++ interfaces provided in gnu-radio and UHD for usrp2 data streaming are CPU-intensive (UHD moreso than gnu-radio). I am wondering if there are easy ways to mitigate this or are there plans in the future to diminish these. For UHD a decimate by 16 process chews up 75% of a CPU just on the uhd::device::recv functiion (not much less even when I use RECV_MODE_FULL_BUFF and size the buffer to be 100x the size of a single packet). For gnuradio's the CPU utilization is more like 36% - still a lot. I may try to recode some of the lower-level interfaces in UHD if there is not an easy way to help improve CPU utilization. Thanks for your help, David ___ 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 Rx triggering on PPS ... help
Hello all, I am building a USRP2 receiver that captures and stores data on the rising edge of the pps input. Is there a gnuradio block or C++ function that would allow me to monitor the pps input or see when its rising or falling edges occur? Thanks, Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CPU Utilization and USRP2
On 11/04/2010 03:23 PM, Josh Blum wrote: Well, there is extra overhead. A pirate thread in the the receive path spins on the socket and inspects the contents. The packet may be an asynchronous message packet for flow control or destined for the user. Or it may be a data packet, in which case it is placed into a queue to be popped off by the device::recv() call. No extra memcopies, its just managing pointers. When you say that this thread spins, do you mean that it's in an infinite loop, waiting on blocking, or non-blocking I/O? That is, does it pause while it waits for data, or is it in a tight CPU loop? -- 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] gcc 4.5 and GNU Radio 3.3.0
On Thu, Nov 04, 2010 at 10:17:04AM -0700, Steve Mcmahon wrote: It took me a while to get some time to go back to my openSUSE 11.3 machine and regenerate the error message. Sorry, I should have done this when I made the initial post. So I successfully installed the following from source under openSUSE 11.3: Cheetah-2.4.2.1.tar.gz Markdown-2.0.3.tar.gz cppunit-1.12.1.tar.gz fftw-3.2.2.tar.gz gsl-1.14.tar.gz numpy-1.4.1.tar.gz sdcc-2.9.0-i386-unknown-linux2.5.tar.bz2 swig-1.3.40.tar.gz Then I do a ./configure for GNU Radio 3.3.0, and it runs fine, and it reports it's going to build everything that I need/that it should. However, when I do a make, it runs for a while, but then I get these errors: There's a much easier way to get where you're headed. Use the master branch in git. I'm pretty sure it has this problem fixed. http://www.gnuradio.org/redmine/wiki/gnuradio/Download Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CPU Utilization and USRP2
On Thu, Nov 04, 2010 at 03:07:42PM -0500, Marc Epard wrote: This reminds me of a question. What do you guys use for profiling native code on Linux? I have a lot more experience on Mac OS where we have Shark, Instruments and the like. Marc, I like to use oprofile. It's packaged for Fedora and Ubuntu (and probably the rest). It gets the job done using the h/w performance counters, and as such, the measurement doesn't perturb the regular execution time, and there's no need to recompile with special options. It would be a great tool to use on this UHD problem to get a better idea of exactly where the cycles are getting burned. http://oprofile.sourceforge.net/docs On Fedora 13: $ rpm -qa | grep -i oprofile oprofile-0.9.6-6.fc13.x86_64 oprofile-gui-0.9.6-6.fc13.x86_64 Eric On Nov 4, 2010, at 2:23 PM, Josh Blum wrote: Well, there is extra overhead. A pirate thread in the the receive path spins on the socket and inspects the contents. The packet may be an asynchronous message packet for flow control or destined for the user. Or it may be a data packet, in which case it is placed into a queue to be popped off by the device::recv() call. No extra memcopies, its just managing pointers. Could this pirate thread be removed? If the async messages came in over a different UDP port, and the multi-device buffer alignment logic was re-written to be event driven (when recv() is called). Then yes. And I will probably implement this when I get the time. :-) So, my best guess is that you are mostly seeing the overhead of the thread inspecting the packets. Of course there is also additional overhead added by using UDP, parsing VRT packets, parsing inline message packets. Thanks for testing it out BTW! -Josh On 11/04/2010 10:46 AM, David Campbell wrote: Hi All, I've noticed that the C++ interfaces provided in gnu-radio and UHD for usrp2 data streaming are CPU-intensive (UHD moreso than gnu-radio). I am wondering if there are easy ways to mitigate this or are there plans in the future to diminish these. For UHD a decimate by 16 process chews up 75% of a CPU just on the uhd::device::recv functiion (not much less even when I use RECV_MODE_FULL_BUFF and size the buffer to be 100x the size of a single packet). For gnuradio's the CPU utilization is more like 36% - still a lot. I may try to recode some of the lower-level interfaces in UHD if there is not an easy way to help improve CPU utilization. Thanks for your help, David ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CPU Utilization and USRP2
On 11/04/2010 01:25 PM, Marcus D. Leech wrote: On 11/04/2010 03:23 PM, Josh Blum wrote: Well, there is extra overhead. A pirate thread in the the receive path spins on the socket and inspects the contents. The packet may be an asynchronous message packet for flow control or destined for the user. Or it may be a data packet, in which case it is placed into a queue to be popped off by the device::recv() call. No extra memcopies, its just managing pointers. When you say that this thread spins, do you mean that it's in an infinite loop, waiting on blocking, or non-blocking I/O? That is, does it pause while it waits for data, or is it in a tight CPU loop? its a blocking call to a socket ::recv with a timeout ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CPU Utilization and USRP2
On Thu, Nov 4, 2010 at 4:07 PM, Marc Epard mep...@me.com wrote: This reminds me of a question. What do you guys use for profiling native code on Linux? I have a lot more experience on Mac OS where we have Shark, Instruments and the like. -Marc Generally, I've used Oprofile. I have recently been exploring cachegrind and callgrind (with valgrind) for use with Kcachegrind. I'm really liking how it displays the results, but I'm still fairly new with it (note: you can also use Kcachegrind with oprofile output). Tom On Nov 4, 2010, at 2:23 PM, Josh Blum wrote: Well, there is extra overhead. A pirate thread in the the receive path spins on the socket and inspects the contents. The packet may be an asynchronous message packet for flow control or destined for the user. Or it may be a data packet, in which case it is placed into a queue to be popped off by the device::recv() call. No extra memcopies, its just managing pointers. Could this pirate thread be removed? If the async messages came in over a different UDP port, and the multi-device buffer alignment logic was re-written to be event driven (when recv() is called). Then yes. And I will probably implement this when I get the time. :-) So, my best guess is that you are mostly seeing the overhead of the thread inspecting the packets. Of course there is also additional overhead added by using UDP, parsing VRT packets, parsing inline message packets. Thanks for testing it out BTW! -Josh On 11/04/2010 10:46 AM, David Campbell wrote: Hi All, I've noticed that the C++ interfaces provided in gnu-radio and UHD for usrp2 data streaming are CPU-intensive (UHD moreso than gnu-radio). I am wondering if there are easy ways to mitigate this or are there plans in the future to diminish these. For UHD a decimate by 16 process chews up 75% of a CPU just on the uhd::device::recv functiion (not much less even when I use RECV_MODE_FULL_BUFF and size the buffer to be 100x the size of a single packet). For gnuradio's the CPU utilization is more like 36% - still a lot. I may try to recode some of the lower-level interfaces in UHD if there is not an easy way to help improve CPU utilization. Thanks for your help, David ___ 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 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] precise transmit scheduling
Dear all,I am developing a transmitter on USRP1 with LFTX daughterboard. This transmitter sends a BPSK modulated Barker code sequence up-converting to a frequency ranging from 1MHz to 20MHz. I implemented the transmission of the whole sequence in one fixed frequency in the requried range on one USRP1 board and receiving on the other USRP1 board. My question is :How can I scheduling the transmitter by sending several bits of the sequence a time and the delays between each time transmitting are 1ms?How can the RF frequency be linearly hopping from 1MHz to 20MHz by secheduling?I've seen that m-blocks appears partially motivated by precise scheduling of transmission. Is the m-block implements is suitable for this scheduling? If so, could anyone give me any suggestion on how can it implement the scheduling for my project? Tons of thanks in advance! I really need your help with this scheduling.Sincerely,Yan attachment: ynie3.vcf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gcc 4.5 and GNU Radio 3.3.0
On Thu, Nov 4, 2010 at 5:06 PM, Eric Blossom e...@comsec.com wrote: On Thu, Nov 04, 2010 at 10:17:04AM -0700, Steve Mcmahon wrote: It took me a while to get some time to go back to my openSUSE 11.3 machine and regenerate the error message. Sorry, I should have done this when I made the initial post. So I successfully installed the following from source under openSUSE 11.3: Cheetah-2.4.2.1.tar.gz Markdown-2.0.3.tar.gz cppunit-1.12.1.tar.gz fftw-3.2.2.tar.gz gsl-1.14.tar.gz numpy-1.4.1.tar.gz sdcc-2.9.0-i386-unknown-linux2.5.tar.bz2 swig-1.3.40.tar.gz Then I do a ./configure for GNU Radio 3.3.0, and it runs fine, and it reports it's going to build everything that I need/that it should. However, when I do a make, it runs for a while, but then I get these errors: There's a much easier way to get where you're headed. Use the master branch in git. I'm pretty sure it has this problem fixed. http://www.gnuradio.org/redmine/wiki/gnuradio/Download Eric I just tried compiling from maint, master, and next on a new OpenSUSE 11.3 installation and all three compiled fine. It fails from the tarball for GNU Radio 3.3.0. So use one of the git versions for now. If you're on a machine not connected, just git clone gnuradio (master is probably the best branch to use) and tar it up to move it across to the other computer. That should work for you. When we get 3.3.1 out, this problem will be fixed. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] High pass frequency response with LFRX boards
Hi All, We're seeing pretty much the same thing on the USRP1 as this: http://www.ruby-forum.com/topic/206912#900641 It seems that there is a very significant roll-off at lower frequencies on the receive side which pretty much makes it unusable for our baseband signals. The aformentioned forum post suggests that it is not caused by the LFRX board and so is likely to be something in the fpga... Just to reiterate the questions from this forum post. 1) What on the FPGA is causing this frequency response? (and what can we do about it?) 2) Why does this happen only in the RX path? And the original poster also wanted to know: 3) According to http://gnuradio.org/redmine/wiki/1/USRP2GenFAQ reference: How can I use both A/D converters on the USRP2? feeding the signal to RX_B does not give ANY output on the ADC If anyone can offer any help at all with this it'd be much appreciated. Thanks, Drew -- Andrew Read +64 (03) 357 0787 Test Analyst Design Verification and Validation Team Tait Electronics Ltd === This email, including any attachments, is only for the intended addressee. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If the receiver is not the intended addressee, please accept our apologies, notify us by return, delete all copies and perform no other act on the email. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission. === ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] time stamped transmission with usrp1 supported in UHD?
USRP1 support is in the UHD, but no timestamps. -Josh On 11/04/2010 05:56 AM, Kyle Zhou wrote: I know time stamped tx/rx with usrp2 is supported in uhd. According to past posts, support for usrp1 was worked on. Could anyone give an update on that progress? Is it already done? Regards Kyle ___ 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] High pass frequency response with LFRX boards
On 11/04/2010 07:24 PM, Drew Read wrote: Hi All, We're seeing pretty much the same thing on the USRP1 as this: http://www.ruby-forum.com/topic/206912#900641 It seems that there is a very significant roll-off at lower frequencies on the receive side which pretty much makes it unusable for our baseband signals. The aformentioned forum post suggests that it is not caused by the LFRX board and so is likely to be something in the fpga... Just to reiterate the questions from this forum post. 1) What on the FPGA is causing this frequency response? (and what can we do about it?) 2) Why does this happen only in the RX path? And the original poster also wanted to know: 3) According to http://gnuradio.org/redmine/wiki/1/USRP2GenFAQ reference: How can I use both A/D converters on the USRP2? feeding the signal to RX_B does not give ANY output on the ADC If anyone can offer any help at all with this it'd be much appreciated. Thanks, Drew I can't speak for your flowgraph, but the referenced flow-graph in your post is mis-constructed in a couple of difference ways. The USRP2 input decimation is set to '101' -- odd decimations in USRP2 are *not recommended*. Plus, neither the SCOPE sink nor the FFT sink have been told the correct sample rate, so lord knows what they're actually showing in terms of frequency response. In USRP2, even decimation, preferrably a multiple of 4. I've noticed no low-frequency rolloff in my applications with either the USRP1 or USRP2. -- 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] High pass frequency response with LFRX boards
On 11/04/2010 04:24 PM, Drew Read wrote: It seems that there is a very significant roll-off at lower frequencies on the receive side which pretty much makes it unusable for our baseband signals. The aformentioned forum post suggests that it is not caused by the LFRX board and so is likely to be something in the fpga... Just to reiterate the questions from this forum post. 1) What on the FPGA is causing this frequency response? (and what can we do about it?) 2) Why does this happen only in the RX path? You're probably seeing the high-pass behavior of the RX DC offset removal. There's a logical block inside the FPGA which integrates the ADC DC offset and subtracts it from the incoming signal. This function isn't needed on the TX side. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] High pass frequency response with LFRX boards
On 11/04/2010 07:47 PM, Eric Brombaugh wrote: You're probably seeing the high-pass behavior of the RX DC offset removal. There's a logical block inside the FPGA which integrates the ADC DC offset and subtracts it from the incoming signal. This function isn't needed on the TX side. Would it have such a high corner-frequency, though? Seems like the DC estimate integrator function could easily be arranged to have a corner frequency much lower than 1KHz. But maybe I'm wrong. -- 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] gcc 4.5 and GNU Radio 3.3.0
On Thursday, November 04, 2010 02:35:32 pm Tom Rondeau wrote: On Thu, Nov 4, 2010 at 5:06 PM, Eric Blossom e...@comsec.com wrote: On Thu, Nov 04, 2010 at 10:17:04AM -0700, Steve Mcmahon wrote: It took me a while to get some time to go back to my openSUSE 11.3 machine and regenerate the error message. Sorry, I should have done this when I made the initial post. So I successfully installed the following from source under openSUSE 11.3: Cheetah-2.4.2.1.tar.gz Markdown-2.0.3.tar.gz cppunit-1.12.1.tar.gz fftw-3.2.2.tar.gz gsl-1.14.tar.gz numpy-1.4.1.tar.gz sdcc-2.9.0-i386-unknown-linux2.5.tar.bz2 swig-1.3.40.tar.gz Then I do a ./configure for GNU Radio 3.3.0, and it runs fine, and it reports it's going to build everything that I need/that it should. However, when I do a make, it runs for a while, but then I get these errors: There's a much easier way to get where you're headed. Use the master branch in git. I'm pretty sure it has this problem fixed. http://www.gnuradio.org/redmine/wiki/gnuradio/Download Eric I just tried compiling from maint, master, and next on a new OpenSUSE 11.3 installation and all three compiled fine. It fails from the tarball for GNU Radio 3.3.0. So use one of the git versions for now. If you're on a machine not connected, just git clone gnuradio (master is probably the best branch to use) and tar it up to move it across to the other computer. That should work for you. When we get 3.3.1 out, this problem will be fixed. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio There is a patch for GCC4.5. I found it on Fedore. let me know if you ned it -- Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] High pass frequency response with LFRX boards
Yes! that seems to be doing it. After using u.set_dc_offset_cl_enable(0x0, 0xf) to disable the dc correction the Low Freq roll-off seems to be gone and my IQ looks a lot better. That's really excelent, I presume I'll still need to compensate for the dc in my flow graph now though... Many thanks! Drew On Fri, Nov 5, 2010 at 1:08 PM, Marcus D. Leech mle...@ripnet.com wrote: On 11/04/2010 07:47 PM, Eric Brombaugh wrote: You're probably seeing the high-pass behavior of the RX DC offset removal. There's a logical block inside the FPGA which integrates the ADC DC offset and subtracts it from the incoming signal. This function isn't needed on the TX side. Would it have such a high corner-frequency, though? Seems like the DC estimate integrator function could easily be arranged to have a corner frequency much lower than 1KHz. But maybe I'm wrong. -- 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 -- Andrew Read +64 (03) 357 0787 Test Analyst Design Verification and Validation Team Tait Electronics Ltd === This email, including any attachments, is only for the intended addressee. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If the receiver is not the intended addressee, please accept our apologies, notify us by return, delete all copies and perform no other act on the email. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission. === ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to enable usrp1 in building uhd?
I am trying uhd with my usrp1. However, when I do cmake, it reported that usrp1 support disabled by configure flag. usrp2 is enabled. It seems to me usrp1 is disabled by default? If I need to give some flags to cmake to enable usrp1? I have no experience in cmake before. Please help Thanks Kyle ~/uhd/host/build$ cmake ../ -- Checking for git -- Checking for git - found -- Version: 20101102.160520.082f619 -- Using install prefix: /usr/local -- Build type not specified: defaulting to release. -- Checking for rst2html (docutils) -- Checking for rst2html (docutils) - found -- Enabled generation of HTML manual. -- Enabled generation of Doxygen documentation. -- Python checking for Python version 2.6 or greater -- Python checking for Python version 2.6 or greater - found -- Python checking for Cheetah templates 2.0.0 or greater -- Python checking for Cheetah templates 2.0.0 or greater - found -- Has USB support - found -- Configuring interface address discovery... -- Interface address discovery supported through getifaddrs. -- Configuring USRP1 support... -- USRP1 support disabled by configure flag -- Skipping USRP1 support. -- Configuring USRP2 support... -- USRP2 support enabled by configure flag -- Building USRP2 support. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to enable usrp1 in building uhd?
So its looks like it found USB support. My guess is that you ran the configure again after installing libusb1.0. Either remove the CMakeCache.txt and re-run cmake, or run the cmake command with the option -DENABLE_USRP1=TRUE -Josh On 11/04/2010 09:15 PM, Kyle Zhou wrote: I am trying uhd with my usrp1. However, when I do cmake, it reported that usrp1 support disabled by configure flag. usrp2 is enabled. It seems to me usrp1 is disabled by default? If I need to give some flags to cmake to enable usrp1? I have no experience in cmake before. Please help Thanks Kyle ~/uhd/host/build$ cmake ../ -- Checking for git -- Checking for git - found -- Version: 20101102.160520.082f619 -- Using install prefix: /usr/local -- Build type not specified: defaulting to release. -- Checking for rst2html (docutils) -- Checking for rst2html (docutils) - found -- Enabled generation of HTML manual. -- Enabled generation of Doxygen documentation. -- Python checking for Python version 2.6 or greater -- Python checking for Python version 2.6 or greater - found -- Python checking for Cheetah templates 2.0.0 or greater -- Python checking for Cheetah templates 2.0.0 or greater - found -- Has USB support - found -- Configuring interface address discovery... -- Interface address discovery supported through getifaddrs. -- Configuring USRP1 support... -- USRP1 support disabled by configure flag -- Skipping USRP1 support. -- Configuring USRP2 support... -- USRP2 support enabled by configure flag -- Building USRP2 support. ___ 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] How to enable usrp1 in building uhd?
or run cmake-gui and check the box for usrp1 :-) -Josh On 11/04/2010 09:15 PM, Kyle Zhou wrote: I am trying uhd with my usrp1. However, when I do cmake, it reported that usrp1 support disabled by configure flag. usrp2 is enabled. It seems to me usrp1 is disabled by default? If I need to give some flags to cmake to enable usrp1? I have no experience in cmake before. Please help Thanks Kyle ~/uhd/host/build$ cmake ../ -- Checking for git -- Checking for git - found -- Version: 20101102.160520.082f619 -- Using install prefix: /usr/local -- Build type not specified: defaulting to release. -- Checking for rst2html (docutils) -- Checking for rst2html (docutils) - found -- Enabled generation of HTML manual. -- Enabled generation of Doxygen documentation. -- Python checking for Python version 2.6 or greater -- Python checking for Python version 2.6 or greater - found -- Python checking for Cheetah templates 2.0.0 or greater -- Python checking for Cheetah templates 2.0.0 or greater - found -- Has USB support - found -- Configuring interface address discovery... -- Interface address discovery supported through getifaddrs. -- Configuring USRP1 support... -- USRP1 support disabled by configure flag -- Skipping USRP1 support. -- Configuring USRP2 support... -- USRP2 support enabled by configure flag -- Building USRP2 support. ___ 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
