[Discuss-gnuradio] Phase unwrapping
Hello, I just started to work with GNU radio for my very basic needs, so please excuse my naive questions and probably my inappropriate use of the jargon. My first trivial application of GNU radio is to simply measure the phase of a phase modulated signal with an Ettus Research USRP N210 and a LFRX daughter-board. Everything works as expected, but I haven't found a way to do phase unwrapping (removing the 2pi ambiguity in the phase obtained from the arctan function looking at discontinuities in the phase data). Is this functionality offered somewhere, and I missed it, or should I look into implementing it myself? Thanks. Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Coverity scan
Hey everyone, A new Coverity scan of our code came back this morning. There is one new issue that falls on Marcus Mueller for his updates to pmt_io.cc, so I'll leave it to him to fix :) Sorry to throw you under the bus there, Marcus, but I wouldn't do it if I didn't think you could handle it. It's also a minor issue, so there's no rush. It seemed like a good excuse to remind everyone of our Coverity scan: https://scan2.coverity.com/projects/588 I believe there are still a few issues from here that are still outstanding and could be tackled by someone interested in helping us out. If you're new to the Coverity scan, though, just recognize that most of the issues discovered are Python/Swig related and there's nothing we can do about those. Just ignore them if the issues are in swig-generated files. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Phase unwrapping
Daniele, The problem with phase unwrapping is that it is unbounded, and will tend to infinity. Once it gets very big, when you try to add a small number to a very big number, floating point loses precision. Eventually, adding small to extremely big returns the big number unchanged. This isn't that useful. Matt On Mon, Jun 16, 2014 at 2:40 PM, Daniele Nicolodi dani...@grinta.net wrote: Hello, I just started to work with GNU radio for my very basic needs, so please excuse my naive questions and probably my inappropriate use of the jargon. My first trivial application of GNU radio is to simply measure the phase of a phase modulated signal with an Ettus Research USRP N210 and a LFRX daughter-board. Everything works as expected, but I haven't found a way to do phase unwrapping (removing the 2pi ambiguity in the phase obtained from the arctan function looking at discontinuities in the phase data). Is this functionality offered somewhere, and I missed it, or should I look into implementing it myself? Thanks. Cheers, Daniele ___ 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] Using set_min_output_buffer() in Python block
Hey Martin, My calls using self.set_min_output_buffer(4096*2) and self.set_min_noutput_items(4096) fail at runtime. Perhaps I am missing some import statements? AttributeError: 'bsld_dec_butterfly_cfb' object has no attribute 'set_min_output_buffer' Regards, David From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org [discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] on behalf of Martin Braun [martin.br...@ettus.com] Sent: 13 June 2014 19:45 To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Using set_min_output_buffer() in Python block On 13.06.2014 15:49, David Halls wrote: Dear All, Is it possible to use set_min_output_buffer() in Python? I want to be able to output more than 4096 items from a Python block during one call to the work function. Is there a way to do this? Hey David, sure, this function is available in Python. It's even in GRC, if you want to create code to see how it's used. M Regards, David NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl http://www.toshiba.eu/research/trl This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com ___ 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 NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl --- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Phase unwrapping
Hello Matt, thank for your answer. I'm aware of the problem and in my application I can keep phase bounded, but not bounded to (-pi, +pi] therefore I need unwrapping to make sense of my modulation data. If such feature does not exist in GNU radio, I hope it is not too hard to code it myself. Thanks. Cheers, Daniele On 16/06/2014 15:44, Matt Ettus wrote: Daniele, The problem with phase unwrapping is that it is unbounded, and will tend to infinity. Once it gets very big, when you try to add a small number to a very big number, floating point loses precision. Eventually, adding small to extremely big returns the big number unchanged. This isn't that useful. Matt On Mon, Jun 16, 2014 at 2:40 PM, Daniele Nicolodi dani...@grinta.net mailto:dani...@grinta.net wrote: Hello, I just started to work with GNU radio for my very basic needs, so please excuse my naive questions and probably my inappropriate use of the jargon. My first trivial application of GNU radio is to simply measure the phase of a phase modulated signal with an Ettus Research USRP N210 and a LFRX daughter-board. Everything works as expected, but I haven't found a way to do phase unwrapping (removing the 2pi ambiguity in the phase obtained from the arctan function looking at discontinuities in the phase data). Is this functionality offered somewhere, and I missed it, or should I look into implementing it myself? Thanks. Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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] Phase unwrapping
Daniele, I have worked on this problem for a specific case as well. I have a document with source code and a short description of what's happening that can be found here ( https://www.dropbox.com/s/bcma7fqa7ip2own/unwrap_example.txt). Michael On Mon, Jun 16, 2014 at 10:05 AM, Daniele Nicolodi dani...@grinta.net wrote: Hello Matt, thank for your answer. I'm aware of the problem and in my application I can keep phase bounded, but not bounded to (-pi, +pi] therefore I need unwrapping to make sense of my modulation data. If such feature does not exist in GNU radio, I hope it is not too hard to code it myself. Thanks. Cheers, Daniele On 16/06/2014 15:44, Matt Ettus wrote: Daniele, The problem with phase unwrapping is that it is unbounded, and will tend to infinity. Once it gets very big, when you try to add a small number to a very big number, floating point loses precision. Eventually, adding small to extremely big returns the big number unchanged. This isn't that useful. Matt On Mon, Jun 16, 2014 at 2:40 PM, Daniele Nicolodi dani...@grinta.net mailto:dani...@grinta.net wrote: Hello, I just started to work with GNU radio for my very basic needs, so please excuse my naive questions and probably my inappropriate use of the jargon. My first trivial application of GNU radio is to simply measure the phase of a phase modulated signal with an Ettus Research USRP N210 and a LFRX daughter-board. Everything works as expected, but I haven't found a way to do phase unwrapping (removing the 2pi ambiguity in the phase obtained from the arctan function looking at discontinuities in the phase data). Is this functionality offered somewhere, and I missed it, or should I look into implementing it myself? Thanks. Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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] Phase unwrapping
On 16/06/2014 19:47, Michael Berman wrote: I have worked on this problem for a specific case as well. I have a document with source code and a short description of what's happening that can be found here Hello Michael, thank for your example code, but the algorithm is trivial, what I don't yet know is how to implement it in such a way that it can be used within the gnuradio framework. I'm having a look at the documentation now. Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Phase unwrapping
If you take a look at the doc again, i updated it a little bit to show it working in an OOT work function. Michael On Mon, Jun 16, 2014 at 10:53 AM, Daniele Nicolodi dani...@grinta.net wrote: On 16/06/2014 19:47, Michael Berman wrote: I have worked on this problem for a specific case as well. I have a document with source code and a short description of what's happening that can be found here Hello Michael, thank for your example code, but the algorithm is trivial, what I don't yet know is how to implement it in such a way that it can be used within the gnuradio framework. I'm having a look at the documentation now. Cheers, Daniele ___ 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] Getting overflows at 50 Msps (not sure why)
I appreciate the suggestions I received. It turns out that I was able to run GNU Radio with realtime priority, and that solved my overflow issues. I am now able to run flowgraphs that actually do things without getting overflows all the time. Thanks, Orin Lincoln On 06/04/2014 05:16 PM, Orin Lincoln wrote: Hello, I am trying to get samples from a B200 at 50 Msps into GNU Radio. The UHD benchmark_rate tool receives at 50 Msps without any overflows detected. My GNU Radio flowgraph is simply a USRP source connected to a null sink, and I'm still getting overflows. I've tried expanding the min_output_buffer for the USRP source, but that doesn't seem to help. I really don't know what is causing the problem. Any suggestions about what I should try? Thank you, Orin Lincoln ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD Driver Not Working
An attempt to use PyBOMBS to install GNU Radio resulted in no errors. However, the UHD driver must have installed incorrectly, because the source and sink blocks are not working. Is there any way to fix this problem? -Carl___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Getting overflows at 50 Msps (not sure why)
Orin, Just curious what USB 3.0 chipset and OS you are using, and if you can go over 50 Msps? I am able to get 45 Msps UHD Benchmark with the VLI VL80x, but not over that. Thanks, Lou KD4HSO -- View this message in context: http://gnuradio.4.n7.nabble.com/Getting-overflows-at-50-Msps-not-sure-why-tp48774p48945.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] Getting overflows at 50 Msps (not sure why)
On 06/16/2014 04:23 PM, madengr wrote: Orin, Just curious what USB 3.0 chipset and OS you are using, and if you can go over 50 Msps? I am able to get 45 Msps UHD Benchmark with the VLI VL80x, but not over that. Thanks, Lou KD4HSO Also, I should point out that getting some high sample-rate in the *benchmark* application is only a very-vague indicator of how well things will do when you're actually *doing things* with the samples. It's very much cheaper to read samples and throw them away than it is to actually do things, including recording, with said samples. -- 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
[Discuss-gnuradio] GNU Radio / Software Radio conceptual question
Hi all, I have a relatively high level question regarding gnuradio and software radio in general. Is it a fair generalization to say that gnuradio is operating at the application layer and is essentially emulating a physical layer implementation (or the implementation of other lower layer protocols)? For example, if I have a link between two USRPs (more specifically, N series USRPs), the digitally sampled received data comes in on the ethernet NIC and moves up the stack to the software radio application. The signal processing that would typically be done in lower layers is then handled by the application. The second part of my question is, given a flow graph in gnuradio, what sort of steps would be necessary to push it back down the stack or implement in a chipset such that it can be used as an interface in a typical network stack? Is this something that anyone using gnuradio has considered or should I assume the next step would involve re-implementation? NOTE: This is by no means for a commercial product, but rather for demonstration. My research has led me to use gnuradio for some proof of concept implementations and I'm curious how much additional effort would be required to port the work to a practical device - for example, implementation on a smart phone. (you can read this as will it cause me to postpone graduation a few weeks? months? years?) Thanks in advance - any input is greatly appreciated. Regards, Michael Rahaim PhD Candidate Boston University, Boston, MA ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio / Software Radio conceptual question
On 06/16/2014 10:24 PM, Michael Rahaim wrote: Hi all, I have a relatively high level question regarding gnuradio and software radio in general. Is it a fair generalization to say that gnuradio is operating at the application layer and is essentially emulating a physical layer implementation (or the implementation of other lower layer protocols)? For example, if I have a link between two USRPs (more specifically, N series USRPs), the digitally sampled received data comes in on the ethernet NIC and moves up the stack to the software radio application. The signal processing that would typically be done in lower layers is then handled by the application. The second part of my question is, given a flow graph in gnuradio, what sort of steps would be necessary to push it back down the stack or implement in a chipset such that it can be used as an interface in a typical network stack? Is this something that anyone using gnuradio has considered or should I assume the next step would involve re-implementation? NOTE: This is by no means for a commercial product, but rather for demonstration. My research has led me to use gnuradio for some proof of concept implementations and I'm curious how much additional effort would be required to port the work to a practical device - for example, implementation on a smart phone. (you can read this as will it cause me to postpone graduation a few weeks? months? years?) Thanks in advance - any input is greatly appreciated. Regards, Michael Rahaim PhD Candidate Boston University, Boston, MA This presentation is several years old at this point, but I give it to ham-radio clubs from time to time: http://www.sbrac.org/files/sdr_introduction.ppt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [GSoC] Co-Processors Update #3
Hello all, Logistical: - 1/3 of the summer is gone! - Midterm evaluations are due at the end of next week (June 27). They are short so shouldn't affect progress at all. - Coproc dev call next week to get more ideas on GNU Radio integration. Time TBD: http://whenisgood.net/rhep54r Progress: - We finally got GNU Radio running on the board and a successful connection to a usrp - Figured out some of TI's software tools. Built and ran a successful self test for the network coprocessor. Will hopefully get data in and out of the FFTC this week. I have updated the wiki with my steps for those interested. I still need to add some stuff on the MCSDK and programming the board but that's when I make a little more progress. Stay tuned: http://gnuradio.org/redmine/projects/gnuradio/wiki/Keystone2 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
