Re: [Discuss-gnuradio] Open-Hardware
On 01/12/2011 02:32 AM, Moeller wrote: Maybe an FPGA Experimentation kit could be extended with an RF/Sampling part: $400 price class, includes PowerPC, 64 DSP slices, Gigabit Ethernet, 64 MB RAM, just RF part and A/D converters are missing: http://www.eetimes.com/electronics-products/fpga-pld-products/4103784/-395-Virtex-5-FXT-FPGA-evaluation-kit Ok, not Open-Source hardware, but at least cheaper than USRP2. There's also the Xilinx SP601, which has roughly half the number of logic blocks as the board you mentioned above, but is also only $249.00. I don't have a good intuitive feel for the number of required logic blocks/LUTs/slices are required for any given task. -- 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] Open-Hardware
On 12.01.2011 09:11, Marcus D. Leech wrote: http://www.eetimes.com/electronics-products/fpga-pld-products/4103784/-395-Virtex-5-FXT-FPGA-evaluation-kit There's also the Xilinx SP601, which has roughly half the number of logic blocks as the board you mentioned above, but is also only $249.00. I don't have a good intuitive feel for the number of required logic blocks/LUTs/slices are required for any given task. I have no experience with such FPGA evaluation kits. Is there an easy way to attach a RF daughter board and ADC/DAC? What bus would be suitable, Rocket-IO or some parallel digital ports? I didn't find analog ports on the board. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio and CUDA reprised
On 01/12/2011 08:44 AM, Moeller wrote: On 11.01.2011 23:13, Andrew Hofmaier wrote: I've begun to look into accelerating GNURadio applications with Nvidia CUDA GPU's and have scanned through the archives of the discussion list. I had two questions on the topic: 1. Is the CUDA-GNURadio port done by Martin DvH circa 2008 still available and runnable? All links I've seen are broken. Is CUDA really suitable? There is a certain overhead in data communications. CUDA is only useful, if it can compute complex things without communicating. True. But with the DMA it's still faster when you compute things like long filters. Or if you have a wideband signal and you want to split it in several small band signals, it can compute way faster than SSE. Another advantage is that it's all done in parallel with the CPU (including most data movements if done properly), so you can work on the demodulation in the CPU and let the GPU do all the pre-filtering/signal shaping for you. But as you noted further, it's more for when your code is pretty much working in the off-line case and you want to make it work real time on big data streams. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: A Humble Request....for allowing to copy Circuit into PCB
On Wed, Jan 12, 2011 at 7:17 AM, Moeller moelle...@gmx.de wrote: You need a critical mass of developers to start a GNU-like open hardware. Anybody interested? It's a lot of work for a single person, but not so much in a shared effort. I absolutely agree. Production costs may be high for an individual trying to build a USRP equivalent, but I don't see why it couldn't be shared. PCB printing in particular can be done in batches, or locally by anyone with reasonable skill. The USRP has become a standard for SDR, and it would be good to get something comparable and open source. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Finally compiled USRP2 code works fine with UDP image ...but not with compiled Raw Ethernet Image
Hi all, I have successfully generated a usrp2 FPGA image in ISE 12.3 (ubuntu 10.10 32 bit version). When I burn my FPGA image with the UDP image (obtained from the repository) and I port it everything works fine. :-D But when I use the FPGA image with the raw ethernet image there is a problem (F led light glows but D led light doesnt glow). %-| Please do suggest me a solution to my problem. -- View this message in context: http://old.nabble.com/Finally-compiled-USRP2-code-works-fine-with-UDP-image-...but-not-with-compiled-Raw-Ethernet-Image-tp30653029p30653029.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] Re: Open-Hardware
schrieb Marcus D. Leech am 2011-01-12 02:40: Well, I *personally* don't care very much about random-disk-noise, errr, I mean Windows, but I'm sure others do :-) There is a lot of people outside the Linux world, especially in the non-academic hobbyist corner. These people seem to me to try to work with least possible changes, that is install no new OS, install no additional tricky exotic drivers, and at most plug in some USB device. That's perfectly ok for me. If these people should be serverd as well you unfortunately _have_ to to think about Windows, as hard and painful as it may seem. I read the UAC1 specs a year ago and thought Great, you can advertise up to 4MSPS on USB Audio!, but it turned out that it was specified for USB 1.1, which just cannot handle the data rates. :-( Then I found the SDR Widget, and they really get everything out of the Windows UAC1 driver. I thought you couldn't do more than 48Ksps with UAC1, no way no how. You can trick Windows to do 192Ksps via UAC1, I think. No sure if its 16 or 24 bit. Perhaps I should read that spec again, but it seems that UAC2 is the way forward, with 384Ksps audiophile DACs using UAC2 already becoming available. I can think of a way how the SDR Widget people do it: Different firmwares for UAC1 and UAC2. With a third for a more generic interface, this could be compatible and fun at the same time. An interesting device is the AD6655, which is an integrated ADC and signal processing chain (complex DDC, and one or more CIC decimators and FIR filters). Now that is not exactly the cheap one, but with its 150MSPS it would be quite a frequency range with low additional effort. What would be the goal for such a device? Which bandwidth are of interest, which dynamic ranges? Which frequency ranges? Extra frontends? IF from other transceivers or transverters? What would you do with it? Oh, I forgot one interesting device: http//:www.websdr.org/ Seems the hardware info is not linked any more, but its a DDS board with Ethernet interface. Very application specific, but all soldered by hand. Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser patrick dot strasser at student dot tugraz dot at Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio and CUDA reprised
I have a feeling -- from working with OpenCL for a while now (but, not in GNU Radio yet), watching profiling timing information (how long it takes to move data around, how long kernels take to get queued and executed) -- that what folks here have written seems mostly true: there is -significant- overhead so the number of computations must be quite high to make using a GPU better than just the CPU (if one is evaluating better just in terms of throughput, not taking into account that the GPU can be executed asynchronously w/r.t. the CPU hence the combined system is generally actually faster overall than just using the CPU). I think that if a GPU can be used, it will be most effective in things like filterbanks, or when searching for packets (via their unique sync sequence, so matched filtering), or very large FIR filters -- places where a LOT of computations and data must be processed and can be parallelized easily. In my initial testing, doing something simple such as c = a + b is probably better left to vector units (e.g., use VOLK once it's fully functional) -- but, as I wrote above, if timing constraints can be met then the GPU can do work in parallel with the CPU hence can increase system throughput somewhat even for such simple tasks. More as I understand program it; really, I'm still in the beginning of heading down this road ... If folks do make progress, I hope they post to this list for those of us interested in this topic. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio and CUDA reprised
Has anyone thought about something like Apple's Core Image for signal processing? Core Image lets you express image filters in a C-like filter language (a subset of GLSL). You chain a set of filters together to achieve the desired effect and then at runtime Core Image uses an LLVM complier to generate optimized code for your GPU or CPU using whatever vector capabilities it has. LLVM supports a growing list of back-end hardware. There is even some work targeting FPGAs. -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio and CUDA reprised
On Wed, Jan 12, 2011 at 2:44 AM, Moeller moelle...@gmx.de wrote: On 11.01.2011 23:13, Andrew Hofmaier wrote: I've begun to look into accelerating GNURadio applications with Nvidia CUDA GPU's and have scanned through the archives of the discussion list. I had two questions on the topic: 1. Is the CUDA-GNURadio port done by Martin DvH circa 2008 still available and runnable? All links I've seen are broken. Is CUDA really suitable? There is a certain overhead in data communications. CUDA is only useful, if it can compute complex things without communicating. But a data streaming application needs lots of I/O. The CPU with SSE is also very fast in things like FFT. I made some experiments with CUDA, but they were not very successful, far below the peak FLOPS you get in benchmarks. But I'm not an experienced programmer ... 2. Much of the results I've seen, both here and elsewhere, suggest that CUDA is not typically applicable to general GNURadio applications. It has worked in specific cases, but only where the data throughput requirements are very high and the algorithms are extremely Yes, I had the same experiences. I tried to let CUDA do the one-dimensional FFT. It was slower than on CPU, had a large communication overhead. Maybe better with larger FFT sizes, or with 2D FFT, or better programming ... In contrast, the sample programs were very fast, but also very special like Fractals computing, Image processing or particle physics. these cards for GNURadio applications? Some of the major relevant improvements are the ability to concurrently schedule multiple kernels and asynchronously perform memory transfers. I think important is that the kernels have to compute very much, compared to data transmission tasks. 1D FFT is not very computing-intensive, related to data shifting. What kind of algorithm do you want to port to CUDA? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio I've done some work with both CUDA and GNURadio, and I think there's definitely some potential there for using them jointly, but only for certain applications, and only if the software is architected intelligently. GPUs are incredibly powerful, with 1+TFLOP operation and 100+GB/s memory speeds within the GPU. I've used GPUs to perform real-time signal processing on 300+MHz of continuously-streaming data, without dropping a sample. But the PCI bus bandwidth of ~5GB/s can sometimes be a real bottleneck, so you have to design accordingly. You DON'T want to try to make individual drop-in CUDA replacements for multiple GNURadio processing blocks in a chain. It doesn't make any sense to send data to the GPU, perform an operation (eg filtering), bring the result back to the host, send some more data to the GPU, perform a 2nd operation, bring the data back, etc. The PCI transfers will eat you alive. The key is to send large chunks (10s or 100s of MBs) of data to the GPU, and do as much computation as possible while there. Large batched ffts, wideband frequency searches, channelizing, it's all gravy. It's great if you can stream wideband data to the GPU, have it do some computationally intensive stuff, perform a rate reduction, then stream the lower bandwidth data back to the host to do further (annoyingly serial) operations. You could even (if you wanted to) implement an entire transmitter or receiver within the GPU, with the CPU solely shuttling data to or from the ADC/DAC. In summary, yes please do get excited about CUDA/OpenCL -- it's great technology. When the USRP 9.0 comes out with a gigasample ADC/DAC, GPUs are there ready to do the heavy lifting :) -Steven ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: A Humble Request....for allowing to copy Circuit into PCB
Hi All, I have USRP1(4.5 Version) purchased from Matt Ettus around 2 years back. Am interested to sell them at half price. I have two mother boards with four daughter boards. I had purchased it for experimenting MIMO based designs. Since am not at all using them, now am planning to sell them. Boards are barely used and are as brand new one. Am from India. Please get back via mail with your contacts. Regards Sanjay On Mon, Jan 3, 2011 at 11:28 PM, Marten Christophe technosa...@gmail.comwrote: Hello ALL, Does you have an answer to my request , is there something for charity there is possibility for like me to use USRP1. Kind Regards, On Sun, Dec 12, 2010 at 10:14 PM, Marten Christophe technosa...@gmail.com wrote: Hello Matt, and All, Is there possible, you can sell only USRP1 board with all components, only board no enclosure no power supply only board. with all component soldered to it , i will arrange specified ratting power supply here locally, why i'm requesting it due to i'm a student and dont have that much money to buy full USRP1+shipping charges if you can send only USRP board without enclosures and power supply it will reduce shipping cost i have arrange so far $ 300 only , so if it is possible , i will be thankful to all of you, USRP1 is very much needed for my practicals and study you ought to run a program to sell your product to poor students at discounted rate as Ettus Research being a big organisation now , but USRP1 was developed as a open source hardware with the help of community and very use full for us. Thanks and Kind regards, On Thu, Nov 4, 2010 at 7:44 PM, Marten Christophe technosa...@gmail.comwrote: Hello Mr. Ettus, Thanks a lot, at least for you reply. Now I will have to search some other cheap SDR, or will have to wait another one year when i will get my scholarship then buy your marvelous product the USRP1.. Thanks and Kind regards, On Fri, Nov 5, 2010 at 1:08 AM, Matt Ettus m...@ettus.com wrote: No. We do not have or sell blank PCBs. Matt On 11/04/2010 12:30 PM, Marten Christophe wrote: O, Mr. Ettus, at least give me a blank PCB, coz by very hard work i have collected IC , FPGA , and all other things, by requesting sample part, if i were moneyed i must have buy USRP1, if i will have a blank PCB at least i will sold all parts , and i wont have to copy any others work, and design , and i will kept away my self from theft, you know, even i will PAY the blank PCB material cost. and postal charges, from US to india, but i buy USRP1 , that i need to shiped, and again high amount. after all i'm student...from India. Kind Regards, On Fri, Nov 5, 2010 at 12:51 AM, Matt Ettus m...@ettus.com mailto:m...@ettus.com wrote: No On 11/04/2010 12:20 PM, Marten Christophe wrote: Hello Mr. Ettus , If you are unable to provide that , know problem , but least reply my mail with negation so i wont wait and for you, and start trying to design PCB with the help of you .SCH file of USRP 1 and will collect money to fabricate it, but for only one PCB it take around $500 start cost. :( and more over before doing so, i want you permission b'coze it was designed by you so if it is my moral responsibility to seek your permission on first place. Kind Regards, Devendra Purohit On Thu, Nov 4, 2010 at 12:02 AM, Marten Christophe technosa...@gmail.com mailto:technosa...@gmail.com mailto:technosa...@gmail.com mailto:technosa...@gmail.com wrote: On Mon, Nov 1, 2010 at 11:04 PM, Marten Christophe technosa...@gmail.com mailto:technosa...@gmail.com mailto:technosa...@gmail.com mailto:technosa...@gmail.com wrote: Hello Mr. Ettus, Kindly provide me USRP motherboard Blank PCB board. i will pay for postage and material cost. I'm a poor student and USRP is needed for my research work and study, i have almost all components collected by sampling so i can assemble and sold all of them if i will have PCB . $1400+400+ UPS courier charges(oversease shipping) it is beyond my ability to spend. I'm a private Student and keen to learn,but I'm poor too , hence don't have capability to buy USRP, so I'm also trying to make USRP my self. but dont' have resources to fabricate PCB. though i have collected all component some of those were costly i arranged samples, only thing left is PCB. can you kindly help me to give me blank PCB for USRP ( whether usrp1 or usrp2) mother and daughter board . I will pay the cost what
Re: [Discuss-gnuradio] Open-Hardware
On 01/12/2011 03:20 AM, Moeller wrote: I have no experience with such FPGA evaluation kits. Is there an easy way to attach a RF daughter board and ADC/DAC? What bus would be suitable, Rocket-IO or some parallel digital ports? I didn't find analog ports on the board. The standard for expansion cards for such FPGA baseboards is something called FMC (Fpga Mezzanine Card), which is a 68-signal-line standard. -- 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] GNURadio and CUDA reprised
On Wed, Jan 12, 2011 at 9:56 AM, Steven Clark steven.p.cl...@gmail.com wrote: On Wed, Jan 12, 2011 at 2:44 AM, Moeller moelle...@gmx.de wrote: On 11.01.2011 23:13, Andrew Hofmaier wrote: I've begun to look into accelerating GNURadio applications with Nvidia CUDA GPU's and have scanned through the archives of the discussion list. I had two questions on the topic: 1. Is the CUDA-GNURadio port done by Martin DvH circa 2008 still available and runnable? All links I've seen are broken. Is CUDA really suitable? There is a certain overhead in data communications. CUDA is only useful, if it can compute complex things without communicating. But a data streaming application needs lots of I/O. The CPU with SSE is also very fast in things like FFT. I made some experiments with CUDA, but they were not very successful, far below the peak FLOPS you get in benchmarks. But I'm not an experienced programmer ... 2. Much of the results I've seen, both here and elsewhere, suggest that CUDA is not typically applicable to general GNURadio applications. It has worked in specific cases, but only where the data throughput requirements are very high and the algorithms are extremely Yes, I had the same experiences. I tried to let CUDA do the one-dimensional FFT. It was slower than on CPU, had a large communication overhead. Maybe better with larger FFT sizes, or with 2D FFT, or better programming ... In contrast, the sample programs were very fast, but also very special like Fractals computing, Image processing or particle physics. these cards for GNURadio applications? Some of the major relevant improvements are the ability to concurrently schedule multiple kernels and asynchronously perform memory transfers. I think important is that the kernels have to compute very much, compared to data transmission tasks. 1D FFT is not very computing-intensive, related to data shifting. What kind of algorithm do you want to port to CUDA? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio I've done some work with both CUDA and GNURadio, and I think there's definitely some potential there for using them jointly, but only for certain applications, and only if the software is architected intelligently. GPUs are incredibly powerful, with 1+TFLOP operation and 100+GB/s memory speeds within the GPU. I've used GPUs to perform real-time signal processing on 300+MHz of continuously-streaming data, without dropping a sample. But the PCI bus bandwidth of ~5GB/s can sometimes be a real bottleneck, so you have to design accordingly. You DON'T want to try to make individual drop-in CUDA replacements for multiple GNURadio processing blocks in a chain. It doesn't make any sense to send data to the GPU, perform an operation (eg filtering), bring the result back to the host, send some more data to the GPU, perform a 2nd operation, bring the data back, etc. The PCI transfers will eat you alive. The key is to send large chunks (10s or 100s of MBs) of data to the GPU, and do as much computation as possible while there. Large batched ffts, wideband frequency searches, channelizing, it's all gravy. It's great if you can stream wideband data to the GPU, have it do some computationally intensive stuff, perform a rate reduction, then stream the lower bandwidth data back to the host to do further (annoyingly serial) operations. You could even (if you wanted to) implement an entire transmitter or receiver within the GPU, with the CPU solely shuttling data to or from the ADC/DAC. In summary, yes please do get excited about CUDA/OpenCL -- it's great technology. When the USRP 9.0 comes out with a gigasample ADC/DAC, GPUs are there ready to do the heavy lifting :) -Steven Steven, That's great information and about along the lines of what I was going to say (sans the example of doing 300 MHz of processing since I haven't done anything that wide on it). I wanted to throw out another idea that no one seems to be bringing up, and this relates to a comment back about how CUDA is limited because of the bus transfers. That's not CUDA that is doing that but the architecture of the machine and having the host (CPU) and device (GPU) separated on a bus. That has nothing to do with CUDA as a language. But I keep thinking about the new Tegra from nVidia and to a lesser extent Sanybridge from Intel. These are showing a trend of moving GPUs and CPUs together on the same die. Sandybridge isn't really exciting from this perspective (yet) since their GPU core isn't very powerful and (I don't believe) CUDA-enabled. My point is, though, that the trend is exciting, and we are starting to see architectures that are moving away from the bus issues that are the biggest problems with GPU programming right now. Any effort spent now on working on GPU programming I think will have legs far into
Re: [Discuss-gnuradio] Re: Open-Hardware
On 01/12/2011 08:17 AM, Patrick Strasser wrote: Now that is not exactly the cheap one, but with its 150MSPS it would be quite a frequency range with low additional effort. What would be the goal for such a device? Which bandwidth are of interest, which dynamic ranges? Which frequency ranges? Extra frontends? IF from other transceivers or transverters? What would you do with it? Oh, I forgot one interesting device: http//:www.websdr.org/ Seems the hardware info is not linked any more, but its a DDS board with Ethernet interface. Very application specific, but all soldered by hand. No, it's not cheap. But because it has built-in DDC+CIC Decimator, you may not need a largish FPGA to do the DDC+Decimation, so you trade-off a more-expensive ADC against not having an FPGA at all. In terms of an RF front-end, I'd previously observed that the Rx range offered by the WBX covers a very wide swath of interesting frequencies for experimenters, namely 50Mhz to 2.2GHz. The core of that capability is an ADF4350 PLL synthesizer, and an ADL5387 quadrature mixer. -- 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] Need help in emergency for the fpga image
Have it a ise10 branch like it have a ise12 branch? Because the main repo in fpga.git don't compile. It have any difference between compilation on windows or on linux, some engineer of the ETS confirm that. Can anybody try to compile the main project of fpga.git and try it with a USRP2? For me and for future users, this bug have to be repair. thx a lot Gabriel - Original Message - From: Josh Blum j...@ettus.com To: discuss-gnuradio@gnu.org Sent: Wednesday, January 05, 2011 3:45 PM Subject: Re: [Discuss-gnuradio] Need help in emergency for the fpga image Allow to me clarify some details since I'm not sure what you are attempting to do: If you want to build the FPGA image for USRP2 over raw ethernet (gnuradio driver), you will need to use the master branch of the repo with ise10 (no exceptions). If you want to build the FPGA image for USRP2 over ipv4/udp (UHD driver), you will need to use the ise12 branch of the repo with ise12 (no exceptions). -Josh On 01/05/2011 12:13 PM, Gabriel Morel wrote: I'm using ISE 12.1 on windows, not on linux, is it different? I think is different for the method of calling command, not on the result. The bin file is suppose to be the same on linux or on windows, no? Gab - Original Message - From: Nick Foster n...@ettus.com To: Gabriel Morel morelgabr...@videotron.ca Cc: Discuss-gnuradio@gnu.org Sent: Wednesday, January 05, 2011 2:55 PM Subject: Re: [Discuss-gnuradio] Need help in emergency for the fpga image Thanks for the info. Try the following to compile it using the makefile we include in the distro. In order to do this you'll have to have the ISE12 settings exported in your shell. You can do this by running: source /opt/Xilinx/12.1/ISE_DS/settings32.sh *OR* source /opt/Xilinx/12.1/ISE_DS/settings64.sh depending on if you're running a 32-bit or 64-bit system. Then cd to the usrp2/top/u2_rev3 directory of the fpga repository and run: make bin The bin file will be in the subdirectory build-ISE?? where ?? is the version of ISE you use. So for 12.1 it will be at build-ISE12/u2_rev3.bin. Let me know if that FPGA file works for you and we can work from there. --n On Wed, 2011-01-05 at 14:32 -0500, Gabriel Morel wrote: - Original Message - From: Nick Foster n...@ettus.com To: Gabriel Morel morelgabr...@videotron.ca Sent: Tuesday, January 04, 2011 1:48 PM Subject: Re: [Discuss-gnuradio] Need help in emergency for the fpga image I asked you a bunch of questions you didn't answer the last time you posted. I can't help you unless you give me more details. Can you answer these questions for me? 1. Are you planning on using the older raw socket interface or UHD to communicate with your USRP2? I use the raw ethernet version. 2. Are you using the original SD card that came with your USRP2? yes I'm using a SD card that came with my USRP2 3. Does re-loading the original downloaded FPGA bin image onto the same SD card make it work for you? Yes 4. What specific firmware file (including full file name) are you loading onto the SD card? I'm using the WBX daughter board with the fpga bin file u2_rev3-20100603.bin and the firmware txrx_wbx_raw_eth_20100608.bin It is working when both file are loaded together 5. Are you using make bin or make -f Makefile.udp bin to compile your image? No, I created a project with the FPGA xc3s200fg456-5 in ISE 12.1 and I added all the files of all differents makefile of all folder of the principal makefile in fpga/usrp2/top/u2_rev3. I implemented the top module and I generated the programming file by double clicking on the command in the design tab. 6. Are you using the master branch or the ise12 branch of the Git repository? I think i used the master branch. I downloaded all the files in repository fpga.git and used the u2_rev3.v top in fpga/usrp2/top/u2_rev3. --n On Tue, 2011-01-04 at 13:29 -0500, Gabriel Morel wrote: Hello everyone, I must find a way to compile the FPGA project for the USRP2 to continue my Masters. I use ISE 12.1 and the top project u2_rev3 in the repository git://ettus.sourcerepo.com/ettus/fpga.git using all the files in different makefile. The compilation works well and I get the bin file of 842Kb. But during the test, only one of the lights glow and the computer does not see the radio. Is there someone who can reproduce this bug and help me find an answer? 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Baseband vs. Carrier freq.
I suggest you to first look into the USRP documentation available on gnuradio website. In it you will learn how a USRP upcoverts and downconverts a signal. In gnuradio we always deal with baseband signals i.e. the signal reaching your computer from the usrp or the signal entering the usrp from the computer is always a baseband signal. To know more about the signal that is in the air you have to find yourself a good book on communication systems. If you are new to Signals, RF communications etc then Communication Systems by Simon Haykin is a very good start. To understand more about upconversion/downcoversion and other digital signal processing then get yourself Understanding Digital Signal Processing by Rick Lyons but first download the pdf of the USRP documentation and read the first 15 pages. In that the author Firas explains how the USRP works in a simple way. Before, you start playing around with GRC by making your own flowgraph start with benchmark_tx.py/benchmark_rx.py examples. These are like the hello world of digital communications using gnuradio/usrp. There is a GRC example for bpsk in the GRC examples folder. Check that out too. -- John On Wed, Jan 12, 2011 at 1:31 AM, Songsong Gee gee.songs...@gmail.comwrote: Thank you for your answer :) Can you tell me more detail? With my understanding, a rectangular pulse from the file source will be an envelope and by up-conversion, a sinusoidal signal will be in the rectangular pulse? I want to know more detail on the up-conversion, Especially, a waveform on the air. 2011/1/12 Nick Foster n...@ettus.com Songsong, The baseband signal you are transmitting will be upconverted by the center frequency you specify in the USRP sink. In this case, the signal's center frequency will be 450MHz. Likewise, the USRP source center frequency you specify for the receiver will convert that frequency to baseband for the rest of your receive flowgraph. --n On Wed, 2011-01-12 at 15:38 +0900, Songsong Gee wrote: I'm wondering whether my flow graph is working correctly. I think that my flow graph just send a baseband signal Sender flow graph / scope plot Recevier flow graph / scope plot Yes, it receives correctly. But my question is The sender seems to send just a baseband signal, not a signal whose center freq. is not 450 MHz I think that it need to be multiplied by sinusoidal signal... -- Seokseong Jeon (aka Songsong Gee) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Seokseong Jeon (aka Songsong Gee) ___ 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] GNURadio and CUDA reprised
On Wed, Jan 12, 2011 at 11:03 AM, Tom Rondeau trondeau1...@gmail.com wrote: I wanted to throw out another idea that no one seems to be bringing up, and this relates to a comment back about how CUDA is limited because of the bus transfers. That's not CUDA that is doing that but the architecture of the machine and having the host (CPU) and device (GPU) separated on a bus. That has nothing to do with CUDA as a language. I think the notion that the language is not the barrier (the hardware architecture is) is precisely why I personally am more excited about OpenCL as a language than CUDA per-se. CUDA is inherently tied to nVidia hardware, and while is conceivable that CUDA will end up being supported on a wider variety of CPU/GPU architectures (e.g. the recently announced 'Project Denver'), I don't imagine it will ever find support on non-nVidia hardware. OpenCL is, on the other hand, enjoying support from a wide variety of hardware vendors (AMD/ATI, nVidia, IBM, Intel, Apple, etc.), and was designed to run on a wide variety of architectures (including a mix of CPU's, GPU's, accelerator/DSP boards, etc.). In the long run it seems to me to be a much better environment for dealing with heterogeneous computing, and without bringing up any serious concerns about being tied to any single vendor. Currently, though, GPUs still have a place for certain applications, even in signal processing and radio. They are not a panacea for improving the performance of all signal processing applications, but if you understand the limitations and where they benefit you, you can get some really good gains out of them. I'm excited about anyone researching and experimenting in this area and very hopeful for the future use of any knowledge and expertise we can generate now. Tom Agreed. Having spent some time on working with OpenCL on GPU's for solving a different sort of problem, I completely agree they are both powerful, and not a silver bullet. I would like to echo some of the previous comments: replacing single processing blocks in a flowgraph with a drop-in CUDA/OpenCL replacement is not likely to lead to any significant gains. It may relieve some of the work the CPU has to do (and thus be a net gain in terms of total samples that can be processed without dropping any on the floor), but I suspect Steve is correct: the big gains will be made in either applications requiring large filtering/channelizers/etc. or with complete RX and/or TX chains written in OpenCL, and GNURadio merely acting as a shuttle from the USRPx/UHD-enabled source/sink and the smaller trickle of bits coming back out (or going in). If that is the case, I think the follow-on question becomes: does GNURadio need to do anything to support OpenCL/CUDA/etc. enabled applications, or is everyone that is doing that sort of work simply writing their own custom block to interface with their custom OpenCL/CUDA/etc. kernel, since they are likely going to have to do all sorts of nasty optimization tricks to get the best performance for their particular application anyways? Or can a common block serve as a generic interface, which loads whatever custom kernel needs to be written, and works well enough in 90% of the cases? I'd like to think the latter is true, but I don't have any evidence as of yet that it might be. Perhaps at a later date I'll have something to share that points in one direction or the other. Doug -- Doug Geiger doug.gei...@bioradiation.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] The (in)famous channel 0 not receiving error
Hi everyone, I recently compiled and installed gnuradio. I then tried to find the usrp2: #find_usrps 00:50:c2:85::3b:5c hw_rev = 0x0400 Next I tried to plot an FFT of the GPS L1 signal (note that my daughterboard is a dbsrx2) #usrp2_fft.py -f 1.57542G usrp2: channel 0 not receiving usrp2::rx_samples() fail Where am I going wrong? I have seen other posts with people facing the same problem but they are from way back in mid-2010 and with different daughterboards from mine. Additional information: - daughterboard is a dbsrx2 - usrp2 was ordered sometime in October 2010 - I have the uhd driver installed but figured that it can exist with the usual Ethernet driver - Are there any firmware and/or fpga upgrades I am supposed to make? Nick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The (in)famous channel 0 not receiving error
Hi everyone, I recently compiled and installed gnuradio. I then tried to find the usrp2: #find_usrps 00:50:c2:85::3b:5c hw_rev = 0x0400 Next I tried to plot an FFT of the GPS L1 signal (note that my daughterboard is a dbsrx2) #usrp2_fft.py -f 1.57542G usrp2: channel 0 not receiving usrp2::rx_samples() fail Where am I going wrong? I have seen other posts with people facing the same problem but they are from way back in mid-2010 and with different daughterboards from mine. Additional information: - daughterboard is a dbsrx2 - usrp2 was ordered sometime in October 2010 - I have the uhd driver installed but figured that it can exist with the usual Ethernet driver - Are there any firmware and/or fpga upgrades I am supposed to make? Nick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio When you go to UHD, you have to change the firmware on the USRP2, which is available here: http://www.ettus.com/downloads/uhd_images/ Further, the UHD provides a different API than classic, and usrp2_fft.py uses the classic API. You can synthesize the functionality of usrp2_fft.py, using an UHD source, within Gnuradio Companion, in about five minutes. With the DBS_RX2, you have no choice but to convert to UHD (or back-port the DBS_RX2 support into the classic USRP2 interface). All new hardware from Ettus will only be supported using the UHD interface, and UHD is now robust enough that I recommend *all* new users use it. -- 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] Finally compiled USRP2 code works fine with UDP image ...but not with compiled Raw Ethernet Image
On 01/12/2011 05:13 AM, anirudh2059. wrote: Hi all, I have successfully generated a usrp2 FPGA image in ISE 12.3 (ubuntu 10.10 32 bit version). When I burn my FPGA image with the UDP image (obtained from the repository) and I port it everything works fine. :-D But when I use the FPGA image with the raw ethernet image there is a problem (F led light glows but D led light doesnt glow). %-| Please suggest a solution to my problem. I have said many times that ISE 12.3 works with the UDP version, but not 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] Finally compiled USRP2 code works fine with UDPimage ...but not with compiled Raw Ethernet Image
- Original Message - From: Matt Ettus m...@ettus.com To: anirudh2059. anirudh2...@gmail.com Cc: Discuss-gnuradio@gnu.org Sent: Wednesday, January 12, 2011 2:10 PM Subject: Re: [Discuss-gnuradio] Finally compiled USRP2 code works fine with UDPimage ...but not with compiled Raw Ethernet Image On 01/12/2011 05:13 AM, anirudh2059. wrote: Hi all, I have successfully generated a usrp2 FPGA image in ISE 12.3 (ubuntu 10.10 32 bit version). When I burn my FPGA image with the UDP image (obtained from the repository) and I port it everything works fine. :-D But when I use the FPGA image with the raw ethernet image there is a problem (F led light glows but D led light doesnt glow). %-| Please suggest a solution to my problem. I have said many times that ISE 12.3 works with the UDP version, but not with the raw ethernet version. Matt Matt: If the raw ethernet version can only be compile with ISE 10.1, why the bin file on the net is 842.4KB. When I compile the project on ISE10.1, the bin file is 837KB Anirudh: Which repo did you use for the raw ethernet version? ___ 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] Re: Open-Hardware
schrieb Marcus D. Leech am 2011-01-12 02:40: There is a lot of people outside the Linux world, especially in the non-academic hobbyist corner. These people seem to me to try to work with least possible changes, that is install no new OS, install no additional tricky exotic drivers, and at most plug in some USB device. That's perfectly ok for me. If these people should be serverd as well you unfortunately _have_ to to think about Windows, as hard and painful as it may seem. Yup, I reluctantly agree. But I have to assume that UAC2 is the future of USB Audio devices, and as such, should probably be the way to go forward. I'm pretty sure that the USB consortium didn't invent UAC2 purely for LInux users :-) Now, to keep ideas ball rolling here: So, by way of a start on a cheap(ish) receive chain block-diagram, I whipped-up this: http://www.sbrac.org/files/digital_receiver2.pdf This has a reasonable RF Rx chain, and includes a reasonable (20Msps) ADC. The trick is that instead of doing decimation in an FPGA, you select the correct filter from the bank, and change the ADC clock rate. Discrete passive filters are reasonably easy to design and fabricate, and if there are only, let's say, four of them, covering 4 different desired SPS rates, that might be acceptable. Also, the design terminates in an FMC connector, which allows you to mate this up with something like a Xilinx FPGA+1GiGe card, like the SP601 or similar. If one desired USB instead, then a simple EZ-FX2 USB-2.0 card with an FMC connector on it, and whatever logic was necessary to grab samples from the ADC could be designed and built. A wrinkle in such a design is that one is at the mercy of the tuning resolution of the down-converter, since there's potentially no DDC (unless you implemented one on the FPGA card). -- 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] Finally compiled USRP2 code works fine with UDPimage ...but not with compiled Raw Ethernet Image
Matt: If the raw ethernet version can only be compile with ISE 10.1, why the bin file on the net is 842.4KB. When I compile the project on ISE10.1, the bin file is 837KB Gabriel, I can't follow what you are doing here. Do you want the raw ethernet version or the udp version? Which version of ISE are you using? I strongly suggest you pick ONE ISE version and ONE version of the image that you want, and stop wasting your time and my time with the other version. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Passing a message from one block to other
Hi, Suppose I have two gnuradio blocks called gr_ACQUISITION and gr_TRACKING where, gr_TRACKING is dependent upon some result derived from gr_ACQ block. Is it possible to pass certain messages to gr_TRACK in order to change its state while the flowgraph is running? One way to do is to have an output line in gr_ACQUISITION that carries this info to the block gr_TRACKING but this doesn't seem like an attractive option to me. Thanks, John. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio and CUDA reprised
On 12.01.2011 14:25, Michael Dickens wrote: the CPU). I think that if a GPU can be used, it will be most effective in things like filterbanks, or when searching for packets (via their unique sync sequence, so matched filtering), or very large FIR filters -- places where a LOT of computations and data must be processed and can be parallelized easily. In my initial testing, doing something simple Is there an efficient parallel FIR implementation for CUDA? You need only few operations on a large set of data. So, isn't this too much for the stream-processor local-memory? If GPU global memory has to be used, this would lead to a slower concurrent access. And then there is still the transfer time from/to the computer RAM. It would be great to have a fast filter, but is it really faster than an optimized SSE CPU FIR? I had the feeling, that the ratio of computing operations vs. number of samples has to be high for a significant GPU vs. CPU speedup. I'm curious about how much speedup you can achieve for FIR filters (let's say large/sharp filters of 1024 taps). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Unofficial Gnuradio Installation Procedure for Newbies on Fedora 14
A little something to help along the newcomers like me :-) Unoffical installation guide for gnuradio on Fedora 14, January 2011 (Note the gnuradio installation procedure may change and hence render this guide unusable) == 1. Get the UHD prerequisites (install using your distro's package installer): * Git * C++ * CMake * Boost * LibUSB * Python * Cheetah * Doxygen * Docutils 2. Get th UHD source: git clone git://code.ettus.com/ettus/uhd.git 3. Generate UHD makefiles with cmake cd uhd-repo-path/host mkdir build cd build cmake ../ 4. Build and install UHD make make test sudo make install Ensure that libuhd.so is in the ldconfig path of your OS. In fedora 14 I did: updatedb locate libuhd.so then put the path from the locate command in: vim /etc/ld.so.conf.d/uhd.conf 5. Get gnuradio: git clone http://gnuradio.org/git/gnuradio.git 6. Install gnuradio prerequisites. Read the instructions from the readme within the gnuradio directory cd path to gnuradio/gnuradio vim README In Fedora 14, I installed all packages except fftw using the package manager. I had to install fftw from source because gnuradio requires a custom-built single precision floating point version of fftw 7. Get the fpga code for USRP2 (not sure whether this is important or not) cd path to gnuradio/gnuradio cd usrp2 rm -rf fpga (but read the inside the fpga directory readme first!) git clone git://ettus.sourcerepo.com/ettus/fpga.git 8. Next we download gr-uhd component of gnuradio. Within the gnuradio directory run the following commands git branch --track next origin/next git checkout next A directory called gr-uhd should be visible in the gnuradio directory. 9. Run ./bootstrap in the gnuradio directory. 10. Run ./configure and find out which components are not going to be installed due to missing prerequisites. Look for the missing prerequisites in the ./configure output and install them using your distro's package manager. Some of the components are not important. In my Fedora 14 installation I did not require gcell, gr-audio-jack, gr-audio-osx, gr-audio-windows and gr-comedi. In fedora 14, after installing sdcc I had to add the following to the bashrc path since configure could not find sdcc export PATH=$PATH:/usr/libexec/sdcc 11. Run make and sudo make install and then run sudo ldconfig . 12. Create the following line in your bashrc file so that the gnuradio python modules can be found export PYTHONPATH=/usr/local/lib/python2.7/site-packages 13. Edit /etc/security/limits.conf and add this line: @usrp - rtprio 50 14. Your ethernet card must be set to promiscuous mode. In fedora: cd /etc/sysconfig/network-scripts/ vim ifcfg-eth0 and add the line: PROMISC=yes 15. If the UHD images have not been written onto the SD card, get them from http://www.ettus.com/downloads/uhd_images/ and write them. Below is an extract of a procedure for writing the UHD images as posted on the gnuradio mailing list by Elvis Dowson: Step 05.01: Locate the correct device for the SD card Insert the SD card into the SD card reader slot of your computer. Run gparted, the graphical disk partitioning utility to quickly determine which device the SD card is connected. Usually /dev/sda would be your primary hard disk, and /dev/sdb would be the SD card. Step 05.02: Write the UHD FPGA and firmware images to the SD Card Write the new UHD FPGA image to the SD card: $ cd uhd/host/utils $ sudo ./usrp2_card_burner.py --dev=/dev/sdb --fpga=/home/elvis/Downloads/usrp2-image/u2_rev3_uhd_20100706.bin Write the new UHD firmware image to the SD card: $ sudo ./usrp2_card_burner.py --dev=/dev/sdb --fw=/home/elvis/Downloads/usrp2-image/txrx_uhd_20100706.bin 16. Configure the ethernet card connected to the USRP2 as follows: IP: 192.168.10.1 Subnet: 255.255.255.0 The default ip address of the USRP2 is 192.168.10.2 Important links http://www.ettus.com/uhd_docs/manual/html/index.html http://gnuradio.org/redmine/wiki/gnuradio/WikiStart 16. Configure the Network card connected to the USRP2 as follows: IP: 192.168.1.1 Subnet: 255.255.255.0 17. Run uhd_find_devices to check if the USRP2 can be detected Nick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Passing a message from one block to other
On Wed, 2011-01-12 at 13:43 -0600, John Andrews wrote: Hi, Suppose I have two gnuradio blocks called gr_ACQUISITION and gr_TRACKING where, gr_TRACKING is dependent upon some result derived from gr_ACQ block. Is it possible to pass certain messages to gr_TRACK in order to change its state while the flowgraph is running? One way to do is to have an output line in gr_ACQUISITION that carries this info to the block gr_TRACKING but this doesn't seem like an attractive option to me. This is what the message queues are for. You can see examples of its use in the gr-pager code. --n Thanks, John. ___ 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] Unofficial Gnuradio Installation Procedure for Newbies on Fedora 14
A little something to help along the newcomers like me :-) In Fedora 14, I installed all packages except fftw using the package manager. I had to install fftw from source because gnuradio requires a custom-built single precision floating point version of fftw I haven't had to install FFTW from source in a long time. Following: http://gnuradio.org/redmine/wiki/gnuradio/FedoraInstall Works for me. 7. Get the fpga code for USRP2 (not sure whether this is important or not) cd path to gnuradio/gnuradio cd usrp2 rm -rf fpga (but read the inside the fpga directory readme first!) git clone git://ettus.sourcerepo.com/ettus/fpga.git http://ettus.sourcerepo.com/ettus/fpga.git You shouldn't need the USRP2 FPGA code, you won't be able to compile it anyway, unless you have the ISE tools. -- 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
[Discuss-gnuradio] Open Source USRP ?
From the product brochure: The entire USRP design is open source, including schematics, firmware, drivers, and even the FPGA and daughterboard designs. When combined with the open source GNU Radio software, you get a completely open software radio system enabling host-based signal processing on commodity platforms. No software or licenses need to be purchased. It provides a complete development environment to create your own radios. No I wonder, how open is the design? The schematics are published. Is it a bit like GNU open source? Can somebody create EDA files from the schematics, publish them, modify the source, republish, produce own PCB and share the design with other people? Is it a free design, in the sense of free speech, not free beer (the motto of GNU software) ? I had the idea to reduce the complexity of USRP1 by omitting the 2nd channel (so only 1 TX/RX) and integrate a broadband RF tuner on a single board. This would require the freedom to modify the design and share the cost of PCB production. Just for a single PCB it would be too expensive. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio and CUDA reprised
On Jan 12, 2011, at 2:56 PM, Moeller wrote: On 12.01.2011 14:25, Michael Dickens wrote: the CPU). I think that if a GPU can be used, it will be most effective in things like filterbanks, or when searching for packets (via their unique sync sequence, so matched filtering), or very large FIR filters -- places where a LOT of computations and data must be processed and can be parallelized easily. Is there an efficient parallel FIR implementation for CUDA? You need only few operations on a large set of data. So, isn't this too much for the stream-processor local-memory? If GPU global memory has to be used, this would lead to a slower concurrent access. And then there is still the transfer time from/to the computer RAM. It would be great to have a fast filter, but is it really faster than an optimized SSE CPU FIR? I had the feeling, that the ratio of computing operations vs. number of samples has to be high for a significant GPU vs. CPU speedup. I'm curious about how much speedup you can achieve for FIR filters (let's say large/sharp filters of 1024 taps). The very large FIR filters was a thought, as an example of an operation that might benefit from a GPU at least when using OpenCL (or CUDA). I haven't done testing yet to know if a GPU can do better than a CPU using vector instructions ... but I'm getting there. If/when I do get there, I'll post my results thoughts. Your comment about global versus local memory certainly does seem true from reading the OpenCL specs. Most modern GPUs have 3 levels of memory: global (for the whole GPU, across all cores), core (across all kernel execution units), and kernel -- in order of decreasing size, increasing access speed, and increasing time to move data to/from. I've been playing around with global memory only so far, but I'll look into the other levels as well to see what they can provide the trade-offs required. Good interesting discussion! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Finally compiled USRP2 code works fine with UDPimage ...but not with compiled Raw Ethernet Image
- Original Message - From: Matt Ettus m...@ettus.com To: Gabriel Morel morelgabr...@videotron.ca Cc: Discuss-gnuradio@gnu.org Sent: Wednesday, January 12, 2011 2:43 PM Subject: Re: [Discuss-gnuradio] Finally compiled USRP2 code works fine with UDPimage ...but not with compiled Raw Ethernet Image Matt: If the raw ethernet version can only be compile with ISE 10.1, why the bin file on the net is 842.4KB. When I compile the project on ISE10.1, the bin file is 837KB Gabriel, I can't follow what you are doing here. Do you want the raw ethernet version or the udp version? Which version of ISE are you using? I strongly suggest you pick ONE ISE version and ONE version of the image that you want, and stop wasting your time and my time with the other version. Matt Matt, Ok, I will compile the raw ethernet project for the USRP2 to be sure that I can modify it and use the modified version to my master. I was try to compile the project fpga.git under ISE10.1 and under ISE12.1. The two method compile well, give two different size of binary file, but both don't work in the USRP2. I compared the size of my two binary file with the binary file on the net, and the raw ethernet file on the net is the same size than my binary file maked under ISE12.1. This is why I ask for anybody to make same procedure than me to compare the data. I have to find the way to compile a good file of the raw ethernet version. But after some test, I can affirm that the problem is not the card, not the version of ISE and not the radio that I use. The problem can be the project under the repo git://ettus.sourcerepo.com/ettus/fpga.git, or maybe it's not the good repo. And it's not only for me, I think it's a major bug and it needs to be repair. If you don't trust me, try it. Use Xilinx on Windows, create a project and put in all file of all different makefile in the repo for USRP2 with u2_rev3.v in top. Implement top module and create the bin file. After, give me some news plz. It's not loosing time, nobody had answer to my question and somebody have same problem than me. Thx a lot. Gab ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio and CUDA reprised
On Wed, Jan 12, 2011 at 3:22 PM, Michael Dickens m...@alum.mit.edu wrote: On Jan 12, 2011, at 2:56 PM, Moeller wrote: On 12.01.2011 14:25, Michael Dickens wrote: the CPU). I think that if a GPU can be used, it will be most effective in things like filterbanks, or when searching for packets (via their unique sync sequence, so matched filtering), or very large FIR filters -- places where a LOT of computations and data must be processed and can be parallelized easily. Is there an efficient parallel FIR implementation for CUDA? You need only few operations on a large set of data. So, isn't this too much for the stream-processor local-memory? If GPU global memory has to be used, this would lead to a slower concurrent access. And then there is still the transfer time from/to the computer RAM. It would be great to have a fast filter, but is it really faster than an optimized SSE CPU FIR? I had the feeling, that the ratio of computing operations vs. number of samples has to be high for a significant GPU vs. CPU speedup. I'm curious about how much speedup you can achieve for FIR filters (let's say large/sharp filters of 1024 taps). The very large FIR filters was a thought, as an example of an operation that might benefit from a GPU at least when using OpenCL (or CUDA). I haven't done testing yet to know if a GPU can do better than a CPU using vector instructions ... but I'm getting there. If/when I do get there, I'll post my results thoughts. Your comment about global versus local memory certainly does seem true from reading the OpenCL specs. Most modern GPUs have 3 levels of memory: global (for the whole GPU, across all cores), core (across all kernel execution units), and kernel -- in order of decreasing size, increasing access speed, and increasing time to move data to/from. I've been playing around with global memory only so far, but I'll look into the other levels as well to see what they can provide the trade-offs required. Good interesting discussion! - MLD Since FFTS IFFTs are so speedy on GPUs (CUFFT is quite good now), a good way is to filter in the frequency domain via FFT - pointwise multiply - IFFT. That way you can have arbitrarily sharp filters. -Steven ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio and CUDA reprised
On Jan 12, 2011, at 2:56 PM, Moeller wrote: The very large FIR filters was a thought, as an example of an operation that might benefit from a GPU at least when using OpenCL (or CUDA). I haven't done testing yet to know if a GPU can do better than a CPU using vector instructions ... but I'm getting there. If/when I do get there, I'll post my results thoughts. Very large FFT filters is also something worth looking into. GPUs have been considered for real-time coherent de-dispersion of radio astronomy data streams for pulsar detection. De-dispersion over large bandwidths at low frequencies requires ferociously-large FFT filters, but in order to make this a viable proposition, you likely have to do the detection and folding on the GPU as well, producing an output data stream that is several orders of magnitude smaller/slower than the input stream. I read a paper on this, (for the specific case of pulsar detection with real-time coherent de-dispersion), and they concluded that it's doable, on the higher end GPUs, provided that you do detection and folding on the GPU as well, otherwise you lose due to transfer overhead. It seems like the only time you ever really win with a GPU-based solution is when you have to suck in large amounts of data, pound on it furiously, and then produce an output stream that's relatively modest. Otherwise, you seem to lose due to data-transfer overhead. -- 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] Finally compiled USRP2 code works fine with UDPimage ...but not with compiled Raw Ethernet Image
Matt, Ok, I will compile the raw ethernet project for the USRP2 to be sure that I can modify it and use the modified version to my master. I was try to compile the project fpga.git under ISE10.1 and under ISE12.1. The two method compile well, give two different size of binary file, but both don't work in the USRP2. From my indirect experience on a non-GnuRadio Xilinx FPGA project, there's a bit of a black art to getting apparently-semantically-good Verilog from the it compiles, it passes timing, the simulations are good, to actually working on real hardware. Different versions of the tools use different optimization and placement strategies that can easily result in a piece of code that looks good simply not mapping onto hardware in a way that will work. If the software development process worked as poorly as the Verilog+real-hardware+vendor-blackmagic-tools apparently does, I'd leave software and take up basket weaving. I admit to having a certain admiration for the folks in the FPGA/Verilog world who can stomach the apparent capriciousness of it, and persevere and produce working hardware. Not for the faint of heart. -- 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
[Discuss-gnuradio] Low cost hardware option
Hi, i'm watching all discussion about poor students and the evil Mr Ettus who don't play like Santa Claus and whant to make some profit :). I'm also watching all topics and discussion regarding a low cost solution for use with GNURADIO. I guess we can have a cheap option to us and I'm very interested in work in such a solution. What I'm suggeting here is to take all people who want's to take the job and start a small project. I'm a embedded systems enthusiatic and was a starving student, now I'm a starving engineer, since I'm unemployed, that have some time to work on this project. The first question is: Ok, we need a low cost solution with some possible applications but what are the limits? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Open-Hardware
On 12.01.2011 20:22, Marcus D. Leech wrote: http://www.sbrac.org/files/digital_receiver2.pdf The RF range is interesting, from 70 MHz to 2.2 GHz. For USRP you would need 2 different boards to cover that range, or invest much more money into the WBX transceiver. This has a reasonable RF Rx chain, and includes a reasonable (20Msps) ADC. The trick is that instead of doing decimation in an FPGA, you select the correct If connected to a Xilinx board, FIR and decimation could still be done in the FPGA. Also, the design terminates in an FMC connector, which allows you to mate this up with something like a Xilinx FPGA+1GiGe card, like the SP601 or similar. This would be a very powerful combination and only $250 for the mainboard. With large memory 128 MB DDR2 memory controller, 32 DSP slices, MicroBlaze processing with MMU and FPU inside a Spartan-6. If one desired USB instead, then a simple EZ-FX2 USB-2.0 card with an FMC connector on it, and whatever logic was necessary to grab samples from the ADC could be designed and built. There's a cheap one here, with USB2 and Spartan3, only 70€ ($100) http://www.ztex.de/usb-fpga-1/usb-fpga-1.2.d.html Or this one for 145€? http://www.cesys.com/fpga/spartan/efm01_en.html Do you think the FMC interface can be realized with the 52 Xilinx GPIO pins, just with the specific FMC driver software? A wrinkle in such a design is that one is at the mercy of the tuning resolution of the down-converter, since there's potentially no DDC (unless you implemented one on the FPGA card). Is this really a problem? For spectral analysis this is only an axis shift. For demodulation you would have to do some kind of adaptive doppler compensation and phase tracking anyway. Could all this be done by continuously changing the DDC parameters over the wire? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Finally compiled USRP2 code works fine with UDPimage ...but not with compiled Raw Ethernet Image
On Wed, Jan 12, 2011 at 3:31 PM, Gabriel Morel morelgabr...@videotron.ca wrote: If you don't trust me, try it. Use Xilinx on Windows, create a project and put in all file of all different makefile in the repo for USRP2 with u2_rev3.v in top. Implement top module and create the bin file. After, give me some news plz. It's not loosing time, nobody had answer to my question and somebody have same problem than me. Thx a lot. Gab Instead of creating a new project, have you tried simply using the supplied Makefile and calling make from cygwin instead? I have never tried building the image from a Windows install of Xilinx - but in general the supplied makefile gives Xilinx the correct optimization/etc. settings to ensure the build works correctly. I'll note that while the instructions on http://www.ettus.com/uhd_docs/manual/html/images.html may not be exactly step by step, they do lay out that the build environment uses make, and in which directories the corresponding Makefiles can be found. Examining them will likely be very helpful if you wish to make modifications to the FPGA image - just as understanding the complete build environment will be just as important as Verilog/VHDL coding skills. I have never found that trying to re-create the project in the Xilinx GUI to be at all useful as far as getting working hardware is concerned. Doug -- Doug Geiger doug.gei...@bioradiation.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Low cost hardware option
Hi, i'm watching all discussion about poor students and the evil Mr Ettus who don't play like Santa Claus and whant to make some profit :). I'm also watching all topics and discussion regarding a low cost solution for use with GNURADIO. I guess we can have a cheap option to us and I'm I don't think anyone *seriously* thinks Matt is evil for wanting to make a profit from his hard labour. That makes as much sense as insisting that Henry Ford should have produced cars at materials cost, and his labour force should have worked for free, for the greater good. The fact is that Henry Ford contributed to the greater good *while* making a significant profit, and giving his workers a living wage, etc, etc. OMG, did I just compare Matt to Henry Ford? Hm. :-) :-) But, I think the question is there an approach to higher-bandwidth Gnu Radio compatible hardware that is simpler (and thus hopefully cheaper) than what is currently on the market, and can we reasonably totally-open-source the result is a reasonable one. very interested in work in such a solution. What I'm suggeting here is to take all people who want's to take the job and start a small project. I'm a embedded systems enthusiatic and was a starving student, now I'm a starving engineer, since I'm unemployed, that have some time to work on this project. The first question is: Ok, we need a low cost solution with some possible applications but what are the limits? Well, I posted a first-cut, potential block-diagram for the Rx side earlier today: http://www.srbac.org/files/digital_receiver2.pdf It covers a goodly swath of the bands of interest for hobbiests (68.75MHz to 2.2GHz). One could substitute a different PLL synthesizer to cover different bands of interest. In fact, if one added another level of output divider on the output of the ADF4350, one could go down to lower frequencies. Hmmm. Thinkage. Looking at the datasheet for the AD5387, the part is only specced to go down to 50MHz, but looking at the plots, it will likely go down much lower (perhaps as low as 5MHz). So adding another configurable, bypassable, divider stage on the output of the ADF4350 yields lower-frequency (in the HF bands) capability, and still provides coverage up to 2.2GHz. Actually, a single, fixed divider that is bypassable might give the required coverage, for example, a single /16 or something. Have to play with the numbers. It will handle up to 20Msps, in 4 discrete steps (2.5Msps, 5Msps, 10Msps, 20Msps). It specifies a generic FMC connector, so you could use it with an FPGA board that uses the FMC (FPGA Mezzanine Connector). FPGA evaluation boards are available *relatively* cheaply, since I think folks like Xilinx sell them through distributors as loss leaders to get you into the mood to design-in their technology to mass-market devices. But hey, if the Open Source community wants to leverage that little bit of market anomaly, that's just fine :-) The approach is to combine the RF front-end with a modestly-capable ADC, and use the ADC output as the demarc point where you plug it into some kind of FPGA+GiGe motherboard (like the Xilinx eval boards), or perhaps an EZ-FX2 type board giving a USB-2.0 interface. The USB board would be the cheaper way of getting data out to the PC, with some provisos, like it won't do DDC, so you're limited to whatever reasonable frequency resolution you can get out of the PLL synthesizer. With an FPGA board, you'll likely be able to do a DDC. Perhaps somebody wants to work on a comparable block-diagram for the Tx side? With roughly-comparable capabilities? One might make simplifying assumptions, like ADC and DAC clock rates are always common, which implies that the analog baseband filter selection would be common, etc, etc. The FMC connector standard apparently provides for 68 signal paths. That should be plenty. -- 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] Re: Open-Hardware
On 12.01.2011 20:22, Marcus D. Leech wrote: If connected to a Xilinx board, FIR and decimation could still be done in the FPGA. Agreed. There's a cheap one here, with USB2 and Spartan3, only 70€ ($100) http://www.ztex.de/usb-fpga-1/usb-fpga-1.2.d.html Or this one for 145€? http://www.cesys.com/fpga/spartan/efm01_en.html Do you think the FMC interface can be realized with the 52 Xilinx GPIO pins, just with the specific FMC driver software? Quite possibly, don't actually know that much about FMC, but my impression is that it's a fairly-generic way of putting expansion goop onto a generic FPGA board. Is this really a problem? For spectral analysis this is only an axis shift. For demodulation you would have to do some kind of adaptive doppler compensation and phase tracking anyway. Could all this be done by continuously changing the DDC parameters over the wire? Maybe, maybe not. Depends on the applications, but I'm guessing that a significant number of applications can get away with the fact that their signal of interest isn't exactly at DC, and do the DDC in software. For example, I happen to be interested in signals centered at 1420.40575Mhz. But I'd be perfectly happy if the 0Hz in the signals was actually at 1420.400MHz--I could compensate in the software side. Resolution of 50KHz or better should be achievable with the PLL I've shown on the block diagram. Phase noise improves with larger resolutions, however. -- 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] Low cost hardware option
2011/1/12 Marcus D. Leech mle...@ripnet.com Hi, i'm watching all discussion about poor students and the evil Mr Ettus who don't play like Santa Claus and whant to make some profit :). I'm also watching all topics and discussion regarding a low cost solution for use with GNURADIO. I guess we can have a cheap option to us and I'm I don't think anyone *seriously* thinks Matt is evil for wanting to make a profit from his hard labour. That makes as much sense as insisting that Henry Ford should have produced cars at materials cost, and his labour force should have worked for free, for the greater good. The fact is that Henry Ford contributed to the greater good *while* making a significant profit, and giving his workers a living wage, etc, etc. OMG, did I just compare Matt to Henry Ford? Hm. :-) :-) Yes, I'm kidding about the evil part :) Backing to the focus of my previous post, I saw the discussion and the block diagram you sent before, my sugestion is to organize this discussion and offer my work force. Later this could be a spin off project from gnuradio. Next friday I'll have my last task at the universty and, next week i'll place some serious effort on this. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Finally compiled USRP2 code works fine with UDPimage ...but not with compiled Raw Ethernet Image
On 01/12/2011 12:31 PM, Gabriel Morel wrote: Ok, I will compile the raw ethernet project for the USRP2 to be sure that I can modify it and use the modified version to my master. I was try to compile the project fpga.git under ISE10.1 and under ISE12.1. The two method compile well, give two different size of binary file, but both don't work in the USRP2. OK, so you chose the raw ethernet version. In reality, that is a bad choice since all future development is on the other version. But fine, that is what you chose. So now, stop using ISE 12, since I have told you that ISE 12 will not work with the raw ethernet version. I compared the size of my two binary file with the binary file on the net, and the raw ethernet file on the net is the same size than my binary file maked under ISE12.1. This is why I ask for anybody to make same procedure than me to compare the data. I have to find the way to compile a good file of the raw ethernet version. File size is meaningless. Use diff or md5sum to tell if files are the same or different. But after some test, I can affirm that the problem is not the card, not the version of ISE and not the radio that I use. The problem can be the project under the repo git://ettus.sourcerepo.com/ettus/fpga.git, or maybe it's not the good repo. And it's not only for me, I think it's a major bug and it needs to be repair. There is no bug. I just built it myself and it works just fine. The bin file should have an md5sum that starts with 3d4a. If you don't trust me, try it. Use Xilinx on Windows, create a project and put in all file of all different makefile in the repo for USRP2 with u2_rev3.v in top. Implement top module and create the bin file. After, give me some news plz. It's not loosing time, nobody had answer to my question and somebody have same problem than me. Thx a lot. Well, that is where you are going wrong. Don't create a project file. Use the makefile as is. It works fine. The Xilinx tools are very picky and we have everything set up just right. We also use them under linux which works much better. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Finally compiled USRP2 code works fine with UDPimage ...but not with compiled Raw Ethernet Image
Just to place some previous experience I have, if you have diferent configuration parameters, the hardware, possibly, will not work!!! Same code without change nothing, and will not work. This is not a USRP issue, FPGA projects can go wrong with diferent parameters for synthesis. 2011/1/12 Matt Ettus m...@ettus.com On 01/12/2011 12:31 PM, Gabriel Morel wrote: Ok, I will compile the raw ethernet project for the USRP2 to be sure that I can modify it and use the modified version to my master. I was try to compile the project fpga.git under ISE10.1 and under ISE12.1. The two method compile well, give two different size of binary file, but both don't work in the USRP2. OK, so you chose the raw ethernet version. In reality, that is a bad choice since all future development is on the other version. But fine, that is what you chose. So now, stop using ISE 12, since I have told you that ISE 12 will not work with the raw ethernet version. I compared the size of my two binary file with the binary file on the net, and the raw ethernet file on the net is the same size than my binary file maked under ISE12.1. This is why I ask for anybody to make same procedure than me to compare the data. I have to find the way to compile a good file of the raw ethernet version. File size is meaningless. Use diff or md5sum to tell if files are the same or different. But after some test, I can affirm that the problem is not the card, not the version of ISE and not the radio that I use. The problem can be the project under the repo git://ettus.sourcerepo.com/ettus/fpga.git, or maybe it's not the good repo. And it's not only for me, I think it's a major bug and it needs to be repair. There is no bug. I just built it myself and it works just fine. The bin file should have an md5sum that starts with 3d4a. If you don't trust me, try it. Use Xilinx on Windows, create a project and put in all file of all different makefile in the repo for USRP2 with u2_rev3.v in top. Implement top module and create the bin file. After, give me some news plz. It's not loosing time, nobody had answer to my question and somebody have same problem than me. Thx a lot. Well, that is where you are going wrong. Don't create a project file. Use the makefile as is. It works fine. The Xilinx tools are very picky and we have everything set up just right. We also use them under linux which works much better. 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] Finally compiled USRP2 code works fine with UDPimage ...but not with compiled Raw Ethernet Image
If you don't trust me, try it. Use Xilinx on Windows, create a project and put in all file of all different makefile in the repo for USRP2 with u2_rev3.v in top. Implement top module and create the bin file. After, give me some news plz. It's not loosing time, nobody had answer to my question and somebody have same problem than me. Thx a lot. Well, that is where you are going wrong. Don't create a project file. Use the makefile as is. It works fine. The Xilinx tools are very picky and we have everything set up just right. We also use them under linux which works much better. From last week's identical discussion: http://www.ruby-forum.com/topic/804184#972803 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Open-Hardware
If one desired USB instead, then a simple [Cypress] EZ-FX2 USB-2.0 card with an FMC connector on it, and whatever logic was necessary to grab samples from the ADC could be designed and built. By the way, USB3 is now hitting the mainstream, with PCI boards, motherboards, disk drives and USB sticks from all the major vendors. It provides a significant bandwidth boost over USB2 (it's designed for 3Gbits/sec, both ways simultaneously). This would be very useful to any newly designed USRP-like device. I haven't investigated what chips could replace the EZ-FX2 in a USB3 USRP. Oddly, the Cypress site seems to know nothing about USB3 devices! John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Open-Hardware
By the way, USB3 is now hitting the mainstream, with PCI boards, motherboards, disk drives and USB sticks from all the major vendors. It provides a significant bandwidth boost over USB2 (it's designed for 3Gbits/sec, both ways simultaneously). This would be very useful to any newly designed USRP-like device. I agree that it's worth considering, I think it has extended range as well. Competing very firmly with GiGe! I haven't investigated what chips could replace the EZ-FX2 in a USB3 USRP. Oddly, the Cypress site seems to know nothing about USB3 devices! John Yes, I found that same thing. Seems odd that Cypress wouldn't be one of the front-runners for USB-3.0. I will point out that one of the enticing things about 1GiGe is that you can run it over extended distances. Which for me is very interesting, since you could put a receiver at each antenna (think Alan Telescope Array), and haul signals back via 1GiGe. With USB-2.0, you can't do that without a funky device like the ICRON Ranger series (which inside, just re-packages USB-2.0 over 1GiGe, as far as I know). -- 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] Hooking the USRP up to a battery
Has anyone done this? Looking to see what configurations ppl have tried. Im using the 1800 dboard. Thanks, Isaac It should run fine on a 6 to 7.5V battery. It draws a couple of amps with a transceiver daughtercard in place. -- 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
[Discuss-gnuradio] Hooking the USRP up to a battery
Has anyone done this? Looking to see what configurations ppl have tried. Im using the 1800 dboard. Thanks, Isaac ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM receiver on USRP2
Hi, Tom I am not quite understand the ofdm_sync_xx.cc in python/gnuradio/blks2impl/. What is the difference between frequency synchronization and carrier frequency offset. Why we have to do the timing and frequency synchronization before it? Thanks, Guanbo Tom Rondeau wrote: On Tue, Feb 16, 2010 at 5:45 PM, Srinivas psriniva...@gmail.com wrote: Matt, Thanks for verifying the data rate calculation! I tried the other solutions that you suggested, namely, - increasing the data rate by a factor of 2 or 4 It works. - modifying the OFDM code to widen the search range - How do I widen the search range ? Should I be looking in the ofdm_sync_ blocks in blks2impl folder ? If yes, which synchronizer is currently used with ofdm_examples ? You need to add an argument to gr.ofdm_frame_acquisition in ofdm_receiver.py (in python/gnuradio/blks2impl). In the current Git master, this is located on line 109 of ofdm_receiver.py. After the ks[0] argument, you can put in an integer. This is the maximum number of bins the receiver will search over for correlation. It defaults to 10. - locking the usrps to a common reference My usrp2s are located wide apart so I guess this solution is not practical. Besides, this confirms that the problem is somewhere in the USRP2 board, right ? (as I tried swapping the daughter cards firmware with the working pair) Thanks, Srinivas Nope, this is typical of radio hardware. They are always off frequency. If two oscillators are off frequency and then multiplied up to another frequency, the difference will also be magnified. So a 2.4 GHz board will have a larger frequency offset than if you ran it just through the BasicTx/Rx boards (even though the ratios should be the same). Tom ___ 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/OFDM-receiver-on-USRP2-tp27557644p30658514.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] OFDM receiver on USRP2
Hi, Tom I am not quite understand the ofdm_sync_xx.cc in python/gnuradio/blks2impl/. What is the difference between frequency synchronization and carrier frequency offset. Why we have to do the timing and frequency synchronization before it? Also, Thanks, Guanbo Tom Rondeau wrote: On Tue, Feb 16, 2010 at 5:45 PM, Srinivas psriniva...@gmail.com wrote: Matt, Thanks for verifying the data rate calculation! I tried the other solutions that you suggested, namely, - increasing the data rate by a factor of 2 or 4 It works. - modifying the OFDM code to widen the search range - How do I widen the search range ? Should I be looking in the ofdm_sync_ blocks in blks2impl folder ? If yes, which synchronizer is currently used with ofdm_examples ? You need to add an argument to gr.ofdm_frame_acquisition in ofdm_receiver.py (in python/gnuradio/blks2impl). In the current Git master, this is located on line 109 of ofdm_receiver.py. After the ks[0] argument, you can put in an integer. This is the maximum number of bins the receiver will search over for correlation. It defaults to 10. - locking the usrps to a common reference My usrp2s are located wide apart so I guess this solution is not practical. Besides, this confirms that the problem is somewhere in the USRP2 board, right ? (as I tried swapping the daughter cards firmware with the working pair) Thanks, Srinivas Nope, this is typical of radio hardware. They are always off frequency. If two oscillators are off frequency and then multiplied up to another frequency, the difference will also be magnified. So a 2.4 GHz board will have a larger frequency offset than if you ran it just through the BasicTx/Rx boards (even though the ratios should be the same). Tom ___ 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/OFDM-receiver-on-USRP2-tp27557644p30658519.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] GNURadio and CUDA reprised
On Wed, Jan 12, 2011 at 3:39 PM, Marcus D. Leech mle...@ripnet.com wrote: On Jan 12, 2011, at 2:56 PM, Moeller wrote: The very large FIR filters was a thought, as an example of an operation that might benefit from a GPU at least when using OpenCL (or CUDA). I haven't done testing yet to know if a GPU can do better than a CPU using vector instructions ... but I'm getting there. If/when I do get there, I'll post my results thoughts. Very large FFT filters is also something worth looking into. GPUs have been considered for real-time coherent de-dispersion of radio astronomy data streams for pulsar detection. De-dispersion over large bandwidths at low frequencies requires ferociously-large FFT filters, but in order to make this a viable proposition, you likely have to do the detection and folding on the GPU as well, producing an output data stream that is several orders of magnitude smaller/slower than the input stream. I read a paper on this, (for the specific case of pulsar detection with real-time coherent de-dispersion), and they concluded that it's doable, on the higher end GPUs, provided that you do detection and folding on the GPU as well, otherwise you lose due to transfer overhead. It seems like the only time you ever really win with a GPU-based solution is when you have to suck in large amounts of data, pound on it furiously, and then produce an output stream that's relatively modest. Otherwise, you seem to lose due to data-transfer overhead. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org From my experiments, I don't thinks its a A _and_ B situation. I think if you have either A) a large amount of data _OR_ B) have to pound on it furiously, you get a win. Most filters needed for normal comms is not enough data or computation, but doing, maybe, a turbo product code or some heavy compute task with normal amounts of data (say, blocks of around 8k samples), you can get a win. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] re: Low cost hardware option
Hi, I am interested in helping out with making some new gnuradio hardware that is compatible with the USRP daughterboards. I worked with Matt doing CAD on the original gnuradio project hardware and have since then made lots more boards including a cyclone 3 board. Here is a possible hardware configuration: USB 3.0 transceiver IC or USB 3.0 microcontroller Altera Cyclone3 FPGA highspeed DAC/ADC If we use just a single channel ADC and DAC (ie half a USRP v1) then we can get away with a smaller/cheaper FPGA and have a cheaper/simpler board that can be paralleled if needed (ie. two boards hooked up to USB 3.0) Also we should pick a good open hardware license, here is one possibility I came across: http://freedomdefined.org/OSHW_draft I do all my work with Eagle CAD, and they sponsored a license for the gnuradio hardware project before, so we could look into getting a gnuradio specific license again or else consider using a free CAD program. Here's an eagle cad board I made with a cyclone3 FPGA on it designed to interface to a powersupply: http://rocketresearch.org/new/FPGA%20control%20module/FPGA%20control%20module%20PCB.png cheers, Jamie [Discuss-gnuradio] Low cost hardware option From: Euripedes Rocha Filho Subject: [Discuss-gnuradio] Low cost hardware option Date: Wed, 12 Jan 2011 19:03:17 -0200 Hi, i'm watching all discussion about poor students and the evil Mr Ettus who don't play like Santa Claus and whant to make some profit :). I'm also watching all topics and discussion regarding a low cost solution for use with GNURADIO. I guess we can have a cheap option to us and I'm very interested in work in such a solution. What I'm suggeting here is to take all people who want's to take the job and start a small project. I'm a embedded systems enthusiatic and was a starving student, now I'm a starving engineer, since I'm unemployed, that have some time to work on this project. The first question is: Ok, we need a low cost solution with some possible applications but what are the limits? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] re: Low cost hardware option
On Wed, Jan 12, 2011 at 8:36 PM, Jamie Morken jmor...@shaw.ca wrote: Hi, I am interested in helping out with making some new gnuradio hardware that is compatible with the USRP daughterboards. I worked with Matt doing CAD on the original gnuradio project hardware and have since then made lots more boards including a cyclone 3 board. Here is a possible hardware configuration: USB 3.0 transceiver IC or USB 3.0 microcontroller Altera Cyclone3 FPGA highspeed DAC/ADC If we use just a single channel ADC and DAC (ie half a USRP v1) then we can get away with a smaller/cheaper FPGA and have a cheaper/simpler board that can be paralleled if needed (ie. two boards hooked up to USB 3.0) The idea of USB3 is nice for the future, but I don't think there are enough peripherals out there yet to make a good board. I can't really find anything that's not completely preliminary and somewhat cheap. I'd like to propose what I think may be a good compromise. Altera Cyclone IV EP4CGX15 FPGA, Analog Devices AD9861 MxFE, USB2 microcontroller (for reprogramming the FPGA) in an ExpressCard/34 format. The FPGA has a hard PCIe 1.1 x1 lane with a hard IP core for PCIe connectivity. The PCIe interface has an extremely low latency and pretty high throughput - ~200MB/sec full duplex (after overhead and whatnot). The FPGA would be mostly empty since the PCIe core is hard. If the F169 package is used, it should be compatible with up to a EP4CGX30 which would give 80 18x18 multipliers and over 1Mbit of embedded memory. The ExpressCard format can fit into desktop PC's with simple and cheap adapters, or into laptops which have ExpressCard slots. ExpressCard has both an x1 PCIe connection as well as a USB 2.0 connection. I imagine a small USB 2.0 micro used for FPGA configuration and, possibly, a secondary way for samples to enter/exit the FPGA for different use cases (similar to the original USRP). But the main purpose would be for reconfiguration of the FPGA. Frequency synthesis can be an optional part of the assembly. I imagine a relatively inexpensive VCTCXO (2ppm accuracy?) along with an Si5338 clock synthesis chip. The idea, though, is to be completely optional for those who really want it. Otherwise, the FPGA PLL's can probably be good enough for most people. For connectors, 2 HDMI (commodity and cheap, twisted pair, shielded and rated to relatively high frequencies) - one for analog/baseband signals, one for digital I2C/SPI comms. Goes to a daughterboard carrier which can hold the daughterboard and a digital IO port expander for controlling the RX/TX IO [0:15] pins for the db connectors. I think the high bandwidth, low latency, and low CPU utilization of PCIe is very attractive. The main downside to the parts are the BGA components which can be daunting for hobbyists, but toaster ovens with PID controllers can really do a pretty amazing job. I'm not sure if this is a dealbreaker or not. I'm very interested to hear other people's opinions as to proposed interfaces, platforms, architectures, and connectivity. Jamie, I hope you don't see this as a hijacking of your original e-mail. I am particularly interested in your response. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] re: Low cost hardware option
On Wed, Jan 12, 2011 at 10:26 PM, Marcus D. Leech mle...@ripnet.com wrote: On 01/12/2011 10:01 PM, Brian Padalino wrote: Altera Cyclone IV EP4CGX15 FPGA, Analog Devices AD9861 MxFE, USB2 microcontroller (for reprogramming the FPGA) in an ExpressCard/34 format. The FPGA has a hard PCIe 1.1 x1 lane with a hard IP core for PCIe connectivity. The PCIe interface has an extremely low latency and pretty high throughput - ~200MB/sec full duplex (after overhead and whatnot). The FPGA would be mostly empty since the PCIe core is hard. If the F169 package is used, it should be compatible with up to a EP4CGX30 which would give 80 18x18 multipliers and over 1Mbit of embedded memory. The ExpressCard format can fit into desktop PC's with simple and cheap adapters, or into laptops which have ExpressCard slots. ExpressCard has both an x1 PCIe connection as well as a USB 2.0 connection. I imagine a small USB 2.0 micro used for FPGA configuration and, possibly, a secondary way for samples to enter/exit the FPGA for different use cases (similar to the original USRP). But the main purpose would be for reconfiguration of the FPGA. Frequency synthesis can be an optional part of the assembly. I imagine a relatively inexpensive VCTCXO (2ppm accuracy?) along with an Si5338 clock synthesis chip. The idea, though, is to be completely optional for those who really want it. Otherwise, the FPGA PLL's can probably be good enough for most people. There are a couple of downsides to a PCIe implementation that I can think of: o not all host platforms are going to have PCIe slots o it's noisy in there! Agreed on PCIe, though I think less platforms have USB3. When speaking of noise at baseband (2V driving 50Ohms), assuming you have a little can over the analog bits, is the noise that high? Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] re: Low cost hardware option
On 01/12/2011 10:46 PM, Brian Padalino wrote: Agreed on PCIe, though I think less platforms have USB3. Almost certainly the case right now. When speaking of noise at baseband (2V driving 50Ohms), assuming you have a little can over the analog bits, is the noise that high? Not sure--somebody should take some measurements. I'm increasingly liking the approach where you demarc at the digital output of the ADC that I suggested earlier where you terminate in something like a LPC-FMC connector or something equally convenient, which allows you to adapt to various getting bits to the host approaches. Including: o 1GiGe o USB-2.0 o USB-3.0 o PCIe But maybe that's the road to *more* expensive, not less (although cost is only ONE of the factors of a project like this). -- 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
[Discuss-gnuradio] Change of complex binary file format for Matlab.
Hello,
I am trying to use rx_samples_to_file.cpp in UHD to save samples received.
UHD seems save samples in complex integer format in c++.
However, it is not possible to read that format from Matlab.
I have checked the Matlab utilities in Gnuradio, but they were not useful.
Is that any simpler way to change the formats of the saving file so that
Matlab can easily read?
Another question is that why the saved samples are integer format? not
float?
Thanks for reading.
std::vectorstd::complexshort
buff(dev-get_max_recv_samps_per_packet());
std::ofstream outfile(file.c_str(), std::ofstream::binary);
while(num_acc_samps total_num_samps){
size_t num_rx_samps = dev-recv(
buff.front(), buff.size(), md,
uhd::io_type_t::COMPLEX_INT16,
uhd::device::RECV_MODE_ONE_PACKET
);
outfile.write((const char*)buff[0], num_rx_samps *
sizeof(std::complexshort));
-- *
*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Change of complex binary file format for Matlab.
I am trying to use rx_samples_to_file.cpp in UHD to save samples received. UHD seems save samples in complex integer format in c++. yes, COMPLEX_INT16 However, it is not possible to read that format from Matlab. I'm not a huge matlab fan, but I am sure that it can read integers from a file. http://tinyurl.com/6kyxdk4 I have checked the Matlab utilities in Gnuradio, but they were not useful. Its looks like you are not very familiar with matlab, so I suggest (out of my person preference) that you take this time to learn python+scipy http://www.scipy.org/ For one, its free. And I have always found myself more productive with python, and I have found the plotting widgets and mathematics that come with scipy give me everything I need. Is that any simpler way to change the formats of the saving file so that Matlab can easily read? You can change the example easily to write binary floats. And with a tiny bit more effort and a for loop you can write a text formatted file as well. Another question is that why the saved samples are integer format? not float? To save disk space and IO overhead for large captures or high data rates. You will appreciate this if you change the example to output a text format. Good luck, -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] re: Low cost hardware option
Jamie- Hi Brian, That sounds like a pretty good system. I should say right off the bat that if I am involved to make this I would want to add a clause in the open source hardware license to not allow the hardware to be used for military applications. I think it is important to state this at the start before I would get involved working on a new gnu radio board. If people can live with that requirement I am happy to do the layout work. Obtaining critical mass with a community based, open source project is difficult enough -- you can see the very few examples that are successful and still alive after a couple of years. I'm not saying you're wrong or right, but if you make the path more narrow, your chances of success -- i.e. reaching milestones on the path and getting others to follow you -- decrease. Can you show some examples of other *successful* open source / open hardware projects where the license has this clause? -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Change of complex binary file format for Matlab.
Hi
I am not that coded up on UHD, but I would think that they have the same
type of file writing system as is used in the GNU Radio code. In the GNU
Radio code they use a binary file writing system. I have attached a matlab M
file that reads these types of files, the file can be found in GNU Radio
file address ~/gnuradiio/gnuradio-core/src/utils. There are a large number
of matlab M files there so just have a look for the type of stuff you want
to do.
Hope it help
Regards
Alan Jones
On 13 January 2011 07:00, Sangho Oh sangho...@gmail.com wrote:
Hello,
I am trying to use rx_samples_to_file.cpp in UHD to save samples
received.
UHD seems save samples in complex integer format in c++.
However, it is not possible to read that format from Matlab.
I have checked the Matlab utilities in Gnuradio, but they were not useful.
Is that any simpler way to change the formats of the saving file so that
Matlab can easily read?
Another question is that why the saved samples are integer format? not
float?
Thanks for reading.
std::vectorstd::complexshort
buff(dev-get_max_recv_samps_per_packet());
std::ofstream outfile(file.c_str(), std::ofstream::binary);
while(num_acc_samps total_num_samps){
size_t num_rx_samps = dev-recv(
buff.front(), buff.size(), md,
uhd::io_type_t::COMPLEX_INT16,
uhd::device::RECV_MODE_ONE_PACKET
);
outfile.write((const char*)buff[0], num_rx_samps *
sizeof(std::complexshort));
-- *
*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
%
% Copyright 2001 Free Software Foundation, Inc.
%
% This file is part of GNU Radio
%
% GNU Radio is free software; you can redistribute it and/or modify
% it under the terms of the GNU General Public License as published by
% the Free Software Foundation; either version 2, or (at your option)
% any later version.
%
% GNU Radio is distributed in the hope that it will be useful,
% but WITHOUT ANY WARRANTY; without even the implied warranty of
% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
% GNU General Public License for more details.
%
% You should have received a copy of the GNU General Public License
% along with GNU Radio; see the file COPYING. If not, write to
% the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
% Boston, MA 02111-1307, USA.
%
function v = read_complex_binary (filename, count)
% ## usage: read_complex_binary (filename, [count])
% ##
% ## open filename and return the contents as a column vector,
% ## treating them as 32 bit complex numbers
% ##
%if ((m = nargchk (1,2,nargin)))
% usage (m);
%endif;
if (nargin 2)
count = Inf;
end
f = fopen (filename, 'rb');
if (f 0)
v = 0;
else
t = fread (f, [2, count], 'float');
fclose (f);
v = t(1,:) + t(2,:)*i;
[r, c] = size (v);
v = reshape (v, c, r);
end
%endfunction;___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio and CUDA reprised
On 13.01.2011 01:49, Tom Rondeau wrote: From my experiments, I don't thinks its a A _and_ B situation. I think if you have either A) a large amount of data _OR_ B) have to pound on it furiously, you get a win. Most filters needed for normal comms is not enough data or computation, but doing, maybe, a turbo product code or some heavy compute task with normal amounts of data (say, blocks of around 8k samples), you can get a win. Even for FFT you have to check it carefully. I really lost time with the GPU. Some benchmarks only count kernel time without transfer time, some others compare an optimized CUFFT against a non-optimized CPU implementation. You have to compare GPU time including transfers against something like FFTW. After that, the speedup is not very high any more, depending on the transform size. To really boost your computations, more operations should be done on the same data set. I think FFT is not very suitable for GPU because of the butterfly structure (many data transfers between the blocks). Thinks like FEM (finite element) are more suitable, because differential equations are solved only on local and direct neighbor data. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] re: Low cost hardware option
On Jan 12, 2011, at 9:17 PM, Jamie Morken wrote: That sounds like a pretty good system. I should say right off the bat that if I am involved to make this I would want to add a clause in the open source hardware license to not allow the hardware to be used for military applications. I think it is important to state this at the start before I would get involved working on a new gnu radio board. If people can live with that requirement I am happy to do the layout work. How would you define military applications? I collect surplus military gear as a hobby, and I'm presently working on a GNUradio-based implementation of a decoder for high-speed Morse code transmissions from my vintage AN/GRA-71 code-burst keyer (for which key pieces of the original reception hardware is unobtainium). I'm presently working entirely in simulation, but my USRP will get pressed into service for this before long. Would you consider that application to be military? Or how about if I were to use the hardware to intercommunicate with other military radio hardware (such as any of the countless surplus military radios used on the ham radio bands every day)? What if I throw it in my HMMWV and use it on a ham band during a Veteran's Day parade? What if a soldier wishes to use the hardware on-base for MARS activities? If any such things would be considered military, then I'd neither use nor contribute towards any hardware that's shackled by such a silly restriction. Furthermore, I doubt very much that the restriction would be at all enforceable. Personally, I don't think that any prior restraint placed upon end use of the hardware (beyond the requirement to keep derivative works open in most cases) is compatible with the very libertarian principles of the open software movement. I've released code under GPL. I thus place certain limited restrictions on the use of the code to keep it open, but beyond those limited restrictions, it's really none of my business to tell people what they can and can't do with it. If I wanted to control its end use to that degree, then I wouldn't have released it in the first place. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] re: Low cost hardware option
On 13.01.2011 02:36, Jamie Morken wrote: I am interested in helping out with making some new gnuradio hardware that is compatible with the USRP daughterboards. I worked with Matt doing CAD on the original gnuradio project hardware and have since then made lots more boards including a cyclone 3 board. So, you're a real expert on Gnuradio hardware ... Great! Also we should pick a good open hardware license, here is one possibility I came across: http://freedomdefined.org/OSHW_draft Good. It's a bit like the LGPL. It allows also to combine open-source with closed-source. The GPL-way would be too strict, because practically you can't ban closed-source components from a complex PCB. I do all my work with Eagle CAD, and they sponsored a license for the gnuradio hardware project before, so we could look into getting a gnuradio specific license again or else consider using a free CAD program. Even if Eagle has more capabilities, I think it would be cool to use the GNU-tool gEDA to create a Gnuradio-Hardware. So it would be a complete GNU world, from hard- to software. I didn't use gEDA before. Would it be possible to replace Eagle completely by gEDA (routing, EMI optimization, Gerber files, all CAM-relevant data)? Wasn't the first USRP announced as a demonstration of gEDA capabilities? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] re: Low cost hardware option
- Original Message - From: Jeff Brower jbro...@signalogic.com Date: Wednesday, January 12, 2011 9:43 pm Subject: Re: [Discuss-gnuradio] re: Low cost hardware option To: Jamie Morken jmor...@shaw.ca Cc: discuss-gnuradio@gnu.org Jamie- Hi Brian, That sounds like a pretty good system. I should say right off the bat that if I am involved to make this I would want to add a clause in the open source hardware license to not allow the hardware to be used for military applications. I think it is important to state this at the start before I would get involved working on a new gnu radio board. If people can live with that requirement I am happy to do the layout work. Obtaining critical mass with a community based, open source project is difficult enough -- you can see the very few examples that are successful and still alive after a couple of years. I'm not saying you're wrong or right, but if you make the path more narrow, your chances of success -- i.e. reaching milestones on the path and getting others to follow you -- decrease. Can you show some examples of other *successful* open source / open hardware projects where the license has this clause? Hi Jeff, All non-commercial use only clauses most likely restrict most military use, and these are quite common, and are far more restrictive than a non-military use only clause. I do follow what you are saying though, but its a choice like ethical investing, it makes economic sense to some people and seems foolish to some people. cheers, Jamie -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Change of complex binary file format for Matlab.
Thanks a lot. I found the problem. I should have used 'int16' instead of 'int' nor 'float'. I think I have better spectrum shape for 20Mhz signal using UHD compared to gnuradio usrp2_rx_cfile.py. But I found high frequency portion is somewhat suppressed than the original samples transmitted. One question is that whether it is possible to demodulate 20Mhz signal using Gnuradio. I think many are trying to demodulate 802.11 packets, but still cannot found any one succeeded. The maximum sampling that Gnuradio can provide rate is 25Mhz with decimation 4. But I am curious about whether it is possible to demodulate the 20Mhz signal without 2x or 4x oversampling. On Thu, Jan 13, 2011 at 12:31 AM, Josh Blum j...@joshknows.com wrote: I am trying to use rx_samples_to_file.cpp in UHD to save samples received. UHD seems save samples in complex integer format in c++. yes, COMPLEX_INT16 However, it is not possible to read that format from Matlab. I'm not a huge matlab fan, but I am sure that it can read integers from a file. http://tinyurl.com/6kyxdk4 I have checked the Matlab utilities in Gnuradio, but they were not useful. Its looks like you are not very familiar with matlab, so I suggest (out of my person preference) that you take this time to learn python+scipy http://www.scipy.org/ For one, its free. And I have always found myself more productive with python, and I have found the plotting widgets and mathematics that come with scipy give me everything I need. Is that any simpler way to change the formats of the saving file so that Matlab can easily read? You can change the example easily to write binary floats. And with a tiny bit more effort and a for loop you can write a text formatted file as well. Another question is that why the saved samples are integer format? not float? To save disk space and IO overhead for large captures or high data rates. You will appreciate this if you change the example to output a text format. Good luck, -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *From: Sangho Oh * *Voice mail: (609) 759-1552* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
