[Discuss-gnuradio] [GSoC] We're in!
Hi everyone, I'm very happy to announce that GNU Radio was accepted as a mentoring org for GSoC 2014, and I'm looking forward to many great projects! Next step is the students-get-to-know-us phase. Then, starting March 10, we're accepting proposals from students. A word of advice to all students: Make sure you've read all of our GSoC info pages, in particular: http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCStudentInfo http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCManifest As well as all student-related info on Melange: http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page Cheers, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] HRPT receiver
Hello, I was wondering if someone can receive hrpt images from NOAA satellites or similar, if so, could you help me with the implementation of the receiver? There is not quite information about that format, so if you could help me I would really appreciate it. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK
On 02/24/2014 09:33 PM, Abhishek Bhowmick wrote: Firstly, congratulations on being accepted as a mentor organization. Thanks for the pointers to gr-atsc and gr-80211. I have started looking there as a starting point. Are there similar modules which are undergoing volk speedup fixes? I had started working on accelerating the OFDM sync blocks in-tree... I'd need to dig around a bit to get that up to date. Contact me off-list if you want to see about this. I am also trying to meet up with other people who have been using GNU radio to identify potential modules for acceleration. As you are now a mentor organization, I feel it's a good time for us to get into detailed discussions. Absolutely, that goes for you and all other applicants. The ideas list is just to get you started, for successful participation, you will need to write a proposal that details what you plan to do for 3 months of full-time coding. At the moment the only mainstream ISA not being targeted is probably AVX2, which has some nice features for the type of kernels we're doing. If you went that route it would likely need add protokernels to a pretty large number of kernels. Nathan This also seems to be promising, though I guess it would require me to come up to speed with AVX2 (which I would love to do). Could you please elaborate a little on the kind of beneficial features you have in mind ? I am concerned that the job of adding proto-kernels might turn out to be mundane/tedious ? Is that a valid concern ? That's highly subjective :) If you don't know much about those specific SIMD instruction sets, it's probably neither. On the other hand, if you're already an expert, it's not that much work, and you can quickly benefit the project. I don't think anyone expects you to do 3 months of proto-kernel development, so you can balance it in your project proposal. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] HRPT receiver
Hi Pablo, Googling Noaa image format instantly yielded: http://commons.wikimedia.org/wiki/File:NOAA_APT_Frame_Format.gif http://www.sat.dundee.ac.uk/hrptformat.html It's already been done a few times - for example like this (really just googling GNU Radio NOAA image decode and clicking the first thing away...) http://www.oz9aec.net/index.php/gnu-radio/gnu-radio-blog/350-noaa-weather-satellite-reception-with-gnu-radio-and-usrp but here, Alexandru Csete used a GNU Radio-Based flowgraph just to record the received signal to a Wav file and process it via atpdec http://atpdec.sourceforge.net/ and, honestly, how cool would it be if you wrote a small piece of GNU Radio software that had a signal sink, which used the atpdec code and displayed images in a window? (Hint: awesome). So: Happy Hacking, Marcus On 02/25/2014 09:38 AM, Pablo Fernández Alonso wrote: Hello, I was wondering if someone can receive hrpt images from NOAA satellites or similar, if so, could you help me with the implementation of the receiver? There is not quite information about that format, so if you could help me I would really appreciate it. ___ 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] HRPT receiver
Hi Pablo, We are receiving 24/7 HRPT sample images http://www.poes-weather.com/sample-hrpt.html Dish: 1.5 m (parabolic) Elevation over Azimuth rotor, made in FI POES-Weather Ltd Downconverter LO 1557 MHz (or why not use DBSRX and a 1.7 GHz LNA + some filter if needed) USRP1 + TVRX (or 2) or an USB SDR dongle. GR HRPT RX software that can be found in examples. An enhanced version can be found here https://github.com/poes-weather (gr-poes-weather), it is NOT compatible with the latest GR...but should not be that tricky to update. Youtube, testing the proto-rotor http://www.youtube.com/watch?v=XYRSgOsDyrU Patrik On Tue, 2014-02-25 at 09:38 +0100, Pablo Fernández Alonso wrote: Hello, I was wondering if someone can receive hrpt images from NOAA satellites or similar, if so, could you help me with the implementation of the receiver? There is not quite information about that format, so if you could help me I would really appreciate it. ___ 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] HRPT receiver
Hi Marcus, APT is (analogue) FM BW ~35-40 kHz and HRPT BW 3 MHz digital. Using a RTLSDR to receive APT can also be found here using windows http://www.poes-weather.com/rtl-sdr/ and howto build a good antenna (RHCP) @ 137 MHz here http://www.poes-weather.com/download/jm-dca/ Patrik On Tue, 2014-02-25 at 09:58 +0100, Marcus Müller wrote: Hi Pablo, Googling Noaa image format instantly yielded: http://commons.wikimedia.org/wiki/File:NOAA_APT_Frame_Format.gif http://www.sat.dundee.ac.uk/hrptformat.html It's already been done a few times - for example like this (really just googling GNU Radio NOAA image decode and clicking the first thing away...) http://www.oz9aec.net/index.php/gnu-radio/gnu-radio-blog/350-noaa-weather-satellite-reception-with-gnu-radio-and-usrp but here, Alexandru Csete used a GNU Radio-Based flowgraph just to record the received signal to a Wav file and process it via atpdec http://atpdec.sourceforge.net/ and, honestly, how cool would it be if you wrote a small piece of GNU Radio software that had a signal sink, which used the atpdec code and displayed images in a window? (Hint: awesome). So: Happy Hacking, Marcus On 02/25/2014 09:38 AM, Pablo Fernández Alonso wrote: Hello, I was wondering if someone can receive hrpt images from NOAA satellites or similar, if so, could you help me with the implementation of the receiver? There is not quite information about that format, so if you could help me I would really appreciate it. ___ 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] HRPT receiver
Hi Marcus, APT is (analogue) FM BW ~35-40 kHz and HRPT BW 3 MHz digital. Using a RTLSDR to receive APT can also be found here using windows http://www.poes-weather.com/rtl-sdr/ and howto build a good antenna (RHCP) @ 137 MHz here http://www.poes-weather.com/download/jm-dca/ Patrik On Tue, 2014-02-25 at 09:58 +0100, Marcus Müller wrote: Hi Pablo, Googling Noaa image format instantly yielded: http://commons.wikimedia.org/wiki/File:NOAA_APT_Frame_Format.gif http://www.sat.dundee.ac.uk/hrptformat.html It's already been done a few times - for example like this (really just googling GNU Radio NOAA image decode and clicking the first thing away...) http://www.oz9aec.net/index.php/gnu-radio/gnu-radio-blog/350-noaa-weather-satellite-reception-with-gnu-radio-and-usrp but here, Alexandru Csete used a GNU Radio-Based flowgraph just to record the received signal to a Wav file and process it via atpdec http://atpdec.sourceforge.net/ and, honestly, how cool would it be if you wrote a small piece of GNU Radio software that had a signal sink, which used the atpdec code and displayed images in a window? (Hint: awesome). So: Happy Hacking, Marcus On 02/25/2014 09:38 AM, Pablo Fernández Alonso wrote: Hello, I was wondering if someone can receive hrpt images from NOAA satellites or similar, if so, could you help me with the implementation of the receiver? There is not quite information about that format, so if you could help me I would really appreciate it. ___ 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
[Discuss-gnuradio] broken gnuplot
Hi all guys, lately I have experienced some problems with showing scope and fft plot. Namely, the plots looks raw and ugly. Once there was an report that gnuplot was killed. Any idea how to check and repair this? Best, -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] broken gnuplot
On 02/25/2014 12:49 PM, Nemanja Savic wrote: Hi all guys, lately I have experienced some problems with showing scope and fft plot. Namely, the plots looks raw and ugly. Once there was an report that gnuplot was killed. Any idea how to check and repair this? Are you using gnuplot? What exactly are doing and which tools are you using? M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK
Hi Abhishek, When implemented gr-dvbt (https://github.com/BogdanDIA/gr-dvbt) I used VOLK in many places to speed-up the processing. However, there is a great deal of speed-up that still need to be achieved on both Tx/Rx in order to lower cpu cycles consumption so there are a lot of challenges in the project from this point of view. For example the Viterbi implementation is done using intrinsics instead of using VOLK just because when I used VOLK it was quite slow, achieving only 16mbps of processing per single thread (7-8mbps on just C implementation). Using intrinsics it raised the spead to 32-37mbps per thread which is quite good but the code is not directly portable. So, a good Viterbi decoder that achieves easily over 60mbps speed at input is still necessary probably not only in dvb-t implementation but perhaps in other applications. Just to add more to the challenge one may want to have a readable code beside the necessary speed (Spiral viterbi implementation is on the opposite side). The OFDM synchronization code is also very time consuming and although uses VOLK already it can be using with great benefit new AVX2 instructions. Actually many of the blocks can use new instructions to speed-up the data processing. Basically, for dvb-t on it's maximum speed with OFDM FFT 8k, QAM-64 and puncturing rate 7/8 the output of video is of 32mbps which means more than 60mbps of processing speed after de-puncturing. A bigger challenge would be implementing real life DVB-S receiver where the data rate is over 50mbps at video output :) ). This is just my short insight of challenges one may face when dealing with speed optimizations in a modern communication project. Bogdan On Sun, 2/23/14, Abhishek Bhowmick abhowmic...@gmail.com wrote: Subject: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK To: discuss-gnuradio@gnu.org Date: Sunday, February 23, 2014, 8:52 AM Hello, I have completed a Bachelor's degree in Electrical Engineering from IIT Bombay, India and will be joining a masters program in Computer Science in August. For the summer, I am interested in participating GSoC 2014 and GNU Radio is an organization where my background fits nicely. I went through the ideas page and was particularly interested in doing performance optimization with VOLK. After going through some online documentation about the library and the SDR'12 paper, I realised that following areas need work : 1. Profiling GNU radio code to identify new kernels and implement them for existing Intel SIMD extensions, also porting kernels to other ISA extensions. 2. Better testing of the effects of more complex scheduler logic on larger environments (beyond simple kernels) 3. Exploring extension of Volk to GPU ISAs, to leverage chips such as AMD Fusion (However, this seems to more research than software development) According to the GSoC proposal, point (1) seems to be the expectation. Given this, I would like some advice on how to go ahead looking for potential ideas (and some feedback on feasibility of the other ideas as well) My background : C++, Python, Signal Processing, Computer Architecture Thanks, Abhishek Bhowmick -Inline Attachment Follows- ___ 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] GSoC2014 Turbo Equalizer
Hi everyone, I am a student at Communications Engineering Lab (CEL) at Karlsruhe Institute of Technology. I major in communication systems and I am currently doing my masterthesis on Parallel log-map decoders for manycore architectures. I am interested in participating in GSoC 2014. There is an older GNURadio GSoC proposal from 2013 to implement a turbo equalizer module in GNURadio in which i am particularly interested working on, as it is closely connected to my current field of study. So i would like to share my thoughts on a possible Update of the old turbo equalizer proposal (and maybe upgrading it to a current proposal ?). - *Turbo Equalizer* A Turbo Equalizer is a receiver component that is highly effective when receiving messages corrupted by Intersymbol Interference (ISI). To archive this, the turbo equalizer uses an Equalizer to eliminate the ISI and a Log-Map Decoder for Forward Error Correction. Both components pass soft information to each other to increase the performance. *Objectives* Possible (sub-)projects: 1. Implement the Log-Map decoder - preferably it can be fully configurable (constraint length, number of states, trellis structure) - preferably optimized for real time applications 2. Implement the linear equalizer - preferably optimized for real time applications *Skills* Knowledge of digital signal processing, C/C++, Python *Potential mentor(s)* Sebastian Koslowski, Michael Schwall -- That would be a project I think would be really interesting to work on and i think it fits well with some of the other proposals for new GNU Radio Modules. As the turbo eq itself is a highly complex architecture, it could also be beneficial to split the tasks in this project. It would be great to get some feedback from you, if this was a proposal that would benefit GNURadio and if it has the potential to be included in the GSoC list of ideas. Thanks and regards, Jan Krämer ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] broken gnuplot
On Tue, Feb 25, 2014 at 8:07 AM, Nemanja Savic vlasi...@gmail.com wrote: So, it is default installation. I use RHEL6. Some time ago I uninstalled numpy due to installation of new version of matplotlib (I don't know if this is important). Now my gui looks like this That's using wxPython, not gnuplot. It doesn't use matplotlib, either (which depends on numpy, so if you installed matplotlib, you also still have numpy). That will have no effect on the wxgui plots. This is possibly related to opengl, though. You can turn that off by editing $prefix/etc/gnuradio/conf.d/gr-wxgui.conf. Tom On Tue, Feb 25, 2014 at 1:13 PM, Martin Braun martin.br...@ettus.comwrote: On 02/25/2014 12:49 PM, Nemanja Savic wrote: Hi all guys, lately I have experienced some problems with showing scope and fft plot. Namely, the plots looks raw and ugly. Once there was an report that gnuplot was killed. Any idea how to check and repair this? Are you using gnuplot? What exactly are doing and which tools are you using? M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Nemanja Savić ___ 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] Google Summer of Code 2014 applicant : Optimization with VOLK
On Tue, Feb 25, 2014 at 8:21 AM, Bogdan Diaconescu b_diacone...@yahoo.com wrote: Hi Abhishek, When implemented gr-dvbt (https://github.com/BogdanDIA/gr-dvbt) I used VOLK in many places to speed-up the processing. However, there is a great deal of speed-up that still need to be achieved on both Tx/Rx in order to lower cpu cycles consumption so there are a lot of challenges in the project from this point of view. For example the Viterbi implementation is done using intrinsics instead of using VOLK just because when I used VOLK it was quite slow, achieving only 16mbps of processing per single thread (7-8mbps on just C implementation). Using intrinsics it raised the spead to 32-37mbps per thread which is quite good but the code is not directly portable. So, a good Viterbi decoder that achieves easily over 60mbps speed at input is still necessary probably not only in dvb-t implementation but perhaps in other applications. Just to add more to the challenge one may want to have a readable code beside the necessary speed (Spiral viterbi implementation is on the opposite side). Bogdan, Good advice, generally. Just a few issues to point out. First, I think there's a misconception between VOLK and using intrinsics. VOLK uses intrinsics and so whatever code you wrote with the intrinsics could be done in VOLK. For instance, the fecapi that we are working to bring into GNU Radio has a constitutional decoder defined as a single VOLK kernel: https://github.com/namccart/fecapi/blob/master/volk_fecapi/kernels/volk_fecapi/volk_fecapi_8u_x4_conv_k7_r2_f2048_8u.h This is actually Spiral code that was wrapped up into a kernel to make it portable and usable. Basically, I'm trying to convey that there is not limit to what we can define as a kernel in VOLK. In fact, the more complex the kernel, the better the speedup because you can keep the data inside the registers and more tightly control the algorithm. We just want a kernel to represent some operations that would be usable in other situations, like a convolutional decoder. The OFDM synchronization code is also very time consuming and although uses VOLK already it can be using with great benefit new AVX2 instructions. Actually many of the blocks can use new instructions to speed-up the data processing. Yes, certainly. The synchronization part is a good place for optimization. Tom Basically, for dvb-t on it's maximum speed with OFDM FFT 8k, QAM-64 and puncturing rate 7/8 the output of video is of 32mbps which means more than 60mbps of processing speed after de-puncturing. A bigger challenge would be implementing real life DVB-S receiver where the data rate is over 50mbps at video output :) ). This is just my short insight of challenges one may face when dealing with speed optimizations in a modern communication project. Bogdan On Sun, 2/23/14, Abhishek Bhowmick abhowmic...@gmail.com wrote: Subject: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK To: discuss-gnuradio@gnu.org Date: Sunday, February 23, 2014, 8:52 AM Hello, I have completed a Bachelor's degree in Electrical Engineering from IIT Bombay, India and will be joining a masters program in Computer Science in August. For the summer, I am interested in participating GSoC 2014 and GNU Radio is an organization where my background fits nicely. I went through the ideas page and was particularly interested in doing performance optimization with VOLK. After going through some online documentation about the library and the SDR'12 paper, I realised that following areas need work : 1. Profiling GNU radio code to identify new kernels and implement them for existing Intel SIMD extensions, also porting kernels to other ISA extensions. 2. Better testing of the effects of more complex scheduler logic on larger environments (beyond simple kernels) 3. Exploring extension of Volk to GPU ISAs, to leverage chips such as AMD Fusion (However, this seems to more research than software development) According to the GSoC proposal, point (1) seems to be the expectation. Given this, I would like some advice on how to go ahead looking for potential ideas (and some feedback on feasibility of the other ideas as well) My background : C++, Python, Signal Processing, Computer Architecture Thanks, Abhishek Bhowmick -Inline Attachment Follows- ___ 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] broken gnuplot
Is there any way to repair this, because one or two months ago, everything was ok? Or, is there any log where I can figure what is the exact problem? On Tue, Feb 25, 2014 at 3:02 PM, Tom Rondeau t...@trondeau.com wrote: On Tue, Feb 25, 2014 at 8:07 AM, Nemanja Savic vlasi...@gmail.com wrote: So, it is default installation. I use RHEL6. Some time ago I uninstalled numpy due to installation of new version of matplotlib (I don't know if this is important). Now my gui looks like this That's using wxPython, not gnuplot. It doesn't use matplotlib, either (which depends on numpy, so if you installed matplotlib, you also still have numpy). That will have no effect on the wxgui plots. This is possibly related to opengl, though. You can turn that off by editing $prefix/etc/gnuradio/conf.d/gr-wxgui.conf. Tom On Tue, Feb 25, 2014 at 1:13 PM, Martin Braun martin.br...@ettus.comwrote: On 02/25/2014 12:49 PM, Nemanja Savic wrote: Hi all guys, lately I have experienced some problems with showing scope and fft plot. Namely, the plots looks raw and ugly. Once there was an report that gnuplot was killed. Any idea how to check and repair this? Are you using gnuplot? What exactly are doing and which tools are you using? M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] broken gnuplot
On Tue, Feb 25, 2014 at 9:35 AM, Nemanja Savic vlasi...@gmail.com wrote: Is there any way to repair this, because one or two months ago, everything was ok? Or, is there any log where I can figure what is the exact problem? Well, since we don't know what you changed on your side, it's hard to help you fix it. Again, numpy, matplotlib, and gnuplot have nothing to do with this. Have you tried my suggestion of turning opengl off? That tends to be the main problem people have with using wxgui. Tom On Tue, Feb 25, 2014 at 3:02 PM, Tom Rondeau t...@trondeau.com wrote: On Tue, Feb 25, 2014 at 8:07 AM, Nemanja Savic vlasi...@gmail.com wrote: So, it is default installation. I use RHEL6. Some time ago I uninstalled numpy due to installation of new version of matplotlib (I don't know if this is important). Now my gui looks like this That's using wxPython, not gnuplot. It doesn't use matplotlib, either (which depends on numpy, so if you installed matplotlib, you also still have numpy). That will have no effect on the wxgui plots. This is possibly related to opengl, though. You can turn that off by editing $prefix/etc/gnuradio/conf.d/gr-wxgui.conf. Tom On Tue, Feb 25, 2014 at 1:13 PM, Martin Braun martin.br...@ettus.com wrote: On 02/25/2014 12:49 PM, Nemanja Savic wrote: Hi all guys, lately I have experienced some problems with showing scope and fft plot. Namely, the plots looks raw and ugly. Once there was an report that gnuplot was killed. Any idea how to check and repair this? Are you using gnuplot? What exactly are doing and which tools are you using? M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr::buffer::index_add Assertion failure
On Mon, Feb 24, 2014 at 6:49 PM, Tommy Tracy II tj...@virginia.edu wrote: Dear community, Every now and then, when I execute my GNU Radio program, I get the following error. Has someone seen this before? It looks like a buffer access problem, but I'm not sure why it happens on and off /home/tjt7a/src/pybombs/src/gnuradio/gnuradio-runtime/include/gnuradio/buffer.h:170: unsigned int gr::buffer::index_add(unsigned int, unsigned int): Assertion `s d_bufsize' failed. Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 You should absolutely not be seeing this error. That code is far below the API and hasn't changed for quite a few years. I'm guessing you're abusing the scheduler somehow. Check any blocks that you've created to make sure they are handling the input/output buffers and consume/produce issues properly. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK
Hi Tom, thanks for your answer. The point I was making was that at the moment of me writing the Viterbi code, I tried to use the available VOLK functions (multiplications, subtractions, etc) and the code was slower than using directly intrinsics. Implementing a new kernel for Viterbi decoder (with intrinsics of course like the others) was just the next step in the process. So, I totally agree that it worth creating a kernel to completely solve a problem like a convolutional decoder as it will make it faster. The downside would be, though, that the next time you want to do something slightly different you'll need to create another kernel. But that is the tradeoff between the flexibility and speed. I see the your code using Spiral implementation, I will look to see what speed it gives as for me this is one of the biggest challenges. I still believe there will be someone who will create a convolutional decoder implementation that is both readable and fast :). I know, I am speaking from a open source sw. guys perspective :) who inherently has the need to understand all the code. Bogdan BTW, from my experience, to speed-up in the case of depuncturing it worth making depuncturer part of the decoder or at least aware of that. On Tue, 2/25/14, Tom Rondeau t...@trondeau.com wrote: Subject: Re: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK To: Bogdan Diaconescu b_diacone...@yahoo.com Cc: GNURadio Discussion List discuss-gnuradio@gnu.org, Abhishek Bhowmick abhowmic...@gmail.com Date: Tuesday, February 25, 2014, 4:09 PM On Tue, Feb 25, 2014 at 8:21 AM, Bogdan Diaconescu b_diacone...@yahoo.com wrote: Hi Abhishek, When implemented gr-dvbt (https://github.com/BogdanDIA/gr-dvbt) I used VOLK in many places to speed-up the processing. However, there is a great deal of speed-up that still need to be achieved on both Tx/Rx in order to lower cpu cycles consumption so there are a lot of challenges in the project from this point of view. For example the Viterbi implementation is done using intrinsics instead of using VOLK just because when I used VOLK it was quite slow, achieving only 16mbps of processing per single thread (7-8mbps on just C implementation). Using intrinsics it raised the spead to 32-37mbps per thread which is quite good but the code is not directly portable. So, a good Viterbi decoder that achieves easily over 60mbps speed at input is still necessary probably not only in dvb-t implementation but perhaps in other applications. Just to add more to the challenge one may want to have a readable code beside the necessary speed (Spiral viterbi implementation is on the opposite side). Bogdan, Good advice, generally. Just a few issues to point out. First, I think there's a misconception between VOLK and using intrinsics. VOLK uses intrinsics and so whatever code you wrote with the intrinsics could be done in VOLK. For instance, the fecapi that we are working to bring into GNU Radio has a constitutional decoder defined as a single VOLK kernel: https://github.com/namccart/fecapi/blob/master/volk_fecapi/kernels/volk_fecapi/volk_fecapi_8u_x4_conv_k7_r2_f2048_8u.h This is actually Spiral code that was wrapped up into a kernel to make it portable and usable. Basically, I'm trying to convey that there is not limit to what we can define as a kernel in VOLK. In fact, the more complex the kernel, the better the speedup because you can keep the data inside the registers and more tightly control the algorithm. We just want a kernel to represent some operations that would be usable in other situations, like a convolutional decoder. The OFDM synchronization code is also very time consuming and although uses VOLK already it can be using with great benefit new AVX2 instructions. Actually many of the blocks can use new instructions to speed-up the data processing. Yes, certainly. The synchronization part is a good place for optimization. Tom Basically, for dvb-t on it's maximum speed with OFDM FFT 8k, QAM-64 and puncturing rate 7/8 the output of video is of 32mbps which means more than 60mbps of processing speed after de-puncturing. A bigger challenge would be implementing real life DVB-S receiver where the data rate is over 50mbps at video output :) ). This is just my short insight of challenges one may face when dealing with speed optimizations in a modern communication project. Bogdan On Sun, 2/23/14, Abhishek Bhowmick abhowmic...@gmail.com wrote: Subject: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK To: discuss-gnuradio@gnu.org Date: Sunday, February 23, 2014, 8:52 AM Hello, I have completed a Bachelor's degree in Electrical Engineering from IIT Bombay, India and will be joining a masters program
[Discuss-gnuradio] GSoC2014 Turbo Equalizer
Just FYI, the gr-trellis has implementations of all these components you suggested. One interesting project is to take the core algorithms of gr-trellis (Viterbi and SISO) and make them threaded for multi-core (eg, by parallelizing forward/backward recursions, or by parallelizing using overlapping subblocks, etc) best Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSoC2014 Turbo Equalizer
On Tue, Feb 25, 2014 at 10:39 AM, Achilleas Anastasopoulos anas...@umich.edu wrote: Just FYI, the gr-trellis has implementations of all these components you suggested. One interesting project is to take the core algorithms of gr-trellis (Viterbi and SISO) and make them threaded for multi-core (eg, by parallelizing forward/backward recursions, or by parallelizing using overlapping subblocks, etc) best Achilleas Also using VOLK inside gr-trellis blocks should provide significant speedup there. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QT GUI Chooser not working
On Mon, Feb 24, 2014 at 10:01 PM, Tom McDermott tom.mcdermo...@yahoo.com wrote: GRC v3.7.2.1-195-g19d111e2 // ubuntu 13.10 Using QT GUI range works fine, changing it to QT GUI chooser (Type = Integer) seems to fail (regardless of number of options), with the following error message: linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.006.000-0-g7788c692 Traceback (most recent call last): File /home/tom/Desktop/top_block.py, line 185, in module tb = top_block() File /home/tom/Desktop/top_block.py, line 78, in __init__ self._RxFreq_callback(self.RxFreq) File /home/tom/Desktop/top_block.py, line 77, in lambda self._RxFreq_callback = lambda i: Qt.QMetaObject.invokeMethod(self._RxFreq_button_group, updateButtonChecked, Qt.Q_ARG(int, self._RxFreq_options.index(i))) ValueError: tuple.index(x): x not in tuple A bug? More information needed? -- Tom, N5EG Just tested this locally, using a integer chooser to change the noise type of a noise source. Worked fine for me. My guess is a version difference. I'm running QT 4.8.1 (on Ubuntu 12.04). This also worked for me using QWT 5.2 and 6.1. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSoC2014 Turbo Equalizer
Yes, I agree with Tom. A good starting point is the three or four core algorithms in gr-trellis/lib/core_algorithms.cc viterbi_algorithm, siso_algorithm, sccc_decoder pccc_decoder (and their _combined versions) Jan, let me know if you decide to work on these; I can provide some ideas if you are interested. best, Achilleas On Tue, Feb 25, 2014 at 10:47 AM, Tom Rondeau t...@trondeau.com wrote: On Tue, Feb 25, 2014 at 10:39 AM, Achilleas Anastasopoulos anas...@umich.edu wrote: Just FYI, the gr-trellis has implementations of all these components you suggested. One interesting project is to take the core algorithms of gr-trellis (Viterbi and SISO) and make them threaded for multi-core (eg, by parallelizing forward/backward recursions, or by parallelizing using overlapping subblocks, etc) best Achilleas Also using VOLK inside gr-trellis blocks should provide significant speedup there. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QT waterfall sink manual intensity
On Mon, Feb 24, 2014 at 10:38 PM, Louis Brown rfe...@everestkc.net wrote: Is there way to manually scale the intensity of the QT waterfall sink, in other words, set the dynamic range and reference level like the WX sink? Adjusting the time axis with the scroll wheel alters the intensity axis, but the actual color values don't change. Thanks, Lou KD4HSO Just to make sure, are you using the QTGUI sink (the one with tabs for the different types of plots) or the waterfall sink (with /just/ the waterfall). If the former, there should be two bars for the upper and lower intensities that will affect the colors. If using the waterfall plot directly, we haven't instrumented the min/max from the gui directly (to avoid clutter). However, the object does export the set_intensity_range(double min, double max) that you can use to directly control these. Alternatively, with this plot, if you middle-click on the mouse, the drop-down menu offers an Auto Scale feature that will adjust the dynamic range based on the min/max values in the current plot. I've found that to be the most useful way to control the intensity. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] (GSoC) MIMO system
Hi Alick, Do you have an english copy of your thesis? I am looking to read up on MIMO implementation and try a few basic things on gnuradio. On Mon, Feb 24, 2014 at 11:34 PM, Martin Braun martin.br...@ettus.comwrote: On 02/24/2014 05:08 PM, YiZiRui Zhou wrote: Hi Tom, As far as I am concerned, plenty of work has done on MIMO. While both of the software(GNU Radio) and the hardware(USRP) are developing fast, many of the source codes are not compatible. So, maybe I have to do this work from the beginning, while former works are still instructive. Do you think I should add this idea to the GR GSoC website? Sure, go ahead! M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Regards Karan Talasila ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSoC2014 Turbo Equalizer
On 02/25/2014 04:39 PM, Achilleas Anastasopoulos wrote: Just FYI, the gr-trellis has implementations of all these components you suggested. One interesting project is to take the core algorithms of gr-trellis (Viterbi and SISO) and make them threaded for multi-core (eg, by parallelizing forward/backward recursions, or by parallelizing using overlapping subblocks, etc) Jan, gr-trellis would be a good place to start looking, but there's still enough to do between gr-trellis and a fully working, optimized, real-time capable Parallel log-map-siso turbo equalizer. When you write a proposal, make sure you've had a look at gr-trellis beforehand. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] QPSK over air
I'm looking for an example of a higher-order modulation implemented successfully in GNU Radio with an SDR frontend. I've seen bpsk, GMSK, etc. implemented over a wireless channel, but I've only seen simulations of higher-order modulations. Could someone point me towards one or confirm that there's no examples? Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QPSK over air
Hi Mark, The problem is that GNU Radio does not have equalizers that can perform sufficiently well for constellations such as 64-QAM. As far as I know, the only one present is a simple decision feedback equalizer. I'm working on implementing a few equalizers: a) 2D Triangulation, and b) Whittaker-Shannon Sinc interpolator, and c) one of my own. These aren't yet ready to share, but once they are, I will send out an email to the list. Best, Aditya On Tue, Feb 25, 2014 at 1:11 PM, SOUTHCOTT, MARK A CIV USAF AFMC AFRL/RITC mark.southcot...@us.af.mil wrote: I'm looking for an example of a higher-order modulation implemented successfully in GNU Radio with an SDR frontend. I've seen bpsk, GMSK, etc. implemented over a wireless channel, but I've only seen simulations of higher-order modulations. Could someone point me towards one or confirm that there's no examples? Mark ___ 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] GSoC2014 Turbo Equalizer
I know I could look to Google / do an internet search, but maybe asking here would be better.What is/are the -seminal- paper/s on parallel log-map-siso decoding? I implemented the non-parallel version of the log-map algorithm -way- back in 2001 on whatever the portable Mac was at the time (5300ce, IIRC). I stripped all of the crap out, and made it -really- fast for non-parallel / non-intrinsics / non-Altivec / non-SIMD / non-accelerated (beyond whatever the compiler did). I thought a lot about how to parallelize the algorithm, but since this was for a class all I needed was the fastest (which it was) my thoughts ended in May with graduation. I have no idea if I still have this code around, but I keep up with channel coding research to some degree since it's been an interest for years. Hence, my question. Thanks! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QPSK over air
On 02/25/2014 07:11 PM, SOUTHCOTT, MARK A CIV USAF AFMC AFRL/RITC wrote: I’m looking for an example of a higher-order modulation implemented successfully in GNU Radio with an SDR frontend. I’ve seen bpsk, GMSK, etc. implemented over a wireless channel, but I’ve only seen simulations of higher-order modulations. Could someone point me towards one or confirm that there’s no examples? Mark, check out files in gr-digital/examples/narrowband and -demod. QPSK and 8-PSK will work out-of-the-box, people have done that ota, too (I've done it inside the OFDM code, for example). M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QPSK over air
On 02/25/2014 07:17 PM, Aditya Dhananjay wrote: Hi Mark, The problem is that GNU Radio does not have equalizers that can perform sufficiently well for constellations such as 64-QAM. As far as I know, the only one present is a simple decision feedback equalizer. I'm working on implementing a few equalizers: a) 2D Triangulation, and b) Whittaker-Shannon Sinc interpolator, and c) one of my own. These aren't yet ready to share, but once they are, I will send out an email to the list. Yeah, that's a good point :) What we have in stock GR should work up to 8-PSK, but higher than that, they will probably be the limiting factor. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Bypassing CIC and half-band filter on N2x0
Is there any way to bypass the CIC and the HBF on the USRP N200 to just stream decimated (no integration) real samples off the 100 MHz ADC? I'd like to eg., record every 25th sample arriving on the ADC. I'd like to avoid compiling my own fpga is necessary. Is there any configuration of calc_cic_filter_word and calc_cordic_word_and_update in the firmware that would magically do this? juha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 135, Issue 30
Dear Martin, Thanks for the suggestion, makes sense to me. I'll try an higher level (different) approach and then consider making changes on the block. Germano On 02/25/2014 05:01 PM, discuss-gnuradio-requ...@gnu.org wrote: With the stock behaviour, it's not possible. If you want to change the block, I recommend passing the new carrier allocation as a tag, check for that at the beginning of work() and re-populate the corresponding attributes. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSoC2014 Turbo Equalizer
Mike, there are roughly 3 ways you can parallelize these algorithms: 1) packet-level: run a lot of codewords at the same time 2) subblock level: divide each codeword into pieces (overlapping) and run SISOs on each one of them in parallel 3) trellis level: do ACS operations in parallel take a look at the following link and references to get some ideas (not claiming it is a seminal paper though :-)) http://web.eecs.umich.edu/~anastas/docs/turbogpu.pdf best, Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QPSK over air
On Tue, Feb 25, 2014 at 3:04 PM, Martin Braun martin.br...@ettus.com wrote: On 02/25/2014 07:17 PM, Aditya Dhananjay wrote: Hi Mark, The problem is that GNU Radio does not have equalizers that can perform sufficiently well for constellations such as 64-QAM. As far as I know, the only one present is a simple decision feedback equalizer. I'm working on implementing a few equalizers: a) 2D Triangulation, and b) Whittaker-Shannon Sinc interpolator, and c) one of my own. These aren't yet ready to share, but once they are, I will send out an email to the list. Yeah, that's a good point :) What we have in stock GR should work up to 8-PSK, but higher than that, they will probably be the limiting factor. M The lms_dd_equalizer should work fine for any constellation, for some definition of 'fine'. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK
On Sun, 2/23/14, Abhishek Bhowmick abhowmic...@gmail.com wrote: Subject: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK To: discuss-gnuradio@gnu.org Date: Sunday, February 23, 2014, 8:52 AM Hello, I have completed a Bachelor's degree in Electrical Engineering from IIT Bombay, India and will be joining a masters program in Computer Science in August. For the summer, I am interested in participating GSoC 2014 and GNU Radio is an organization wheAbhishekre my background fits nicely. I went through the ideas page and was particularly interested in doing performance optimization with VOLK. After going through some online documentation about the library and the SDR'12 paper, I realised that following areas need work : 1. Profiling GNU radio code to identify new kernels and implement them for existing Intel SIMD extensions, also porting kernels to other ISA extensions. 2. Better testing of the effects of more complex scheduler logic on larger environments (beyond simple kernels) 3. Exploring extension of Volk to GPU ISAs, to leverage chips such as AMD Fusion (However, this seems to more research than software development) According to the GSoC proposal, point (1) seems to be the expectation. Given this, I would like some advice on how to go ahead looking for potential ideas (and some feedback on feasibility of the other ideas as well) My background : C++, Python, Signal Processing, Computer Architecture Thanks, Abhishek Bhowmick This is a great conversation, and I'll take the opportunity to plug the up coming VOLK working group call (https://plus.google.com/u/1/events/ch3jrjcvp7mdiqelpismfieg3n0). Bogdan, your results aren't particula rly surprising, but the feedback is really good to hear. Back to GSoC: Abhishek, Thanks for the pointers to gr-atsc and gr-80211. I have started looking there as a starting point. Are there similar modules which are undergoing volk speedup fixes? I am also trying to meet up with other people who have been using GNU radio to identify potential modules for acceleration. As you are now a mentor organization, I feel it's a good time for us to get into detailed discussions. From the previous discussion it should be apparent that how algorithms are implemented will make the biggest difference, and that the new acceleration is primarily going to come from larger more complex kernels. At the end of the day it's going to be your proposal. So far on the list of places to look we have * in-tree OFDM (contact Martin) * gr-atsc (use Andrew Davis' fork) * gr-dvbt * gr-fecapi For your proposal I would recommend looking at their code, then getting in contact with the author(s) of those modules to ask about their thoughts on accelerating blocks they have written. The reality of this project is that we are accelerating some signal processing algorithm and knowledge of that algorithm is useful for acceleration. Whatever application you have interested and/or knowledge in (fresh out of a BS it's more likely to be interest) should guide your proposal. If you know anything about error correcting codes then the latter 2 would be good fits. OFDM frame detection probably has a gentler learning curve since at the basic level you're looking at convolution, and there's papers you can look for on more involved algorithms. Other algorithms to look at might include agc or equalizers. If you're interested in GPU programming don't forget to checkout gr-gpu. At the moment the only mainstream ISA not being targeted is probably AVX2, which has some nice features for the type of kernels we're doing. If you went that route it would likely need add protokernels to a pretty large number of kernels. Nathan This also seems to be promising, though I guess it would require me to come up to speed with AVX2 (which I would love to do). Could you please elaborate a little on the kind of beneficial features you have in mind ? I am concerned that the job of adding proto-kernels might turn out to be mundane/tedious ? Is that a valid concern ? Right, so as Martin mentioned the answer is sort of relative. I wouldn't go so far as to say it's mundane, especially if you have little experience with using intrinsics and SIMD instructions. One reason AVX isn't so prominently featured (I suspect) is that the instructions are almost the same as SSE instructions, but the vectors are twice as long so that is actually mundane. AVX2/FMA extensions introduce some new features to the amd64 instruction set. The most obvious being that it looks like Intel and AMD finally settled in on the same fused multiply-add (there's also a multiply-subtract that's good for complex numbers) implementation. That will
Re: [Discuss-gnuradio] broken gnuplot
Thank you Tom. I try tomorrow. On Tue, Feb 25, 2014 at 4:20 PM, Tom Rondeau t...@trondeau.com wrote: On Tue, Feb 25, 2014 at 9:35 AM, Nemanja Savic vlasi...@gmail.com wrote: Is there any way to repair this, because one or two months ago, everything was ok? Or, is there any log where I can figure what is the exact problem? Well, since we don't know what you changed on your side, it's hard to help you fix it. Again, numpy, matplotlib, and gnuplot have nothing to do with this. Have you tried my suggestion of turning opengl off? That tends to be the main problem people have with using wxgui. Tom On Tue, Feb 25, 2014 at 3:02 PM, Tom Rondeau t...@trondeau.com wrote: On Tue, Feb 25, 2014 at 8:07 AM, Nemanja Savic vlasi...@gmail.com wrote: So, it is default installation. I use RHEL6. Some time ago I uninstalled numpy due to installation of new version of matplotlib (I don't know if this is important). Now my gui looks like this That's using wxPython, not gnuplot. It doesn't use matplotlib, either (which depends on numpy, so if you installed matplotlib, you also still have numpy). That will have no effect on the wxgui plots. This is possibly related to opengl, though. You can turn that off by editing $prefix/etc/gnuradio/conf.d/gr-wxgui.conf. Tom On Tue, Feb 25, 2014 at 1:13 PM, Martin Braun martin.br...@ettus.com wrote: On 02/25/2014 12:49 PM, Nemanja Savic wrote: Hi all guys, lately I have experienced some problems with showing scope and fft plot. Namely, the plots looks raw and ugly. Once there was an report that gnuplot was killed. Any idea how to check and repair this? Are you using gnuplot? What exactly are doing and which tools are you using? M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Nemanja Savić -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK
On Tue, Feb 25, 2014 at 4:37 PM, West, Nathan n...@ostatemail.okstate.edu wrote: On Sun, 2/23/14, Abhishek Bhowmick abhowmic...@gmail.com wrote: Subject: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK To: discuss-gnuradio@gnu.org Date: Sunday, February 23, 2014, 8:52 AM Hello, I have completed a Bachelor's degree in Electrical Engineering from IIT Bombay, India and will be joining a masters program in Computer Science in August. For the summer, I am interested in participating GSoC 2014 and GNU Radio is an organization wheAbhishekre my background fits nicely. I went through the ideas page and was particularly interested in doing performance optimization with VOLK. After going through some online documentation about the library and the SDR'12 paper, I realised that following areas need work : 1. Profiling GNU radio code to identify new kernels and implement them for existing Intel SIMD extensions, also porting kernels to other ISA extensions. 2. Better testing of the effects of more complex scheduler logic on larger environments (beyond simple kernels) 3. Exploring extension of Volk to GPU ISAs, to leverage chips such as AMD Fusion (However, this seems to more research than software development) According to the GSoC proposal, point (1) seems to be the expectation. Given this, I would like some advice on how to go ahead looking for potential ideas (and some feedback on feasibility of the other ideas as well) My background : C++, Python, Signal Processing, Computer Architecture Thanks, Abhishek Bhowmick This is a great conversation, and I'll take the opportunity to plug the up coming VOLK working group call (https://plus.google.com/u/1/events/ch3jrjcvp7mdiqelpismfieg3n0). Bogdan, your results aren't particula rly surprising, but the feedback is really good to hear. Back to GSoC: Abhishek, Thanks for the pointers to gr-atsc and gr-80211. I have started looking there as a starting point. Are there similar modules which are undergoing volk speedup fixes? I am also trying to meet up with other people who have been using GNU radio to identify potential modules for acceleration. As you are now a mentor organization, I feel it's a good time for us to get into detailed discussions. From the previous discussion it should be apparent that how algorithms are implemented will make the biggest difference, and that the new acceleration is primarily going to come from larger more complex kernels. At the end of the day it's going to be your proposal. So far on the list of places to look we have * in-tree OFDM (contact Martin) * gr-atsc (use Andrew Davis' fork) * gr-dvbt * gr-fecapi For your proposal I would recommend looking at their code, then getting in contact with the author(s) of those modules to ask about their thoughts on accelerating blocks they have written. The reality of this project is that we are accelerating some signal processing algorithm and knowledge of that algorithm is useful for acceleration. Whatever application you have interested and/or knowledge in (fresh out of a BS it's more likely to be interest) should guide your proposal. If you know anything about error correcting codes then the latter 2 would be good fits. OFDM frame detection probably has a gentler learning curve since at the basic level you're looking at convolution, and there's papers you can look for on more involved algorithms. Other algorithms to look at might include agc or equalizers. If you're interested in GPU programming don't forget to checkout gr-gpu. At the moment the only mainstream ISA not being targeted is probably AVX2, which has some nice features for the type of kernels we're doing. If you went that route it would likely need add protokernels to a pretty large number of kernels. Nathan This also seems to be promising, though I guess it would require me to come up to speed with AVX2 (which I would love to do). Could you please elaborate a little on the kind of beneficial features you have in mind ? I am concerned that the job of adding proto-kernels might turn out to be mundane/tedious ? Is that a valid concern ? Right, so as Martin mentioned the answer is sort of relative. I wouldn't go so far as to say it's mundane, especially if you have little experienhttp://gnss-sdr.org/documentation/google-summer-code-2014-ideas-listce with using intrinsics and SIMD instructions. One reason AVX isn't so prominently featured (I suspect) is that the instructions are almost the same as SSE instructions, but the vectors are twice as long so that is actually mundane. AVX2/FMA extensions introduce some new features to the amd64 instruction set. The most
Re: [Discuss-gnuradio] QPSK over air
Only half of the solution, but there's a fully functional 64-QAM transmitter for bladeRF here: https://github.com/argilo/gr-qam It implements the North American CATV standard ANSI/SCTE07 also known as ITU-T J.83 Annex B. We're just using cable ready TV's as receivers. Ron On 2/25/2014 10:11 AM, SOUTHCOTT, MARK A CIV USAF AFMC AFRL/RITC wrote: I'm looking for an example of a higher-order modulation implemented successfully in GNU Radio with an SDR frontend. I've seen bpsk, GMSK, etc. implemented over a wireless channel, but I've only seen simulations of higher-order modulations. Could someone point me towards one or confirm that there's no examples? Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OOT Decimation Module dropping data samples
I am seeing some odd behavior with an OOT decimation block. What I am seeing is chunks of data are being dropped down to noise for random calls of the work function in my OOT. To observe this happening, I tee'd off the connection going into my OOT module and went strait into a file sink and then from within the OOT module for each call of the work function I stored off the incoming data to a file; the results of a good and bad frame of data are provided in the below links. Within this data, the top chart is the file sink tee'd off and you can see it tracking well for the most part with the data from within the module on the bottom. Within the bad frame image however, a little over 1000 samples in, the data drops down noise around 0 instead of being a nice (and slightly noisy...) sinusoid. The OOT module has a decimation value of 4000 in this particular case. I am running on Fedora 20 with a week old pull of GNURadio master branch. Does anybody have any thoughts as to why this is happening, and what I could do to resolve it? The first resolution that is coming to mind would be to re-write my OOT module to run with general_work, and manage the input buffer myself. Does anybody see any issues with doing this as a work around/solution? good frame: https://www.dropbox.com/s/tma3qn5byismgha/good_frame.png bad frame: https://www.dropbox.com/s/xgvcmlbgma14k0i/bad_frame.jpg Thank you all in advance for the help, Michael Berman ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-audio OSX fixes test branch
Another update to https://github.com/michaelld/gnuradio/tree/fix_gr_audio_osx
:
+ the audio source should be working fully now; I've tested with both the
built-in mic and a FUNcube Dongle Pro (not Pro+) and device selection works and
sample rates are correct;
+ audio source devices can be added and removed, and the source device usage
will be reconfigured on the fly (sink does not work like this yet; hopefully
tomorrow ...);
+ fixes a bug making low sample rates usable again (source and sink);
+ should not have any multi-threading conflicts (source; sink does not have
these yet);
+ can use the Default Audio Device and switch it using System Preferences on
the fly (source only right now; sink hopefully tomorrow ...).
Now that the source works with all this on the fly stuff, it'll be simple to
move that over to the sink -- of course, I do not have multiple audio sinks
from which to choose so I'll make those changes, push them, and hope someone
else can test them for functionality. Since the sink and source codes will be
roughly equivalent in threading / protection, they should both work the same
for in the fly stuff.
If you want do use MacPorts to test out these changes, here's what I recommend
you do:
1) make sure the gnuradio-devel port is installed and up to date
{{{
sudo port -f deactivate `port installed | grep gnuradio | sed -e
s@(active)@@g`
sudo port install gnuradio-devel
sudo port selfupdate
sudo port upgrade gnuradio-devel
}}}
2) Download the patch for these fixes; you can get them via my github branch
above (commit eaf27b15b4), and I've also put them into DropBox:
https://dl.dropboxusercontent.com/u/16655336/gr-audio-osx-wip-2014-02-25.diff
3) Patch gnuradio-devel; change /PATH/TO to be the correct path to the patch:
{{{
sudo port patch gnuradio-devel
cd `port work gnuradio-devel`/gnuradio*
sudo patch -p1 /PATH/TO/gr-audio-osx-wip-2014-02-25.diff
}}}
4) build gnuradio-devel:
{{{
sudo port build gnuradio-devel
}}}
5) install the gr audio library (assuming PREFIX=/opt/local; if not, change the
cp destination):
{{{
cd `port work gnuradio-devel`/build/gr-audio/lib
sudo cp libgnuradio-audio.3.7.3git.dylib /opt/local/lib
}}}
6) Try it out! For example:
{{{
/opt/local/share/gnuradio/examples/audio/audio_fft.py -r 96000 -I FUN
/opt/local/share/gnuradio/examples/audio/dial_tone.py -r 1200 -O Built
}}}
Try different rates, and different I/O devices. You should see printouts from
audio_osx_source and audio_osx_sink with information about what it's doing.
Let me know what you think! - MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QT waterfall sink manual intensity
I'm using just the waterfall sink. The spectrum is slightly oversampled so I see the decimation filter roll off to -170 dB and the edges, thus I'd like to set the intensity minimum at the passband noise floor which is up at -100 dB. The auto scale always catches -170 dB at the edges. I'll try editing the Python script directly to access the set_intensity_range(double min, double max) of the object, unless there is a way to do it in GRC. Thanks, Lou KD4HSO On Feb 25, 2014, at 10:28 AM, Tom Rondeau t...@trondeau.com wrote: On Mon, Feb 24, 2014 at 10:38 PM, Louis Brown rfe...@everestkc.net wrote: Is there way to manually scale the intensity of the QT waterfall sink, in other words, set the dynamic range and reference level like the WX sink? Adjusting the time axis with the scroll wheel alters the intensity axis, but the actual color values don't change. Thanks, Lou KD4HSO Just to make sure, are you using the QTGUI sink (the one with tabs for the different types of plots) or the waterfall sink (with /just/ the waterfall). If the former, there should be two bars for the upper and lower intensities that will affect the colors. If using the waterfall plot directly, we haven't instrumented the min/max from the gui directly (to avoid clutter). However, the object does export the set_intensity_range(double min, double max) that you can use to directly control these. Alternatively, with this plot, if you middle-click on the mouse, the drop-down menu offers an Auto Scale feature that will adjust the dynamic range based on the min/max values in the current plot. I've found that to be the most useful way to control the intensity. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-audio OSX fixes test branch
On Feb 25, 2014, at 19:06, Michael Dickens michael.dick...@ettus.com wrote:
Another update to
https://github.com/michaelld/gnuradio/tree/fix_gr_audio_osx :
...
If you want do use MacPorts to test out these changes, here's what I
recommend you do:
Thanks for including the instructions; otherwise I probably wouldn't have
gotten around to testing (as I haven't before).
1) make sure the gnuradio-devel port is installed and up to date
{{{
sudo port -f deactivate `port installed | grep gnuradio | sed -e
s@(active)@@g`
This can be more robustly written as
sudo port -f deactivate 'gnuradio*'
or (fewer harmless errors, same effect)
sudo port -f deactivate installed and 'gnuradio*'
5) install the gr audio library (assuming PREFIX=/opt/local; if not, change
the cp destination):
{{{
cd `port work gnuradio-devel`/build/gr-audio/lib
sudo cp libgnuradio-audio.3.7.3git.dylib /opt/local/lib
}}}
Mucking with MacPorts prefix files manually is a bad practice; why not just
install the gnuradio built in step 4? (Worked for me -- 'sudo port install -s
gnuradio') Doing this also means you only need to build/install gnuradio-devel
once (rather than installing it before patching it).
Try different rates, and different I/O devices. You should see printouts
from audio_osx_source and audio_osx_sink with information about what it's
doing.
Let me know what you think! - MLD
For the audio source, flowgraph start/stop/reconfiguring and specifying the
device name both work fine as far as I've tested them.
Some criticism of incidental aspects:
I hope that the final version will not send text to stdout, because this
interferes with a program delivering data to stdout; preferably all log-ish
output should be optional (other components of gnuradio fail at this), and if
present it should go to stderr rather than stdout.
The behavior on not finding the specified device should not be using the
default device; instead, it should fail in a way the caller can observe. Doing
otherwise creates or hides bugs. (For example, suppose I'm building a publicly
accessible receiver (like WebSDR) using a soundcard interface; if it used the
default input device if that device wasn't found, there's a good chance I'd
then be streaming audio from the room the computer is in, which is a privacy
problem!)
Furthermore any information important enough to warn on ought to be exposed to
the caller, not just stderr/stdout, if nothing else so that non-console-based
applications can communicate the information to their actual user interface, as
well as performing appropriate error handling.
--
Kevin Reid http://switchb.org/kpreid/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Summit on SDR
Dear Group, We are doing a multi-disciplinary faculty summit in Gr. Noida on 8th March'14. Wireless communication is also one of the parallel tracks. Sole purpose of the summit is to create awareness about SDR and recent trends in wireless communications. There will be demonstration of SDR40 by Amitech LTD and Labview by NI. Both faculty students can participate. More details can be found here http://goo.gl/TWT396 Links for registration Faculty http://goo.gl/OaJunm Students http://goo.gl/i1Z0gi Thanks Sumit -- View this message in context: http://gnuradio.4.n7.nabble.com/Summit-on-SDR-tp46573.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] Google Summer of Code 2014 applicant : Optimization with VOLK
Thanks everyone. These are quite a few pointers, I will spend some time digesting it all. So there are really two approaches, large complex kernels on one hand and AVX2/AVX/FMA on the other, or a combination of the two. I guess I should propose identifying and implementing larger complex kernels and then further accelerating using AVX2/FMA etc. Doing both will of course limit the number of applications/algorithms I can feasibly target. What's your take on this ? Abhishek On Wed, Feb 26, 2014 at 5:03 AM, West, Nathan n...@ostatemail.okstate.edu wrote: On Tue, Feb 25, 2014 at 4:37 PM, West, Nathan n...@ostatemail.okstate.edu wrote: On Sun, 2/23/14, Abhishek Bhowmick abhowmic...@gmail.com wrote: Subject: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK To: discuss-gnuradio@gnu.org Date: Sunday, February 23, 2014, 8:52 AM Hello, I have completed a Bachelor's degree in Electrical Engineering from IIT Bombay, India and will be joining a masters program in Computer Science in August. For the summer, I am interested in participating GSoC 2014 and GNU Radio is an organization wheAbhishekre my background fits nicely. I went through the ideas page and was particularly interested in doing performance optimization with VOLK. After going through some online documentation about the library and the SDR'12 paper, I realised that following areas need work : 1. Profiling GNU radio code to identify new kernels and implement them for existing Intel SIMD extensions, also porting kernels to other ISA extensions. 2. Better testing of the effects of more complex scheduler logic on larger environments (beyond simple kernels) 3. Exploring extension of Volk to GPU ISAs, to leverage chips such as AMD Fusion (However, this seems to more research than software development) According to the GSoC proposal, point (1) seems to be the expectation. Given this, I would like some advice on how to go ahead looking for potential ideas (and some feedback on feasibility of the other ideas as well) My background : C++, Python, Signal Processing, Computer Architecture Thanks, Abhishek Bhowmick This is a great conversation, and I'll take the opportunity to plug the up coming VOLK working group call (https://plus.google.com/u/1/events/ch3jrjcvp7mdiqelpismfieg3n0). Bogdan, your results aren't particula rly surprising, but the feedback is really good to hear. Back to GSoC: Abhishek, Thanks for the pointers to gr-atsc and gr-80211. I have started looking there as a starting point. Are there similar modules which are undergoing volk speedup fixes? I am also trying to meet up with other people who have been using GNU radio to identify potential modules for acceleration. As you are now a mentor organization, I feel it's a good time for us to get into detailed discussions. From the previous discussion it should be apparent that how algorithms are implemented will make the biggest difference, and that the new acceleration is primarily going to come from larger more complex kernels. At the end of the day it's going to be your proposal. So far on the list of places to look we have * in-tree OFDM (contact Martin) * gr-atsc (use Andrew Davis' fork) * gr-dvbt * gr-fecapi For your proposal I would recommend looking at their code, then getting in contact with the author(s) of those modules to ask about their thoughts on accelerating blocks they have written. The reality of this project is that we are accelerating some signal processing algorithm and knowledge of that algorithm is useful for acceleration. Whatever application you have interested and/or knowledge in (fresh out of a BS it's more likely to be interest) should guide your proposal. If you know anything about error correcting codes then the latter 2 would be good fits. OFDM frame detection probably has a gentler learning curve since at the basic level you're looking at convolution, and there's papers you can look for on more involved algorithms. Other algorithms to look at might include agc or equalizers. If you're interested in GPU programming don't forget to checkout gr-gpu. At the moment the only mainstream ISA not being targeted is probably AVX2, which has some nice features for the type of kernels we're doing. If you went that route it would likely need add protokernels to a pretty large number of kernels. Nathan This also seems to be promising, though I guess it would require me to come up to speed with AVX2 (which I would love to do). Could you please elaborate a little on the kind of beneficial features you have in mind ? I am concerned that the job of adding proto-kernels might turn out to be mundane/tedious ? Is that a
