Re: [Discuss-gnuradio] cheap sdr platform / OpenSource-Hardware

Yes, for some student and hobby experiments we need cheaper SDR. I like the idea of OpenSource-Hardware. Material cost is usually not too high. And it's possible to modify designs, improve it, strip down for cheaper variants ... A good toy for hardware-experimenting and to gain experience in elect

Re: [Discuss-gnuradio] Can't set center frequency of USRP2 w/DBSRX

ning in the bands at 800 MHz. It seems to communicate. But we receive no signal in the expected frequency. Just always the same noise with some fixed lines, regardless of the frequency setting. Any idea what could be wrong? All other daughter-boards work fine, except the DBSRX. Moeller p

[Discuss-gnuradio] USRP2 and DBSRX compatibility (?)

te useless for us without the DBSRX. Other daughterboards are working fine. So I assume the firmware, the mainboard and our software installation is correct. Moeller ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailma

Re: [Discuss-gnuradio] USRP2 and DBSRX compatibility (?)

rent gcc 4.5.0 compiler. I had to change the sources. I will provide a patch for that later. Moeller ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gnuradio source patch to make it work with a current GCC 4.5.0

inserted. This takes not much time when writing the source, less than writing a full documentation document later. Moeller 41c41 < boost::weak_ptr value; --- > boost::weak_ptr value; 43c43 < usrp_table_entry(const std::string &_key, boost::weak_ptr _value) --- > u

Re: [Discuss-gnuradio] gnuradio source patch to make it work with a current GCC 4.5.0

cks I saw some of the "docstrings" in the gnuradio source, but not in the Doxygen-Doc. Can this be integrated, or does it need a second independent Doc? Moeller On 04 > http://gnuradio.org/doc/doxygen/modules.html > > The Gnu Radio deve

[Discuss-gnuradio] USRP2 control from Octave/Matlab, Tune Radio / Take Samples interface functions

setting 2. taking samples as a signal snapshot into separate function calls ??? It would mean that the USRP2 is keeping the tuned settings. So I would have these two functions: usrp2_tune(frequency,decimation,gain,...) and usrp2_rx(number_of_samples) possibly with a time trigge

Re: [Discuss-gnuradio] Matlab interface to USRP

ng I miss, that professors do not promote the free alternatives SciLab and Octave. I think for gnuradio and USRP it would be best to provide multilingual interfaces, that the user can choose between the environment he likes. Matlab, Octave and C++ are very important tools for signal processing and analysis. Moeller ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Unknown dboard-id

Is my impression right, that the dboard id 2 is for the original dbsrx variant and the dboard id 13 ist for the usrp2 patched variant? I was wondering if the programming was successful or not. The modification instructions have no comment about this. With the id 13 now it's working with the ursp2

Re: [Discuss-gnuradio] Matlab interface to USRP

, sometimes not. At least for my code, I try do avoid proprietary specials. It's an ideological question (promoting Octave over Matlab), whether we want the Octave-only style (which looks better indeed), or a Matlab-compatible style.I don't want to judge about this, since I didn't c

[Discuss-gnuradio] Universal device API, parameter standardization?

ld be done all automatically. Moeller ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio source patch to make it work with a current GCC 4.5.0

On 04.08.2010 19:24, Eric Blossom wrote: > On Wed, Aug 04, 2010 at 05:35:01PM +0200, Moeller wrote: >> Oh sorry, thanks for the hint. >> Apparently I only visited those source files without doxygen comments. > FWIW, the doxygen comments are in the .h files > Eric >From

Re: [Discuss-gnuradio] Universal device API, parameter standardization?

nly. I think that should be realistic. The ADC are not that expensive. There are some amateur solutions around 100$, but they use the soundcard as ADC. For an oscilloscope that's not enough bandwidth. Moeller ___ Discuss-gnuradio mailing list Dis

Re: [Discuss-gnuradio] Brief tags describing each source file

xygen statements are also very nice for generating a software manual from the source and additional LaTex text files. > I suspect that if you, Moeller, submitted a patch that added > a similar comment to every GNU Radio source file that you understand > the function of, it would be accepted.

Re: [Discuss-gnuradio] Brief tags describing each source file

xygen statements are also very nice for generating a software manual from the source and additional LaTex text files. > I suspect that if you, Moeller, submitted a patch that added > a similar comment to every GNU Radio source file that you understand > the function of, it would be accepted.

Re: [Discuss-gnuradio] Free Signal Analysis Tool

The GUI is not very important for me. Moeller ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Openbts-discuss] [Discuss-gnuradio] Free Signal Analysis Tool

GnuRadio is a good design for "live" signal processing with your radio hardware. In offline signal analysis I prefer Matlab or Octave. There are many toolboxes available for all fields of application. Python is more powerful as a language, but Octave is easier to use. In Octave you write A' for

Re: [Discuss-gnuradio] Can't set center frequency of USRP2 w/DBSRX

On 11.08.2010 15:49, spaceyaeon wrote: > Hello, > > I am having a similar problem as mentioned by Moeller in his message. I have > made the required modifications to be USRP2 + DBSRX. All I see is a noise > floor when I try usrp2_fft.py. I am inputting 2.165 GHz signal through RF

Re: [Discuss-gnuradio] Can't set center frequency of USRP2 w/DBSRX

Linux': command('sync') So, it should have been in sync after burning. But it's too late now, I can't reconstruct all exactly any more. At least the DBSRX is working now. Moeller ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Can't set center frequency of USRP2 w/DBSRX

On 12.08.2010 00:10, Jason Abele wrote: > Testing the id number of your DBSRX on USRP2: Thanks Jason, your diagnosis instructions are very clear now. I thought it was more than just changing an ID number. Can you add this to the official mod.-instructions on the gnuradio Wiki? It would help people

[Discuss-gnuradio] Google Summer of Code: Bridging SciLab with Python (and Gnuradio?)

tions. Moeller ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Porting Gnuradio-Applications to UHD. The right moment to switch to the new USRP Firmware

I wonder if it is time now for switching to the new UHD Firmware. It is declared as "alpha", but it seems that for new code now, the UHD should be the preferred API. The problem is, what to do with the old applications? They are all made for the old API model. So, switching to UHD on the USRP side

[Discuss-gnuradio] UHD with Cygwin?

I managed to compile most of the Gnuradio for Cygwin, including the grc. Only the USRP2 driver was incompatible with Windows, because the raw-socket concepts are totally different (even in with Cygwin). Now with UHD the chances for Cygwin support are much better, right? If the UHD is using UDP dat

Re: [Discuss-gnuradio] UHD with Cygwin?

On 19.08.2010 00:45, Josh Blum wrote: >> Now with UHD the chances for Cygwin support are much better, right? >> If the UHD is using UDP datagrams, this should be realistic in Cygwin >> with standard sockets. The UHD build instructions for Windows only deal with >> the MSVC. > > I believe that cma

Re: [Discuss-gnuradio] building gnuradio on windows with msvc

Hi Josh, isn't it easier with the GNU-Toolchain like Mingw (Windows native) or Cygwin (POSIX/Windows API)? For Cygwin there are lots of prebuilt packages and others build easily with ./configure ; make. Some need to be patched. Once I managed to get gnuradio running in Cygwin (X-windows) with GRC

Re: [Discuss-gnuradio] building gnuradio on windows with msvc

On 02.01.2011 22:38, Don Ward wrote: > I use MinGW for my "production" GNU Radio system. It is a pain to gather and > build the dependencies, but it's not as hard as it looks, and once it > works it works forever. And if anyone is interested, I have a script to do > all the work (posted twice,

Re: [Discuss-gnuradio] Re: A Humble Request.... - "Open-Hardware"

On 09.01.2011 05:48, Brian Padalino wrote: >> Hello Mr. Ettus, >> Do you have any plan to reduce price for USRP1 or release PCB layout for >> poor students? > So lets figure out something that is worth while for you to do - > simulate something. Simulate anything! There is a channel simulator > b

Re: [Discuss-gnuradio] Re: A Humble Request.... - "Open-Hardware"

On 09.01.2011 18:31, J.D. Bakker wrote: >> It's not a wrong question to ask for cheaper hardware that everybody can >> afford. > It is if you're not willing to invest the time and money to make it happen. That is the commercial point of view. GNU itself is very non-commercial. It would be logical

Re: [Discuss-gnuradio] Re: A Humble Request.... - "Open-Hardware"

On 09.01.2011 22:34, Marcus D. Leech wrote: > > Sounds like you're volunteering to create such a project. Let us know when > you have everything set-up, > including initial high-level designs, and preliminary parts selections. :-) No, but some people started (SSRP), really a good starting poin

Re: [Discuss-gnuradio] Re: A Humble Request.... - "Open-Hardware"

On 10.01.2011 00:44, J.D. Bakker wrote: > The SSRP doesn't look too bad. Another option is the OpenHPSDR > (http://openhpsdr.org/); I believe people are working on GNUradio drivers. I like the idea. But this one is even more complex (more expensive?) than the USRP. I believe that it's necessary f

Re: [Discuss-gnuradio] Alternative Hardware [was: Re: A Humble Request.... - "Open-Hardware"]

On 10.01.2011 15:35, Martin Braun wrote: > If I may add a note here: I agree with Brian and Patrick, and would even > go further to say that developing fun stuff needs no hardware at all. > So, I hope this didn't sound too snobbish -- but I think that using GNU > Radio, essentially any budget is e

Re: [Discuss-gnuradio] Re: A Humble Request.... - "Open-Hardware"

On 10.01.2011 02:22, Marcus D. Leech wrote: > The SSRP, as far as I can tell, is dead. Last status update was nearly 4 > years ago. The development stopped apparently. But at least he has a working design for the RX part. > o The ADC board (single-channel, thus cannot handle direct-conversion w

Re: [Discuss-gnuradio] Re: A Humble Request....for allowing to copy Circuit into PCB

On 11.01.2011 04:24, Marten Christophe wrote: > matured that time. USRP has been sold in $450 , how one can claim > proprietorship on a product which was develop as open sourced > hardware project. many of people have contributed to it on Mr. Ettus The copyright is at Ettus. EDA-files are not d

Re: [Discuss-gnuradio] Re: A Humble Request....for allowing to copy Circuit into PCB

On 11.01.2011 12:35, Patrick Strasser wrote: >> The copyright is at Ettus. > The schematics are freely available, you can produce the PCBs for an > USRP yourself. > I'm used to respect copyrights. So, it's allowed to freely reproduce, modify and republish the USRP design? That's what I expect from

Re: [Discuss-gnuradio] "Open-Hardware"

On 12.01.2011 00:13, Patrick Strasser wrote: > > You need the decimation on the device side of the USB connection to > reduce the amount of data sent over it. The absolute limit isbetween 32 > an about 40MiByte/sec. Divided by 16bit=2byte per sample is 16-20MSPS > real-valued or 8-10MSPS complex-va

Re: [Discuss-gnuradio] GNURadio and CUDA reprised

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 sti

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 o

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 computa

[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

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

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 doin

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 cyc

Re: [Discuss-gnuradio] Re: Low cost hardware option

On 14.01.2011 22:28, Charly Lima wrote: > What about using an ASIC instead of the FPGA for the DDC, for example AD6652 > from Analog Devices, and connect that directly to the USB 3.0 Controller? > Might > be cheaper? >

Re: [Discuss-gnuradio] Low-cost hardware options

On 15.01.2011 03:10, Marcus D. Leech wrote: > I've posted my latest thoughts at: > > http://www.sbrac.org/files/digital_receiver2.pdf > > This version has some BOM cost estimates for most of the items, and > shows a new I counted $75, let's say $100 (incl. voltage conrollers, R/C), plus $50 for

Re: [Discuss-gnuradio] Building an RF Front end for DSP FPGA Kits with ADCs

On 13.01.2011 22:59, sirjanselot wrote: > The reason why I do not want to attenuate is because I want to receive a > high-powered signal and low-powered signal at the same frequency. Can you be more specific? This is an interesting topic. In most cases the signals cannot be separated any more. Y

Re: [Discuss-gnuradio] Re: Low cost hardware option

On 15.01.2011 13:45, Patrick Strasser wrote: > For flexibility, being able to bypass stages or feed signals e.g. at the > ADC would be cheap. Preparing for different transport systems would make I wonder how much noise will be introduced with a switch at the ADC. At least I would use 2 different i

Re: [Discuss-gnuradio] re: Low cost hardware option, the "total GNU solution"

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 cyc

Re: [Discuss-gnuradio] re: Low cost hardware option, the "total GNU solution"

On 15.01.2011 16:17, Marcus D. Leech wrote: >> It would be really cool to create a "total GNU" solution for the GNURADIO. >> GNU EDA tools, GNU-like Hardware (open-source community license), >> GNU FPGA-code, GNU µC-Code, GNU signal processing (the existing Gnuradio), >> GNU operating system, GNU p

Re: [Discuss-gnuradio] re: Low cost hardware option, the "total GNU solution"

On 15.01.2011 15:46, Marcus D. Leech wrote: >> It would be really cool to create a "total GNU" solution for the GNURADIO. >> GNU EDA tools, GNU-like Hardware (open-source community license), >> GNU FPGA-code, GNU µC-Code, GNU signal processing (the existing Gnuradio), >> GNU operating system, GNU p

Re: [Discuss-gnuradio] re: Low cost hardware option, the "total GNUsolution"

On 18.01.2011 12:03, Patrik Tast wrote: > Yes, very important and I like what you are designing, > you bet I will get one if I can get it as already tuned. What is "already tuned"? The design was just a RF/ADC board, without FPGA. But possibly it could be attached to a cheap FPGA development boa

Re: [Discuss-gnuradio] Building an RF Front end for DSP FPGA Kits with ADCs

On 18.01.2011 23:37, JP234 wrote: > > Moeller: Yes I am trying to solve the near-far problem. I have used the > USRP radios to test the concept, and it works really well I am getting about > 55 - 60 dB suppression which is essentially equal to the practical dynamic > range of t

Re: [Discuss-gnuradio] Yet another kick at the cheap-hardware can

On 20.01.2011 16:16, William Cox wrote: > I don't know if this is kosher, but has anyone looked at the (vast array of) > offerings from Comblocks (comblock.com )? They sell > FPGA IP cores for all of their hardware, and it seems like it might be a good > match for building a

Re: [Discuss-gnuradio] Yet another kick at the cheap-hardware can

On 20.01.2011 00:23, Marcus D. Leech wrote: > If the answer to the above is "yes", then the next question is: is > there a community of interested > volunteers to bring the project to fruition? Such an interested > community would involve: I'm interested in developing a SDR teaching platform,

Re: [Discuss-gnuradio] GNURadio is disappointing [was: Greeting and a question]

On 21.01.2011 10:19, Martin Braun wrote: > But all these open hardware threads seem to neglect that there's a > powerful *software* tool out there for real-time signal processing, and > a lot is happening at that end. GNU Radio is much more than the USRPs; > in fact, it's *not even* the USRPs. > I

Re: [Discuss-gnuradio] USRP design is free

On 22.01.2011 11:18, John Gilmore wrote: > I don't understand why people are complaining that the Ettus Research > board designs aren't free. They are free. Matt publicly announced > that he intended to release them under the GPL. Right up to this > day, the schematics (in PDF) are trivially do

Re: [Discuss-gnuradio] The 'next' branch

On 22.02.2011 04:50, Don Ward wrote: > Tom Rondeau wrote: >> I would ask all of you who can to start either using or at least >> testing out the 'next' branch now and provide us with feedback and bug >> reports. I installed the Cygwin 1.43 boost libraries, but: checking for exit in -lboost_unit_t

Re: [Discuss-gnuradio] The 'next' branch [MinGW]

On 22.02.2011 20:27, Don Ward wrote: > (2) The Boost 'filesystem' module does not build on MinGW, because wstring > is not supported in its libstdc++. I will look at the latest MinGW to see > if this has changed. One possibility is to use an alternate C++ library > (such as STLPort), but that

Re: [Discuss-gnuradio] Re: FUNCube dongle

On 22.02.2011 15:26, Patrick Strasser wrote: > I think this would be of great use. The FCB is based on the Softrock DDS > design, which evolved to a family of different solutions, with the > common factor of a stereo sound interface and a HID interface for > control like frequency, source multiplex

Re: [Discuss-gnuradio] Re: FUNCube dongle

#x27;s the nice thing about abstract interfaces. Yes, I think it's a nice abstract interface. Do you know the theoretical limits for the sample rate? Can it fill the full USB bandwidth or does it only accept "standard audio" sample rates? Moeller __

Re: [Discuss-gnuradio] Re: FUNCube dongle

On 25.02.2011 18:45, Alexandru Csete wrote: > There is still an audio codec - the difference is that it is in the Funcube > Dongle rather than in the host computer. Moreover, the IQ imbalance is not > only due to audio hardware but also due to the qudrature demodulator, so DC > offset and phase

Re: [Discuss-gnuradio] Re: FUNCube dongle

On 26.02.2011 11:36, Patrick Strasser wrote: > Just putting USB Audio Class 1 on USB 2.0 would not work, because blocks > are structured different between 1.1 and 2.0. That was my hope, but I didn't check the specs if it would be possible. > But back in 2005 USB Audio Class 2 (UAC2) was adopted,

Re: [Discuss-gnuradio] Real-only direct-conversion

On 27.02.2011 17:28, Marcus D. Leech wrote: > I was on a call the other night with someone who asserted that you > didn't need an I & Q representation > for a direct-conversion receiver, and that I and Q could be > synthesized later from a real-mode-only > baseband signal. ... > So, my feelin

Re: [Discuss-gnuradio] Real-only direct-conversion

On 28.02.2011 00:22, Marcus D. Leech wrote: > But for a zero-IF, direct-conversion, with only a single baseband output > (single mixer), I don't see how you >can make it work. A real valued zero-IF "universal" (modulation independent) receiver does not exist. I think you have the a demodulat

Re: [Discuss-gnuradio] volk build issues on Cygwin, partial success

On 05.03.2011 01:52, Don Ward wrote: > Due mainly to circumstances beyond my control, it is now possible to build > the volk library on Cygwin :-). Previously, there was no support for C99 > complex data types in the Cygwin library, but this was fixed by the release > of Cygwin 1.7.8-1 this pas

Re: [Discuss-gnuradio] Error while building wxPython, GCC4

On 07.03.2011 15:15, Don Ward wrote: > Remove any gcc/g++ versions other than the one you choose to use (only > 3.4.4-999 is currently known to work with GNU Radio). Be prepared to > rebuild any dependencies that you might have built with another compiler. The GCC 4.3.4 (GCC4 cygwin packages) als

Re: [Discuss-gnuradio] libstdc++ error on Cygwin

On 06.03.2011 20:04, Vijay Pillai wrote: > /usr/bin/grep: /usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.la: No such file > or directory When I upgraded to the GCC 4.5 compiler I had a similar issue. It was not sufficient to select the gcc-4 4.5 compiler packets, but also the libstdc++6 packets (Lib

[Discuss-gnuradio] UHD on Cygwin

Finally also the UHD builds with Cygwin, some tests pass, some fail. The build problems were caused by bugs in Boost 1.43: https://svn.boost.org/trac/boost/ticket/4816 I solved it by inserting #include on top of the include list in "usr\include\boost\asio.hpp", and with a dirty hack in "usr\inclu

Re: [Discuss-gnuradio] USRP2 Spectrum Sensing Help, (variant for FunCube Dongle?)

On 18.03.2011 18:10, devin kelly wrote: > I have two problems with my data though. In the file attached is some TV > spectrum (left half) and noise (right half). > My first question is this: why isn't the spectrum for the TV signal flat, it > seems to bob up and down. Note that each segment is

Re: [Discuss-gnuradio] 100 Msps FPGA code for USRP N210 - Gnu Spectrum analyzer

On 18.03.2011 20:09, Marc Epard wrote: > We've customized an FPGA image for the N210 that lets us grab batches of 256K > complex samples (one SRAM full) at 100 Msps with no decimation, scaling, > or downconversion. It works by filling the SRAM with samples at full rate, > then dribbling them out

Re: [Discuss-gnuradio] Use of OpenGL in gr-qtgui

On 27.03.2011 10:10, Alexandru Csete wrote: >> If they do, then are the Qt widgets equally-likely to provoke some of the >> horrible problems I've seen with the OpenGL in >> WxWidgets used in Gnu Radio? >> The OpenGL "eco-system" seems to break randomly, even for apparently-correct >> applications

Re: [Discuss-gnuradio] Latest GIT on OpenSuse 11.4 x64 - PYTHONPATH

Unfortunately, the Gnuradio "make install" Installer is a bit buggy. It distributes python libs between the lib64 and lib folders. Python cannot handle this chaos, even with both directories in PYTHONPATH. I solved it by creating a symlink before installing: ln -s /usr/local/lib64/python2.7/ /usr

Re: [Discuss-gnuradio] CYGWIN/X gnuradio

I prefer the bash command line and GCC for development, even on Windows. You have regular expressions everywhere, scripting, automation, git, rsync ... Why using Microsoft compilers for GNU programs? Unix is the dominating OS world-wide. Nearly all smartphones (iPhone,Android) and most embedded dev