[Discuss-gnuradio] WTB USRP2 Boards and Daughter cards
Hi, I'm looking for USRP2 boards and daughter cards. If anyone is selling, hit me up. thanks Stan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Viterbi--OFDM
Hello Achilleas, that's exactly what I thought abaout as well. Because the part I discribed as channel in my last mail is a wireless transmission using usrp2. Not using channel coding, I have packet error rates of 1 to 2 % using bpsk subcarrier constellation and abaout 18 % using qpsk. And if I evaluate the packet error rates not as a mean value, but in smaller periodes, there are periodes where the viterbi correcty almost every error, but there are also periodes in which there are just erroneus packets produced. So as you said, I thought about using an interveaver to reduce the problem of burst errors. If that doesn't work, it's no bigger problem, because I've implemented a selective repeat arq as well, so using this protocol, I'm getting good or even better performances, due to the reduced amount of data to transmit. So thanks for your quick help, I'll try this out, when I'm back a university on monday. Tobias Am 10.09.2010 20:47, schrieb Achilleas Anastasopoulos: My guess is that the inner channel (ie the combination of OFDM modulator/channel/OFDM demodulator) is producing big bursts of errors. Essentially either the packet is correctly received or completely erroneously received. In that case the outer Convolutional code cannot do much; on the contrary it deteriorates performance because of the SNR loss due to coding. One way to verify this hypothesis is to measure the error statistics of the inner channel. The way to improve is to interleave before the inner channel with sufficient depth (multiple OFDM symbols). Achilleas ___ 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] GNU Radio via MacPorts Updated
On Wed, Sep 8, 2010 at 4:27 AM, Michael Dickens m...@alum.mit.edu wrote: On Sep 7, 2010, at 2:04 PM, Elvis Dowson wrote: Does it use the GTK+ with support for native OS X look and feel? It uses whatever MacPorts provides; by default: gtk2 @2.20.1_0 +x11 but I can specify for it to use instead: gtk2 @2.20.1_0 +no_x11 +quartz and then I have to go through all of the various graphics ports make sure they are also +no_x11+quartz . I haven't tried this latter to make sure it works, but I don't see why it wouldn't (unless one of the ports is broken with those variants). I tried on another computer to install gtk2 +no_x11 +quartz and learned that pango (the font rendering engine) is quite broken. It's a known problem: https://trac.macports.org/ticket/20924 Until fixed it is not very useful because all text is dsplayed as squares. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: s/Eric/Tom/g
Eric, Many of us are deeply grateful to you for what you have contributed to GNU Radio development, Q/A, and maintenance. Without your pioneer work, commitment and dedication, GNU Radio would not be like what we have today (this applies also to a few other folks you mentioned in your announcement). As far as I know, many many people, particular students all over the world, have benefited greatly from your work. Twenty years after SDR was proposed, it is still hard to find low cost and relatively good performance SDR software packages and platforms. It's you, Matt, and a few others who have changed the landscape. Taking this opportunity, I'd like to show my gratitude to you folks. I have personally worked with Tom Rondeau. Even though it was just a few months in 2007, I was able to find out that he is smart, skilled, dedicated, and passionate about SDR RD. Since then, Tom, as I have observed, has been continuously contributing greatly to GNU Radio development. His philosophy about open source project combined with his knowledge and skills, I believe, will enable him, together with this community, to drive GNU Radio to new levels. I hope that, after stepping down as the Maintainer, you will have more time for other things that you like to do in your life. Best regards, Feng (Andrew) Ge, Ph.D. Senior Research Scientist Telcordia Technologies, Inc. On 9/10/2010 12:00 PM, discuss-gnuradio-requ...@gnu.org wrote: -- Message: 26 Date: Fri, 10 Sep 2010 08:38:40 -0700 From: Eric Blossome...@comsec.com Subject: [Discuss-gnuradio] s/Eric/Tom/g To:discuss-gnuradio@gnu.org Message-ID:20100910153839.ga4...@comsec.com Content-Type: text/plain; charset=us-ascii As some of you know, I've been involved with GNU Radio for a long time. The idea that became GNU Radio started as a conversation over dinner in San Francisco with John Gilmore, something like 10 years ago. Interest and use of GNU Radio is currently at the highest level it's ever been. I however, have come to a place in my life where I'd like to devote less of my time to GNU Radio and more to other things. After discussions with GNU Radio developers over the past several months, I'm pleased to announce that long time GNU Radio contributor Tom Rondeau has agreed to take over the GNU Radio Maintainer role from me. For those of you who don't know Tom, he's the perfect person for the job. He's smart, has a vision for the future, and has the cat herding instinct required to succeed in the position. Tom received his Ph.D. in 2007 from Virginia Tech's Department of Electrical and Computer Engineering. Johnathan Corgan will continue to handle GNU Radio release management and provide professional services related to GNU Radio. Matt Ettus and the rest of the crew at Ettus Research will continue to crank out low cost hardware for all of us to enjoy. I plan to continue contributing to GNU Radio, and will be finishing up some extensions for message passing, as well as some other things where I'm probably best positioned to do the work. Bottom line: business continues as usual, and you'll see more of Tom and less of me. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: s/Eric/Tom/g
On Sat, Sep 11, 2010 at 04:57:26PM -0400, Andrew Ge wrote: Eric, Many of us are deeply grateful to you for what you have contributed to GNU Radio development, Q/A, and maintenance. Without your pioneer work, commitment and dedication, GNU Radio would not be like what we have today (this applies also to a few other folks you mentioned in your announcement). As far as I know, many many people, particular students all over the world, have benefited greatly from your work. Twenty years after SDR was proposed, it is still hard to find low cost and relatively good performance SDR software packages and platforms. It's you, Matt, and a few others who have changed the landscape. Taking this opportunity, I'd like to show my gratitude to you folks. I have personally worked with Tom Rondeau. Even though it was just a few months in 2007, I was able to find out that he is smart, skilled, dedicated, and passionate about SDR RD. Since then, Tom, as I have observed, has been continuously contributing greatly to GNU Radio development. His philosophy about open source project combined with his knowledge and skills, I believe, will enable him, together with this community, to drive GNU Radio to new levels. I hope that, after stepping down as the Maintainer, you will have more time for other things that you like to do in your life. Best regards, Feng (Andrew) Ge, Ph.D. Senior Research Scientist Telcordia Technologies, Inc. Thanks for the kind words! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] please help - i am stuck - spreading data and bpsk
hi, Can someone please tell me how to do this? I want to generate DSSS with BPSK modulation in gnuradio but I have a few doubts that couldn't be cleared even after a lot of looking for an answer. The DSSS transmitter block diagram from various books shows that i have to XOR the input data with the PN sequence to spread and then BPSK modulate. My doubt is 1. I did the same and then BPSK modulated using the gnuradio DBPSK modulation without the diff encoder block but I am having trouble in acquisition at the receiver. I am using the method described in the book Fundamentals of Global Positioning System Receivers by Tsui. Maybe I am doing something fundamentally wrong at the transmitter. 2. Someone on this list suggested BPSKmod- RRCFilter -SPREADING. If samples per symbol were 1 then I can just multiply the symbol with the PN sequence but as it is always greater than 1 I cannot figure out how I can spread. Can someone please help me here? 3. Is it possible to remove the RRC filter completely and instead use (1+0j) and (-1+0j) symbols to modulate the carrier and still get good results at the receiver? If it is possible then life would be easier as I don't have to worry about the problem mentioned above in 2. 3. If anyone can share the transmitter block diagram of a GPS transmitter then I think it can be of great help as it has a DSSS modulation scheme. All i found on the internet was block diagrams but my concern is about pulse shaping and none of these diagrams show nothing about that. I did put in an effort to find answers by myself for a long time but as I couldn't find an answer I am writing for a little guidance. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] s/Eric/Tom/g
As some of you know, I've been involved with GNU Radio for a long time. The idea that became GNU Radio started as a conversation over dinner in San Francisco with John Gilmore, something like 10 years ago. As one of the guys present at that dinner in early 2001, let me suggest that Eric has done an incredible job picking up that idea and running with it for a decade. We saw that commercial companies were using digital signal processing to radically simplify and improve their products, but that the free software world hadn't learned those lessons. That meant there was a real opportunity hanging wide-open. Eric jumped on it. Part of the deal was that I'd pay his salary for the first year or two, because I knew you can't really get much public support or financial support for a free software project until it can actually do some useful job. Eric spent the first year learning modern signal processing, surveying existing hardware and existing free software, then settled on MIT's spectra/pspectra code base as a good place to start hacking. After the first few years, he found enough academic and commercial support for GNU Radio that I didn't need to pay him full time -- and he weaned himself fully off my support shortly afterward. Matt Ettus was an early volunteer who also saw the real-world promise in free signal processing software. We had reasonable software, but the available high speed A/D and D/A hardware cost thousands of dollars and was pretty lame. Matt finished his job designing Bluetooth circuitry, and then risked everything to design and build what became the USRP. With Eric's help, he built up from nothing to a one-man design/procurement/manufacturing/stocking/shipping/sales/customer-support/programming shop, which over the years has matured into the thriving and valuable business it is today. Jay Lepreau was another early contributor who saw how GNU Radio could enable active academic research into cognitive radios. Jay brought us into his lab at the University of Utah, encouraging researchers at dozens of other institutions to design their experiments on GNU Radio and the USRP. He brought us into the academic funding that significantly matured GNU Radio's ability to do packet-based communication. Jay died in 2008 but his contributions live on in this community. Along the way we took a few detours into application areas that tested and honed GNU Radio's strengths. While Hollywood was trying to force the FCC to outlaw TV receivers that could receive free over-the-air digital TV signals (because they'd forgotten to put DRM into them), Eric and a small team successfully implemented an HDTV receiver using old PCI-bus digitizer boards and GNU Radio. Hollywood's engineers said it couldn't be done, and we knew they were liars, so we did it. Indeed, it ran 30x slower than realtime on a dual Athlon motherboard. But it ran, decoded actual TV signals, and proved to the regulators and to the standards committee that you'd have to not only outlaw hardware demodulators, but also software -- which EFF had recently proven to a Federal appeals court was a violation of the First Amendment. The fucking bastards at the FCC passed the regulation anyway (https://secure.wikimedia.org/wikipedia/en/wiki/Broadcast_Flag), but the American Library Association and Public Knowledge litigated in federal court, proved that the FCC had no authority to regulate what receivers do with their signals after reception, and the rule was struck down. This HDTV demodulator code is *still* not running in the latest version of GNU Radio, but I hope someone will work out the kinks. Modern hardware should be able to do it in realtime. A second big attempted application area was passive radar. We read that the US Army's favorite tactic when invading somewhere was to blow up all the TV and radio stations because it's easy to track airplanes by watching their signals bounce off the planes. It works with cellphone tower signals, too. Eric spent several years researching the topic, writing GNU Radio code, and designing antennas and hardware. Ultimately none of it worked reliably; it took more dynamic range (or custom differential hardware) than we had, but we learned a lot and have made it easier for future generations to do this as the hardware improves. Eric, it's been a great decade, and I'm looking forward to the next big trouble you get into! John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
