Re: [Discuss-gnuradio] OFDM Channel Equalisation not unity for perfect channel
Hi again, My current suspicion is that there is a triggering delay produced by the *Schmidl & Cox OFDM Sync* block that isn't accounted for by the *delay* block currently running in parallel to it in the flowgraph (delays samples going to the header/payload demux until the trigger point is found in the sync words). On the default 64 FFT + 16 cyclic prefix arrangement for example, if I change the delay block from 80 to 73, it results in a unity OFDM channel estimation and I am able to decode successfully using my comb pilot interpolation equalisation technique (also: 89 gets unity alternating between the real and imaginary). It does appear however that the first estimation is off before correctly reaching unity on the second packet. This effect disappears if I bypass my *channel model *block (epsilon = 1, taps = 1.0, noise voltage = 0, frequency offset = 0). This raises the question of whether this triggering delay is somehow variable and depends on what blocks are currently in the flowgraph...? As a comparison, when I changed to having the header/payload demux triggered by a tag instead of the trigger port, I achieved a unity channel estimation. Is there something I'm misinterpreting about the Schmidl & Cox method's triggering or is this a known issue? Thanks for your help. Regards, Justin On Mon, May 8, 2017 at 1:01 PM, Justin Hamilton wrote: > Hi everyone, > > I've been working on a coded-OFDM system (looks similar to the standard > OFDM flowgraphs) and have come to the stage where I am trying to improve > channel estimation by implementing LS, STA and comb pilot interpolation > methods similar to gr-ieee802.11. If I follow the default technique > outlined in *ofdm_equalizer_simpledfe* and equalise just a single > subcarrier using its estimated tap calculated by the *OFDM Channel > Estimation* block, everything behaves as usual and I can decode my OFDM > packets. If however I start using neighbouring subcarriers as per STA or > when interpolating pilots, I am unable to decode any symbols. > > Suspecting something strange was going on, I began investigating my > flowgraph. Since I am running the system in simulation across a perfect > channel, I would have expected the channel taps derived by the *OFDM > Channel Estimation* block to all be equal to 1. Instead each channel > appeared to be experiencing it's own arbitrary value (which explains why > using multiple subcarriers wouldn't work). Since they are not equal to 1, I > figured some other part of the flowgraph must be applying some unintended > modulation. > > At first I suspected irreversibility between the FFT/IFFT blocks, but > after ensuring both were using *fft.window.rectangular(fft_len)* as the > selected window function and correctly rescaling after the FFT, I was able > to successfully recover the original signal directly after the IFFT. Next I > took a look at the *cyclic prefixer* and *header/payload demux* combo, > but after using a *Keep M in N *block after the *cyclic prefixer *I was > again able to recover the signal. > > This left only the *Schmidl & Cox OFDM Sync* block, *analog frequency > modulation* block and the subsequent multiplication. Since I was on a > perfect channel, it was no surprise that the fine frequency offset was 0Hz, > meaning the frequency mod block resulted in a simply multiplication by 1. > However,replacing the input to the frequency mod block with a constant > source of zero changed the resulting channel estimations further down the > line and meant they were correct (unity) for at least one packet (and again > on every third packet for some reason...) I can't really explain what's > going on...? > > Now I might be on the totally incorrect path here, so if anyone has any > suspicions or could recommend something for me to try out, it would be > greatly appreciated. I could be misinterpreting the Schmidl/Cox technique > for example or the role of channel equalisation altogether. Thanks in > advance for your help! > > Regards, > Justin > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Major OpenCL Updates
Ubuntu 16.04. I followed the notes for the nvidia install. Got me past the incompatible headers. Would be cool to steal the cmake opencl magic they use in gr-phosfor so it picks up the right includes and whatnot paths. Anywho, now I get: home/anon/gr-clenabled/lib/clFilter_impl.h:26:24: fatal error: fir_filter.h: No such file or directory I didn't poke around to see if this is auto-generated somehow, but given the recent commits relating to the topic, is it possible it just got missed in a commit? It is, indeed, not there: anon@anon:~/gr-clenabled$ find . -name "fir_filter.h" anon@anon:~/gr-clenabled$ On Sun, May 7, 2017 at 5:44 PM, GhostOp14 wrote: > Hi Anon. I set it up for 1.2. The biggest gotcha I've run into in the > build process is missing the cl.hpp file, but how to get it can vary by OS. > There's some setup notes in the setup_help directory for debian and Ubuntu > that may help you out. What OS are you running it on? > > On Sun, May 7, 2017 at 4:35 PM, Anon Lister wrote: >> >> Neat. What opencl implementation are you building against? >> >> I get errors related to _svm_ parts of code. I.e. >> cl_device_svm_capabilities was not declared in this scope. Trying to use the >> Nvidia cuda sdk, just downloaded from their developer site (ver 8.0). >> >> >> >> On May 6, 2017 8:59 AM, "Ghost Op" wrote: >>> >>> Hi everyone. A number of you have asked me to keep you informed of >>> any major updates on the OpenCL gr-clenabled project and the past >>> couple of weeks have been pretty active. There's now a version up in >>> the repo with a significant number of updates and all blocks have been >>> validated (at least in their basic modes). >>> >>> So here's the major updates: >>> >>> Validation flowgraphs - Almost all test flowgraphs have been posted in >>> the examples directory. You can run the comparisons on your own >>> hardware for comparison. This is important on older cards that don't >>> support double precision (you can check with the included clview >>> command-line tool). >>> >>> Signal Source Block - A discrepancy in the output was due to an >>> OpenCL issue. Turns out single/float precision wasn't producing >>> accurate enough numbers. This block now uses double precision if the >>> hardware supports it (most new hardware will) for an even cleaner >>> signal than the native block (no secondary nodes). >>> >>> Quad Demod - Same single/double trig discrepancy due to precision >>> which was corrected. >>> >>> Filters - A lot of work this week has been spent on filter validation >>> (hence the few emails about TD vs. FD from yesterday) >>> - Both FIR and FFT implementations are now implemented and >>> producing correct output >>> - A generic tap-based block was added for more flexibility >>> - A test-clfilter command-line tool was added to test performance >>> given a number of taps across OpenCL FIR, GNURadio FIR, OpenCL FFT, >>> and GNURadio FFT so you can pick the best performing filter given your >>> implementation. >>> >>> Costas Loop - A Costas Loop was added, however the performance on a >>> GPU kernel is horrible. Because of the sequential calculations, it >>> couldn't be SIMD parallel processed so it was written as an OpenCL >>> task-based kernel. This means it just runs single-threaded on a >>> single core, which is why the performance is so bad. However if >>> anyone has an OpenCL-capable FPGA card like an Altera I'd love to see >>> the result of running the included test-clenabled timing tool and see >>> how the Costas Loop performs. I just don't have access to one. >>> >>> Performance - Code was added to detect if the hardware supports Fused >>> Multiply/Add functionality for added kernel performance. If it's >>> available it's used. >>> >>> OpenCL Setup Instructions - For those that may not have OpenCL set up, >>> I added some installation guides in the setup_help directory for >>> Ubuntu and Debian with step-by-steps on getting it up and running. >>> I've taken both of those processes on several systems and been up and >>> running pretty quickly. I also pulled some of the important points >>> into the main page's README, since in my experience that's generally >>> all I look through too. >>> >>> Study - Based on the filter updates, the filter section in the study >>> in the docs directory was completely rewritten. The report was noted >>> as updated. >>> >>> I think that's the biggest updates for now. As always let me know if >>> anyone runs into any issues. >>> >>> ___ >>> 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] OFDM Channel Equalisation not unity for perfect channel
Hi everyone, I've been working on a coded-OFDM system (looks similar to the standard OFDM flowgraphs) and have come to the stage where I am trying to improve channel estimation by implementing LS, STA and comb pilot interpolation methods similar to gr-ieee802.11. If I follow the default technique outlined in *ofdm_equalizer_simpledfe* and equalise just a single subcarrier using its estimated tap calculated by the *OFDM Channel Estimation* block, everything behaves as usual and I can decode my OFDM packets. If however I start using neighbouring subcarriers as per STA or when interpolating pilots, I am unable to decode any symbols. Suspecting something strange was going on, I began investigating my flowgraph. Since I am running the system in simulation across a perfect channel, I would have expected the channel taps derived by the *OFDM Channel Estimation* block to all be equal to 1. Instead each channel appeared to be experiencing it's own arbitrary value (which explains why using multiple subcarriers wouldn't work). Since they are not equal to 1, I figured some other part of the flowgraph must be applying some unintended modulation. At first I suspected irreversibility between the FFT/IFFT blocks, but after ensuring both were using *fft.window.rectangular(fft_len)* as the selected window function and correctly rescaling after the FFT, I was able to successfully recover the original signal directly after the IFFT. Next I took a look at the *cyclic prefixer* and *header/payload demux* combo, but after using a *Keep M in N *block after the *cyclic prefixer *I was again able to recover the signal. This left only the *Schmidl & Cox OFDM Sync* block, *analog frequency modulation* block and the subsequent multiplication. Since I was on a perfect channel, it was no surprise that the fine frequency offset was 0Hz, meaning the frequency mod block resulted in a simply multiplication by 1. However,replacing the input to the frequency mod block with a constant source of zero changed the resulting channel estimations further down the line and meant they were correct (unity) for at least one packet (and again on every third packet for some reason...) I can't really explain what's going on...? Now I might be on the totally incorrect path here, so if anyone has any suspicions or could recommend something for me to try out, it would be greatly appreciated. I could be misinterpreting the Schmidl/Cox technique for example or the role of channel equalisation altogether. Thanks in advance for your help! Regards, Justin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-ieee802-11 wifi signal bitrate
> On 7. May 2017, at 21:27, Thom L wrote: > > Hi Bastian, > > Le 7 mai 2017 22:10, "Bastian Bloessl" a écrit : > > The red line is the complex component (which is around 0), while the blue > line shows the real part (which jumps between 1 and -1). > > Yes but it jumps at sample rate 20M and not 6M? IEEE 802.11a/g always uses 20MHz channels independent from the modulation and coding scheme. So it will always be a signal with a 20MHz bandwidth. If you encode data with BPSK and a coding rate of 1/2, the 20MHz signal will carry 6Mbit/s (bits per second, not bandwidth in frequency domain). > What I would is to see the bit rate If you want to visualize the data throughput, I would recommend to parse the Wireshark output and calculate a moving average. But you won’t see the 6 MBit/s. It’s only the PHY throughput, which you could only reach if you sent a single frame with infinite size. Best, Bastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Major OpenCL Updates
Hi Anon. I set it up for 1.2. The biggest gotcha I've run into in the build process is missing the cl.hpp file, but how to get it can vary by OS. There's some setup notes in the setup_help directory for debian and Ubuntu that may help you out. What OS are you running it on? On Sun, May 7, 2017 at 4:35 PM, Anon Lister wrote: > Neat. What opencl implementation are you building against? > > I get errors related to _svm_ parts of code. I.e. > cl_device_svm_capabilities was not declared in this scope. Trying to use > the Nvidia cuda sdk, just downloaded from their developer site (ver 8.0). > > > > On May 6, 2017 8:59 AM, "Ghost Op" wrote: > >> Hi everyone. A number of you have asked me to keep you informed of >> any major updates on the OpenCL gr-clenabled project and the past >> couple of weeks have been pretty active. There's now a version up in >> the repo with a significant number of updates and all blocks have been >> validated (at least in their basic modes). >> >> So here's the major updates: >> >> Validation flowgraphs - Almost all test flowgraphs have been posted in >> the examples directory. You can run the comparisons on your own >> hardware for comparison. This is important on older cards that don't >> support double precision (you can check with the included clview >> command-line tool). >> >> Signal Source Block - A discrepancy in the output was due to an >> OpenCL issue. Turns out single/float precision wasn't producing >> accurate enough numbers. This block now uses double precision if the >> hardware supports it (most new hardware will) for an even cleaner >> signal than the native block (no secondary nodes). >> >> Quad Demod - Same single/double trig discrepancy due to precision >> which was corrected. >> >> Filters - A lot of work this week has been spent on filter validation >> (hence the few emails about TD vs. FD from yesterday) >> - Both FIR and FFT implementations are now implemented and >> producing correct output >> - A generic tap-based block was added for more flexibility >> - A test-clfilter command-line tool was added to test performance >> given a number of taps across OpenCL FIR, GNURadio FIR, OpenCL FFT, >> and GNURadio FFT so you can pick the best performing filter given your >> implementation. >> >> Costas Loop - A Costas Loop was added, however the performance on a >> GPU kernel is horrible. Because of the sequential calculations, it >> couldn't be SIMD parallel processed so it was written as an OpenCL >> task-based kernel. This means it just runs single-threaded on a >> single core, which is why the performance is so bad. However if >> anyone has an OpenCL-capable FPGA card like an Altera I'd love to see >> the result of running the included test-clenabled timing tool and see >> how the Costas Loop performs. I just don't have access to one. >> >> Performance - Code was added to detect if the hardware supports Fused >> Multiply/Add functionality for added kernel performance. If it's >> available it's used. >> >> OpenCL Setup Instructions - For those that may not have OpenCL set up, >> I added some installation guides in the setup_help directory for >> Ubuntu and Debian with step-by-steps on getting it up and running. >> I've taken both of those processes on several systems and been up and >> running pretty quickly. I also pulled some of the important points >> into the main page's README, since in my experience that's generally >> all I look through too. >> >> Study - Based on the filter updates, the filter section in the study >> in the docs directory was completely rewritten. The report was noted >> as updated. >> >> I think that's the biggest updates for now. As always let me know if >> anyone runs into any issues. >> >> ___ >> 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] Major OpenCL Updates
Neat. What opencl implementation are you building against? I get errors related to _svm_ parts of code. I.e. cl_device_svm_capabilities was not declared in this scope. Trying to use the Nvidia cuda sdk, just downloaded from their developer site (ver 8.0). On May 6, 2017 8:59 AM, "Ghost Op" wrote: > Hi everyone. A number of you have asked me to keep you informed of > any major updates on the OpenCL gr-clenabled project and the past > couple of weeks have been pretty active. There's now a version up in > the repo with a significant number of updates and all blocks have been > validated (at least in their basic modes). > > So here's the major updates: > > Validation flowgraphs - Almost all test flowgraphs have been posted in > the examples directory. You can run the comparisons on your own > hardware for comparison. This is important on older cards that don't > support double precision (you can check with the included clview > command-line tool). > > Signal Source Block - A discrepancy in the output was due to an > OpenCL issue. Turns out single/float precision wasn't producing > accurate enough numbers. This block now uses double precision if the > hardware supports it (most new hardware will) for an even cleaner > signal than the native block (no secondary nodes). > > Quad Demod - Same single/double trig discrepancy due to precision > which was corrected. > > Filters - A lot of work this week has been spent on filter validation > (hence the few emails about TD vs. FD from yesterday) > - Both FIR and FFT implementations are now implemented and > producing correct output > - A generic tap-based block was added for more flexibility > - A test-clfilter command-line tool was added to test performance > given a number of taps across OpenCL FIR, GNURadio FIR, OpenCL FFT, > and GNURadio FFT so you can pick the best performing filter given your > implementation. > > Costas Loop - A Costas Loop was added, however the performance on a > GPU kernel is horrible. Because of the sequential calculations, it > couldn't be SIMD parallel processed so it was written as an OpenCL > task-based kernel. This means it just runs single-threaded on a > single core, which is why the performance is so bad. However if > anyone has an OpenCL-capable FPGA card like an Altera I'd love to see > the result of running the included test-clenabled timing tool and see > how the Costas Loop performs. I just don't have access to one. > > Performance - Code was added to detect if the hardware supports Fused > Multiply/Add functionality for added kernel performance. If it's > available it's used. > > OpenCL Setup Instructions - For those that may not have OpenCL set up, > I added some installation guides in the setup_help directory for > Ubuntu and Debian with step-by-steps on getting it up and running. > I've taken both of those processes on several systems and been up and > running pretty quickly. I also pulled some of the important points > into the main page's README, since in my experience that's generally > all I look through too. > > Study - Based on the filter updates, the filter section in the study > in the docs directory was completely rewritten. The report was noted > as updated. > > I think that's the biggest updates for now. As always let me know if > anyone runs into any issues. > > ___ > 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] gr-ieee802-11 wifi signal bitrate
Hi Bastian, Le 7 mai 2017 22:10, "Bastian Bloessl" a écrit : The red line is the complex component (which is around 0), while the blue line shows the real part (which jumps between 1 and -1). Yes but it jumps at sample rate 20M and not 6M? What I would is to see the bit rate Thank you for your help Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-ieee802-11 wifi signal bitrate
Hi Thomas, > On 7. May 2017, at 09:21, Thom L wrote: > I added a time block sink and watched the signal in 6M mode (sampling rate is > 20M) but I can not interpret the result (cf attachment). Well I do not have > to look at the right place or the right way .. I’m not sure what you are trying to visualise, but the equalizer outputs the data subcarriers. In the picture it shows BPSK, where the constellation points are around (-1, 0) and (1,0). The time domain plot interprets the subcarriers as time series and visualises real and imaginary parts in a line plot. The red line is the complex component (which is around 0), while the blue line shows the real part (which jumps between 1 and -1). > In fact I can not quite understand the graph in the time domain which is by > default in the module gr-ieee811 (magnitude) IIRC, it shows the autocorrelation of the signal. If you add a trigger to the default plot (level ~0.56) you should see the characteristic plateau of the short training sequence at the beginning of frames (this is used for frame detection). Best, Bastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] crash when placing osmocom source + osmocon sink
Using Opensuse 42.2 Gnuradio from repository home:dl8fcl:branches:hamradio i | gnuradio | package| 3.7.11-10.2 | x86_64 | home:dl8fcl:branches:hamradio I have tried it with repository hamradio and it failed too. When I place both blocks on a diagram (I can even play the diagram), GRC crash. When I open it again this is the log: fernando@andromeda:~> gnuradio-companion Warning: restarting the docstring loader (crashed while loading 'osmosdr_sink') Warning: restarting the docstring loader (crashed while loading 'osmosdr_source') /usr/lib64/python2.7/site-packages/gnuradio/grc/gui/BlockTreeWindow.py:102: GtkWarning: Theme directory base/ of theme oxygen has no size field self.search_entry.set_icon_from_stock(gtk.ENTRY_ICON_PRIMARY, gtk.STOCK_FIND) <<< Welcome to GNU Radio Companion 3.7.11 >>> Block paths: /home/fernando/.grc_gnuradio /usr/share/gnuradio/grc/blocks Warning: restarting the docstring loader (crashed while loading 'uhd_amsg_source') Warning: restarting the docstring loader (crashed while loading 'uhd_usrp_sink') Warning: restarting the docstring loader (crashed while loading 'uhd_usrp_source') Warning: docstring loader crashed too often Any help? regards ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio bugtracker
Vladimir, The bug tracker was recently moved to github, so head to http://github.com/GNURadio/GNURadio to find the issues/bug tracker. Geof On Sun, May 7, 2017 at 07:19 Владимир Мартьянов wrote: > Hello, I'm new in gnuradio and maybe don't know some obvious things... But > where is a bugtracker? I found a link > https://gnuradio.org/redmine/projects/gnuradio/issues in the FAQ, but it > redirected me to the https://gnuradio.org and it's strange, I think ;-) > ___ > 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] gnuradio bugtracker
Hello, I'm new in gnuradio and maybe don't know some obvious things... But where is a bugtracker? I found a link https://gnuradio.org/redmine/projects/gnuradio/issues in the FAQ, but it redirected me to the https://gnuradio.org and it's strange, I think ;-) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
