Re: [Discuss-gnuradio] [USRP-users] How to stop "usrp_spectrum_sense.py"?

[Martin Braun]

On 04/07/2014 04:51 AM, Syed Aqeel Raza wrote:
> Hi Martin,
> 
> Good Day !!!
> 
> I somehow able to run the program and it successfully switches in
> between of relay mode to sensing mode with respect to the mentioned time
> frame. However, the program terminates by its own after switching two
> times from relay mode to sensing mode and vice versa. I have been
> encountered with the following error message: 
> 
> "RuntimeError: boost::thread_resource_error: Resource temporarily
> unavailable"
> 
> For detailed information about this error message, see the attached
> file. Waiting for your reply, thanks.

Syed,

at this point, it's impossible to help you any further without seeing
the code. Also, you would probably get more responses on the GNU Radio
mailing list, which I've added.

Another note: It's usually better to post the error message (if short,
in an email, if long, on a pasting service such as pastebin) than to
post a screenshot.

Martin


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Occasional choppiness/underruns (aUaU) with FCDPP->GRC->Pulse

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Chuck,
really in a hurry now, but I can't let you down, sooo:

On 08.04.2014 06:22, Chuck Ritola wrote:
> There doesn't seem to be a system in place in gmail/mailman for
> replying to a list digest entry. Hope this works...
> 
> Switching from 'pulse' to 'sysdefault' or leaving it blank appears
> to fix the issue
This kind of says don't use pulseaudio :) at least for this application
> but breaks pulseaudio and everything running on it by kicking it 
> off of sysdefault. ALSA cannot allow multiple applications to use
> the same output, which is what gave rise to pulseaudio.
Not really. dmix has been around for a long time now, which is ALSA's
method of mixing multiple streams. Basically, you should be able to
dmix GNU Radio's output and pulse's output.
The question here is whether mixing using DMIX is really more
efficient than using pulse. My wild guess here is that, yes, it is.

Pulseaudio is the default soundserver for gnome-ish desktop
environments -- it was meant to relieve application designers of the
task of coping with different audio hardware, mixing, remote audio etc
and giving programs a unified control interface. It is very much
designed to be easy to use and good for applications that want to
output a "chime" once in a while or "just want to play that MP3, and
not worry"; I don't think it was designed for high-rate continuous
streams...

> My understanding is that ALSA is deprecated to just being a driver
> interface or for very intensive streams (like USRP) and that direct
> ALSA access is discouraged since it disables all other applications
> from sharing the audio I/O.
s.a.

> 
> This affects me because I use a lot of tools to analyze and record
> the monitored signals demodulated by GRC, such as gMFSK through
> padsp, parec, I need notification sounds, and Audacity.
I think at least for parec there should be a workaround using alsa
loopback and any recording program, or even just monitoring the output
stream.
Then again, you can just write your GNU Radio output to a wav file
whilst simultaneously outputting it to alsa/pulse; maybe that is what
you need?

> Furthermore, firefox is open when using GRC with sysdefault as its
> output,
sounds like dmix can fix that
> flash is broken
I just leave this here. Flash has always been broken -- do you
*really* need flash on the PC you're doing signal processing on?
> since it uses pulse and remains broken until the browser is
> restarted without GRC running. Replacements and rearrangements to
> work around this problem are nontrivial. Pulse gives good facility
> to route things around. Giving any application direct access to the
> ALSA output monitoring device (sysdefault) instead of pulseaudio's
> virtual outputs breaks everything but GRC.
Ok, to be completely frank here:
It looks like your computer is not up to the task of mixing pulse
streams while simultaneously doing signal processing and watching
Flash movies. Or maybe this is an irregularity in pulse, or pulse
starts to internally resample other streams from 44.1kHz to 48 or very
many other things...
I'd say: try using dmix, if you really need to mix your GNU Radio
output and your system sounds.

> 
> I am using a Phenom II X3 running at ~2.8GHz. 4GB ram.
> 
> Under normal circumstances the overhead of pulseaudio is very low.
> Using a graph to reproduce the issue consumes about 10% of one core
> using sysdefault (direct to ALSA) in the output block, and when
> using 'pulse' in the output block, the same 10% of one core. In all
> cases, the FCDPP is accessed directly as hw:3 because using pulse
> and routing it doesn't work - it just gives silence and "aUaUaU".

Seems like pulse is simply just not up to the task on your PC.

> The flutters are apparently coming from the connection between
> pulse and GRC being reset rapidly over and over again. It should
> not be resetting this much. This is causing the big CPU spike and
> continued fluttering. I do not know if this is a GRC issue or pulse
> issue, but all of my applications but one (noted below) have never
> had any issues of this nature. I can even play MP3s from exaile
> which sound fine while GRC continues to flutter in the background.
> 
> The exception was gMFSK through padsp, the waterfall plot shows
> occasional signs of the same fluttering when pulseaudio routes GRC
> to gMFSK's input, it would scroll 2-3x faster with gaps, even when
> GRC->pulse was sounding fine at the moment. When that occurs,
> pulseaudio's CPU usage spikes to the 90% range of a core.
This really looks like a pulse issue to me.

Greetings,
Marcus

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTQ7Z4AAoJEBQ6EdjyzlHtZJQH/i01+5DWvLQoWBs42N8VfB+l
a0c5coGNXQMdCdb7ElCrGHxknW3wRKEHR7+kEbYHcVl1pYY7FgS75+YT2PNkUDAQ
FmVOjkeCRHFWOrgIjaKApPHGvIBtmCDf9SVACXNSi0npU2UOu9oTFNRF/o2xSF7k
Ra9PmZCFzZ+Y+6O5SIgjYH6iCC67RffyPmPyvMiGIv7r9WFXguP0e6xTjb3Bipw5

[Discuss-gnuradio] Smith Chart in GNU Radio

[MITUL VEKARIYA]

Hi

I am trying to figure out how to use smith chart as a sink in GNU Radio.
I made an OOT (https://github.com/mitul93/gr-smithchart) using pyQT by
following Tim O'shea's work.
It is merely a skeleton, still lots of work to do.

I made two versions of smith chart - one using pyQT and another using
matplotlib (ploar plot).
After executing example_smithsink_numpy.py when I close the graph, the
program won't stop. I tried to write an close_event() for the graph, but it
didn't work. Is it happening due to the fact I am using it with GNU Radio?

To display data point on graph, shall I use message passing or simple
vector input?

Also please give me your feedback about expected function that I must
implement in smith chart.

Thanks
Mitul Vekariya
Institute of Technology
Nirma University
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Occasional choppiness/underruns (aUaU) with FCDPP->GRC->Pulse

[Martin Braun]

On 04/08/2014 10:42 AM, Marcus Müller wrote:
> [...]
> Ok, to be completely frank here:
> It looks like your computer is not up to the task of mixing pulse
> streams while simultaneously doing signal processing and watching
> Flash movies. Or maybe this is an irregularity in pulse, or pulse
> starts to internally resample other streams from 44.1kHz to 48 or very
> many other things...
> I'd say: try using dmix, if you really need to mix your GNU Radio
> output and your system sounds.
> 
> [...]
>> I am using a Phenom II X3 running at ~2.8GHz. 4GB ram.
> 
>> Under normal circumstances the overhead of pulseaudio is very low.
>> Using a graph to reproduce the issue consumes about 10% of one core
>> using sysdefault (direct to ALSA) in the output block, and when
>> using 'pulse' in the output block, the same 10% of one core. In all
>> cases, the FCDPP is accessed directly as hw:3 because using pulse
>> and routing it doesn't work - it just gives silence and "aUaUaU".
> 
> Seems like pulse is simply just not up to the task on your PC.

Hm, I don't really think Pulse is the issue. "High rate audio streams"
don't really exist (what is 48 kHz compared to our radio stuff)?

Chuck, I know you say it's not a two-clock problem, but I'm not
convinced, despite your great problem description. It takes little
difference to cause lots of underruns. One way you can figure that out
is by resampling a bit above the audio rate (say, 48100 or 48200 Hz) and
piping that into a Pulse that expects 48000 Hz. If you get less Us
(maybe some Os), that's the problem.

Martin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Problem with getting clear FM signals using the usrp e110

[Abouda Yassine]

Hello,
I followed this tutorial to build a simple FM receiver:
https://www.youtube.com/watch?v=KWeY2yqwVA0.I am using the USRP e110,my
problem is I am only getting noise.I tried to change blocks and parameters
and it worked for me when I deleted the rational resampler and made a 100k
as a sample_rate parameter.I get to hear FM radio stations but the quality
of the sound is very bad it's like on the SAW movie.Any one has a solution
on how to improve the sound qualitythx
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-air-modes broken in recent update ?

[M Dammer]

I tried rebuilding gr-air-modes with make -j1 both for build and
install, but it did no help. I even changed the generic makewidth
setting to 1 and rebuilt gnuradio, rtl_sdr..., but the problem is still
there.

Mark

On 07/04/14 22:19, Johnathan Corgan wrote:
> On 04/08/2014 01:41 AM, M Dammer wrote:
>>File
>> "/home/mark/apps/gnuradio/3.7/lib/python2.7/dist-packages/air_modes/air_modes_swig.py",
>>
>> line 22, in swig_import_helper
>>  _mod = imp.load_module('_air_modes_swig', fp, pathname,
>> description)
>> ImportError: dynamic module does not define init function
>> (init_air_modes_swig)
>
> The "does not define init function" is almost certainly a parallel
> make failure.  To fix, you go into the build directory, do a 'make
> clean', then a single process 'make'.
>
> I thought that the PyBOMBS recipe for gr-air-modes had an override to
> always use -j1 when compiling.
>
> Johnathan




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] BER and OFDM

[MegaDuzera]

I already tried the new blocks

The BER results are wrong, it gives me a value of "0.0 Units" always 



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/BER-and-OFDM-tp47428p47449.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] gr-air-modes broken in recent update ?

[Sylvain Munaut]

Hi,

>> "/home/mark/apps/gnuradio/3.7/lib/python2.7/dist-packages/air_modes/air_modes_swig.py",
>> line 22, in swig_import_helper
>>  _mod = imp.load_module('_air_modes_swig', fp, pathname, description)
>> ImportError: dynamic module does not define init function
>> (init_air_modes_swig)
>
>
> The "does not define init function" is almost certainly a parallel make
> failure.  To fix, you go into the build directory, do a 'make clean', then a
> single process 'make'.

This error is also typical of having linked against the python 2.7
binaries but the python 3.x libs ...

There was a fix for GR to avoid this and only ever pick 2.7 but all
OOT haven't picked up that fix.

Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Using GRC without UHD

[Ruecan]

Hello GR,

Are there any fake sink and source blocks which simulates the uhd sink and
source.
I would like to test some flow graphs but for the moment I don't have access
to the radios.

Or is there any other option, let's say using a channel block between the Tx
and the Rx.

Any hints or explanation are well appreciated.

Regards,
Ruecan



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Using-GRC-without-UHD-tp47451.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] Using GRC without UHD

[Martin Braun]

On 04/08/2014 05:36 PM, Ruecan wrote:
> Hello GR,
> 
> Are there any fake sink and source blocks which simulates the uhd sink and
> source.
> I would like to test some flow graphs but for the moment I don't have access
> to the radios.
> 
> Or is there any other option, let's say using a channel block between the Tx
> and the Rx.
> 
> Any hints or explanation are well appreciated.

You can use file sinks- and sources. There's also several different
channel blocks.

Martin


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Using GRC without UHD

[Tom Rondeau]

On Tue, Apr 8, 2014 at 11:48 AM, Ruecan  wrote:

> Thank you Martin,
>
> Does the file sink and source blocks work in case of a stream of packets
> (802.15.4).
>
> Ruecan
>

Ruecan,

http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-is-the-file-format-of-a-gr_file_sink-How-can-I-read-files-produced-by-a-file-sink


In GRC, look under Channel Models for the available models we have in the
code.

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Using GRC without UHD

[Ruecan]

Thanks.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Using-GRC-without-UHD-tp47451p47455.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] Latest Hackfest (discussion on trellis and RA codes)

[Achilleas Anastasopoulos]

Miklos and Tom,

one option may be to merge the work that Miklos described with gr-trellis
(or the other way around :-))
Recall there was a discussion in the recent past of volk-ing the basic
trellis algorithms such as VA and SISO.
I believe the work that Miklos describes would be a wonderful way to start.

Also, Miklos, some of the functionality you are describing (interleaving,
generation of codes, FSM structure, etc) is in gr-trellis.
In the spirit of not duplicating efforts, would you consider a joint effort
to refactor as much as possible into one module/API?

best
Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Using GRC without UHD

[Ed Criscuolo]

Connect up a null sink and null source in parallel with the uhd blocks. Then 
right- mouse on the uhd blocks and select "disable".  This will gray-out the 
blocks and not compile them, but will leave them there preserving all your 
parameters.

@(^.^)@  Ed

Sent from my iPod

On Apr 8, 2014, at 11:36 AM, Ruecan  wrote:

> Hello GR,
> 
> Are there any fake sink and source blocks which simulates the uhd sink and
> source.
> I would like to test some flow graphs but for the moment I don't have access
> to the radios.
> 
> Or is there any other option, let's say using a channel block between the Tx
> and the Rx.
> 
> Any hints or explanation are well appreciated.
> 
> Regards,
> Ruecan
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Using-GRC-without-UHD-tp47451.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Tips for improving file transfer data loss

[Ken Adams]

I'm looking for some tips on how to improve file transfer using two USRP's.
I understand the method I'm using might be fairly crude, but I'm just
starting out.

Problem is I'm dropping a lot of data out of the file (receiving missing
parts of a string and such). This gets really bad when one of the USRP's is
moving.

File Source > Packet Encoder > GMSK Mod > USRPB100 Sink

USRP B100 Source > Xlating FIR Filter (LP 100khz) > GMSK Demod > Packet
Decoder > File Sink.

I want to try and add some FEC, however, the only FEC blocks that ship with
GNURadio say "This package is for continuous data, not packetized". Any FEC
tips would be nice.

Is there anything wrong/bad with this flow graph for sending files? Or
perhaps a better solution? I understand there could be a heap of problems
not relating to GNURadio, but I'm sending the files in the middle of a very
large (>1mile square) open field , with good line of sight.

Cheers,

Ken
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] FSK Demodulation trouble

[Jay Radcliffe]

Hello All,

I am working on learning gnuradio and getting a grip on demodulating
digital communications.  I've been a ham for a long time, and this seems
far from my days as a kid running 1200 baud half duplex AFSK.  ;)

What I have is a toy with a cc1101 chip in it that transmits @ 19.2 k baud,
2-FSK, 16.5 khz deviation. The sync word is the default 0xD3 0x91.   Here
is a link to the capture file I am working with:
https://dl.dropboxusercontent.com/u/37979208/ping_903.020m_0.400m_20140403_00z_rtlsdr.cfile

I started out by trying to get Jared Boone's TPMS code to work,
https://github.com/jboone/tpms but it doesn't like me or my system at all.
(Ubuntu 12.04, gnuradio built with the build-gnuradio script).  I really
like his reverse engineering methods that he talked about in the talk he
gave at toorcon.  I also like the ability to analyse the captures offline
with a CLI interface.

When I have worked with the GRC, I run the file source through a throttle,
then through the quadrature demod block, then to a Scope Sink to try and
see the bits on the scope.  I am a little lost on a couple things: 1. I
know i need to provide some information about the signal (data rate,
deviation, offset) but I don't see any place to add those values.  2. Can I
use the squelch block to limit the demodulation to only look at signals
above a certain signal strength?

Ideally, I would love to get a GRC or script that worked on the capture
file, then I can have a good example to learn from.  Most of the posts I
see from googleing show really incomplete work, or just the final product,
without explanation of how to get there (the dreaded "self-documenting
code").

Any help would be greatly appreciated.  beer is on me if I see you at a
conference or swap.

73

Jay n8os


Jay Radcliffe
Twitter: @jradcliffe02
E-Mail: 
jay.radcli...@gmail.com
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Arch Linux WXGUI Support (GNR3.7)

[Jordan Johnson]

There has been an issue for some months now in the latest build of gnuradio
from the AUR. It does not build, nor can run the WX/QT GUI modules. I have
had to downgrade some packages to make an older version of GNR work. I need
the instrumentation tools for testing things and cannot work without them
in some applications.

Has anyone come up with a parch or workaround?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Arch Linux WXGUI Support (GNR3.7)

[Tom Rondeau]

On Tue, Apr 8, 2014 at 6:44 PM, Jordan Johnson wrote:

> There has been an issue for some months now in the latest build of
> gnuradio from the AUR. It does not build, nor can run the WX/QT GUI
> modules. I have had to downgrade some packages to make an older version of
> GNR work. I need the instrumentation tools for testing things and cannot
> work without them in some applications.
>
> Has anyone come up with a parch or workaround?
>


Hi Jordan,

Can you be more specific in the versions and problems you're talking about?
Downgraded from what to what? When you can't build, what kinds of errors
are you running into? What's the problems that you wee with WX/QT GUI?

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Arch Linux WXGUI Support (GNR3.7)

[Jordan Johnson]

Attempted building and running it. Got this.

(top_block.py:16685): Gtk-WARNING **: Unable to locate theme engine in
module_path: "murrine",
Using Volk machine: avx_64_mmx_orc
Traceback (most recent call last):
  File "/home/ushio/top_block.py", line 77, in 
tb = top_block()
  File "/home/ushio/top_block.py", line 46, in __init__
peak_hold=False,
  File "/usr/lib/python2.7/site-packages/gnuradio/wxgui/fftsink_nongl.py",
line 198, in __init__
self.win = fft_window(self, parent, size=size)
  File "/usr/lib/python2.7/site-packages/gnuradio/wxgui/fftsink_nongl.py",
line 331, in __init__
self.control_panel = control_panel(self)
  File "/usr/lib/python2.7/site-packages/gnuradio/wxgui/fftsink_nongl.py",
line 256, in __init__
wx.Panel.__init__(self, parent, -1, style=wx.SIMPLE_BORDER)
  File "/usr/lib/python2.7/site-packages/wx-3.0-gtk2/wx/_windows.py", line
68, in __init__
_windows_.Panel_swiginit(self,_windows_.new_Panel(*args, **kwargs))
wx._core.PyAssertionError: C++ assertion "m_window" failed at
./src/gtk/dcclient.cpp(2041) in DoGetSize(): GetSize() doesn't work without
window


On Tue, Apr 8, 2014 at 4:02 PM, Tom Rondeau  wrote:

> On Tue, Apr 8, 2014 at 6:44 PM, Jordan Johnson wrote:
>
>> There has been an issue for some months now in the latest build of
>> gnuradio from the AUR. It does not build, nor can run the WX/QT GUI
>> modules. I have had to downgrade some packages to make an older version of
>> GNR work. I need the instrumentation tools for testing things and cannot
>> work without them in some applications.
>>
>> Has anyone come up with a parch or workaround?
>>
>
>
> Hi Jordan,
>
> Can you be more specific in the versions and problems you're talking
> about? Downgraded from what to what? When you can't build, what kinds of
> errors are you running into? What's the problems that you wee with WX/QT
> GUI?
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Smith Chart in GNU Radio

[MITUL VEKARIYA]

Hello

Problem solved. I removed the QApplication() from the example. Matplotlib
was used for plotting, no need of qApp!!

Thanks
Mitul Vekariya


On Tue, Apr 8, 2014 at 2:22 PM, MITUL VEKARIYA <10bec...@nirmauni.ac.in>wrote:

> Hi
>
> I am trying to figure out how to use smith chart as a sink in GNU Radio.
> I made an OOT (https://github.com/mitul93/gr-smithchart) using pyQT by
> following Tim O'shea's work.
> It is merely a skeleton, still lots of work to do.
>
> I made two versions of smith chart - one using pyQT and another using
> matplotlib (ploar plot).
> After executing example_smithsink_numpy.py when I close the graph, the
> program won't stop. I tried to write an close_event() for the graph, but it
> didn't work. Is it happening due to the fact I am using it with GNU Radio?
>
> To display data point on graph, shall I use message passing or simple
> vector input?
>
> Also please give me your feedback about expected function that I must
> implement in smith chart.
>
> Thanks
> Mitul Vekariya
> Institute of Technology
> Nirma University
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] BER and OFDM

[bsivakumar]

Dear user,
  I think this is not the way to implement OFDM simulation. It requires
multiply const block before channel model. You may get variation in BER
value when you use USRP boards.  I will execute the same flow-graph and let
me inform you results in soon.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/BER-and-OFDM-tp47428p47464.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