[Discuss-gnuradio] forecast and set history function for haar decomposition
I am creating a new gnu radio block for decomposing the signal using haar wavelet decompostion and includes the option of number of levels of decompostion. In order to write the code, how should i set the set_history or forecast function because in order to produce output the input signal should be processed as a whole rather than in chunks. -- View this message in context: http://gnuradio.4.n7.nabble.com/forecast-and-set-history-function-for-haar-decomposition-tp44327.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast and set history function for haar decomposition
On Tue, Oct 22, 2013 at 11:10:54PM -0700, Bharat Mukkala wrote: I am creating a new gnu radio block for decomposing the signal using haar wavelet decompostion and includes the option of number of levels of decompostion. In order to write the code, how should i set the set_history or forecast function because in order to produce output the input signal should be processed as a whole rather than in chunks. This seems to be a case of set_output_multiple() rather than forecast() (the i/o ratio is still a constant, right?). 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 pgpvYo1vEOCGy.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BladRF
I am using Kubuntu 12.04 LTS 32bit, boost should be something like 1.49 or 1.50, gnuradio is latest build 3.7, and gr-osmosdr a few weeks old as with the latest version gqrx and bladerf do not work together. For exact versions you have to wait a bit, I do not have this system at hand right now :) Ralph. From: Muhammad JUNAID [mailto:m_junaid0...@yahoo.com] Sent: Wednesday, October 23, 2013 11:51 AM To: Ralph A. Schmid, dk5ras Subject: Re: [Discuss-gnuradio] BladRF Dear Ralph, What is Ubuntu ,GNURadio, Osmosdr and Boost version on your successful installation of BladRF. Regards Muhammad Junaid On Wednesday, October 23, 2013 2:23 PM, Ralph A. Schmid, dk5ras ra...@schmid.xxx wrote: Yes, I had this problem. As far as I remember I uninstalled bladerf and gr-osmosdr, then manually deleted all remains of it and of hackrf (what I never used) from my system, compiled and installed again bladerf, compiled a fresh version of gr-osmosdr with the cmake-option not to build hackrf support, installed it, finally everything worked. Ralph. From: discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Muhammad JUNAID Sent: Tuesday, October 22, 2013 3:02 PM To: discuss-gnuradio@gnu.org Cc: discuss-gnuradio-requ...@gnu.org Subject: [Discuss-gnuradio] BladRF I am working on bladeRF, dose anyone working on it and facing this error? Ubuntu 13.04 linux; GNU C++ version 4.7.3; Boost_105300; UHD_003.005.004-140-gfb32ed16 Welcome to GNU Radio Companion 3.7.1 i got this error while running osmocom_fft. junaid@Junaid:~/gnuradio/gr-osmosdr$ osmocom_fft -a bladerf=0,fpga=/opt/bladeRF/fpga/hostedx115.rbf -s 800 -f 44600 linux; GNU C++ version 4.7.3; Boost_105300; UHD_003.005.004-140-gfb32ed16 gr-osmosdr v0.1.0-23-g6f4e16ff (0.1.1git) gnuradio 3.7.1 built-in source types: file fcd rtl rtl_tcp uhd hackrf FATAL: Failed to open HackRF device (-5) HACKRF_ERROR_NOT_FOUND Trying to fill up 1 missing channel(s) with null source(s). This is being done to prevent the application from crashing due to a gnuradio bug. The maintainers have been informed. Source has no sample rates (wrong device arguments?). BLADERF CLI info bladeRF load fpga /opt/bladeRF/fpga/hostedx115.rbf Loading fpga from /opt/bladeRF/fpga/hostedx115.rbf... Done. bladeRF info Serial #: 5cc7c3a07c529478308a9d5424965eb0 VCTCXO DAC calibration: 0x99d1 FPGA size:115 KLE FPGA loaded: yes USB bus: 3 USB address: 2 Backend: libusb Instance: 0 bladeRF version bladeRF-cli version:0.5.0-git-130cbba libbladeRF version: 0.6.2-git-130cbba Firmware version: 1.5.3-git- FPGA version: GR-OSMOCOM enabled components -- -- ## -- # gr-osmosdr enabled components -- ## -- * Python support -- * Osmocom IQ Imbalance Correction -- * FUNcube Dongle -- * IQ File Source -- * Osmocom RTLSDR -- * RTLSDR TCP Client -- * Ettus USRP Devices -- * HackRF Jawbreaker -- * nuand bladeRF -- -- ## -- # gr-osmosdr disabled components -- ## -- * sysmocom OsmoSDR -- * FUNcube Dongle Pro+ -- * Osmocom MiriSDR -- -- Building for version: v0.1.0-23-g6f4e16ff / 0.1.1git -- Using install prefix: /opt/gnuradio-3.7.1git -- Configuring done -- Generating done -- Build files have been written to: /home/junaid/gnuradio/gr-osmosdr Regards Muhammad Junaid ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast and set history function for haar decomposition
the i/o ratio is 1 since the number of input items is same the number of output items, but while processing we use the whole signal but not a single element while calculating the output elements, i have doubt in figuring out how to tell that to gnuradio,my idea is that, can i set_output_multiple to ninput_items_required and then do processing. thank you -- View this message in context: http://gnuradio.4.n7.nabble.com/forecast-and-set-history-function-for-haar-decomposition-tp44327p44330.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast and set history function for haar decomposition
On Wed, Oct 23, 2013 at 03:23:36AM -0700, Bharat Mukkala wrote: the i/o ratio is 1 since the number of input items is same the number of output items, but while processing we use the whole signal but not a single element while calculating the output elements, i have doubt in figuring out how to tell that to gnuradio,my idea is that, can i set_output_multiple to ninput_items_required and then do processing. thank you You can only set_output_multiple before work starts, usually in the constructor. So you set_output_multiple such that you can process the entire signal at once, and make your block a gr::sync_block. 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 pgpfEcty018h_.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast and set history function for haar decomposition
On Wed, Oct 23, 2013 at 7:47 AM, Martin Braun (CEL) martin.br...@kit.edu wrote: On Wed, Oct 23, 2013 at 03:23:36AM -0700, Bharat Mukkala wrote: the i/o ratio is 1 since the number of input items is same the number of output items, but while processing we use the whole signal but not a single element while calculating the output elements, i have doubt in figuring out how to tell that to gnuradio,my idea is that, can i set_output_multiple to ninput_items_required and then do processing. thank you You can only set_output_multiple before work starts, usually in the constructor. So you set_output_multiple such that you can process the entire signal at once, and make your block a gr::sync_block. MB Bharat, Have you looked at the wavelet_ff block in gr-wavelet? It might do what you want already or is at least close. Also, since a wavelet is very much like a decimating fir filter, I'm not sure output_multiple is the right thing to do. I think setting the history for the length of the wavelet coefficients should be adequate. Check out my overview of the scheduler for some details on what history does: http://www.trondeau.com/blog/2013/9/15/explaining-the-gnu-radio-scheduler.html Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Sending file through tx_ofdm.grc in gnuradio 3.7.1
Hi all, I want to transmit a file through tx_ofdm.grc model and receive it in using rx_ofdm.grc. Presently this simulation takes in a vector source of packet length as input and it creates tags for it. I am able to receive these vectors correctly using rx_ofdm.grc Now I want to send file as data but I dont find any block which adds tags to file. Alternately, can someone suggest the method of converting the file content into vectors of packet length configurable by the user so that it can be entered into the vector source. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Costas loop lock?
On Thu, Oct 10, 2013 at 9:30 PM, tom sutherland alphatoz...@yahoo.com wrote: I am using a Costas loop for carrier recovery with QAM16 data. The carrier is only 2khz. The I/Q output of the Costas loop seems to track (the original sin/cos of the modulating carrier's Frequency Phase) steadily for a long period (minutes) and then the Phase moves off, normally in +/- 45 or 90 degrees in one or both of the phases. Any thoughts on why this occurs or how I can fix this issue? Thanks...Tom Tom, The Costas loop is not designed to handle QAM16. It only works for BPSK, QPSK, and 8PSK. My guess is that you are using an order 4 loop? What's probably happening is that the symbols at the four corners of the constellation are dominating the error calculations because they have the highest energy. But the loop can get biased by another symbol in the constellation that turns it to another phase lock. The Costas loop has no idea what the right constellation is; it's just minimizing an error function and has probably gotten trapped in a local minimum that your constellation presents to it. I would suggest turning instead to the constellation_receiver block. This allows you to specify the constellation you want it to handle. The constellation objects (http://jenkins.gnuradio.org/manual/doxygen/page_digital.html) allow you to specify a symbol mapping to a set of complex points. There are specialized forms of the constellations for certain known types (BPSK, QPSK, etc.) that have more computationally efficient decision making functions. But for any given constellation, it will at least be able to calculate the minimum Euclidean distance between each point. Slow but reliable. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Google Summer of Code 2014
Dear students, dear prospective mentors, Google has already put out the word that GSoC will continue next year. Given the huge success of our summer of code, we're pretty sure we'll also continue participating. Of course, it's too early to say anything definitive about next year's GSoC, except for the fact that we'll most likely be part of it. Still, if you're interested in GSoC, you should read on. There's one section each for * Students * Faculty members * Anyone who might be a mentor (i.e. anyone else) Students If you're a student next year (i.e. enrolled at a university somewhere in the world), you're probably eligible for GSoC. This means you have the opportunity to write free software during the summer, get paid for it (by Google), collect fame and nerd cred by participating in a prestigious program, and win a t-shirt. GNU Radio has participated only twice so far, but both years, we had no students fail, and many interesting projects were tackled. Perhaps some of the past students want to weigh in here, but my impression as mentor and admin was that it's a huge opportunity to learn lots and actively contribute. If this sounds interesting, you should think about participating earlier rather than later. When we evaluate proposals (which act as applications), we take your previous coding experience into account, as well as your ability to use a mailing list and interact with an open source community. If you have been active in the GNU Radio project before submitting a proposal, that can count to your favour. Being active in this community can definitely increase your chances. One of our main goals with GSoC is to find people that stay with us and continue contributing. This will help us get to know you before the short application phase. Faculty Members === If you like, you can help us with GSoC--become a mentor, suggest projects etc. But right now, all I ask is that you encourage students who want to participate in GSoC. Sadly, every year, we hear of students who don't apply for GSoC because it doesn't fit into their curriculum, or simply because advisors oppose the idea of students working on something like GSoC during the summer. A student returning from GSoC will most likely have learnt lots about signal processing, coding, collaborating in a software project and general radio stuff. You will get a better student in return! GSoC and university can also go together really well. As an example, two years ago, one of our students participated in GSoC while he was finishing his degree's final project. This was possible because mentors and university cooperated such that his GSoC project had a very large overlap with his final project, and he didn't lose any time with GSoC. Such win-win-win situations are rare, but not impossible. If you're a faculty member and believe there is space for cooperation, please contact me off-list. Potential mentors = How about mentoring a project? You can support up-and-coming new SDR hackers, teach wisdom and promote projects you're enthusiastic about. Mentoring *is* some work. But it's also lots of fun! So think about if you'd like to mentor, and sign up next summer. Martin -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpiJkr1L4tOa.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GnuRadio in particle accelerators
Hi, people. Anyone here has experience using Gnuradio or USRP as an instrumentation tool (I mean, not for actual radio transmissions)? After years studying, hobbying and working with SDR, I've just learned that they are very similar to particle acceleator instrumentation, in a very pleasant way: I was just hired to work on one, precisely because of the skills acquired with my SDR projects. Moreover, this particular project (Sirius, in Brasil), has adopted an open hardware and free software attitude, which makes the use of Gnuradio particularly interesting. Has anyone worked with this kind of instruments using Gnuradio? Is USRP a good tool for this kind of job, or you can think about any limitation? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GnuRadio in particle accelerators
Hi Aylons, I have no answer here. But talking about Gnuradio and nuclear physics I want to add my idea to your question: Would it be possible to use Gnuradio in a (home made) Gamma Spectrometer ? These spectrometers usually work with a multichannel analyzer that measures the pulse height coming from the detector and then sorting the heights into bins. This is similar to the histogram GUI element found in GRC, but the counting is accumulative until a timer or manual interaction stops it. The big difference between SDR use and nuclear instrumentation is that while SDR mainly works with a constant stream of data the latter mainly deals with transient pulses. Mark On 23/10/13 17:14, Aylons Hazzud wrote: Hi, people. Anyone here has experience using Gnuradio or USRP as an instrumentation tool (I mean, not for actual radio transmissions)? After years studying, hobbying and working with SDR, I've just learned that they are very similar to particle acceleator instrumentation, in a very pleasant way: I was just hired to work on one, precisely because of the skills acquired with my SDR projects. Moreover, this particular project (Sirius, in Brasil), has adopted an open hardware and free software attitude, which makes the use of Gnuradio particularly interesting. Has anyone worked with this kind of instruments using Gnuradio? Is USRP a good tool for this kind of job, or you can think about any limitation? ___ 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] GnuRadio in particle accelerators
Not exactly the same thing, but I recall a physicist presented a paper at the first GnuRadio Conference in 2011 on using GR for quantum communication. See http://gnuradio.squarespace.com/grc2011-abstracts#wednesday_1530_1600 Very Respectfully, Dan CaJacob On Wed, Oct 23, 2013 at 12:36 PM, M Dammer i...@mdammer.net wrote: Hi Aylons, I have no answer here. But talking about Gnuradio and nuclear physics I want to add my idea to your question: Would it be possible to use Gnuradio in a (home made) Gamma Spectrometer ? These spectrometers usually work with a multichannel analyzer that measures the pulse height coming from the detector and then sorting the heights into bins. This is similar to the histogram GUI element found in GRC, but the counting is accumulative until a timer or manual interaction stops it. The big difference between SDR use and nuclear instrumentation is that while SDR mainly works with a constant stream of data the latter mainly deals with transient pulses. Mark On 23/10/13 17:14, Aylons Hazzud wrote: Hi, people. Anyone here has experience using Gnuradio or USRP as an instrumentation tool (I mean, not for actual radio transmissions)? After years studying, hobbying and working with SDR, I've just learned that they are very similar to particle acceleator instrumentation, in a very pleasant way: I was just hired to work on one, precisely because of the skills acquired with my SDR projects. Moreover, this particular project (Sirius, in Brasil), has adopted an open hardware and free software attitude, which makes the use of Gnuradio particularly interesting. Has anyone worked with this kind of instruments using Gnuradio? Is USRP a good tool for this kind of job, or you can think about any limitation? ___ 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] GnuRadio in particle accelerators
On Wed, Oct 23, 2013 at 02:14:01PM -0200, Aylons Hazzud wrote: Moreover, this particular project (Sirius, in Brasil), has adopted an open hardware and free software attitude, which makes the use of Gnuradio particularly interesting. That's a great attitude :) Has anyone worked with this kind of instruments using Gnuradio? Is USRP a good tool for this kind of job, or you can think about any limitation? This depends on what exactly you need to do. But GNU Radio has been used for many different things in the past, and most likely, it'll be useful for you. I'm always amazed what people have achieved with GNU Radio. Hopefully you can add another cool application :) Happy hacking, 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 pgpccLICj5Tbx.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sending file through tx_ofdm.grc in gnuradio 3.7.1
On Wed, Oct 23, 2013 at 10:06:57PM +0800, ashish mishra wrote: I want to transmit a file through tx_ofdm.grc model and receive it in using rx_ofdm.grc. Presently this simulation takes in a vector source of packet length as input and it creates tags for it. I am able to receive these vectors correctly using rx_ofdm.grc Hi Ashish, and first of all, thanks for testing the OFDM codes. Now I want to send file as data but I dont find any block which adds tags to file. Alternately, can someone suggest the method of converting the file content into vectors of packet length configurable by the user so that it can be entered into the vector source. There's no simple way to do this, which I believe is an omission. I've created http://gnuradio.org/redmine/issues/603 and will add a block soon. Until then, you'll have to load the block into an array, split that into manageable chunks and pass all of them as tagged streams to the vector_source (in Python land). Cheers, 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 pgpH4fUPUqvWh.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QT GUI Range - broken in GRC 3.7.2git-107-g636140af ??
On Tue, Oct 22, 2013 at 10:29 PM, Tom McDermott
tom.mcdermo...@yahoo.com wrote:
Have updated to the latest git, been a month or two since the last update
here.
Previous 3.7.2git (a little back) ran fine.
With the latest, flowgraphs seem to start but immediately exit ('done') when
there is a QT GUI Range control on them. If the QT GUI Range is deleted and
replaced with
a QT GUI entry, (selecting the same variable that the Range previously
selected) then the flow graph runs fine.
Tried it on several different flowgraphs contianing other QT GUI widgets,
seems
that the range control breaks all the flowgraphs, and replacing with Entry
fixes all.
-- Tom, N5EG
Tom,
I have created ticket #604 on our issue tracker, so please move all
discussion over there. In particular, this seems to be a problem after
updating from Ubuntu 13.04 to 13.10. Can you update the ticket with
your OS information (and if you upgraded your OS between the last time
you ran it and the latest)?
Thanks,
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] forecast and set history function for haar decomposition
its true that setting the history to length of coefficients work, but when we go for more than 1 level of decomposition, the output from previous level will be used , so how can is use the output again ? i have another doubt , if we set the size of each element in the input signature to be 4*sizeof(float) and size of each output element to be 4*sizeof(float) in a gr::sync_block, then in the work function , how each element will be handled, (is it like 4 input items of size float), also please tell me how to use them. thank you -- View this message in context: http://gnuradio.4.n7.nabble.com/forecast-and-set-history-function-for-haar-decomposition-tp44327p44342.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] DySPAN call for papers deadline extended
Hi everyone, At GRCon13, we discussed the importance of policy and regulatory aspects of spectrum and how it can impact GNU Radio as well as how we could possibly impact it. The IEEE DySPAN symposium is a great place for this and other discussions related to dynamic spectrum access. I've chaired the demonstrations section in the past and have been a member of the technical program committee for most DySPANs. It's one of the few places where the technical and policy communities come together in an open and academic forum to discuss these important issues. I just wanted to let everyone know that they have extended the paper deadline from Nov. 1 to Nov. 10 and demonstrations. Posters, tutorials, and demonstrations are due Dec 1 (the original deadline). The call for papers is here but the new deadline dates have not yet been modified: http://dyspan2014.ieee-dyspan.org/call-for-papers I've written about the symposium here: http://www.trondeau.com/blog/2013/9/17/dyspan-2014-announcements.html I think that this community has a huge potential to impact the thinking and direction of all aspects of future wireless technology and policy, so I hope that you take this opportunity to get involved. Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Behaviour of gs-osmosdr when multiple devices in the source
I'm trying to understand the behaviour for gr-osmosdr when you have multiple devices in the source -- does it start delivering samples immediately, or is there a synchronization point, so that all devices start delivering samples more-or-less at the same time? -- 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] Behaviour of gs-osmosdr when multiple devices in the source
On Wed, Oct 23, 2013 at 9:58 PM, Marcus D. Leech mle...@ripnet.com wrote: I'm trying to understand the behaviour for gr-osmosdr when you have multiple devices in the source -- does it start delivering samples immediately, or is there a synchronization point, so that all devices start delivering samples more-or-less at the same time? Hi Marcus, I believe the behavior is different from source to source and basically depends on whether the source block takes advantage of the start/stop methods. For example, the Funcube Dongle Pro and Pro+ blocks are gnuradio audio source blocks that use the start and stop methods and therefore will not start reading samples until the flow graph is started. In other words, two funcube dongles will be more or less synchronized, except for the clock differences. I think it is the same for the UHD sources. On the other hand, I have observed that if I create an rtlsdr source block, after a few seconds it will start spitting OO out to the terminal until I start the flow graph. This indicates that the rtlsdr source is started as soon as it is created. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Behaviour of gs-osmosdr when multiple devices in the source
On 10/23/2013 04:19 PM, Alexandru Csete wrote: Hi Marcus, I believe the behavior is different from source to source and basically depends on whether the source block takes advantage of the start/stop methods. For example, the Funcube Dongle Pro and Pro+ blocks are gnuradio audio source blocks that use the start and stop methods and therefore will not start reading samples until the flow graph is started. In other words, two funcube dongles will be more or less synchronized, except for the clock differences. I think it is the same for the UHD sources. On the other hand, I have observed that if I create an rtlsdr source block, after a few seconds it will start spitting OO out to the terminal until I start the flow graph. This indicates that the rtlsdr source is started as soon as it is created. Alex Interesting. I'll observe, out loud, that it would be useful for my current coherence testing if the behaviour could be closer to roughly synchronized. Not sure how easy that is to do for RTLSDR. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Behaviour of gs-osmosdr when multiple devices in the source
On Wed, Oct 23, 2013 at 10:33 PM, Marcus D. Leech mle...@ripnet.com wrote: On 10/23/2013 04:19 PM, Alexandru Csete wrote: Hi Marcus, I believe the behavior is different from source to source and basically depends on whether the source block takes advantage of the start/stop methods. For example, the Funcube Dongle Pro and Pro+ blocks are gnuradio audio source blocks that use the start and stop methods and therefore will not start reading samples until the flow graph is started. In other words, two funcube dongles will be more or less synchronized, except for the clock differences. I think it is the same for the UHD sources. On the other hand, I have observed that if I create an rtlsdr source block, after a few seconds it will start spitting OO out to the terminal until I start the flow graph. This indicates that the rtlsdr source is started as soon as it is created. Alex Interesting. I'll observe, out loud, that it would be useful for my current coherence testing if the behaviour could be closer to roughly synchronized. Not sure how easy that is to do for RTLSDR. I think you can create one multi-channel source using 2 separate devices. That may get you close. I haven't tried this feature though so I don't know how it works. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Behaviour of gs-osmosdr when multiple devices in the source
Interesting. I'll observe, out loud, that it would be useful for my current coherence testing if the behaviour could be closer to roughly synchronized. Not sure how easy that is to do for RTLSDR. I think you can create one multi-channel source using 2 separate devices. That may get you close. I haven't tried this feature though so I don't know how it works. Alex That's the case I'm talking about... -- 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] Sending file through tx_ofdm.grc in gnuradio 3.7.1
On Wed, Oct 23, 2013 at 07:05:08PM +0200, Martin Braun (CEL) wrote: Alternately, can someone suggest the method of converting the file content into vectors of packet length configurable by the user so that it can be entered into the vector source. There's no simple way to do this, which I believe is an omission. I've created http://gnuradio.org/redmine/issues/603 and will add a block soon. Can you please try this: https://github.com/mbant/gnuradio/tree/streamtagger Thanks, 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 pgpifHhYfBF8s.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNURadio Run with USRP2 Hangs on Execution
I finally got my GNURadio Python script running, but after I execute the script, I get a UHD Warning about requested decimation (a few lines of text), then a single 0 on a newline, and nothing. I let it run for about five minutes, and my output file didn't change from 0 bytes. I am trying to capture the entire shortwave frequency spectrum to analyze later (hence the output file). I am using a sample I found online, modified for GNURadio 3.7. I have set the following parameters samp_rate = 3000 (for 30MHz) tune_request = 1500 (for the middle frequency) self._head = blocks.head(8, int(100)) (that is what the example stated to use for number of samples, but I will likely change that once I verify everything is working correctly) I am not getting any errors, like I was initially before converting it all to 3.7, except not doing anything for five minutes and the output file size not growing. Links to similar projects are welcome, and any feedback/help is appreciated. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio Run with USRP2 Hangs on Execution
Paul, With (the default) 16bit complex sample format the maximum sample rate supported on USRP2 is 25Msps, simply because that is pretty much as much data as you can get over 1G Ethernet in one direction. 50Msps is supported if you use 8bit complex samples and loose some dynamic range. The decimation rate must be an integer, thus 25Msps is a decimation rate of 4 from the raw ADC converter clock of 100MHz. Also, since the receive DSP chain cascades 2 Halfband FIR filters (each with fixed decimation of 2) before a CIC filter (With arbitrary integer decimation), it is preferable to always use decimation rates that factor by 4 so that both half band filters are active which results in the flattest passband. UHD will automatically use the half band filters in preference to the CIC when possible with the specified decimation. -Ian On Oct 23, 2013, at 3:39 PM, Paul B. Huter paul.b.hu...@gmail.com wrote: I finally got my GNURadio Python script running, but after I execute the script, I get a UHD Warning about requested decimation (a few lines of text), then a single 0 on a newline, and nothing. I let it run for about five minutes, and my output file didn't change from 0 bytes. I am trying to capture the entire shortwave frequency spectrum to analyze later (hence the output file). I am using a sample I found online, modified for GNURadio 3.7. I have set the following parameters samp_rate = 3000 (for 30MHz) tune_request = 1500 (for the middle frequency) self._head = blocks.head(8, int(100)) (that is what the example stated to use for number of samples, but I will likely change that once I verify everything is working correctly) I am not getting any errors, like I was initially before converting it all to 3.7, except not doing anything for five minutes and the output file size not growing. Links to similar projects are welcome, and any feedback/help is appreciated. ___ 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] GNURadio Run with USRP2 Hangs on Execution
Ian: Thank you for your detailed response. If I stick with eight bits and increase to 50Msps, will that solve the decimation rate problem? I realize this would result in a decimation rate of two, which would not be ideal. I may decide to only grab 25MHz, not the full 30, to keep the decimation rate at four. Thank you, again. Paul B. Huter Ian Buckley i...@ionconcepts.com wrote: Paul, With (the default) 16bit complex sample format the maximum sample rate supported on USRP2 is 25Msps, simply because that is pretty much as much data as you can get over 1G Ethernet in one direction. 50Msps is supported if you use 8bit complex samples and loose some dynamic range. The decimation rate must be an integer, thus 25Msps is a decimation rate of 4 from the raw ADC converter clock of 100MHz. Also, since the receive DSP chain cascades 2 Halfband FIR filters (each with fixed decimation of 2) before a CIC filter (With arbitrary integer decimation), it is preferable to always use decimation rates that factor by 4 so that both half band filters are active which results in the flattest passband. UHD will automatically use the half band filters in preference to the CIC when possible with the specified decimation. -Ian On Oct 23, 2013, at 3:39 PM, Paul B. Huter paul.b.hu...@gmail.com wrote: I finally got my GNURadio Python script running, but after I execute the script, I get a UHD Warning about requested decimation (a few lines of text), then a single 0 on a newline, and nothing. I let it run for about five minutes, and my output file didn't change from 0 bytes. I am trying to capture the entire shortwave frequency spectrum to analyze later (hence the output file). I am using a sample I found online, modified for GNURadio 3.7. I have set the following parameters samp_rate = 3000 (for 30MHz) tune_request = 1500 (for the middle frequency) self._head = blocks.head(8, int(100)) (that is what the example stated to use for number of samples, but I will likely change that once I verify everything is working correctly) I am not getting any errors, like I was initially before converting it all to 3.7, except not doing anything for five minutes and the output file size not growing. Links to similar projects are welcome, and any feedback/help is appreciated. ___ 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] GNURadio Run with USRP2 Hangs on Execution
On 10/23/2013 07:44 PM, Paul B. Huter wrote: Ian: Thank you for your detailed response. If I stick with eight bits and increase to 50Msps, will that solve the decimation rate problem? I realize this would result in a decimation rate of two, which would not be ideal. I may decide to only grab 25MHz, not the full 30, to keep the decimation rate at four. Thank you, again. Paul B. Huter Keep firmly in mind that your computer will need enough grunt to deal with the resulting torrent of samples from the USRP. Even if you're only recording them, you'll need a minimum of 100Mbyte/second sustained write speed to your disks. If you're actually *doing something* with the samples, in the mathematical sense, you'll need lots of aggregate GFLOPS to keep up. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio Run with USRP2 Hangs on Execution
Thanks, Marcus. I am just saving the data into a data file for later analysis. I only plan to save about a minute of data at a time. I intend to start small, though, and work my way up to see if my computer can handle things. On Wed, Oct 23, 2013 at 6:59 PM, Marcus D. Leech mle...@ripnet.com wrote: On 10/23/2013 07:44 PM, Paul B. Huter wrote: Ian: Thank you for your detailed response. If I stick with eight bits and increase to 50Msps, will that solve the decimation rate problem? I realize this would result in a decimation rate of two, which would not be ideal. I may decide to only grab 25MHz, not the full 30, to keep the decimation rate at four. Thank you, again. Paul B. Huter Keep firmly in mind that your computer will need enough grunt to deal with the resulting torrent of samples from the USRP. Even if you're only recording them, you'll need a minimum of 100Mbyte/second sustained write speed to your disks. If you're actually *doing something* with the samples, in the mathematical sense, you'll need lots of aggregate GFLOPS to keep up. __**_ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/**listinfo/discuss-gnuradiohttps://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] Missing File?
Running my script, I get an error (repeated twice): ~\AppData\Roaming\.gnuradio\prefs\vmcircbuf_default_factory: Invalid argument I looked, and there is no 'vmcircbuf_default_factory' in the \prefs folder (there isn't anything in there). The Internet (GNURadio website and GNURado mailing list archives in addition to general Internet searches) provides plenty of examples of 'vmcircbuf_sysv_shm, where the user is told to update the 'vmcircbuf_default_factory' file, but nothing relating directly to my problem. Is this a file that should have been created when I installed GNURadio and its dependencies? Can I just create the file, and, if so, what does the structure/format look like? Or, can someone point me to either a sample file, or the file location somewhere else? Thank you. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] tx_ofdm.grc rx_ofdm.grc output data
Has anyone tested successfully these two files combined? The input data or vector source is an array of 96 elements [0-95] but I'm getting a strange output at the end. The 96 + 4 elements from the crc, then another 100 values (200 total), then the sequence repeats. I tried using the OFDM transmitter and receiver blocks and they work perfectly, same input as ouput. I began tracing the problem comparing the same log debug output files and it seems the Header/Payload Demux is causing some issues. Here's the output at the very end of the RX by the way (200 elements, then repeats): [ 0123456789 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 114 115 -56 81 -26 39 -70 38 66 -106 -111 115 -1240 3211 -1201 -63 -56 688 19 -120 -127 83 53 -30 -104 121 -39 -10 -103 88 -96 -72 -66 -96 9 34 -88 -118 42 10 -86 -88 -96012345 6789 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55] Thanks in advanced. -- View this message in context: http://gnuradio.4.n7.nabble.com/tx-ofdm-grc-rx-ofdm-grc-output-data-tp44356.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 compile error about GNURADIO_RUNTIME_INCLUDE_DIRS
when I compile the gr-osmosdr,such error happens,like: Found PkgConfig: C:/Program Files/gnuradio/bin/pkg-config.exe (found version 0.26) Checking for GNU Radio Module: RUNTIME checking for module 'gnuradio-runtime' found gnuradio-runtime, version 3.7.1-52 * INCLUDES=GNURADIO_RUNTIME_INCLUDE_DIRS-NOTFOUND * LIBS=GNURADIO_RUNTIME_LIBRARIES-NOTFOUND Could NOT find GNURADIO_RUNTIME (missing: GNURADIO_RUNTIME_LIBRARIES GNURADIO_RUNTIME_INCLUDE_DIRS) GNURADIO_RUNTIME_FOUND = FALSE CMake Error at C:/Program Files/gnuradio/lib/cmake/gnuradio/GnuradioConfig.cmake:97 (message): Required GNU Radio Component: RUNTIME missing! Call Stack (most recent call first): C:/Program Files/gnuradio/lib/cmake/gnuradio/GnuradioConfig.cmake:104 (GR_MODULE) CMakeLists.txt:150 (find_package) But I don't know what the GNURADIO_RUNTIME_INCLUDE_DIRS is,and how can I solve it?I search it in the cmakelists in /gr-osmosdr,but don't know add what to correct this error? Thank you! -- View this message in context: http://gnuradio.4.n7.nabble.com/gnuradio-compile-error-about-GNURADIO-RUNTIME-INCLUDE-DIRS-tp44357.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
