[Discuss-gnuradio] editing .cc files??
Hi, i am using the ubuntu 9.04 and installed the gnuradio at the build guide through the binary package instructions for ubuntu at: http://gnuradio.org/redmine/wiki/gnuradio/DebianPackages i placed a problem here a couple of days ago and the solution suggested that i should modify c code written in the file gr_quadrature_demod_cf.cc in order to get the desired results. the problem is that i am unable to locate the .cc files. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] editing .cc files??
Omer Ihsan wrote: Hi, i am using the ubuntu 9.04 and installed the gnuradio at the build guide through the binary package instructions for ubuntu at: http://gnuradio.org/redmine/wiki/gnuradio/DebianPackages i placed a problem here a couple of days ago and the solution suggested that i should modify c code written in the file gr_quadrature_demod_cf.cc in order to get the desired results. the problem is that i am unable to locate the .cc files. You have to download and build from source to be able to modify the .cc- files. See http://gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall //Mattias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] IT++ functions
On Fri, Mar 05, 2010 at 06:15:13PM -0500, Pradyumna Desale wrote: Hey Per, Thanks for replying! I wanted to start by incorporating channel models (channel.h if you are familiar with IT++) and was wondering if just writing a wrapper function in swig would do the necessary work for us or we have to make some specific changes to incorporate those codes in gnuradio framework. Any thoughts? I've been wanting to use the channel coders from IT++ in GNU Radio, and found writing wrappers is not difficult. I never finished packaging any code (though I've got some code somewhere, if I find it I'll send it to you), but here's some of the knowledge I gathered: - The data types of GNU Radio and IT++ are in theory compatible, but in practice I found you either need to subclass IT++' Vec-class to directly access the memory, or you need to copy everything by hand from your input data to the IT++ vector. - In any case, IT++' structure is pretty coherent, so writing a wrapper for pretty much anything is fairly straightforward: 1) Include an object to your channel model (or whatever) in your block, e.g. a d_rayleigh_channel attribute 2) In your work function, you need to shift your data from input_data to your Vec 3) Load that into d_rayleigh_channel or whatever 4) Take the results and copy them to the output_data - What's really simple about it all is that these steps are virtually the same no matter what you include, be it channels, encoders etc. - Perhaps slightly more difficult would be to adapt the build system (check for libs etc). Perhaps this was of any help to you... 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 pgpRJdbpAIaTP.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Re: help req gnu radio installation on ubuntu 9.10
thanks it worked _ Hotmail: Free, trusted and rich email service. http://clk.atdmt.com/GBL/go/201469228/direct/01/___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] help req :editing .bashrc file
hi , im installing hydra0.4 (http://hydra.ece.utexas.edu/testbed/) on ubuntu 9.04 and gnuradio 3.2.2. im having following issue: 1) at step n.o. 8 of the attached INSTALL file when i add the lines to /home/sanam/.bashrc and i restart the terminal i get following error: : command not found ': not a valid identifier : command not found ': not a valid identifier_PATH : command not found ': not a valid identifier : command not found ': not a valid identifier : command not found i have installed the hydra0.4 in /home/sanam im not understanding what is the issue here, i simply copy the step 8 lines into .bashrc but it doesnt work. 123 is my .bashrc file with name changed here so that i can attach it in mail. please help me. Regards, Sanam _ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 INSTALL Description: Binary data 123 Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help req :editing .bashrc file
On Mon, Mar 08, 2010 at 11:48:58AM +, sanam singh wrote: im installing hydra0.4 (http://hydra.ece.utexas.edu/testbed/) on ubuntu 9.04 and gnuradio 3.2.2. im having following issue: 1) at step n.o. 8 of the attached INSTALL file when i add the lines to /home/ sanam/.bashrc and i restart the terminal i get following error: Hi Sanam, this is not a GNU Radio related issue, so you will very likely get more helpful answers if you post somewhere else, e.g. your local Linux mailing list or one of the many online Linux fora. 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 pgpQH0vwuFT03.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] help req :editing .bashrc file
hi, i tried your idea, but unfortunately it didnt work. however i eliminated the spaces between the new added lines, nor the terminal no longer gives any error. but now im facing a new error. When in step no10 (INSTALL attached) in meta-80211n i write ./bootstrap ./configure --prefix=$GR make make install following error appears checking for wicom = 0... Package wicom was not found in the pkg-config search path. Perhaps you should add the directory containing `wicom.pc' to the PKG_CONFIG_PATH environment variable No package 'wicom' found configure: error: Library requirements (wicom = 0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. i fear that the step 8 (INSTALL attached) hasnt been performed properly by me. my new .bashrc file is attached as 123 and so is the INSTALL instructions by hydra. Please help me Regards. _ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 123 Description: Binary data INSTALL Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tvrx and usrp_tv_rcv
On Mon, Mar 08, 2010 at 11:33:18AM +0700, Muhammad Najib wrote: Hello All, I'm trying to recreate Mr. Dayal's thesis about analog tv decoding using gnuradio. i have already got the black and white picture after taking 8MHz band with frequency centered in the middle of the channel. the problem is, i got about one or two fps with my computer(2.3GHz atlon64 x2 4400). Is this normal? what is the minimum cpu/memory requirement for this? thank you for your response. --Najib. I'm not familiar with the code that you're using, but in general, yes, I would expect it to be possible to decode analog TV with your equipment. Algorithms make a big difference... Note also that the passband of the the TVRX is about 6 MHz wide (NTSC), so if your channel bandwidth really is 7 or 8 MHz wide (PAL/SECAM), you're probably filter some of the signal. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interesting observation regarding varying time duration it takes to execute fg.start() [a flowgraph start ala thread spawning??]
On 03/07/2010 01:12 PM, Eric Blossom wrote: On Sun, Mar 07, 2010 at 04:07:58PM -0500, Bishal Thapa wrote: Thank you for your reply Eric. I did print delta and delta.microseconds and guess what I did get this: Receiver (0) = BABA0002 Requested RX Bitrate: 100k Probe Level 39 0:00:00.000327 [*This is from printing delta*] 327 [*This is from printing delta.microseconds*] Why do you think I should not get 309us? I am sorry if I don't get something fundamental here. Thanks again for helping me out :) No problem. 309us may be reasonable. In general the wide variance that you're seeeing could be caused by pretty much any other activity on the machine. You are measuring wall time. Does this flowgraph have a USRP1? If so, the very long time could be when you have first powered up the USRP1 and so it needs to have its FPGA image downloaded. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] IT++ functions
On Mon, Mar 8, 2010 at 02:06, Martin Braun martin.br...@kit.edu wrote: I've been wanting to use the channel coders from IT++ in GNU Radio, and found writing wrappers is not difficult. I never finished packaging any code (though I've got some code somewhere, if I find it I'll send it to you), The license on IT++ appears to be GPLv2. 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. If there is enough interest, I can create a skeleton top-level component as a basis for patch submission. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Possible bug in the vrt branch firmware?
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 -- View this message in context: http://old.nabble.com/Possible-bug-in-the-vrt-branch-firmware--tp27825201p27825201.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] Possible bug in the vrt branch firmware?
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] problem installing gnu radio
hi, im facing following problem installing gnuradio from tarz libtool: link: only absolute run-paths are allowed make[6]: *** [_gnuradio_swig_py_filter.la] Error 1 make[6]: Leaving directory `/home/ahsan/hydra-0.4/gnuradio-3.2.2/gnuradio-core/src/lib/swig' make[5]: *** [all] Error 2 make[5]: Leaving directory `/home/ahsan/hydra-0.4/gnuradio-3.2.2/gnuradio-core/src/lib/swig' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/ahsan/hydra-0.4/gnuradio-3.2.2/gnuradio-core/src/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/ahsan/hydra-0.4/gnuradio-3.2.2/gnuradio-core/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/ahsan/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. 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] Possible bug in the vrt branch firmware?
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 -- View this message in context: http://old.nabble.com/Possible-bug-in-the-vrt-branch-firmware--tp27825201p27826670.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] Interesting observation regarding varying time duration it takes to execute fg.start() [a flowgraph start ala thread spawning??]
Yes Matt, you were correct. Now the range between min-time recorded and max-time recorded is much less. Min = 309us (still), Max = 2349us. So range ~= 2ms. I believe it is due to Eric's reasoning, multiple services running on my host machine, although I have to mention I am running these programs as sudo. Anyways, I will try to run it on a different host with nothing much going on, and see if I can reduce the range variation of 2ms. Thank you Eric and Matt for your time, Sincerely, On Mon, Mar 8, 2010 at 10:07 AM, Matt Ettus m...@ettus.com wrote: On 03/07/2010 01:12 PM, Eric Blossom wrote: On Sun, Mar 07, 2010 at 04:07:58PM -0500, Bishal Thapa wrote: Thank you for your reply Eric. I did print delta and delta.microseconds and guess what I did get this: Receiver (0) = BABA0002 Requested RX Bitrate: 100k Probe Level 39 0:00:00.000327 [*This is from printing delta*] 327 [*This is from printing delta.microseconds*] Why do you think I should not get 309us? I am sorry if I don't get something fundamental here. Thanks again for helping me out :) No problem. 309us may be reasonable. In general the wide variance that you're seeeing could be caused by pretty much any other activity on the machine. You are measuring wall time. Does this flowgraph have a USRP1? If so, the very long time could be when you have first powered up the USRP1 and so it needs to have its FPGA image downloaded. Matt ___ 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 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
Re: [Discuss-gnuradio] USRP2/FPGA Directory Removed
I tried to download the repository from the link given below, but the connection timed out. I found the project on sourcerepo ( http://code.ettus.com/redmine/ettus/projects/show/fpga), and also tried the link given there also timed out. gnura...@gnuradio-laptop:~$ git clone git:// ettus.sourcerepo.com/ettus/fpga.git Initialized empty Git repository in /home/gnuradio/fpga/.git/ ettus.sourcerepo.com[0: 68.233.8.98]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) gnura...@gnuradio-laptop:~$ git clone git://git.ettus.com/ettus/fpga.git Initialized empty Git repository in /home/gnuradio/fpga/.git/ git.ettus.com[0: 68.233.8.98]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) Any help here would be greatly appreciated. -Michael Berman On Tue, Mar 2, 2010 at 12:14 AM, Jared Casper jaredcas...@gmail.com wrote: On Mon, Mar 1, 2010 at 11:33 PM, Michael Berman mrberma...@gmail.com wrote: It appears that the entire USRP2/FPGA directory was removed from the repository on 2/28/2010. Was this an error, or is the Verilog code no longer going to be posted? From the git log: Revision a2c00f5c ID: a2c00f5cff7407ff10fc6c812d06fefe52c0b6a3 Added by Johnathan Corgan 1 day ago Remove usrp1 and usrp2 FPGA files. These are now hosted at: git://ettus.sourcerepo.com/ettus/fpga.git ...under the 'usrp1' and 'usrp2' top-level directories. Jared -- -Michael Berman ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interesting observation regarding varying time duration it takes to execute fg.start() [a flowgraph start ala thread spawning??]
On Mon, Mar 08, 2010 at 04:09:49PM -0500, Bishal Thapa wrote: Yes Matt, you were correct. Now the range between min-time recorded and max-time recorded is much less. Min = 309us (still), Max = 2349us. So range ~= 2ms. I believe it is due to Eric's reasoning, multiple services running on my host machine, although I have to mention I am running these programs as sudo. Sudo doesn't have anything (directly) to do with scheduling... Eric ___ 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/08/2010 03:22 PM, Michael Berman wrote: I tried to download the repository from the link given below, but the connection timed out. I found the project on sourcerepo (http://code.ettus.com/redmine/ettus/projects/show/fpga), and also tried the link given there also timed out. gnura...@gnuradio-laptop:~$ git clone git://ettus.sourcerepo.com/ettus/fpga.git http://ettus.sourcerepo.com/ettus/fpga.git Initialized empty Git repository in /home/gnuradio/fpga/.git/ ettus.sourcerepo.com http://ettus.sourcerepo.com[0: 68.233.8.98]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) gnura...@gnuradio-laptop:~$ git clone git://git.ettus.com/ettus/fpga.git http://git.ettus.com/ettus/fpga.git Initialized empty Git repository in /home/gnuradio/fpga/.git/ git.ettus.com http://git.ettus.com[0: 68.233.8.98]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) Any help here would be greatly appreciated. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2/FPGA Directory Removed
I believe that you are behind a firewall. You need TCP port 9418 unblocked to use the git protocol. -Josh On 03/08/2010 03:22 PM, Michael Berman wrote: I tried to download the repository from the link given below, but the connection timed out. I found the project on sourcerepo ( http://code.ettus.com/redmine/ettus/projects/show/fpga), and also tried the link given there also timed out. gnura...@gnuradio-laptop:~$ git clone git:// ettus.sourcerepo.com/ettus/fpga.git Initialized empty Git repository in /home/gnuradio/fpga/.git/ ettus.sourcerepo.com[0: 68.233.8.98]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) gnura...@gnuradio-laptop:~$ git clone git://git.ettus.com/ettus/fpga.git Initialized empty Git repository in /home/gnuradio/fpga/.git/ git.ettus.com[0: 68.233.8.98]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) Any help here would be greatly appreciated. -Michael Berman On Tue, Mar 2, 2010 at 12:14 AM, Jared Casperjaredcas...@gmail.com wrote: On Mon, Mar 1, 2010 at 11:33 PM, Michael Bermanmrberma...@gmail.com wrote: It appears that the entire USRP2/FPGA directory was removed from the repository on 2/28/2010. Was this an error, or is the Verilog code no longer going to be posted? From the git log: Revision a2c00f5c ID: a2c00f5cff7407ff10fc6c812d06fefe52c0b6a3 Added by Johnathan Corgan 1 day ago Remove usrp1 and usrp2 FPGA files. These are now hosted at: git://ettus.sourcerepo.com/ettus/fpga.git ...under the 'usrp1' and 'usrp2' top-level directories. Jared ___ 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] USRP2/FPGA Directory Removed
Yup, that was it. Thank you very much, Michael Berman On Mon, Mar 8, 2010 at 3:40 PM, Matt Ettus m...@ettus.com wrote: On 03/08/2010 03:22 PM, Michael Berman wrote: I tried to download the repository from the link given below, but the connection timed out. I found the project on sourcerepo (http://code.ettus.com/redmine/ettus/projects/show/fpga), and also tried the link given there also timed out. gnura...@gnuradio-laptop:~$ git clone git://ettus.sourcerepo.com/ettus/fpga.git http://ettus.sourcerepo.com/ettus/fpga.git Initialized empty Git repository in /home/gnuradio/fpga/.git/ ettus.sourcerepo.com http://ettus.sourcerepo.com[0: 68.233.8.98]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) gnura...@gnuradio-laptop:~$ git clone git://git.ettus.com/ettus/fpga.git http://git.ettus.com/ettus/fpga.git Initialized empty Git repository in /home/gnuradio/fpga/.git/ git.ettus.com http://git.ettus.com[0: 68.233.8.98]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) Any help here would be greatly appreciated. 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 -- -Michael Berman ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP1 hangs, benchmark doesn't continue
Hi,
* I've installed the latest and greatest gnuradio from git, everything
compiled fine.
* I have a pre-500 USRP1, and fixed the wiring of the clock to the four
daughterboard sockets.
* I've been running gnuradio on this hardware ~2 weeks ago successfully.
Now, when I try to run anything that connects to the USRP, it just
hangs. It downloads the firmware (blinking gets slower), it identifies
my two WBX boards correctly, but:
---8---
$ /opt/gnuradio/HEAD/share/gnuradio/examples/usrp/usrp_benchmark_usb.py
Testing 2MB/sec...
---8---
...and that's where it ends. It just hangs there.
If I try usrp_oscope.py on a local radio station, I see *nothing*.
I also tried usrp_wfm_rcv_nogui.py:
$ usrp_wfm_rcv_nogui.py -f 100.6e6 -O plughw:0,0 -g 30
When I strace the process, I only see
select(0, NULL, NULL, NULL, {0, 2000}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {0, 4000}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {0, 8000}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {0, 16000}) = 0 (Timeout)
Any hints?
Alex
signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 hangs, benchmark doesn't continue
On 03/08/2010 04:10 PM, Alexander List wrote: Hi, * I've installed the latest and greatest gnuradio from git, everything compiled fine. * I have a pre-500 USRP1, and fixed the wiring of the clock to the four daughterboard sockets. * I've been running gnuradio on this hardware ~2 weeks ago successfully. Now, when I try to run anything that connects to the USRP, it just hangs. It downloads the firmware (blinking gets slower), it identifies my two WBX boards correctly, but: Sounds like there is a clock problem. Can you measure the clock with an oscilloscope? What about when you remove the daughterboards? Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 hangs, benchmark doesn't continue
On 3/9/10 1:19 AM, Matt Ettus wrote: Sounds like there is a clock problem. Can you measure the clock with an oscilloscope? What about when you remove the daughterboards? I don't have one at home, but I guess I'll find someone in Zurich who has ;) Removing the daughterboards yields no change with usrp_benchmark_usb :( I hope I haven't killed the oscillator? I connected the output of X2 to each of the daugherboard connector's clock lines (clock db a p) with 47 Ohms in front of each connector. Alex signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] solved: USRP1 hangs, benchmark doesn't continue
On 3/9/10 1:36 AM, Alexander List wrote: I hope I haven't killed the oscillator? I connected the output of X2 to each of the daugherboard connector's clock lines (clock db a p) with 47 Ohms in front of each connector. D'oh. I'll never solder on SMD PCBs again when I have a hangover. I shorted pins 10 and 12 of J667, connecting the clock to DVDD:1 ... Thanks for the hint with the clock! Alex signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] simultanuous receive and transmit on USRP2 in C++, maybe use threads
Hi All, I am building an application where I simultanuously want to receive and transmit using the USRP2. Since I also need the timestamps, I implement this using C++. (Building my own filewriter class which extends usrp2::rx_nop_handler, like in rx_streaming_samples.cc) Should I use threads to keep TX and RX from interfering with each other. With threads I could just start the RX thread and TX thread. If I don't use threads I have to interleave sending and receiving packets. Is there an example I could look at. I now based my code on : usrp2/host/apps/rx_streaming_samples.cc and usrp2/host/apps/tx_samples.cc I know gnuradio has its own support code for threads, but I couldn't find an easy example on how to use it. Best Regards, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] pmt_dict API change in master
Changeset cbbe4816f99ac introduces an API change in the pmt library. I doubt that this change will cause problems for anyone, but if does, see below for the changes you'll have to make to your code. With the change, pmt_dict becomes an immutable object (persistent in functional programming lingo), and is now safe to pass in messages. The primary change is that the old key/value setter: //! dict[key] = value void pmt_dict_set(pmt_t dict, pmt_t key, pmt_t value); is replaced with: //! Return a new dictionary with \p key associated with \p value. pmt_t pmt_dict_add(const pmt_t dict, const pmt_t key, const pmt_t value); It returns a new dictionary with the key, value association added. The previous dictionary is unchanged. There is also a new function that returns a version of a dictionary with a key removed: //! Return a new dictionary with \p key removed. pmt_t pmt_dict_delete(const pmt_t dict, const pmt_t key); The new implementation is simple-minded. If it gets to be a performance problem, we can replace it with a persistent red-black tree or something similar. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] simultanuous receive and transmit on USRP2 in C++, maybe use threads
On Tue, Mar 09, 2010 at 02:34:32AM +0100, Martin DvH wrote: Hi All, I am building an application where I simultanuously want to receive and transmit using the USRP2. Since I also need the timestamps, I implement this using C++. (Building my own filewriter class which extends usrp2::rx_nop_handler, like in rx_streaming_samples.cc) Should I use threads to keep TX and RX from interfering with each other. With threads I could just start the RX thread and TX thread. If I don't use threads I have to interleave sending and receiving packets. Is there an example I could look at. I now based my code on : usrp2/host/apps/rx_streaming_samples.cc and usrp2/host/apps/tx_samples.cc I know gnuradio has its own support code for threads, but I couldn't find an easy example on how to use it. Martin, We just build everything on top of boost::thread and gruel::thread_group (boost bug fixes) . It's pretty straight-forward. The boost docs will give you the details. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
