Re: [Discuss-gnuradio] Inquiry about USRP GNU Radio

If there was a MIMO project on CGRAN you can find it archived still: https://web.archive.org/web/20140822005337/https://www.cgran.org/ I need to just link to this on the explanation... On Oct 28, 2014 9:19 PM, "이재훈" wrote: > Dear > > > > > > Hi, my name is jaehoon Lee and a graduate student at S

Re: [Discuss-gnuradio] Looking for simple ra

Hi Will, The subversion server is still up and your relevant code is at https://www.cgran.org/svn/projects/simple_ra Archive.org has a nice cache of CGRAN also: https://web.archive.org/web/20140702091149/https://cgran.org/wiki/simple_ra - George On Mon, Oct 20, 2014 at 6:20 PM, Will Caruana wr

Re: [Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for long (want feedback)

in at the last published version. > > > On Mon, Oct 6, 2014 at 10:22 AM, George Nychis wrote: > >> Let me add one more thing about CGRAN while we are still trying to narrow >> down how to handle this. One reason I put CGRAN in place was to host code >> that might "d

Re: [Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for long (want feedback)

Let me add one more thing about CGRAN while we are still trying to narrow down how to handle this. One reason I put CGRAN in place was to host code that might "disappear." For example, students post it on university webpages and when they graduate, that hosting gets taken down. Additionally, some

Re: [Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for long (want feedback)

thub/osmocom/wherever. We get the functionality to backup "all the GNU > Radio ecosystem" at once by running some git submodule update command, and > pybombs could just clone that repo, and init submodules as the user > installs them. > > Greetings, > Marcus > > >

Re: [Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for long (want feedback)

I agree with Martin that once we go to git, every project has its own independent repo. That shouldn't take much time at all to do, I can just run some svn2git magic to spit out separate repositories. The question will be where those repositories live. I can host the repositories again. I could

Re: [Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for long (want feedback)

nd to be more supportive of newer projects. The clear example has always been making it more git-centric. On Mon, Sep 29, 2014 at 2:37 PM, Marcus D. Leech wrote: > On 09/29/2014 05:31 PM, George Nychis wrote: > > Thanks for the feedback, Chris and Martin. What I'm going to do i

Re: [Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for long (want feedback)

thing that ties in nicely with > Pybombs, and also uses the gits. How exactly, that's something we need to > decide, and any community input on this is appreciated. > > Cheers, > M > > > On 29.09.2014 11:01, George Nychis wrote: > >> The machine that runs CGRAN

[Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for long (want feedback)

The machine that runs CGRAN down in some basement somewhere at Carnegie Mellon has hit some issues again. Given that I'm no longer at the university, these issues are becoming harder for me to address. At this point, it's probably best for CGRAN to "move on" as we've all been in discussion about

Re: [Discuss-gnuradio] CGRAN down, working on it

3, 2014 at 1:58 PM, George Nychis wrote: > Something must have been upgraded on the machine, and a significant number > of the dependencies needed to run Trac have disappeared. For example, > python has disappeared from the machine :P > > This might take a while, sorry. > >

Re: [Discuss-gnuradio] CGRAN down, working on it

Something must have been upgraded on the machine, and a significant number of the dependencies needed to run Trac have disappeared. For example, python has disappeared from the machine :P This might take a while, sorry. On Sat, May 3, 2014 at 1:15 PM, George Nychis wrote: > It looks l

[Discuss-gnuradio] CGRAN down, working on it

It looks like CGRAN is down for some reason. The machine that hosts it is still up and I haven't found the cause of the problem yet. Still digging. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listin

Re: [Discuss-gnuradio] cgran is weird

Tue, Oct 22, 2013 at 12:48 AM, Vanush Vaswani wrote: > It would be good to have a list of up to date modules. > > On Tue, Oct 22, 2013 at 2:58 PM, George Nychis wrote: > > CGRAN founder, here! > > > > Like Marcus said, it's just out of date code and instructions

Re: [Discuss-gnuradio] cgran is weird

CGRAN founder, here! Like Marcus said, it's just out of date code and instructions. This is bound to happen with the majority of projects over time. But, the benefit to anyone is that parts of them can be used to build new things, and if you really need functionality provided by one of those proje

Re: [Discuss-gnuradio] GUIs are not showing in 'master'

This fixed my "GUI issues" ... thanks a bunch for tracking down the error and pushing a fix for it so quickly! I appreciate it. On Sat, Jun 22, 2013 at 1:19 PM, Johnathan Corgan wrote: > On Fri, Jun 21, 2013 at 6:48 PM, Michael Dickens wrote: > >> >> So fixing the init call as above with "attri

Re: [Discuss-gnuradio] GUIs are not showing in 'master'

Great suggestion, Jonathan. I've never used bisect (still migrating myself over to the git world), but I'll check out bisect and see if I can track down this bug. On Fri, Jun 21, 2013 at 4:40 PM, Johnathan Corgan wrote: > On Fri, Jun 21, 2013 at 1:36 PM, George Nychis wrote: >

Re: [Discuss-gnuradio] GUIs are not showing in 'master'

ivide and conquer with a little bit of intelligence in what was committed... On Wed, Jun 19, 2013 at 2:49 AM, George Nychis wrote: > My build is running on Ubuntu 12.04 within Parallels ,8 on a OS X > 10.8.4 host (MacBook Air). If there's any more debugging I can do to > help th

Re: [Discuss-gnuradio] GUIs are not showing in 'master'

My build is running on Ubuntu 12.04 within Parallels ,8 on a OS X 10.8.4 host (MacBook Air). If there's any more debugging I can do to help this out, let me know On Tue, Jun 18, 2013 at 5:36 PM, Johnathan Corgan wrote: > On Tue, Jun 18, 2013 at 2:22 PM, George Nychis wrote: >>

Re: [Discuss-gnuradio] GUIs are not showing in 'master'

also broke Linux. > > There was a revert of that in the last day or two. > > on Jun 18, 2013, *Tom Rondeau* wrote: > > On Tue, Jun 18, 2013 at 2:31 PM, George Nychis wrote: > > I have two builds of gnuradio, one that uses 'maint' and one that is > > 'mas

[Discuss-gnuradio] GUIs are not showing in 'master'

I have two builds of gnuradio, one that uses 'maint' and one that is 'master' ... in the master, I'm finding that GUIs are not showing. For example, if I run uhd_fft or uhd_siggen_gui using the master branch then I have no window that pops up. It is building gr-wxgui and I believe I have the appro

[Discuss-gnuradio] CGRAN: some traffic statistics, top projects, call for new projects!

Hey all, I hope you're enjoying #grhack with your airhorn ;) CGRAN (https://cgran.org) still continues to grow, and its traffic far exceeds ever what I thought it was. Here are some numbers: - *Page Views Per Day: *~1000+ - *Unique Visitors: *1,598 (in 1 week) - *Demographics: *visi

Re: [Discuss-gnuradio] CGRAN "release tagging"

If there is anything fundamentally that I can change about the CGRAN repository to help, let me know! On Thu, Sep 13, 2012 at 4:00 PM, Richard Farina wrote: > On 09/13/2012 03:31 PM, mle...@ripnet.com wrote: > > > > > > I've tried, and failed to tag the current version of multimode on > > CGRAN

[Discuss-gnuradio] CGRAN now breaking projects in to categories, feedback wanted!

Hi all, CGRAN has grown significantly beyond my expectations over the past 4 years! It started off as two personal projects with the hope of providing somewhere for people to develop applications outside of the main GNU Radio code base. Now we have 38 projects and a few others in development but

Re: [Discuss-gnuradio] Remove USRP filters.

Hey Michael, I just purchased an Ubertooth One and it came in the mail today, pumped to play around with it! I was excited to find the project. It fills in a huge gap of commodity bluetooth sensing. In downloading the ubertooth code, I stumbled in to your gr-bluetooth code and then just so happ

Re: [Discuss-gnuradio] if uhd_transmitter instantiated after receiver, TX works, otherwise RX works

Your attached patch also fixes the problem! Thanks a bunch for helping narrow down this issue :) On Mon, Jun 18, 2012 at 3:59 PM, George Nychis wrote: > Hi Josh, > > Thanks a bunch for these pointers/patches and looking in to it! We are > currently testing them out, shouldn

Re: [Discuss-gnuradio] if uhd_transmitter instantiated after receiver, TX works, otherwise RX works

Hi Josh, Thanks a bunch for these pointers/patches and looking in to it! We are currently testing them out, shouldn't take long. However, we did verify that reverting to the older version (003.003.002) did work for us as it did for King (thanks!). Stay tuned... we'll let you know ASAP. - Georg

Re: [Discuss-gnuradio] if uhd_transmitter instantiated after receiver, TX works, otherwise RX works

it out in the instantiation of the transmitter, the receiver will work. This is despite both calls to set_freq() taking the same frequency. This must trigger whatever tuning is happening that breaks the opposing chain. Trying a newer version of UHD now... On Thu, Jun 14, 2012 at 4:12 PM, George

[Discuss-gnuradio] if uhd_transmitter instantiated after receiver, TX works, otherwise RX works

Hi all, I'm observing some odd behavior that I can't seem to figure out. This is in (your favorite script) tunnel.py Here, self.sink is instantiated as a uhd_transmitter() and then self.source is a uhd_receiver(). Both are connected respectively to their part of the flow graph: https://github.c

Re: [Discuss-gnuradio] CGRAN downtime - working on it

Back alive... if anyone has issues please let me know. On Mon, Jun 4, 2012 at 11:42 AM, George Nychis wrote: > Having some issues with CGRAN right now and actively working on it. So if > you experience problems, hang in there. > > The SVN repo should be working just fine, but hav

[Discuss-gnuradio] CGRAN downtime - working on it

Having some issues with CGRAN right now and actively working on it. So if you experience problems, hang in there. The SVN repo should be working just fine, but having some web issues. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org

Re: [Discuss-gnuradio] Help using UCLA Zigbee PHY examples updated for UHD

Henry, If you are able to update this code for UHD, please consider committing your changes to CGRAN so others don't have to go through the same process :) https://www.cgran.org/wiki/UCLAZigBee On Tue, May 15, 2012 at 7:01 PM, Josh Blum wrote: > > > File > "/usr/local/lib/python2.7/dist-p

[Discuss-gnuradio] IEEE DySPAN 2012: Call for Demonstrations

cation: 27 July 2012 Camera-Ready Paper Due: 17 August 2012 For enquiries, please contact DySPAN 2012 Demonstration Chairs. Best Regards, IEEE DySPAN 2012 Demo Chairs George Nychis, Carnegie Mellon University, Pittsburg, PA, USA ( gnyc...@cmu.edu) Przemyslaw Pawelczak, Fraunhofer Heinrich Hertz In

Re: [Discuss-gnuradio] detecting spectrum holes

Finding white space in the spectrum can be done by looking at power across the bins you are monitoring. I have done White space research with the USRP2 and the WBX, and they worked out great for me. So you're on the right track! Take a look at this work, Section 3.1: http://static.usenix.org/eve

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

On Mon, Mar 5, 2012 at 9:26 AM, David Knox wrote: > > > I just don't want to loose all the flexibility of software by moving the > > critical but interesting things to hardware. > > > > (* But of course, it all depends upon your goals. *) > > George (and others), >I th

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

Let me put it this way... I'm going to build it because I need it ;) But what I'm asking/hoping for is for it to be useful beyond just me and actually have a lifespan beyond my immediate use of it. So, I'd like to get some feedback on how others might like to see it tied in to UHD, or the type of

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

On Sun, Mar 4, 2012 at 10:01 AM, Marcus D. Leech wrote: > George, >> >> >> I do think we need something like what you have suggested but I am still >> a bit puzzled about the right way of implementing it. >> >> Best regards, >> Andre >> >> I think a more fundamental issue is that "carrier sense"

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

> > > I totally like and support your idea and would love to help realizing > it. Using the timestamp logic inside UHD as a reference is a great idea > that also came to my mind a while ago. > There are a few things from the architecture point of view though that > need to be discussed. Let's take

[Discuss-gnuradio] building carrier sense in the FPGA and UHD

Hi all, I'm going to be hacking carrier sense in to the FPGA on the USRP2 very soon. Basically, taking what I did with the "in-band" project from the USRP1 with carrier sense, and moving it forward to USRP2. The idea is, just like you can set a timestamp to "gate" a packet on its way out: only t

Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs

e also be of value 1? Or only just the first sample? What about the last sample? Just trying to understand exactly how the trigger works. On Mon, Feb 27, 2012 at 9:12 PM, Josh Blum wrote: > > > On 02/27/2012 05:30 PM, George Nychis wrote: > > It's be good if you can ch

Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs

bursts, but don't seem to control the overall stream? Maybe I am missing something. On Sunday, February 26, 2012, Marcus D. Leech wrote: > ** > On 02/26/2012 08:54 PM, George Nychis wrote: > > > > On Sun, Feb 26, 2012 at 5:01 PM, Marcus D. Leech > > > wrote: > &

Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs

bursts, but don't seem to control the overall stream? Maybe I am missing something. On Sunday, February 26, 2012, Marcus D. Leech wrote: > ** > On 02/26/2012 08:54 PM, George Nychis wrote: > > > > On Sun, Feb 26, 2012 at 5:01 PM, Marcus D. Leech > > > wrote: > &

Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs

On Sun, Feb 26, 2012 at 5:01 PM, Marcus D. Leech wrote: > ** > On 02/26/2012 02:29 PM, Apurv Bhartia wrote: > > Its an XCVR2450, but I do *not* start any 'packet' transmissions. All I > do, is to start both the flowgraphs, and just listen for packets. > > In which case, the TX side is running--e

Re: [Discuss-gnuradio] Citation of GNUradio codes

Hi Nazmul, I've seen most people just cite "GNU Radio. http://gnuradio.org"; ... ultimately benchmark_tx and benchmark_rx use large parts of the entire GNU Radio project. - George On Fri, Feb 24, 2012 at 7:16 PM, Nazmul Islam wrote: > Hello, > > I have used the benchmark_tx and benchmark_rx cod

Re: [Discuss-gnuradio] discussion on USRP-->Wall Socket for Power Line Comms

> > > > Maybe something a little more accessible from MAXIM: > > http://www.maxim-ic.com/products/powerline/ > > They have an evaluation kit which might have some testpoints to > connect up to a USRP, or try to ship off samples through their 10/100 > ethernet interface. > > Thanks, Brian! I will

[Discuss-gnuradio] discussion on USRP-->Wall Socket for Power Line Comms

Okay! So apparently there is some interest in power line communication for GSoC. But, what we would want to do is already have a safe way of connecting the USRP in to the wall socket for the student(s), and for the future of GNU Radio and USRP power line communications development. So, as a goal

Re: [Discuss-gnuradio] Power line communications

On Mon, Feb 20, 2012 at 6:32 PM, Johnathan Corgan < jcor...@corganenterprises.com> wrote: > On Mon, Feb 20, 2012 at 07:32, Johnathan Corgan > wrote: > > >> If you ever do this again, I would love to see some of the channels over > >> time. I ordered some basic PLC equipment, but all I really hav

Re: [Discuss-gnuradio] Reminder about call today

> > > OFDM for the equalization and FEC for the channel errors has been a > successful technique used in residential power-line communications. > However, commercial buildings tend to have long and unpredictable > power delay profiles, requiring long symbol times. In addition, there > are enormous

Re: [Discuss-gnuradio] Reminder about call today

> > > Interesting thought. Powerline communications have been discussed for > quite a while, but they tend to be horrible channels (old copper, long > distances, bad shielding, etc.). So yes, I'd expect OFDM for the > equalization and multipath (or 'echos' in this case) issues and heavy > channel c

Re: [Discuss-gnuradio] Reminder about call today

Hey all, I actually really want to join the call, because I have a GSoC idea, but I have a conflict with teaching assistant duties during that time. So I thought I'd briefly share, and if it does become of interest then maybe someone can get ahold of me and I could try to mentor or something. I

[Discuss-gnuradio] CGRAN wants your GNU Radio projects!

Just your friendly CGRAN update to the mailing list. I've seen a slowdown in projects posted to the CGRAN, yet not a slowdown in account signups. So, I thought I'd just e-mail out a quick update. The usual quick blurb (https://www.cgran.org/): *The Comprehensive GNU Radio Archive Network (CGRAN)

Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc

A bit late on this conversation... I just noticed it after I posted an update for CGRAN. GNU Radio has been largely successful in the academic community, because it provides us the flexibility to perform the style of research we need. Ultimately though, the limitations of the framework that were

Re: [Discuss-gnuradio] how to learn of decimation rate in general_work() ?

at 4:12 PM, Tom Rondeau wrote: > > On Tue, Feb 7, 2012 at 5:37 PM, George Nychis wrote: > >> >>> Hey George, >>> >>> You can use the relative_rate data member of the blocks. Setting the >>> decimation actually sets the relative_rate to 1.0/decimation. Yo

Re: [Discuss-gnuradio] how to learn of decimation rate in general_work() ?

> > > Hey George, > > You can use the relative_rate data member of the blocks. Setting the > decimation actually sets the relative_rate to 1.0/decimation. You can get > this value with the accessor function "relative_rate()". > > Hey Tom, Using this I can get the decimation rate, but is there a wa

Re: [Discuss-gnuradio] not getting timestamps from UHD received stream tags

Bingo, didn't realize they were only incoming at those points in time. Problem solved, thanks Josh! On Mon, Feb 6, 2012 at 9:18 PM, Josh Blum wrote: > > > On 02/06/2012 06:13 PM, George Nychis wrote: > > I am trying to read incoming RX timestamps from the UHD sample stream

[Discuss-gnuradio] not getting timestamps from UHD received stream tags

I am trying to read incoming RX timestamps from the UHD sample stream. I'd like to calculate the approximate time a preamble is received in the OFDM code. The issue is that, despite getting incoming frames and preambles, I do not seem to be getting timestamp values. I use get_tags_in_range() on

[Discuss-gnuradio] how to learn of decimation rate in general_work() ?

I am using stream tags to get the timestamp of its corresponding sample in general_work(). Now, if I want to calculate the time of an arbitrary sample in the incoming sample stream I need to know the decimation rate. This tells me how much clock time is added per-sample. So I can calculate the o

Re: [Discuss-gnuradio] MAC layer questions

Sorry for the brevity, traveling abroad and only have my phone. I am the author of the MAC code in cgran and have a paper on the work, give it a read: Enabling MAC Protocol implementations on software-defined radios. It gives you an idea of what all we did to gnu radio to build Macs and what the sp

[Discuss-gnuradio] CGRAN update, new projects, statistic keeping?

Hi all, It's been a while since I've sent out a CGRAN update, so I thought it was time for one. As of this e-mail, there are 169 registered CGRAN users, and 28 projects. Thanks to everyone for contributing, and I hope it continues to grow! Here are the 4 newest projects on our project list ( ht

[Discuss-gnuradio] CGRAN -- come share your GNU Radio / USRP projects!

Hi all, CGRAN has seen a little bit of a lull recently, either due to too many holiday cookies or too many cases of the common cold ;) Considering there is always a churn of GNU Radio users, I figured a "ping" might help! What is it? --- The Comprehensive GNU Radio Archive Network (C

Re: [Discuss-gnuradio] CGRAN, Merge tracking

On Mon, Dec 6, 2010 at 9:09 AM, Martin Braun wrote: > Hi, > > which version is the CGRAN SVN-Server? I just tried using > > $ svn merge --reintegrate > > on one of my CGRAN branches, and it failed. Is this just the CGRAN > server? Or is there a way to do this? > > Hi Martin, Here is the version:

[Discuss-gnuradio] CGRAN Project: tracking commercial aircraft with Mode S

Hi all, Another cool addition to CGRAN: Project: Mode S Receiver for Tracking Commercial Aircraft Contributor: Nick Foster Project Page: https://www.cgran.org/wiki/gr-air-modes Description: This module implements a complete Mode S and ADS-B

[Discuss-gnuradio] Gen2 RFID reader available in CGRAN

Hi all, I'm trying to send updates when new projects come in to CGRAN to help them gain exposure. Project: Gen2 RFID Listener Publication: Challenge: towards distributed RFID sensing with Software-Defined Radio MobiCom 2010 CGR

Re: [Discuss-gnuradio] UHD USRP2 full duplex mystery solved

To elaborate more on my issue... I see the USRP2 send mac pause frames, and then no new data is sent over the interface for 5-10 seconds. On Thu, Sep 23, 2010 at 2:46 AM, George Nychis wrote: > Just saw this thread now... I'm seeing this problem with my USRP2s and the > WBX board. H

Re: [Discuss-gnuradio] UHD USRP2 full duplex mystery solved

Just saw this thread now... I'm seeing this problem with my USRP2s and the WBX board. However, I'm not using UHD. Do you know a fix for this outside of UHD? On Tue, Sep 14, 2010 at 5:28 PM, Josh Blum wrote: > FYI - in the future this will go away in the future when tx flow control > becomes ho

Re: [Discuss-gnuradio] USRP2+WBX full duplex doesn't receive

Did you ever get this fixed? I'm seeing the same problem... On Wed, Aug 25, 2010 at 5:53 PM, Marcus D. Leech wrote: > > > > On Aug 24, 2010, at 11:16 PM, George Nychis wrote: > > > > > >> I don't think I've had this issue with my WBX and USRP2.

Re: [Discuss-gnuradio] USRP2+WBX full duplex doesn't receive

On Tue, Aug 24, 2010 at 7:11 AM, Marc Epard wrote: > On Aug 23, 2010, at 10:10 PM, George Nychis wrote: > > > If you stop transmitting, does your RX sample stream then begin again? > > Alas, no. Once it stops receiving, it never starts again. Time to dig into > the firmwa

Re: [Discuss-gnuradio] USRP2+WBX full duplex doesn't receive

On Mon, Aug 23, 2010 at 1:41 PM, Marc Epard wrote: > I'm trying to simultaneously transmit and receive with a USRP2 and WBX in a > C++ command line tool. I'm using txrx_wbx_raw_eth_20100608.bin and > u2_rev3-20100603.bin on the USRP2 and have tried GNU Radio version 3.3.0 and > 3.3.1 on the Ubunt

[Discuss-gnuradio] CGRAN now keeps project stats, and OFDMA project added

Hi all, At the request of several users, CGRAN now keeps track of project statistics through SVN logging. This keeps track of checkouts and updates, on a per-project basis. So if anyone wants statistics for the number of "downloads" on their project (starting as of today), you can email me privat

Re: [Discuss-gnuradio] Helper script to automatically add blocks

thanks for the contribution Martin :) I have some tools I could add to it myself. I think "devtools" was the right thing to do. Hopefully several people will contribute other tools to it. I will move it to the top of the Projects page. On Mon, Aug 16, 2010 at 5:44 AM, Martin Braun wrote: > H

[Discuss-gnuradio] Re: scaling issue on USRP2

So maybe I should be scaling to abs(complex) instead. Will try this. On Aug 14, 2010, at 6:26 PM, George Nychis wrote: > Whenever I send samples to the USRP2, I scale them between -1 and 1, such > that the absolute value of the greatest real, and imaginary, component is 1: > scale= 1 /

[Discuss-gnuradio] CGRAN wants your GNU Radio projects!

Hey all, I am trying to continually build up the number of projects on CGRAN. It is growing quickly! For those of you who don't know of it, it is an archive of 3rd party GNU Radio code and projects: https://www.cgran.org We broke 100 registered users recently, and we hit the 20 project mark! B

Re: [Discuss-gnuradio] USRP1 Inband firmware questions

> I managed to fix it (well, I think I did at least :) > > But the generated code, altough meeting fmax constraint, has some > setup/hold violation. > > Looking at the path, it seems there are latches (and not register) and > combinatorial signal being used as clocks ... which is frightening for >

Re: [Discuss-gnuradio] improper WBX transmission of tone in center of spectrum

PM, Matt Ettus wrote: > >> >> The WBX can put out about 20dBm at 520 MHz. -55dBm would be 75dB below >> the desired signal, which is quite a good amount of LO suppression. If >> you need more, you'll need to actively calibrate the DC offset to null >> it out. >&

Re: [Discuss-gnuradio] improper WBX transmission of tone in center of spectrum

The power of the tone comes in to the spectrum analyzer at -55.6dBm On Tue, Aug 3, 2010 at 12:04 PM, Matt Ettus wrote: > > > You are seeing uncompensated DC offset. What is the actual power of the > tone? > > Matt > > > On 08/03/2010 10:12 AM, George Nychis wrote:

Re: [Discuss-gnuradio] anyone had luck with high throughput IPC to GNU Radio?

On Fri, Jul 30, 2010 at 8:38 AM, Kunal Kandekar wrote: > Hi, > > I am unfamiliar with Octave, so I cannot be sure about your particular > scenario, but a potential problem could be internal buffering between > writes... Maybe try flushing the stream more? > > I could be wrong, but I thought named

[Discuss-gnuradio] WBX and auto TR switching?

I'm assuming the WBX has auto TR switching? Is there any code needed to enable auto TR switching from C++ after initializing the USRP2 with the standard usrp2::usrp2::make(interface, mac_addr_str); and then setting center frequency, decimation, interpolation, and gains? Thanks for the help. - Ge

[Discuss-gnuradio] anyone had luck with high throughput IPC to GNU Radio?

Hi all, Has anyone had any luck achieving high throughput (e.g., supporting interpolation of 8 or 16 with USRP2) from Octave to a GNU Radio flowgraph? I am trying to stream a signal to my GR flowgraph, and at first I tried sockets but then realized it was way too slow, and so I moved to pipes but

Re: [Discuss-gnuradio] OFDM spectrum with power rolloff?

Thanks a bunch for your response, Matt! > > Since you are using an interpolation is a multiple of 4, you won't see CIC > rolloff, you get a nice flat passband. > Got ya! > There are likely a couple of issues causing the spectrum to look bad. > First, successive symbols coming out of the FFT

[Discuss-gnuradio] OFDM spectrum with power rolloff?

Hi all, I am generating my own "OFDM" waveform which actually does not modulate anything. Step by step. I am simulating 1024 subcarriers but first generating 1024 zeros, and then I want to only enable the center 100 subcarriers. To do this, I map the center frequency at the first index in the a

Re: [Discuss-gnuradio] 802.15.4 how to forward a parameter to a c++ block

On Tue, May 25, 2010 at 10:16 AM, wrote: > Hi, > > I'm currently using the UCLA ZigBee PHY implementation posted on: > https://www.cgran.org/wiki/UCLAZigBee > with gnuradio. > > My question is the following: > How can I forward a parameter from: src/python/ieee802_15_4_pkt.py > ... e.g. from the

Re: [Discuss-gnuradio] BBN 80211b Transmitter with GNURadio 3.2.2 and USRP1

On Fri, May 21, 2010 at 1:06 PM, Smith L. wrote: > > Hi George, > > Were you able to test the usrp2_version code with two USRP2s? > > Let me know if you were able to successfully transmit 80211b packets from > one USRP2 to another. > were you able to build the usrp2 branch successfully with the

Re: [Discuss-gnuradio] BBN 80211b Transmitter with GNURadio 3.2.2 and USRP1

On Thu, May 20, 2010 at 11:08 PM, Smith L. wrote: > > Thanks George for your inputs. > > I have closely been monitoring cgran website. However, every project seems > to be focusing on how well one can use USRP1 or USRP2 as 80211b receiver. > But my goal is to communicate between two USRPs (whethe

Re: [Discuss-gnuradio] BBN 80211b Transmitter with GNURadio 3.2.2 and USRP1

On Thu, May 20, 2010 at 9:29 PM, Smith L. wrote: > > Hi Colby, > > Were you able to communicate between two USRP2s using bbn 80211 > usrp2_version code? > > I am not able to receive packets using USRP2 receiver even when other USRP2 > is transmitting. Can you please let me know if there are any c

Re: [Discuss-gnuradio] BBN 80211b Transmitter with GNURadio 3.2.2 and USRP1

On Thu, May 20, 2010 at 3:14 PM, Smith L. wrote: > > Thanks for the help, Doug. > > I do have two USRP2s and hence was also working on the usrp2_version code. > I > have both the transmitter and receiver code individually working correctly > with USRP2. However, the receiver is not able to receiv

[Discuss-gnuradio] new inband plan? message passing?

Hi all, What is the gameplan for the new inband infrastructure? VRT now defines the protocol/structure of the messages between the USRP and host... but what about message passing at the host? This is something I'm going to need in the near future, and if the price (a very, very, solid plan) is r

[Discuss-gnuradio] old USRP inband code

I'm trying to grab a copy of the GNU Radio code through git which still has the old USRP inband code. I noticed this commit from Jonathan in my search: Author: jcorgan Date: Thu Jul 9 02:55:51 2009 + Merged r11377:11390 from jcorgan/usrp-headers in to trunk. * Removed usrp-inband

Re: [Discuss-gnuradio] ofdm occupied tones concept

George, > Since the code they built to do the NC-OFDM was based originally on the > code inside GNU Radio, doesn't it make sense to put that back into GNU Radio > instead of CGRAN? The way that I originally wrote the code was to allow for > people to do this by manipulating the subcarrier map, so

Re: [Discuss-gnuradio] ofdm occupied tones concept

On Sun, May 2, 2010 at 4:08 AM, jf w wrote: > Hi all, > > I'm thinking about implementing non-contiguous OFDM with gnuradio. So I > read the ofdm codes of gnuradio. And I find the occupied tones concept in > gnuradio. Is it designed for non-contiguous OFDM? Or it is for other > reasons > There

Re: [Discuss-gnuradio] Spread Spectrum question in gnuradio

this would be similar to 802.11b's PHY at 1Mbps, except it uses the barker sequence as opposed to the sequence you mention. It spreads a BPSK signal using the barker sequence. You can take a look at the BBN 802.11b code in CGRAN to see how they implement this: https://www.cgran.org/browser/projec

Re: [Discuss-gnuradio] discontinuous OFDM implementation?

> > Do you mean discontinuous in time or frequency? If you're talking > about frequency (selectively turning off subcarriers, which I've heard > referred to as non-contiguous OFDM mostly), then there are definitely > a few implementations out there. I saw two groups at the latest IEEE > DySPAN conf

[Discuss-gnuradio] discontinuous OFDM implementation?

Hi all, Has anyone out there implemented discontinuous OFDM on GNU Radio and the USRP? I've seen a couple papers with an implementation on GNU Radio in DySPAN and some other conferences, but nobody has responded to my requests for the implementation. - George

Re: [Discuss-gnuradio] RANT ALERT: WTF Is wrong with you people?

In my time here, I've learned that SDRs bring together two worlds... those in EE, and those in CS. Those from the CS world don't understand a lot of the RF world, but would like to leverage SDRs to achieve something at the higher level and are thrown in to the RF world. Those in the EE world, und

[Discuss-gnuradio] CGRAN: new projects added & updates

ction into GNU Radio blocks. IT++ is a C++-based library for running communication based simulations, and includes channel coding functions, mobile propagation channel models and some mathematical tool needed in communications engineering and DSP development. Split-Functionality MAC Protocols (G

Re: [Discuss-gnuradio] Re: importing usrp2 module failing

on > command line: python -c "from gnuradio import usrp2" > > You should not need to run as root as long as the socket opener app has > suid permissions > > sudo chown root:usrp `which usrp2_socket_opener` > sudo chmod 04750 `which usrp2_socket_opener` > > -J

[Discuss-gnuradio] Re: importing usrp2 module failing

**NOTE** I do not get the import error when I do not run the command with > sudo, but then I do not get the proper raw socket permissions. Maybe that > rings a bell to someone? Something probably about an environment variable I > am missing. > > actually... I am getting the same error now without

[Discuss-gnuradio] importing usrp2 module failing

Hi all, I installed GNU Radio via the Ubuntu package first, and when trying to run usrp2_probe, i got the error "ImportError: cannot import name usrp2" ... so then I tried a manual install from the latest git, and I still get that same error. I have confirmed that gnuradio exists in: /usr/local/l

Re: [Discuss-gnuradio] MAC layer development and USRP2

On Wed, Apr 7, 2010 at 4:54 PM, Per Zetterberg wrote: > Dear All, > > Regarding MAC layer development I would like to empasize on the importance > of time-stamps. With time-stamps we can at least do slotted schemes. Maybe > non-slotted schemes can be approximated by slotted ones ? > Hi Per, I'm

Re: [Discuss-gnuradio] MAC layer development and USRP2

Hi Veljko, > What I got from your paper is that the matched filter approach for > fast packet detection would not work in an OFDM setting. What about > fast ACK generation? Would it require an IFFT implementation on the > USRP? Would it help much? > It's a good question, and something I haven't

Re: [Discuss-gnuradio] MAC layer development and USRP2

PS. if you haven't seen, SORA is able to interoperate with 802.11g, which is impressive. It meets all of the timing requirements. However, it does not come with the exact ease of programming that we're familiar with. They do have to push the use of SSE and tradeoff a lot of computation for memo

Re: [Discuss-gnuradio] MAC layer development and USRP2

> > Did you see my previous post about the accelerator PCIe card? To some > extent the Microsoft approach is what we're > doing. But we want to stay compatible with USRP2 hardware so we connect > GbE to the accelerator card; non MAC-related > dataflow is PCIe from there. Buffering required to st

  1   2   3   4   5   6   >