[Discuss-gnuradio] Tune UHD - as fast as possible
Hi! I have put a Flow-Graph together, which is quite simple: Sine Signal -> USRP2 UHD Now I want to change the center-frequency as fast as possible. My initial idea was a while True loop and to issue the self.uhd_usrp_sink_0.set_center_freq(self.freq, 0) command from Python. This does not work. It remains at the initial frequency. Do you use the Function Probe block in GRC? Or is there any other way to make it tune without ending the Flow-Graph? Best, Marius signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Google Summer of Code '12 is On
On 02/08/2012 01:29 AM, Martin Braun wrote: > Hi everyone, > > On Tue, Feb 07, 2012 at 09:46:08AM -0500, Philip Balister wrote: >> At the last developer call I agreed to lead the GSoC effort. > > That's great! > As you might know, I'm always interested in getting students involved in > GNU Radio, so I'd like to join the mentoring crew. > > Also, I'd like to keep this thread going. Here's a wiki page for GSoc, > to collect ideas etc.: > http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC (the wiki is > being quite slow, again). Thanks Martin! The GSoC FAQ references this idea list also: http://community.kde.org/GSoC/2011/Ideas Looks like we should ad some info about potential mentors and background/skill set needed to work on the idea. Also, how many students are interested in working on the GSoC with GNU Radio? What sort of things would you like to work on? Philip > >> Based on my prior experience with GSoC (via the BeagleBoard project), >> the single most important part of the application is the list of ideas. >> We need to start thinking about ideas that are possible for >> undergrad/grad type students in a three month period. I also recommend >> looking at idea list published by other successful organizations. > > Here's what GIMP did last year (just picked a random project): > http://wiki.gimp.org/index.php?title=Hacking:GSoC_2011/Ideas > > Not too difficult, it seems :) > >> The application deadline is March 9. We should aim to be done before >> that due to WSR12. > > So you're coming? :) > > MB > > > > > > ___ > 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] how to learn of decimation rate in general_work() ?
On Wed, Feb 8, 2012 at 7:34 PM, Ian Buckley wrote: > Just to confirm, the USRP2/N2x0 ADC samples at 100MHz. (The DAC output > however runs at 400MHz, its fed samples at 100MHz and it has built in 4x > interpolation which may be the source of confusion). > > On Feb 8, 2012, at 4:12 PM, Tom Rondeau wrote: > > On Tue, Feb 7, 2012 at 5:37 PM, George Nychis wrote: > >> >>> Hey George, >>> >>> You can use the relative_rate data member of the blocks. Setting the >>> decimation actually sets the relative_rate to 1.0/decimation. You can get >>> this value with the accessor function "relative_rate()". >>> >>> >> Hey Tom, >> >> Using this I can get the decimation rate, but is there a way to get the >> rate of samples from the ADC? That way I can compute the real clock time >> in-between samples. For the USRP2, despite the ADC running running at >> 400Msps, it's rate through the FPGA is actually 100Msps, right? > > > Actually, I think the ADC is running at 100 Msps, which I think you can > get with the "get_clock_rate(mboard)" method. The rate that they come > across is then determined by the decimation rate. You can query sample rate > from the USRP via the UHD with the "get_sampl_rate()" method. > > Great, thanks a bunch for the info Tom & Ian! I'm using UHD, so I will use get_sampl_rate() ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Three different USRP2 nodes are transmitting with almost exactly 1 MHz frequency offset
Nazmul - Your version of UHD is from November 22nd. Will you try updating your UHD install? I'm not sure how you installed, or how familiar you are with git / Linux - here is a quick command list, assuming you used Git to checkout the code to begin with, and it is in a directory called uhd.git/ $ cd uhd.git $ git checkout master $ git remote update; git pull $ rm -rf build $ mkdir build; cd build $ cmake ../ && make Let us know how it goes! Cheers, Ben On Wed, Feb 8, 2012 at 8:52 PM, Nazmul Islam wrote: > Thanks for the reply, Jason. The uhd_usrp_probe --version command gave the > following result: > > linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.004.000-71810ad > > 003.004.000-71810ad > > Do I have to download the latest UHD image? The image that I am using > right now was downloaded by one of my colleagues and I think that he did it > recently. > > Also, I tried running the benchmark_tx and benchmark_rx codes with a 1 MHz > frequency offset input, i.e., I gave the following commands: > > ./benchmark_tx.py -f 2.4G -r 1M -m gmsk -a "addr = 192.168.10.2" > > ./benchmark_tx.py -f 2.401G -r 1M -m gmsk -a "addr = 192.168.10.2" > > Since the uhd_fft.py and the my lab spectrum analyzer show a 1 MHz > frequency offset, I assumed that the above commands would work. > Unfortunately, this did not help either! > > Suggestions will be very appreciated. > > Thanks, > > Nazmul > > > > > On Wed, Feb 8, 2012 at 7:37 PM, Jason Abele wrote: > >> On Wed, Feb 08, 2012 at 06:39:24PM -0500, Nazmul Islam wrote: >> > Hello, >> > >> > I am running the benchmark_tx.py codes and looking at the spectrum of >> the >> > signals using uhd_fft.py. I am using the latest image of GNU radio >> > (GNUradio 3.5) and I have XCVR2450 daughterboards. I ran the >> > benchmark_tx.py code in three transmitter nodes and surprisingly, all of >> > them are transmitting with 1 MHz frequency offset! I have attached two >> > screenshots with the email (I hope that they go through). I give the >> > following input parameters to run the benchmark_tx code. >> > >> > ./benchmark_tx.py -f 2.4G -r 1M -m gmsk -M 10 -a "addr = 192.168.10.2" >> > >> > Both uhd_fft.py and the spectrum analyzer of my laboratory show that the >> > received signal is centered at 2.401 GHz. I varied the frequency to 2.45 >> > GHz, 2.41 GHz, but this 1 MHz frequency shift persists. >> > >> > When I run the benchmark_rx.py code at the receiver nodes, they don't >> > receive/detect any packets (due to the frequency offset, I guess). I >> even >> > tried to run the transmitter at 2.4 GHz and the receiver at 2.401 GHz. >> > However, that did not help either! >> > >> > I will try to modify the control loop gain parameters using Tom's blogs >> > suggestions and see if that helps. However, I am really surprised to see >> > how all three different transmitter nodes can transmit with almost >> exactly >> > 1 MHz frequency offset. Any suggestion will be appreciated. >> > >> >> Can you tell us which version of UHD you are using? >> (uhd_usrp_probe --version) >> >> We have heard reports of such an issue and my best guess is that it was >> related to an accidental swap of I and Q in the XCVR2450 transmitter >> code. This went in after the 3.3.2 release and is fixed on latest UHD >> master since 837437c65ce36d418cceb3df5b093f9497b3af5f >> >> Jason >> > > > > -- > 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 > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] dbpsk demodulation
Hey, Apologies if this is a duplicate but i found this is my drafts while i thought i got delivered. I having been trying to debug my demodulator for a few days now and in due process i receive the following error message. ValueError: itemsize mismatch : dbpsk_demod(5):0 using 1, sub_ff(15):0 using 4. Now there are two things that i observed. 1) With the connect statement of these two at hand , sub_ff is expecting 4 float bytes which is only connected to "1 byte/sample" output by the dbpsk_demod block. 2) The output of the dbpsk_demod block (according to the line -- > io_sig_out = gr.io_signature(1,1,gr.sizeof_char) .. so its a dbpsk_demod_complex->character conversion where as the sub_ff is a "float --> float " . My question is will a custom "gr_dbpsk_demod_cf" with a cosine function(that possibly uses a certain kind of cosine table) be useful to do the following : 1) keep the constellation in check (i.e 1 bit/symbol) at 0 and 180 degrees respectively. 2) ofcourse convert a complex to float. 3) How effective would such a cpp block be as opposed to a full fledged python block ? Thanks & regards, Anay. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] uhd_mimo_sink
Hi all, I've just updated my system and found a problem when trying to use the uhd_mimo_sink: AtributeError: 'module' object has no attribute 'mimo_sink'. I don't know if it has to do with some mistake during the installation progress and this block is missing or it is something else. Referring to this I would like to know if someone who has already implemented a mimo system could tell me which sink/source blocks should be used.I have a MIMO cable and I guess the smartest is to use this uhd_mimo_sink and uhd_mimo source, but it may work too using two simple uhd_usrp_sink and configuring one of them as a slave as it is explained in the application notes, is it right? I would like to know if someone has experience on that and could me to use the best option. Thank you very much in advance! any advice would be great! Jorge ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd_mimo_sink
On Thu, 9 Feb 2012 21:24:46 +0100, Jorge Hernandez wrote: > Hi all, > > I've just updated my system and found a problem when trying to use the uhd_mimo_sink: AtributeError: 'module' object has no attribute 'mimo_sink'. > I don't know if it has to do with some mistake during the installation progress and this block is missing or it is something else. Referring to this I would like to know if someone who has already implemented a mimo system could tell me which sink/source blocks should be used.I have a MIMO cable and I guess the smartest is to use this uhd_mimo_sink and uhd_mimo source, but it may work too using two simple uhd_usrp_sink and configuring one of them as a slave as it is explained in the application notes, is it right? I would like to know if someone has experience on that and could me to use the best option. Thank you very much in advance! any advice would be great! > > Jorge Those blocks haven't been present in many releases. Use the normal UHD source/sink blocks, and configure the clocking appropriately. The source/sink blocks can have many, many, many streams, which each stream connected to different motherboard device addresses, etc. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tune UHD - as fast as possible
self.uhd_usrp_sink_0.set_center_freq(self.freq, 0) will take forever, the whole front end has to re-settle. How far are you moving the center frequency? If it's less than 50MHz you could change the sin signal frequency. You could even hook up a Frequency modulator and change the frequency continually and with absolutely no delay. On Thu, Feb 9, 2012 at 7:02 AM, Marius Ciepluch wrote: > Hi! > > I have put a Flow-Graph together, which is quite simple: > Sine Signal -> USRP2 UHD > > Now I want to change the center-frequency as fast as possible. > > My initial idea was a while True loop and to issue the > self.uhd_usrp_sink_0.set_center_freq(self.freq, 0) command from Python. > This does not work. It remains at the initial frequency. > > Do you use the Function Probe block in GRC? Or is there any other way to > make it tune without ending the Flow-Graph? > > Best, > Marius > > > ___ > 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] How to use USRP device MAC address in python code
I am working with GNURadio 3.5, UHD_003.004.000-287958b and USRP N210 running WBX daughterboards. I need to access and use the device's MAC address from my python code. On browsing through the documentation, I found the following class *usrp2_base* in Gnuradio 3.4.2 has a method *mac_addr()*to get the USRP2 hardware MAC address. Is there an equivalent method in UHD? If so, how can it be invoked from python code? -- Dhrubojyoti Roy 1655, North 4th Street, Apt-D Columbus, OH-43201 Contact no.: +1-740-417-5890 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to use USRP device MAC address in python code
On Thu, Feb 9, 2012 at 4:43 PM, Dhrubojyoti Roy wrote: > I am working with GNURadio 3.5, UHD_003.004.000-287958b and USRP N210 > running WBX daughterboards. I need to access and use the device's MAC > address from my python code. On browsing through the documentation, I found > the following class *usrp2_base* in Gnuradio 3.4.2 has a method * > mac_addr()* to get the USRP2 hardware MAC address. Is there an equivalent > method in UHD? If so, how can it be invoked from python code? > Use the "arp" utility, and parse the output. nick@smidgen:~$ arp 192.168.10.2 Address HWtype HWaddress Flags Mask Iface 192.168.10.1 ether 20:cf:30:ae:00:c1 C wlan0 --n > > > -- > Dhrubojyoti Roy > 1655, North 4th Street, Apt-D > Columbus, OH-43201 > Contact no.: +1-740-417-5890 > > > ___ > 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] dbpsk demodulation
On Thu, Feb 9, 2012 at 12:47 PM, anay tuljapurkar < anay.tuljapur...@gmail.com> wrote: > Hey, > > Apologies if this is a duplicate but i found this is my drafts while > i thought i got delivered. > > I having been trying to debug my demodulator for a few days now and > in due process i receive the following error message. > > ValueError: itemsize mismatch : dbpsk_demod(5):0 using 1, sub_ff(15):0 > using 4. > > Now there are two things that i observed. > 1) With the connect statement of these two at hand , sub_ff is expecting 4 > float bytes which is only connected to "1 byte/sample" output by the > dbpsk_demod block. > > 2) The output of the dbpsk_demod block (according to the line -- > > io_sig_out = gr.io_signature(1,1,gr.sizeof_char) .. so its a > dbpsk_demod_complex->character conversion where as the sub_ff is a "float > --> float " . > > My question is will a custom "gr_dbpsk_demod_cf" with a cosine > function(that possibly uses a certain kind of cosine table) be useful to do > the following : > > 1) keep the constellation in check (i.e 1 bit/symbol) at 0 and 180 degrees > respectively. > 2) ofcourse convert a complex to float. > 3) How effective would such a cpp block be as opposed to a full fledged > python block ? > > Thanks & regards, > Anay. > Anay, It's not clear what you really want to do here. If you want to work on the samples as floats, you could probably just edit the Python hier_block2 file for what you want (or create a duplicate for your needs). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Quetion regarding crc checks .
On Mon, Jan 30, 2012 at 12:24 PM, anay tuljapurkar < anay.tuljapur...@gmail.com> wrote: > Dear all, > I am currently working on a gnuradio project and i was wondering if > anybody could please share some information about how crc checks are made. > As in when one makes a crc32 call from ones python script , in crc.py it > says the following > > crc = digital_swig.crc32(s) > > and there after it makes a call to _digital_swig.crc32. I dont fully > understand the "behind the scene operation" of "_digital_swig" . I > understand that its a library associated file but its operation is what i > cannot fully comprehend. Does it help make a call to digital_crc32.cc file > which has all the underlying code. > > I would be awfully obliged if somebody were to spare sometime and help out > in this regard. > > Thanks, > Anay. > Anay, Yes, the CRC is implemented in C++ and wrapped into Python using SWIG. The actual Python module is digital_swig (which then gets exposed to the outside as the 'digital' module). The _digital_swig is the library call made behind the scenes. No one really needs to know anything about that, though. So yes, if you are interested in the operation of the CRC block, look at digtial_crc32.cc in gr-digital/lib. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
