[Discuss-gnuradio] bpsk lost some packet when transmit data discontinuously
Hi: I have some problem about dbpsk and bpsk using benchmark_tx/rx.py with some modification. My experiment set up was that the transmitter waits for a time delay (0.5 s) after sending a packet. It means that we transmit data discontinuously. If we using dbpsk modulation, we can successfully receive every packet. But if we removed the differential encoder/decoder (equals to bpsk modulation), we uaually lost some packet (almost half of the data lost). However, when we transmit data continuously,the bpsk modulation seems work fine and we can successfully receive every packet. My problem is that what reason causing the bpsk modulation can not successfully receive packet when transmit data discontinuously. Could anyone have any idea about it, please let me know. I am deeply appreciative. Fisheep :) -- View this message in context: http://old.nabble.com/bpsk-lost-some-packet-when-transmit-data-discontinuously-tp27832481p27832481.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] bpsk lost some packet when transmit data discontinuously
The problem does not lie with the bpsk modulator, the problem is in the packetizer. The packetizer waits until it gets enough data to completely fill up a packet, generally resulting in the loss of the last packet as there is not enough data to fill it perfectly. There is a modified copy of the packetizer.py that you could use that has been set up to handle this specific async digital communication scenario at http://code.google.com/p/softwaredefinedradio . If you look at .../trunk/src/Data_Path, there is a modified Python file for packetizer.py. You may also want to look at the dpsk.py file in this directory, as it shows how to set up the top level design to use a message queue for the asynchronous sending of packets. The last (useful) file in this director is the txrx_controller.py, which establishes a custom rudimentary protocol to ensure packet retrieval went well, and all information is received properly. There is some documentation for this in the Docs folder. -Michael Berman On Tue, Mar 9, 2010 at 12:03 AM, Fisheep fisheep0...@gmail.com wrote: Hi: I have some problem about dbpsk and bpsk using benchmark_tx/rx.py with some modification. My experiment set up was that the transmitter waits for a time delay (0.5 s) after sending a packet. It means that we transmit data discontinuously. If we using dbpsk modulation, we can successfully receive every packet. But if we removed the differential encoder/decoder (equals to bpsk modulation), we uaually lost some packet (almost half of the data lost). However, when we transmit data continuously,the bpsk modulation seems work fine and we can successfully receive every packet. My problem is that what reason causing the bpsk modulation can not successfully receive packet when transmit data discontinuously. Could anyone have any idea about it, please let me know. I am deeply appreciative. Fisheep :) -- View this message in context: http://old.nabble.com/bpsk-lost-some-packet-when-transmit-data-discontinuously-tp27832481p27832481.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possible bug in the vrt branch firmware?
If our library is providing a standard call to set the timestamps of returned samples, shouldn't the standard or default way to do it result in those timestamps being accurate wallclock UTC realtime, rather than counting up from zero or from a random number? If by default our streams of samples came back with accurate nanosecond timestamps, that would be a big plus in the long run. You could later sync up signals from receivers all around the world; recordings would contain the time when the signal was received; etc. Any computer on the Internet can easily sync using NTP to within about 10 ms or so, to set the high order bits. And anyone with a PPS clock hooked to their USRP would get real cesium-linked timestamps. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possible bug in the vrt branch firmware?
There was a gap in our understanding what those commands exactly do, and the problem was caused by telling the USRPs to start streaming in the past... Inserting sleep (1) did work. Thanks for the explanations! Valentin Josh Blum-2 wrote: If you just re-powered the device, time_spec_t(2, 1) is always a time in the past (by the time you get to run a usrp2 app) because of the time it takes for hardware/firmware initialization. If you need to rely on a specific time to be in the usrp2, use the set_time_now. If you need to use set_time_at_next_pps, give yourself 1 second to be sure that the time is latched into the registers before starting to stream. In the example you posted, there is no sleep time between the u2-set_time_at_next_pps(usrp2::time_spec_t(0, 0) and the u2-start_rx_streaming(0, usrp2::time_spec_t(2, 1). Therefore, set_time_at_next_pps will not take effect in time for the start_rx_streaming. And, start_rx_streaming will see a time in the registers that is unknown and very likely to be larger than time_spec_t(2, 1). As I said before, I believe there is a bug related to telling it to start streaming in the past. I could be wrong, but try to add the sleep just to remove the issue of telling it to start to stream with a time in the past. In general, you will always want to wait at least one second after set_time_at_next_pps before streaming so you can guarantee known values in the timestamps. -Josh On 03/08/2010 11:58 AM, ValentinG wrote: How u2-start_rx_streaming(0, usrp2::time_spec_t(2, 1)) is start streaming in the PAST? Isn't it 2 seconds later than the time we reset to which is (0,0)? Also we have tried changing the start streaming time to (5,1) which didn't help, hence I'm not sure if sleep(1) is going to make a difference... Josh Blum-2 wrote: There have been no recent changes to the images posted at http://www.ettus.com/usrp2_vrt I believe that there is a problem when you tell usrp2 to start streaming at a time in the past. I cannot verify this at the moment. Try putting a sleep(1) after the set time at next pps. By nature, set time at nest pps could take a second (worst case scenario) to latch in new values. -Josh On 03/08/2010 10:12 AM, ValentinG wrote: Hi All, We've tried editing the rx_timed_samples.cc to set the time on the USRPs on the next pps and then start streaming data some time after, by inserting the following code (instead of the existing one) between rx_handler my_handler(nsamples) and the while loop: //create a new usrp2 object, set some properties usrp2::usrp2::sptr u2 = usrp2::usrp2::make(interface, mac_addr_str); u2-set_rx_decim(16); //set the system time to the usrp2 u2-set_time_at_next_pps(usrp2::time_spec_t(0, 0)); //begin streaming in the future u2-start_rx_streaming(0, usrp2::time_spec_t(2, 1)); this code used to work in the middle of last week. We had to reflash our SD cards on Friday, so we downloaded the firmware from http://www.ettus.com/usrp2_vrt and flashed our cards with it. After doing that the above code just stopped working. Was there an update of firmware some time last week? Strangely enough it works if we set the time of the usrps to 200,0 instead of 0,0 and start streaming at 202, 1. But this fix only works for one acquisition, i.e. if we run the code one more time it just freezes and doesn't do anything, so to run it again we have to reset the usrps. We're using 1Hz TTL PPS as required by the USRP2 spec. Any ideas? Valentin ___ 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 -- View this message in context: http://old.nabble.com/Possible-bug-in-the-vrt-branch-firmware--tp27825201p27833980.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] GNU Radio and Fedora 12 - installation problems with no solution, who to contact?
Eric, thanks for your reply. $ python import wx returns no error. As far as I can tell wx libs are installed. Out of desperation I am trying to compile boost lib and see what happens If you have any idea please let me know. regards, fabrizio On Tue, Mar 9, 2010 at 3:24 PM, Eric Blossom e...@comsec.com wrote: On Tue, Mar 09, 2010 at 02:40:38PM +0100, Fabrizio Tappero wrote: Hello, I have followed the installation instructions to install GNU Radio for Fedora 12 http://gnuradio.org/redmine/wiki/1/FedoraInstall As described in here: http://lists.gnu.org/archive/html/discuss-gnuradio/2010-03/msg00139.html usrp_fft.py and many other python scripts will not run. I have repeated the installation from GNU Radio form source (via git) but got the same results. All dependencies seems OK but clearly there is something wrong. The problem could be with GNU Radio or with some dependencies. Or maybe with Fedora being on a Macbook 64 bit. I have spent several days on google and reading around but I am still lost. May I please ask the people behind the GNU Radio development for an advise on what to do in this case? Best regards, Fabrizio Sorry, no experience with your configuration (although I run 64-bit F12 on Linux), but from the backtrace it looks like the problem is in the wx or wxPython library (somewhere). Does make check work? Does this work: $ python import wx Does any non-GNU Radio wxPython app work? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] MA (Memory Acceleration) and SR-DVB in Karlsruhe, @ WSR10
Hi everybody, here are the links to 3 youtube videos covering SR-DVB Presentation http://www.youtube.com/watch?v=AfvLCh8ADxk SR-DVB Demo + MA (Memory Acceleration) Intro http://www.youtube.com/watch?v=XxXW4Gya918 Conclusions and first question http://www.youtube.com/watch?v=7EuqKYKc6mg (then the small DVD ended, unfortunately :( ) at WSR10, Karlsruhe during GNURadio-dedicated session. Links to Presented Paper and Presentation Slides are attached to each video :-) best regards to everybody vincenzo -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] problem in gnuradio installation PLEASE help
hi, thanks for your reply. i have done both and here is the output of ./configure: The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gr-gcell gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows These components will not be built. after that when i do make check i get : make[3]: Entering directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src' make check-TESTS make[4]: Entering directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src' Traceback (most recent call last): File ./qa_usrp.py, line 24, in module import usrp_swig File /home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src/usrp_swig.py, line 18, in module _usrp_swig = swig_import_helper() File /home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src/usrp_swig.py, line 16, in swig_import_helper if fp is not None: fp.close() UnboundLocalError: local variable 'fp' referenced before assignment FAIL: run_tests == 1 of 1 test failed == make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src' make[2]: *** [check] Error 2 make[2]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp' make: *** [check-recursive] Error 1 _ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2/FPGA Directory Removed
On 3/8/2010 6:40 PM, Matt Ettus wrote: It looks like your firewall is blocking the git protocol. You probably don't have problems with the GNU Radio git repo because it is served over http, but this one is only served over the git protocol. Matt Any chance you can setup your git repository to serve up over http for those sitting behind such-configured firewalls? I understand git over http isn't as efficient, but it would certainly make it more convenient. Doug -- Douglas Geiger Code 5545 U.S. Naval Research Laboratory Washington, DC 20375 (202) 767-9048 douglas.gei...@nrl.navy.mil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bpsk lost some packet when transmit data discontinuously
Thanks for your reply.
I thought that the problem can not get enough data to fill up a packet could
happen on any modulator.
But why we could receive every packet properly when using dbpsk and lost
packets when using bpsk?
(Under transmitting each packet with a time interval.)
And I went through the packetizer.py quickly and found that it seems that
different modulations have different packet preambles.
i.e.
preamble = conv_packed_binary_string_to_1_0_string('\xA4\xF2')
preamble_bpsk = conv_packed_binary_string_to_1_0_string('\x55\x55\x55')
preamble_qpsk =
conv_packed_binary_string_to_1_0_string('\x1E\x1E\x1E\x1E\x1E\x1E')
...
Does this different cause the bpsk can not receive data properly?
Again, Thanks for your reply. It really helps me a lot.
I am deeply appreciative.
Fisheep :)
Michael Berman-2 wrote:
The problem does not lie with the bpsk modulator, the problem is in the
packetizer. The packetizer waits until it gets enough data to completely
fill up a packet, generally resulting in the loss of the last packet as
there is not enough data to fill it perfectly.
There is a modified copy of the packetizer.py that you could use that has
been set up to handle this specific async digital communication scenario
at
http://code.google.com/p/softwaredefinedradio . If you look at
.../trunk/src/Data_Path, there is a modified Python file for
packetizer.py.
You may also want to look at the dpsk.py file in this directory, as it
shows
how to set up the top level design to use a message queue for the
asynchronous sending of packets. The last (useful) file in this director
is
the txrx_controller.py, which establishes a custom rudimentary protocol to
ensure packet retrieval went well, and all information is received
properly. There is some documentation for this in the Docs folder.
-Michael Berman
On Tue, Mar 9, 2010 at 12:03 AM, Fisheep fisheep0...@gmail.com wrote:
Hi:
I have some problem about dbpsk and bpsk using benchmark_tx/rx.py with
some
modification.
My experiment set up was that the transmitter waits for a time delay (0.5
s)
after sending a packet.
It means that we transmit data discontinuously.
If we using dbpsk modulation, we can successfully receive every packet.
But if we removed the differential encoder/decoder (equals to bpsk
modulation), we uaually
lost some packet (almost half of the data lost).
However, when we transmit data continuously,the bpsk modulation seems
work
fine and we can successfully receive every packet.
My problem is that what reason causing the bpsk modulation can not
successfully receive packet when
transmit data discontinuously.
Could anyone have any idea about it, please let me know.
I am deeply appreciative.
Fisheep :)
--
View this message in context:
http://old.nabble.com/bpsk-lost-some-packet-when-transmit-data-discontinuously-tp27832481p27832481.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
View this message in context:
http://old.nabble.com/bpsk-lost-some-packet-when-transmit-data-discontinuously-tp27832481p27836131.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] MA (Memory Acceleration) and SR-DVB in Karlsruhe, @ WSR10
Hi Vincenzo - Can you also provide links to your papers, both the WSR10 one and whatever you can on your MA technique? Enquiring minds will want to know more about MA ... Thanks! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio and Fedora 12 - installation problems with no solution, who to contact?
On Tue, Mar 09, 2010 at 02:40:38PM +0100, Fabrizio Tappero wrote: Hello, I have followed the installation instructions to install GNU Radio for Fedora 12 http://gnuradio.org/redmine/wiki/1/FedoraInstall As described in here: http://lists.gnu.org/archive/html/discuss-gnuradio/2010-03/msg00139.html usrp_fft.py and many other python scripts will not run. I have repeated the installation from GNU Radio form source (via git) but got the same results. All dependencies seems OK but clearly there is something wrong. The problem could be with GNU Radio or with some dependencies. Or maybe with Fedora being on a Macbook 64 bit. I have spent several days on google and reading around but I am still lost. May I please ask the people behind the GNU Radio development for an advise on what to do in this case? Best regards, Fabrizio Sorry, no experience with your configuration (although I run 64-bit F12 on Linux), but from the backtrace it looks like the problem is in the wx or wxPython library (somewhere). Does make check work? Does this work: $ python import wx Does any non-GNU Radio wxPython app work? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] IT++ functions
On Mon, Mar 08, 2010 at 08:42:03AM -0800, Johnathan Corgan wrote: If wrapping IT++ code with GNU Radio blocks is as straightforward as you say, it may be worth it to create a new, optional top-level component in gnuradio, say gr-itpp, that provides wrappers for some of the more useful bits. This wouldn't include any IT++ code itself; the component would just require having IT++ already installed as a build/runtime dependency. (For people not interested, it just wouldn't get configured for build at configure time.) I would encourage those on the list here to discuss the idea further, with an aim to figuring out what the low-hanging fruit would be. IT++ has some nice stuff, it's well documented and tested. Judging by the web site, development seems to have stalled at the moment, but from what I can tell, it seems to be at a pretty mature stage. I guess adding wrappers would be an easy way to enhance GNU Radio. Two things I'd like to add: - Performance might be an issue; it doesn't seem to have been a design criterion. This could become a problem when doing, e.g., Turbo decoding when processor time is already limited by other blocks. - I can't see a way (read: my C++ skills aren't that advanced) to create a generic wrapper which could take any IT++ block in a consistent manner. As far as I can tell, it would be necessary to create one GR block by hand for every IT++ function. The last point is not a big problem in my opinion, since there's not that much stuff in IT++ which is really interesting in GR (basically the channel models and the FECs). As I said, I already had a look at this and seeing there's some interest, I'd give it a hack. 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 pgplxyEQX0nnY.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] problem in gnuradio installation PLEASE help
hi, i did make check and following error appeared may be this will help us in solving the problem make[3]: Entering directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src' make check-TESTS make[4]: Entering directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src' Traceback (most recent call last): File ./qa_usrp.py, line 24, in module import usrp_swig File /home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src/usrp_swig.py, line 18, in module _usrp_swig = swig_import_helper() File /home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src/usrp_swig.py, line 16, in swig_import_helper if fp is not None: fp.close() UnboundLocalError: local variable 'fp' referenced before assignment FAIL: run_tests == 1 of 1 test failed == make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src' make[2]: *** [check] Error 2 make[2]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp' make: *** [check-recursive] Error 1 _ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problem in gnuradio installation PLEASE help
hi, im facing following problem for past two days in installing gnuradio 3.3.2 from tar.gz. i am using ubuntu 9.10 libtool: link: only absolute run-paths are allowed make[6]: *** [_gnuradio_swig_py_filter.la] Error 1 make[6]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gnuradio-core/src/lib/swig' make[5]: *** [all] Error 2 make[5]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gnuradio-core/src/lib/swig' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gnuradio-core/src/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gnuradio-core/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gnuradio-core' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/ahsan/hydra-0.4/gnuradio-3.2.2' make: *** [all] Error 2 please help me, i have searched a lot wrt previous threads but to no avail Regards, Sanam Hotmail: Trusted email with powerful SPAM protection. Sign up now. _ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. https://signup.live.com/signup.aspx?id=60969___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] dependencies with different name
Hi, I'm facing a problem while installing gnuradio. a message show : libgnuradio-qtgui0: Depends: libboost-thread1.37.0 (= 1.37.0-1) which is a virtual package. Ofcourse not only this package depends on libboost-thread1.37.0 there are many which create a huge problem. does this mean that this version can be installed after installing boost_1_37_0? if this correct, why after install boost_1_37_0 i found : libboost-thread1.37.0 named as libboost-thread1.38.0 thanks, -- View this message in context: http://old.nabble.com/dependencies-with-different-name-tp27834447p27834447.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio and Fedora 12 - installation problems with no solution, who to contact?
Hello, I have followed the installation instructions to install GNU Radio for Fedora 12 http://gnuradio.org/redmine/wiki/1/FedoraInstall As described in here: http://lists.gnu.org/archive/html/discuss-gnuradio/2010-03/msg00139.html usrp_fft.py and many other python scripts will not run. I have repeated the installation from GNU Radio form source (via git) but got the same results. All dependencies seems OK but clearly there is something wrong. The problem could be with GNU Radio or with some dependencies. Or maybe with Fedora being on a Macbook 64 bit. I have spent several days on google and reading around but I am still lost. May I please ask the people behind the GNU Radio development for an advise on what to do in this case? Best regards, Fabrizio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem in gnuradio installation PLEASE help
On Tue, Mar 09, 2010 at 12:53:34PM +, sanam singh wrote: hi, im facing following problem for past two days in installing gnuradio 3.3.2 from tar.gz. i am using ubuntu 9.10 Have you tried using $ ./bootstrap followed by $ ./configure ... Google says the problem is often related to use of -rpath somewhere, but I've never run into the problem. Eric libtool: link: only absolute run-paths are allowed make[6]: *** [_gnuradio_swig_py_filter.la] Error 1 make[6]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gnuradio-core/src/lib/swig' make[5]: *** [all] Error 2 make[5]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gnuradio-core/src/lib/swig' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gnuradio-core/src/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gnuradio-core/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gnuradio-core' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/ahsan/hydra-0.4/gnuradio-3.2.2' make: *** [all] Error 2 please help me, i have searched a lot wrt previous threads but to no avail Regards, Sanam ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2/FPGA Directory Removed
On 03/09/2010 06:08 AM, Doug Geiger wrote: On 3/8/2010 6:40 PM, Matt Ettus wrote: It looks like your firewall is blocking the git protocol. You probably don't have problems with the GNU Radio git repo because it is served over http, but this one is only served over the git protocol. Matt Any chance you can setup your git repository to serve up over http for those sitting behind such-configured firewalls? I understand git over http isn't as efficient, but it would certainly make it more convenient. Doug If you are blocked by your firewall, I would recommend talking to whoever made that decision and convince them to unblock port 9418. You can explain that just because a service is on a port other than 80 doesn't make it less secure, and that being on port 80 is no guarantee of safety. If that doesn't work, you can use the mirror here: http://github.com/EttusResearch/usrp-fpga-mirror Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] problem in gnuradio installation PLEASE help
I got the same error when i was installing gnuradio by compilation. maybe you should try to use the binary and source packages instead. regards, sanam singh wrote: hi, thanks for your reply. i have done both and here is the output of ./configure: The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gr-gcell gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows These components will not be built. after that when i do make check i get : make[3]: Entering directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src' make check-TESTS make[4]: Entering directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src' Traceback (most recent call last): File ./qa_usrp.py, line 24, in module import usrp_swig File /home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src/usrp_swig.py, line 18, in module _usrp_swig = swig_import_helper() File /home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src/usrp_swig.py, line 16, in swig_import_helper if fp is not None: fp.close() UnboundLocalError: local variable 'fp' referenced before assignment FAIL: run_tests == 1 of 1 test failed == make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src' make[2]: *** [check] Error 2 make[2]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp' make: *** [check-recursive] Error 1 _ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/problem-in-gnuradio-installation-PLEASE-help-tp27835243p27837818.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP synchronization
Hi All, We are trying to use 4 USRPs to extract the phase information due to differences in positions of the antennas. In a standard communications system an internally generated carrier is locked IN PHASE with the incoming signal to perform downconversion (see Figure 1.). http://old.nabble.com/file/p27838729/Fig%2B1%2BUSRP%2Bv2.jpg As mentioned above we are using 4 USRPs to receive a signal from a single source. We wish to retain the phase information of this signal between boxes due to the different positions of the antennas. We feed all 4 boxes with a clock reference signal (10MHz, 1.5Vpk-pk), so that their internal clocks should be locked in phase with respect to each other. Are the internally generated carriers generated using this clock as a phase reference, i.e. is it correct, that this should also make all the internally generated carriers have zero phase difference between the boxes instead of locking to the phases of the incoming signals (see Figure 2.)? http://old.nabble.com/file/p27838729/Fig%2B2%2BUSRP%2Bv2.jpg However, when we observe the internal clocks of 4 USRPs they are phase locked with respect to one another, but THERE IS A PHASE DIFFERENCE BETWEEN THEM, which is constant for a given power cycle. Does this imply that the phases of the internally generated carriers are locked to one another, but also with some NON 0 PHASE difference, i.e. that our actual system looks like Figure 3? http://old.nabble.com/file/p27838729/Fig%2B3%2BUSRP%2Bv3.jpg Thanks, Valentin. -- View this message in context: http://old.nabble.com/USRP-synchronization-tp27838729p27838729.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem in gnuradio installation PLEASE help
On Tue, Mar 09, 2010 at 02:33:29PM +, sanam singh wrote: hi, thanks for your reply. i have done both and here is the output of ./configure: The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gr-gcell gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows These components will not be built. after that when i do make check i get : make[3]: Entering directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src' make check-TESTS make[4]: Entering directory `/home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src' Traceback (most recent call last): File ./qa_usrp.py, line 24, in module import usrp_swig File /home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src/usrp_swig.py, line 18, in module _usrp_swig = swig_import_helper() File /home/sanam/hydra-0.4/gnuradio-3.2.2/gr-usrp/src/usrp_swig.py, line 16, in swig_import_helper if fp is not None: fp.close() UnboundLocalError: local variable 'fp' referenced before assignment FAIL: run_tests IIRC, that problem showed up with python 2.6 and is fixed in the git master. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP synchronization
Hi All, We are trying to use 4 USRPs to extract the phase information due to differences in positions of the antennas. In a standard communications system an internally generated carrier is locked IN PHASE with the incoming signal to perform downconversion (see Figure 1.). http://old.nabble.com/file/p27838821/Fig%2B1%2BUSRP%2Bv2.jpg As mentioned above we are using 4 USRPs to receive a signal from a single source. We wish to retain the phase information of this signal between boxes due to the different positions of the antennas. We feed all 4 boxes with a clock reference signal (10MHz, 1.5Vpk-pk), so that their internal clocks should be locked in phase with respect to each other. Are the internally generated carriers generated using this clock as a phase reference, i.e. is it correct, that this should also make all the internally generated carriers have zero phase difference between the boxes instead of locking to the phases of the incoming signals (see Figure 2.)? http://old.nabble.com/file/p27838821/Fig%2B2%2BUSRP%2Bv2.jpg However, when we observe the internal clocks of 4 USRPs they are phase locked with respect to one another, but THERE IS A PHASE DIFFERENCE BETWEEN THEM, which is constant for a given power cycle. Does this imply that the phases of the internally generated carriers are locked to one another, but also with some NON 0 PHASE difference, i.e. that our actual system looks like Figure 3? http://old.nabble.com/file/p27838821/Fig%2B3%2BUSRP%2Bv3.jpg Thanks, Valentin. -- View this message in context: http://old.nabble.com/USRP-synchronization-tp27838821p27838821.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] problem in gnuradio installation PLEASE help
hi, thanks for your guidance. well the problem is that im installing hydra testbed. and in its installation instructions (INSTALL attached file) it says to first build gnuradio from git then from tarball (step 10). i would be grateful if you could have a look at the attached file and kindly tell me a way to do step 10 in such i dont have to install gnuradio from tar.gz. i.e. do ./bootstrap ./configure --prefix=$GR make make install from /home/sanam/hydra-0.4/gnuradio-3.2.2 thankyou for your time. Regards, Sanam. _ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. https://signup.live.com/signup.aspx?id=60969 INSTALL Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP synchronization
On Tue, Mar 09, 2010 at 09:20:28AM -0800, ValentinG wrote: Hi All, We are trying to use 4 USRPs to extract the phase information due to differences in positions of the antennas. In a standard communications system an internally generated carrier is locked IN PHASE with the incoming signal to perform downconversion (see Figure 1.). http://old.nabble.com/file/p27838821/Fig%2B1%2BUSRP%2Bv2.jpg As mentioned above we are using 4 USRPs to receive a signal from a single source. We wish to retain the phase information of this signal between boxes due to the different positions of the antennas. We feed all 4 boxes with a clock reference signal (10MHz, 1.5Vpk-pk), so that their internal clocks should be locked in phase with respect to each other. Are the internally generated carriers generated using this clock as a phase reference, i.e. is it correct, that this should also make all the internally generated carriers have zero phase difference between the boxes instead of locking to the phases of the incoming signals (see Figure 2.)? http://old.nabble.com/file/p27838821/Fig%2B2%2BUSRP%2Bv2.jpg However, when we observe the internal clocks of 4 USRPs they are phase locked with respect to one another, but THERE IS A PHASE DIFFERENCE BETWEEN THEM, which is constant for a given power cycle. Does this imply that the phases of the internally generated carriers are locked to one another, but also with some NON 0 PHASE difference, i.e. that our actual system looks like Figure 3? http://old.nabble.com/file/p27838821/Fig%2B3%2BUSRP%2Bv3.jpg Thanks, Valentin. Matt can provide more info when he gets a chance, but I'm pretty sure that what you're seeing is is normal and is due to the PLLs on the daugherboards. There's a finite number of phases that the PLL's will lock to depending on the ratios programmed into the PLLs. I don't recall which daughterboards use integer-N vs fractional-N PLL's, but they give different numbers of possible solutions. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem in gnuradio installation PLEASE help
On Tue, Mar 09, 2010 at 06:21:22PM +, sanam singh wrote: hi, thanks for your guidance. well the problem is that im installing hydra testbed. and in its installation instructions (INSTALL attached file) it says to first build gnuradio from git then from tarball (step 10). i would be grateful if you could have a look at the attached file and kindly tell me a way to do step 10 in such i dont have to install gnuradio from tar.gz. i.e. do ./bootstrap ./configure --prefix=$GR make make install from /home/sanam/hydra-0.4/gnuradio-3.2.2 thankyou for your time. Regards, Sanam. Sanam, I think you're going to have better luck talking to the other hydra users. We're not going to spend time here trying to fix a problem that's already fixed in the git master. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MA (Memory Acceleration) and SR-DVB in Karlsruhe, @ WSR10
Vincenzo, I read your new teaser on Memory Acceleration. Time/memory tradeoffs, yes, have done that. Recursive table aggregation, OK. Algorithm segmentation, sure. I am still looking forward to the real paper, when it gets released. But I have a structural question. We've now seen two major projects that use the USRP, libusrp, and the general software signal processing paradigm of GNU Radio. But they both totally abandoned the GNU Radio code base. Both SR-DVB and OpenBTS wrote their own code from scratch, even though major parts of the computation could have been handled by GNU Radio processing blocks. Why? Does something about the structure of GNU Radio doom it to only be used in experiments and demos? Is the problem in the complex, multi-language realtime high level structure, or the low level block processing structure, or somewhere else? Perhaps it was a legal issue, that both projects initially thought they didn't want to license their code under the GPL? (OpenBTS has since changed its mind.) Will techniques like memory acceleration be usable in signal processing blocks embedded in the GNU Radio signal processing framework? Or does its basic signal flow structure make it an inappropriate host? If so, what should we do about this? Have we made it too hard to use GNU Radio as a subroutine library for the functions close to the hardware (like tuning and demodulation), letting them be called from a custom main program that includes custom code for parsing and managing higher level protocols? How can we make it simpler to build big projects on GNU Radio and produce reliable and efficient production-quality programs? John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possible bug in the vrt branch firmware?
On 03/09/2010 04:58 AM, John Gilmore wrote: If our library is providing a standard call to set the timestamps of returned samples, shouldn't the standard or default way to do it result in those timestamps being accurate wallclock UTC realtime, rather than counting up from zero or from a random number? If by default our streams of samples came back with accurate nanosecond timestamps, that would be a big plus in the long run. You could later sync up signals from receivers all around the world; recordings would contain the time when the signal was received; etc. Any computer on the Internet can easily sync using NTP to within about 10 ms or so, to set the high order bits. And anyone with a PPS clock hooked to their USRP would get real cesium-linked timestamps. John I'm working on a paper tiger design for a specialized direct-conversion receiver for radio astronomy that would include a GPS receiver, and a 64-bit nanosecond counter in it, the idea being that each sample block would include an accurate timestamp. My plan is to make the wire format compatible with the USRP2--which I haven't actually looked at yet. GPS modules can be purchased very cheaply these days, and integrated into various hardware platforms, including receivers and digitizers, for use as a phase reference. My receiver will use 1PPS to phase-lock both LO frequency, and the sample clocks, and also to provide head of block nano-second timestamps. I've been working with GPS clocks quite a bit in my real(tm) job. Phase agreement between GPS units, even connected to the same antenna, isn't as spectacular as you'd like. Most of them can get to within 40nsec phase-agreement on the 1PPS outputs. So that means that for doing things like VLBI, you'll still need to futz with the data to get fringes to come out, but your futzing window will be smaller :-) Cheers -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP synchronization
On 03/09/2010 09:20 AM, ValentinG wrote: Hi All, We are trying to use 4 USRPs to extract the phase information due to differences in positions of the antennas. In a standard communications system an internally generated carrier is locked IN PHASE with the incoming signal to perform downconversion (see Figure 1.). http://old.nabble.com/file/p27838821/Fig%2B1%2BUSRP%2Bv2.jpg As mentioned above we are using 4 USRPs to receive a signal from a single source. We wish to retain the phase information of this signal between boxes due to the different positions of the antennas. We feed all 4 boxes with a clock reference signal (10MHz, 1.5Vpk-pk), so that their internal clocks should be locked in phase with respect to each other. Are the internally generated carriers generated using this clock as a phase reference, i.e. is it correct, that this should also make all the internally generated carriers have zero phase difference between the boxes instead of locking to the phases of the incoming signals (see Figure 2.)? http://old.nabble.com/file/p27838821/Fig%2B2%2BUSRP%2Bv2.jpg However, when we observe the internal clocks of 4 USRPs they are phase locked with respect to one another, but THERE IS A PHASE DIFFERENCE BETWEEN THEM, which is constant for a given power cycle. Does this imply that the phases of the internally generated carriers are locked to one another, but also with some NON 0 PHASE difference, i.e. that our actual system looks like Figure 3? http://old.nabble.com/file/p27838821/Fig%2B3%2BUSRP%2Bv3.jpg Thanks, Valentin. I assume you are using all USRP2s. There are multiple sources of ambiguity here. First, unless you are using a common PPS signal to all systems, using sync_on_pps, your time samples won't be aligned. Think of it this way -- everyone's watch is running at the same speed, but everybody thinks the time is different because you haven't coordinated. That's what the PPS is for Second, and this is what Eric mentioned, the PLLs on the daughterboards will all be locked to the same reference, but they can have an arbitrary offset which will change every time you tune. The important thing is that the relative phases don't change with time. This means you can do MIMO operations, but phased-arrays will require you to calibrate every time. You can use the TX side of the RFX-series as a signal generate to do this, but it will take some software. You didn't tell us what daughterboards you are using. The ones with the integer-N PLLs (DBSRX, RFX-series) will have a finite number of possibilities for that phase difference, usually less than 25, and you can tune in such a way that there is no ambiguity if you are careful. The fractional-N ones (XCVR2450, WBX) will have an effectively infinite number of possibilities, but you can still measure it and compensate. If you are just using the BasicRX or LFRX then you don't have this problem, you just need to align their DDC oscillators using PPS. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MA (Memory Acceleration) and SR-DVB in Karlsruhe, @ WSR10
Hi Michael, links to WSR10 paper and presentation slides are embedded into the videos from my previous post. Believe me, I would love to post the full MA paper right now. I will do immediately after being allowed to do so by peer reviewing / publication process. I will do all possible efforts to obtain such authorization ASAP. Meanwhile will keep developing MA and provide the most informative possible updates in case anything significant happens. Thanks for being interested. my best regards vincenzo 2010/3/9 Michael Dickens m...@alum.mit.edu: Hi Vincenzo - Can you also provide links to your papers, both the WSR10 one and whatever you can on your MA technique? Enquiring minds will want to know more about MA ... Thanks! - MLD -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GPS Receiver for USRP2
Hi I am choosing the GPS receiver to make the timing synchronization between the two USRP2's. I have already placed an order, and it would take few days to reach here. Mean while , i wanted to learn about how to synchronize the USRP2's using GPS reciever, Can anyone guide me , how to ? and from where i can get some useful material or information to setup and synchronize USRP2's using GPS receiver...! By searching the google , i had found some information regarding the USRP2 sychroniztion. relating to calling the function config_mimo(MC_WE_LOCK_TO_SMA) and sync_to_pps( ) for locking to USRP2 to external clock 10MHz and 1PPS, My question is Can anyone give me a clear picture, how to configure these programs and to synchronize two USRP2's. I am not going to use MIMO(using to MIMO cable given) configuration right now, currently i am only focusing on SISO config. If synchronising USRP2's in MIMO case is different from SISO, can you please differentiate. Thanks in advance MADAN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem installing new module
Hi all, The same error I am also getting for the basic gr-howto-write-a-block-3.2 == ERROR: test_001_square_ff (__main__.qa_howto) -- Traceback (most recent call last): File ./qa_howto.py, line 42, in test_001_square_ff self.tb.run () File /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/gnuradio/gr/top_block.py, line 103, in run self.start() File /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/gnuradio/gr/top_block.py, line 97, in start self._tb.start() File /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py, line 1455, in start return _gnuradio_swig_py_runtime.gr_top_block_sptr_start(self) RuntimeError: unable to resolve input endpoint square_ff(0):0 == ERROR: test_002_square2_ff (__main__.qa_howto) -- Traceback (most recent call last): File ./qa_howto.py, line 54, in test_002_square2_ff self.tb.run () File /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/gnuradio/gr/top_block.py, line 103, in run self.start() File /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/gnuradio/gr/top_block.py, line 97, in start self._tb.start() File /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py, line 1455, in start return _gnuradio_swig_py_runtime.gr_top_block_sptr_start(self) RuntimeError: unable to resolve input endpoint square2_ff(1):0 -- Ran 2 tests in 0.059s FAILED (errors=2) FAIL: run_tests == 1 of 1 test failed == make[3]: *** [check-TESTS] Error 1 make[2]: *** [check-am] Error 2 make[1]: *** [check-recursive] Error 1 make: *** [check-recursive] Error 1 So I think its more of configuration issue specific to my machine (MAC OS 10.5). GNURadio works perfectly. Only when I try to add new block, I get same error.. I am stuck.. Any help will be appreciated. Thanks, sagar On Mon, Mar 1, 2010 at 7:39 AM, Johnathan Corgan jcor...@corganenterprises.com wrote: On Mon, Mar 1, 2010 at 00:41, Sagar Kapare writetosag...@gmail.com wrote: RuntimeError: unable to resolve input endpoint sink_ff(0):0 The runtime doesn't like a reference you are passing to a 'connect' call. Check what you are putting in the connect call that you are wiring to 'sink_ff' input 0. It should be a properly instantiated gr block or hierarchical block. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Please help: Stuck in make command
Hi all, I am stuck , when I type make command after ./configure while building the minimal GNU radio system. Its really urgent. I am working on this for weeks and still not getting ahead. I will tell you the step by step procedure as to how I am working on cygwin.1) I run cygwin set-up.exe and then I choose a mirror cygwin.cygmirror. I select the useful utilities and after the installation is complete I choose set up a desktop icon and such. 2) I now install boost1.42 and sdcc externally.3) I download gnuradio-3.2.2 in cygwin.4) I give the following path as given in wiki. or the path where my pkgconfig is located: $ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig.5) After this I type the following: $ cd gnuradio-3.2.2 $ ./configure --disable-all-components --enable-omnithread --enable-gruel --enable-gnuradio-core --enable-gr-audio-oss6) After this command is executed, I know what components were built and which were not.7) I type make.8) I get the following: g...@abc ~ $ cd f: g...@abc /cygdrive/f $ cd cygwin g...@abc /cygdrive/f/cygwin $ cd gnuradio-3.2.2 g...@abc /cygdrive/f/cygwin/gnuradio-3.2.2 $ make make all-recursive make[1]: Entering directory `/cygdrive/f/cygwin/gnuradio-3.2.2' Making all in config make[2]: Entering directory `/cygdrive/f/cygwin/gnuradio-3.2.2/config' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/cygdrive/f/cygwin/gnuradio-3.2.2/config' Making all in gruel make[2]: Entering directory `/cygdrive/f/cygwin/gnuradio-3.2.2/gruel' Making all in src make[3]: Entering directory `/cygdrive/f/cygwin/gnuradio-3.2.2/gruel/src' Making all in include make[4]: Entering directory `/cygdrive/f/cygwin/gnuradio-3.2.2/gruel/src/include ' Making all in gruel make[5]: Entering directory `/cygdrive/f/cygwin/gnuradio-3.2.2/gruel/src/include /gruel' make all-am make[6]: Entering directory `/cygdrive/f/cygwin/gnuradio-3.2.2/gruel/src/include /gruel' make[6]: Nothing to be done for `all-am'. make[6]: Leaving directory `/cygdrive/f/cygwin/gnuradio-3.2.2/gruel/src/include/ gruel' make[5]: Leaving directory `/cygdrive/f/cygwin/gnuradio-3.2.2/gruel/src/include/ gruel' make[5]: Entering directory `/cygdrive/f/cygwin/gnuradio-3.2.2/gruel/src/include ' make[5]: Nothing to be done for `all-am'. make[5]: Leaving directory `/cygdrive/f/cygwin/gnuradio-3.2.2/gruel/src/include' make[4]: Leaving directory `/cygdrive/f/cygwin/gnuradio-3.2.2/gruel/src/include' Making all in lib make[4]: Entering directory `/cygdrive/f/cygwin/gnuradio-3.2.2/gruel/src/lib' /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. /../.. -DOMNITHREAD_POSIX=1 -I/usr/local/include -I/cygdrive/f/cygwin/gnuradio- 3.2.2/gruel/src/include -I/cygdrive/f/cygwin/gnuradio-3.2.2/gruel/src/include -g -O2 -Wall -Woverloaded-virtual -MT realtime.lo -MD -MP -MF .deps/realtime.T po -c -o realtime.lo realtime.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I/us r/local/include -I/cygdrive/f/cygwin/gnuradio-3.2.2/gruel/src/include -I/cygdriv e/f/cygwin/gnuradio-3.2.2/gruel/src/include -g -O2 -Wall -Woverloaded-virtual -M T realtime.lo -MD -MP -MF .deps/realtime.Tpo -c realtime.cc -DDLL_EXPORT -DPIC -o .libs/realtime.o In file included from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/cstring:49, from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/char_tr aits.h:45, from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/string:47, from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/stdexcept:45 , from /cygdrive/f/cygwin/gnuradio-3.2.2/gruel/src/include/gruel/ realtime.h:26, from realtime.cc:27: /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/cstddef:53: error: expected unqual ified-id before unsigned /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/cstddef:53: error: expected `;' be fore unsigned In file included from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_alg obase.h:69, from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/char_tr aits.h:46, from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/string:47, from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/stdexcept:45 , from /cygdrive/f/cygwin/gnuradio-3.2.2/gruel/src/include/gruel/ realtime.h:26, from realtime.cc:27: /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/new:82: error: declaration of `ope rator new' as non-function /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/new:82: error: expected unqualifie d-id before unsigned /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/new:82: error: expected `,' or `;' before throw /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/new:83: error: declaration of `ope rator new []' as non-function /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/new:83: error: expected unqualifie d-id before unsigned /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/new:83: error: expected `,' or `;'
[Discuss-gnuradio] Multiple Channel USRP Confusion
Hi all, I am looking to simultaneously record two real signals (not with IQ) using a single LFRX daughtercard. How can I do this with GNURadio companion? I have spent a while looking at the USRP Source and Dual USRP Source blocks and could not figure out. I am looking to record from Side A with RXA and RXB. I tried setting the RX Antenna setting to RXAB and used the complex to real block to extract channel RXA, and complex to imaginary block to extract RXB. I don't think this worked properly. I also tried using two separate USRP source blocks, each on side A but one for RXA and the other for RXB. When I did this I got an error related to already having one USRP side A block running. Any help would be greatly appreciated Thanks, Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] WAV File Sink problem
Hi all, I am having trouble using GNURadio companion and getting the wav file sink to work for me. I am interested in recording from a USRP with an LFRX daughtercard. I am simply trying to record from Side A, on the RXA channel. To do this, I am using the following blocks in order from left to right in my flow graph: 1. USRP Source 2. Complex to Real 3. Rational Resampler 4. Multiply by constant ((2^ -15)-1) to get values within the +/-1 range for the wav file sink 5. Head with 20,000,000 samples 6. Wav File Sink (1 channel, 16 bits per sample) I have checked and all the parameters in each of the blocks are set properly. For simiplicity in the rational resampler, I set the interpolation and decimation to a value of 1. Also the wav file sample rate matches the USRP source sample rate. The .WAV file is generated however I have to actually manually kill the flow graph. I can then see that the .WAV file has a size that is exactly what I expect for 20,000,000 samples. However when I open it with any .WAV editor I have problems saying there is something wrong with the file structure. Is it possible I am actually writing the header wrong with my method? Does anyone know if my approach is even valid? Thanks, Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
