[Discuss-gnuradio] Artwork
Hello! I'd like to use the logo from the wiki. I've found two images in the savannah web repository [1], but I was not able to find any vector-format source file for those. Are any source files available? Are the pictures GPLed? Patrick http://web.cvs.savannah.gnu.org/viewvc/gnuradio/images/gnuradio14.png?root=gnuradioview=log -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser patrick dot strasser at tugraz dot at Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Impulse response USRP DAC-ADC
When I changed the base-band frequency of the digital up/down-conversion from zero to 4MHz the hole disappeared. -Original Message- From: Matt Ettus [mailto:[EMAIL PROTECTED] Sent: den 24 mars 2008 20:18 To: Per Zetterberg Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Impulse response USRP DAC-ADC Per Zetterberg wrote: Hi All, I connected the DAC of the USRP directly to the ADC (basic db, 50ohm cable), 2MHz sample-rate. The impulse responses I get are: h1=[0,-2,2,-7,8,-6,314,479,-47,-161,-124,-103,-79,-63,-50,-39,-29,-23, -17,-1 4,-13,-9,-7,-5,-4,-3,-3,-2,-1,-3,-3]; h2=[0,-1,-1,0,-2,2,22,274,208,-77,-79,-71,-53,-46,-36,-28,-23,-17,-15, -12,-1 0,-7,-5,-4,-4,-3,-4,-2,-2,-2,-1,-2]; Where h1 is with set_adc_buffer_bypass and h2 without it. Does this make sense ? Yes, this looks reasonable. You are seeing a hole at DC because of the low frequency cutoff of the transformers. If you used the LFRX and LFTX instead of the BasicRX and BasicTX, you wouldn't see the hole there. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] a question about wx.App()
On Mar 25, 2008, at 1:13 AM, Bill Stevenson wrote: Oops! Could u tell me the location of _core_.py file? I just found out the _core.py file, but could not find the _core_.py. Thank you again!!! I'm glad you caught my error ... _core instead of _code ;) _core.py and _core_.so shuld be in the same directory (in your case, / usr/lib/python2.5/sitepackages/wx-2.8-gtk2-unicode/wx ). The 'so' is a shared library, created by wxPython, and is part of a SWIG interface into wxWidgets (which is a C++ compiled library and includes). On Mar 25, 2008, at 1:11 AM, Bill Stevenson wrote: Thank u for your reply!!! I have searched all of my compute, but could not find out the wxWidgets! Could u tell me what its path is? Where is it? I really want to look at the C++ code! Thank u!!! In order to access those codes, you'll need the original source tarball, extract it, and find those files. Depending on your OS-type, this can be done as part of the code install - or you might need to download the tarball (e.g., from http://www.wxwidgets.org/downloads/ ), extract it, and then start searching around in it. For example, if you're running on MacOS X and using MacPorts, you can find the original source via: sudo port -f patch wxWidgets pushd `port dir wxWidgets`/work/wxWidgets* and then search around from there (e.g. grep -inr 'wx\.App' .). I would guess on most Linux'es, you're better off just downloading the original source tarball and working with it ... just makes sure you find the correct version of wxWidgets ;) - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Signal processing block compiling problem
On Mar 24, 2008, at 10:12 PM, Jonathon Pendlum wrote: /usr/bin/ld: cannot find -lfftw3f This even occurs if I try to compile the howto example. Another member on my team has installed FFTW3, so I'm not sure why I am getting this error. Can anyone help me out? Thanks! FFTW3F is a separate install from FFTW3 on most systems. Do a search for that package name in whatever install system you're OS is using, and hopefully it'll turn up. BTW What OS / version are you working on? Always helps to know this info up front. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
From the information on the DV Dongle list the shipping firmware is the same as on the moetronix.com web site. http://www.moetronix.com/dvdongle/ Hmm. Yes it does seem they are saying everything inside the Dongle is open source. But I don't see how they can do that since as far as I know, DVSI has never provided open source for IMBE or AMBE. I'm going to guess that if you pin down Moetronix, they will tell you the open source refers to the Atmel 91SAM7S microcontroller that's in there, not the TI DSP. I would further guess that since there is a hardware 'boundary' between the Atmel and the DSP (most likely one of the McBSP simple synchronous serial ports found on many TI DSPs), they will tell you they don't face a GPL requirement to show the DVSI source. I.e. it looks like a brick and they don't know what's in it. -Jeff Hello, I guess you did not notice the Somebody Else's Problem (SEP) field generator on the board. :) It is good to know that I am not the only one that was confused. If you go through the official link (www.dvdongle.com) then you get a slick website for a commercial device marketed for PC based DStar. If I had clicked on that link first then I may have concluded that it was a DStar only device. The Experimenter's link is: http://www.moetronix.com/dvdongle/ So to clarify based on my research so far... GNURadio code would talk to the open source firmware on the DV Dongle which deals with the AMBE2000 AMBE Codec. Windows source code (yes, Source!) for the test application is available at: http://www.moetronix.com/files/ambetest103.zip The DV Dongle should work as a general AMBE/AMBE+ CODEC. It does not support AMBE+ 2. The device uses ASCP protocol over USB developed by Moetronix. The low-level communication portion of SDR-14 example code could be modified and used for communications. My first experiments will be dealing with IMBE decoding. Decoding IMBE would make this device useful for APCO Project 25 voice decoding. Hopefully this will resolve the AMBE will not decode IMBE issue. 73 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] new 802.11b receiver
Mohammad: Do you know Fehrouz Farhang-B? I am sure you must. He is an acquaintance of mine. Are you in the Wireless Communications Lab or the DSP Lab (Signal Processing Group)? I have before, and I wish to recommend again, Fehrouz book on SDR techniques to people here. http://www2.elen.utah.edu/~farhang/ Who is directing your thesis work? I want to remind you and everyone else listening, that we will soon have the USRP2. It will definitely support the 802.11b and g. It would be good to have the code early so we can make a plan on moving it to the USRP2 to support the full bandwidth. I am looking forward to visit your department at some time in the next few months. I hope to be able to meet you. Thank your for doing this work! Bob McGwier Mohammad Hamed Firooz wrote: Quoting George Nychis [EMAIL PROTECTED]: Brian Padalino wrote: On Mon, Mar 24, 2008 at 1:02 AM, Mohammad Hamed Firooz [EMAIL PROTECTED] wrote: Hi, As you may know, BBN guys have developed a receiver for 802.11b. But due to the USB limitation, they had to cut the spectrum which leads to low SNR. We have developed a new receiver by doing some operation (especially de-spreading) inside the FPGA (before sending data to USB). Therefore, our receiver use the whole spectrum to abstract the data. you can find more information and the codes in our website: http://span.ece.utah.edu/pmwiki/pmwiki.php?n=Main.80211bReceiver So, where's the Verilog for the changed FPGA build? Considering the amount of research in 802.11 networks, I'm sure it will be extremely helpful for someone in the future who might want to modify your implementation for you to host the Verilog code... just as Matt was nice enough to provide you his FPGA code for the USRP ;) Maybe make it a separate archive that you are hosting. Nonetheless, cool and thanks for sharing! I'm sure someone will poke around with this. - George Sure, I will probably post the Verilog codes by tomorrow. Right now, I am trying to make it more readable and neat. Sorry for the delay. -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] execute MATLAB code with mlab_call
Hello all, I've been working with a colleague who works mostly in MATLAB to prototype and test the work we're doing, so I've written a block that uses the MATLAB engine interface to execute MATLAB code as part of a flowgraph. It's based on the howto-write-a-block example, and can be built and used in much the same way. Please let me know if you find this block useful and if you needs other versions (for floats, etc.). If you're interested in using this block, please follow the README. Since there is a translation to the MATLAB engine and back, this block is significantly slower than a straightforward C++ block. I'd strongly recommend using it with something like gr_head or small data streams. It is located at: http://tyrfing.hls.stevens-tech.edu/gnuradio/ml-0.1.tar.gz I've left most of the licensing and doc stuff alone since I'm not sure how to best modify it. Please let me know if this is an issue. Thanks, Dev ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] execute MATLAB code with mlab_call
I used Tom Rondeau's changeset 7848 and applied it to my current updated code. Currently I am getting a runtime error from ofdm sampler saying that there are insufficient output ports. Has anyone faced a similar issue? Esp. for OFDM over air, this is a major prob. On Tue, Mar 25, 2008 at 3:28 PM, Dev Ramudit [EMAIL PROTECTED] wrote: Hello all, I've been working with a colleague who works mostly in MATLAB to prototype and test the work we're doing, so I've written a block that uses the MATLAB engine interface to execute MATLAB code as part of a flowgraph. It's based on the howto-write-a-block example, and can be built and used in much the same way. Please let me know if you find this block useful and if you needs other versions (for floats, etc.). If you're interested in using this block, please follow the README. Since there is a translation to the MATLAB engine and back, this block is significantly slower than a straightforward C++ block. I'd strongly recommend using it with something like gr_head or small data streams. It is located at: http://tyrfing.hls.stevens-tech.edu/gnuradio/ml-0.1.tar.gz I've left most of the licensing and doc stuff alone since I'm not sure how to best modify it. Please let me know if this is an issue. Thanks, Dev ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Sarang Mandke, MS in Telecommunications, University of Maryland,College Park ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] SDR08 Open Source Track
Every year the SDR Forum puts on a big conference and trade show. At SDR08, there will be an Open Source in SDR track which I am organizing. The session is open to any SDR topic so long as there is some sort of Open Source connection. I would like to invite everyone to submit abstracts. The call for papers is here: http://sdrforum.org/sdr08/papers.html The abstract deadline has passed, but if you can get an abstract in during the next week or so, you should be OK. Please contact me if you would like more info. Thanks, Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
