Re: [Discuss-gnuradio] Tuning in uhd_fft.py
Found this mail, it seems that the DC removal is still on implementing? If so, the tune request can not solve the DC problem at all? Sorry for these questions, as I am really confused by the code and the observed phenomenon. On Fri, Aug 17, 2012 at 12:44 PM, Josh Blum wrote: > > > On 08/17/2012 05:09 AM, Sanat Gulvadi wrote: > > Greetings, > > > > How are the effects of DC mitigated in GNU radio? For example, if I use > the > > uhd_fft.py to just scan the spectrum, I do not see any DC spike at the > > centre frequency. When I looked at the code, it has : > > > > r = self.u.set_center_freq(target_freq, 0) > > > > So I assume, it does not use the advanced tuning feature of UHD. Is this > > correct? How, in this case is there no DC spike seen at the centre > > frequency? > > I am trying to code a scanning system that goes through the whole > frequency > > band of my RFX2400 dboard and at each center frequency, I grab a packet > > from the air and apply an FFT to check for possible interferers etc. But > I > > am ending up with a spike at every centre frequency iteration. I have > used > > the two stage advanced tuning to try and push the DC leakage out of my > band > > of interest but I see no difference. I still get that single spike. (I am > > using the UHD library and not GNU Radio) > > > > There is a DC removal in the USRP, but it needs some time to integrate. > Perhaps in the gnuradio case, you are looking at an FFT that has had > some time to integrate at the new frequency. But in your finite > acquisition case, there is no time. > > -josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Alex, *Dreams can come true – just believe.* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio Screencast for Absolute Beginners
Hi Comunity, I have just uploaded some more screen casts. There are 6 of them. One is about basic hacking with the dial_tone.py script so that the beginners get a flavour of doing customization without knowing much of the language paradigms. here is the link (its under GNURADIO Experiments for Fun playlist) http://www.youtube.com/watch?v=kFMRSXR-w58&feature=plcp Rest are about USRP related things like (they are listed under GNURADIO & USRP, DAUGHTERBOARDS, ANTENNAS playlist) 1. changing the USRP name and finding it with several identifiers http://www.youtube.com/watch?v=sWFCXr-o2YY&feature=plcp 2. how to load customized firmware and fpga files in USRP http://www.youtube.com/watch?v=yvNe1QLBZfs&feature=plcp 3. And a very important tutorial about sub devices... http://www.youtube.com/watch?v=BERxSmWlRZM&feature=plcp and finally 4. how to find the available subdevices and how to use them http://www.youtube.com/watch?v=-g5RQIJQ868&feature=plcp http://www.youtube.com/watch?v=-V6ewR1a6_w&feature=plcp More videos are coming soon. -- View this message in context: http://gnuradio.4.n7.nabble.com/Gnuradio-Screencast-for-Absolute-Beginners-tp14542p37821.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] GNURADIO Screencast for absolute beginners : Some more screencast uploaded
Hi Community, I have just uploaded some more screen casts. There are 6 of them. One is about basic hacking with the dial_tone.py script so that the beginners get a flavour of doing customization without knowing much of the language paradigms. here is the link (its under GNURADIO Experiments for Fun playlist) http://www.youtube.com/watch?v=kFMRSXR-w58&feature=plcp Rest are about USRP related things like (they are listed under GNURADIO & USRP, DAUGHTERBOARDS, ANTENNAS playlist) 1. changing the USRP name and finding it with several identifiers http://www.youtube.com/watch?v=sWFCXr-o2YY&feature=plcp 2. how to load customized firmware and fpga files in USRP http://www.youtube.com/watch?v=yvNe1QLBZfs&feature=plcp 3. And a very important tutorial about sub devices... http://www.youtube.com/watch?v=BERxSmWlRZM&feature=plcp and finally 4. how to find the available subdevices and how to use them http://www.youtube.com/watch?v=-g5RQIJQ868&feature=plcp http://www.youtube.com/watch?v=-V6ewR1a6_w&feature=plcp More videos are coming soon. -- View this message in context: http://gnuradio.4.n7.nabble.com/GNURADIO-Screencast-for-absolute-beginners-Some-more-screencast-uploaded-tp37822.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] FLL Band-Edge Detectors: Literature?
Hi, is there any literature that goes with the FLL synch blocks in gr-digital? Ironically, Google always points me to the GR source files when I search for 'fll band edge' related topics. M -- 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 pgpnhk9NTGfrL.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FLL Band-Edge Detectors: Literature?
Hello, Frederic Harris's "Multirate Signal Processing: for communication systems" has a section on FLL band edge sync. I think that the GR-digital code was designed based on these algorithms. Tom or other GNUradio block designers can verify it. Thanks, Nazmul On Mon, Oct 1, 2012 at 11:40 AM, Martin Braun (CEL) wrote: > Hi, > > is there any literature that goes with the FLL synch blocks in > gr-digital? Ironically, Google always points me to the GR source files > when I search for 'fll band edge' related topics. > > M > > > -- > 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 > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Muhammad Nazmul Islam Graduate Student Electrical & Computer Engineering Wireless Information & Networking Laboratory Rutgers, USA. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A Question on WX GUI FFT Sink
I tried to find in the QT GUI Widgets category an item that does FFT. But don't find one. I wonder what is meant by the "QT GUI FFT display"? Thanks, LD On Fri, Sep 28, 2012 at 3:39 PM, Josh Blum wrote: > > > On 09/28/2012 02:15 PM, LD Zhang wrote: > > Hello, > > > > I have a simple GRC demo where the USRP source goes to a WX GUI FFT sink > > and WX GUI Scope sink. They appear to be a good tools for sanity checks. > > One feature I don't find however but I think should be quite necessary is > > when one needs to examine a portion of the FFT spectrum more closely. > But I > > don't find an option where one can specify the start and stop frequency > for > > the FFT spectrum display. Am I missing something? > > > > WX FFT sink cant do this. But... > > FWIW, the QT gui FFT display sink does have a zoom feature. > > -josh > > ___ > 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
[Discuss-gnuradio] Simple QAM mod/demod
As sanity check I'm trying a simple flowgraph in GRC with a QAM mod/demod: Vector Source ==> Throttle ==> QAM Mod ==> QAM Demod ==> Unpacked to Packed ==> File Sink The parameters in the mod/demod are as default. I also have a File Sink before the mod. In the output I see first a bunch of zeros, then a bunch of random numbers and after 20 or so bytes I get a sequence with the same period as the original one, but different numbers. I suppose this is a problem of phase sync. What's the right way to simulate a simple mod/demod? How do I add sync between mod and demod? Thanks, Fabián ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A Question on WX GUI FFT Sink
Well I should have been more patient before I sent out the last email. It turns out for the functionality I want (flexible zoom in display of the fft spectrum) the block is called simply "QT GUI sink", if I am not mistaken. When I tried, there is the error message: --- Traceback (most recent call last): File "/home/ldz/usrp_tests/top_block.py", line 75, in tb = top_block() File "/home/ldz/usrp_tests/top_block.py", line 58, in __init__ self.top_layout.addWidget(self._qtgui_sink_x_0_win) File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 94, in __getattr__ return getattr(self._tb, name) AttributeError: 'gr_top_block_sptr' object has no attribute 'top_layout' - I took a look in the top_block.py in my test directory. But I don't understand the problem. I have not yet become accustomed to the python environment. Please off suggestions. Thanks. LD On Fri, Sep 28, 2012 at 3:39 PM, Josh Blum wrote: > > > On 09/28/2012 02:15 PM, LD Zhang wrote: > > Hello, > > > > I have a simple GRC demo where the USRP source goes to a WX GUI FFT sink > > and WX GUI Scope sink. They appear to be a good tools for sanity checks. > > One feature I don't find however but I think should be quite necessary is > > when one needs to examine a portion of the FFT spectrum more closely. > But I > > don't find an option where one can specify the start and stop frequency > for > > the FFT spectrum display. Am I missing something? > > > > WX FFT sink cant do this. But... > > FWIW, the QT gui FFT display sink does have a zoom feature. > > -josh > > ___ > 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] 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 things is basically the same > thing > > I have on the RX side. If I set the subdev spec on the basic RX to "A:A > > A:B" and then use usrp->set_rx_freq(uhd::tune_request_t(freq)) for each > > channel, I get two separate rx channels, both with their own IQ pairs. On > > the TX side I only manage to have one IQ pair, as in I through TX_A and Q > > through TX_B. We were trying for a 4 channel transmit on 2 USRPs, so that > > they could all be connected by s MIMO cable. One more question, when you > > say "too complicated to be worth it", generally, what kind of > modification > > would be necessary? > > The reason for the complication is there is this whole flow control > implementation for the TX. Here is my suggestion: > > On the host, interleave your MIMO channels. So send 1 TX channel where > the samples are ch0IQ0, ch1IQ0, ch0IQ1 > > In the FPGA, a good way is to modify the top level to have two DUC > chains. See right here: > > http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/usrp2/top/N2x0/u2plus_core.v#L716 > > Instantiate two DUC chains. Most of the wires can stay the same. Since > this is MIMO, you want both DUC chains to have the same settings > anyways. What you want to do here is to play with the strobe_tx signal > such that every even strobe is off for DUC0 and every off strobe is off > for DUC1... thats effectively the deinterleave. Also notice how the > tx_fe outputs are connected. > > reg even; > always @(posedge dsp_clk) >if (~run_tx) even <= 0; >else if (strobe_tx) even <= ~even; > > duc_chain #(.BASE(SR_TX_DSP), .DSPNO(0)) duc_chain0 > (.clk(dsp_clk),.rst(dsp_rst), .clr(clear_tx), > > .set_stb(set_stb_dsp),.set_addr(set_addr_dsp),.set_data(set_data_dsp), > .set_stb_user(set_stb_user), .set_addr_user(set_addr_user), > .set_data_user(set_data_user), > .tx_fe_i(tx_fe_i),.tx_fe_q(), > .sample(sample_tx), .run(run_tx), .strobe(strobe_tx & even), > .debug() ); > > duc_chain #(.BASE(SR_TX_DSP), .DSPNO(0)) duc_chain1 > (.clk(dsp_clk),.rst(dsp_rst), .clr(clear_tx), > > .set_stb(set_stb_dsp),.set_addr(set_addr_dsp),.set_data(set_data_dsp), > .set_stb_user(set_stb_user), .set_addr_user(set_addr_user), > .set_data_user(set_data_user), > .tx_fe_i(tx_fe_q),.tx_fe_q(), > .sample(sample_tx), .run(run_tx), .strobe(strobe_tx & ~even), > .debug() ); > > > -Josh > > > 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 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 > >>> this is because there is only one DUC chain in the N210. Is there a way > >> to > >>> modify this so that I can have two DUC chains in the same way that I > have > >>> two DDC chains? > >>> Thanks, > >>> Anisha > >> > >> I think adding two complete DUC chains into N210 would be too > >> complicated to be worth it. > >> > >> Is there something specific that you cant do with the single DUC chain? > >> As long as the cordic is set to zero, I and Q will remain completely > >> separate from host samples, all the way to the SMA connectors A and B. > >> > >> Otherwise, perhaps you need a different rotation for I vs Q? I think > >> that would be better accomplished by two different cordics. Then perhaps > >> a custom DSP in the FPGA is for you: > >> > >> > http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/README.txt#L29 > >> > >> I hope that helps. > >> > >> -josh > >> > >>> > >>> > >>> > >>> ___ > >>> 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 > >> > > > > > > > -- Anisha Gorur Class of 2012 Electrical Engineering ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 and > > receive frame size are still the defaults, 1472 for receive and 1444 for > > send. In the notes, it says "to improve receive latency, configure the > > transport for a smaller frame size", will this work for send latency as > > well? Also is there an equation I can use to determine what the best > frame > > sizes would be, or should I just go with trial and error and use > > latency_test.cpp to determine if it has shifted? If you change the frame > > size, how much improvement in latency do you usually see? > > Again, thank you so much. > > -Anisha > > > > The reason that shrinking the receive frame size reduces latency is that > the RX DSP chain produces samples at a fixed rate. Therefore, the device > cannot release a packet until samples_per_packet / sample_rate. The > first sample is a packet is delayed by the time it takes to produce the > last sample. > > However, in the case of transmission/send there is no such issue. > Essentially your application is the pacer and producer of samples. So > you have total control. > > -Josh > > > 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 > >> > >> The dominating factor in latency here is the gigabit ethernet, this > >> tends to be around 100us. Here are a few notes about that: > >> > >> > >> > http://files.ettus.com/uhd_docs/manual/html/transport.html#latency-optimization > >> > >>> the data be routed through the host? My Radio, We only have a couple > >> months > >> > >> Normally the samples would all go to the host computer that configured > >> the USRP. It is possible to configure the USRP with one machine but send > >> the samples to an arbitrary network location: > >> > >> > >> > http://files.ettus.com/uhd_docs/manual/html/usrp2.html#alternative-stream-destination > >> > >> For that matter, there is nothing wrong with splitting up the USRP > >> configuration among several computers. It all depends how you plan on > >> using the data. > >> > >>> to do this, but we have tried to synchronize USRPs before, so we are > >> aware > >>> of some of the problems. > >> > >> Anything in particular that I could help to clarify? > >> > >> -josh > >> > >>> Thanks, > >>> Anisha > >>> > >>> On Wed, Sep 26, 2012 at 3:51 PM, My Radio > >> wrote: > >>> > One should remember the extremes involved in syncing all USRP'S which > >> will > lead to developing a new driver for USRP2. > > What about the your APP development time?. Are you interested in > developing new driver or app ? > > > On Thu, Sep 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. > > > > Matt > > > > 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-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 daisy chaining mimo cables, without using a switch or > > network > >> connections. > >> > >> Thank you, > >> Anisha > >> > >> > >> ___ > >> 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 > > > > > > ___ > 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 > >>> > >> > >> ___ > >> Discuss-gnuradio mailing list > >> Discuss-gnuradio@gnu.org > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >> > > > > > > > -- Anisha Gorur Class of 2012 Electrical Engineering __
Re: [Discuss-gnuradio] A Question on WX GUI FFT Sink
On Mon, Oct 1, 2012 at 4:35 PM, LD Zhang wrote: > Well I should have been more patient before I sent out the last email. It > turns out for the functionality I want (flexible zoom in display of the fft > spectrum) the block is called simply "QT GUI sink", if I am not mistaken. > > When I tried, there is the error message: > > --- > Traceback (most recent call last): > File "/home/ldz/usrp_tests/top_block.py", line 75, in > tb = top_block() > File "/home/ldz/usrp_tests/top_block.py", line 58, in __init__ > self.top_layout.addWidget(self._qtgui_sink_x_0_win) > File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", > line 94, in __getattr__ > return getattr(self._tb, name) > AttributeError: 'gr_top_block_sptr' object has no attribute 'top_layout' > - > > I took a look in the top_block.py in my test directory. But I don't > understand the problem. I have not yet become accustomed to the python > environment. > > Please off suggestions. Thanks. > > LD In the Options blocks, you have to change from using WXGUI to QTGUI. And just use the QT Sink block. From there, you can switch between the FFT, spectrogram, time, and constellation modes. Tom > On Fri, Sep 28, 2012 at 3:39 PM, Josh Blum wrote: >> >> >> >> On 09/28/2012 02:15 PM, LD Zhang wrote: >> > Hello, >> > >> > I have a simple GRC demo where the USRP source goes to a WX GUI FFT sink >> > and WX GUI Scope sink. They appear to be a good tools for sanity checks. >> > One feature I don't find however but I think should be quite necessary >> > is >> > when one needs to examine a portion of the FFT spectrum more closely. >> > But I >> > don't find an option where one can specify the start and stop frequency >> > for >> > the FFT spectrum display. Am I missing something? >> > >> >> WX FFT sink cant do this. But... >> >> FWIW, the QT gui FFT display sink does have a zoom feature. >> >> -josh >> >> ___ >> 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 > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FLL Band-Edge Detectors: Literature?
On Mon, Oct 1, 2012 at 12:00 PM, Nazmul Islam wrote: > Hello, > > Frederic Harris's "Multirate Signal Processing: for communication systems" > has a section on FLL band edge sync. I think that the GR-digital code was > designed based on these algorithms. Tom or other GNUradio block designers > can verify it. > > Thanks, > > Nazmul > > On Mon, Oct 1, 2012 at 11:40 AM, Martin Braun (CEL) > wrote: >> >> Hi, >> >> is there any literature that goes with the FLL synch blocks in >> gr-digital? Ironically, Google always points me to the GR source files >> when I search for 'fll band edge' related topics. >> >> M Martin, Yes, harris' book is the best to start with. There is another paper from him called "Let's Assume the System is Synchronized" that also goes over it. I'm not sure if he's published a paper that discusses the specifics of the filter derivation, yet, though. It's based on the derivative of the half cosine waveform of the RRC filter rolloff. The system behaves much better this way than just generating any random band edge filter. In theory, this should work for any signal using an RRC pulse shaping. For specific constellations, you could use a Costas loop with a wider lock in bandwidth to handle the frequency offset. Oh, and I might be the only one who calls this the "FLL band edge filter" specifically to point out that this is only one possible implementation of an FLL for coarse frequency tracking. Other algorithms are welcome :) Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to use gr_hier_block2 with multi output
On Thu, Sep 27, 2012 at 11:21 PM, Luong Tan Phong wrote: > Hi Lists, > > I've used gr_hier_block2 class with 1 output stream and it's OK but I can't > use gr_hier_block2 with 2 output streams. Could you help me, please? > > Thanks. > > Phong Yes, you should be able to set up an io_signature just like any other block. You should then be able to use self.connect(block0, (self,0)) and self.connect(block1, (self,1)) to connect them up. Or the appropriate C++ version for this. The main restriction is that you cannot have a variable number of streams. So if you use 2 output streams, you must use io_signature(2, 2, sizeof(...)) and then make sure both streams are connected in your graph. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] TCP sink in server mode
What does the TCP sink do in server mode before any connects? Does it drop samples, or stall the pipeline? -- 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
Re: [Discuss-gnuradio] TCP sink in server mode
On 10/01/2012 04:42 PM, Marcus D. Leech wrote: > What does the TCP sink do in server mode before any connects? Does it > drop samples, or stall the pipeline? I think thats a little python wrapper around a gr file descriptor sink and a python tcp socket. The block's constructor blocks waiting for a connection. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QS1R SDR support?
On Mon, Sep 24, 2012 at 3:56 PM, Matthew Biederman wrote: > Hello, > > I just learned about gnuradio and am very interested in the possibilities. I > currently own a QS1R (http://qs1r.wikispaces.com) and while I found a few > posts referring to using it with gnu radio software, I didn't explicitly find > anyone actually using the two together. Has anyone out there successfully > used it? > > thanks in advance > matthew > VA2XBX Hi Matthew, Unfortunately, no. At least there's no block in GNU Radio and I don't think anyone has developed one outside. At one point I had meant to, but never got around to it. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_block::set_history()
On Mon, Sep 24, 2012 at 12:47 PM, cjpatton wrote: > Hello Tom, > > I have a follow-up question about how history works in gnuradio. Making no > assumptions about the input/output ratio of a gr_block, is it safe to assume > that noutput_items is the number of new data given to the block? I.e., Does > calling 'consume(noutput_items)' consume all the new data available when the > work function is called? If this is is the case, what does ninput_items > represent? > > Thanks again, > Chris Patton Chris, By default, yes, an input will have at least noutput_items available to it. This is due to the forecast function that defaults to say that the required number of inputs is the number of outputs plus the history. So unless you overload the forecast function, this is how it works. When you say consume(i, noutput_items), then you are just telling the scheduler that that is how many items read from the input. But there could be more items available; you just (probably) wouldn't process them because you don't have the space on the output. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Does USRP ADC have internal noise (out-of-band) dither?
Dear Group, I need to clarify a very basic feature of the USRP ADC. The question is: Does the ADC have internal noise dither when sampling? I looked at the TI ADS62P45 data sheet but did not find explicit mention of the noise dither. On the other hand, if you read those app notes from Analog Device Walt Kester, the noise dither is such a prominent feature that it is almost essential to have it in the A-to-D process. From the spectrum I gathered so far, I cannot tell. I would think TI should be good on this basic point. Could someone clarify? Many Thanks, LD Zhang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
