Re: [Discuss-gnuradio] Unexpected energy peak sensing thermal noise and using usrp_spectrum_sense.py
Thank you for answering but I cannot understand what you mean with The USRP is not a measurement receiver. If USRP was not a measurement receiver, which is its utility? Moreover, if it is not a measurement receiver what is the result memorized in m.data that is the output of usrp_spectrum_sense.py? When I use a WiFi antenna I can receive (and measure) the energy of WiFi channels. The problem arises without antenna becasue USRP measures a signal that cannot exist! Furthermore, such a signal is always at the beginning of the sensed bandwidth, so this has not any sense! Any idea about that? Thank you! Nick Foster-4 wrote: On Wed, 2011-05-25 at 08:51 -0700, Lebowski80 wrote: Hello everyone I’m using an USRP with a XCVR2450 daughter board working at 2.4 - 2.5 GHz. I want to find a threshold between thermal noise and signals energy using the script usrp_spectrum_sense.py and sensing from 2.400 GHz to 2.500 GHz. To do that, I replaced the WiFi antenna with a resistor of 50 Ω to measure the noise. I obtained a very strange peak at the beginning of the bandwidth (around 2.405 GHz) and this result was totally unexpected because I supposed to sense only thermal noise without any particular peak. So, I repeated the experiment from 2.420 GHz to 2.500 GHz and I achieved the same peak always at the beginning of the bandwidth (in this case around 2.425 GHz). Therefore, I'm quite sure this is a problem linked to USRP or to the script usrp_spectrum_sense.py, isn’t it? Can someone give me a hint about that please? The USRP is not a measurement receiver, and some small spurs are to be expected. You can plan for this, or work around it by changing the LO offset at a given center frequency using the advanced tuning parameters: http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__request__t.html --n Regards ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Unexpected-energy-peak-sensing-thermal-noise-and-using-usrp_spectrum_sense.py-tp31700266p31705762.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] How to hexdump in gnuradio realtime
Hi guys, First of all my apologies for my bad English. I am a Dutch student and for a internship I use GNURadio. For test purposes I want to show the hexadecimals values of a stream of chars realtime (while running). I don't want to use 'printf' in the c-code of a block because sometimes it messes up the order of printing. What I want to use is some kind of terminal what shows the hexadecimals values. In GNURadio I saw a block named terminal sink, but I couldn't figure out how to use it. My question is as follows: Is there any way to show hexadecimal numbers in some kind of terminal realtime? Hopefully you understand my question and know an answer. Best regards, Nimsi ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to hexdump in gnuradio realtime
On Thu, May 26, 2011 at 07:55:33AM +, nimsi stouwdam wrote: Hi guys, First of all my apologies for my bad English. I am a Dutch student and for a internship I use GNURadio. For test purposes I want to show the hexadecimals values of a stream of chars realtime (while running). I don't want to use 'printf' in the c-code of a block because sometimes it messes up the order of printing. What I want to use is some kind of terminal what shows the hexadecimals values. In GNURadio I saw a block named terminal sink, but I couldn't figure out how to use it. My question is as follows: Is there any way to show hexadecimal numbers in some kind of terminal realtime? Hopefully you understand my question and know an answer. I'm not sure... you want to print the hex values of chars, but *not* on the same output as your regular stdout? Try this: - Make a new block that converts chars to ASCII-hex (e.g. w/ sprintf) - Connect that block to a gr_file_sink (or a gr_file_descriptor_sink), and write to a file (or a named pipe). - When the flowgraph is running, open a separate xterm, and in there, do a 'tail -f FILENAME' (or 'cat PIPENAME'). The file approach will create a massive big text file, but perhaps you want that. 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 pgpio6530DiqJ.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building gnuradio 3.3.0 on Fedora 15 (issue with SDCC)
On Thu, May 26, 2011 at 3:08 AM, Marcus D. Leech mle...@ripnet.com wrote: On 05/25/2011 09:01 PM, Arturo Rinaldi wrote: i have an issue regarding the SDCC executable in the building of gnuradio 3.3.0 on Fedora 15. I set up the PATH in my *.bashrc* file as : *export PATH=/usr/libexec/sdcc:$PATH *as written in the build guide but I still get the error in the configure process : *USRP requires sdcc. sdcc not found. See http://sdcc.sf.net Unable to find firmware compiler SDCC. Not building component usrp.* Where am i wrong ? If I launch from terminal *$ sdcc -v * it returns : *$ SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 3.0.0 #6037 (Apr 13 2011) (Linux)* thx in advance. All the others pre-requisites are fully satisfied. Regards, Arturo. A few points: If you're using UHD, you don't need component USRP. Since Fedora 14, they have shipped SDCC version 3.0 which has different command names, and also some difference syntax for built-in variable-type intrinsics, so the USRP1 firmware won't build under SDCC-3.0 anyway. The configure script for Gnu Radio looks for SDCC using the SDCC version 2.X command names, and so for a system with SDCC 3.0, this will fail. But, once again, if you're using UHD (which I *strongly* recommend), you don't need the component usrp and gr-usrp to be built anyway. I haven't upgraded any of my systems to F15 yet, but when I do, expect the famous (almost!) build-gnuradio script to get updated to deal with F15. -- Principal Investigator Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org And if you do really want to get the usrp and gr-usrp components to build, you should be able to easily install a 2.9 version of SDCC. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tuesday, 24th May sample volcanic ash image
Very cool, Patrik, thanks for posting! Tom On Wed, May 25, 2011 at 7:10 PM, Patrik Tast pat...@poes-weather.comwrote: Yep, Patrik - Original Message - From: Alexandru Csete oz9...@gmail.com To: Discuss-gnuradio@gnu.org Sent: Wednesday, May 25, 2011 19:39 Subject: Re: [Discuss-gnuradio] Tuesday, 24th May sample volcanic ash image On Wed, May 25, 2011 at 2:21 PM, Patrik Tast pat...@poes-weather.com wrote: Just FYI, to encourage GNURadio users, Received using GR USRP1 + TVRX (traditional, no uhd). Satellite Feng Yun channel-6 HRPT (1km resolution) gray-scale unprocessed image showing volcanic ash cloud entering Scandinavian airspace on Tuesday 24th May @ 1350Z http://www.poes-weather.com/downloads/Iceland-Ash-Cloud/Tue-May-24-2011/2011-05-24T164949-FENGYUN-1D-CH-6.jpg Amazing! So this is received using gr-noaa package and your GUI? Alex ___ 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] How to hexdump in gnuradio realtime
Hi, Thank you for the fast reply. I will try what you suggested. I will let you know if it worked. regards Nimsi Date: Thu, 26 May 2011 11:12:51 +0200 From: martin.br...@kit.edu To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] How to hexdump in gnuradio realtime On Thu, May 26, 2011 at 07:55:33AM +, nimsi stouwdam wrote: Hi guys, First of all my apologies for my bad English. I am a Dutch student and for a internship I use GNURadio. For test purposes I want to show the hexadecimals values of a stream of chars realtime (while running). I don't want to use 'printf' in the c-code of a block because sometimes it messes up the order of printing. What I want to use is some kind of terminal what shows the hexadecimals values. In GNURadio I saw a block named terminal sink, but I couldn't figure out how to use it. My question is as follows: Is there any way to show hexadecimal numbers in some kind of terminal realtime? Hopefully you understand my question and know an answer. I'm not sure... you want to print the hex values of chars, but *not* on the same output as your regular stdout? Try this: - Make a new block that converts chars to ASCII-hex (e.g. w/ sprintf) - Connect that block to a gr_file_sink (or a gr_file_descriptor_sink), and write to a file (or a named pipe). - When the flowgraph is running, open a separate xterm, and in there, do a 'tail -f FILENAME' (or 'cat PIPENAME'). The file approach will create a massive big text file, but perhaps you want that. 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 ___ 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] Building gnuradio 3.3.0 on Fedora 15 (issue with SDCC)
On either my Ubuntu box or my Fedora box, 2.9.0 fails. I used 2.8.0 and all is well. I get it from sdcc sourceforge site and was done in a few minutes. Bob On May 26, 2011 6:15 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Thu, May 26, 2011 at 3:08 AM, Marcus D. Leech mle...@ripnet.com wrote: On 05/25/2011 09:01 PM, Arturo Rinaldi wrote: i have an issue regarding the SDCC executable in the building of gnuradio 3.3.0 on Fedora 15. I set up the PATH in my *.bashrc* file as : *export PATH=/usr/libexec/sdcc:$PATH *as written in the build guide but I still get the error in the configure process : *USRP requires sdcc. sdcc not found. See http://sdcc.sf.net Unable to find firmware compiler SDCC. Not building component usrp.* Where am i wrong ? If I launch from terminal *$ sdcc -v * it returns : *$ SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 3.0.0 #6037 (Apr 13 2011) (Linux)* thx in advance. All the others pre-requisites are fully satisfied. Regards, Arturo. A few points: If you're using UHD, you don't need component USRP. Since Fedora 14, they have shipped SDCC version 3.0 which has different command names, and also some difference syntax for built-in variable-type intrinsics, so the USRP1 firmware won't build under SDCC-3.0 anyway. The configure script for Gnu Radio looks for SDCC using the SDCC version 2.X command names, and so for a system with SDCC 3.0, this will fail. But, once again, if you're using UHD (which I *strongly* recommend), you don't need the component usrp and gr-usrp to be built anyway. I haven't upgraded any of my systems to F15 yet, but when I do, expect the famous (almost!) build-gnuradio script to get updated to deal with F15. -- Principal Investigator Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org And if you do really want to get the usrp and gr-usrp components to build, you should be able to easily install a 2.9 version of SDCC. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building gnuradio 3.3.0 on Fedora 15 (issue with SDCC)
Il 26/05/2011 13:05, Robert McGwier ha scritto: On either my Ubuntu box or my Fedora box, 2.9.0 fails. I used 2.8.0 and all is well. I get it from sdcc sourceforge site and was done in a few minutes. Bob On May 26, 2011 6:15 AM, Tom Rondeau trondeau1...@gmail.com mailto:trondeau1...@gmail.com wrote: On Thu, May 26, 2011 at 3:08 AM, Marcus D. Leech mle...@ripnet.com mailto:mle...@ripnet.com wrote: On 05/25/2011 09:01 PM, Arturo Rinaldi wrote: i have an issue regarding the SDCC executable in the building of gnuradio 3.3.0 on Fedora 15. I set up the PATH in my *.bashrc* file as : *export PATH=/usr/libexec/sdcc:$PATH *as written in the build guide but I still get the error in the configure process : *USRP requires sdcc. sdcc not found. See http://sdcc.sf.net Unable to find firmware compiler SDCC. Not building component usrp.* Where am i wrong ? If I launch from terminal *$ sdcc -v * it returns : *$ SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 3.0.0 #6037 (Apr 13 2011) (Linux)* thx in advance. All the others pre-requisites are fully satisfied. Regards, Arturo. A few points: If you're using UHD, you don't need component USRP. Since Fedora 14, they have shipped SDCC version 3.0 which has different command names, and also some difference syntax for built-in variable-type intrinsics, so the USRP1 firmware won't build under SDCC-3.0 anyway. The configure script for Gnu Radio looks for SDCC using the SDCC version 2.X command names, and so for a system with SDCC 3.0, this will fail. But, once again, if you're using UHD (which I *strongly* recommend), you don't need the component usrp and gr-usrp to be built anyway. I haven't upgraded any of my systems to F15 yet, but when I do, expect the famous (almost!) build-gnuradio script to get updated to deal with F15. -- Principal Investigator Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org http://www.sbrac.org And if you do really want to get the usrp and gr-usrp components to build, you should be able to easily install a 2.9 version of SDCC. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio thank you very much to all of you. I'll do my test on my Fedora 15 system as soon as possible. I think the best solution is to build 2.9.0-7 from source and then install. @ Bob never experienced any issue on Ubuntu with sdcc 2.9.0-5. I also remember that building from source on a Fedora 14 worked well like described in the guide on the gnuradio website. Best Regards to all, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unexpected energy peak sensing thermal noise and using usrp_spectrum_sense.py
Thank you for answering but I cannot understand what you mean with The USRP is not a measurement receiver. If USRP was not a measurement receiver, which is its utility? Moreover, if it is not a measurement receiver what is the result memorized in m.data that is the output of usrp_spectrum_sense.py? When I use a WiFi antenna I can receive (and measure) the energy of WiFi channels. The problem arises without antenna becasue USRP measures a signal that cannot exist! Furthermore, such a signal is always at the beginning of the sensed bandwidth, so this has not any sense! Any idea about that? Thank you! You should perhaps do some diagnosis using something other than spectrum_sense.py. Try a simple FFT display with your tuner tuned to different frequencies. Does an apparent spur appear in those cases as well? A general observation is that essentially-all receivers will experience spurs in the RF, IF and occasionally baseband stages. These are internally-generated, small, signals narrowband in nature that come from the internal operations of the receiver itself. A measurement receiver is one that has been engineered specifically to drastically reduce spurs, and also to have a *calibrated* (as in laboratory-quality calibrated) response that is predictable, specified, and flat across the entire tunable bandwidth of the receiver. Providing that kind of functionality requires design and *construction* techniques that are very, very, expensive. However, that doesn't mean that the hardware can't be used for measurement, you just have to be aware of things like changes in response at different frequencies, and calibrate them yourself. I would suggest that you use a simple FFT display at various frequencies to help with diagnosis. -- 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] Building gnuradio 3.3.0 on Fedora 15 (issue with SDCC)
On Thu, May 26, 2011 at 12:31 PM, Arturo Rinaldi arty.n...@gmail.comwrote: Il 26/05/2011 13:05, Robert McGwier ha scritto: On either my Ubuntu box or my Fedora box, 2.9.0 fails. I used 2.8.0 and all is well. I get it from sdcc sourceforge site and was done in a few minutes. Bob On May 26, 2011 6:15 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Thu, May 26, 2011 at 3:08 AM, Marcus D. Leech mle...@ripnet.com wrote: On 05/25/2011 09:01 PM, Arturo Rinaldi wrote: i have an issue regarding the SDCC executable in the building of gnuradio 3.3.0 on Fedora 15. I set up the PATH in my *.bashrc* file as : *export PATH=/usr/libexec/sdcc:$PATH *as written in the build guide but I still get the error in the configure process : *USRP requires sdcc. sdcc not found. See http://sdcc.sf.net Unable to find firmware compiler SDCC. Not building component usrp.* Where am i wrong ? If I launch from terminal *$ sdcc -v * it returns : *$ SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 3.0.0 #6037 (Apr 13 2011) (Linux)* thx in advance. All the others pre-requisites are fully satisfied. Regards, Arturo. A few points: If you're using UHD, you don't need component USRP. Since Fedora 14, they have shipped SDCC version 3.0 which has different command names, and also some difference syntax for built-in variable-type intrinsics, so the USRP1 firmware won't build under SDCC-3.0 anyway. The configure script for Gnu Radio looks for SDCC using the SDCC version 2.X command names, and so for a system with SDCC 3.0, this will fail. But, once again, if you're using UHD (which I *strongly* recommend), you don't need the component usrp and gr-usrp to be built anyway. I haven't upgraded any of my systems to F15 yet, but when I do, expect the famous (almost!) build-gnuradio script to get updated to deal with F15. -- Principal Investigator Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org And if you do really want to get the usrp and gr-usrp components to build, you should be able to easily install a 2.9 version of SDCC. Tom ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio thank you very much to all of you. I'll do my test on my Fedora 15 system as soon as possible. I think the best solution is to build 2.9.0-7 from source and then install. @ Bob never experienced any issue on Ubuntu with sdcc 2.9.0-5. I also remember that building from source on a Fedora 14 worked well like described in the guide on the gnuradio website. Best Regards to all, Arturo Thanks all. I've built using SDCC 2.9.0 in Ubuntu, which is the native version in 11.04, with no problems. So I didn't build or install it from another package. If someone else is having issues with a 2.9 version and can confirm Bob's problem, let me know. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
On 26/05/2011 9:55 AM, Michael Dickens wrote: It would be great if you could share with the list example code snippets of how you do the pipes. For example: Where in an online repository one can find such code. I think that's what Jeff was getting at: that we are providing IANAL advice rather than code examples. I, for one, have never actually tried the pipes -- I've just heard that they are possible and that using them does not form a greater work in the GPL sense. - MLD ___ Actually, my SIDSuite code uses this a little bit, in that data recording is handled outside of Gnu Radio. The basic idea is that there's a shell script that sets up the environment (creates the FIFO files, starts the external programs in the background, etc), then the Gnu Radio flow-graph is called. The flow-graphs just use File Source and File Sink with buffering turned off--as far as Gnu Radio is concerned, it's writing to a file, but in fact, it's a FIFO file or named pipe. See: http://www.sbrac.org/files/sidsuite.tar.gz It doesn't do it as much as other code that I've written, but it gives one a flavour for how the pipes are used. The other trick that I use is to use the XMLRPC server stuff that Josh put in GRC--it allows you to set flowgraph variables from an outside program, which is really great! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Reconfigure example with lock/disconnect/connect/unlock code hangs randomly
Hey guys, I have written some example code to learn how to dynamically reconfigure gnuradio based on events generated by probe blocks and a watcher thread. First I thought everything is running very well but later I noticed that the program hangs if you let it run long enough. If you uncomment the sleep(0.0001) it seems to be working fine but says: Exception in thread Thread-1 (most likely raised during interpreter shutdown) We are running Ubuntu 10.10 over here. Can somebody please run the code and confirm this? Looks like a bug for me. --- #!/usr/bin/env python from gnuradio import gr import gnuradio.gr.gr_threading as _threading from time import sleep class h_block_one(gr.hier_block2): def __init__(self): gr.hier_block2.__init__(self, foo, gr.io_signature(0, 0, 0), gr.io_signature(0, 0, 0)) vec = range(100) self.source = gr.vector_source_f(vec,True,1) self.probe = gr.probe_signal_f() self.sink = gr.null_sink(gr.sizeof_float) self.connect(self.source, self.probe) def level_one(self): return self.probe.level() class h_block_two(gr.hier_block2): def __init__(self): gr.hier_block2.__init__(self, bar, gr.io_signature(0, 0, 0), gr.io_signature(0, 0, 0)) vec = range(100) self.source = gr.vector_source_f(vec,True,1) self.probe = gr.probe_signal_f() self.sink = gr.null_sink(gr.sizeof_float) self.connect(self.source, self.probe) def level_two(self): return self.probe.level() class probe_this(gr.top_block): def __init__(self): gr.top_block.__init__(self, 'Probe Reconfigure Test') self.h_block_one = h_block_one() self.h_block_two = h_block_two() self.connect(self.h_block_one) def level_one(self): return self.h_block_one.level_one() def level_two(self): return self.h_block_two.level_two() def reconfigure(self): self.lock() self.disconnect(self.h_block_one) self.connect(self.h_block_two) self.unlock() def conf_back(self): self.lock() self.disconnect(self.h_block_two) self.connect(self.h_block_one) #sleep(0.0001) self.unlock() class _probe_watcher_thread(_threading.Thread): def __init__(self, level_one, reconfigure, level_two, conf_back): _threading.Thread.__init__(self) self.setDaemon(1) self.level_one = level_one self.reconfigure = reconfigure self.level_two = level_two self.conf_back = conf_back self.confed = False self.keep_running = True self.start() def run(self): while self.keep_running: if self.confed: if self.level_two() 50: self.conf_back() self.confed = False print 'reconfiguring' else: if self.level_one() 50: self.reconfigure() self.confed = True print 'reconfiguring back' #if self.level_one and self.level_two: #print 'foo', self.level_one() #print 'bar', self.level_two() if __name__==__main__: def callback(msg): print 'received:', msg tb = probe_this() watcher = _probe_watcher_thread(tb.level_one,tb.reconfigure,tb.level_two,tb.conf_back) tb.start() sleep(100) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reconfigure example with lock/disconnect/connect/unlock code hangs randomly
There should be another sleep in the reconfigure method to make it working fine. def reconfigure(self): self.lock() self.disconnect(self.h_block_one) self.connect(self.h_block_two) sleep(0.0001) self.unlock() I am not sure how long we have to sleep in order to fix the problem. - Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Signal Generator synced to PPS Reference wave
Has anyone made a Signal generator that can be synced to the PPS, and 10MHz input? -- Thank you, Sam Price (707) 742-3726 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Store data with usrp_spectrum_sense.py
I did a project similar to this. Look at this structure m = parse_msg(tb.msgq.delete_head()) There is a field called data (I think) that contains the magnitude of the sweep. You record m.data to a file (like a csv, hdf5, or binary file). Keep in mind that you have to do the equivalent of fftshift. Hope that helps. On Sat, May 21, 2011 at 2:04 PM, Miguel Angel Sanz Rodriguez mikys...@hotmail.com wrote: Hi everyone, I am new in GNUradio and I want to sense the spectrum of Wifi from 2.4G to 2.5 G with a USRP. I have been reading through a lot of discussions in the forum but I have not been able to store any data using usrp_spectrum_sense.py. I want to analyze this data with matlab, but I dont get any suitable file after running spectrum sense. I know that I have to modify the script, but I dont know how. I am quite bad at programming, so I would appreciate so much a way to find the solution(it must be very easy, but I am usless in programming) Thanks in advance for your help ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- http://users.wpi.edu/~dkelly/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to speed up spectrum sensing?
Changing the fft size won't change your sensing time that much unless the machine you're using is really slow or the fft size is outrageous. What fft sizes are you using? What will affect your sensing time more is the sampling/decimation rate you sent, the tune delay, and the dwell delay. Be careful when changing the tune delay, if it is too short your data will be corrupted. Look at the usrp_spectrum_sense.py code and try this: $ python usrp_spectrum_sense.py --help Also, since you're only trying to look at a narrow band, usrp_spectrum_sense.py isn't for you. This script is really for looking at different bands and different times, but you really only need to look at one band. Basically, you never need to retune and a lot of that script does is retune. Devin On Sat, May 14, 2011 at 8:11 AM, Alexander Chemeris alexander.cheme...@gmail.com wrote: On Fri, May 13, 2011 at 14:25, Tom Rondeau trondeau1...@gmail.com wrote: On Fri, May 13, 2011 at 11:12 AM, Yang yyl@gmail.com wrote: Hi all, I am working on the implementation of dynamic spectrum access with gnuradio and usrp2. I modified usrp_spectrum_sense for usrp2 to do the sensing job. However, I find the sensing speed is intolerably slow, which is about 1s for 1MHz. Yang, Considering that the USRP2 can sample 25 MHz, you should be able to capture that bandwidth instantaneously. Note, that while USRP2 can sample 25MHz, you probably can't receive that much in your PC. I'm working with USRP N210 and having troubles with receiving even 16 MSPS. -- Regards, Alexander Chemeris. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- http://users.wpi.edu/~dkelly/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion
USRP1: - When we have a very simple flowgraph with a USRP1 sink connected to a signal source and a USRP1 source connected to a WX scope- trying to shut down the app using the close box causes the USB on the host system to freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids this problem. This problem exists on many flowgraphs, both GRC generated and not- as far as I know it is limited to flowgraphs with both USRP1 source and sink. This is a serious problem that has hit us on multiple platforms and machines and causes unnecessary reboots. It is honestly an unacceptable bug. USRP2 / UHD: - With a similar flowgraph to the one above, changing the secs/div causes the various traces to change phase relative to one another but this doesn't happen when a USRP1 source is substituted. However, I believe this is indicative of a deeper problem. We also see with the same flowgraph and a slider that controls both the TX and RX frequencies simultaneously, the flowgraph gets into a place where it seems to be getting data but it no longer represents the state of what's coming in and we also see the phase slippage. Long story short, create a flowgraph with a UHD (USRP2) sink and source with a siggen at a fixed frequency/amplitude, a wx scope, and a slider that sets the TX+RX frequencies to the slider value. Direct connect the TX to the RX with an SMA cable. Run the flowgraph and move the slider. At least on LFTX/RX this seems to give various results. Do the same thing with a USRP1 for comparison. To me it seems like UHD is losing data or the various paths in the flowgraph get out of whack with eachother. There were no O's or U's printed. We were trying to do a simple VNA in UHD and it just doesn't work as expected, but switching it all over to a USRP1 its fine and dandy. On a general note- I think there should be two new block sets added: 1) A simple source block that provides samples in the appropriate format (float, complex, etc depending on the _f / _c etc) which generates as fast as possible and counts how many it generates in a second which gets output on a float output. 2) The same thing but a consumer. The idea being it would help diagnose blocks that end up putting out more or less data than they take in and whose decimation/interpolation rates aren't apparent. For instance, I have a decimating filter block that appears to actually be producing more samples than it takes in, causing the data to show up almost 30 seconds later on the scope which is set at the source's data rate. I'd love to put the timed consumer and timed provider blocks on either side and see how the in/out amounts compare. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to speed up spectrum sensing?
Thank you for replying. I have already tried different fft size (256, 128, 32, etc) but as you said it did not change my sensing time. I also change my decimation but no luck too. I intend to sense a broad band, say, 20M or 40M. But it seems this script costs too much time working. Should I retune or not? Because if I do not it only sense a very narrow band. -- Yang Sent with Sparrow On 2011年5月27日星期五 at 上午4:15, devin kelly wrote: Changing the fft size won't change your sensing time that much unless the machine you're using is really slow or the fft size is outrageous. What fft sizes are you using? What will affect your sensing time more is the sampling/decimation rate you sent, the tune delay, and the dwell delay. Be careful when changing the tune delay, if it is too short your data will be corrupted. Look at the usrp_spectrum_sense.py code and try this: $ python usrp_spectrum_sense.py --help Also, since you're only trying to look at a narrow band, usrp_spectrum_sense.py isn't for you. This script is really for looking at different bands and different times, but you really only need to look at one band. Basically, you never need to retune and a lot of that script does is retune. Devin On Sat, May 14, 2011 at 8:11 AM, Alexander Chemeris alexander.cheme...@gmail.com wrote: On Fri, May 13, 2011 at 14:25, Tom Rondeau trondeau1...@gmail.com wrote: On Fri, May 13, 2011 at 11:12 AM, Yang yyl@gmail.com wrote: Hi all, I am working on the implementation of dynamic spectrum access with gnuradio and usrp2. I modified usrp_spectrum_sense for usrp2 to do the sensing job. However, I find the sensing speed is intolerably slow, which is about 1s for 1MHz. Yang, Considering that the USRP2 can sample 25 MHz, you should be able to capture that bandwidth instantaneously. Note, that while USRP2 can sample 25MHz, you probably can't receive that much in your PC. I'm working with USRP N210 and having troubles with receiving even 16 MSPS. -- Regards, Alexander Chemeris. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- http://users.wpi.edu/~dkelly/ ___ 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] USRP1 problem, UHD problem, and one suggestion
On Thu, 2011-05-26 at 19:29 -0500, Brett L. Trotter wrote: USRP1: - When we have a very simple flowgraph with a USRP1 sink connected to a signal source and a USRP1 source connected to a WX scope- trying to shut down the app using the close box causes the USB on the host system to freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids this problem. This problem exists on many flowgraphs, both GRC generated and not- as far as I know it is limited to flowgraphs with both USRP1 source and sink. This is a serious problem that has hit us on multiple platforms and machines and causes unnecessary reboots. It is honestly an unacceptable bug. UHD or gr-usrp? What OS? What version of libusb? Do all USB devices freeze or just the USRP? Does power cycling the USRP un-freeze it? This is definitely not something I've seen before. USRP2 / UHD: - With a similar flowgraph to the one above, changing the secs/div causes the various traces to change phase relative to one another but this doesn't happen when a USRP1 source is substituted. However, I believe this is indicative of a deeper problem. We also see with the same flowgraph and a slider that controls both the TX and RX frequencies simultaneously, the flowgraph gets into a place where it seems to be getting data but it no longer represents the state of what's coming in and we also see the phase slippage. Long story short, create a flowgraph with a UHD (USRP2) sink and source with a siggen at a fixed frequency/amplitude, a wx scope, and a slider that sets the TX+RX frequencies to the slider value. Direct connect the TX to the RX with an SMA cable. Run the flowgraph and move the slider. At least on LFTX/RX this seems to give various results. Do the same thing with a USRP1 for comparison. To me it seems like UHD is losing data or the various paths in the flowgraph get out of whack with eachother. There were no O's or U's printed. If you lose samples somewhere in the chain, which can happen, the TX and RX paths will change their relative alignment. Have you tried reducing your sample rate, or the refresh rate on the graphical sink? The various graphical sinks can be very CPU-intensive. It is generally not a great idea to rely on the TX and RX paths staying aligned with respect to each other all the time. The fact that the USRP1 seems to in your test is a bonus, but I wouldn't rely on that going forward either. If you require the TX and RX paths to maintain a fixed relationship, the USRP2 with UHD will let you use timed samples to achieve this down to 10ns. You could also align your TX and RX paths in your application, using known TX waveforms to correlate the RX against. This approach probably fits best into your design flow (don't have to code C++ with UHD). --n We were trying to do a simple VNA in UHD and it just doesn't work as expected, but switching it all over to a USRP1 its fine and dandy. On a general note- I think there should be two new block sets added: 1) A simple source block that provides samples in the appropriate format (float, complex, etc depending on the _f / _c etc) which generates as fast as possible and counts how many it generates in a second which gets output on a float output. 2) The same thing but a consumer. The idea being it would help diagnose blocks that end up putting out more or less data than they take in and whose decimation/interpolation rates aren't apparent. For instance, I have a decimating filter block that appears to actually be producing more samples than it takes in, causing the data to show up almost 30 seconds later on the scope which is set at the source's data rate. I'd love to put the timed consumer and timed provider blocks on either side and see how the in/out amounts compare. This is a cool idea, but I'm not sure how it could be implemented in Gnuradio's scheduler. I'll have to think about that one. --n ___ 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] about signal process window design?
Hi all: When I try to implement some spectrum estimate algorithm encounter a problem like this hope some one can help me out ,cause I really don't understand how to design the window in window.py which I have post below or in the attachment. please help me figure out the midn(fft_size) ?problem Thanks all! God bless you! File usrp_welch_rt.py, line 327, in module main () File usrp_welch_rt.py, line 323, in main app = stdgui2.stdapp(app_top_block, USRP Welch, nstatus=1) File /usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py, line 36, in __init__ wx.App.__init__ (self, redirect=False) File /usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py, line 7978, in __init__ self._BootstrapApp() File /usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py, line 7552, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File /usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py, line 39, in OnInit frame = stdframe (self.top_block_maker, self.title, self._nstatus) File /usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py, line 60, in __init__ self.panel = stdpanel (self, self, top_block_maker) File /usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py, line 81, in __init__ self.top_block = top_block_maker (frame, self, vbox, sys.argv) File usrp_welch_rt.py, line 136, in __init__ mywindow1 = window.blackman2(options.fft_size) File /usr/local/lib/python2.6/dist-packages/gnuradio/window.py, line 102, in blackman2 for index in xrange(midn(fft_size)+1): NameError: global name 'midn' is not defined window.py content below: ''' Routines for designing window functions. ''' import math from gnuradio import gr def izero(x): izeroepsilon = 1e-21 halfx = x/2.0 accum = u = n = 1 while 1: temp = halfx/n n += 1 temp *= temp u *= temp accum += u if u = IzeroEPSILON*sum: break return accum def midm1(fft_size): return (fft_size - 1)/2 def midp1(fft_size): return (fft_size+1)/2 def freq(fft_size): return 2.0*math.pi/fft_size def rate(fft_size): return 1.0/(fft_size 1) def expn(fft_size): math.log(2.0)/(midn(fft_size) + 1.0) def hamming(fft_size): window = [] for index in xrange(fft_size): window.append(0.54 - 0.46 * math.cos (2 * math.pi / fft_size * index)) # Hamming window return window def hanning(fft_size): window = [] for index in xrange(fft_size): window.append(0.5 - 0.5 * math.cos (2 * math.pi / fft_size * index)) # von Hann window return window def welch(fft_size): window = [0 for i in range(fft_size)] j = fft_size-1 for index in xrange(midn(fft_size)+1): window[j] = window[index] = (1.0 - math.sqrt((index - midm1(fft_size)) / midp1(fft_size))) j -= 1 return window def parzen(fft_size): window = [0 for i in range(fft_size)] j = fft_size-1 for index in xrange(midn(fft_size)+1): window[j] = window[index] = (1.0 - math.abs((index - midm1(fft_size)) / midp1(fft_size))) j -= 1 return window def bartlett(fft_size): mfrq = freq(fft_size) angle = 0 window = [0 for i in range(fft_size)] j = fft_size-1 for index in xrange(midn(fft_size)+1): window[j] = window[index] = angle angle += freq j -= 1 return window def blackman2(fft_size): mfrq = freq(fft_size) angle = 0 window = [0 for i in range(fft_size)] j = fft_size-1 for index in xrange(midn(fft_size)+1): cx = math.cos(angle) window[j] = window[index] = (.34401 + (cx * (-.49755 + (cx * .15844 angle += freq j -= 1 return window def blackman3(fft_size): mfrq = freq(fft_size) angle = 0 window = [0 for i in range(fft_size)] j = fft_size-1 for index in xrange(midn(fft_size)+1): cx = math.cos(angle) window[j] = window[index] = (.21747 + (cx * (-.45325 + (cx * (.28256 - (cx * .04672)) angle += freq j -= 1 return window def blackman4(fft_size): mfrq = freq(fft_size) angle = 0 window = [0 for i in range(fft_size)] j = fft_size-1 for index in xrange(midn(fft_size)+1): cx = math.cos(angle) window[j] = window[index] = (.084037 + (cx * (-.29145 + (cx * (.375696 + (cx * (-.20762 + (cx * .041194 angle += freq j -= 1 return window def exponential(fft_size): expsum = 1.0 window = [0 for i in range(fft_size)] j = fft_size-1 for index in xrange(midn(fft_size)+1): window[j] = window[i] = (expsum - 1.0) expsum *= expn(fft_size) j -= 1 return window def riemann(fft_size): sr1 = freq(fft_size) window = [0 for i in range(fft_size)] j = fft_size-1 for index in xrange(midn(fft_size)): if index ==
Re: [Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion
Replying to self- here's another case on the USRP2/UHD- TX Path: Sig Source - UHD (USRP2) Sink RX Path: UHD (USRP2) Source - Band Pass Filter - Scope Sink It seems that any kind of filter, even with appropriate calculation of the rate coming out of the filter taking into account decimation will yield a very delayed signal on the scope sink. The same problem does not happen on USRP1 when the sinks are swapped out and the sample rates adjusted appropriately. On 05/26/2011 07:29 PM, Brett L. Trotter wrote: USRP1: - When we have a very simple flowgraph with a USRP1 sink connected to a signal source and a USRP1 source connected to a WX scope- trying to shut down the app using the close box causes the USB on the host system to freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids this problem. This problem exists on many flowgraphs, both GRC generated and not- as far as I know it is limited to flowgraphs with both USRP1 source and sink. This is a serious problem that has hit us on multiple platforms and machines and causes unnecessary reboots. It is honestly an unacceptable bug. USRP2 / UHD: - With a similar flowgraph to the one above, changing the secs/div causes the various traces to change phase relative to one another but this doesn't happen when a USRP1 source is substituted. However, I believe this is indicative of a deeper problem. We also see with the same flowgraph and a slider that controls both the TX and RX frequencies simultaneously, the flowgraph gets into a place where it seems to be getting data but it no longer represents the state of what's coming in and we also see the phase slippage. Long story short, create a flowgraph with a UHD (USRP2) sink and source with a siggen at a fixed frequency/amplitude, a wx scope, and a slider that sets the TX+RX frequencies to the slider value. Direct connect the TX to the RX with an SMA cable. Run the flowgraph and move the slider. At least on LFTX/RX this seems to give various results. Do the same thing with a USRP1 for comparison. To me it seems like UHD is losing data or the various paths in the flowgraph get out of whack with eachother. There were no O's or U's printed. We were trying to do a simple VNA in UHD and it just doesn't work as expected, but switching it all over to a USRP1 its fine and dandy. On a general note- I think there should be two new block sets added: 1) A simple source block that provides samples in the appropriate format (float, complex, etc depending on the _f / _c etc) which generates as fast as possible and counts how many it generates in a second which gets output on a float output. 2) The same thing but a consumer. The idea being it would help diagnose blocks that end up putting out more or less data than they take in and whose decimation/interpolation rates aren't apparent. For instance, I have a decimating filter block that appears to actually be producing more samples than it takes in, causing the data to show up almost 30 seconds later on the scope which is set at the source's data rate. I'd love to put the timed consumer and timed provider blocks on either side and see how the in/out amounts compare. ___ 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] USRP1 problem, UHD problem, and one suggestion
On 05/26/2011 08:06 PM, Nick Foster wrote: On Thu, 2011-05-26 at 19:29 -0500, Brett L. Trotter wrote: USRP1: - When we have a very simple flowgraph with a USRP1 sink connected to a signal source and a USRP1 source connected to a WX scope- trying to shut down the app using the close box causes the USB on the host system to freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids this problem. This problem exists on many flowgraphs, both GRC generated and not- as far as I know it is limited to flowgraphs with both USRP1 source and sink. This is a serious problem that has hit us on multiple platforms and machines and causes unnecessary reboots. It is honestly an unacceptable bug. UHD or gr-usrp? What OS? What version of libusb? Do all USB devices freeze or just the USRP? Does power cycling the USRP un-freeze it? This is definitely not something I've seen before. gr-usrp Ubuntu x86_64 with libusrp /usr/lib/libusb-0.1.so.4.4.4 RHEL-6 x86-64 with libusrp /usr/lib64/libusb-0.1.so.4.4.4 I believe I've also seen it on FC14 and RHEL5 USB devices continue to function, but it will not recognize new connection events of any device, the USRP will not reinitialize even if power cycled and reconnected, even to a different port. USRP2 / UHD: - With a similar flowgraph to the one above, changing the secs/div causes the various traces to change phase relative to one another but this doesn't happen when a USRP1 source is substituted. However, I believe this is indicative of a deeper problem. We also see with the same flowgraph and a slider that controls both the TX and RX frequencies simultaneously, the flowgraph gets into a place where it seems to be getting data but it no longer represents the state of what's coming in and we also see the phase slippage. Long story short, create a flowgraph with a UHD (USRP2) sink and source with a siggen at a fixed frequency/amplitude, a wx scope, and a slider that sets the TX+RX frequencies to the slider value. Direct connect the TX to the RX with an SMA cable. Run the flowgraph and move the slider. At least on LFTX/RX this seems to give various results. Do the same thing with a USRP1 for comparison. To me it seems like UHD is losing data or the various paths in the flowgraph get out of whack with eachother. There were no O's or U's printed. If you lose samples somewhere in the chain, which can happen, the TX and RX paths will change their relative alignment. Have you tried reducing your sample rate, or the refresh rate on the graphical sink? The various graphical sinks can be very CPU-intensive. It is generally not a great idea to rely on the TX and RX paths staying aligned with respect to each other all the time. The fact that the USRP1 seems to in your test is a bonus, but I wouldn't rely on that going forward either. If you require the TX and RX paths to maintain a fixed relationship, the USRP2 with UHD will let you use timed samples to achieve this down to 10ns. You could also align your TX and RX paths in your application, using known TX waveforms to correlate the RX against. This approach probably fits best into your design flow (don't have to code C++ with UHD). --n The alignment I'm talking about wasn't even relative between RX and TX- it was between branches of the RX path such as the real and imaginary components of that path when viewed on the scope. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion
USRP1: - When we have a very simple flowgraph with a USRP1 sink connected to a signal source and a USRP1 source connected to a WX scope- trying to shut down the app using the close box causes the USB on the host system to freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids this problem. This problem exists on many flowgraphs, both GRC generated and not- as far as I know it is limited to flowgraphs with both USRP1 source and sink. This is a serious problem that has hit us on multiple platforms and machines and causes unnecessary reboots. It is honestly an unacceptable bug. My intuition here is that the close box doesn't cause the flow-graph to do the usual finish the flow-graph thing. Which means that the USRP1 is still streaming, and nobody is listening. For the 'power off' case, the USRP1 resets itself, and stops streaming data, and for ctrl-C, there's built-in logic that causes the flow-graph to shutdown politely, and send a please stop streaming command to the USRP1. My suspicion about USB freeze-up is that the problem is due to the USB drivers in the kernel not doing the right thing with a deluge of data still arriving when nobody is actually listening. Which makes it a not-strictly-GnuRadio thing, and more of a USB drivers thing. Also, USB is inherently half-duplex, which may (somehow) play into scenarios like this--some kind of weird deadlock problem in the kernel USB drivers? USRP2 / UHD: - With a similar flowgraph to the one above, changing the secs/div causes the various traces to change phase relative to one another but this doesn't happen when a USRP1 source is substituted. However, I believe this is indicative of a deeper problem. We also see with the same flowgraph and a slider that controls both the TX and RX frequencies simultaneously, the flowgraph gets into a place where it seems to be getting data but it no longer represents the state of what's coming in and we also see the phase slippage. Long story short, create a flowgraph with a UHD (USRP2) sink and source with a siggen at a fixed frequency/amplitude, a wx scope, and a slider that sets the TX+RX frequencies to the slider value. Direct connect the TX to the RX with an SMA cable. Run the flowgraph and move the slider. At least on LFTX/RX this seems to give various results. Do the same thing with a USRP1 for comparison. To me it seems like UHD is losing data or the various paths in the flowgraph get out of whack with eachother. There were no O's or U's printed. We were trying to do a simple VNA in UHD and it just doesn't work as expected, but switching it all over to a USRP1 its fine and dandy. There's a tremendous amount of buffering inside a Gnu Radio flow-graph, which can easily cause *seconds* of latency. The buffer-sizing algorithm is complicated, and the buffering at any point in the graph is calculated by whatever is downstream, including decimators. I've long opined that the buffer-sizing (with its inherent latency) isn't actually correct all the time, but I admit to not having offered any meaningful solutions. I don't know whether UHD exacerbates this problem or not. -- 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] USRP1 problem, UHD problem, and one suggestion
On 05/26/2011 08:06 PM, Nick Foster wrote: The alignment I'm talking about wasn't even relative between RX and TX- it was between branches of the RX path such as the real and imaginary components of that path when viewed on the scope. So, you're talking about splitting I/Q for the same signal, and joining them later, and seeing phase slip on the scope? By default Gnu Radio now schedules each block in its own CPU thread. So there could be differences in instantaneous latencies down each path. -- 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] USRP1 problem, UHD problem, and one suggestion
By default Gnu Radio now schedules each block in its own CPU thread. So there could be differences in instantaneous latencies down each path. Also- whether a data is processed at the same time in terms of physical timeslices in the real world isn't so important, but by definition, gnuradio should assure that samples in various block arrive in order to the various things- so say in the simplest case you have a vector source with [1, 0] in it, and you have two sink blocks connected to it, each sink should receive 1,0,1,0 always. Make it more complicated, add a const multiplier (*2) in one of the two paths- one sink should receive 2,0,2,0... and the other should receive 1,0,1,0. My point is - in-order processing and sample order preservation and arrival should be preserved or half the DSP in done in gnuradio wouldn't be possible. The Scope sink should be grabbing the same number of samples off each of the inputs on each work pass, and if one path doesn't have enough available it should stop short and not report consuming anything past the smallest available number of samples on the inputs, and not render any data seen past the shortest available. I'm not sure how the scope sink deals with the minimum amount of data available issue. But the broader question becomes something like: given two (or more) subgraphs where the signals in the subgraphs had relative phase foo at the head of those sub-graphs, and the two (or more) subgraphs do different numbers and types of things to those signals, is relative phase preserved as seen by a sink object? It seems, on reflection, that unless those things *explicitly* modify phase, then phase should naturally be preserved. This is in stark contrast to the analog world, where there will be minor (or major!) phase-distortions as a result of following different paths. -- 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
