[Discuss-gnuradio] Read/Write stream tags in Python

Hello all, I've been trying to work with stream tags in python, mainly using the grextras blocks coding guide here:https://github.com/guruofquality/grextras/wiki/Blo... . I've set up a very simple flow graph

Re: [Discuss-gnuradio] Read/Write stream tags in Python

> On 07/13/2012 08:51 AM, Anisha Gorur wrote: > > Hello all, > > I've been trying to work with stream tags in python, mainly using the > > grextras blocks coding guide > > here:https://github.com/guruofquality/grextras/wiki/Blo... > > < > https://github.c

Re: [Discuss-gnuradio] Read/Write stream tags in Python

helpful. I also had one more quick question, I'm getting this error: 'gr_top_block_sptr' object has no attribute 'add_item_tag', though I thought add_item_tag was inherited from gr_block. Thanks again! On Fri, Jul 13, 2012 at 2:40 PM, Josh Blum wrote: > > > On 07/13

Re: [Discuss-gnuradio] Read/Write stream tags in Python

at 3:25 PM, Josh Blum wrote: > > > On 07/13/2012 12:08 PM, Anisha Gorur wrote: > > Thanks for the examples, I will definitely be looking into them! > > As for links, This one: http://gnuradio.org/cgit/jblum.git/log/?h=nextis > > broken, it comes from one of the block

Re: [Discuss-gnuradio] Read/Write stream tags in Python

Also, I've been assuming that nitems_written/read is from gr_block_detail, and add_item_tag is from gr_block and that they have both been swigged, since you used them in your example. Is it possible that they haven't been? Thanks -Anisha On Fri, Jul 13, 2012 at 3:57 PM, Anisha Gorur w

Re: [Discuss-gnuradio] Read/Write stream tags in Python

at "make test" passed for you :-) > > -josh > > On 07/13/2012 01:20 PM, Anisha Gorur wrote: > > Also, I've been assuming that nitems_written/read is from > gr_block_detail, > > and add_item_tag is from gr_block and that they have both been swigged, &g

[Discuss-gnuradio] Creating a signal source block using Python

Hello All, I've been attempting to create my own source block in Python. I have been reading the blocks coding guide here: https://github.com/guruofquality/grextras/wiki/Blocks-Coding-Guide#wiki-work-operation-modes, but so far my source only outputs zeros. An outline of my code is as follows: cl

Re: [Discuss-gnuradio] Creating a signal source block using Python

ul 19, 2012 at 3:47 AM, Martin Braun (CEL) wrote: > On Wed, Jul 18, 2012 at 02:32:28PM -0400, Anisha Gorur wrote: > > I then write my constSource block to a file and I try to see the output > of the > > file using a scope sink, but it is just a constant stream of zeros. Am I &g

Re: [Discuss-gnuradio] Creating a signal source block using Python

012 11:32 AM, Anisha Gorur wrote: > > Hello All, > > > > I've been attempting to create my own source block in Python. I have been > > reading the blocks coding guide here: > > > https://github.com/guruofquality/grextras/wiki/Blocks-Coding-Guide#wiki-work-op

Re: [Discuss-gnuradio] Creating a signal source block using Python

Sorry, just to clarify, I get that error unless I fill output_items completely, no matter the length of x. Thanks, Anisha On Thu, Jul 19, 2012 at 3:00 PM, Anisha Gorur wrote: > I was trying that earlier, however, I get this error from my code >output_items[0][:] = x #where x eq

Re: [Discuss-gnuradio] Creating a signal source block using Python

On 07/19/2012 11:28 AM, Anisha Gorur wrote: > > It works now, thanks! It was a combination of a couple dumb errors on my > > part. One last thing, I was wondering if there was a way to change the > > length of output_items[0]? It is 4096 by default I believe. > > Thanks,

Re: [Discuss-gnuradio] Creating a signal source block using Python

at 2:44 PM, Josh Blum > j...@ettus.com>> wrote: >> >> >> >> On 07/19/2012 11:28 AM, Anisha Gorur wrote: >> > It works now, thanks! It was a combination of a couple dumb >> errors on my >> > part. One last thing, I was wonderi

[Discuss-gnuradio] preload a signal onto USRP

Hello All, I have a bit of a strange question. Is it possible to somehow preload a signal (it would be periodic) onto a USRP so that I would only have to send a signal saying "begin transmit", and it would do so, without sending anything besides the "begin transmit" message over the Ethernet cable?

Re: [Discuss-gnuradio] preload a signal onto USRP

e FPGA, > depending on how much in the way of resources are left unused. It would be > much more work than the file source method mentioned earlier. Why do you > want it preloaded? Low latency? > > -R C > > On Tue, Aug 7, 2012 at 4:38 PM, Anisha Gorur wrote: > >> Hel

[Discuss-gnuradio] LLLL error printout

Hello, Very quick question, I'm trying to transmit a signal that I have created, and in the console output at the beginning of the transmission, I get this printout: LL. The error is not continuous, it stops after about 10 L's. What does this mean? Thanks, -Anisha __

[Discuss-gnuradio] FPGA time

Hello, We've been having some trouble with the synchronizing aspects of our project. What we want is the exact same time as the FPGA tick counter, not a time_spec_t representation of time. Where can we get access to that? Thanks! -Anisha ___ Discuss-gnura

Re: [Discuss-gnuradio] FPGA time

s set as when either way, supposedly the internal GPSDO is being used. Thanks, On Tue, Aug 28, 2012 at 4:13 PM, Josh Blum wrote: > > > On 08/28/2012 12:03 PM, Anisha Gorur wrote: > > Hello, > > We've been having some trouble with the synchronizing aspects of our > &g

Re: [Discuss-gnuradio] FPGA time

, 2012 at 5:40 PM, Josh Blum wrote: > > > On 08/28/2012 01:39 PM, Anisha Gorur wrote: > > Thats actually what we are using, however, when printing out the tick > > count, we randomly, and only sometimes, see a jump of about 30 ticks, and > > if each tick is 10ns, that is a h

Re: [Discuss-gnuradio] FPGA time

____ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Anisha Gorur Class of 2012 Electrical Engineering ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] 2 complex receive channels on usrp n210

Hello All, I know that on the USRP1, it was possible to have four seperate RX channels, and therefore receive two pairs of IQ samples. I was wondering if there were any way to do this on a USRP N210, using a basic RX daughterboard, even by possible changing the FPGA code, or it you could only have

Re: [Discuss-gnuradio] 2 complex receive channels on usrp n210

Great! So if i selected 0:A and 0:B as multiple subdevices, I would receive something like I0, Q0 and I1, Q1? On Wed, Sep 19, 2012 at 12:45 PM, Josh Blum wrote: > > > On 09/19/2012 10:44 AM, Anisha Gorur wrote: > > Hello All, > > > > I know that on the USRP1, i

Re: [Discuss-gnuradio] 2 complex receive channels on usrp n210

signal on antenna RXB * **Frontend AB:** quadrature frontend using both antennas (IQ) * **Frontend BA:** quadrature frontend using both antennas (QI) So choosing A and B as the subdevice specs would give me two real signals, correct? On Wed, Sep 19, 2012 at 2:58 PM, Anisha Gorur wrote: > Great!

Re: [Discuss-gnuradio] 2 complex receive channels on usrp n210

A:A and A:B, should I change those? On Wed, Sep 19, 2012 at 6:50 PM, Josh Blum wrote: > > > On 09/19/2012 04:54 PM, Anisha Gorur wrote: > > I tried this out, and I am getting two real signals, while I want two > > complex signals. From dboards.rst: > > > > ^^^

[Discuss-gnuradio] 8-channel receiver

I have a quick theoretical question. Is there any way to construct an 8-channel receiver using 4 USRPS without data going through the host computer? Basically some kind of way to daisy chain mimo cables (though I know this is not possible), or at least get the same benefits you would receive from d

Re: [Discuss-gnuradio] 8-channel receiver

Clarification: This would be using USRP N210, not USRP1, where I know it is possible to have an 8 channel receive or transmit only using a mimo cable. On Wed, Sep 26, 2012 at 12:38 PM, Anisha Gorur wrote: > I have a quick theoretical question. Is there any way to construct an > 8-c

[Discuss-gnuradio] Can another DUC chain be added to USRP N210?

Hello All, I am using a USRP N210. When i set the subdev spec for my basic RX daughterboard as "A:A A:B" I can receive two channels. However, if I try to do something similar for the basic TX I get an error like "The user specified 2 channels, but there are only 1 tx dsps on mboard 0." I assume th

Re: [Discuss-gnuradio] 8-channel receiver

ep 27, 2012 at 12:04 AM, Matt Ettus wrote: > >> You can use a gigabit ethernet switch and put all the USRPs on there. >> You should be able to make USRPs send data to each other. You will of >> course need to do work to get your algorithms into the FPGA. >> >

Re: [Discuss-gnuradio] Can another DUC chain be added to USRP N210?

generally, what kind of modification would be necessary? Thanks for your time! -Anisha On Fri, Sep 28, 2012 at 6:36 PM, Josh Blum wrote: > > > On 09/28/2012 08:49 AM, Anisha Gorur wrote: > > Hello All, > > > > I am using a USRP N210. When i set the subdev spec for my basic R

Re: [Discuss-gnuradio] 8-channel receiver

ovement in latency do you usually see? Again, thank you so much. -Anisha On Fri, Sep 28, 2012 at 6:57 PM, Josh Blum wrote: > > > On 09/28/2012 02:46 PM, Anisha Gorur wrote: > > Thanks Matt! > > Do you have any idea for what kind of latency we would expect? Also would >

Re: [Discuss-gnuradio] Can another DUC chain be added to USRP N210?

Thank you very much for your help Josh! I'll let you know if we end up going this way in our design. On Sun, Sep 30, 2012 at 7:01 PM, Josh Blum wrote: > > > On 09/29/2012 09:45 AM, Anisha Gorur wrote: > > Thanks Josh, > > What I am looking for on the TX side of th

Re: [Discuss-gnuradio] 8-channel receiver

Thank you very much again! On Sun, Sep 30, 2012 at 6:22 PM, Josh Blum wrote: > > > On 09/29/2012 09:46 AM, Anisha Gorur wrote: > > Thanks Josh, that helps quite a bit! Our sampling frequency is not > > particularly fast, it will only be around 5 MS/S. Right now the send

[Discuss-gnuradio] preload tx buffer on USRP N210

Hey All, I was wondering if there was a way to preload samples onto the FIFO buffer on the FPGA, so that I could theoretically loop through those samples and keep transmitting them? The idea was mentioned in this thread: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-October/0055