[Discuss-gnuradio] FX2 Controller/ GPIF questions
Hi All, Can anyone shed some light on how the FX2 firmware / GPIF handles simultaneous reads and writes? I mean if I set up my USRP1 to receive and transmit simultaneously, what is happening exactly down there at the GPIF level? Given that there are two GPIF waveform configurations one each for Read and Write, are there two concurrent instantiations of the FIFO state machine during simultaneous read/ writes for full duplex operation , or in other words are there separate FIFO state machines operating in two configurations at the same time? If the GPIF state machine is in only one configuration (FIFOWr or FIFORd) at one time, how is true full duplex communication possible? Thanks, Arya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] E100 frustrated newbie questions.
Just so you don't think I gave up all disillusioned. I have figured out how to change the GRC generated python files to not refer to the wx libraries, only takes a couple of lines to be edited. The result is that I can now create flowgraphs in grc on my development vm, copy the python file to the USRP E100, edit the couple of lines and my text based project works! The proof of the pudding is a WBFM receiver that I just fired up and a couple of NBFM tx programs as well. I did find a problem with the latest git gnuradio though, the UHD types are missing a _t at the end eg. io_type = uhd.io_type.COMPLEX_FLOAT32 is generated by GRC but io_type = uhd.io_type_t.COMPLEX_FLOAT32 is what is required to work... Cheers, Ingmar Canberra, Australia On 13/02/2011 1:26 PM, Ingmar Meins wrote: Hi All, I've now had the E100 with WBX for about a week and I feel like I am going around in circles! I've run the UHD examples and the non-USRP examples because of course the python examples have not caught up with UHD, the E100 itself works fine. I have now found some of the work on the list where people are porting the examples to python/UHD. When I try to run some of this example code I get the error message "ImportError: cannot import name usrp". Is this because the board is not actually setup with the python links to UHD when you get it? Do I have to go through the whole p.i.t.a. process of recompiling UHD and gnuradio on the E100 or are these available from some secret repository so I can use opkg? Huge learning curve at present not helped at all by the zero information that comes in the $2000 box! Also, I know grc won't fully run because there is no wxpython library on the E100 but am I correct in assuming I should be able to still use grc to compile my designs to python files and then run those results? Sorry but I'm struggling with the whole finding the right forum or complete (and CORRECT) answers to some basic questions on this sexy new product (E100). Any newbie pointers would be very much appreciated, Cheers, Ingmar Canberra, Australia ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio On 13/02/2011 1:26 PM, Ingmar Meins wrote: Hi All, I've now had the E100 with WBX for about a week and I feel like I am going around in circles! I've run the UHD examples and the non-USRP examples because of course the python examples have not caught up with UHD, the E100 itself works fine. I have now found some of the work on the list where people are porting the examples to python/UHD. When I try to run some of this example code I get the error message "ImportError: cannot import name usrp". Is this because the board is not actually setup with the python links to UHD when you get it? Do I have to go through the whole p.i.t.a. process of recompiling UHD and gnuradio on the E100 or are these available from some secret repository so I can use opkg? Huge learning curve at present not helped at all by the zero information that comes in the $2000 box! Also, I know grc won't fully run because there is no wxpython library on the E100 but am I correct in assuming I should be able to still use grc to compile my designs to python files and then run those results? Sorry but I'm struggling with the whole finding the right forum or complete (and CORRECT) answers to some basic questions on this sexy new product (E100). Any newbie pointers would be very much appreciated, Cheers, Ingmar Canberra, Australia ___ 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] UHD example on USRP1 - Buffering
Hi All, I was wondering if there is any buffering happening on the host and/or on the USRP (USRP1 and N210) when the UHD send() and recv() methods are called? Thanks, Shiva On Thu, Feb 3, 2011 at 10:40 AM, Josh Blum wrote: > > > 1. What is the parameter --spb, samples per buffer. And generally, what > is > > this buffer? > > This is the buffer that the application fills with samples, and passes > into the call device->send() > > > 2. What is the relationship between spb (sample per buffer), duration > > (number of seconds to transmit) and rate (rate of outgoing samples) and > > wave-freq (waveform frequency in Hz)? > > > > Samples per buffer is independent of these other variables. Indirectly, > it controls how often the call to send() occurs. The option is there to > allow users to experiment with various buffer sizes. > > -josh > > ___ > 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] UHD won't work with GRC
Thanks Josh. Getting the newest gnuradio from git solved the uhd
problem, but now gnuradio is broken. I know it must be some path problem
but I have tried the usual tricks: I set my
PYTHONPATH=/usr/local/lib/pkgconfig/dist-packages and
LD_LIBRARY_PATH=/usr/local/lib and I did sudo ldconfig in the gnuradio
directory. And I checked /etc/ld.so.conf and /usr/local/lib is in there.
I get the following problem when trying to run any gnuradio programs.
And when I try gnuradio-companion a gui pops up that says "can't import
gnuradio, are your PYTHONPATH and LD_LIBRARY_PATH set correctly?
sjohnston@ubunte:~/gnuradio/
gnuradio-examples/python/pfb$ ./channelize.py --help
Traceback (most recent call last):
File "./channelize.py", line 23, in
from gnuradio import gr, blks2
File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/__init__.py",
line 43, in
from gnuradio_core import *
File
"/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core.py",
line 23, in
from gnuradio_core_runtime import *
File
"/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py",
line 24, in
_gnuradio_core_runtime = swig_import_helper()
File
"/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py",
line 20, in swig_import_helper
_mod = imp.load_module('_gnuradio_core_runtime', fp, pathname,
description)
ImportError: /usr/local/lib/libgnuradio-core-3.4git.so.0: undefined
symbol: _ZTIN5gruel12msg_accepterE
sjohnston@ubunte:~/gnuradio/gnuradio-examples/python/digital$
./benchmark_loopback.py --help
Traceback (most recent call last):
File "./benchmark_loopback.py", line 23, in
from gnuradio import gr, gru, modulation_utils
File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/__init__.py",
line 43, in
from gnuradio_core import *
File
"/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core.py",
line 23, in
from gnuradio_core_runtime import *
File
"/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py",
line 24, in
_gnuradio_core_runtime = swig_import_helper()
File
"/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py",
line 20, in swig_import_helper
_mod = imp.load_module('_gnuradio_core_runtime', fp, pathname,
description)
ImportError: /usr/local/lib/libgnuradio-core-3.4git.so.0: undefined
symbol: _ZTIN5gruel12msg_accepterE
Josh Blum wrote:
Cat your /usr/local/lib/pkgconfig/uhd.pc files and
gnuradio/config/grc_gr_uhd.m4 and make sure the version reqs match up.
Or the repo is out of date. -josh
On 02/15/2011 07:56 AM, Scott Johnston wrote:
I am having the same problem. When the configure breaks on UHD it says I
need libuhd.1.x.x. I have libuhd.0.0.2 in /usr/local/lib and uhd.pc is
in pkgconfig directory. I have PKG_CONFIG_PATH=/usr/local/lib/pkgconfig.
I have also done sudo ldconfig. I really dont want to wipe my whole
system. Oh, UHD works correctly, uhd_find_devices and rx_samples_to_file
both work.
Any other ideas?
Scott
Josh Blum wrote:
The configure check is very simple. Just make sure that uhd.pc is in
your PKG_CONFIG_PATH, and that if you look at uhd.pc, the version should
read 002.. If not, then you didnt update or install the
latest uhd, that could be another reason its getting rejected.
-Josh
On 01/21/2011 04:21 PM, Fabian Klaes wrote:
I tried sudo ldconfig several times, no luck there :-(
I think I also checked PKG_CONFIG_PATH and uhd.pc was in the (standard?)
/usr/local/lib/pkgconfig, but right now I'm not sure about this. I will
check this on monday again!
Nevertheless I also did (see also my 3rd message in this thread):
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:${PKG_CONFIG_PATH}
so i think i should be fine (but will be checked monday)
If this doesn't work out, i think the best move would be to do a fresh
install of Ubuntu and try to install UHD and GNUradio again on a
complete
clean system?
Good Night
Fabian
On Fri, Jan 21, 2011 at 6:19 PM, Josh Blum wrote:
how about a good luck sudo ldconfig? -josh
On 01/21/2011 05:02 AM, Fabian Klaes wrote:
I first tried make distclean and the installation went fine, but
when I
tried to start the GRC, following window showed up:
http://tinypic.com/r/dq671d/7 containing the error message "Cannot
import
gnuradio. Are your PHYTONPATH and LD_LIBRARY_PATH set correctly?"
I then tried git clean -dfx and rebuilding from scratch (for UHD and
GNUradio).
Installation for UHD (worked):
git clone git://code.ettus.com/ettus/uhd.git
cd uhd/host
mkdir build
cmake -DCMAKE_INSTALL_PREFIX=/opt/uhd ../
make
make test
sudo make install
PATH=$PATH:/opt/uhd/bin
uhd_find_devices and uhd_usrp_probe works fine now, so i figured that
the
installation of UHD was successfull
Installation for GNUradio (error at ./configure):
git clone git://gnurad
Re: [Discuss-gnuradio] UHD won't work with GRC
On Wed, Feb 16, 2011 at 3:19 PM, Scott Johnston wrote: > Thanks Josh. Getting the newest gnuradio from git solved the uhd problem, > but now gnuradio is broken. I know it must be some path problem but I have > tried the usual tricks: I set my > PYTHONPATH=/usr/local/lib/pkgconfig/dist-packages and > LD_LIBRARY_PATH=/usr/local/lib and I did sudo ldconfig in the gnuradio > directory. And I checked /etc/ld.so.conf and /usr/local/lib is in there. Maybe just a typo, but instead of PYTHONPATH=/usr/local/lib/pkgconfig/dist-packages try: PYTHONPATH=/usr/local/lib/python2.6/site-packages Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD won't work with GRC
Yes, that was typo. PYTHONPATH=/usr/local/lib/python2.6/dist-packages I did mean dist-pakages. I have three directories in dist, gnuradio grc_gnuradio usrpm. And nothing in the site-packages. Alexandru Csete wrote: On Wed, Feb 16, 2011 at 3:19 PM, Scott Johnston wrote: Thanks Josh. Getting the newest gnuradio from git solved the uhd problem, but now gnuradio is broken. I know it must be some path problem but I have tried the usual tricks: I set my PYTHONPATH=/usr/local/lib/pkgconfig/dist-packages and LD_LIBRARY_PATH=/usr/local/lib and I did sudo ldconfig in the gnuradio directory. And I checked /etc/ld.so.conf and /usr/local/lib is in there. Maybe just a typo, but instead of PYTHONPATH=/usr/local/lib/pkgconfig/dist-packages try: PYTHONPATH=/usr/local/lib/python2.6/site-packages Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Scott Johnston MIT Lincoln Laboratory 244 Wood Street, Lexington, MA 02420-9108 (781) 981-8196 scott.johns...@ll.mit.edu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FX2 Controller/ GPIF questions
On Wed, Feb 16, 2011 at 3:54 AM, Arya Santini wrote: > Hi All, > > Can anyone shed some light on how the FX2 firmware / GPIF handles > simultaneous reads and writes? I mean if I set up my USRP1 to receive > and transmit simultaneously, what is happening exactly down there at > the GPIF level? Given that there are two GPIF waveform configurations > one each for Read and Write, are there two concurrent instantiations > of the FIFO state machine during simultaneous read/ writes for full > duplex operation , or in other words are there separate FIFO state > machines operating in two configurations at the same time? If the GPIF > state machine is in only one configuration (FIFOWr or FIFORd) at one > time, how is true full duplex communication possible? There are separate GPIF waveforms for reads and writes, which occur as 512 byte bursts when data and buffer space are available. FIFO buffers in both directions allow for full duplex operation. There's a good summary of the main run loop on the wiki page. http://gnuradio.org/redmine/wiki/1/UsrpFAQFX2 Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Don't find some primitive
Hi, I finally managed to run ISE 10.1 on Linux to compile the raw internet version of the fpga project, but when I call 'make bin', the following error appears: ERROR:HDLCompilers:87 - "../../../fifo/fifo_2clock.v" line 26 Could not find module/primitive 'fifo_xlnx_2Kx36_2clk' I checked in the makefile to be sure all is called well and the file above is in there. Anybody know why? Am I obligated to update to sp3? Thx Gabriel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Don't find some primitive
On 02/16/2011 09:33 AM, Gabriel Morel wrote: > Hi, I finally managed to run ISE 10.1 on Linux to compile the raw > internet version of the fpga project, > but when I call 'make bin', the following error appears: > > ERROR:HDLCompilers:87 - "../../../fifo/fifo_2clock.v" line 26 Could not > find module/primitive 'fifo_xlnx_2Kx36_2clk' > > I checked in the makefile to be sure all is called well and the file > above is in there. Anybody know why? > > Am I obligated to update to sp3? Yes. sp3 fixed some major bugs. However, that upgrade is not likely to fix what you are seeing. Once again, I STRONGLY suggest that you NOT use the raw ethernet version, and use the new UHD version instead. There simply is no good reason to stick with the raw ethernet version. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Don't find some primitive
Where does one get the uhd version of the FPGA sources? Nick On Wed, Feb 16, 2011 at 12:39 PM, Matt Ettus wrote: > On 02/16/2011 09:33 AM, Gabriel Morel wrote: > > Hi, I finally managed to run ISE 10.1 on Linux to compile the raw > > internet version of the fpga project, > > but when I call 'make bin', the following error appears: > > > > ERROR:HDLCompilers:87 - "../../../fifo/fifo_2clock.v" line 26 Could not > > find module/primitive 'fifo_xlnx_2Kx36_2clk' > > > > I checked in the makefile to be sure all is called well and the file > > above is in there. Anybody know why? > > > > Am I obligated to update to sp3? > > Yes. sp3 fixed some major bugs. However, that upgrade is not likely to > fix what you are seeing. > > Once again, I STRONGLY suggest that you NOT use the raw ethernet > version, and use the new UHD version instead. There simply is no good > reason to stick with the raw ethernet version. > > Matt > > ___ > 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] Don't find some primitive
On 02/16/2011 09:45 AM, Nick Othieno wrote: > Where does one get the uhd version of the FPGA sources? In either the uhd git tree or by getting the ise12 branch from the FPGA git tree. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD example on USRP1 - Buffering
On 02/16/2011 02:50 AM, Sivaramakrishnan B C wrote: > Hi All, > > I was wondering if there is any buffering happening on the host and/or on > the USRP (USRP1 and N210) when the UHD send() and recv() methods are called? > Yes of course. There are buffers in the host and device (fifos). -josh > > Thanks, > Shiva > > On Thu, Feb 3, 2011 at 10:40 AM, Josh Blum wrote: > >> >>> 1. What is the parameter --spb, samples per buffer. And generally, what >> is >>> this buffer? >> >> This is the buffer that the application fills with samples, and passes >> into the call device->send() >> >>> 2. What is the relationship between spb (sample per buffer), duration >>> (number of seconds to transmit) and rate (rate of outgoing samples) and >>> wave-freq (waveform frequency in Hz)? >>> >> >> Samples per buffer is independent of these other variables. Indirectly, >> it controls how often the call to send() occurs. The option is there to >> allow users to experiment with various buffer sizes. >> >> -josh >> >> ___ >> 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] TI vs Freescale DSP for open-source development
Jeff, Al, Brian, A little bit delayed thank you to all of you! So, I took my time to investigate TI offer further and after all I should agree that TI support of open-source is indeed much more decent then that of Freescale. Combined with Jeff's comment about the number of developers who work with TI and with Freescale, this moves TI far behind Freescale. So, we decided to bet on TI for our open-source development. I asked TI guys about support of the new C66 family in their compilers and whether one can use them to develop an open-source code, and they said - yes, you can. Check out answers of Bill Miils at this thread: http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/92243/322882.aspx Now I can't wait to get an EMV for this great new C66 SoC to start playing. And in my dreams I see someone creating a "Gumstix C66 4-8 core" to use with USRP E100 - that would be truly killer SDR solution. On Sat, Jan 29, 2011 at 00:59, Jeff Brower wrote: > Alexander- > >> okay here are my 2 cents >> >> 2- TI actually offers all the tools you need to develop for their DSP for >> free, I can vouch for the C64x+ DSP since >> that's what I have experience using. You can download and look at the >> supported DSP for the free download from >> http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_sb/targetcontent/ >> >> >> The biggest issue you might run into with the free software is the ability >> to use a JTAG, if you want to use a JTAG >> you have to use Code Composer period. Though I've read about people using >> the free demo version of Code Composer >> (CCS) 4.0 with a very cheap JTAG ( < $150) to debug their DSP code. I think >> TI restricts the type of DSPs and JTAGs >> you can use with the free CCS I know that the JTAG I use (XDS560) is not >> supported. >> >> 3- TI support for open source is surprisingly decent. I've posted many >> questions on their support forums and TI >> engineers have always gotten back to me with alot of good information and >> continued asnwering as posted more follow up >> questions. >> >> 4- The learning tool has a bit of a learning curve that's for sure. I have >> posted a github link on the listserv >> yesterday which includes new custom blocks for GNU Radio using the C64x+ >> DSP. You might find the guide helpful in >> shedding some light about developing with TI tools. >> >> 6- I've been using TI software as an open source developer for almost 1.5 >> years now and I think they've managed to >> find a great balance between being a for profit company and a supplier of >> tools for the open source community. I >> don't have experience with freescale but my experience with TI has been a >> positive one. > > We are a heavy TI device user and have been for years. Al Fayez's comments > are pretty much accurate. > > I would add a few additional comments for MSC8x5x vs. C667x; i.e. high > performance multicore CPUs (the vendors are > moving away from the term "DSPs" nowadays, hehe). My comments apply *only* > to these high-end multicore devices. > > My two major concerns with Freescale are a) peer support and b) product > roadmap. First, there simply are not enough > users. For example there is a motoroladsp Yahoo Group (there are several TI > DSP Yahoo groups, C6x, C5x, etc) but in > the last several years activity on the mot group has slowly died off. There > are still knowledgeable Mot/Freescale DSP > guys on comp.dsp, but mostly in audio/acoustic related areas. > > Second, product roadmap. Before they were Freescale, Mot used to have a > strong, competitive product portfolio in DSP. > In 1998 they started a downhill slide when their CEO re-organized his own > DSP guys into an "internal resource > matrix", essentially deciding there wasn't actually a DSP market. Obviously > TI thought otherwise and became "a DSP > company" and we all know the rest of that story. (As a side note, that CEO > was Hector Ruiz, the same guy who later > presided over AMD during its decline and is now subject to an SEC > investigation). In 2004, Mot DSPs became Freescale > and enjoyed a resurgence with Starcore based devices. Starcore technology > has always looked quite promising, but in > my opinion, in day-to-day execution Freescale has not been able to match TI. > Now TI has out the C667x series, which > leaps beyond MSC815x/MSC825x. > > Not to mention that TI's multicore CPUs benefit indirectly, both in terms of > technical advances, and in terms of > customer support, from what TI is doing in smart phones, tablets, > high-performance ARM, etc. > > -Jeff > >> -Original Message- >> From: Alexander Chemeris >> To: Gnuradio-discuss >> Sent: Fri, Jan 28, 2011 10:24 am >> Subject: [Discuss-gnuradio] TI vs Freescale DSP for open-source development >> >> >> Hello all, >> >> We're working on an open-source WiMAX receiver/scanner and we're >> looking into using a high-performance DSP to process data from USRP. >> Right now we implement this process
[Discuss-gnuradio] 802.11g
Hi, we are doing some research here on decoding 802.11g using GNURadio. As far as i know there is code available for transmission of 802.11g frames on CGRAN but no receiver code. Is there any work going on for the receiver side right now? Is it theoretically possible to decode a signal received with the USRP N210? The bandwidth provided by the gigabit ethernet connection should be sufficient in contrast to the USRP1 USB connection, or am i wrong? I had a look at the (generic) GNURadio OFDM mod/demod code but its kind of hard to understand whats going on there. I have reused the ofdm-sync-pm code to generate seemingly helpful frequency offset values from the 802.11 short training sequence. I also extracted timing information by correlating with the known short sequence. However i am not sure if this synchronization is accurate enough for at least a few fft blocks. Is there anything like: fine timing/frequency correction, sampling offset correction, channel estimation or code for using pilot tone subcarriers in the generic GNURadio ofdm implementation that could be reused for a 802.11g receiver? What is with the code for extracting infos from the subcarriers? Would it be easier to rewrite it from scratch or can some of the gnuradio code be reused? Thanks for any information you can provide, Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Don't find some primitive
This is quick and off the top of the top of my head but here are some clues: 1)The appropriate Makefile.srcs should call both 'fifo_xlnx_2Kx36_2clk.v' and ''fifo_xlnx_2Kx36_2clk.xco' 2) In the log (capture all ISE output to a file for review by redirecting STDOUT) you should see the following lines if you grep for fifo_xlnx_2Kx36_2clk: >>> Adding source to project: >>> /home/ianb/ettus/sram_fifo/fpgapriv/usrp2/coregen/fifo_xlnx_2Kx36_2clk.v >>> Adding source to project: >>> /home/ianb/ettus/sram_fifo/fpgapriv/usrp2/coregen/fifo_xlnx_2Kx36_2clk.xco Compiling verilog file "../../../coregen/fifo_xlnx_2Kx36_2clk.v" in library work Module compiled Reading core <../../../coregen/fifo_xlnx_2Kx36_2clk.ngc>. 3) Coregen should automatically build this block from the spec in the .xco file to create the .ngc data read my ISE. You could try running coregen in the 'coregen' subdirectory to see if it can build it manually. Sometimes there can be issues with different versions of the FIFO generator tool included in ISE vs that specified in the .xco file. Report back with grep output from your log if you can't crack this. -Ian On Feb 16, 2011, at 9:33 AM, Gabriel Morel wrote: > Hi, I finally managed to run ISE 10.1 on Linux to compile the raw internet > version of the fpga project, > but when I call 'make bin', the following error appears: > > ERROR:HDLCompilers:87 - "../../../fifo/fifo_2clock.v" line 26 Could not find > module/primitive 'fifo_xlnx_2Kx36_2clk' > > I checked in the makefile to be sure all is called well and the file above is > in there. Anybody know why? > > Am I obligated to update to sp3? > > Thx > Gabriel > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] HUD make device
Is there a list of options can be passed to uhd::device::make ? So far I have found: "addr", "recv_buff_size" (is this in samples or bytes?). Regards Gaetano -- cpp-today.blogspot.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] HUD make device
On 02/16/2011 12:24 PM, Gaetano Mendola wrote: > Is there a list of options can be passed to uhd::device::make ? > http://www.ettus.com/uhd_docs/manual/html/identification.html > So far I have found: "addr", "recv_buff_size" (is this in samples or bytes?). http://www.ettus.com/uhd_docs/manual/html/transport.html -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] HUD make device
On Wed, Feb 16, 2011 at 9:29 PM, Josh Blum wrote: > > > On 02/16/2011 12:24 PM, Gaetano Mendola wrote: >> Is there a list of options can be passed to uhd::device::make ? >> > > http://www.ettus.com/uhd_docs/manual/html/identification.html > >> So far I have found: "addr", "recv_buff_size" (is this in samples or >> bytes?). > > http://www.ettus.com/uhd_docs/manual/html/transport.html Thank you, somehow I did miss those docs. Regards Gaetano -- cpp-today.blogspot.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Packet size UHD vs libusrp2
Hi, in libusrp2 samples are sent to device in packets of 370 samples, while in UHD now the max is 362, is there any way to have 370 in UHD as well ? Regards Gaetano -- cpp-today.blogspot.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Packet size UHD vs libusrp2
On 02/16/2011 01:02 PM, Gaetano Mendola wrote: > Hi, > in libusrp2 samples are sent to device in packets of 370 samples, > while in UHD now the max is 362, > is there any way to have 370 in UHD as well ? > Yes and maybe: The default recv_frame_size is the mtu of 1472 for a maximum length udp packet. The samples per packet is directly calculated from this number. You can increase this, however, your network card may or may not accept frames greater than 1500 bytes. http://www.ettus.com/uhd_docs/manual/html/transport.html#transport-parameters -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Packet size UHD vs libusrp2
On Wed, Feb 16, 2011 at 10:22 PM, Josh Blum wrote: > > On 02/16/2011 01:02 PM, Gaetano Mendola wrote: >> Hi, >> in libusrp2 samples are sent to device in packets of 370 samples, >> while in UHD now the max is 362, >> is there any way to have 370 in UHD as well ? >> > Yes and maybe: The default recv_frame_size is the mtu of 1472 for a > maximum length udp packet. The samples per packet is directly calculated > from this number. You can increase this, however, your network card may > or may not accept frames greater than 1500 bytes. > > http://www.ettus.com/uhd_docs/manual/html/transport.html#transport-parameters So changing ups_per_fifo it should be possible, I will try it. Regards Gaetano -- cpp-today.blogspot.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD + USRP2(RFX400)
I fix for RFX400 + UHD has been pushed to the master and next branches. -Josh On 02/07/2011 04:44 AM, Gaetano Mendola wrote: > Hi, > is the combo RFX400 with UHD supposed to work ? > > I tried the example ./tx_waveforms and it doesn't seems to work, even > if the device is recognized. > Using a WBX I get the expected result. > > Regards > Gaetano Mendola > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
