Re: [Discuss-gnuradio] Question on gnuradio.wxgui and the agc block
Hi, > On Thu, 5/21/09, Ankit Saf wrote: > > > I'll go a step further and ask if there is are more help files on available > GNU radio blocks, and > about writing your own block? > > Thanks! There is a old and un-updated document that lists Gnuradio blocks at: http://www.scribd.com/doc/9688074/Simple-Gnuradio-User-Manual-v10 Best Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using a USRP as a PID feeback controller
I've got my verilog code for a USRP-based PID controller to the stage where it is more or less coherent, and commented. I made some modifications to the top level file, and added a few small .v modules. What is the reigning protocol on this mailing list about .v file attachments? Can I just attach a few files? Once upon a time, when I was still knee high to a grasshopper, I got symphonically scolded for attaching a core dump to some open source project mailing list, so ever since I have been cautious... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Q. USRP2+RFX2400 performances on dynamic range, and decim
Yc Park wrote: > Eric Blossom wrote: >> On Thu, May 21, 2009 at 08:23:31AM +0200, Yc Park wrote: >>> The recorded signal showed only about 25dB between the in-band spectrum >>> level(-25dBm/RBW) and the noise floor (-50dBm/RBW) while the original >>> signal shows at least 45dB. >> >> What gain setting are you using? >> Have you tried lowering it? >> >> Eric > > The gain was 10dB. With higher gain, the ACPR gets worse with the given > input power. > > I'm sorry that I do not know how to upload the captured spectrum, but it > is exactly as I mentioned in the first place: The noise floor is about > -50dBm while the in-band signal is at -25dBm over the 8.8MHz of the > signal bandwidth. Forgot to mention: I also tested the gain 0, -10(I guess the result with negative gain was same with 0dB). But nothing much different with the spectrum. -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Q. USRP2+RFX2400 performances on dynamic range, and decim
Eric Blossom wrote: > On Thu, May 21, 2009 at 08:23:31AM +0200, Yc Park wrote: >> The recorded signal showed only about 25dB between the in-band spectrum >> level(-25dBm/RBW) and the noise floor (-50dBm/RBW) while the original >> signal shows at least 45dB. > > What gain setting are you using? > Have you tried lowering it? > > Eric The gain was 10dB. With higher gain, the ACPR gets worse with the given input power. I'm sorry that I do not know how to upload the captured spectrum, but it is exactly as I mentioned in the first place: The noise floor is about -50dBm while the in-band signal is at -25dBm over the 8.8MHz of the signal bandwidth. -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Q. USRP2+RFX2400 performances on dynamic range, and decim
On Thu, May 21, 2009 at 08:23:31AM +0200, Yc Park wrote: > Hi guys, > > Using my usrp2+RFX2400 and the GRC with gnuradio 3.2svn, > I've recorded a wimax signal out of a RF signal generator. > > However, I found some issues with the result and ask you guys for some > help. > (I tried to search on these issues, but only found some about usrp.) > > 1) The biggest problem is the dynamic range of the signal: > The recorded signal showed only about 25dB between the in-band spectrum > level(-25dBm/RBW) and the noise floor (-50dBm/RBW) while the original > signal shows at least 45dB. What gain setting are you using? Have you tried lowering it? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question on gnuradio.wxgui and the agc block
Does anyone have info on gnuradio.wxgui? Like a list of blocks available through it, etc? Also, I have "A dictionary of the GNU Radio blocks" by Dawei Shen, but I couldn't find anything about the gr.agc_cc block in it. Any help on that? I'll go a step further and ask if there is are more help files on available GNU radio blocks, and about writing your own block? Thanks! -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Handling Messages
Hi Ali - I think the issue is that the output of the C2M is of item_size 'fftsize', whereas the message_sink has item_size of 'gr.sizeof_float'. Try incorporating the 'gr.vector_to_stream' you created between the C2M and the message_sink. - MLD On May 21, 2009, at 11:34 AM, ali siddiqi wrote: signal source --> stream2vector --> fft --> c2m --> msg_sink ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Handling Messages
Hi, I am trying to make a flowgraph as given: signal source --> stream2vector --> fft --> c2m --> msg_sink If the size of fft is 4096, then I want to retrieve these 4096 points in python and then do simple maths and logic based on some of the values within these 4096 points within python. And then based on the result, I want to initiate another flowgraph! Currently, there is an error between the interface between c2m and msg_sink. The code is: class top(gr.top_block): def __init__(self): gr.top_block.__init__(self) ## # Variables ## self.samp_rate = samp_rate = 32000 ## # Blocks ## self.sigsource = gr.sig_source_c(samp_rate, gr.GR_COS_WAVE, 1000, 10, 0) self.sigsource1 = gr.sig_source_c(samp_rate, gr.GR_COS_WAVE, 2000, 20, 0) self.sigadder = gr.add_vcc(1) fftsize = 4096 mywin = window.blackmanharris(fftsize) fft = gr.fft_vcc(fftsize, True, mywin) c2m = gr.complex_to_mag(fftsize) s2f1 = gr.short_to_float() s2f2 = gr.short_to_float() # Vector Sink/Source ss2v = gr.stream_to_vector(gr.sizeof_gr_complex, fftsize) v2ss = gr.vector_to_stream(gr.sizeof_float, fftsize) # Message Settings self.qsize = 10 self.msgq0 = gr.msg_queue(self.qsize) # queue amplitude # Message sink m_sink0 = gr.message_sink(gr.sizeof_float, self.msgq0, True) self.connect((self.sigsource, 0), (self.sigadder, 0)) self.connect((self.sigsource1, 0), (self.sigadder, 1)) self.connect(self.sigadder, ss2v, fft, c2m, m_sink0) def main (): # Start Top Block tb = top() #Start Flowgraph tb.start() # Read first message amsg = tb.msgq0.delete_head() # get first amplitude message raw_a = amsg.to_string() # raw amplitude data a_data = numpy.fromstring(raw_a, numpy.float32, count = int(amsg.arg2())) # converted amplitude data print "Data in sink is: ",a_data tb.stop() if __name__ == '__main__': main () Regards, from gnuradio import gr, gru, eng_notation, optfir, window import numpy class top(gr.top_block): def __init__(self): gr.top_block.__init__(self) ## # Variables ## self.samp_rate = samp_rate = 32000 ## # Blocks ## self.sigsource = gr.sig_source_c(samp_rate, gr.GR_COS_WAVE, 1000, 10, 0) self.sigsource1 = gr.sig_source_c(samp_rate, gr.GR_COS_WAVE, 2000, 20, 0) self.sigadder = gr.add_vcc(1) fftsize = 4096 mywin = window.blackmanharris(fftsize) fft = gr.fft_vcc(fftsize, True, mywin) c2m = gr.complex_to_mag(fftsize) s2f1 = gr.short_to_float() s2f2 = gr.short_to_float() # Vector Sink/Source ss2v = gr.stream_to_vector(gr.sizeof_gr_complex, fftsize) v2ss = gr.vector_to_stream(gr.sizeof_float, fftsize) # Message Settings self.qsize = 10 self.msgq0 = gr.msg_queue(self.qsize) # queue amplitude # Message sink m_sink0 = gr.message_sink(gr.sizeof_float, self.msgq0, True) self.connect((self.sigsource, 0), (self.sigadder, 0)) self.connect((self.sigsource1, 0), (self.sigadder, 1)) self.connect(self.sigadder, ss2v, fft, c2m, m_sink0) def main (): # Start Top Block tb = top() #Start Flowgraph tb.start() # Read first message amsg = tb.msgq0.delete_head() # get first amplitude message raw_a = amsg.to_string() # raw amplitude data a_data = numpy.fromstring(raw_a, numpy.float32, count = int(amsg.arg2())) # converted amplitude data print "Data in sink is: ",a_data tb.stop() if __name__ == '__main__': main () ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] a few queries related to ofdm implementation
Hi,I am using the trunk repository with revision no. 11025. I am presently experimenting on ofdm. The given code is working fine on the USRP setup. Here we specify the center frequency at which the ofdm signal is going to be transmitted.1) Is this the center frequency of the sub-carrier of a particular channel? If so, what is the bandwidth used? 2) If not, how the sub-carrier is differentiated from the channel? How many sub-carriers are supported? 3) Is it possible to switch to a different frequency at runtime? 4) The modulation parameter is the modulation technique defined for a particular sub-carrier, right? If so, can we also define a different modulation technique to be used at runtime once we switch to a different frequency?5) The preamble defined for the packets - are they standardized? I mean to say, any ofdm packet will be having the same preamble?6) Why the interpolation/decimation values need to be specified for this experiment alone? This is not the case for other examples given in 'gnuradio-examples' folder.Please help me figure out the answers for these. It will help in proper understanding of ofdm implemented on gnuradio.Shesh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Modifying the USRP FPGA core
Hi, Since the USB data rate is the limiting factor in my current setup I figured I would implement some functions on the FPGA itself since they are likely to be simple to implement. I have loaded the project in Quartus and have been looking at the Schematic for some time. I already figured I have to configure with a reduced number of RX, TX channels to free up some FPGA resources. I was wondering where to put my extra logic in this diagram. To be more precise, the logic will only be affecting the RX side and I don't mind the 16-bit values coming out of USB, as long as it's processed with my logic. I was thinking about putting the logic between the rx_chain blocks and the rx_buffer i.e. taking the I and Q values coming out of the DDCs and adding an extra block to do my transformations. I am assuming the rx_buffer only takes the values presented to it and shifts them out USB according to the multi-channel scrambling *e.g.* I0, Q0, I1, Q1, etc. Could you confirm/infirm that my proposed design is valid ? Will the extra block delay affect the functioning of the system ? Thank you, -- Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using a USRP as a PID feeback controller
Hello Aviv... I believe this has something similar to what you were mentioning... http://staff.washington.edu/jon/gr-mrfm/ Regards, Rakesh On Wed, May 20, 2009 at 4:20 AM, Aviv Keshet wrote: > This email is not a question, but more of a comment. > > I've been working for about a week on re-purposing a USRP as a digital > feedback > controller, rather than a software radio. The USRP hardware platform > provides > you with quite a good starting point for this sort of general purpose > digital > signal processing application. Nice, fast, and fairly high resolution > analog > front end. And the total ADC + DAC latency is only 250 ns (by my > measurements), > which means PID feedback controllers with lock bandwidths up to 1MHz are > quite > achievable (something that can be quite a pain to do with analog > components). > And of course a digital feedback controller, being programmable, can be > made to > do also sorts of fancy "smart" things that are a pain to do in analog (hold > or > reset the integrator when told to do so, or make the loop gains > setpoint-dependent, or your great idea here). > > Despite this seeming like a killer app, I haven't really found much > discussion > of it in this list's archives or on the gnuradio wiki. So I'm mentioning > the > idea in public, for future mailing list archive searchers. If, at some > point, > my FPGA code reaches a level of maturity where am I not too embarassed to > share > it, maybe I will post it somewhere. Or maybe someone on this list will now > pipe > in that this is all old hat and has already been done. > > Aviv > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
