[Discuss-gnuradio] UHD Announcement - January 20th 2011
Hello list, The UHD work in the next branch has been merged into the master. These changes include new FPGA and firmware images, changes uhd host code, and changes to gnuradio gr-uhd. - -- FPGA and firmware images - New images are required for all USRP products except for the USRP1 classic (which has not changed). Upgrading N210 images is a new thing for USRP users. Make sure to burn both the FPGA and the firmware image before power cycling. If you get it wrong or mess up, you can always boot into the safe mode and try again. *Do not overwrite the safe mode images.* Instructions here: http://www.ettus.com/uhd_docs/manual/html/usrp2.html#load-the-images-onto-the-on-board-flash-usrp-n-series-only Most recent images available here: http://www.ettus.com/downloads/uhd_images/UHD-images-most-recent/ - -- API changes - The API compat number has been incremented from 1 to 2. The change was necessary to ensure compatibility with new features in gr-uhd. But, nothing has changed from an API perspective that would cause code out there to break. One obvious change is that the range types and gains are now all of type double. By only using type double, I could simplify the ranges types, get rid of some temple nonsense and in short, UHD will build and run under the clang compiler. A new call, get time at last pps has been added. Users may query this function to determine that their device is indeed getting the PPS signal. It also simplifies coordinating a synchronization across multiple devices when the PPS edge is unknown to the host. See http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#a79a5472fc16ab9723781c8cdae0bdf00 http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#a413014bf3aea4a8ea2d268b4a3b390e9 - -- gr-uhd features - Most of these changes involved bringing existing c++ features into python land. This includes: * device discovery and enumeration * devices addresses swigged up * types are now printable, think __str__ and __repr__ * the _t suffix on the uhd types is now optional - -- USRP2 + N series MIMO cable support - MIMO cable support has now been integrated. In short, the MIMO cable provides time and clock reference synchronization, and can optionally share a data path between devices. Basic usage notes detailed here: http://www.ettus.com/uhd_docs/manual/html/usrp2.html#using-the-mimo-cable - -- USRP1 feature emulation - The USRP1 classic lacks many of the time-based streaming features found in the newer devices. Ex: If you tell the USRP1 to stream N samples at time t, it will throw an error. Many of the missing streaming features have now been implemented in software, and as a result, most of the examples in UHD now work with USRP1. The following details the features: http://www.ettus.com/uhd_docs/manual/html/usrp1.html#missing-and-emulated-features I will throw this out there as a little challenge. With these features implemented, the OpenBTS+UHD port on USRP1 will probably run without error, but will it _work_ (as in talk to a gsm phone)? Just a curiosity... - Feedback is welcome! Thanks, -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Announcement - January 20th 2011
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/20/2011 09:05 AM, Josh Blum wrote: [...] UHD will build and run under the clang compiler. Cool stuff! Thanks Josh :-) Cheers, Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJNN/UPAAoJEOjnDXL6I0uZRqcP/1pU/Wf6XujpPRwKqu1stLz6 +9uLMnid53Vekl6nUkOFaJQaG8Rtm2+pqBqKAujhQqbp3jjRitkJ42/6Yl4y8UAc CDc8y7qLBSE/SdrnhQR5TkvROnpu6MkDvEoEYciVbvJ0n9gcpGAA+ptTL65LjoKh N9DPkY98UhJFjrf0Iocnajv8IM6TGb9+u9cpkmD2OqGh0npnJjHd3sHFE5q5fSoM jUmNDCROVj0DdfFb+rNB7QfDOuZDfbVRzM01eqYUIDxhxdpZsfIZkLkt3qaPjipS Pus6SYjFFiEQbz4qxAo+iPlfUXAqLaTY8ZRA7ag04kLYkipAIrxXmwMQSm9D4bHi +95Vd6h1Uw2Rq8PAFeqfFAi+Nwajy1z+C1zLnMgAWdAXlX7V+AOE7eJujSgLjhZG qs3lyPy4P+x297dH/f+L/ed+dKGvMCILnD3ykbI1ex5RpjrO/mxOrAZldXt1Y9VM eyItn1wyY4nQ4k3JN5CkhoSAnfEFqW/Cz5ekzuUnarmc8JfyZbrR00IN3/Kt5KOD BjM02Ll6n+oAUeN8IhoC6ub7HNrZAiFZrIODmmdB9R4UpzL3OqyWcccKDvzYwSrv f22aHBu8YwwPEgHyQKeuYCBui7Iyk+wfyLTDYGLP5FJDfuxOH6qg6t67GMyhX7vC PSdlJpDzdlaADKBP8IUB =5bvg -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mail with picture
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/19/2011 08:01 PM, Gabriel Morel wrote: Do you know how can I send a email with pictures. I just tried to send one and he was fired. Just upload it somewhere and send a link. Like this the people that want to see it can see it, while the others save time and bandwidth. Moritz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJNN/YvAAoJEOjnDXL6I0uZXuEQAIgD9JdtBt3C7mHxXOIH0gU8 q0yMtvcIGdi9fDg6SikoEKfqggbcHV+OLsMLXjSssPy+818fPj3P7dt81+1X0hjM 0rm+yzRDeMDJZgmT5ivcPz34TG3qzXVlGikpCG3UPNPAylD4OgSn/8QLKRjn2Gpn dJCK07DUJ5nNJtlC/alevRrmcG9h5vdtCpu0zHDazRb/A+SzgQGRtH1iMHc+FF12 o05Vgo+3T4G/K7b3FqNhVVUAKFtJ48+ixkM1dUb3pvu/lml8V32c+jqQEayzPhGc RZKrN363SKBUS8q5wSpnBCnne3IFLEq6Sp1bw5JIn2k71kLe4EAvLfftQ7hJb8oO ibKXC3udliMl0MkdAjXFWdxSMqHqPQasVdCesRdtKsjCSsb+LOG8hVYBd/m7JCqQ eYQaIAfK9/MWICYjhIJZk/M8NyZOXoeCT1X4njanhihJMXzuAXQT+MIuoPuHyBa2 qdFY7kZ1wEo+3+wGV8MVG15vxuqnNbdlicXTGnucMmxoGgcTryDfL5KPQskW8xUJ GFiYlSr42Nf9H06BkAfdE1I1O/xgaw2t5ZJ6dnc82wjUMGkhkjwTcINg7T+BxX9h 5AQ5POq8Ew2vHbrLq2jd4KKYLso0sddvzNSaflU5vm4moEoAALNdNj38z+sf3/yX gu2eihh7oCTSBlRs8zbn =a3Jr -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] constellation object
On Wed, Jan 19, 2011 at 11:55:30AM -0700, Ben Reynwar wrote: I'm new to all this, so I don't have a good handle on soft versus hard decision making. My understanding is that a hard decision maker simply returns the symbol value, and a soft decision maker would return probabilities for various symbols values. Then this probabilistic information would be interpreted by the decoder which would make the hard decision for sets of symbols simultaneously. I don't understand what receiver_cf is doing if it returning a stream of floats. You've got that right: a soft decider doesn't really decide, but rather gives a value how good the estimate is. Say you have a binary output, 1 and -1. A soft decider can also give any value in between. If you get a 0, then the soft decider really has no clue what was actually transmitted and instead of guessing a binary value, it relays this uncertainty. One place this is really important is the channel decoding. On a related note, I've read that the minimum euclidean distance minimizes the chance of error if you have white gaussian noise. Is this always a sensible assumption or are there practical situations in which a different measure would be better? If not, then the distance could be used as a proxy for probability. If others measures are sometimes better, then it would be nice to keep things more general. Just a couple of euro-cents I'd like to add: - White noise is a perfectly valid assumption. In most cases, your noise is WGN-ish anyway. If it isn't, then the constellation demodulator is not the right place to handle it, you'd use some kind of pre-whitening filter a priori. - I'd say if you have to implement a soft- and hard-decider for each constellation anyway, you're general enough. With the aforementioned point, this means the hard decider is sіmply always the minimum euclidean distance, as you said already. - After having a quick peek at your code, I wasn't quite sure if you've thought of differential PSKs? All that aside, I think this is a good approach. GNU Radio currently has a lot of fantastic DЅP code; what I miss is more structure, and I'm glad to hear about the plans to refactor the digital stuff. Cheers, MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgp9ZW1uRj6XX.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Yet another kick at the cheap-hardware can
Hi, I'm very intersted in this project and will help to make things happen. I can help in any part of the design, but I have more experience in FPGA developing. Euripedes 2011/1/20 Marcus D. Leech mle...@ripnet.com Hi Marcus, Who works on this project now? Nobody, really, except that I've posted a few straw man designs. Why choose USB as the interface to host. The USB interface became the bandwidth bottleneck in USRP1, so why use network interface? USB-2.0 is relatively cheap to implement, which is *one* of the project goals. Using 8-bit samples, you can achieve roughly 16Msps. Using 4-bit samples, you can do better. 4-bit samples reduces your dynamic range, but for certain high-bandwidth applications, that's OK. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org ___ 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] Yet another kick at the cheap-hardware can
On Wed, Jan 19, 2011 at 11:23 PM, Marcus D. Leech mle...@ripnet.com 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: o High-level hardware design o Detailed schematic capture and PCB layout o FPGA firmware design o Host-interface (FX2?) firmware design o Host driver software design and implementation o Small-scale financial investment for initial PCBs, components, etc I have no knowledge of radio design beyond block diagrams, but I'm very interested in this project as the sort of device every community workshop or school should be able to get hold of. I'm happy to prototype PCBs and devices locally and help on the software interfacing side. Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Unwanted signal transmitted RFX900
Hi all, Making some tests I have found that my system (USRP + RFX900) transmits an important signal (it seems a tone) without any application running, just when I plug the power source it transmits this unwanted signal. I'm working at the GSM900 downlink frequency band (between 935 and 960 MHz) and the signal appears close to the upper side of this band, around 959,6 Mhz. My system makes an spectrum sensing for that band and it locates the present signals, so it produces an error because it detects this undesired signal generated by itself. Any idea of the problem? Any solution? Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD won't work with GRC
Dear list, i somehow can't get the UHD working with GRC. Detecting an USRP2 with uhd_find_devices works just fine. I am building from git (master) (what should include the UHD since today. I'm also seeing the gr-uhd directory.) I think that the issue is with ./configure, because there i can't find gr-uhd when ./configure is finished. It prints: * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: usrp2-firmware These components will not be built. * The following GNU Radio components have been successfully configured: config gruel gnuradio-core usrp usrp2 gr-usrp gr-usrp2 gr-msdd6000 gr-audio-alsa gr-audio-oss gr-atsc gr-cvsd-vocoder gr-gpio gr-gsm-fr-vocoder gr-noaa gr-pager gr-radar-mono gr-radio-astronomy gr-trellis gr-video-sdl gr-wxgui gr-qtgui gr-sounder gr-utils gnuradio-examples grc docs You my now run the make command to build these components. * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gr-gcell gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows gr-comedi These components will not be built. Configured GNU Radio release v3.3.1git-144-gf294603d for build. But gr-uhd is neither in the components that will be build, nor in those, that won't be build. I also tried ./configure --enable-gr-uhd but that didn't change a thing :-( If you got any ideas on how to proceed, please let me know. Fabian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD won't work with GRC
On Thu, Jan 20, 2011 at 2:51 PM, Fabian Klaes fabian.kl...@gmail.com wrote: Dear list, i somehow can't get the UHD working with GRC. Detecting an USRP2 with uhd_find_devices works just fine. I am building from git (master) (what should include the UHD since today. I'm also seeing the gr-uhd directory.) The merging of next - master was announced for UHD, not for GNU Radio. You need: UHD master branch GNU Radio next branch see http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki I think that the issue is with ./configure, because there i can't find gr-uhd when ./configure is finished. It prints: * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: usrp2-firmware These components will not be built. * The following GNU Radio components have been successfully configured: config gruel gnuradio-core usrp usrp2 gr-usrp gr-usrp2 gr-msdd6000 gr-audio-alsa gr-audio-oss gr-atsc gr-cvsd-vocoder gr-gpio gr-gsm-fr-vocoder gr-noaa gr-pager gr-radar-mono gr-radio-astronomy gr-trellis gr-video-sdl gr-wxgui gr-qtgui gr-sounder gr-utils gnuradio-examples grc docs You my now run the make command to build these components. * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gr-gcell gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows gr-comedi These components will not be built. Configured GNU Radio release v3.3.1git-144-gf294603d for build. This number is for the master branch. The correct revision id for the next branch is (was earlier today) v3.3.1git-865-gd429522 But gr-uhd is neither in the components that will be build, nor in those, that won't be build. I also tried ./configure --enable-gr-uhd but that didn't change a thing :-( If you got any ideas on how to proceed, please let me know. Aside from using the correct GNU Radio branch (next) you also need to install UHD first, otherwise the GNU Radio configure script will not detect it and will skip it. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Yet another kick at the cheap-hardware can
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 basic I/Q acquisition system. Here's a full product list: http://comblock.com/product_list.html http://comblock.com/product_list.htmlThe block diagram at the bottom of this page gives an idea of how things could work: http://comblock.com/com8002.html http://comblock.com/com8002.html-William On Thu, Jan 20, 2011 at 6:05 AM, Mark Steward markstew...@gmail.com wrote: On Wed, Jan 19, 2011 at 11:23 PM, Marcus D. Leech mle...@ripnet.com 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: o High-level hardware design o Detailed schematic capture and PCB layout o FPGA firmware design o Host-interface (FX2?) firmware design o Host driver software design and implementation o Small-scale financial investment for initial PCBs, components, etc I have no knowledge of radio design beyond block diagrams, but I'm very interested in this project as the sort of device every community workshop or school should be able to get hold of. I'm happy to prototype PCBs and devices locally and help on the software interfacing side. Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD won't work with GRC
First of all, thank you for your advice. Now i encountered another Problem: At first i updated UHD via git pull, then i did (from the build directory) cmake ../ make make test sudo make install everything works fine (well, not everything, but at least the installation ;-) ). Then i went to my gnuradio directory and did: git checkout next git clean -xf git pull # GNU Radio release is now v3.3.1git-865-gd429522b instead of v3.3.1git-865-gd429522, but this should be newer export LD_LIBRARY_PATH=$BOOST_PREFIX/lib ./bootstrap ./configure --with-boost=$BOOST_PREFIX # ./configure now includes gr-uhd, so this problem is solved. Thanks again! make Then, make fails with: Making install in swig make[5]: Betrete Verzeichnis '/home/fs/gnuradio-git/gnuradio/usrp/host/swig' make install-am make[6]: Betrete Verzeichnis '/home/fs/gnuradio-git/gnuradio/usrp/host/swig' make[6]: *** Keine Regel vorhanden, um das Target »usrp_prims.cc«, benötigt von »_usrp_prims_la-usrp_prims.lo«, zu erstellen. Schluss. make[6]: Verlasse Verzeichnis '/home/fs/gnuradio-git/gnuradio/usrp/host/swig' make[5]: *** [install] Fehler 2 make[5]: Verlasse Verzeichnis '/home/fs/gnuradio-git/gnuradio/usrp/host/swig' make[4]: *** [install-recursive] Fehler 1 make[4]: Verlasse Verzeichnis '/home/fs/gnuradio-git/gnuradio/usrp/host' make[3]: *** [install-recursive] Fehler 1 make[3]: Verlasse Verzeichnis '/home/fs/gnuradio-git/gnuradio/usrp' make[2]: *** [install] Fehler 2 make[2]: Verlasse Verzeichnis '/home/fs/gnuradio-git/gnuradio/usrp' make[1]: *** [install-recursive] Fehler 1 make[1]: Verlasse Verzeichnis '/home/fs/gnuradio-git/gnuradio' make: *** [install] Fehler 2 Sorry, that it's in german, heres the translation: Betrete Verzeichnis = Entering directory Verlasse Verzeichnis = Leaving directory Fehler = Error And the (probably) critical part causing the error: make[6]: *** Keine Regel vorhanden, um das Target »usrp_prims.cc«, benötigt von »_usrp_prims_la-usrp_prims.lo«, zu erstellen. Schluss. make[6]: *** No Rule given, for making Target »usrp_prims.cc«, needed by »_usrp_prims_la-usrp_prims.lo«. Ending. If you (or anyone else) got another hint on how to solve this i would be really glad. Thanks again and in advance Fabian On Thu, Jan 20, 2011 at 3:11 PM, Alexandru Csete oz9...@gmail.com wrote: On Thu, Jan 20, 2011 at 2:51 PM, Fabian Klaes fabian.kl...@gmail.com wrote: Dear list, i somehow can't get the UHD working with GRC. Detecting an USRP2 with uhd_find_devices works just fine. I am building from git (master) (what should include the UHD since today. I'm also seeing the gr-uhd directory.) The merging of next - master was announced for UHD, not for GNU Radio. You need: UHD master branch GNU Radio next branch see http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki I think that the issue is with ./configure, because there i can't find gr-uhd when ./configure is finished. It prints: * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: usrp2-firmware These components will not be built. * The following GNU Radio components have been successfully configured: config gruel gnuradio-core usrp usrp2 gr-usrp gr-usrp2 gr-msdd6000 gr-audio-alsa gr-audio-oss gr-atsc gr-cvsd-vocoder gr-gpio gr-gsm-fr-vocoder gr-noaa gr-pager gr-radar-mono gr-radio-astronomy gr-trellis gr-video-sdl gr-wxgui gr-qtgui gr-sounder gr-utils gnuradio-examples grc docs You my now run the make command to build these components. * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gr-gcell gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows gr-comedi These components will not be built. Configured GNU Radio release v3.3.1git-144-gf294603d for build. This number is for the master branch. The correct revision id for the next branch is (was earlier today) v3.3.1git-865-gd429522 But gr-uhd is neither in the components that will be build, nor in those, that won't be build. I also tried ./configure --enable-gr-uhd but that didn't change a thing :-( If you got any ideas on how to proceed, please let me know. Aside from using the correct GNU Radio branch (next) you also need to install UHD first, otherwise the GNU Radio configure script will not detect it and will skip it. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Yet another kick at the cheap-hardware can
Well, may be an option for someone , but we are trying to get a cheaper, and open-source, hardware and I hope we can do this. Euripedes 2011/1/20 William Cox wc...@ncsu.edu 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 basic I/Q acquisition system. Here's a full product list: http://comblock.com/product_list.html http://comblock.com/product_list.htmlThe block diagram at the bottom of this page gives an idea of how things could work: http://comblock.com/com8002.html http://comblock.com/com8002.html-William On Thu, Jan 20, 2011 at 6:05 AM, Mark Steward markstew...@gmail.comwrote: On Wed, Jan 19, 2011 at 11:23 PM, Marcus D. Leech mle...@ripnet.com 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: o High-level hardware design o Detailed schematic capture and PCB layout o FPGA firmware design o Host-interface (FX2?) firmware design o Host driver software design and implementation o Small-scale financial investment for initial PCBs, components, etc I have no knowledge of radio design beyond block diagrams, but I'm very interested in this project as the sort of device every community workshop or school should be able to get hold of. I'm happy to prototype PCBs and devices locally and help on the software interfacing side. Mark ___ 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] Greeting and a question
Hi all, Am disappointed with the way GNURadio is getting into. I see all the discussion around is to promote the products of Ettus Research. Agreed!. Great work from Ettus Research. But there are many boards available which are far better in capability vs price. I don't want to mention them here to deviate the concern. During the market for USRP1, no one in the forum focused discussion on embedded platform. When queries regarding any such embedded platform was posted, there were lot of quotes saying GNURadio is focused on developing SDR framework based on Desktop based solution. With Ettus Research coming out with USRP E100, everyone on is bouncing on embedded platform. I wonder; Is GNURadio biased with Ettus Reserch ?. My obvious understanding is NO!. Its the community of people driving Ettus products into market. The potential of doing so is to make money. Either way, Ettus Research is now part of National Instruments and may be now GNURadio be delinked with Ettus Research for being open source. There are many people who can contribute low cost open source solutions. Initially, all the Hardware and software was part of GNURadio. All the files was part of free source available to download and use. In around a year or so all the files from GNURadio were moved out separating hardware and software. All the hardware related files were not available after this. Why so, no one knows. The boards when purchased from Ettus Research it was under terms and conditions as free open source schematics for motherboard and free open source schematics and pcb files. Its time now for the community of people interested in building free open source platform including both software and Hardware to come out with an complete open source low cost solution. S--- On Wed, Jan 19, 2011 at 3:05 PM, Farhad Abdolian f.abdol...@yahoo.comwrote: HI Tom, I am afraid not, first of all OMAP is under export restriction from the US government that means it can not be sold (or should not be sold) without US export control. Second, this board is a nice toy, but I can not justify $1300 for the functionality that E100 gives. Best regards, Farhad -- *From:* Tom Rondeau trondeau1...@gmail.com *To:* Farhad Abdolian f.abdol...@yahoo.com *Cc:* discuss-gnuradio@gnu.org *Sent:* Mon, January 17, 2011 6:27:40 PM *Subject:* Re: [Discuss-gnuradio] Greeting and a question That sounds like a reasonable approach. When you're ready, you should probably look at the Ettus USRP-E100, which uses an ARM-based OMAP processor. That seems like it's pretty much the form-factor you are looking for. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD won't work with GRC
And the (probably) critical part causing the error: make[6]: *** Keine Regel vorhanden, um das Target »usrp_prims.cc«, benötigt von »_usrp_prims_la-usrp_prims.lo«, zu erstellen. Schluss. make[6]: *** No Rule given, for making Target »usrp_prims.cc«, needed by »_usrp_prims_la-usrp_prims.lo«. Ending. If you (or anyone else) got another hint on how to solve this i would be really glad. Sometimes autotools gets confused when there are many changes to the build system. Try make distclean, and if not working: git clean -dfx (wipes everything). and rebuild from scratch. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] filename using time-stamp in GRC
If you created a custom block in python that would do the right thing as far as writing the file and handling the data; then you could use the variable chooser (button) or variable text box (string input) to generate the event. -Josh On 01/19/2011 10:47 AM, emat...@yahoo.com wrote: He all- is there a way to implement a button controlling a record-to-file function where the filename is generated instantly from the current time stamp? I can do this manually in python as follows (taken from a previously existing gnuradio code): # # Recording file, in case we ever need to record baseband data # self.recording = gr.file_sink(gr.sizeof_float, /dev/null) self.recording_state = False # Filename prefix for recording file self.prefix = options.prefix # We come up with recording turned off, but the user may # request recording later on self.recording.close() . . . self.connect (self.source, self.recording) . . . # Data recording control buttonbox = wx.BoxSizer(wx.HORIZONTAL) self.record_control = form.button_with_callback(self.panel, label=Recording Data: Off , callback=self.toggle_recording) buttonbox.Add(self.record_control, 0, wx.CENTER) . . . # # Turn recording on/off # Called-back by Recording button # def toggle_recording(self): # Pick up localtime, for generating filenames timestamp = time.localtime() # Generate filenames for both data and header file filename = %04d_%02d_%02d_%02d:%02d:%02d.dat % (timestamp.tm_year, timestamp.tm_mon, timestamp.tm_mday, timestamp.tm_hour, timestamp.tm_min,timestamp.tm_sec) # Current recording? Flip state if (self.recording_state == True): self.recording_state = False self.record_control.SetLabel(Recording Data: Off ) self.recording.close() # Not recording? else: self.recording_state = True self.record_control.SetLabel(Recording Data to: +filename) # Cause gr_file_sink object to accept new filename # note use of self.prefix--filename prefix from # command line (defaults to ./) # self.recording.open (self.prefix+filename) Thanks! eric ___ 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] WBX - only real signal after some time
Hello. I just wondered if anyone else has experienced that the WBX stops sending the quadrature component of the complex signal after a while. This happens especially if I have sliders for setting the frequencies or the gain, and the sliders are slided. (so that a frequency change control signal is sent several times successively) In an FFT-sink, this is observed as a display mirrored around the base frequency. I have not found any other solution to fix this than to restart the whole program every time it happens. This has never happened when using the TVRX board. I wonder if this is normal for these daughterboards, and that one just has to ensure that they do not get a lot of frequency setting control messages successively, or if there is a workaround. Ruben (using USRP1) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] filename using time-stamp in GRC
--- On Wed, 1/19/11, emat...@yahoo.com emat...@yahoo.com wrote: From: emat...@yahoo.com emat...@yahoo.com Subject: [Discuss-gnuradio] filename using time-stamp in GRC To: discuss-gnuradio@gnu.org Date: Wednesday, January 19, 2011, 12:47 PM He all- is there a way to implement a button controlling a record-to-file function where the filename is generated instantly from the current time stamp? I can do this manually in python as follows (taken from a previously existing gnuradio code): # # Recording file, in case we ever need to record baseband data # self.recording = gr.file_sink(gr.sizeof_float, /dev/null) self.recording_state = False # Filename prefix for recording file self.prefix = options.prefix # We come up with recording turned off, but the user may # request recording later on self.recording.close() . . . self.connect (self.source, self.recording) . . . # Data recording control buttonbox = wx.BoxSizer(wx.HORIZONTAL) self.record_control = form.button_with_callback(self.panel, label=Recording Data: Off , callback=self.toggle_recording) buttonbox.Add(self.record_control, 0, wx.CENTER) . . . # # Turn recording on/off # Called-back by Recording button # def toggle_recording(self): # Pick up localtime, for generating filenames timestamp = time.localtime() # Generate filenames for both data and header file filename = %04d_%02d_%02d_%02d:%02d:%02d.dat % (timestamp.tm_year, timestamp.tm_mon, timestamp.tm_mday, timestamp.tm_hour, timestamp.tm_min,timestamp.tm_sec) # Current recording? Flip state if (self.recording_state == True): self.recording_state = False self.record_control.SetLabel(Recording Data: Off ) self.recording.close() # Not recording? else: self.recording_state = True self.record_control.SetLabel(Recording Data to: +filename) # Cause gr_file_sink object to accept new filename # note use of self.prefix--filename prefix from # command line (defaults to ./) # self.recording.open (self.prefix+filename) Thanks! eric Following up on this, I found this site that had some useful suggestions:http://www.oz9aec.net/index.php/gnu-radio/grc-examples A grc example is provided that implements a dynamic time stamp, but NOT a button to control it. So I am trying to use a Variable Chooser to select between /dev/null and the filename that is based on the time-stamp. However, nothing is generated. In particular, I have: A file sink with File: recfile A Variable with ID prefix with Value ./ A Variable Chooser with ID: recfile, Default Value: /dev/null and Choices of /dev/null or prefix + datetime.now().strftime(%Y.%m.%d.%H.%M.%S) + .bin I was hoping this would dynamically create a file with the current time stamp for the name, but no files are actually being generated. Could this be and issue related to a bug that is described in the link below? http://lists.gnu.org/archive/html/discuss-gnuradio/2011-01/msg00080.html If so, will this approach work if I upgrade via git? Thanks! eric ___ 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] Yet another kick at the cheap-hardware can
I don't know if this is kosher, but has anyone looked at the (vast array of) offerings from Comblocks (comblock.com http://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 basic I/Q acquisition system. Here's a full product list: http://comblock.com/product_list.html http://comblock.com/product_list.htmlThe block diagram at the bottom of this page gives an idea of how things could work: http://comblock.com/com8002.html http://comblock.com/com8002.html-William The hardware looks somewhat pricey--roughly $1000.00 for a receiver+sampler+network stack. But since this is supposed to be an open-source project, I don't think licensing FPGA IP is the correct direction, either. -- 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] WBX - only real signal after some time
On 01/20/2011 11:40 AM, Ruben Undheim wrote: Hello. I just wondered if anyone else has experienced that the WBX stops sending the quadrature component of the complex signal after a while. This happens especially if I have sliders for setting the frequencies or the gain, and the sliders are slided. (so that a frequency change control signal is sent several times successively) In an FFT-sink, this is observed as a display mirrored around the base frequency. I have not found any other solution to fix this than to restart the whole program every time it happens. This has never happened when using the TVRX board. The TVRX isn't actually a quadrature front-end, so quadrature is synthesized within the FPGA. I wonder if this is normal for these daughterboards, and that one just has to ensure that they do not get a lot of frequency setting control messages successively, or if there is a workaround. I don't think it's normal. Something definitely wonky. Are you using UHD, or traditional ?? There was something *similar* in UHD a couple of months back, but it was for USRP2, so I don't think that's it. -- 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] filename using time-stamp in GRC
On Thu, Jan 20, 2011 at 5:41 PM, emat...@yahoo.com wrote: ... Following up on this, I found this site that had some useful suggestions:http://www.oz9aec.net/index.php/gnu-radio/grc-examples A grc example is provided that implements a dynamic time stamp, but NOT a button to control it. So I am trying to use a Variable Chooser to select between /dev/null and the filename that is based on the time-stamp. However, nothing is generated. In particular, I have: A file sink with File: recfile A Variable with ID prefix with Value ./ A Variable Chooser with ID: recfile, Default Value: /dev/null and Choices of /dev/null or prefix + datetime.now().strftime(%Y.%m.%d.%H.%M.%S) + .bin I was hoping this would dynamically create a file with the current time stamp for the name, but no files are actually being generated. Could this be and issue related to a bug that is described in the link below? http://lists.gnu.org/archive/html/discuss-gnuradio/2011-01/msg00080.html If so, will this approach work if I upgrade via git? Hi Eric, The problem with this simple example is that the variable containing prefix + datetime.now().strftime(%Y.%m.%d.%H.%M.%S) + .bin is evaluated when you start the script, so it will only work for a single file per execution. I believe it is for the same reason that you see no file with your modification: The file sink is initialized with /dev/null as filename and it can not change the file name during runtime because the required code for close file, set new file name, open new file is not generated by GRC - I am not exactly sure about this but it should be obvious if you look in the generated code. I would try to do as Josh said in the other mail, implement the required code yourself and embed it as a custom block. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unwanted signal transmitted RFX900
On Thu, 2011-01-20 at 12:48 +0100, Paco Quiñoy wrote: Hi all, Making some tests I have found that my system (USRP + RFX900) transmits an important signal (it seems a tone) without any application running, just when I plug the power source it transmits this unwanted signal. I'm working at the GSM900 downlink frequency band (between 935 and 960 MHz) and the signal appears close to the upper side of this band, around 959,6 Mhz. My system makes an spectrum sensing for that band and it locates the present signals, so it produces an error because it detects this undesired signal generated by itself. Any idea of the problem? Any solution? Paco, This is likely to be the 15th harmonic of the USRP's 64MHz sample clock (64e6*15=960e6). It may get better after the USRP is initialized (run uhd_usrp_probe or any other application after power-up). The AD9862 tends to come up in a weird state. --n Thanks! ___ 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 is disappointing [was: Greeting and a question]
I changed the subject to better match the tone of the email. On Thu, Jan 20, 2011 at 11:12 AM, Sanjay Singh sanjaysinghshyam...@gmail.com wrote: Hi all, Am disappointed with the way GNURadio is getting into. I see all the discussion around is to promote the products of Ettus Research. Agreed!. Great work from Ettus Research. But there are many boards available which are far better in capability vs price. I don't want to mention them here to deviate the concern. During the market for USRP1, no one in the forum focused discussion on embedded platform. When queries regarding any such embedded platform was posted, there were lot of quotes saying GNURadio is focused on developing SDR framework based on Desktop based solution. With Ettus Research coming out with USRP E100, everyone on is bouncing on embedded platform. I wonder; Is GNURadio biased with Ettus Reserch ?. My obvious understanding is NO!. Its the community of people driving Ettus products into market. The potential of doing so is to make money. Either way, Ettus Research is now part of National Instruments and may be now GNURadio be delinked with Ettus Research for being open source. There are many people who can contribute low cost open source solutions. Initially, all the Hardware and software was part of GNURadio. All the files was part of free source available to download and use. In around a year or so all the files from GNURadio were moved out separating hardware and software. All the hardware related files were not available after this. Why so, no one knows. The boards when purchased from Ettus Research it was under terms and conditions as free open source schematics for motherboard and free open source schematics and pcb files. Its time now for the community of people interested in building free open source platform including both software and Hardware to come out with an complete open source low cost solution. S--- I need to borrow your soapbox. This e-mail infuriates me. If you thought you bought a motherboard from Ettus under the terms that you were getting schematics and PCB files and blah blah blah, fine. If you didn't get them, point to the line item on the receipt or the clause in the contract and take it up with Ettus. Next - the general tone of GNU Radio seems to be biased towards Ettus only due to the fact that he, Josh and a whole slew of other people worked damned hard to not only develop their hardware, but make sure it was compatible with GNU Radio. Let me repeat that. Matt, Josh, and the rest of the people at Ettus Research did damn near ALL the legwork - software and hardware - to make it compatible with GNU Radio so you can buy something, plug it in and make it work. Moreover, they field support questions on an open forum for free. To dismiss this fact is grossly inappropriate. On that note, I have put together a simple list of things for people to do if they feel they want to get out of this Ettus Research totalitarian dictatorship that is GNU Radio: 1) Create your own RF front end boards 2) Create your own digital/baseband board 3) Write all the software for board in step (2) to control all the boards you create in step (1) 4) Write all the host side software to interface software written in step (3) with GNU Radio 5) Contribute all previous work to GNU Radio 6) Stop complaining* *NOTE: Steps 1-5 are optional. I am a massive proponent of making some 100% fully open SDR hardware that serves the low cost/cheap and easily-modifiable-for-my-specific-purpose market. Like I said in my original e-mail, stop asking and stop the rhetoric. If you want to dethrone Ettus from the monopoly he has on the GNU Radio hardware scene, you just need to do something. GNU Radio is open source. Make your board and contribute your patches. In other words, do some work if you don't like the current state of things. This community is driven by the people on this list. If you don't like something about it, you need to have the drive to change it. Demonizing Ettus Research is childish. If anything, look at their past and draw inspiration from it. I look forward to seeing your patches in GNU Radio. Thanks for the soapbox. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] filename using time-stamp in GRC
--- On Thu, 1/20/11, Alexandru Csete oz9...@gmail.com wrote: From: Alexandru Csete oz9...@gmail.com Subject: Re: [Discuss-gnuradio] filename using time-stamp in GRC To: discuss-gnuradio@gnu.org Date: Thursday, January 20, 2011, 11:41 AM On Thu, Jan 20, 2011 at 5:41 PM, emat...@yahoo.com wrote: ... Following up on this, I found this site that had some useful suggestions:http://www.oz9aec.net/index.php/gnu-radio/grc-examples A grc example is provided that implements a dynamic time stamp, but NOT a button to control it. So I am trying to use a Variable Chooser to select between /dev/null and the filename that is based on the time-stamp. However, nothing is generated. In particular, I have: A file sink with File: recfile A Variable with ID prefix with Value ./ A Variable Chooser with ID: recfile, Default Value: /dev/null and Choices of /dev/null or prefix + datetime.now().strftime(%Y.%m.%d.%H.%M.%S) + .bin I was hoping this would dynamically create a file with the current time stamp for the name, but no files are actually being generated. Could this be and issue related to a bug that is described in the link below? http://lists.gnu.org/archive/html/discuss-gnuradio/2011-01/msg00080.html If so, will this approach work if I upgrade via git? Hi Eric, The problem with this simple example is that the variable containing prefix + datetime.now().strftime(%Y.%m.%d.%H.%M.%S) + .bin is evaluated when you start the script, so it will only work for a single file per execution. I believe it is for the same reason that you see no file with your modification: The file sink is initialized with /dev/null as filename and it can not change the file name during runtime because the required code for close file, set new file name, open new file is not generated by GRC - I am not exactly sure about this but it should be obvious if you look in the generated code. I would try to do as Josh said in the other mail, implement the required code yourself and embed it as a custom block. Alex Thank you all. Eric ___ 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 is disappointing [was: Greeting and a question]
Hi all, To be specific to concern 1) Create your own RF front end boards putting mixer and LO is a handy breadboard work.. tryout some good examples from Analog Devices and TI. To get additional gains put LNA or PA in series. Learn basic hardware designs. 2) Create your own digital/baseband board Check out many thesis work who have developed demonstrating platforms. Adding to commercial front, check SP601/605 from Avnet. Check for the prices for sure!. Also check Spartan 3A 1800 DSP from Xilinx. 3) Write all the software for board in step (2) to control all the boards you create in step (1) Not required. All the development boards are platform specific and the board developer supports BSP(Board support package). If you are building your board, you need to develop your own BSP. All the development board comes with BSP. A mere DMA transfers between PC and board is a 4 weeks of development activity. 4) Write all the host side software to interface software written in step (3) with GNU Radio Platform independent drivers already address the issue. 5) Contribute all previous work to GNU Radio No one says its personal development after posting at open source community developers 6) Stop complaining* No one complains unless there is deviation against addressed. The capability and contribution you are talking about cannot be patchy work. Patchy work is needed to fix design bugs. Open source community would be interested to have proper solution rather patches. S-- On Fri, Jan 21, 2011 at 12:12 AM, Brian Padalino bpadal...@gmail.comwrote: I changed the subject to better match the tone of the email. On Thu, Jan 20, 2011 at 11:12 AM, Sanjay Singh sanjaysinghshyam...@gmail.com wrote: Hi all, Am disappointed with the way GNURadio is getting into. I see all the discussion around is to promote the products of Ettus Research. Agreed!. Great work from Ettus Research. But there are many boards available which are far better in capability vs price. I don't want to mention them here to deviate the concern. During the market for USRP1, no one in the forum focused discussion on embedded platform. When queries regarding any such embedded platform was posted, there were lot of quotes saying GNURadio is focused on developing SDR framework based on Desktop based solution. With Ettus Research coming out with USRP E100, everyone on is bouncing on embedded platform. I wonder; Is GNURadio biased with Ettus Reserch ?. My obvious understanding is NO!. Its the community of people driving Ettus products into market. The potential of doing so is to make money. Either way, Ettus Research is now part of National Instruments and may be now GNURadio be delinked with Ettus Research for being open source. There are many people who can contribute low cost open source solutions. Initially, all the Hardware and software was part of GNURadio. All the files was part of free source available to download and use. In around a year or so all the files from GNURadio were moved out separating hardware and software. All the hardware related files were not available after this. Why so, no one knows. The boards when purchased from Ettus Research it was under terms and conditions as free open source schematics for motherboard and free open source schematics and pcb files. Its time now for the community of people interested in building free open source platform including both software and Hardware to come out with an complete open source low cost solution. S--- I need to borrow your soapbox. This e-mail infuriates me. If you thought you bought a motherboard from Ettus under the terms that you were getting schematics and PCB files and blah blah blah, fine. If you didn't get them, point to the line item on the receipt or the clause in the contract and take it up with Ettus. Next - the general tone of GNU Radio seems to be biased towards Ettus only due to the fact that he, Josh and a whole slew of other people worked damned hard to not only develop their hardware, but make sure it was compatible with GNU Radio. Let me repeat that. Matt, Josh, and the rest of the people at Ettus Research did damn near ALL the legwork - software and hardware - to make it compatible with GNU Radio so you can buy something, plug it in and make it work. Moreover, they field support questions on an open forum for free. To dismiss this fact is grossly inappropriate. On that note, I have put together a simple list of things for people to do if they feel they want to get out of this Ettus Research totalitarian dictatorship that is GNU Radio: 1) Create your own RF front end boards 2) Create your own digital/baseband board 3) Write all the software for board in step (2) to control all the boards you create in step (1) 4) Write all the host side software to interface software written in step (3) with GNU Radio 5)
Re: [Discuss-gnuradio] E100 Suitability for Space Applications
On 01/19/2011 07:56 AM, Ed Criscuolo wrote: Matt, I'm considering the E100 for use with GnuRadio/UHD aboard a small spacecraft, and I have a few of questions: We definitely did not design with space applications in mind. 1. What's the power drain? Watt-hours are always at a premium aboard a small spacecraft. The E100 itself draws about 6-9 Watts. The daughterboard will also draw power, up to as much as an additional 6 or 7 watts depending on the board. 2. Are there any vacuum-sensitive components? For example, electrolytic capacitors are no good (they dry out or rupture) but tantalum's are ok. No electrolytics on there. There are 4 crystal oscillators which may or may not have vacuum issues. 3. Is cooling an issue? Air-cooled heatsinks don't work in vacuum, and have to be replaced with conduction cooling. We have done no testing of cooling in a vacuum, so you are really on your own here. 4. Any Lithium batteries? They are considered hazardous for space and require special provisions or removal. There is a coin cell battery backup for the real time clock, but that can be removed. 5. Without writing any FPGA or DSP code, what's the ballpark sample rate that the ARM can keep up with? It largely depends on what you want to do with those samples, but you should figure on 4-5 MS/s. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WBX - only real signal after some time
Thanks I am using the traditional driver. Maybe I can try to use another computer or to put the board in the other slot, and see if the problem remains the same. Ruben 2011/1/20 Marcus D. Leech mle...@ripnet.com On 01/20/2011 11:40 AM, Ruben Undheim wrote: Hello. I just wondered if anyone else has experienced that the WBX stops sending the quadrature component of the complex signal after a while. This happens especially if I have sliders for setting the frequencies or the gain, and the sliders are slided. (so that a frequency change control signal is sent several times successively) In an FFT-sink, this is observed as a display mirrored around the base frequency. I have not found any other solution to fix this than to restart the whole program every time it happens. This has never happened when using the TVRX board. The TVRX isn't actually a quadrature front-end, so quadrature is synthesized within the FPGA. I wonder if this is normal for these daughterboards, and that one just has to ensure that they do not get a lot of frequency setting control messages successively, or if there is a workaround. I don't think it's normal. Something definitely wonky. Are you using UHD, or traditional ?? There was something *similar* in UHD a couple of months back, but it was for USRP2, so I don't think that's it. -- 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio is disappointing [was: Greeting and a question]
On 01/20/2011 02:10 PM, Sanjay Singh wrote: Hi all, To be specific to concern 2) Create your own digital/baseband board Check out many thesis work who have developed demonstrating platforms. Adding to commercial front, check SP601/605 from Avnet. Check for the prices for sure!. Also check Spartan 3A 1800 DSP from Xilinx. 3) Write all the software for board in step (2) to control all the boards you create in step (1) Not required. All the development boards are platform specific and the board developer supports BSP(Board support package). If you are building your board, you need to develop your own BSP. All the development board comes with BSP. A mere DMA transfers between PC and board is a 4 weeks of development activity. So, respectfully, you're full of crap, Sanjay. No BSP is going to automatically know how to do all the functions we want to do: o Interface with whatever RF hardware is developed above o Do the required DDC and CIC Decimation, and whatever else *this specific application requires*. o Send data over the host-interface, *in the required formats, using the required protocols* There's no magic FPGA Fairy that somehow intuits exactly what you want your *application* to do, and do it for you, whether you use an off-the-shelf FPGA card, or roll your own. Certainly, a BSP can *help* with basic functionality, and provide libraries to make it easier to integrate your application, whatever that application may be, but the BSP doesn't construct that application all by itself. Some work, quite significant, is required to *construct* your own application. 4) Write all the host side software to interface software written in step (3) with GNU Radio Platform independent drivers already address the issue. Right. Because Xilinx/Altera/Digilent/whoever has already written drivers to interface to Gnu Radio, but they're selfishly withholding that information from public view? How churlish of them. 5) Contribute all previous work to GNU Radio No one says its personal development after posting at open source community developers 6) Stop complaining* No one complains unless there is deviation against addressed. I have no idea what you're talking about. -- 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] About clock rate of USRP E100
Thanks a lot for your help. Could you explain how to slow down the FPGA/ADC rate? How should we modify the firmware? Which part of the code should we look into? Thanks! This is a host code modification. see the clock_ctrl.cpp in host/lib/usrp/usrp_e100/ http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/host/lib/usrp/usrp_e100/clock_ctrl.cpp You will want to manipulate codec clock. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] NanoSail-D turns out isn't lost!
If you're in a position to listen for the beacon packets of NanoSail-D, some of the details are here: http://nanosaild.engr.scu.edu/dashboard.htm Wish my SBRAC dish was fully operational. I'd actually be able to *track* it--I've got 400MHz feeds, and a WBX-based receive chain. So much coolness, so little time :-( -- 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] NanoSail-D turns out isn't lost!
On Fri, Jan 21, 2011 at 2:03 AM, Marcus D. Leech mle...@ripnet.com wrote: If you're in a position to listen for the beacon packets of NanoSail-D, some of the details are here: http://nanosaild.engr.scu.edu/dashboard.htm Wish my SBRAC dish was fully operational. I'd actually be able to *track* it--I've got 400MHz feeds, and a WBX-based receive chain. So much coolness, so little time :-( I tried earlier today with a handheld Arrow II yagi connected directly to WBX. I could hear it but it was too weak to decode. A bigger yagi should give sufficient signal. In case you receive, it is very easy to decode the telemetry. It uses 1200 bps AFSK FM modulating the carrier, so a simple NBFM receiver and the audio fed to e.g. multimon (http://www.baycom.org/~tom/ham/linux/multimon.html) works. Decoded telemetry can be submitted to the ops team at http://beacon.engr.scu.edu/Submission.aspx Have fun! Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] hi all, can I use one RX receive a wideband signal and then seperate it to many narrowband signals
Hi Tom, This is very old topic. I have read a DSP book. But I find that I still not very understand channelizer. Why in channelizer use low pass filter, in my imagine channelizer will use band pass filter to filter each channel like that: 600Mhz baseband signal have 4 channel each channel have 100Khz bandwidth. so the channel freq is: 599.8Mhz 599.9Mhz 600Mhz 600.1Mhz. So I need 4 bandpass filter to filter each channel but actually the channelizer use lowpass filter, so why? Thanks! On Thu, Dec 23, 2010 at 10:16 PM, Tom Rondeau trondeau1...@gmail.comwrote: On Thu, Dec 23, 2010 at 3:53 AM, James Jordan james.jordan@gmail.com wrote: Thanks Tom. if I really don't know how pfb_channelizer_ccf and pfb_decimator_ccf do, but they seem use the same principle. And how to set the taps? Yes, they are based on the same principle, but the decimator just extracts the 1 channel while the channelizer produces all channels. To create the taps, you want to build a prototype filter that will have the bandwidth of the channelized signals at the input sampling rate. So if the input to the channelizer is fs and the bandwidth of each channel is B, you can build the taps with: taps = gr.firdes.low_pass_2(1, fs, B/2, B/10, 80) The B/10 is the transition width, which you can make as tight as you need to, this is just a random guess right now. The 80 is the stopband attenuation. This should make a rather long filter, then each channel uses a filter that is len(taps)/N. In the examples directory, you can see how this is done in pfb/cahnnelize.py and pfb/decimate.py. Tom On Thu, Dec 23, 2010 at 2:49 PM, Tom Rondeau trondeau1...@gmail.com wrote: On Thu, Dec 23, 2010 at 1:19 AM, James Jordan james.jordan@gmail.com wrote: Hi Martin, pfb_channelizer_ccf will seperate all channels, But I dont need each channel. I only need the channel I am interested in. Seperating all channels will eat a lot of CPU resource. Not really. It's a very efficient algorithm and won't cost you that much. I have check pfb_channelizer_ccf source, it finally use fftw to process channelizer. So can I directly use fftw to do my work. Not quite. The PFB channelizer uses a filterbank where each filter is specifically generated with a phase relation. The FFT part isn't doing exactly what you expect it's doing. We'd have to go through the math, though. If you are looking to just get a single channel out, then use the pfb_decimator_ccf(N, taps, channel) to split the bandwidth into N channels, using filter taps taps, and you can specify which channel you want to take by specifying the channel. Here's the way to translate the channel into the physical Nyquist zone you are looking for N=7 (hopefully this format survives): Channel: 456 0 1 2 3 Frequency: -3B | -2B | -1B | 0 | 2B | 2B | 3B Tom On Tue, Dec 21, 2010 at 6:19 PM, Martin Braun martin.br...@kit.edu wrote: On Tue, Dec 21, 2010 at 06:02:44PM +0800, James Jordan wrote: Hi all, I need to receive many narrowband signals, but usrp hard ware only provide 4 RX, so I need to receive more than one narrowband signals per RX. Is my idea possible? I dont want to use more than one usrp to achieve that, anyway which will be an option if my first idea can't work. If your total bandwidth (sum of all bandwidths) does not exceed a couple of MHz, you can use the polyphase channelizer (pfb_channelizer_ccf). The result will be an equally spaced set of narrowband channels. Happy DSP'ing, MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-3790 Fax: +49 721 608-6071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association ___ 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] GNURadio is disappointing [was: Greeting and a question]
Its not about talking high. Its community of people trying hard to press Ettus Research products. Putting people down is not the motto of GNURadio. Regrading putting off from the list: Discussion is on for open source platform. This is GNURadio platform. Here discussions are open for Ettus Research products and any other hardware product which can be used with GNURadio. Is GNURadio also owned by Ettus Research ?. Regarding your concern on keeping things focused; Things on GNURadio are not focused. That's the concern. When.open source platform is the focus then everyone has the freedom to discuss open platform solution rather than promoting specific products for commercial needs. Regrading your comment people on the list that don't like Ettus Research or the way Gnu Radio is running, take them off the list Is that only Ettus Research based products needs to be discussed ?. I suggest you reconsider your statement. On Fri, Jan 21, 2011 at 2:25 AM, Elvis Dowson elvis.dow...@mac.com wrote: Hi Tom Matt, Begin forwarded message: From: Marcus D. Leech mle...@ripnet.com So, respectfully, you're full of crap, Sanjay. No BSP is going to automatically know how to do all the functions we want to do: Someone ought to moderate this list. I for one find Marcus annoying. He mentioned that he's employed part time by Ettus Research. He should be told to tone down. It just takes a few guys like Marcus to put people off. If there are people on the list that don't like Ettus Research or the way Gnu Radio is running, take them off the list. At least it will keep things focussed in the right direction. As for people like Marcus, they should be told to behave politely to other members on the list. Elvis Dowson ___ 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] hi all, can I use one RX receive a wideband signal and then seperate it to many narrowband signals
On 01/20/2011 09:42 PM, James Jordan wrote: Hi Tom, This is very old topic. I have read a DSP book. But I find that I still not very understand channelizer. Why in channelizer use low pass filter, in my imagine channelizer will use band pass filter to filter each channel like that: 600Mhz baseband signal have 4 channel each channel have 100Khz bandwidth. so the channel freq is: 599.8Mhz 599.9Mhz 600Mhz 600.1Mhz. So I need 4 bandpass filter to filter each channel but actually the channelizer use lowpass filter, so why? I know you've asked Tom, but he's on the road. I haven't looked at the Gnu Radio channelizer, but one way to implement a channelizer is to convert all the signals to baseband, then low-pass filter.That way, all channels are at baseband when you're done. Does that make sense? -- 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] hi all, can I use one RX receive a wideband signal and then seperate it to many narrowband signals
Marcus, Thanks for reply. That is make sense, so the point become how to convert the signal to baseband. On Fri, Jan 21, 2011 at 11:11 AM, Marcus D. Leech mle...@ripnet.com wrote: On 01/20/2011 09:42 PM, James Jordan wrote: Hi Tom, This is very old topic. I have read a DSP book. But I find that I still not very understand channelizer. Why in channelizer use low pass filter, in my imagine channelizer will use band pass filter to filter each channel like that: 600Mhz baseband signal have 4 channel each channel have 100Khz bandwidth. so the channel freq is: 599.8Mhz 599.9Mhz 600Mhz 600.1Mhz. So I need 4 bandpass filter to filter each channel but actually the channelizer use lowpass filter, so why? I know you've asked Tom, but he's on the road. I haven't looked at the Gnu Radio channelizer, but one way to implement a channelizer is to convert all the signals to baseband, then low-pass filter.That way, all channels are at baseband when you're done. Does that make sense? -- 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Yet another kick at the cheap-hardware can
Hi Marcus, In your design there is only a single RX. I think it is better to build an expandable board which can expand 2 RX 3 RX... That will only introduce a little more cost but will meet much more people's need. On Thu, Jan 20, 2011 at 11:39 AM, James Jordan james.jordan@gmail.comwrote: Hi Marcus, Who works on this project now? Why choose USB as the interface to host. The USB interface became the bandwidth bottleneck in USRP1, so why use network interface? On Thu, Jan 20, 2011 at 7:23 AM, Marcus D. Leech mle...@ripnet.comwrote: http://www.sbrac.org/files/digital_receiver_cheap.pdf This has everything in one place--commit to a single host I/O, and go cheaper as a result. The estimated BOM cost for this, including PCB would be under $100.00. If you sacrifice very-fine tunability, then you don't need a DDC in the FPGA, and only need a CIC decimator chain, and you only need Rx logic in the FPGA, so you can get away with the smaller EP1C6 FPGA. There's a 9K-LE Xilinx Spartan-6 which is marginally cheaper ($16.44 vs $17.50) than the Altera, but only available in larger quantities from Digikey. Also, I think the Altera toolchain is cheaper (free??) -- I dunno, I'm not an FPGA guy. Note the use of ultra-cheap 8-bit ADCs. This design isn't going to win any awards for dynamic range, but it helps keep the BOM cost down, and as someone else observed, you get processing gain every time you reduce the bandwidth. So at 5MHz bandwidth, you've added a couple of effective bits. For the types of wide-band science-radio experiments one might want to do with this, a handful of bits is just fine. Now, I want to emphasize again that I have *no interest* in physically producing such a thing, but I'm always willing to contribute my engineering wisdom, for whatever that's worth. Also, to set a ground rule for future discussions. If this turns, yet-again, into an Ettus-bashing fest, I'm dropping out of the thread, and not participating in any further discussions. Such nonsense isn't productive, or even fair or reasonable. Matt and his employees (and part-time contractors, like me) are good, hard-working people with an excellent product, and who have **pioneered** reasonably-priced hardware that works well with Gnu Radio. The question I think this discussion can answer is fairly simple: are there design choices that can be made, with significant compromises in functionality, that can produce a design that is practically producible by an open-source hardware community, and will such a device be useful-enough over the types of hobbiest uses-cases we're interested in. Further, will such a device meet the delivered-price goals. 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: o High-level hardware design o Detailed schematic capture and PCB layout o FPGA firmware design o Host-interface (FX2?) firmware design o Host driver software design and implementation o Small-scale financial investment for initial PCBs, components, etc Once such a board works, then someone needs to be found to distribute either kits or finished product. Something that vaguely compares to this effort is the FunCube Dongle, which is a quadrature receiver covering 64MHz to 1.7GHz, but with 96KHz host-side bandwidth. That project is selling fully-built units for about USD 170.00. -- 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] hi all, can I use one RX receive a wideband signal and then seperate it to many narrowband signals
On 01/20/2011 10:22 PM, James Jordan wrote: Marcus, Thanks for reply. That is make sense, so the point become how to convert the signal to baseband. Oh, that's relatively easy--you multiply it with a complex signal at the same frequency--that's exactly how it's done in hardware, and it works equally-well in software. The Gnu Radio channelizer likely is more sophisticated than that, using different mathematical tricks to improve efficiency, etc. When you multiply two sinusoids of Xhz and Yhz, you end up with a mixed sinusoid-- Xhz+YHz and XHz-Yhz. In direct-conversion, you mix (multiply) it with a signal of the same center frequency, and you get the baseband frequencies, but since this is baseband, you need to use complex representation, otherwise the + and - frequencies fold around each other. -- 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] NanoSail-D turns out isn't lost!
On 01/20/2011 08:35 PM, Alexandru Csete wrote: I tried earlier today with a handheld Arrow II yagi connected directly to WBX. I could hear it but it was too weak to decode. A bigger yagi should give sufficient signal. In case you receive, it is very easy to decode the telemetry. It uses 1200 bps AFSK FM modulating the carrier, so a simple NBFM receiver and the audio fed to e.g. multimon (http://www.baycom.org/~tom/ham/linux/multimon.html) works. Decoded telemetry can be submitted to the ops team at http://beacon.engr.scu.edu/Submission.aspx Have fun! Alex ___ Yup, I knew it was 1200 AFSK FM. Good to know you *almost* demodulated it successfully with WBX. I rather doubt that I'll be able to get to my groups 60ft dish before the topic becomes uninteresting :-( But I do have a 70cm YAGI in my store-room somewhere, perhaps I shall dig it out, and wait for a pass over my city to see if I can demodulate the signal! -- 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] Showing a time-varying quantity in GNU Radio (with qtgui)
Thanks, all. If I have a problem with adding a plotting widget, I'll post further questions. :) -- Minsuk Kang On Wed, Jan 19, 2011 at 9:01 PM, Tom Rondeau trondeau1...@gmail.com wrote: On Wed, Jan 19, 2011 at 12:08 AM, Minsuk Kang minsuk.k...@itc.kaist.ac.kr wrote: Dear all, I'm implementing a GUI to show the time-varying wireless channel gain with qtgui. To be specific, I want to implement is a history plot. The X-axis is discrete time and the Y-axis is a channel gain. And the plot should be updated (refreshed) every few seconds. ( for example http://qwt.sourceforge.net/cpuplot.png ) I've tried with qtgui.sink_f() block. But, the basic option 'plottime' is not appropriate for this purpose. Is there any other way to implement it? Minsuk Kang You will have to add a plotting widget to the qtsink in C++ in gr-qtgui/src/lib to do what you want. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to solve the error of bert in /digital-bert/
Dear all, From now on, I tried to estimate BER SNR value by using bert supported by gnuradio in order to get SNR-BER plot for various modulation scheme. However, when I executed benchmark programs of TX/RX in digital-bert, SNR value was about 7~8 dB and BER value was about minimum 0.06~0.07 although tx's amplitude is maximum value. I believe that the benchmark sources has fatal error and I can't use the source for our purpose. How to solve this problem to get accurate SNR and BER information? Maybe, Did anyone try to take SNR-BER plot by using gnuradio to other case, and how? Please, Help me!! - Hanjin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
