Re: [Discuss-gnuradio] GPIO setting on USRP N200 with LFTX plugged + UHD
On 09/26/11, Josh Blum wrote: > > With gr-uhd you can call into the dboard iface from python. That > includes USRP1 and N200. > > This is the dboard iface: > http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1dboard__iface.html > > -Josh Thank you so much for your reply, Josh. I will try this method to configure the I/O pins on dboard. I am wondering if there is any examples in GNU Radio involved the GPIO configuration? I would love to ensure the method I try is correct, as illustrated on GNU Radio website, any inappropriate operation on GPIO would damage the board. Really appreciate your help! Thanks, Yan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] benchmark_tx/rx for UHD
On Mon, Sep 26, 2011 at 10:36 PM, wrote: > Hi, all > > I would like to transmit the modulated ( by gmsk, dqpsk, dbpsk) signals > by using USRP N210 + WBX. > > > Are there any benchmark_tx/rx programs > which is supporting UHD and > is similar to gnuradio/examples/digital/benchmark_tx/rx.py. > > > I tried the Tom's branch(gr-digital), > >https://github.com/trondeau/gnuradio/tree/digital/gr-digital/examples > But these program couldn't transmit and receive the signals. > > > > Regards, youhei > Working on it... Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] benchmark_tx/rx for UHD
Hi, all I would like to transmit the modulated ( by gmsk, dqpsk, dbpsk) signals by using USRP N210 + WBX. Are there any benchmark_tx/rx programs which is supporting UHD and is similar to gnuradio/examples/digital/benchmark_tx/rx.py. I tried the Tom's branch(gr-digital), >https://github.com/trondeau/gnuradio/tree/digital/gr-digital/examples But these program couldn't transmit and receive the signals. Regards, youhei ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GPIO setting on USRP N200 with LFTX plugged + UHD
On 09/26/2011 02:32 PM, Yan Nie wrote: > Dear all, > > I am using USRP N200 with LFTX and LFRX plugged + UHD to design a > transmitter and a receiver. I am trying to toggle a GPIO pin high > when the LFTX board is transmitting and low otherwise, which is > similar to the io_tx_06 pin on RFX boards. > > From what I found, this I/O pin could be configured by _write_oe (int > which_dboard, int value, int mask) for USRP1, though did not how to > use write_gpio in an appropriate way in python. Any suggestion on the > implementation of functionality above would be really appreciated! > > > Have a great day! > With gr-uhd you can call into the dboard iface from python. That includes USRP1 and N200. This is the dboard iface: http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1dboard__iface.html -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GPIO setting on USRP N200 with LFTX plugged + UHD
Dear all, I am using USRP N200 with LFTX and LFRX plugged + UHD to design a transmitter and a receiver. I am trying to toggle a GPIO pin high when the LFTX board is transmitting and low otherwise, which is similar to the io_tx_06 pin on RFX boards. >From what I found, this I/O pin could be configured by _write_oe (int >which_dboard, int value, int mask) for USRP1, though did not how to use >write_gpio in an appropriate way in python. Any suggestion on the >implementation of functionality above would be really appreciated! Have a great day! Thanks, Yan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synchronization between two E100 devices
Hi Nick, Thanks for your reply. In my application, a microsecond-order accuracy will be enough for the synchronization right now. But I didn't manage to issue set_time_now() to the other usrp because it seems only the usrp of the host device is accessible. So I was wondering if there is a way to access another e100 from the host device? Thanks, Terry On 09/26/2011 05:52 PM, ziyang wrote: Hi everyone, I'm trying to synchronize two E100 devices, both connecting to the ethernet. According to the Synchronization Application Notes of UHD, there are a couple of methods to do it. But the problem is that I don't have access to either an external GPSDO or a reference clock signal. I tried to access both devices by providing the IP address of uhd_usrp_source/sink, then set the time of them using the set_time_now() method. But it turned out that another m'board is not accessible to the host device. So I was wondering, under this circumstances, is there a way to synchronize the device time of two E100s? Thanks in advance, Terry ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] making gnuradio blocks entirely in python
On 09/26/2011 09:22 AM, Johnathan Corgan wrote: > On Mon, Sep 26, 2011 at 09:05, Josh Blum wrote: > >> The implementation is relying on a hairy thing like swig directors. >> Shiver... > > We've had mixed results with swig directors in the past. The bigger > issue here, though is the Python global interpreter lock. This is > released by the GNU Radio runtime in top_block.start() and > top_block.run() so that the Python calling thread can proceed after > GNU Radio kicks off the flowgraph threads. > > When calling back up to Python, that lock has to be re-acquired, and > all other Python threads in operation (including GUI threads for > wxPython and QTGui) will block waiting for it to be released. > > So while this would work in theory, it could create a nasty coupling > in application performance between signal processing code and GUI > code, and possibly even deadlocks if the non-GNU Radio Python code > needed to interact with the Python block. > > Fortunately, you've done this in a way that can be tested without any > modifications to GNU Radio, so we can get some empirical results. > > I think a more useful area for C++->Python communication is to make it > *easy* for a GNU Radio block to notify a Python object that something > has happened, possibly with data attached. > > For example, in the uhd_fft.py and other GUI programs that use the fft > sink, we have to end the GNU Radio flowgraph proper in a message > sink/message queue, and then have a Python thread run this queue for > entries, process them, then post the processed FFT frames to > wxPython's GUI thread. This is not only inefficient, but hard to > generalize from or even just learn from by inspection. I created the > gru.msgq_runner class to help this, but it's still a hack. > > So a mechanism that takes an arbitrary pmt on the GNU Radio C++ end > and results in a function call to a Python bare function or class > method with that pmt as the argument would create a generic method to > pass events of all sorts up from the "data plane" portion of the app > to the "control plane", non-GNU Radio code. > > So a little bit about the implementation I used: The communication between pyblock_gateway.cc and python is actually message based. When I made the announcement, the implementation used a python thread to block on a call, get a message, and dispatch work. This worked, but I was kind of annoyed dealing with the python thread and getting it to exit. And its definitely more ideal to have the scheduler call directly into this python work(). So last night I changed the implementation to use a SWIG director. So the python handler is called to read the message and dispatch work. - In the case of the thread implementation, you need to take the GIL locking into account. Basically, I did the same thing as the message queue blocking calls. - In the case of the director, the GIL locking also has to be taking into account. So, I grabbed the GIL locker implementation from gr_feval. So basically, any implementation has to deal with unlocking the GIL properly. I would like to see how well this current implementation works for people. I think its the right way to do it, but SWIG directors still seem like black magic so I am less trustworthy of them. I will add a throw exception when the default handler gets called (means something about directors didnt build right on your machine). _josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Synchronization between two E100 devices
On Mon, Sep 26, 2011 at 8:52 AM, ziyang wrote: > Hi everyone, > > I'm trying to synchronize two E100 devices, both connecting to the ethernet. > According to the Synchronization Application Notes of UHD, there are a > couple of methods to do it. But the problem is that I don't have access to > either an external GPSDO or a reference clock signal. > > I tried to access both devices by providing the IP address of > uhd_usrp_source/sink, then set the time of them using the set_time_now() > method. But it turned out that another m'board is not accessible to the host > device. > > So I was wondering, under this circumstances, is there a way to synchronize > the device time of two E100s? If you need them to be truly synchronized, then the only way to do it is by distributing an accurate PPS and 10MHz reference to them. Issuing set_time_now() "simultaneously" to two devices will get you within some microseconds, but not synchronize them at the sample level. --n > > Thanks in advance, > > Terry > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-atsc module transmit questions
I have converted atsc_field_sync_mux to type gr_block and added atsc_symbol_mapper and atsc_weaver_mod_head. The rest can be done using existing GR blocks; I don't frequency translate the signal away from complex baseband (see 3 below): [atsc stuff] => [float_to_complex] => [fir_filter_ccf] => [pfb_arb_resampler_ccf] => [file sink] I have a couple more questions: 3) Is there a reason the weaver_mod_tail module was introduced as opposed to the output being complex baseband (-3 MHz to 3 MHz)? I could combine some of the other blocks with frequency translation to mimmic what was GrAtscWeaverModTail but im not sure that is the idea here. 4) What is the purpose of the atsci_x functions as opposed to atsc_x? Thanks, I'll get this cleaned up and documented and submit it. Jacob On Mon, Sep 26, 2011 at 8:56 AM, Tom Rondeau wrote: > On Sat, Sep 24, 2011 at 10:40 AM, Jay Jones wrote: > >> Hi, >> >> I am relatively new to gnuradio block-level development and am working >> with the gr-atsc module. I am specifically interested in the transmit >> portion and have a few [likely elementary] questions: >> >> 1) From what I can see the transmit functionality is only implemented up >> to the atsc_field_sync_mux(), I don't see the symbol mapping or VSB >> modulation though I have read a few other posts that suggest it is there. >> The gnuradio 0.9 has GrAtscWeaverModHead and GrAtscWeaverModTail header >> files but maybe these did not get modified into gr 3.x. >> > > Well, the atsc receive functionality hasn't worked properly for some time. > It's been on my todo list for ages, but I haven't gotten there, yet, so if > you are working on it and can fix it up, that would be great! > > So having said that, no, I don't think all of the pieces to make an atsc > transmitter are there, either. So I don't think you are wasting your time or > far off track. > > >> 2) The atsc_field_sync_mux block is derived from gr_sync_block however it >> outputs more data fields than it consumes (by a factor of 313/312). Even >> though this seems to work, for my own benefit I re-did this as a gr_block >> but I am not sure if that is necessary; could someone shed some light on why >> gr_sync_block works (or appears to but doesn't)? >> >> Thanks for your time, JJ >> > > Yes, if the block is outputting 313 and consuming 312 items, then it's not > a sync block, so it sounds like you are doing the right thing. Being off by > that small amount will have an effect, but my guess is that it was minimal. > Maybe a blip or overwriting a value or two here and there. So it was > probably that the problem wasn't noticeable but present. > > Let us know how you're getting along with it. > > Tom > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] making gnuradio blocks entirely in python
On Mon, Sep 26, 2011 at 09:05, Josh Blum wrote: > The implementation is relying on a hairy thing like swig directors. > Shiver... We've had mixed results with swig directors in the past. The bigger issue here, though is the Python global interpreter lock. This is released by the GNU Radio runtime in top_block.start() and top_block.run() so that the Python calling thread can proceed after GNU Radio kicks off the flowgraph threads. When calling back up to Python, that lock has to be re-acquired, and all other Python threads in operation (including GUI threads for wxPython and QTGui) will block waiting for it to be released. So while this would work in theory, it could create a nasty coupling in application performance between signal processing code and GUI code, and possibly even deadlocks if the non-GNU Radio Python code needed to interact with the Python block. Fortunately, you've done this in a way that can be tested without any modifications to GNU Radio, so we can get some empirical results. I think a more useful area for C++->Python communication is to make it *easy* for a GNU Radio block to notify a Python object that something has happened, possibly with data attached. For example, in the uhd_fft.py and other GUI programs that use the fft sink, we have to end the GNU Radio flowgraph proper in a message sink/message queue, and then have a Python thread run this queue for entries, process them, then post the processed FFT frames to wxPython's GUI thread. This is not only inefficient, but hard to generalize from or even just learn from by inspection. I created the gru.msgq_runner class to help this, but it's still a hack. So a mechanism that takes an arbitrary pmt on the GNU Radio C++ end and results in a function call to a Python bare function or class method with that pmt as the argument would create a generic method to pass events of all sorts up from the "data plane" portion of the app to the "control plane", non-GNU Radio code. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] making gnuradio blocks entirely in python
> > Now, here's the question. Do we keep this as a separate project or put it > into GNU Radio proper? > Id like it too see more testing. But I hope to get it in gnuradio. The implementation is relying on a hairy thing like swig directors. Shiver... > If you want to keep it separate and on github, we could at least clone it on > gnuradio.org and have a redmine projects page for it. Or even just a link if > you don't want to worry about updating and supporting the redmine interface > and feel that github gives you everything you need. > I thought we were transitioning to github so I dont even know anymore. > On the other hand, part of me doesn't want it in GNU Radio because I don't > want people to start using it as the default way of doing things, > specifically, that they don't start with a pyblock and never move it into a > proper C++ block. In my experience with numpy (and scipy), they are great > interfaces and they are faster than using Python, but they are still much > slower than they could/should be. So we shouldn't be relying on Python-level > stuff for real implementations. > All the tag qa code could be in python. That could make a developers life easier. Id like to point out that the adder implemented w/ numpy could be performing arithmetic faster because thats vectorized and until we use volk, the adder in gnuradio C++ is not. The real overhead probably comes from the memory allocations that happen going between python and C++ and making python objects. I havent benchmarked it, but I am guessing its non-trivial. > On the other hand (I think I've run out of hands...), this also goes a long > way to solving the problem of people wanting a Matlab interface system. If > you could work in using Matplotlib into your examples, people might see how > much they can do in Python that replicates/replaces/supersedes Matlab for > these purposes. > > Again, great stuff. Let us know how you want to continue to support it. > Yes: I want to support proper message passing. I noticed that I can register a message handler to receive messages. Can you point me to how messages are produced? I really hate gr_tag_info.h. I would rather get_tags_in_range filled a vector of type tag_type, where tag_type has methods like .get_key(), .get_value(), etc... Basically im complaining that we didnt use object orientedness here when its realy well suited for it. You will see that I did this wrap-around in my pyblock_gateway so I didnt have to swig tag_info. See the tags_demo.py to see how I used it. _josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] error compiling 3.4.1 on ubuntu maverick (2)
On Mon, Sep 26, 2011 at 06:41, Tom Rondeau wrote: > On Mon, Sep 26, 2011 at 9:02 AM, Arturo Rinaldi wrote: >> >> i attached the configure and the make log of the stdout on Ubuntu >> Maverick. If i disable the "volk" module the building goes smoothly : >> >> ./configure --disable-volk >> make >> make check >> >> thx in advance, Arturo. > > I hate to be that guy, but it would really help us if your logs were in > English :) The error in question is the equivalent of "No rule to make the target 'all' ". It looks like the generated Makefile in the volk directory is broken somehow. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Synchronization between two E100 devices
Hi everyone, I'm trying to synchronize two E100 devices, both connecting to the ethernet. According to the Synchronization Application Notes of UHD, there are a couple of methods to do it. But the problem is that I don't have access to either an external GPSDO or a reference clock signal. I tried to access both devices by providing the IP address of uhd_usrp_source/sink, then set the time of them using the set_time_now() method. But it turned out that another m'board is not accessible to the host device. So I was wondering, under this circumstances, is there a way to synchronize the device time of two E100s? Thanks in advance, Terry ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio component directory structure
On Mon, Sep 26, 2011 at 11:48 AM, Ben Hilburn wrote: > Restarting the discussion for a small point: > > > 1) It separates publicly installed headers vs private headers in the lib > > directory. > > I think this, honestly, is the best argument for having the separate > directory. In terms of project navigation, I think this is really helpful, > and makes sense. > > > > 2) Its a cleaner separation of API and implementation. > > > 3) Its easier to point doxygen to the public headers and keep it from > > parsing everything in "lib". > > This is the point I wanted to comment on. I've worked on a number of > projects that point Doxygen only to include/, and projects that point to > both include/ and lib/. Honestly, and while this is obviously highly > subjective and easily swapped back and forth for anyone that cares, I > actually prefer including the lib/ directory as well. There is usually a > whole lot of stuff in the the implementation files that aren't declared in > the headers, and a lot of it is usually extremely helpful (at least to me) > when I'm hacking around. > > Again, this is obviously preference. If you only want Doxygen to document > the public GNURadio API, then obviously you only want to point it to > include. For actually developing _inside_ of GNURadio, however, I often > find having the lib/ documentation to be very helpful. > > Cheers, > Ben > I agree with everything you've said here. I think we'll be including both. There's some maintenance work on Doxygen that I need to sort out soon, so making sure we're picking up everything that we want is going to be part of it. Thanks, Tom > On Mon, Sep 26, 2011 at 5:10 AM, Tom Rondeau wrote: > >> On Mon, Sep 26, 2011 at 3:39 AM, Martin Braun wrote: >> >>> On Wed, Sep 21, 2011 at 10:04:23AM -0400, Tom Rondeau wrote: >>> > On Sat, Sep 17, 2011 at 3:14 PM, Martin Braun >>> wrote: >>> > >>> > I'd like to point out a disadvantage to get a discussion going: >>> > While you're developing, this might be an inconvenience because the >>> > files are physically separated. Most IDEs/editors have many >>> features >>> > such as tagging, switching from headers to sources and vice versa, >>> 'go >>> > to file at cursor' commands etc. If half of the files are somewhere >>> > else, one has to set up the editor specifically for this dir >>> structure >>> > to do all of this. >>> > >>> > >>> > It's a logical separation that a lot of projects use. I know that I'm a >>> bit >>> > biased because my "IDE" is Emacs, but I don't recall having project >>> files in >>> > different directories was a problem. Way back when I developed in >>> Windows and >>> > used Visual Studio, this wasn't an issue, but that could have been due >>> to the >>> > project file that VS kept. >>> > >>> > >>> > We haven't made it part of our official standard, but talking with both >>> > Johnathan and Josh last week about it, I was thinking that we would. >>> I'm not >>> > sure that your argument here has quite convinced me that it'll be a >>> problem. >>> >>> To be honest, >>> >>> after re-reading this, I'm not even convinced myself. >>> Sometimes I just like to argue :) >>> >>> Martin >> >> >> Always good to have the discussion. I think we're settled on the use of >> include directory, then. >> >> Thanks! >> Tom >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sine output between packets
On Mon, Sep 26, 2011 at 05:36, Tom Rondeau wrote: > On Sun, Sep 25, 2011 at 8:07 AM, Brett L. Trotter > wrote: >> >> It seems my old patch that zeroed out the output of the USRP didn't make >> it into UHD- we're seeing a constant sine output between packets- and in >> our case this messes with the receiver unless we use some custom TX >> cards that have an amp we can shut down with ATR. >> >> Is there any way to fix this? > > I've never noticed this with my work with the UHD. There are various > commands issued to the USRPs to turn it on and shut it off between bursts. > Maybe there's something missing in the gr-uhd. > On the other hand, Josh and Nick have been working on using tags with gr-uhd > on the transmit side, which should fix your problem. > Any comments from the UHD folks? Brett, if you are using anything beside the BasicTX or LFTX, then it's also possible you are seeing LO feedthrough/DC offset in the transit mixer, which results in a carrier output between packets. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] making gnuradio blocks entirely in python
On Mon, Sep 26, 2011 at 05:24, Tom Rondeau wrote: > On the other hand (I think I've run out of hands...) ...that would be "on the gripping hand." (obscure SF reference of the week.) Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sine output between packets
On 09/26/2011 05:36 AM, Tom Rondeau wrote: > On Sun, Sep 25, 2011 at 8:07 AM, Brett L. Trotter wrote: > >> It seems my old patch that zeroed out the output of the USRP didn't make >> it into UHD- we're seeing a constant sine output between packets- and in >> our case this messes with the receiver unless we use some custom TX >> cards that have an amp we can shut down with ATR. >> >> Is there any way to fix this? >> > > I've never noticed this with my work with the UHD. There are various > commands issued to the USRPs to turn it on and shut it off between bursts. > Maybe there's something missing in the gr-uhd. > > On the other hand, Josh and Nick have been working on using tags with gr-uhd > on the transmit side, which should fix your problem. > > Any comments from the UHD folks? > The usrp1 shutdown mechanism in UHD is a little soft (because there is no inline metadata with the samples). However, if you mark end of burst, then the transmitter should get disabled. You can do this w/ tags using this branch: http://gnuradio.org/cgit/jblum.git/log/?h=mergme/uhd_tags_impl_on_master I would verify that the behavior w/ eob is OK for you on usrp1 by modifying some uhd (non gnuradio) examples before getting into tags. And BTW, I didnt know about this patch. The UHD usrp1 images match the gnuradio ones, so its definitely not in there: http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/4b5e1238492fe40727d19abefe22ae448c720419 It looks like the patch involves verilog changes. Is this an image that you can just build and drop in place of the existing one or does it need host code support? Have you tried it? -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Constant output message source
On Sun, Feb 27, 2011 at 6:22 PM, Tom Rondeau wrote:
> On Sat, Feb 19, 2011 at 4:52 AM, ichigo.san wrote:
>>
>> Hi,
>>
>> I was wondering if there is a method to have a source block constantly
>> sending out "0" and once it recieves a message from python, e.g a packet,
>> it
>> will then stream the message and switch back to sending "0" when done.
>>
>> I've tried:
>> Message Source > (Add, 0)
>> Constant Source/Vector Source with 0 -> (Add, 1) ---> output
>>
>> However, the add block (and all blocks in gnuradio) waits for stream items
>> from both inputs to be ready (i.e no interpolation) before making a output
>> stream item. This effectively nullifies the const source in the above
>> example.
>>
>> I was wondering if there is any possible way to solve this problem?
>>
>> The reason I am asking this is I am using a dual TX setup on a single USRP
>> which interleaves output signals. I have I output signal that is
>> constantly
>> sending (beacon) and one that is only sending sometimes, however the
>> interleaving of output signals means that both streams needs to be
>> constantly sending.
>
> Right, the add block needs to see items from both streams so that it can add
> them together. If there is no data on one stream, there is nothing to add
> and it does not assume zeros.
> My advice is to make a new block. The easiest would probably to make a new
> add block that inherits from gr_block instead of gr_sync_block. In this
> block, you tests the length of both inputs and add which items together that
> you want, substituting zeros when there is no more data on the incoming
> message stream. It will be pretty specific to your needs, and be careful
> with your consume() and return item numbers to account for what you've done
> with both streams.
> Tom
I tried to implement this. Instead of obeying noutput_items, my
general_work function takes the maximum in ninput_items[] and produces
that quantity instead:
--8<-
//declare in_f_xxx from input_items[xxx]
int num_out = std::max(ninput_items[0], ninput_items[1]);
for (int i = 0; i < num_out; i++) {
float acc = 0;
if (ninput_items[0] > i) acc += in_f_0[i];
if (ninput_items[1] > i) acc += in_f_1[i];
*optr++ = (float) acc;
}
consume(0, std::min(ninput_items[0], num_out));
consume(1, std::min(ninput_items[1], num_out)); //probably
consume(1,num_out), but if port1 is constant 0 it shouldnt matter
produce(0, num_out);
return WORK_CALLED_PRODUCE;
--8<-
I also implemented forecast() requiring only the second input to have samples:
ninput_items_required[1] = noutput_items;
However, the logic still seems incorrect and I couldn't write a
meaningful test code with a small number of samples and a
gr_message_source block. There seems to be some kind of race condition
on the thread running this which allows it to write a bunch of zeroes
even when there are samples in the first input port.
My interest in this is in writing a PHY simulator. I have a channel
whose impulse response includes the propagation time and my
understanding so far is that the convolution tail of the FIR filter
was being "cut off" since there were no more incoming samples from the
message stream. Because of that, the last symbol was always
incomplete, so I figured this non-blocking adder would help me get the
tail out of the channel memory.
If anyone has suggestions for this I would be happy to read.
--
Igor Almeida
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Wiki Access
On Mon, Sep 26, 2011 at 9:40 AM, Robert McGwier wrote: > I don't know you seem pretty malicious to me > > ;-) > I've been fooling everyone for years! Really, I'm just that stupid :) Martin, You are set up as a reporter for the GNU Radio project and can now edit the wiki. Tom > On Mon, Sep 26, 2011 at 9:37 AM, Tom Rondeau wrote: > >> On Mon, Sep 26, 2011 at 9:08 AM, Martin Braun wrote: >> >>> Hi, >>> >>> I just created an account (mbraun) on the wiki website, and found >>> out I can't edit pages with that. I guess the Wiki's configured to >>> not allow new accounts, but isn't that a bit pointless given that >>> everyone can use the 'guest' account anyway? >>> >>> MB >>> >> >> "Never attribute to *malice* that which is adequately explained by * >> stupidity."* >> >> I need to see if I can set up the redmine access to automatically assign a >> default permission to a project. Yes, you should be signed up as a >> "reporter" to the GNU Radio project page when you get an account. >> >> Tom >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > -- > Bob McGwier > ARS: N4HY > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Wiki Access
I don't know you seem pretty malicious to me ;-) On Mon, Sep 26, 2011 at 9:37 AM, Tom Rondeau wrote: > On Mon, Sep 26, 2011 at 9:08 AM, Martin Braun wrote: > >> Hi, >> >> I just created an account (mbraun) on the wiki website, and found >> out I can't edit pages with that. I guess the Wiki's configured to >> not allow new accounts, but isn't that a bit pointless given that >> everyone can use the 'guest' account anyway? >> >> MB >> > > "Never attribute to *malice* that which is adequately explained by * > stupidity."* > > I need to see if I can set up the redmine access to automatically assign a > default permission to a project. Yes, you should be signed up as a > "reporter" to the GNU Radio project page when you get an account. > > Tom > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Bob McGwier ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] error compiling 3.4.1 on ubuntu maverick (2)
On Mon, Sep 26, 2011 at 9:02 AM, Arturo Rinaldi wrote: > i attached the configure and the make log of the stdout on Ubuntu Maverick. > If i disable the "volk" module the building goes smoothly : > > ./configure --disable-volk > make > make check > > thx in advance, Arturo. > I hate to be that guy, but it would really help us if your logs were in English :) We had an issue with Volk on 32-bit architectures before, but I thought we fixed them a while ago. Guess we'll have to relook at it. Anyone else using 32-bit Ubuntu having problems? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Wiki Access
On Mon, Sep 26, 2011 at 9:08 AM, Martin Braun wrote: > Hi, > > I just created an account (mbraun) on the wiki website, and found > out I can't edit pages with that. I guess the Wiki's configured to > not allow new accounts, but isn't that a bit pointless given that > everyone can use the 'guest' account anyway? > > MB > "Never attribute to *malice* that which is adequately explained by * stupidity."* I need to see if I can set up the redmine access to automatically assign a default permission to a project. Yes, you should be signed up as a "reporter" to the GNU Radio project page when you get an account. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM Implementation
Hey Marcus this was very very informative.This offset was really killing me every time when I was running the OFDM example.I think I need to order some GPSDO :) Marcus D. Leech wrote: > > On 09/09/2011 07:26 PM, Tuan (Johnny) Ta wrote: >> As far as I know there's no open source code for an OFDM transceiver >> available. I was trying to build one half a year back but wasn't >> successful before I had to move on to something else. The >> benchmark_ofdm code will give you a simplex OFDM system. Ie you can >> run the transmitter on 1 USRP and receiver on another. >> >> Ie. run this on 1 USRP >> ./benchmark_ofdm_tx.py -f 2.412G >> >> And this on the other >> ./benchmark_ofdm_rx.py -f 2.412G >> >> The value of the frequency depends on the daughterboards you're using. >> If you're using USRP1 make sure the decimation rate is 1/2 of the >> interpolation rate as the ADC is 2 times faster than the DAC on the >> USRP1 (or the other way around, you should chek that). > The DAC on the USRP1 runs at twice the rate of the ADC. > >> >> Watch out for the frequency offset, it killed the system for me. If >> the above doesn't work, run the transmitter on 1 USRP and usrp_fft.py >> on the other. Check the center frequency of the FFT plot and manually >> adjust the receiver center frequency. I used the RFX2400 boards and >> the offset for me was ~ 40kHz. >> >> > Frequency offset comes up a lot on this list. It's usually in the > context of someone who has up to this point in their DSP/SDR "career" >only been dealing with baseband signals inside a simulation > environment--and environment that doesn't always adequately reflect >what you'll experience in real-world systems, and real-world channels. > > RF synthesizers are only as good as their reference clock. The > reference clocks on most garden variety RF platforms are usually of >good-to-excellent quality. But they may still have residual errors > of a few 10s of PPM. So that means for every MHz of frequency, >the absolute, actual frequency could be "off" by a few 10s of Hz. > Multiply that up to typical channel frequencies for many experiments >in the modern communications domain of 1 to 3GHz or even higher, and > you can easily end up with 10s of Khz of absolute frequency offset, >and this applies to both the transmitter and receiver. > > In typical cellular phone systems like LTE, and GSM and the like, the > base-station transmitters typically have really good reference clocks-- >good to a few PPB--a local rubidium clock, or a GPSDO. The the > hand-helds typically have cheap local reference clocks, in order to meet >the grueling BOM cost requirements of typical consumer electronics. > > What that means is that the demodulation chain needs some mechanism to > deal with frequency offset, and provide feedback to "center" >the baseband signal--either by tweaking the RX hardware, or shifting > the baseband signal in software. But the example code that's floating >around is typically *not* a *complete* system in this regard. In > some sense, much of it was designed to work in the "fantasy" land of >the simulation environment, and may not work that well in the real > world. In some OFDM systems, for example, I understand that there >is often a "pilot" carrier against which one can correlate some kind > of sequence, and once you've found the most-strongly-correlated >"bin" in the OFDM "comb", you can use that to estimate the frequency > offset relative to the transmitter. Examples and simulations may or >may not have that covered. College-level programs in DSP and SDR may > or may not discuss that important "real world" detail. > > Physics, it turns out, is a harsh mistress... > > > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > - Sumit Kr. Research Assistant Communication Research center IIIT Hyderabad India -- View this message in context: http://old.nabble.com/OFDM-Implementation-tp32380874p32503942.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Wiki Access
Hi, I just created an account (mbraun) on the wiki website, and found out I can't edit pages with that. I guess the Wiki's configured to not allow new accounts, but isn't that a bit pointless given that everyone can use the 'guest' account anyway? 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 pgpbspYnhf8sn.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-atsc module transmit questions
On Sat, Sep 24, 2011 at 10:40 AM, Jay Jones wrote: > Hi, > > I am relatively new to gnuradio block-level development and am working with > the gr-atsc module. I am specifically interested in the transmit portion and > have a few [likely elementary] questions: > > 1) From what I can see the transmit functionality is only implemented up to > the atsc_field_sync_mux(), I don't see the symbol mapping or VSB modulation > though I have read a few other posts that suggest it is there. The gnuradio > 0.9 has GrAtscWeaverModHead and GrAtscWeaverModTail header files but maybe > these did not get modified into gr 3.x. > Well, the atsc receive functionality hasn't worked properly for some time. It's been on my todo list for ages, but I haven't gotten there, yet, so if you are working on it and can fix it up, that would be great! So having said that, no, I don't think all of the pieces to make an atsc transmitter are there, either. So I don't think you are wasting your time or far off track. > 2) The atsc_field_sync_mux block is derived from gr_sync_block however it > outputs more data fields than it consumes (by a factor of 313/312). Even > though this seems to work, for my own benefit I re-did this as a gr_block > but I am not sure if that is necessary; could someone shed some light on why > gr_sync_block works (or appears to but doesn't)? > > Thanks for your time, JJ > Yes, if the block is outputting 313 and consuming 312 items, then it's not a sync block, so it sounds like you are doing the right thing. Being off by that small amount will have an effect, but my guess is that it was minimal. Maybe a blip or overwriting a value or two here and there. So it was probably that the problem wasn't noticeable but present. Let us know how you're getting along with it. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sine output between packets
On Sun, Sep 25, 2011 at 8:07 AM, Brett L. Trotter wrote: > It seems my old patch that zeroed out the output of the USRP didn't make > it into UHD- we're seeing a constant sine output between packets- and in > our case this messes with the receiver unless we use some custom TX > cards that have an amp we can shut down with ATR. > > Is there any way to fix this? > I've never noticed this with my work with the UHD. There are various commands issued to the USRPs to turn it on and shut it off between bursts. Maybe there's something missing in the gr-uhd. On the other hand, Josh and Nick have been working on using tags with gr-uhd on the transmit side, which should fix your problem. Any comments from the UHD folks? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Usrp2+Wbx firmware issue
Because programs written for UHD and and raw ethernet drivers are not compatible with each other. usrp2_probe works only with raw ethernet drivers while uhd_find_devices works only when UHD is on your SD card. In case of UHD thing on your SD card the uhd_fft.py shd work fine. If you are using TVRX daughter board then only UHD support is there for it. What error messages are you getting. filomena wrote: > > > Hi , I'm Filomena . I'm trying to use the USRP2 + WBX on linux ubuntu > 11.04 but I have a problem! > > When I load the firmware " txrx_wbx_raw_eth_20100608.bin " and the fpga > "u2_rev3-20100603.bin"on the SDcard (via usrp2 card burner), I can > > find the device with the command "Usrp2_probe", but "uhd_find_devices" and > "uhd_usrp_probe" can't find it. > > Moreover, the devices doesn't answer if I try via ping (destination IP= > 192.168.10.2). > > Instead, if I use firmware and fpga downloaded from > http://files.ettus.com/uhd_releases/master_images/ (newer version),I can > > comunicate via ping with the device , "uhd_find_devices" and " > uhd_usrp_probe work correcty, but "usrp2_probe" fails. > > in both of these cases, when I try to run "uhd_fft.py", it doesn't work. > > There is a firmware version that can solve all these problems, or i have > to do any other procedures to make "uhd_fft.py" work correctly? > - Sumit Kr. Research Assistant Communication Research center IIIT Hyderabad India -- View this message in context: http://old.nabble.com/Usrp2%2BWbx-firmware-issue-tp32503804p32503938.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Usrp2+Wbx firmware issue
Because programs written for UHD and and raw ethernet drivers are not compatible with each other. usrp2_probe works only with raw ethernet drivers while uhd_find_devices works only when UHD is on your SD card. In case of UHD thing on your SD card the uhd_fft.py shd work fine. If you are using TVRX daughter board then only UHD support is there for it. What error messages are you getting. filomena wrote: > > > Hi , I'm Filomena . I'm trying to use the USRP2 + WBX on linux ubuntu > 11.04 but I have a problem! > > When I load the firmware " txrx_wbx_raw_eth_20100608.bin " and the fpga > "u2_rev3-20100603.bin"on the SDcard (via usrp2 card burner), I can > > find the device with the command "Usrp2_probe", but "uhd_find_devices" and > "uhd_usrp_probe" can't find it. > > Moreover, the devices doesn't answer if I try via ping (destination IP= > 192.168.10.2). > > Instead, if I use firmware and fpga downloaded from > http://files.ettus.com/uhd_releases/master_images/ (newer version),I can > > comunicate via ping with the device , "uhd_find_devices" and " > uhd_usrp_probe work correcty, but "usrp2_probe" fails. > > in both of these cases, when I try to run "uhd_fft.py", it doesn't work. > > There is a firmware version that can solve all these problems, or i have > to do any other procedures to make "uhd_fft.py" work correctly? > - Sumit Kr. Research Assistant Communication Research center IIIT Hyderabad India -- View this message in context: http://old.nabble.com/Usrp2%2BWbx-firmware-issue-tp32503804p32503937.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] making gnuradio blocks entirely in python
On Sun, Sep 25, 2011 at 10:58 PM, Josh Blum wrote:
> So there is a useful feature I think gnuradio is missing, and thats the
> ability to rapidly prototype signal processing in python. It would be
> great if a python block would have access to all the facilities
> available to a block written in a c++ environment.
>
> So I put together pyblock (not to be confused with those other project
> by the same name). Its a stand-alone build that links against gnuradio.
> https://github.com/guruofquality/pyblock
>
> Theres a few demos: an adder, using tags, interp and decim blocks.
> https://github.com/guruofquality/pyblock/tree/master/examples
>
> The interesting thing is that the work functions just call into numpy
> routines, so there is a chance that the implementations can be
> reasonably fast.
>
> I would like to be able to support history so i can implement a filter
> using numpy but I am a little lacking in the basic understanding so fill
> me in if you know. Suppose I have this work function:
>
> int work(int noutput_items, gr_vector_const_void_star
> &input_items,gr_vector_void_star &output_items){
> const float *in = reinterpret_cast(input_items[0]);
>
> I am assuming history is on the input buffer.
> Is the vector "in" ninput_items + history() items long? Where
> ninput_items = noutput_items*/some_factor.
> Whats the first index of the first item? Is in[0] or in[0-history()]?
>
> -Josh
>
Josh,
This is REALLY cool, thanks!
Now, here's the question. Do we keep this as a separate project or put it
into GNU Radio proper?
If you want to keep it separate and on github, we could at least clone it on
gnuradio.org and have a redmine projects page for it. Or even just a link if
you don't want to worry about updating and supporting the redmine interface
and feel that github gives you everything you need.
Part of me wants to put this into GNU Radio, just because it's a nice
feature for developers, especially those not comfortable developing code in
C++ going back and forth between GNU Radio and Python (which I've often done
in the past).
On the other hand, part of me doesn't want it in GNU Radio because I don't
want people to start using it as the default way of doing things,
specifically, that they don't start with a pyblock and never move it into a
proper C++ block. In my experience with numpy (and scipy), they are great
interfaces and they are faster than using Python, but they are still much
slower than they could/should be. So we shouldn't be relying on Python-level
stuff for real implementations.
On the other hand (I think I've run out of hands...), this also goes a long
way to solving the problem of people wanting a Matlab interface system. If
you could work in using Matplotlib into your examples, people might see how
much they can do in Python that replicates/replaces/supersedes Matlab for
these purposes.
Again, great stuff. Let us know how you want to continue to support it.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Status of GNU Radio on Mac OS X
On Sun, Sep 25, 2011 at 10:13 PM, Ben Reynwar wrote: > On Sun, Sep 25, 2011 at 5:54 PM, Michael Dickens wrote: > > On Sep 25, 2011, at 8:39 PM, Ben Reynwar wrote: > >> It wasn't that python2.5 didn't work, rather that macports didn't > >> attempt to install gnuradio for that version. Instead it installed > >> python2.6 and setup gnuradio for that. I've never messed about with > >> macports scripts so I don't know why that might happen. > > > > > > If you do "port info gnuradio", you'll see: > > > > gnuradio @3.3.0 (science) > > Variants: docs, python25, [+]python26, python27 > > > > which means that if you do "sudo port install gnuradio" -- install with > default variants -- then it will do so for use with Python 2.6. If you want > to use gnuradio with Python 2.5, then you'll want to do "sudo port install > gnuradio +python25". > > > > Hope that helps & makes sense. - MLD > > > > > > Makes sense. I didn't know about that. > Great. Thanks again Michael! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio component directory structure
On Mon, Sep 26, 2011 at 3:39 AM, Martin Braun wrote: > On Wed, Sep 21, 2011 at 10:04:23AM -0400, Tom Rondeau wrote: > > On Sat, Sep 17, 2011 at 3:14 PM, Martin Braun > wrote: > > > > I'd like to point out a disadvantage to get a discussion going: > > While you're developing, this might be an inconvenience because the > > files are physically separated. Most IDEs/editors have many features > > such as tagging, switching from headers to sources and vice versa, > 'go > > to file at cursor' commands etc. If half of the files are somewhere > > else, one has to set up the editor specifically for this dir > structure > > to do all of this. > > > > > > It's a logical separation that a lot of projects use. I know that I'm a > bit > > biased because my "IDE" is Emacs, but I don't recall having project files > in > > different directories was a problem. Way back when I developed in Windows > and > > used Visual Studio, this wasn't an issue, but that could have been due to > the > > project file that VS kept. > > > > > > We haven't made it part of our official standard, but talking with both > > Johnathan and Josh last week about it, I was thinking that we would. I'm > not > > sure that your argument here has quite convinced me that it'll be a > problem. > > To be honest, > > after re-reading this, I'm not even convinced myself. > Sometimes I just like to argue :) > > Martin Always good to have the discussion. I think we're settled on the use of include directory, then. Thanks! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio component directory structure
On Wed, Sep 21, 2011 at 10:04:23AM -0400, Tom Rondeau wrote: > On Sat, Sep 17, 2011 at 3:14 PM, Martin Braun wrote: > > I'd like to point out a disadvantage to get a discussion going: > While you're developing, this might be an inconvenience because the > files are physically separated. Most IDEs/editors have many features > such as tagging, switching from headers to sources and vice versa, 'go > to file at cursor' commands etc. If half of the files are somewhere > else, one has to set up the editor specifically for this dir structure > to do all of this. > > > It's a logical separation that a lot of projects use. I know that I'm a bit > biased because my "IDE" is Emacs, but I don't recall having project files in > different directories was a problem. Way back when I developed in Windows and > used Visual Studio, this wasn't an issue, but that could have been due to the > project file that VS kept. > > > We haven't made it part of our official standard, but talking with both > Johnathan and Josh last week about it, I was thinking that we would. I'm not > sure that your argument here has quite convinced me that it'll be a problem. To be honest, after re-reading this, I'm not even convinced myself. Sometimes I just like to argue :) Martin -- 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 pgpyUfJ28NMjr.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
