[Discuss-gnuradio] OFDM frame detection

[farid mihoub]

Hello, In the OFDM examples in gr-digital, for the packet detection blocks (Schmidt and Cox, Freq Mod and Delay), how to better choose the parameters  for different FFT lengths. the problem I have to figure out that manually.   Thank you. 

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

[Discuss-gnuradio] OFDM with continuous pilots but bursty data

[Achilleas Anastasopoulos]

Hi Alex,

you may want to take a look at the OOT module gr-cdma (
https://github.com/anastas/gr-cdma).
This system implements a two-channel system with one of the orthogonal
channels being continuously transmitting pilots,
while the other carries data (in a synchronous/asynchronous way).
The Rx is always listening to the pilot channel and is continuously
adjusting frequency/timing.

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

Re: [Discuss-gnuradio] OFDM with continuous pilots but bursty data

[Michael Dickens]

Hi Alex - The default OFDM Rx is fully asynchronous: It tries to detect the 
packet preamble on a packet by packet basis only, without using any knowledge 
of historical successful packet detection. I don't think GR provides a 
synchronous receiver, and I don't know of one in any GR out of tree (OOT) 
module ... but I don't know everything so maybe there is one & if so hopefully 
others will chime in to tell us! Hope this is useful! - MLD

On Tue, Aug 13, 2019, at 1:04 PM, Alex Roberts wrote:
> I'm playing around with an OFDM transmit/receive chain. I've noticed that if 
> I get underruns at a high enough rate, it becomes a bursty system and the 
> receiver is unable to lock in and no longer demodulates the symbols. 
> 
> Would it be possible to generate continuous pilot tones or send OFDM frames 
> with just preambles and padded data such that even if the source data stream 
> underruns, the output is continous rather than bursty so that the receiver 
> can keep lock with time and frequency offests?
> 
> -Alex
> ___
> 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 with continuous pilots but bursty data

[Alex Roberts]

I'm playing around with an OFDM transmit/receive chain. I've noticed that
if I get underruns at a high enough rate, it becomes a bursty system and
the receiver is unable to lock in and no longer demodulates the symbols.

Would it be possible to generate continuous pilot tones or send OFDM frames
with just preambles and padded data such that even if the source data
stream underruns, the output is continous rather than bursty so that the
receiver can keep lock with time and frequency offests?

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

Re: [Discuss-gnuradio] OFDM Mod Block - how is it working?

[rear1019]

On Tue, 09 Jul 2019 at 17:42:11 +0200, lilijobo1 lilijobo1 wrote:
> The thing is that I dont really get how the parameters 
> occupied tones and the FFT length work in that case. 
> Is the occupied tones equal to the numer of subcarriers? If yes where do get 
> to know the subcarrier spacing because if Im right this is different for 
> LTE or 802.11a .
>
> And what about the parameter FFT length?

Occupied tones determines the number of used (occupied) carriers, i.e.
the number of carriers which contain data and pilots. The number of
carriers which can be used at most is determined by the FFT length.

Carrier spacing Δf_c is determined by Δf_c = 1/T_s where T_s is the
length of the OFDM symbol (cyclic prefix not included). Assuming a
sampling rate of f_s you get Δf_c = 1/(N·(1/f_s)) = f_s/N where N is the
required length of the FFT.

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

[Discuss-gnuradio] OFDM Mod Block - how is it working?

[lilijobo1 lilijobo1]

Hi,

 

I'm working with grc and a LimeSDR board and saw that there is the "OFDM Mod" Block available that I thought I could use to generate a broadband signal that is similar to a channel in LTE.

In detail I want to generate a signal with a known bandwidth like 5MHz  and analyze how the LimeSDR works with that for different frequencies and gains. Therefore I just took a random source the OFDM Mod block and the Limesuite sink ( Gr-limesdr Plugin from Myriad) to generate such a signal. 

The thing is that I don't really get how the parameters "occupied tones" and the "FFT length" work in that case. Is the occupied tones equal to the numer of subcarriers? If yes where do get to know the subcarrier spacing because if I'm right this is different for LTE or 802.11a .

And what about the parameter "FFT length"?

I would appreciate any help or suggestions.

 

Thank you in advance

 

Greetings

Johannes

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

Re: [Discuss-gnuradio] OFDM

[Michael Dickens]

Hi Farid - I'll reply off list since this is pretty technical; we can summarize 
back on list if appropriate. - MLD

On Sat, Jun 8, 2019, at 1:19 PM, farid mihoub wrote:
> Hello,
> I am trying to change the OFDM_tx_rx payload modulation by a custom 64kQAM,
> I implemented the block in several ways, it works fine but I had issues using 
> it with OFDM_tx_rx:
> /*1- sync:
> taking a short item and produce a complex item
> modulation:
> **signatures:***
> 64kQAM_code_impl::64kQAM_code_impl( )
>  : gr::sync_block("64kQAM_code",
>  gr::io_signature::make(1, 1, sizeof(unsigned short int)),
>  gr::io_signature::make(1, 1, sizeof(gr_complex)))
>  {}
> **work function:***
> int
>  64kQAM_code_impl::work(int noutput_items,
>  gr_vector_const_void_star _items,
>  gr_vector_void_star _items)
>  {
>  const unsigned short int *in = (const unsigned short int *) input_items[0];
>  gr_complex *out = (gr_complex *) output_items[0];
>  for(int i = 0;i   out[i].real((float(in[i]&0x00FF)-128.0)*level);
>  out[i].imag((float((in[i]&0xFF00)>>8)-128.0)*level);
>  }
>  return noutput_items;
>  }
> demodulation:
> taking a complex item and produce a short item
> **signature:***
>  64kQAM_decode_impl::64kQAM_decode_impl( )
>  : gr::sync_block("64kQAM_decode",
>  gr::io_signature::make(1, 1, sizeof(gr_complex)),
>  gr::io_signature::make(1, 1, sizeof(unsigned short int)))
>  {}
> **work function:***
>  int
>  64kQAM_decode_impl::work(int noutput_items,
>  gr_vector_const_void_star _items,
>  gr_vector_void_star _items)
>  {
>  const gr_complex *in = (const gr_complex *) input_items[0];
>  unsigned short int *out = (unsigned short int *) output_items[0];
>  unsigned short int tmp;
>  for(int i =0; i   { 
>  tmp = int((in[i].imag()/level)+128.5);
>  tmp = (tmp<<8) | int((in[i].real()/level)+128.5);
>  out[i] = tmp;
>  }
>  return noutput_items;
>  }
>  Problem: -I got the write samples in the QT time sink, and in the
>  file sink, but the transmission stops after some amount
>  of data has been transmitted (repeat set to yes), the
>  packet_len tag is displayed
> 
> /*2- interpolator/decimator:***
> modulation: 
> takes 2 bytes and produce one complex item
> demodulation:
> takes one complex item and produce 2 bytes.
> my decimaition and interpolation factor is 2
>  Problems: same as 1.
> 
> /**2-general:**
> modulation:
> taking two byte items and produce a complex item
>  void
>  64kQAM_code_impl::forecast (int noutput_items, gr_vector_int 
> _items_required)
>  {
>  ninput_items_required[0] = noutput_items*2;
>  }
> 
>  int
>  64kQAM_code_impl::general_work (int noutput_items,
>  gr_vector_int _items,
>  gr_vector_const_void_star _items,
>  gr_vector_void_star _items)
>  {
>  const unsigned char *in = (const unsigned char*) input_items[0];
>  gr_complex *out = (gr_complex *) output_items[0];
> 
>  for(int i = 0;i   {
>  out[i].real(in[2*i]*level);
>  out[i].imag(in[2*i+1]*level);
>  }
>  consume_each (noutput_items);
> 
>  // Tell runtime system how many output items we produced.
>  return noutput_items;
>  }
> demodulation:
>  void
>  64kQAM_decode::forecast (int noutput_items, gr_vector_int 
> _items_required)
>  {
>  ninput_items_required[0] = noutput_items/2;
>  }
> 
>  int
>  64kQAM_decode_impl::general_work (int noutput_items,
>  gr_vector_int _items,
>  gr_vector_const_void_star _items,
>  gr_vector_void_star _items)
>  {
> 
>  const gr_complex *in = (const gr_complex *) input_items[0];
>  unsigned char *out = (unsigned char *) output_items[0];
> 
> 
>  for(int i =0; i   { 
>  out[2*i]=in[i].real()/level;
>  out[2*i+1] =in[i].imag()/level;
>  }
>  consume_each (noutput_items);
> 
>  // Tell runtime system how many output items we produced.
>  return noutput_items*2;
>  }
> taking a complex item and produce two byte items
> 
>  problem: -It writes quickly a large amount of data to the disk.
>  -In the QT display I get the correct samples but in a sink file
>  I got additionnal data generally this type (^@^@), also packet_len tag
>  is not displayed on the QT time GUI.
> 
> 4-trying with tagged stream block, tagged stream mux block gives an error : " 
> Buffer too small for min_noutput_items"
> 
> Thank you.
> 
> ___
> 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

[farid mihoub]

Hello,I am trying to change the OFDM_tx_rx payload modulation by a custom 64kQAM,I implemented the block in several ways, it works fine but I had issues using it with OFDM_tx_rx:/*1- sync:taking a short item and produce a complex itemmodulation:**signatures:***64kQAM_code_impl::64kQAM_code_impl( )  : gr::sync_block("64kQAM_code",  gr::io_signature::make(1, 1, sizeof(unsigned short int)),  gr::io_signature::make(1, 1, sizeof(gr_complex)))    {}**work function:***int    64kQAM_code_impl::work(int noutput_items,    gr_vector_const_void_star _items,    gr_vector_void_star _items)    { const unsigned short int *in = (const unsigned short int *) input_items[0];  gr_complex *out = (gr_complex *) output_items[0];   for(int i = 0;i   out[i].real((float(in[i]&0x00FF)-128.0)*level);  out[i].imag((float((in[i]&0xFF00)>>8)-128.0)*level);  }  return noutput_items;    }demodulation:taking a complex item and produce a short item**signature:***    64kQAM_decode_impl::64kQAM_decode_impl( )  : gr::sync_block("64kQAM_decode",  gr::io_signature::make(1, 1, sizeof(gr_complex)),  gr::io_signature::make(1, 1, sizeof(unsigned short int)))    {}**work function:***    int    64kQAM_decode_impl::work(int noutput_items,    gr_vector_const_void_star _items,    gr_vector_void_star _items)    {  const gr_complex *in = (const gr_complex *) input_items[0];  unsigned short int *out = (unsigned short int *) output_items[0];  unsigned short int tmp;  for(int  i =0; i  {  tmp = int((in[i].imag()/level)+128.5);    tmp = (tmp<<8) | int((in[i].real()/level)+128.5);    out[i] = tmp;  }  return noutput_items;    }  Problem: -I got the write samples in the QT time sink, and in the file sink, but the transmission stops after some amount of data has been transmitted (repeat set to yes), the packet_len tag is displayed/*2- interpolator/decimator:***modulation:  takes 2 bytes and produce one complex itemdemodulation:takes one complex item and produce 2 bytes.my decimaition and interpolation factor is 2  Problems: same as 1. /**2-general:**modulation:taking two byte items and produce a complex item    void    64kQAM_code_impl::forecast (int noutput_items, gr_vector_int _items_required)    {  ninput_items_required[0] = noutput_items*2;    }    int   64kQAM_code_impl::general_work (int noutput_items,   gr_vector_int _items,   gr_vector_const_void_star _items,   gr_vector_void_star _items)    {  const unsigned char  *in = (const unsigned  char*) input_items[0];  gr_complex *out = (gr_complex *) output_items[0];    for(int i = 0;i     {  out[i].real(in[2*i]*level);  out[i].imag(in[2*i+1]*level);    }  consume_each (noutput_items);  // Tell runtime system how many output items we produced.  return noutput_items;    }demodulation:    void    64kQAM_decode::forecast (int noutput_items, gr_vector_int _items_required)    {  ninput_items_required[0] = noutput_items/2;    }    int    64kQAM_decode_impl::general_work (int noutput_items,   gr_vector_int _items,   gr_vector_const_void_star _items,   gr_vector_void_star _items)    {   const gr_complex *in = (const gr_complex *) input_items[0];  unsigned char *out = (unsigned char *) output_items[0];    for(int  i =0; i     {       out[2*i]=in[i].real()/level;   out[2*i+1] =in[i].imag()/level; }  consume_each (noutput_items);  // Tell runtime system how many output items we produced.  return noutput_items*2;    }taking a complex item and produce two byte items  problem: -It writes quickly a large amount of data to the disk.   -In the QT display I get the correct samples but in a sink file    I got additionnal data generally this type (^@^@), also packet_len tag    is not displayed on the QT time GUI.4-trying with tagged stream block,  tagged stream mux block gives an error : " Buffer too small for min_noutput_items" Thank you. ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OFDM / softcast / rate distortion theory (was:Re: OFDM_TX_RX)

[Marcus Müller]

As said, I doubt that omitting channel coding is a good idea, but OK,
you do the math. 

In any case, when you really don't want channel coding and symbol
mapping, and none of the header structure the OFDM blocks offer, you'll
simply be best off writing your own OFDM transmitter – no big deal,
it's but an IFFT and a cyclic prefix block. That shouldn't take you
very long!

Also, the softcast folks used GNU Radio, so they most definitely have
source code to what they've done – and since MIT takes pride in doing
good science, I'm pretty sure that if you ask, you can get all the code
you need to reproduce.


By the way, they write:

> the receiver with low noise can distinguish
> which of the 16 small squares the original sample
> belongs to, and hence can correctly decode the 4 most
> significant bits of the transmitted sample. The receiver
> with higher noise can distinguish only the quadrant of
> the transmitted signal sample, and hence can decode
> only the two most significant bits of the transmitted
> sample. Thus, wireless broadcast naturally delivers to
> each receiver a number of signal bits that match its SNR.

That's a pretty established method. I think DVB-T does that.

Generally, I'm a bit surprised about the whole "try to contain the
numerical properties from the source video through video coding AND
channel coding" approach, from which they say they get better behaviour
under bit flips:

The very idea of video coding (i.e. source coding) is to maximize the
entropy of each bit. So, if you want to have "least significant bits",
as they argue they can get, not all bits are equally random, i.e.
there's bits that carry more, and bits that carry less information. 
The amount in which this non-equal-distribution of information /
probability happens is called redundancy, and simply means that you
spend more energy per video pixel to get the same error probability.
Sounds counter-productive to me!

Now, the argument of softcast seems to be: 

> Haha! The energy we waste in non-optimal source coding is more than
compensated by the r=1 rate channel code of not doing any channel
coding at all!

That seems strange. If I remember correctly, the whole point is that
joint source-channel coding (which softcast is) can be shown to be
rate-achieving for a *lossless* transmission, but separated source and
channel encoders, in which the source encoder actually maximizes
infobit entropy, and the channel coder minimizes bit error rate, are
superior when it comes to achieving a limited, yet non-zero rate
distortion.
If I was to write a publication about all this, I'd be very sure to
find a paper (I'm certain they cite their theoretical foundations
somewhere – the paper [1] as I could find it really just says "here's
how we're doing it, and that's how much better it is") that explains
how they found a sweet spot where an uncoded transmission achieves
higher info rate under the same distortion as the coded transmission in
an explicitly high-SNR scenario.

Best regards,
Marcus

[1]http://people.csail.mit.edu/szym/softcast/tr2.pdf

On Sat, 2019-05-25 at 19:38 +0100, farid mihoub wrote:
> My application is to broadcast a video using softcast approach. 
> Video-->2DCT_or_3DCT-->Floating coefficients-->complex_mapping
> -->ofdm_phy
> My video quality (PSNR) will depend linearly to my SNR so no need to
> have an adaptive modulation.
> 
> 
> 25.05.2019, 18:27, "Marcus Müller" :
> > 1- So, you have an SNR of best-case 16 dB; that's not high for an
> > OFDM
> > system.
> > 
> > 2- No, there's no power normalization. Hint: you can look all this
> > up
> > by actually looking inside these blocks! This would make a lot of
> > sense, since it sounds you don't actually want to use tzhe OFDM
> > blocks
> > at all. The whole advantage of the OFDM blocks compared to just
> > doing
> > an IFFT of your transmit vector is that you get a header and
> > modulation
> > scheme.
> > 
> > 3- Not quite sure what "information is linearly related to complex
> > symbols" means? Can you elaborate?
> > 3b- A case where you *don't* do FEC is either a non-communications
> > system (i.e. you don't actually want to do OFDM for the reason of
> > transmitting information) or the extremely-bad-SNR case (where FEC
> > makes your BER better). For both cases, the existing OFDM blocks
> > are
> > more of an obstacle than a solution.
> > 
> > What are you building? What is your overall application. Please
> > paint
> > the bigger picture – it's a bit frustrating to try to help you, but
> > then only get told that "this is not how I want to do it".
> > 
> > Best regards,
> > Marcus
> > 
> > On Sat, 2019-05-25 at 18:39 +0200, Marcus Müller wrote:
> > >  Dear Farid,
> > > 
> > >  please always respond on the mailing list.
> > >  Thank you,
> > >  Marcus Müller
> > > 
> > >  On Sat, 2019-05-25 at 17:36 +0100, farid mihoub wrote:
> > >  > 1- For the noise : in the TX side the output is in the order
> > > of 2A,
> > >  > the noise 0.05A.
> > >  > 2-Second even without 

Re: [Discuss-gnuradio] OFDM cyclic prefix

[Ron Economos]

It's telling you there's a mismatch in the vector size (based on the FFT 
length) between the FFT block and the Cyclic Prefixer block. It appears 
you have the FFT block set to 512/8 = 64 and the Cyclic Prefixer block 
set to 8/8 = 1.


Unless you're just writing this block as an exercise, if you set the 
rolloff to 0 in the built-in Cyclic Prefixer block, the rolloff is 
disabled completely.


Ron

On 4/13/19 14:27, Simran Kaur wrote:

Hi Team,
I am trying to make own cyclic prefix block in C++ in GNU 
Radio(removing roll-off part and keeping all other parameters same). 
After connecting my cyclic_prefix block to the already present FFT 
block in tx_ofdm.grc, i am getting the following error:



Executing: /usr/bin/python2 -u 
/home/labuser/workarea-gnuradio/gnuradio/gr-digital/examples/ofdm/tx_ofdm.py


Traceback (most recent call last):
  File 
"/home/labuser/workarea-gnuradio/gnuradio/gr-digital/examples/ofdm/tx_ofdm.py", 
line 352, in 

    main()
  File 
"/home/labuser/workarea-gnuradio/gnuradio/gr-digital/examples/ofdm/tx_ofdm.py", 
line 340, in main

    tb = top_block_cls()
  File 
"/home/labuser/workarea-gnuradio/gnuradio/gr-digital/examples/ofdm/tx_ofdm.py", 
line 239, in __init__

    self.connect((self.fft_vxx_0, 0), (self.cyclicprefix_CP_cc_0, 0))
  File 
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", 
line 47, in wrapped

    func(self, src, src_port, dst, dst_port)
  File 
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", 
line 110, in connect

    self.primitive_connect(*args)
  File 
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", 
line 5334, in primitive_connect

    return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
ValueError:*itemsize mismatch: fft_vcc_fftw0:0 using 512, CP_cc0:0 
using 8*


*NOTE:* CP_cc is the block name that i gave when creating my own 
cyclic_prefix block.

Can anyone help with your suggestions?

Thanks,
Simran Kaur

___
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 cyclic prefix

[Simran Kaur]

Hi Team,
I am trying to make own cyclic prefix block in C++ in GNU Radio(removing
roll-off part and keeping all other parameters same). After connecting my
cyclic_prefix block to the already present FFT block in tx_ofdm.grc, i am
getting the following error:


Executing: /usr/bin/python2 -u
/home/labuser/workarea-gnuradio/gnuradio/gr-digital/examples/ofdm/tx_ofdm.py

Traceback (most recent call last):
  File
"/home/labuser/workarea-gnuradio/gnuradio/gr-digital/examples/ofdm/tx_ofdm.py",
line 352, in 
main()
  File
"/home/labuser/workarea-gnuradio/gnuradio/gr-digital/examples/ofdm/tx_ofdm.py",
line 340, in main
tb = top_block_cls()
  File
"/home/labuser/workarea-gnuradio/gnuradio/gr-digital/examples/ofdm/tx_ofdm.py",
line 239, in __init__
self.connect((self.fft_vxx_0, 0), (self.cyclicprefix_CP_cc_0, 0))
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
line 47, in wrapped
func(self, src, src_port, dst, dst_port)
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
line 110, in connect
self.primitive_connect(*args)
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line
5334, in primitive_connect
return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
ValueError:* itemsize mismatch: fft_vcc_fftw0:0 using 512, CP_cc0:0 using 8*

*NOTE:* CP_cc is the block name that i gave when creating my own
cyclic_prefix block.
Can anyone help with your suggestions?

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

Re: [Discuss-gnuradio] OFDM Frequency Spacing

[CEL]

Hi ARob,

You're right to presume that – because that's how the math behind the
DFT works out! So, no, you can't change that.

What you can do, of course, make a system with the correct resulting
sampling rate (as calculated from desired spacing times number of
bins), and just resample that to the rate you need.
Alternatively, and that's what you probably want: Calculate the FFT
length so that you get your desired channel spacing giving your
sampling rate, and use the carrier map to just use the (typically
center, aside from DC) ones that you need.

Best regards,
Marcus
On Wed, 2019-02-27 at 13:00 -0600, Alex Roberts wrote:
> Hello GNURadio Users,
> 
> Is it possible to specify the frequency spacing of the carriers in the OFDM 
> Transmitter Block or Carrier Allocator block? My assumption is the carrier 
> spacing is calculated from the sampling rate and the FFT length (e.g, if 
> sampling rate is 640k and fft length is 64, is the frequency spacing 10 kHz). 
> It would be nice to have the capability to manually define the frequency bin 
> spacing. 
> 
> Thanks,
> ARob
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OFDM Frequency Spacing

[Alex Roberts]

Hello GNURadio Users,

Is it possible to specify the frequency spacing of the carriers in the OFDM
Transmitter Block or Carrier Allocator block? My assumption is the carrier
spacing is calculated from the sampling rate and the FFT length (e.g, if
sampling rate is 640k and fft length is 64, is the frequency spacing 10
kHz). It would be nice to have the capability to manually define the
frequency bin spacing.

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

[Discuss-gnuradio] OFDM TX original example - output broken

[Sebastian Peters]

Hey All!

I'm fighting a problem with the original GNU Radio OFDM TX example from
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/examples/ofdm/tx_ofdm.grc

Nothing is changed, except adding two File Sinks writing the data to two 
text files.
One File Sink is added at the random source and one at the OFDM Receiver 
output (parallel to Tag Debug).


Letting it run for a short while, gives me two output files: send.txt 
and received.txt

Then, I'm comparing the outputs in hex:
hexdump -C send.txt > send.txt.hex
hexdump -C received.txt > received.txt.hex
meld send.txt.hex received.txt.hex

(meld is a nicer diff tool)

Every time I do this, the received file is broken at some point. Six 
lines in hexdump (i.e. 6*16=96 bytes) are missing.
It occurs at random places, sometimes multiple times, and as the pattern 
is repeating but not always broken at the same point, you can see that 
it is not a special magic string that is causing it.

My expectation is an error-free transmission.

Can someone explain this behaviour? Am I missing some basic aspect?
I have noticed, that the packet length is 96bytes.

Sebastian

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

[Discuss-gnuradio] OFDM Carrier Allocator

[dapodun nudopad]

Hello, I have trouble assigning parameters to sync words in OFDM Carrier
allocator block in gnu radio.
Does anyone has an example to share.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM TX/RX PAPR

[guillaume.tochou]

How do you reduce the PAPR with existing block in GRC ?

I've tried with Scrambler->Encoder CCSDS->Interleaver but it doesn't 
seems to work. I'm still not having any signal at the output of the OFDM 
receiver.


Guillaume


Le 27/03/2018 à 11:58, Ron Economos a écrit :
Yes, I think the whitener does the trick. If you plot the PAPR of band 
limited white noise, it's pretty much the same curve.


Ron

On 03/27/2018 02:36 AM, Müller, Marcus (CEL) wrote:

Oooh, that's a nice plot!
This is way better than I would have anticipated. Can I attribute that
to awesome whitening properties of the code itself and following
scramblers/interleavers?

Marcus
On Tue, 2018-03-27 at 02:31 -0700, Ron Economos wrote:
CCDF (Complementary Cumulative Distribution Function) is often used 
to show PAPR probability. Here's what the GNU Radio DVB-T2 
transmitter looks like at 32K (27841 active) carriers with an 
without tone reservation PAPR reduction.


Ron
On 03/27/2018 02:09 AM, Müller, Marcus (CEL) wrote:

On Fri, 2018-03-23 at 14:21 -0700, Martin Braun wrote:

If you've
increased the number of carriers, PAPR also goes up (a bit).

Yep, by the same factor as you increase the number of carriers (proof
idea: time-symbol with worst PAPR is the discrete dirac over the 
vector
of FFT length N. That has a PAPR of N/1 = N if freq domain samples 
were

amplitude-limited to 1.)

The probability to hit a PAPR that bad is, however, limited.
Considering an M-PSK modulation on the N subcarriers. Then there's a
total of M^N possible time-domain OFDM symbols, but only M·N of these
are worst-PAPR, so
P(worst PAPR for N carriers) = M·N/M^N = N / M^(N-1)
assuming equally likely symbols. Since M^N pretty certainly grows
faster than N, your likelihood of ending up in the "worst PAPR"
scenario actually drops with N.

The story looks a bit different if you're not interested in the worst-
PAPR-symbol, but in all symbols that have a PAPR worse than some
threshold, e.g. 20dB. Especially for LTE, there's a lot of
simulative/monte carlo PAPR>threshold curves, as things like trading
clipping for amplifier efficiency plays a very commercially relevant
role there.

Best regards,

Marcus


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



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.



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

Re: [Discuss-gnuradio] OFDM TX/RX

[Ron Economos]

Yes, I think the whitener does the trick. If you plot the PAPR of band 
limited white noise, it's pretty much the same curve.


Ron

On 03/27/2018 02:36 AM, Müller, Marcus (CEL) wrote:

Oooh, that's a nice plot!
This is way better than I would have anticipated. Can I attribute that
to awesome whitening properties of the code itself and following
scramblers/interleavers?

Marcus
On Tue, 2018-03-27 at 02:31 -0700, Ron Economos wrote:

CCDF (Complementary Cumulative Distribution Function) is often used to show 
PAPR probability. Here's what the GNU Radio DVB-T2 transmitter looks like at 
32K (27841 active) carriers with an without tone reservation PAPR reduction.

Ron
On 03/27/2018 02:09 AM, Müller, Marcus (CEL) wrote:

On Fri, 2018-03-23 at 14:21 -0700, Martin Braun wrote:

If you've
increased the number of carriers, PAPR also goes up (a bit).

Yep, by the same factor as you increase the number of carriers (proof
idea: time-symbol with worst PAPR is the discrete dirac over the vector
of FFT length N. That has a PAPR of N/1 = N if freq domain samples were
amplitude-limited to 1.)

The probability to hit a PAPR that bad is, however, limited.
Considering an M-PSK modulation on the N subcarriers. Then there's a
total of M^N possible time-domain OFDM symbols, but only M·N of these
are worst-PAPR, so
P(worst PAPR for N carriers) = M·N/M^N = N / M^(N-1)
assuming equally likely symbols. Since M^N pretty certainly grows
faster than N, your likelihood of ending up in the "worst PAPR"
scenario actually drops with N.

The story looks a bit different if you're not interested in the worst-
PAPR-symbol, but in all symbols that have a PAPR worse than some
threshold, e.g. 20dB. Especially for LTE, there's a lot of
simulative/monte carlo PAPR>threshold curves, as things like trading
clipping for amplifier efficiency plays a very commercially relevant
role there.

Best regards,

Marcus


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

Re: [Discuss-gnuradio] OFDM TX/RX

[CEL]

Oooh, that's a nice plot!
This is way better than I would have anticipated. Can I attribute that
to awesome whitening properties of the code itself and following
scramblers/interleavers?

Marcus
On Tue, 2018-03-27 at 02:31 -0700, Ron Economos wrote:
> CCDF (Complementary Cumulative Distribution Function) is often used to show 
> PAPR probability. Here's what the GNU Radio DVB-T2 transmitter looks like at 
> 32K (27841 active) carriers with an without tone reservation PAPR reduction.
> 
> Ron
> On 03/27/2018 02:09 AM, Müller, Marcus (CEL) wrote:
> > On Fri, 2018-03-23 at 14:21 -0700, Martin Braun wrote:
> > > If you've
> > > increased the number of carriers, PAPR also goes up (a bit).
> > 
> > Yep, by the same factor as you increase the number of carriers (proof
> > idea: time-symbol with worst PAPR is the discrete dirac over the vector
> > of FFT length N. That has a PAPR of N/1 = N if freq domain samples were
> > amplitude-limited to 1.)
> > 
> > The probability to hit a PAPR that bad is, however, limited.
> > Considering an M-PSK modulation on the N subcarriers. Then there's a
> > total of M^N possible time-domain OFDM symbols, but only M·N of these
> > are worst-PAPR, so
> > P(worst PAPR for N carriers) = M·N/M^N = N / M^(N-1)
> > assuming equally likely symbols. Since M^N pretty certainly grows
> > faster than N, your likelihood of ending up in the "worst PAPR"
> > scenario actually drops with N.
> > 
> > The story looks a bit different if you're not interested in the worst-
> > PAPR-symbol, but in all symbols that have a PAPR worse than some
> > threshold, e.g. 20dB. Especially for LTE, there's a lot of
> > simulative/monte carlo PAPR>threshold curves, as things like trading
> > clipping for amplifier efficiency plays a very commercially relevant
> > role there.
> > 
> > Best regards,
> > 
> > Marcus
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM TX/RX

[CEL]

On Fri, 2018-03-23 at 14:21 -0700, Martin Braun wrote:
> If you've
> increased the number of carriers, PAPR also goes up (a bit).

Yep, by the same factor as you increase the number of carriers (proof
idea: time-symbol with worst PAPR is the discrete dirac over the vector
of FFT length N. That has a PAPR of N/1 = N if freq domain samples were
amplitude-limited to 1.)

The probability to hit a PAPR that bad is, however, limited.
Considering an M-PSK modulation on the N subcarriers. Then there's a
total of M^N possible time-domain OFDM symbols, but only M·N of these
are worst-PAPR, so
P(worst PAPR for N carriers) = M·N/M^N = N / M^(N-1)
assuming equally likely symbols. Since M^N pretty certainly grows
faster than N, your likelihood of ending up in the "worst PAPR"
scenario actually drops with N.

The story looks a bit different if you're not interested in the worst-
PAPR-symbol, but in all symbols that have a PAPR worse than some
threshold, e.g. 20dB. Especially for LTE, there's a lot of
simulative/monte carlo PAPR>threshold curves, as things like trading
clipping for amplifier efficiency plays a very commercially relevant
role there.

Best regards,

Marcus

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM TX/RX

[Martin Braun]

On 03/16/2018 09:33 AM, guillaume.toc...@orange.com wrote:
> Hello all,
> 
> I want to make a flow graph for transmitting and receiving OFDM
> modulated data. To be precise, I want to do a LTE-M "like"
> transmission/reception, so I am trying to transmit data with a BW of
> 1.08 MHz OFDM.
> To do so, I use the following configuration : samp_rate = 1.92 MHz, fft
> length = 128, number of sub carriers = 72 , cp = 32
> 
> I modified the tx_ofdm.grc example file
> (/gnuradio/gr-digital/examples/ofdm/tx_ofdm.grc)
> To summary, I change the occupied carriers : range(-36, -21) +
> range(-20, -7) + range(-6, 0) + range(1, 7) + range(8, 21) + range(22,
> 37),) ; pilot carriers and symbols unchanged ; double the sync words to
> be equal to fft length.
> 
> The problem is at the output of the "Tag debug" I have just those
> messages :
> INFO: Parser returned #f
> INFO: Detected an invalid packet at item 1496
> ..
> INFO: Parser returned #f
> INFO: Detected an invalid packet at item 681901
> 
> And the spectrum isn't "stable" at 1.08 MHz BW.

Are you going across the air? The most common cause for this is too much
gain, and resulting distortions caused by large PAPR. If you've
increased the number of carriers, PAPR also goes up (a bit).

-- M
>  
> 
> What am I doing wrong ? How the sync words are determine ? Should I add
> pilot/symbol carriers ?
> 
> 
> Best Regards and thanks by advance,
> 
> Guillaume Tochou
> 
> 
> 
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 
> 
> 
> ___
> 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 TX/RX

[guillaume.tochou]

Hello all,

I want to make a flow graph for transmitting and receiving OFDM 
modulated data. To be precise, I want to do a LTE-M "like" 
transmission/reception, so I am trying to transmit data with a BW of 
1.08 MHz OFDM.
To do so, I use the following configuration : samp_rate = 1.92 MHz, fft 
length = 128, number of sub carriers = 72 , cp = 32


I modified the tx_ofdm.grc example file 
(/gnuradio/gr-digital/examples/ofdm/tx_ofdm.grc)
To summary, I change the occupied carriers : range(-36, -21) + 
range(-20, -7) + range(-6, 0) + range(1, 7) + range(8, 21) + range(22, 
37),) ; pilot carriers and symbols unchanged ; double the sync words to 
be equal to fft length.


The problem is at the output of the "Tag debug" I have just those 
messages :

INFO: Parser returned #f
INFO: Detected an invalid packet at item 1496
..
INFO: Parser returned #f
INFO: Detected an invalid packet at item 681901

And the spectrum isn't "stable" at 1.08 MHz BW.

What am I doing wrong ? How the sync words are determine ? Should I add 
pilot/symbol carriers ?



Best Regards and thanks by advance,

Guillaume Tochou





_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.



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

Re: [Discuss-gnuradio] OFDM channel tap questions

[Edwin Li]

Hi Bob,

Thanks for your detailed explanation. I figured out the causes for non-unity 
channel taps in my case. One is I didn’t consider normalization. Second, it was 
because that the Schmidl-Cox sync has a metric plateau. Imperfect 
synchronization gave me the phase rotation. 

Regards,
Edwin

Sent from Mail for Windows 10

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

Re: [Discuss-gnuradio] OFDM channel tap questions

[Robert McGwier]

Orthogonality (as the O in OFDM) guarantees a fixed phase relationship for
every symbol unless a pattern is introduced in an effort to reduce peak to
average power ratio (which I do not believe is happening here).  PAPR is
bane of OFDM and much research has gone in to reduce this problem which
requires high linearity in the amplifiers in cell towers.  Linearity is
typically accompanied by poor efficiency (lots of heat goes along with
watts).

In addition to this ,  there is indeed a random process involved in the
synchronization.  Schmidl-Cox is imperfect and "fine tuning" of the
sampling phase also has some randomness.  On the air you will have phase
offsets due to frequency dependent group delay through the analog
components of the RF systems,  group delay due to multipath, and on and
on.  I didn't open your grc file but I assume this was the perfect "wire"
channel with additive noise in which case ignore all of the other analog
stuff I added.

Bob


On Fri, Jan 12, 2018 at 2:22 PM, Jeff Long  wrote:

> Ah, normalization was the secret. The phase offset is there because the
> subcarriers frequencies each look like a phasor that keeps moving (at a
> rate relative to its offset). You want to predict what the phase will be at
> the next symbol.
>
>
> On 01/12/2018 01:59 PM, edwin wrote:
>
>> Hi Jeff,
>>
>> I just found out that if I normalize these taps by the FFT number(64 in
>> this case), they have magnitude of 1! Now my questions are:
>>
>> Why are there phase offset? The phase offset for each subchannel seems
>> different. Is it because of imperfect synchronization?
>>
>>
>> Regards,
>>
>> Edwin
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Bob McGwier
Founder, Federated Wireless, Inc
Founder and Technical Advisor, HawkEye 360, Inc
Research Professor Virginia Tech
Chief Scientist:  The Ted and Karyn Hume Center for National Security and
Technology
Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
Faculty Advisor Virginia Tech Amateur Radio Assn, Trustee K4KDJ
Director of AMSAT
Member of PVRC (Roanoke-Blacksburg), TAPR,  life member of ARRL and AMSAT,
NRVR.ORG (Rocketry)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM channel tap questions

[Jeff Long]

Ah, normalization was the secret. The phase offset is there because the 
subcarriers frequencies each look like a phasor that keeps moving (at a 
rate relative to its offset). You want to predict what the phase will be 
at the next symbol.


On 01/12/2018 01:59 PM, edwin wrote:

Hi Jeff,

I just found out that if I normalize these taps by the FFT number(64 in 
this case), they have magnitude of 1! Now my questions are:


Why are there phase offset? The phase offset for each subchannel seems 
different. Is it because of imperfect synchronization?



Regards,

Edwin




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

Re: [Discuss-gnuradio] OFDM channel tap questions

[edwin]

Hi Jeff,

I just found out that if I normalize these taps by the FFT number(64 in 
this case), they have magnitude of 1! Now my questions are:


Why are there phase offset? The phase offset for each subchannel seems 
different. Is it because of imperfect synchronization?



Regards,

Edwin


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

Re: [Discuss-gnuradio] OFDM channel tap questions

[Jeff Long]

I have to agree with you, and I don't understand what's going on. It 
looks like the magnitude of the taps should be 1.0, even if there's a 
phase offset.


On 01/11/2018 03:53 PM, edwin wrote:

Hi Jeff,

Thanks for the reply. What you said about the noise makes sense. 
However, even if I turn the noise off, I still get the weired taps:


Offset: 2112  Source: n/a Key: ofdm_sync_chan_taps   Value: #[(0,0) 
(0,0) (0,0) (0,0) (0,0) (0,0) (35.5567,-53.2143) (-6.27313,-63.6921) 
(-45.255,-45.255) (-63.6921,-6.27313) (-53.2143,35.5567) 
(-18.5783,61.2445) (24.4919,59.1286) (56.4432,30.1695) 
(62.7706,-12.4858) (40.6014,-49.4729) (2.45706e-06,-64.0003) 
(-40.6014,-49.4729) (-62.7706,-12.4858) (-56.4432,30.1695) 
(-24.4919,59.1286) (18.5783,61.2445) (53.2143,35.5567) 
(6.36922,-0.627315) (4.52551,-4.52551) (6.27312,-63.6921) 
(-3.55567,-5.32143) (-6.12445,-1.85783) (-5.91286,2.44919) 
(-3.01695,5.64432) (1.24858,6.27706) (4.94729,4.06014) (0,0) 
(4.94729,-4.06014) (1.24858,-6.27706) (-3.01696,-5.64433) 
(-5.91286,-2.44919) (-6.12445,1.85783) (-3.55567,5.32144) 
(6.27312,63.6921) (4.52551,4.52551) (6.36922,0.627312) 
(5.32143,-3.55567) (1.85783,-6.12445) (-2.44919,-5.91286) 
(-5.64433,-3.01696) (-6.27706,1.24858) (-4.06014,4.94729) 
(-1.9985e-06,6.40003) (4.06014,4.94729) (6.27706,1.24858) 
(5.64432,-3.01696) (2.44918,-5.91286) (-18.5783,-61.2445) 
(-5.32143,-3.55567) (-6.36922,0.62731) (-4.52551,4.52551) 
(-0.627314,6.36921) (3.55567,5.32143) (0,0) (0,0) (0,0) (0,0) (0,0)]



The piece of code you posted:

   for (int i = loop_start; i < loop_end; i++) {
 if ((d_ref_sym[i-carr_offset] != gr_complex(0, 0))) {
   taps[i-carr_offset] = sym[i] / d_ref_sym[i-carr_offset];
 }
   }

I believe it comes from the ofdm_chanest_vcvc_impl.cc, doesn't it? 
According to my understanding, it is calculating the channel taps by 
dividing the received symbol with the sync symbols, which are known. If 
the channel is perfect and there is no noise, the received symbols 
should be exactly the same as the sync symbols. The channel taps should 
be 1.



Regards,

Edwin




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

Re: [Discuss-gnuradio] OFDM channel tap questions

[edwin]

Hi Jeff,

Thanks for the reply. What you said about the noise makes sense. 
However, even if I turn the noise off, I still get the weired taps:


Offset: 2112  Source: n/a Key: ofdm_sync_chan_taps   Value: #[(0,0) 
(0,0) (0,0) (0,0) (0,0) (0,0) (35.5567,-53.2143) (-6.27313,-63.6921) 
(-45.255,-45.255) (-63.6921,-6.27313) (-53.2143,35.5567) 
(-18.5783,61.2445) (24.4919,59.1286) (56.4432,30.1695) 
(62.7706,-12.4858) (40.6014,-49.4729) (2.45706e-06,-64.0003) 
(-40.6014,-49.4729) (-62.7706,-12.4858) (-56.4432,30.1695) 
(-24.4919,59.1286) (18.5783,61.2445) (53.2143,35.5567) 
(6.36922,-0.627315) (4.52551,-4.52551) (6.27312,-63.6921) 
(-3.55567,-5.32143) (-6.12445,-1.85783) (-5.91286,2.44919) 
(-3.01695,5.64432) (1.24858,6.27706) (4.94729,4.06014) (0,0) 
(4.94729,-4.06014) (1.24858,-6.27706) (-3.01696,-5.64433) 
(-5.91286,-2.44919) (-6.12445,1.85783) (-3.55567,5.32144) 
(6.27312,63.6921) (4.52551,4.52551) (6.36922,0.627312) 
(5.32143,-3.55567) (1.85783,-6.12445) (-2.44919,-5.91286) 
(-5.64433,-3.01696) (-6.27706,1.24858) (-4.06014,4.94729) 
(-1.9985e-06,6.40003) (4.06014,4.94729) (6.27706,1.24858) 
(5.64432,-3.01696) (2.44918,-5.91286) (-18.5783,-61.2445) 
(-5.32143,-3.55567) (-6.36922,0.62731) (-4.52551,4.52551) 
(-0.627314,6.36921) (3.55567,5.32143) (0,0) (0,0) (0,0) (0,0) (0,0)]



The piece of code you posted:

  for (int i = loop_start; i < loop_end; i++) {
if ((d_ref_sym[i-carr_offset] != gr_complex(0, 0))) {
  taps[i-carr_offset] = sym[i] / d_ref_sym[i-carr_offset];
}
  }

I believe it comes from the ofdm_chanest_vcvc_impl.cc, doesn't it? 
According to my understanding, it is calculating the channel taps by 
dividing the received symbol with the sync symbols, which are known. If 
the channel is perfect and there is no noise, the received symbols 
should be exactly the same as the sync symbols. The channel taps should 
be 1.



Regards,

Edwin

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

Re: [Discuss-gnuradio] OFDM channel tap questions

[Jeff Long]

Hmm, that wasn't the whole answer. After reading the code a little more, 
it looks like the taps are a function of the sync symbols too, not just 
the channel.


  for (int i = loop_start; i < loop_end; i++) {
if ((d_ref_sym[i-carr_offset] != gr_complex(0, 0))) {
  taps[i-carr_offset] = sym[i] / d_ref_sym[i-carr_offset];
}
  }

On 01/10/2018 06:19 PM, Jeff Long wrote:
Noise has some bias and structure when measured over a short period. You 
can see this on a FFT display, where larger transforms give you a 
smoother noise floor. You'll notice that the taps change randomly with 
every packet as the estimator adjusts to the noise.


On 01/10/2018 04:59 PM, Edwin Li wrote:

Hi all,

I run the example found in the 
~/prefix/share/gnuradio/examples/digital/ofdm/rx_ofdm.grc. The ofdm 
signals can be decoded correctly. But I don't understand the channel 
taps.

The channel taps are shown to be
  Key: ofdm_sync_chan_taps   Value: #[(0,0) (0,0) (0,0) (0,0) (0,0) 
(0,0) (64.2159,-3.65375) (47.2264,-42.4505) (8.44977,-62.8107) 
(-32.7931,-54.5247) (-59.9085,-21.3488) (-59.8031,23.3288) 
(-32.3382,55.4137) (9.05079,63.8184) (46.331,42.7923) 
(65.1778,2.83559) (51.1081,-38.6363) (15.815,-62.1237) 
(-27.1419,-57.8722) (-58.2753,-27.4043) (-62.3711,15.658) 
(-37.9986,51.1873) (3.2302,64.2116) (5.44772,5.36124) 
(6.75629,1.41069) (54.079,-33.4137) (2.19591,-6.12473) 
(-1.91544,-6.56722) (-5.87699,-3.166) (-6.83039,0.994718) 
(-4.49682,5.42143) (-0.363706,6.79664) (0,0) (6.653,1.39701) 
(6.73628,-2.57781) (2.83963,-6.40383) (-1.3027,-7.62756) 
(-5.2442,-4.20318) (-7.30496,-0.464149) (-46.0595,43.0102) 
(-1.1131,6.52395) (3.2,5.98481) (6.67649,1.87579) 
(6.12278,-2.4737) (3.20924,-5.88361) (-1.73027,-7.05576) 
(-5.08706,-4.94171) (-6.68616,-0.0110321) (-5.45217,3.92032) 
(-1.28323,7.08399) (3.24904,6.21134) (6.67752,2.90531) 
(7.18779,-1.51598) (36.8116,-51.7724) (0.146267,-7.00651) 
(-4.51996,-4.89137) (-7.37838,-1.41322) (-6.20339,3.98806) 
(-2.49422,6.80633) (0,0) (0,0) (0,0) (0,0) (0,0)]


This is weired. The channel is just AWGN.  Why are not the channel 
taps 1?
I found the same question posted before. 
https://lists.gnu.org/archive/html/discuss-gnuradio/2017-05/msg00057.html. 
But didn't see the answer.


I'm running GNU Radio Companion 3.7.12 by the way. The example can be 
found in the attachment.


Regards,
Edwin



___
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] OFDM channel tap questions

[Jeff Long]

Noise has some bias and structure when measured over a short period. You 
can see this on a FFT display, where larger transforms give you a 
smoother noise floor. You'll notice that the taps change randomly with 
every packet as the estimator adjusts to the noise.


On 01/10/2018 04:59 PM, Edwin Li wrote:

Hi all,

I run the example found in the 
~/prefix/share/gnuradio/examples/digital/ofdm/rx_ofdm.grc. The ofdm 
signals can be decoded correctly. But I don't understand the channel taps.

The channel taps are shown to be
  Key: ofdm_sync_chan_taps   Value: #[(0,0) (0,0) (0,0) (0,0) (0,0) 
(0,0) (64.2159,-3.65375) (47.2264,-42.4505) (8.44977,-62.8107) 
(-32.7931,-54.5247) (-59.9085,-21.3488) (-59.8031,23.3288) 
(-32.3382,55.4137) (9.05079,63.8184) (46.331,42.7923) (65.1778,2.83559) 
(51.1081,-38.6363) (15.815,-62.1237) (-27.1419,-57.8722) 
(-58.2753,-27.4043) (-62.3711,15.658) (-37.9986,51.1873) 
(3.2302,64.2116) (5.44772,5.36124) (6.75629,1.41069) (54.079,-33.4137) 
(2.19591,-6.12473) (-1.91544,-6.56722) (-5.87699,-3.166) 
(-6.83039,0.994718) (-4.49682,5.42143) (-0.363706,6.79664) (0,0) 
(6.653,1.39701) (6.73628,-2.57781) (2.83963,-6.40383) (-1.3027,-7.62756) 
(-5.2442,-4.20318) (-7.30496,-0.464149) (-46.0595,43.0102) 
(-1.1131,6.52395) (3.2,5.98481) (6.67649,1.87579) (6.12278,-2.4737) 
(3.20924,-5.88361) (-1.73027,-7.05576) (-5.08706,-4.94171) 
(-6.68616,-0.0110321) (-5.45217,3.92032) (-1.28323,7.08399) 
(3.24904,6.21134) (6.67752,2.90531) (7.18779,-1.51598) 
(36.8116,-51.7724) (0.146267,-7.00651) (-4.51996,-4.89137) 
(-7.37838,-1.41322) (-6.20339,3.98806) (-2.49422,6.80633) (0,0) (0,0) 
(0,0) (0,0) (0,0)]


This is weired. The channel is just AWGN.  Why are not the channel taps 1?
I found the same question posted before. 
https://lists.gnu.org/archive/html/discuss-gnuradio/2017-05/msg00057.html. 
But didn't see the answer.


I'm running GNU Radio Companion 3.7.12 by the way. The example can be 
found in the attachment.


Regards,
Edwin



___
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 tap questions

[Edwin Li]

Hi all,

I run the example found in the
~/prefix/share/gnuradio/examples/digital/ofdm/rx_ofdm.grc. The ofdm signals
can be decoded correctly. But I don't understand the channel taps.
The channel taps are shown to be
 Key: ofdm_sync_chan_taps   Value: #[(0,0) (0,0) (0,0) (0,0) (0,0) (0,0)
(64.2159,-3.65375) (47.2264,-42.4505) (8.44977,-62.8107)
(-32.7931,-54.5247) (-59.9085,-21.3488) (-59.8031,23.3288)
(-32.3382,55.4137) (9.05079,63.8184) (46.331,42.7923) (65.1778,2.83559)
(51.1081,-38.6363) (15.815,-62.1237) (-27.1419,-57.8722)
(-58.2753,-27.4043) (-62.3711,15.658) (-37.9986,51.1873) (3.2302,64.2116)
(5.44772,5.36124) (6.75629,1.41069) (54.079,-33.4137) (2.19591,-6.12473)
(-1.91544,-6.56722) (-5.87699,-3.166) (-6.83039,0.994718)
(-4.49682,5.42143) (-0.363706,6.79664) (0,0) (6.653,1.39701)
(6.73628,-2.57781) (2.83963,-6.40383) (-1.3027,-7.62756) (-5.2442,-4.20318)
(-7.30496,-0.464149) (-46.0595,43.0102) (-1.1131,6.52395) (3.2,5.98481)
(6.67649,1.87579) (6.12278,-2.4737) (3.20924,-5.88361) (-1.73027,-7.05576)
(-5.08706,-4.94171) (-6.68616,-0.0110321) (-5.45217,3.92032)
(-1.28323,7.08399) (3.24904,6.21134) (6.67752,2.90531) (7.18779,-1.51598)
(36.8116,-51.7724) (0.146267,-7.00651) (-4.51996,-4.89137)
(-7.37838,-1.41322) (-6.20339,3.98806) (-2.49422,6.80633) (0,0) (0,0) (0,0)
(0,0) (0,0)]

This is weired. The channel is just AWGN.  Why are not the channel taps 1?
I found the same question posted before.
https://lists.gnu.org/archive/html/discuss-gnuradio/2017-05/msg00057.html.
But didn't see the answer.

I'm running GNU Radio Companion 3.7.12 by the way. The example can be found
in the attachment.

Regards,
Edwin


rx_ofdm.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM frame equalizer length tag

[Michael Dickens]

Hi Alice - If I had to guess, it would be that the tag for the
frame_equalizer_alix block is "frame_len", while that for the Pseudo-
Random Generator is "frame len" ... without the "_" joining the words.
Or, that's what it looks like in the image. The tagged_stream_block is
picky about these names; they really have to be identical!
A word of advice: Assign a variable that holds this string value, and
set all of the blocks that use it to the variable. Make the variable
name and it's value something other than "frame_len" alone ... for
example, "frame_len_alix" or the like ... a name that will be clear in
debugging that it is either there and correct or not (and thus
incorrect).
Hope this helps! - MLD

On Wed, Dec 6, 2017, at 05:54 PM, Alice Lo Valvo wrote:
> Hi,


> I duplicated the OFDM Frame Equalizer block, and all it works, I added
> a second input port which is connect with another block that is a
> tagged_stream block. I don't understand the reason of this error:> 
>> gr::log :FATAL: frame_equalizer_alix0 - Missing a required length tag
>> on port 1 at item #0>>  thread[thread-per-block[49]: > frame_equalizer_alix (17)>]:
>>  Missing length tag.> Length tag is there.. any ideas?
> 
>  Thanks in advance.
>  Alice
> 
> _
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> Email had 1 attachment:


>  * Schermata 2017-12-06 alle 23.51.39.png 497k (image/png)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM Preamble

[Edwin Li]

Hi Adhitha,

I haven't used the "OFDM Insert Preamble" module before. But in my
understanding, in tx_ofdm.grc, "OFDM Carrier Allocator" does the job of
"OFDM insert preamble". It uses "sync word" instead of "preamble". I think
they are the same thing. As for FFT length, keep it the same as your other
OFDM modules. Note that the length of a sync word must be the same as FFT
length.

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

[Discuss-gnuradio] OFDM Preamble

[Adhitha Dias]

Hi,

Could anyone please help me to set the input parameters in "OFDM Insert
Preamble" OOT in GNURadio? It has 2 parameters FFT Length, and Preamble.
Where should it be used in the tx_ofdm.grc example. Thank you for the help
in advance.

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

Re: [Discuss-gnuradio] OFDM Channel Equalisation not unity for perfect channel

[Justin Hamilton]

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

[Discuss-gnuradio] OFDM Channel Equalisation not unity for perfect channel

[Justin Hamilton]

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

[Discuss-gnuradio] Ofdm rx_time and packet error rate

[Tschuls Lebarski]

Hi All,

First of all: I'm a newbee

I'm into the example of gr-digital: rx_ofdm.grc and tx_ofdm.gr.
I have 2 Questions:

1. My goal is to check the time between 2 recieved packets. I realized that
the TAG_DEBUG-Block outputs some rx_Time.
 Offset: 1035  Source: n/a Key: rx_time   Value: {2523 0.455868}
 From the documentation I saw that unit 2523 is seconds and 0.455868 is a
fraction of a second.
Does that mean: 2523s and 455.868ms?

2. I want to calculate the recieved packages in order do have a
comparisson: packets send to packets recieved.
I found out that i can limit data with the head block.
Can someone explain me how to calculate how many packets arrived correctly
or is there a certain block counting the recieved packets?

Thanks a lot in advance
Julian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM implementation for high data rates

[Ron Economos]

There's the DVB-T transmitter and receiver in the Digital Television 
component of GNU Radio. It's capable of 31.6 Mbps in a standard 8 MHz 
bandwidth. (and can be used at higher bandwidths).


I have some OOT modules that allow sending IP packets over DVB. Note 
that these modules only implement the transmit portion and are meant to 
be used with commercial receivers.


https://github.com/drmpeg/gr-mpe

https://github.com/drmpeg/gr-ule

One of the drawbacks is that DVB-T is a streaming protocol, so a two-way 
link would require a full-duplex RF system. Also, latency is pretty high 
due to the long frame size used in DVB-T. You can get a much lower 
latency with the DVB-T2 transmitter (which has adjustable frame size), 
but there's no companion DVB-T2 receiver in GNU Radio (you have to use a 
commercial DVB-T2 receiver like the PCTV 292e).


Ron

On 04/06/2017 09:52 AM, Yaşar Sinan NASIR wrote:

Hi,

For OFDM transmitter and receiver, I was using benchmark_tx/rx 
implementations. However, I am wondering what is the best publicly 
available OFDM implementation for relatively high bandwidths (10s of 
MHz) and data rates (10s of Mbps)?


Best,
Sinan




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

[Discuss-gnuradio] OFDM implementation for high data rates

[Yaşar Sinan NASIR]

Hi,

For OFDM transmitter and receiver, I was using benchmark_tx/rx
implementations. However, I am wondering what is the best publicly
available OFDM implementation for relatively high bandwidths (10s of MHz)
and data rates (10s of Mbps)?

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

Re: [Discuss-gnuradio] OFDM/GR-IEEE802-11

[Thomas Wilkinson]

Understood. Thanks!

On Fri, Mar 31, 2017 at 2:32 PM, Marcus Müller 
wrote:

> Depends on where you are. But usually, no.
>
> On 31.03.2017 19:54, Thomas Wilkinson wrote:
>
> Legally, I can perform tests within ISM bands. Correct?
>
> On Fri, Mar 31, 2017 at 1:14 PM, Martin Braun  wrote:
>
>> You can change the frequency technically. Legally, we can't give you
>> advice here other than to follow the rules.
>>
>> Cheers,
>> Martin
>>
>> On 03/30/2017 09:52 AM, Thomas Wilkinson wrote:
>> >
>> > Please forgive me as I am new to SDRs and DSP.
>> >
>> > I am interested in development of a radio link using two B210s and
>> > GR-IEEE802-11.   However, I would like for this link to operate at any
>> > frequency. I am interested in a robust waveform with minimum of 11MBPS
>> > throughput, which is why I am interested in OFDM/802.11. My very limited
>> > hope/understanding is that I can potentially change the frequency of
>> > operation in the PHY layer.
>> >
>> > Thanks in advance for your help.
>> >
>> >
>> > Tom
>> >
>> >
>> > ___
>> > 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
>>
>
>
>
> --
> Regards,
>
> Tom Wilkinson
> SMART Scholar 
> MS Student, Electrical Engineering
> NC State University
> c: 919.951.4449 <%28919%29%20951-4449>
> e: tbwil...@ncsu.edu
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Regards,

Tom Wilkinson
SMART Scholar 
MS Student, Electrical Engineering
NC State University
c: 919.951.4449
e: tbwil...@ncsu.edu
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM/GR-IEEE802-11

[Marcus Müller]

Depends on where you are. But usually, no.


On 31.03.2017 19:54, Thomas Wilkinson wrote:
> Legally, I can perform tests within ISM bands. Correct?
>
> On Fri, Mar 31, 2017 at 1:14 PM, Martin Braun  > wrote:
>
> You can change the frequency technically. Legally, we can't give you
> advice here other than to follow the rules.
>
> Cheers,
> Martin
>
> On 03/30/2017 09:52 AM, Thomas Wilkinson wrote:
> >
> > Please forgive me as I am new to SDRs and DSP.
> >
> > I am interested in development of a radio link using two B210s and
> > GR-IEEE802-11.   However, I would like for this link to operate
> at any
> > frequency. I am interested in a robust waveform with minimum of
> 11MBPS
> > throughput, which is why I am interested in OFDM/802.11. My very
> limited
> > hope/understanding is that I can potentially change the frequency of
> > operation in the PHY layer.
> >
> > Thanks in advance for your help.
> >
> >
> > Tom
> >
> >
> > ___
> > 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
> 
>
>
>
>
> -- 
> Regards,
>
> Tom Wilkinson
> SMART Scholar 
> MS Student, Electrical Engineering
> NC State University
> c: 919.951.4449 
> e: tbwil...@ncsu.edu 
>
>
> ___
> 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] OFDM/GR-IEEE802-11

[Thomas Wilkinson]

Legally, I can perform tests within ISM bands. Correct?

On Fri, Mar 31, 2017 at 1:14 PM, Martin Braun  wrote:

> You can change the frequency technically. Legally, we can't give you
> advice here other than to follow the rules.
>
> Cheers,
> Martin
>
> On 03/30/2017 09:52 AM, Thomas Wilkinson wrote:
> >
> > Please forgive me as I am new to SDRs and DSP.
> >
> > I am interested in development of a radio link using two B210s and
> > GR-IEEE802-11.   However, I would like for this link to operate at any
> > frequency. I am interested in a robust waveform with minimum of 11MBPS
> > throughput, which is why I am interested in OFDM/802.11. My very limited
> > hope/understanding is that I can potentially change the frequency of
> > operation in the PHY layer.
> >
> > Thanks in advance for your help.
> >
> >
> > Tom
> >
> >
> > ___
> > 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
>



-- 
Regards,

Tom Wilkinson
SMART Scholar 
MS Student, Electrical Engineering
NC State University
c: 919.951.4449 <(919)%20951-4449>
e: tbwil...@ncsu.edu
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM/GR-IEEE802-11

[Martin Braun]

You can change the frequency technically. Legally, we can't give you
advice here other than to follow the rules.

Cheers,
Martin

On 03/30/2017 09:52 AM, Thomas Wilkinson wrote:
> 
> Please forgive me as I am new to SDRs and DSP. 
> 
> I am interested in development of a radio link using two B210s and
> GR-IEEE802-11.   However, I would like for this link to operate at any
> frequency. I am interested in a robust waveform with minimum of 11MBPS
> throughput, which is why I am interested in OFDM/802.11. My very limited
> hope/understanding is that I can potentially change the frequency of
> operation in the PHY layer.
> 
> Thanks in advance for your help. 
> 
> 
> Tom
> 
> 
> ___
> 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/GR-IEEE802-11

[Thomas Wilkinson]

Please forgive me as I am new to SDRs and DSP.

I am interested in development of a radio link using two B210s and
GR-IEEE802-11.   However, I would like for this link to operate at any
frequency. I am interested in a robust waveform with minimum of 11MBPS
throughput, which is why I am interested in OFDM/802.11. My very limited
hope/understanding is that I can potentially change the frequency of
operation in the PHY layer.

Thanks in advance for your help.


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

[Discuss-gnuradio] OFDM Receiver

[MUHAMMAD AHMAD]

Hi,

I am referring the built in  example of gnuradio companion  ( rx_ofdm.grc).
In which I replace random source with usrp source.
on Transmetter side I am sending some bits and in receiver flow graph
(rx_ofdm ) I am facing problem where I have to attach file sink to get
 these bits.

I attached *File sink block* after *bits repack* block but I did not
get any data in file.
I also have attached *File sink after stream CRC32 block but*  I did not
get data in file.

Kindly inform if possible where I have to attach file sink in flow graph to
get receiving bits.

Here is an Attached flow graph modified form of (rx_ofdm)

Thanks in anticipation.


finaloftm_rx.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM receiver

[Marcus Müller]

Hi Muhammad,

sadly, it's not very clear what you're asking about.

* Which flow graph are you referring to?
* What is your precise problem, and what have you tried to solve it so
far? How can we help you with that?

Best regards,

Marcus

On 02/22/2017 02:05 PM, MUHAMMAD AHMAD wrote:
> How can I receive  bits using file sink in ofdm receiver.
> where I have to connect  file sink in flow graph of ofdm receiver?
> either bits repack block output can give bits?
>
>
> ___
> 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 receiver

[MUHAMMAD AHMAD]

How can I receive  bits using file sink in ofdm receiver.
where I have to connect  file sink in flow graph of ofdm receiver?
either bits repack block output can give bits?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OFDM channel etimation

[HAFIZ HASHIM Imtiaz]

Hi,

I want to estimate the channel (h) using OFDM. I am using rx_OFDM.grc flow
graph for OFDM implementation. According to my knowledge, I can find
channel from the output of OFDM channel estimation block. The channel is
present on tags. But how can I extract channel form these tags. If I
connect the tag debug block with complex type, would I get the chennel?
Please guide if possible.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM channel estimation

[Martin Braun]

On 10/04/2016 06:25 AM, Andreas Weinand wrote:
> Hello,
> 
> i'm currently dealing with OFDM channel estimation and try to read out
> the estimated values for this purpose. It works when i take the ones
> that are given by the tag debug block (Key: ofdm_sync_chan_taps). But
> somehow the values look a bit strange to me. Can anybody explain why
> there are some carriers in the upper frequency range that are not
> allocated, although they should be (see the plotted values). I did not
> change the number of active subcarrier which is 48. So carriers should
> be allocated up to carrier 59.
> I have used N210 USRPs und SBX daughterboards to get these values, but
> the same thing happens when i run the ofdm receiver in a simulation. The
> magnitude of these upper carriers is still approx. 1 Decade below the
> magnitude of the other active carriers in that case like in the OTA
> setup. Can anybody help with this problem?

Andreas,

as you can see, the length of the channel estimate vectors is equal to
the FFT length. However, channel estimates are only calculated for those
bins that are actually occupied. Here's the code:

https://github.com/gnuradio/gnuradio/blob/807bba681d56589d2f02cd6227181d9abc796e17/gr-digital/lib/ofdm_chanest_vcvc_impl.cc#L198-L210

There's several reasons why the length of channel taps is FFT length
instead of the number of carriers, but one major one is that we shift
the channel taps around according to the coarse frequency offset.

Cheers,
Martin

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

[Discuss-gnuradio] OFDM channel estimation

[Andreas Weinand]

Hello,

i'm currently dealing with OFDM channel estimation and try to read out 
the estimated values for this purpose. It works when i take the ones 
that are given by the tag debug block (Key: ofdm_sync_chan_taps). But 
somehow the values look a bit strange to me. Can anybody explain why 
there are some carriers in the upper frequency range that are not 
allocated, although they should be (see the plotted values). I did not 
change the number of active subcarrier which is 48. So carriers should 
be allocated up to carrier 59.
I have used N210 USRPs und SBX daughterboards to get these values, but 
the same thing happens when i run the ofdm receiver in a simulation. The 
magnitude of these upper carriers is still approx. 1 Decade below the 
magnitude of the other active carriers in that case like in the OTA 
setup. Can anybody help with this problem?


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

[Discuss-gnuradio] OFDM sync word generator

[Suman Bhunia]

Hi!

I was wondering if there is any code block available to generate 
suitable sync words for OFDM transceivers. I want to use 512, 1024 and 
2048 as FFT length for OFDM.


Any help is much appreciated.

==
Thanks and Regards,
Suman Bhunia
PhD candidate in CSE
University of Nevada Reno
http://www.sbhunia.me




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

Re: [Discuss-gnuradio] OFDM IFFT calculate

[Marcus Müller]

Ah, forgot to actually cite one thing:

On 30.05.2016 14:49, Marcus Müller wrote:
>
>> I can't find its' implementation in anywhere so that I can't
>> understand what happen in this function.
> A DFT is performed, by calling the fftwf_execute function of the FFTw
> library, which really, just executes a fast DFT.
And because "DFT" is not totally unambiguous (because there are
different normalization conventions out there), if you care for the
actual formula, it's  on
http://www.fftw.org/doc/The-1d-Discrete-Fourier-Transform-_0028DFT_0029.html#The-1d-Discrete-Fourier-Transform-_0028DFT_0029
i.e. the backwards (inverse) n-point FFT is really just plain, old,
boring, textbook


No normalization.

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

Re: [Discuss-gnuradio] OFDM IFFT calculate

[Marcus Müller]

Hi SangHyuk

On 30.05.2016 14:25, SangHyuk Kim wrote:
> Hi all,
>
> The file, /gr-fft/lib/fft_vcc_fftw.cc(http://goo.gl/X8WNPh),
No need to use URL shorteners in Emails.
Why are you using a revision of that file from 2012? That is not what
you should do. Select "branch: Master" from the drop-down menu; you
should be looking at
http://gnuradio.org/redmine/projects/gnuradio/repository/entry/gr-fft/lib/fft_vcc_fftw.cc?rev=master
.
Reading versions of code that no-one uses anymore doesn't help you !

> I can understand how get inputs to 'd_fft', but I don't know about
d_fft->execute() that compute the fft.

So, here's how you approach something like this: Find out what "d_fft"
is. For that, you often need to look in the .h file to your .cc.

There you'll find out which class type d_fft has.

Find that type's definition.

Or, you could just go to

and search for "execute" in the search box. That'll tell you the classes
that have a method called "execute", and you can access the
documentation to these.

> I can't find its' implementation in anywhere so that I can't
> understand what happen in this function.
A DFT is performed, by calling the fftwf_execute function of the FFTw
library, which really, just executes a fast DFT.


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

[Discuss-gnuradio] OFDM IFFT calculate

[SangHyuk Kim]

Hi all,

The file, /gr-fft/lib/fft_vcc_fftw.cc(http://goo.gl/X8WNPh), changes domain
from frequency to time using IFFT(Inverse-Fast-Fourier-Transform).

It takes parallel subcarriers in frequency-domain (it is defined 'in' in
the file) and converts it into time-domain(it is defined 'out').

I can understand how get inputs to 'd_fft', but I don't know about
d_fft->execute() that compute the fft.

I can't find its' implementation in anywhere so that I can't understand
what happen in this function.

Could anyone tell me how compute the fft in the function ?

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

Re: [Discuss-gnuradio] OFDM Packets and Frames into Tagged Stream Block?

[Martin Braun]

A quick hack would be to throw down a block that renames certain tags.
You'd have to write that block, but it would consist of a memcpy() for
the data and a conditional tag copying.

M

On 04/25/2016 10:20 PM, Jingyi Sun wrote:
> Hello experts,
> 
> I have a question regarding using both OFDM packets and frames as inputs
> into the same tagged stream blocks.
> 
> In particular, I would like to input data from inside an OFDM
> transmitter and data from inside an OFDM receiver into the same tagged
> stream block. I would like to process the data while they are symbols
> before the IFFT in the transmitter, and after the FFT in the receiver,
> as shown in the attached flow graph. When we run the flow graph with
> this additional block, data transmission stops due to a run-time error. 
> 
> We believe that the problem is because we are trying to input tagged
> streams with different length tag keys: the tagged stream from the OFDM
> transmitter has length_tag_key = packet_len, while the tagged stream
> from the OFDM receiver has length_tag_key = frame_len. When we use
> inputs of the same length_tag_key, we find that there is no run time error. 
> 
> My question: is there someway that we can process the receiver data and
> the transmitter data in the same block? For example, can I "break down"
> the frames into packets so that we can avoid the mismatching
> length_tag_key error? 
> 
> Thanks a bunch!
> Jenny & Team
> 
> 
> ​


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

Re: [Discuss-gnuradio] OFDM Constellation Issue

[Martin Braun]

You have windows enabled in the FFTs. Switch to rectangular windows for
OFDM (you can check out the OFDM examples).

M

On 04/16/2016 02:53 PM, Abhinav Jadon wrote:
> Hi,
> I made two flowgraphs.
> 1st flowgraph : Source -> BPSK modulation -> Constellation Sink
> 2nd flowgraph : Source -> BPSK modulation -> IFFT -> FFT ->
> Constellation Sink
> 
> The source is configured such that if only transmits 1s.
> Therefore one would expect the constellation plot to have one dot on the
> x-axis around the point (1,0). This is what happens :)
> But in the second flowgraph one would expect the same result but the
> flowgraph is not what it should look like.
> 
> The link for the screenshots :
> https://drive.google.com/folderview?id=0Bwh_xvBu7PpWaTRZX0VqQzBxNU0=sharing
> p1 and p2 correspond to the second flowgraph
> Regards
> Abhinav Jadon
> 
> 
> ___
> 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 Constellation Issue

[Abhinav Jadon]

Hi,
I made two flowgraphs.
1st flowgraph : Source -> BPSK modulation -> Constellation Sink
2nd flowgraph : Source -> BPSK modulation -> IFFT -> FFT -> Constellation
Sink

The source is configured such that if only transmits 1s.
Therefore one would expect the constellation plot to have one dot on the
x-axis around the point (1,0). This is what happens :)
But in the second flowgraph one would expect the same result but the
flowgraph is not what it should look like.

The link for the screenshots :
https://drive.google.com/folderview?id=0Bwh_xvBu7PpWaTRZX0VqQzBxNU0=sharing
p1 and p2 correspond to the second flowgraph
Regards
Abhinav Jadon
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM tx rx error

[Martin Braun]

Jenny,

we have a limit in place for packet sizes, which depends on your system.
If you type sysctl -a, it'll say something like

kernel.shmmax = 18446744073692774399


100 OFDM symbols seems pretty long, though. If your packet length is 96,
as in the example, that means a total packet length of 100 (including
CRC). With 48 useful carriers, you get 6 bytes per OFDM symbol, which
results in 17 OFDM symbols, plus 2 more for the header. You'll need to
give us some more info for us to help you.

Cheers,
Martin

On 03/19/2016 11:44 AM, Jingyi Sun wrote:
> Hi, 
> 
> I'm using the examples rx_ofdm.grc and tx_ofdm.grc together to transmit
> and receive packets over the air.  Both work over a simulated channel,
> but when I actually transmit and receive over the air, I get the error:
> 
> *"Detected a packet larger than max frame size (100 symbols)"*
> 
> I saw the previous thread on this called "OFDM transmitter receiver"
> which goes as follows, but I don't really know what to make of this... 
> 
> I tried to run /sysctl kernel.shmmax /in terminal, but I got the message
> "No such file or directory". I'm also not sure what kernel.shmmax is.
> 
> These are my parameters:
> 
> fft length= 64
> 
> cyclic prefix = 16
> packet length = 96
> no. of occupied carriers = 53
> no. of pilot carriers = 4
> 
> 
> I'm very new to gnuradio, and any insights into this would be appreciated!!
> 
> 
> Thanks,
> Jenny
> 
> --
> 
> *From*:   Martin Braun
> *Subject*:Re: [Discuss-gnuradio] OFDM transmitter receiver
> *Date*:   Tue, 26 Aug 2014 11:10:53 +0200
> *User-agent*: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
> Thunderbird/24.6.0
> 
> 
> 
> Try and not kill the context in a mailing list thread; these are also
> archived and are used by others for referral.
> 
> Max frame size depends on max_output_buffer(). 80 symbols at a 64-sized
> FFT would be ~40kB... that doesn't seem unreasonable. Not sure if
> there's a problem here. I suggest you have a look at the buffer sizes to
> track down this problem.
> 
> M
> 
> On 08/25/2014 03:31 PM, Martin Braun wrote:
>>/What's your kernel.shmmax value? (run sysctl kernel.shmmax)/
>>//
>>/M/
>>//
>>/On 08/25/2014 12:47 PM, sreena p h wrote:/
>>/> Hi/
>>/> I used the ofdm transmitter receiver blocks to create a simple system as/
>>/> shown in the attachment. I used the system parameters as those used in/
>>/> the example transmitter and receiver grcs. Now I get error that/
>>/> 'Detected a packet larger than max frame size (80 symbols)'. I would/
>>/> like to know how the max frame size is set and should I add more/
>>/> information to the grc. /
>>/>/
>>/> My transmitter- receiver parameters/
>>/>/
>>/> fft length= 64/
>>/> cyclic prefix = 16/
>>/> packet length = 96/
>>/> no. of occupied carriers = 48/
>>/> no. of pilot carriers = 4/
>>/>/
>>/>/
>>/>/
>>/> ___/
> 
> 
> 
> ___
> 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] OFDM benchmark optimal parameter

[Diyar Muhammed]

Marcus, many thanks I will do it.

On Mon, Mar 21, 2016 at 11:01 AM, Marcus Müller 
wrote:

> I'd encourage you to either fix the Bit Error Rate block or write
> something that does your job. In fact, the unmodified ofdm_loopback example
> doesn't work as BER test, because all packets are identical, and if a
> packet has errors, the OFDM receiver will drop it, so you'd never see an
> error.
>
> Open rx_ofdm.grc ; it is a very similar example, but instead of having the
> black box "OFDM Receiver", you see how the OFDM receiver internally works.
> Play with the channel model; e.g. set the noise voltage really high (1.0)
> and the frequency offset to e.g. 2.0/fft_len. You'll see a lot of
>
> INFO: Detected and invalid packet at item 
>
> printed.
> Now, change these parameters.
> Your ratio of valid packets and invalid packets gives you a packet error
> rate.
>
> Best regards,
> Marcus
>
>
> On 21.03.2016 11:47, Diyar Muhammed wrote:
>
> Marcus,
> I look at ofdm_loopback.grc example, I made the same scenario but I had
> problem with Error Rate block I got error rate around 4 to 5, as my
> knowledge that is not right I think should be between 0 to 1.
> If there is a transceiver example with measure bit error rate that will be
> helpful for me.
> in advance thank you.
>
> On Mon, Mar 21, 2016 at 10:36 AM, Marcus Müller 
> wrote:
>
>> Note that the benchmark_rx/_tx example is really a bit old, and I always
>> try to steer people away from it towards the newer OFDM examples that are
>> far more flexible and behave a lot more like a real system would.
>>
>> Have a look at the ofdm_loopback.grc example; you can replace the
>> (channelmodel->throttle) by a USRP sink and source. Tadah! Live demo.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 21.03.2016 11:34, Diyar Muhammed wrote:
>>
>> many thanks
>>
>> On Mon, Mar 21, 2016 at 10:31 AM, Marcus Müller <
>> marcus.muel...@ettus.com> wrote:
>>
>>> Diyar,
>>>
>>> > I look at tx benchmark help I could not find rates but there is packet
>>> size and megabytes to transmit.
>>>
>>> benchmark_tx --help should help you.
>>> You set the bandwidth, which sets the sampling rate; together with the
>>> occupied tones number related to the FFT length, you get a symbol rate.
>>> Together with the modulation you set, this gives you a
>>>
>>> Since only one program can use a USRP at a time, you can't use
>>> benchmark_tx and benchmark_rx at the same time.
>>> Instead, use benchmark_tx with the "--to-file" option to save the
>>> samples to a file, and build a quick GNU Radio flow graph in GRC that has a
>>> file source (reading that file), a USRP sink (fed from the file source), a
>>> USRP source, and a file sink (saving the samples from the USRP source to
>>> another file).
>>>
>>> Then use benchmark_rx with the --from-file option to read in these saved
>>> samples.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 21.03.2016 11:17, Diyar Muhammed wrote:
>>>
>>> Dear Marcus,
>>> Thank you very much indeed for fast replying.
>>> I look at tx benchmark help I could not find rates but there is packet
>>> size and megabytes to transmit.
>>> so that, which one do you mean packet size or megabytes?
>>> it is okay to use USRP B210 for transmitting and receiving by using to
>>> benchmark file?
>>> because when I used one of them (tx or rx) and then I wanted to run
>>> another one the error come up (no device found for empty device address).
>>> in advance many thanks.
>>>
>>> On Mon, Mar 21, 2016 at 9:57 AM, Marcus Müller <
>>> marcus.muel...@ettus.com> wrote:
>>>
 Diyar,

 with the benchmark_ scripts, you **set** the rates, and you can only
 observe how many packets were successfully transmitted.
 The rest is really very basic math.

 Best regards,
 Marcus


 On 21.03.2016 10:50, Diyar Muhammed wrote:

 Dear SangHyuk,
 I would like to know how to measure Throughput and BER by using
 benchmark tx and rx?
 could you show or explain with real example as you used.
 in advance thanks.

 On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller <
 marcus.muel...@ettus.com> wrote:

> Hi,
>
> On 21.03.2016 01 <21.03.2016%2001>:37, SangHyuk Kim wrote:
> > I want to know other user's performance (avg performance).
> Yes, but what is "user's performance"? Is it more important to have
> higher throughput, or lower error rates? What about robustness?
>
> I mean, the OFDM rx_benchmark is a really static example.
> You might find a setting that maximizes troughput for a given channel,
> but imagine something happens that reduces your receiver's SNR by 3dB:
> Now your suddenly losing a lot of performance.
>
> Really "how can I parameterize this" can only be answered for a single,
> mathematically well-defined target, and for a well-defined channel.
>

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Marcus Müller]

I'd encourage you to either fix the Bit Error Rate block or write
something that does your job. In fact, the unmodified ofdm_loopback
example doesn't work as BER test, because all packets are identical, and
if a packet has errors, the OFDM receiver will drop it, so you'd never
see an error.

Open rx_ofdm.grc ; it is a very similar example, but instead of having
the black box "OFDM Receiver", you see how the OFDM receiver internally
works.
Play with the channel model; e.g. set the noise voltage really high
(1.0) and the frequency offset to e.g. 2.0/fft_len. You'll see a lot of

INFO: Detected and invalid packet at item 

printed.
Now, change these parameters.
Your ratio of valid packets and invalid packets gives you a packet error
rate.

Best regards,
Marcus

On 21.03.2016 11:47, Diyar Muhammed wrote:
> Marcus,
> I look at ofdm_loopback.grc example, I made the same scenario but I
> had problem with Error Rate block I got error rate around 4 to 5, as
> my knowledge that is not right I think should be between 0 to 1.
> If there is a transceiver example with measure bit error rate that
> will be helpful for me.
> in advance thank you.
>
> On Mon, Mar 21, 2016 at 10:36 AM, Marcus Müller
> > wrote:
>
> Note that the benchmark_rx/_tx example is really a bit old, and I
> always try to steer people away from it towards the newer OFDM
> examples that are far more flexible and behave a lot more like a
> real system would.
>
> Have a look at the ofdm_loopback.grc example; you can replace the
> (channelmodel->throttle) by a USRP sink and source. Tadah! Live demo.
>
> Best regards,
> Marcus
>
>
> On 21.03.2016 11:34, Diyar Muhammed wrote:
>> many thanks 
>>
>> On Mon, Mar 21, 2016 at 10:31 AM, Marcus Müller
>> > wrote:
>>
>> Diyar,
>>
>> > I look at tx benchmark help I could not find rates but
>> there is packet size and megabytes to transmit.
>>
>> benchmark_tx --help should help you.
>> You set the bandwidth, which sets the sampling rate; together
>> with the occupied tones number related to the FFT length, you
>> get a symbol rate.
>> Together with the modulation you set, this gives you a
>>
>> Since only one program can use a USRP at a time, you can't
>> use benchmark_tx and benchmark_rx at the same time.
>> Instead, use benchmark_tx with the "--to-file" option to save
>> the samples to a file, and build a quick GNU Radio flow graph
>> in GRC that has a file source (reading that file), a USRP
>> sink (fed from the file source), a USRP source, and a file
>> sink (saving the samples from the USRP source to another file).
>>
>> Then use benchmark_rx with the --from-file option to read in
>> these saved samples.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 21.03.2016 11:17, Diyar Muhammed wrote:
>>> Dear Marcus,
>>> Thank you very much indeed for fast replying.
>>> I look at tx benchmark help I could not find rates but there
>>> is packet size and megabytes to transmit.
>>> so that, which one do you mean packet size or megabytes?
>>> it is okay to use USRP B210 for transmitting and receiving
>>> by using to benchmark file?
>>> because when I used one of them (tx or rx) and then I wanted
>>> to run another one the error come up (no device found for
>>> empty device address).
>>> in advance many thanks.
>>>
>>> On Mon, Mar 21, 2016 at 9:57 AM, Marcus Müller
>>> >
>>> wrote:
>>>
>>> Diyar,
>>>
>>> with the benchmark_ scripts, you **set** the rates, and
>>> you can only observe how many packets were successfully
>>> transmitted.
>>> The rest is really very basic math.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 21.03.2016 10:50, Diyar Muhammed wrote:
 Dear SangHyuk,
 I would like to know how to measure Throughput and BER
 by using benchmark tx and rx?
 could you show or explain with real example as you used.
 in advance thanks.

 On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller
 > wrote:

 Hi,

 On 21.03.2016 01 :37, SangHyuk
 Kim wrote:
 > I want to know other user's performance (avg
 performance).
 Yes, but what is "user's performance"? Is it more
 important to have
 

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Diyar Muhammed]

Marcus,
I look at ofdm_loopback.grc example, I made the same scenario but I had
problem with Error Rate block I got error rate around 4 to 5, as my
knowledge that is not right I think should be between 0 to 1.
If there is a transceiver example with measure bit error rate that will be
helpful for me.
in advance thank you.

On Mon, Mar 21, 2016 at 10:36 AM, Marcus Müller 
wrote:

> Note that the benchmark_rx/_tx example is really a bit old, and I always
> try to steer people away from it towards the newer OFDM examples that are
> far more flexible and behave a lot more like a real system would.
>
> Have a look at the ofdm_loopback.grc example; you can replace the
> (channelmodel->throttle) by a USRP sink and source. Tadah! Live demo.
>
> Best regards,
> Marcus
>
>
> On 21.03.2016 11:34, Diyar Muhammed wrote:
>
> many thanks
>
> On Mon, Mar 21, 2016 at 10:31 AM, Marcus Müller 
> wrote:
>
>> Diyar,
>>
>> > I look at tx benchmark help I could not find rates but there is packet
>> size and megabytes to transmit.
>>
>> benchmark_tx --help should help you.
>> You set the bandwidth, which sets the sampling rate; together with the
>> occupied tones number related to the FFT length, you get a symbol rate.
>> Together with the modulation you set, this gives you a
>>
>> Since only one program can use a USRP at a time, you can't use
>> benchmark_tx and benchmark_rx at the same time.
>> Instead, use benchmark_tx with the "--to-file" option to save the samples
>> to a file, and build a quick GNU Radio flow graph in GRC that has a file
>> source (reading that file), a USRP sink (fed from the file source), a USRP
>> source, and a file sink (saving the samples from the USRP source to another
>> file).
>>
>> Then use benchmark_rx with the --from-file option to read in these saved
>> samples.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 21.03.2016 11:17, Diyar Muhammed wrote:
>>
>> Dear Marcus,
>> Thank you very much indeed for fast replying.
>> I look at tx benchmark help I could not find rates but there is packet
>> size and megabytes to transmit.
>> so that, which one do you mean packet size or megabytes?
>> it is okay to use USRP B210 for transmitting and receiving by using to
>> benchmark file?
>> because when I used one of them (tx or rx) and then I wanted to run
>> another one the error come up (no device found for empty device address).
>> in advance many thanks.
>>
>> On Mon, Mar 21, 2016 at 9:57 AM, Marcus Müller <
>> marcus.muel...@ettus.com> wrote:
>>
>>> Diyar,
>>>
>>> with the benchmark_ scripts, you **set** the rates, and you can only
>>> observe how many packets were successfully transmitted.
>>> The rest is really very basic math.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 21.03.2016 10:50, Diyar Muhammed wrote:
>>>
>>> Dear SangHyuk,
>>> I would like to know how to measure Throughput and BER by using
>>> benchmark tx and rx?
>>> could you show or explain with real example as you used.
>>> in advance thanks.
>>>
>>> On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller <
>>> marcus.muel...@ettus.com> wrote:
>>>
 Hi,

 On 21.03.2016 01 <21.03.2016%2001>:37, SangHyuk Kim wrote:
 > I want to know other user's performance (avg performance).
 Yes, but what is "user's performance"? Is it more important to have
 higher throughput, or lower error rates? What about robustness?

 I mean, the OFDM rx_benchmark is a really static example.
 You might find a setting that maximizes troughput for a given channel,
 but imagine something happens that reduces your receiver's SNR by 3dB:
 Now your suddenly losing a lot of performance.

 Really "how can I parameterize this" can only be answered for a single,
 mathematically well-defined target, and for a well-defined channel.

 In a real-world scenario, if using a transceiver with a fixed
 modulation, you usually wouldn't maximize throughput for a given
 setting, but you would define what "it still works sufficiently" means,
 and then you'd define "the worst channel I want the system to still work
 sufficiently".
 Then you'd come up with a metric that gives you a number for "the link
 quality on all considerable channels where this should be working", and
 then you'd try to maximize that metric under the outage constraints set
 before. Notice that this metric has to take things like error rate,
 throughtput, the "cost" of re-sending something (if you have a mechanism
 for that), available channel coding, how much you care about latency,
 computational complexity (that really gets important with iterative
 channel decoding),

 In other words:
 This is digital communications. If there was a single "best" solution,
 we'd all be using that and be done. Use your digital communications
 knowledge to analyze your requirements and challenges!

 Best 

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Marcus Müller]

Note that the benchmark_rx/_tx example is really a bit old, and I always
try to steer people away from it towards the newer OFDM examples that
are far more flexible and behave a lot more like a real system would.

Have a look at the ofdm_loopback.grc example; you can replace the
(channelmodel->throttle) by a USRP sink and source. Tadah! Live demo.

Best regards,
Marcus

On 21.03.2016 11:34, Diyar Muhammed wrote:
> many thanks 
>
> On Mon, Mar 21, 2016 at 10:31 AM, Marcus Müller
> > wrote:
>
> Diyar,
>
> > I look at tx benchmark help I could not find rates but there is
> packet size and megabytes to transmit.
>
> benchmark_tx --help should help you.
> You set the bandwidth, which sets the sampling rate; together with
> the occupied tones number related to the FFT length, you get a
> symbol rate.
> Together with the modulation you set, this gives you a
>
> Since only one program can use a USRP at a time, you can't use
> benchmark_tx and benchmark_rx at the same time.
> Instead, use benchmark_tx with the "--to-file" option to save the
> samples to a file, and build a quick GNU Radio flow graph in GRC
> that has a file source (reading that file), a USRP sink (fed from
> the file source), a USRP source, and a file sink (saving the
> samples from the USRP source to another file).
>
> Then use benchmark_rx with the --from-file option to read in these
> saved samples.
>
> Best regards,
> Marcus
>
>
> On 21.03.2016 11:17, Diyar Muhammed wrote:
>> Dear Marcus,
>> Thank you very much indeed for fast replying.
>> I look at tx benchmark help I could not find rates but there is
>> packet size and megabytes to transmit.
>> so that, which one do you mean packet size or megabytes?
>> it is okay to use USRP B210 for transmitting and receiving by
>> using to benchmark file?
>> because when I used one of them (tx or rx) and then I wanted to
>> run another one the error come up (no device found for empty
>> device address).
>> in advance many thanks.
>>
>> On Mon, Mar 21, 2016 at 9:57 AM, Marcus Müller
>> > wrote:
>>
>> Diyar,
>>
>> with the benchmark_ scripts, you **set** the rates, and you
>> can only observe how many packets were successfully transmitted.
>> The rest is really very basic math.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 21.03.2016 10:50, Diyar Muhammed wrote:
>>> Dear SangHyuk,
>>> I would like to know how to measure Throughput and BER by
>>> using benchmark tx and rx?
>>> could you show or explain with real example as you used.
>>> in advance thanks.
>>>
>>> On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller
>>> >
>>> wrote:
>>>
>>> Hi,
>>>
>>> On 21.03.2016 01 :37, SangHyuk Kim
>>> wrote:
>>> > I want to know other user's performance (avg performance).
>>> Yes, but what is "user's performance"? Is it more
>>> important to have
>>> higher throughput, or lower error rates? What about
>>> robustness?
>>>
>>> I mean, the OFDM rx_benchmark is a really static example.
>>> You might find a setting that maximizes troughput for a
>>> given channel,
>>> but imagine something happens that reduces your
>>> receiver's SNR by 3dB:
>>> Now your suddenly losing a lot of performance.
>>>
>>> Really "how can I parameterize this" can only be
>>> answered for a single,
>>> mathematically well-defined target, and for a
>>> well-defined channel.
>>>
>>> In a real-world scenario, if using a transceiver with a
>>> fixed
>>> modulation, you usually wouldn't maximize throughput for
>>> a given
>>> setting, but you would define what "it still works
>>> sufficiently" means,
>>> and then you'd define "the worst channel I want the
>>> system to still work
>>> sufficiently".
>>> Then you'd come up with a metric that gives you a number
>>> for "the link
>>> quality on all considerable channels where this should
>>> be working", and
>>> then you'd try to maximize that metric under the outage
>>> constraints set
>>> before. Notice that this metric has to take things like
>>> error rate,
>>> throughtput, the "cost" of re-sending something (if you
>>> have a mechanism
>>> for that), available channel coding, how much you care
>>> about latency,

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Diyar Muhammed]

many thanks

On Mon, Mar 21, 2016 at 10:31 AM, Marcus Müller 
wrote:

> Diyar,
>
> > I look at tx benchmark help I could not find rates but there is packet
> size and megabytes to transmit.
>
> benchmark_tx --help should help you.
> You set the bandwidth, which sets the sampling rate; together with the
> occupied tones number related to the FFT length, you get a symbol rate.
> Together with the modulation you set, this gives you a
>
> Since only one program can use a USRP at a time, you can't use
> benchmark_tx and benchmark_rx at the same time.
> Instead, use benchmark_tx with the "--to-file" option to save the samples
> to a file, and build a quick GNU Radio flow graph in GRC that has a file
> source (reading that file), a USRP sink (fed from the file source), a USRP
> source, and a file sink (saving the samples from the USRP source to another
> file).
>
> Then use benchmark_rx with the --from-file option to read in these saved
> samples.
>
> Best regards,
> Marcus
>
>
> On 21.03.2016 11:17, Diyar Muhammed wrote:
>
> Dear Marcus,
> Thank you very much indeed for fast replying.
> I look at tx benchmark help I could not find rates but there is packet
> size and megabytes to transmit.
> so that, which one do you mean packet size or megabytes?
> it is okay to use USRP B210 for transmitting and receiving by using to
> benchmark file?
> because when I used one of them (tx or rx) and then I wanted to run
> another one the error come up (no device found for empty device address).
> in advance many thanks.
>
> On Mon, Mar 21, 2016 at 9:57 AM, Marcus Müller 
> wrote:
>
>> Diyar,
>>
>> with the benchmark_ scripts, you **set** the rates, and you can only
>> observe how many packets were successfully transmitted.
>> The rest is really very basic math.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 21.03.2016 10:50, Diyar Muhammed wrote:
>>
>> Dear SangHyuk,
>> I would like to know how to measure Throughput and BER by using benchmark
>> tx and rx?
>> could you show or explain with real example as you used.
>> in advance thanks.
>>
>> On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller <
>> marcus.muel...@ettus.com> wrote:
>>
>>> Hi,
>>>
>>> On 21.03.2016 01 <21.03.2016%2001>:37, SangHyuk Kim wrote:
>>> > I want to know other user's performance (avg performance).
>>> Yes, but what is "user's performance"? Is it more important to have
>>> higher throughput, or lower error rates? What about robustness?
>>>
>>> I mean, the OFDM rx_benchmark is a really static example.
>>> You might find a setting that maximizes troughput for a given channel,
>>> but imagine something happens that reduces your receiver's SNR by 3dB:
>>> Now your suddenly losing a lot of performance.
>>>
>>> Really "how can I parameterize this" can only be answered for a single,
>>> mathematically well-defined target, and for a well-defined channel.
>>>
>>> In a real-world scenario, if using a transceiver with a fixed
>>> modulation, you usually wouldn't maximize throughput for a given
>>> setting, but you would define what "it still works sufficiently" means,
>>> and then you'd define "the worst channel I want the system to still work
>>> sufficiently".
>>> Then you'd come up with a metric that gives you a number for "the link
>>> quality on all considerable channels where this should be working", and
>>> then you'd try to maximize that metric under the outage constraints set
>>> before. Notice that this metric has to take things like error rate,
>>> throughtput, the "cost" of re-sending something (if you have a mechanism
>>> for that), available channel coding, how much you care about latency,
>>> computational complexity (that really gets important with iterative
>>> channel decoding),
>>>
>>> In other words:
>>> This is digital communications. If there was a single "best" solution,
>>> we'd all be using that and be done. Use your digital communications
>>> knowledge to analyze your requirements and challenges!
>>>
>>> Best regards
>>> Marcus
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>>
>> --
>> Regards,
>> Diyar Muhammed
>> Ministry of Higher Education and Scientific Research
>> Duty: Network Administration and Design
>> Website:   www.mhe-krg.org
>> Cell Phone: 009647504690060
>> Office Phone:   00964662554683
>>
>>
>>
>
>
> --
> Regards,
> Diyar Muhammed
> Ministry of Higher Education and Scientific Research
> Duty: Network Administration and Design
> Website:  www.mhe-krg.org
> Cell Phone: 009647504690060
> Office Phone:   00964662554683
>
>
>


-- 
Regards,
Diyar Muhammed
Ministry of Higher Education and Scientific Research
Duty: Network Administration and Design
Website:  www.mhe-krg.org
Cell Phone: 009647504690060
Office Phone:   00964662554683
___
Discuss-gnuradio 

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Marcus Müller]

Diyar,

> I look at tx benchmark help I could not find rates but there is packet
size and megabytes to transmit.

benchmark_tx --help should help you.
You set the bandwidth, which sets the sampling rate; together with the
occupied tones number related to the FFT length, you get a symbol rate.
Together with the modulation you set, this gives you a

Since only one program can use a USRP at a time, you can't use
benchmark_tx and benchmark_rx at the same time.
Instead, use benchmark_tx with the "--to-file" option to save the
samples to a file, and build a quick GNU Radio flow graph in GRC that
has a file source (reading that file), a USRP sink (fed from the file
source), a USRP source, and a file sink (saving the samples from the
USRP source to another file).

Then use benchmark_rx with the --from-file option to read in these saved
samples.

Best regards,
Marcus

On 21.03.2016 11:17, Diyar Muhammed wrote:
> Dear Marcus,
> Thank you very much indeed for fast replying.
> I look at tx benchmark help I could not find rates but there is packet
> size and megabytes to transmit.
> so that, which one do you mean packet size or megabytes?
> it is okay to use USRP B210 for transmitting and receiving by using to
> benchmark file?
> because when I used one of them (tx or rx) and then I wanted to run
> another one the error come up (no device found for empty device address).
> in advance many thanks.
>
> On Mon, Mar 21, 2016 at 9:57 AM, Marcus Müller
> > wrote:
>
> Diyar,
>
> with the benchmark_ scripts, you **set** the rates, and you can
> only observe how many packets were successfully transmitted.
> The rest is really very basic math.
>
> Best regards,
> Marcus
>
>
> On 21.03.2016 10:50, Diyar Muhammed wrote:
>> Dear SangHyuk,
>> I would like to know how to measure Throughput and BER by using
>> benchmark tx and rx?
>> could you show or explain with real example as you used.
>> in advance thanks.
>>
>> On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller
>> > wrote:
>>
>> Hi,
>>
>> On 21.03.2016 01 :37, SangHyuk Kim wrote:
>> > I want to know other user's performance (avg performance).
>> Yes, but what is "user's performance"? Is it more important
>> to have
>> higher throughput, or lower error rates? What about robustness?
>>
>> I mean, the OFDM rx_benchmark is a really static example.
>> You might find a setting that maximizes troughput for a given
>> channel,
>> but imagine something happens that reduces your receiver's
>> SNR by 3dB:
>> Now your suddenly losing a lot of performance.
>>
>> Really "how can I parameterize this" can only be answered for
>> a single,
>> mathematically well-defined target, and for a well-defined
>> channel.
>>
>> In a real-world scenario, if using a transceiver with a fixed
>> modulation, you usually wouldn't maximize throughput for a given
>> setting, but you would define what "it still works
>> sufficiently" means,
>> and then you'd define "the worst channel I want the system to
>> still work
>> sufficiently".
>> Then you'd come up with a metric that gives you a number for
>> "the link
>> quality on all considerable channels where this should be
>> working", and
>> then you'd try to maximize that metric under the outage
>> constraints set
>> before. Notice that this metric has to take things like error
>> rate,
>> throughtput, the "cost" of re-sending something (if you have
>> a mechanism
>> for that), available channel coding, how much you care about
>> latency,
>> computational complexity (that really gets important with
>> iterative
>> channel decoding),
>>
>> In other words:
>> This is digital communications. If there was a single "best"
>> solution,
>> we'd all be using that and be done. Use your digital
>> communications
>> knowledge to analyze your requirements and challenges!
>>
>> Best regards
>> Marcus
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>>
>> -- 
>> Regards,
>> Diyar Muhammed
>> Ministry of Higher Education and Scientific Research
>> Duty: Network Administration and Design
>> Website:  www.mhe-krg.org 
>> Cell Phone: 009647504690060
>> Office Phone:   00964662554683
>
>
>
>
> -- 
> Regards,
> Diyar Muhammed
> Ministry of Higher Education and Scientific Research
> 

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Diyar Muhammed]

Dear Marcus,
Thank you very much indeed for fast replying.
I look at tx benchmark help I could not find rates but there is packet size
and megabytes to transmit.
so that, which one do you mean packet size or megabytes?
it is okay to use USRP B210 for transmitting and receiving by using to
benchmark file?
because when I used one of them (tx or rx) and then I wanted to run another
one the error come up (no device found for empty device address).
in advance many thanks.

On Mon, Mar 21, 2016 at 9:57 AM, Marcus Müller 
wrote:

> Diyar,
>
> with the benchmark_ scripts, you **set** the rates, and you can only
> observe how many packets were successfully transmitted.
> The rest is really very basic math.
>
> Best regards,
> Marcus
>
>
> On 21.03.2016 10:50, Diyar Muhammed wrote:
>
> Dear SangHyuk,
> I would like to know how to measure Throughput and BER by using benchmark
> tx and rx?
> could you show or explain with real example as you used.
> in advance thanks.
>
> On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller 
> wrote:
>
>> Hi,
>>
>> On 21.03.2016 01:37, SangHyuk Kim wrote:
>> > I want to know other user's performance (avg performance).
>> Yes, but what is "user's performance"? Is it more important to have
>> higher throughput, or lower error rates? What about robustness?
>>
>> I mean, the OFDM rx_benchmark is a really static example.
>> You might find a setting that maximizes troughput for a given channel,
>> but imagine something happens that reduces your receiver's SNR by 3dB:
>> Now your suddenly losing a lot of performance.
>>
>> Really "how can I parameterize this" can only be answered for a single,
>> mathematically well-defined target, and for a well-defined channel.
>>
>> In a real-world scenario, if using a transceiver with a fixed
>> modulation, you usually wouldn't maximize throughput for a given
>> setting, but you would define what "it still works sufficiently" means,
>> and then you'd define "the worst channel I want the system to still work
>> sufficiently".
>> Then you'd come up with a metric that gives you a number for "the link
>> quality on all considerable channels where this should be working", and
>> then you'd try to maximize that metric under the outage constraints set
>> before. Notice that this metric has to take things like error rate,
>> throughtput, the "cost" of re-sending something (if you have a mechanism
>> for that), available channel coding, how much you care about latency,
>> computational complexity (that really gets important with iterative
>> channel decoding),
>>
>> In other words:
>> This is digital communications. If there was a single "best" solution,
>> we'd all be using that and be done. Use your digital communications
>> knowledge to analyze your requirements and challenges!
>>
>> Best regards
>> Marcus
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> --
> Regards,
> Diyar Muhammed
> Ministry of Higher Education and Scientific Research
> Duty: Network Administration and Design
> Website:  www.mhe-krg.org
> Cell Phone: 009647504690060
> Office Phone:   00964662554683
>
>
>


-- 
Regards,
Diyar Muhammed
Ministry of Higher Education and Scientific Research
Duty: Network Administration and Design
Website:  www.mhe-krg.org
Cell Phone: 009647504690060
Office Phone:   00964662554683
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Marcus Müller]

Diyar,

with the benchmark_ scripts, you **set** the rates, and you can only
observe how many packets were successfully transmitted.
The rest is really very basic math.

Best regards,
Marcus

On 21.03.2016 10:50, Diyar Muhammed wrote:
> Dear SangHyuk,
> I would like to know how to measure Throughput and BER by using
> benchmark tx and rx?
> could you show or explain with real example as you used.
> in advance thanks.
>
> On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller
> > wrote:
>
> Hi,
>
> On 21.03.2016 01 :37, SangHyuk Kim wrote:
> > I want to know other user's performance (avg performance).
> Yes, but what is "user's performance"? Is it more important to have
> higher throughput, or lower error rates? What about robustness?
>
> I mean, the OFDM rx_benchmark is a really static example.
> You might find a setting that maximizes troughput for a given channel,
> but imagine something happens that reduces your receiver's SNR by 3dB:
> Now your suddenly losing a lot of performance.
>
> Really "how can I parameterize this" can only be answered for a
> single,
> mathematically well-defined target, and for a well-defined channel.
>
> In a real-world scenario, if using a transceiver with a fixed
> modulation, you usually wouldn't maximize throughput for a given
> setting, but you would define what "it still works sufficiently"
> means,
> and then you'd define "the worst channel I want the system to
> still work
> sufficiently".
> Then you'd come up with a metric that gives you a number for "the link
> quality on all considerable channels where this should be
> working", and
> then you'd try to maximize that metric under the outage
> constraints set
> before. Notice that this metric has to take things like error rate,
> throughtput, the "cost" of re-sending something (if you have a
> mechanism
> for that), available channel coding, how much you care about latency,
> computational complexity (that really gets important with iterative
> channel decoding),
>
> In other words:
> This is digital communications. If there was a single "best" solution,
> we'd all be using that and be done. Use your digital communications
> knowledge to analyze your requirements and challenges!
>
> Best regards
> Marcus
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> -- 
> Regards,
> Diyar Muhammed
> Ministry of Higher Education and Scientific Research
> Duty: Network Administration and Design
> Website:  www.mhe-krg.org 
> Cell Phone: 009647504690060
> Office Phone:   00964662554683

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

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Diyar Muhammed]

Dear SangHyuk,
I would like to know how to measure Throughput and BER by using benchmark
tx and rx?
could you show or explain with real example as you used.
in advance thanks.

On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller 
wrote:

> Hi,
>
> On 21.03.2016 01:37, SangHyuk Kim wrote:
> > I want to know other user's performance (avg performance).
> Yes, but what is "user's performance"? Is it more important to have
> higher throughput, or lower error rates? What about robustness?
>
> I mean, the OFDM rx_benchmark is a really static example.
> You might find a setting that maximizes troughput for a given channel,
> but imagine something happens that reduces your receiver's SNR by 3dB:
> Now your suddenly losing a lot of performance.
>
> Really "how can I parameterize this" can only be answered for a single,
> mathematically well-defined target, and for a well-defined channel.
>
> In a real-world scenario, if using a transceiver with a fixed
> modulation, you usually wouldn't maximize throughput for a given
> setting, but you would define what "it still works sufficiently" means,
> and then you'd define "the worst channel I want the system to still work
> sufficiently".
> Then you'd come up with a metric that gives you a number for "the link
> quality on all considerable channels where this should be working", and
> then you'd try to maximize that metric under the outage constraints set
> before. Notice that this metric has to take things like error rate,
> throughtput, the "cost" of re-sending something (if you have a mechanism
> for that), available channel coding, how much you care about latency,
> computational complexity (that really gets important with iterative
> channel decoding),
>
> In other words:
> This is digital communications. If there was a single "best" solution,
> we'd all be using that and be done. Use your digital communications
> knowledge to analyze your requirements and challenges!
>
> Best regards
> Marcus
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Regards,
Diyar Muhammed
Ministry of Higher Education and Scientific Research
Duty: Network Administration and Design
Website:  www.mhe-krg.org
Cell Phone: 009647504690060
Office Phone:   00964662554683
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Marcus Müller]

Hi,

On 21.03.2016 01:37, SangHyuk Kim wrote:
> I want to know other user's performance (avg performance).
Yes, but what is "user's performance"? Is it more important to have
higher throughput, or lower error rates? What about robustness?

I mean, the OFDM rx_benchmark is a really static example.
You might find a setting that maximizes troughput for a given channel,
but imagine something happens that reduces your receiver's SNR by 3dB:
Now your suddenly losing a lot of performance.

Really "how can I parameterize this" can only be answered for a single,
mathematically well-defined target, and for a well-defined channel.

In a real-world scenario, if using a transceiver with a fixed
modulation, you usually wouldn't maximize throughput for a given
setting, but you would define what "it still works sufficiently" means,
and then you'd define "the worst channel I want the system to still work
sufficiently".
Then you'd come up with a metric that gives you a number for "the link
quality on all considerable channels where this should be working", and
then you'd try to maximize that metric under the outage constraints set
before. Notice that this metric has to take things like error rate,
throughtput, the "cost" of re-sending something (if you have a mechanism
for that), available channel coding, how much you care about latency,
computational complexity (that really gets important with iterative
channel decoding),

In other words:
This is digital communications. If there was a single "best" solution,
we'd all be using that and be done. Use your digital communications
knowledge to analyze your requirements and challenges!

Best regards
Marcus

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

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[SangHyuk Kim]

Hi,

I want to know other user's performance (avg performance).

When I operate ./benchmark_tx.py -f 1.5G -m qpsk -W 250
--fft-length=256 --tx-gain=31.5, it results up to 60Mbps. (USRP N210, CBX
40MHz, ANT500)

I empirically got fine parameters and generally (small fft length, high
bandwidth, high tx-gain, big occupied carriers, high bits per symbol
modulation) show better performance (throughput and BER)

Thanks.


2016-03-21 3:22 GMT+09:00 Marcus Müller :

> Trial and error. It depends on your environment, what you want to test,
> and what you want to achieve.
> Best regards,
> Marcus
>
> On 19.03.2016 14:15, SangHyoeg Kim wrote:
> > Hi, I am using ofdm/benchmark example with USRP N210 and CBX 40Mhz
> daughterboard.
> >
> > I tried to know optimal parameter(bandwidth, fft length, occupied tones,
> packet size) for maximum throughput and minimum error rates.
> >
> > How can I reach maximum throughput by adjusting parameter or modifying
> code ?
> >
> > Thanks.
> > ___
> > 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] OFDM benchmark optimal parameter

[Marcus Müller]

Trial and error. It depends on your environment, what you want to test,
and what you want to achieve.
Best regards,
Marcus

On 19.03.2016 14:15, SangHyoeg Kim wrote:
> Hi, I am using ofdm/benchmark example with USRP N210 and CBX 40Mhz 
> daughterboard. 
>
> I tried to know optimal parameter(bandwidth, fft length, occupied tones, 
> packet size) for maximum throughput and minimum error rates. 
>
> How can I reach maximum throughput by adjusting parameter or modifying code ?
>
> Thanks. 
> ___
> 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] OFDM Training Sequence

[Martin Braun]

Mateusz,

the sync words are both for the Schmidl & Cox synchronization. Also,
they're defined in the frequency domain, so you won't see the 'two
identical parts here'. Rather, you skip every 2nd carrier.

Cheers,
Martin

On 03/17/2016 04:47 AM, Mateusz wrote:
> Hey, I do my Bachelor Thesis on OFDM using GnuRadio.
> 
> I am using the joint system created from tx_ofdm and rx_ofdm examples.
> In simulation I try to use a bigger fft. So far I have managed to send
> and receive for fft_len=128 and fft_len=256, BPSK modulation. I ask to
> help me understand the creation of sync_words for bigger fft.
> 
> I see the influence of the training sequences which I use on the quality
> of transmission. Of course I have read that the synchronization is based
> on "PN Sequence Correlation" and "Maximal Likelihood" papers. I suppose
> that sync_word1 and sync_word2 are based on those algorithms
> respectively. However I don't see "two identical parts of PN sequence"
> like it was described in the Schmidl paper.
> 
> I tried to use the sequences containing 0's where needed, and random
> -1's and 1's elsewhere, but then the timing synchronization error
> (missing trigger signal in sync_sc) occurs more often, than when I use
> the replicas of original sync_words from the OFDM example.
> 
> I attach the file with the training sequences which I have used.
> 
> Regards,
> Mateusz Loch
> 
> 
> ___
> 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 tx rx error

[Jingyi Sun]

Hi,

I'm using the examples rx_ofdm.grc and tx_ofdm.grc together to transmit and
receive packets over the air.  Both work over a simulated channel, but when
I actually transmit and receive over the air, I get the error:

*"Detected a packet larger than max frame size (100 symbols)"*

I saw the previous thread on this called "OFDM transmitter receiver" which
goes as follows, but I don't really know what to make of this...

I tried to run *sysctl kernel.shmmax *in terminal, but I got the message
"No such file or directory". I'm also not sure what kernel.shmmax is.

These are my parameters:

fft length= 64

cyclic prefix = 16
packet length = 96
no. of occupied carriers = 53
no. of pilot carriers = 4


I'm very new to gnuradio, and any insights into this would be appreciated!!


Thanks,
Jenny

PS sorry if this is redundant. I didn't get my email through the list so
I'm assuming it didn't go through the first time.
--

*From*:  Martin Braun
*Subject*:  Re: [Discuss-gnuradio] OFDM transmitter receiver
*Date*:  Tue, 26 Aug 2014 11:10:53 +0200
*User-agent*:  Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Thunderbird/24.6.0
--

Try and not kill the context in a mailing list thread; these are also
archived and are used by others for referral.

Max frame size depends on max_output_buffer(). 80 symbols at a 64-sized
FFT would be ~40kB... that doesn't seem unreasonable. Not sure if
there's a problem here. I suggest you have a look at the buffer sizes to
track down this problem.

M

On 08/25/2014 03:31 PM, Martin Braun wrote:
>* What's your kernel.shmmax value? (run sysctl kernel.shmmax)*
>
>* M*
>
>* On 08/25/2014 12:47 PM, sreena p h wrote:*
>*> Hi*
>*> I used the ofdm transmitter receiver blocks to create a simple system as*
>*> shown in the attachment. I used the system parameters as those used in*
>*> the example transmitter and receiver grcs. Now I get error that*
>*> 'Detected a packet larger than max frame size (80 symbols)'. I would*
>*> like to know how the max frame size is set and should I add more*
>*> information to the grc. *
>*>*
>*> My transmitter- receiver parameters*
>*>*
>*> fft length= 64*
>*> cyclic prefix = 16*
>*> packet length = 96*
>*> no. of occupied carriers = 48*
>*> no. of pilot carriers = 4*
>*>*
>*>*
>*>*
>*> ___*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OFDM tx rx error

[Jingyi Sun]

Hi,

I'm using the examples rx_ofdm.grc and tx_ofdm.grc together to transmit and
receive packets over the air.  Both work over a simulated channel, but when
I actually transmit and receive over the air, I get the error:

*"Detected a packet larger than max frame size (100 symbols)"*

I saw the previous thread on this called "OFDM transmitter receiver" which
goes as follows, but I don't really know what to make of this...

I tried to run *sysctl kernel.shmmax *in terminal, but I got the message
"No such file or directory". I'm also not sure what kernel.shmmax is.

These are my parameters:

fft length= 64

cyclic prefix = 16
packet length = 96
no. of occupied carriers = 53
no. of pilot carriers = 4


I'm very new to gnuradio, and any insights into this would be appreciated!!


Thanks,
Jenny

--

*From*:  Martin Braun
*Subject*:  Re: [Discuss-gnuradio] OFDM transmitter receiver
*Date*:  Tue, 26 Aug 2014 11:10:53 +0200
*User-agent*:  Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Thunderbird/24.6.0
--

Try and not kill the context in a mailing list thread; these are also
archived and are used by others for referral.

Max frame size depends on max_output_buffer(). 80 symbols at a 64-sized
FFT would be ~40kB... that doesn't seem unreasonable. Not sure if
there's a problem here. I suggest you have a look at the buffer sizes to
track down this problem.

M

On 08/25/2014 03:31 PM, Martin Braun wrote:
>* What's your kernel.shmmax value? (run sysctl kernel.shmmax)*
>
>* M*
>
>* On 08/25/2014 12:47 PM, sreena p h wrote:*
>*> Hi*
>*> I used the ofdm transmitter receiver blocks to create a simple system as*
>*> shown in the attachment. I used the system parameters as those used in*
>*> the example transmitter and receiver grcs. Now I get error that*
>*> 'Detected a packet larger than max frame size (80 symbols)'. I would*
>*> like to know how the max frame size is set and should I add more*
>*> information to the grc. *
>*>*
>*> My transmitter- receiver parameters*
>*>*
>*> fft length= 64*
>*> cyclic prefix = 16*
>*> packet length = 96*
>*> no. of occupied carriers = 48*
>*> no. of pilot carriers = 4*
>*>*
>*>*
>*>*
>*> ___*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OFDM benchmark optimal parameter

[SangHyoeg Kim]

Hi, I am using ofdm/benchmark example with USRP N210 and CBX 40Mhz 
daughterboard. 

I tried to know optimal parameter(bandwidth, fft length, occupied tones, packet 
size) for maximum throughput and minimum error rates. 

How can I reach maximum throughput by adjusting parameter or modifying code ?

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

[Discuss-gnuradio] OFDM Training Sequence

[Mateusz]

Hey, I do my Bachelor Thesis on OFDM using GnuRadio.

I am using the joint system created from tx_ofdm and rx_ofdm examples. 
In simulation I try to use a bigger fft. So far I have managed to send 
and receive for fft_len=128 and fft_len=256, BPSK modulation. I ask to 
help me understand the creation of sync_words for bigger fft.


I see the influence of the training sequences which I use on the quality 
of transmission. Of course I have read that the synchronization is based 
on "PN Sequence Correlation" and "Maximal Likelihood" papers. I suppose 
that sync_word1 and sync_word2 are based on those algorithms 
respectively. However I don't see "two identical parts of PN sequence" 
like it was described in the Schmidl paper.


I tried to use the sequences containing 0's where needed, and random 
-1's and 1's elsewhere, but then the timing synchronization error 
(missing trigger signal in sync_sc) occurs more often, than when I use 
the replicas of original sync_words from the OFDM example.


I attach the file with the training sequences which I have used.

Regards,
Mateusz Loch
--sync word1 64-- (from tx_ofdm example), 6x0., 13x(0.,scaled_rand), 6x0.
[0., 0., 0., 0., 0., 0., 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 
-1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 
0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 
-1.41421356, 
0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 
1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 
0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 0., 0., 
0., 0., 0.]

--sync word2-- (from tx_ofdm example), 64 6x0, 26x(rand+0j), 1x0, 26xrand, 5x0
[0j, 0j, 0j, 0j, 0j, 0j, (-1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), (1+0j), 
(-1+0j), (-1+0j), (-1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), (1 +0j), (1+0j), 
(1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), (-1+0j), (-1+0j), 
(1+0j), (-1+0j), 0j, (1+0j), (-1+0j), (1+0j), (1+0j), (1+0j), (-1+0j), (1+0j), 
(1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), (1+0j), (1+0j), (-1+0j), (1+0j), 
(-1+0j), (-1+0j), (-1+0j), (1+0j), (-1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), 
(-1+0j), 0j, 0j, 0j, 0j, 0j]

--sync word1 128--  recreated from sync64, 12x0, 26x(0.+scaled_rand), 12x0 
[0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 
0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 
-1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 
0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 
-1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 
0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 
-1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 
0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 
1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 
0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 
1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 
0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 
1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 
0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 
0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.]

--sync word2 128-- recreated from sync64, 12x0, 52x(rand+0j), 1x0, 52xrand, 11x0
[0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j, 
(-1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), (1+0j), 
(-1+0j), (-1+0j), (-1+0j), (1+0j), (-1+0j), (-1+0j), (1+0j), (1+0j), 
(-1+0j), (-1+0j), (-1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), (1 +0j), 
(1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), (1+0j), (1 +0j), 
(1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), 
(-1+0j), (-1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), 
(-1+0j), (-1+0j), (1+0j), (-1+0j), 0j, (1+0j), (-1+0j), (1+0j), (1+0j), 
(1+0j), (-1+0j), (1+0j), (1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), 
(1+0j), (-1+0j), (1+0j), (1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), 
(1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), (-1+0j), (1+0j), (1+0j), 
(1+0j), (1+0j), (-1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), 
(-1+0j), (1+0j), (-1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (1+0j), 
(-1+0j), (1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j), (-1+0j),
 0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j, 0j]

--sync word1 256-- recreated from sync64, 24x0, 52x(0., scaled_rand), 24x0
[0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 
0., 0., 0., 0., 0.,
0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 
0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 
1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356,  
0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356,  0., 
-1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 
0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 
-1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 

Re: [Discuss-gnuradio] OFDM with noise - lost packets

[Martin Braun]

I need to check the loopback flowgraph you mentioned, but the header
detection should work down to very low Eb/N0 values.

However, you mention a noise amplitude of 1.5. IIRC, that would yield an
SNR below 0 dB, not 13 dB as you mention.

Cheers,
Martin


On 19.12.2015 17:41, Mateusz wrote:
> Hello, I have been evaluating the OFDM examples (at the beginning of my
> Bachelor Thesis)
> In ofdm_rx I have added noise source and file sinks to plot BER(SNR) in
> matlab. I added a Tag Debug on the output.
> The result is disappointing, I observe plenty of lost packets already at
> the SNR of about 13dB and below (noise amplitude about 1.5 in an
> unmodified ofdm_rx).
> So are those examples useful, with such a performance, to utilize with
> USRP and antennas?
> Which part of a synchronization process fails, that causes missing
> indexes of data packets (observed in a Tag Debug) in a noisy channel)?
> I think it's at the loop of 'header recognition', so it's the 'coarse
> frequency offset' that is too big for 'channel estimator'.
> 
> I mainly want to know if it's only possible to use ofdm_rx with a low
> noise, with SNR over about 13 dB.
> 
> Mateusz Loch
> 
> ___
> 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 with noise - lost packets

[Mateusz]

Hello, I have been evaluating the OFDM examples (at the beginning of my 
Bachelor Thesis)
In ofdm_rx I have added noise source and file sinks to plot BER(SNR) in 
matlab. I added a Tag Debug on the output.
The result is disappointing, I observe plenty of lost packets already at 
the SNR of about 13dB and below (noise amplitude about 1.5 in an 
unmodified ofdm_rx).
So are those examples useful, with such a performance, to utilize with 
USRP and antennas?
Which part of a synchronization process fails, that causes missing 
indexes of data packets (observed in a Tag Debug) in a noisy channel)?
I think it's at the loop of 'header recognition', so it's the 'coarse 
frequency offset' that is too big for 'channel estimator'.


I mainly want to know if it's only possible to use ofdm_rx with a low 
noise, with SNR over about 13 dB.


Mateusz Loch

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

Re: [Discuss-gnuradio] ofdm demod could not demodulate

[Marcus Müller]

Hi Gnoob16,

it would be interesting to see your actual OFDM demodulator flowgraph,
as well as the spectrum you see on the Qt frequency sink in your picture.
However, the fact that the OFDM demod doesn't output anything usually
simply means that it doesn't detect any packets coming in; are you sure
your RF sink/source's settings are correct? A ~4MHz sampling rate with a
2kHz RF bandwidth doesn't seem to make too much sense to me :)

Best regards,
Marcus

On 19.09.2015 11:26, gnoob16 wrote:
>  
>
> hi this is my ofdm transmitter... the thing here is that the ofdm signal
> could not get demodulated at all... the qt frequency sink displays nothing
> when connected after the ofdm demodulator...
>
> im using zedboard with the adi fmcomms...
>
> thanks!
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/ofdm-demod-could-not-demodulate-tp56156.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] ofdm demod could not demodulate

[gnoob16]

 

hi this is my ofdm transmitter... the thing here is that the ofdm signal
could not get demodulated at all... the qt frequency sink displays nothing
when connected after the ofdm demodulator...

im using zedboard with the adi fmcomms...

thanks!



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/ofdm-demod-could-not-demodulate-tp56156.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] ofdm plateau_detector_fb_impl//ofdm_sync_sc_cfb_impl

[zs]

Hi all,
   I have a question on the synchronization of ofdm example,namely the 
sch source code.
   
   The plateau_detector_fb_impl.cc can find the plateau,and then 
header_payload_demux_impl can find the head data.
STEP 1: plateau_detector_fb_impl find the plateau.
flank_start = i;
  while(i < noutput_items && in[i] >= d_threshold)
i++;
  if((i - flank_start) > 1) { // 1 Sample is not a plateau
out[flank_start + (i-flank_start)/2] = 1;
i = std::min(i+d_max_len, noutput_items-1);
  }
STEP 2:header_payload_demux_impl can find the head data
case STATE_HEADER:
  if (check_items_available(d_header_len, ninput_items, 
noutput_items, nread)) {
copy_n_symbols(in, out_header, PORT_HEADER, d_header_len);
  STEP  3:
 memcpy((void *) out, (void *) (in + d_gi * d_itemsize), 
d_items_per_symbol * d_itemsize);


I think may be the code have some errors.For example,the data is
cdef+abcdef,the cyclic prefix is cdef,and the data is abcdef.
According step1,the output will ouput 001000.Because the sch will 
output a plateau in the cyclic prefix,namely the index corresponding to the 
cdefa will be the plateau.The source code output 1 in the middle.Namely the 
index corresponding to the middle "e" output 1.
   According to the step 2 and step3, we copy the d_items_per_symbol * 
d_itemsize bytes after (in + d_gi * d_itemsize) to the output.In the example, 
cdef+abcdef,the d_gi is 4. (in + d_gi * d_itemsize) will correspond to the 
c.Then output d_items_per_symbol is 6,then output cdef..But the true head data 
is abcdef,so I think maybe the source code have some problems.Is my 
understanding right?
Thank you.
Best regards,
zswx
 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ofdm plateau_detector_fb_impl//ofdm_sync_sc_cfb_impl

[Martin Braun]

On 31.08.2015 07:15, zs wrote:
>According to the step 2 and step3, we copy the
> d_items_per_symbol * d_itemsize bytes after (in + d_gi * d_itemsize) to
> the output.In the example, cdef+abcdef,the d_gi is 4. (in + d_gi *
> d_itemsize) will correspond to the c.Then output d_items_per_symbol is
> 6,then output cdef..But the true head data is abcdef,so I think maybe
> the source code have some problems.Is my understanding right?

Not sure I'm understanding you correctly, but maybe these factoids help you:

- If you check out ofdm_rx.grc, you'll see a couple of delays that try
and align things.
- The qa_ofdm_*.py files check the OFDM stuff pretty exhaustively, and
you might be interested in qa_ofdm_sync_sc_cfb.py in particular.
- If we start copying at the first 'e' in your example, the receiver
will still work fine (minus a phase offset).

Cheers,
Martin

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

Re: [Discuss-gnuradio] ofdm mod error

[Patrcia Wonder]

I'm using ZedBoard by ADI as my dev board and this is their instructions 
for installing everything...

http://wiki.analog.com/resources/tools-software/linux-software/zynq_images

I did everything in here...

It seems everything about the OFDM blocks have similar problem...

-- 
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] ofdm mod error

[nick_meynen]

Marcus,

I just saw i was still running a 32 bit installation of linux.  I just removed 
my old installation and busy reinstalling a fresh Ubuntu 14.04 LTS.

What instalation way is best?  Installing by the sudo apt-get install command 
or just build my own version?

best regards,

Nick

- Oorspronkelijk bericht -
Van: Marcus Müller marcus.muel...@ettus.com
Aan: discuss-gnuradio@gnu.org
Verzonden: Maandag 24 augustus 2015 16:59:13
Onderwerp: Re: [Discuss-gnuradio] ofdm mod error

The point is that what you're seeing is clearly a Python telling you
that it can't find the crc32_bb module nor the constellation_psk object
where they should be, on a proper installation of GNU Radio.
This is not a problem of these examples, but of your installation; as
Martin hinted, we need to solve that first.

Best regards,
Marcus

On 08/24/2015 07:44 AM, Patrcia Wonder wrote:
 I'm using ZedBoard by ADI as my dev board and this is their instructions 
 for installing everything...

 http://wiki.analog.com/resources/tools-software/linux-software/zynq_images

 I did everything in here...

 It seems everything about the OFDM blocks have similar problem...



___
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] ofdm mod error

[Marcus Müller]

The point is that what you're seeing is clearly a Python telling you
that it can't find the crc32_bb module nor the constellation_psk object
where they should be, on a proper installation of GNU Radio.
This is not a problem of these examples, but of your installation; as
Martin hinted, we need to solve that first.

Best regards,
Marcus

On 08/24/2015 07:44 AM, Patrcia Wonder wrote:
 I'm using ZedBoard by ADI as my dev board and this is their instructions 
 for installing everything...

 http://wiki.analog.com/resources/tools-software/linux-software/zynq_images

 I did everything in here...

 It seems everything about the OFDM blocks have similar problem...



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

Re: [Discuss-gnuradio] ofdm mod error

[Martin Braun]

Patrcia,

this looks more like you don't have GNU Radio properly installed --
these examples will work fine with a full installation of GNU Radio.

Cheers,
Martin

On 19.08.2015 23:43, Patrcia Wonder wrote:
 Hi! I think I'm using the latest OFDM blocks. I then  tried using the 
 ofdm_loopback.grc and an error occured that is similar to the first 
 one...
 
 Showing: /home/analog/Documents/ofdm_loopback.grc
 
 Generating: /home/analog/Documents/ofdm_loopback_example.py
 
 Executing: /home/analog/Documents/ofdm_loopback_example.py
 
 Fontconfig warning: ignoring C.UTF-8: not a valid language tag
 Using Volk machine: neon_hardfp
 Traceback (most recent call last):
   File /home/analog/Documents/ofdm_loopback_example.py, line 290, in 
 module
 tb = ofdm_loopback_example()
   File /home/analog/Documents/ofdm_loopback_example.py, line 186, in 
 __init__
 scramble_bits=False
   File /usr/lib/python2.7/dist-packages/gnuradio/digital/ofdm_txrx.py, 
 line 187, in __init__
 crc = digital.crc32_bb(False, self.packet_length_tag_key)
 AttributeError: 'module' object has no attribute 'crc32_bb'
 
 Done
 


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

Re: [Discuss-gnuradio] ofdm mod error

[Patrcia Wonder]

Hi! I think I'm using the latest OFDM blocks. I then  tried using the 
ofdm_loopback.grc and an error occured that is similar to the first 
one...

Showing: /home/analog/Documents/ofdm_loopback.grc

Generating: /home/analog/Documents/ofdm_loopback_example.py

Executing: /home/analog/Documents/ofdm_loopback_example.py

Fontconfig warning: ignoring C.UTF-8: not a valid language tag
Using Volk machine: neon_hardfp
Traceback (most recent call last):
  File /home/analog/Documents/ofdm_loopback_example.py, line 290, in 
module
tb = ofdm_loopback_example()
  File /home/analog/Documents/ofdm_loopback_example.py, line 186, in 
__init__
scramble_bits=False
  File /usr/lib/python2.7/dist-packages/gnuradio/digital/ofdm_txrx.py, 
line 187, in __init__
crc = digital.crc32_bb(False, self.packet_length_tag_key)
AttributeError: 'module' object has no attribute 'crc32_bb'

 Done

-- 
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] ofdm mod error

[Patrcia Wonder]

i've noticed that the digital_swig causes some error for both... looking 
at it, there is nothing inside the digital_swig.py file... is that ok?

-- 
Posted via http://www.ruby-forum.com/.

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

[Discuss-gnuradio] ofdm mod error

[Patrcia Wonder]

Hi! I'm using gnuradio on ZedBoard and was trying a simple OFDM Mod
system just like in this video
https://www.youtube.com/watch?v=LZDWfnrxo6c

the flowgraph just looks like this... random sourceshort to floatofdm
modthrottlewx gui fft sink

and this comes up...

Generating: /home/analog/Documents/top_block.py

Executing: /home/analog/Documents/top_block.py

Fontconfig warning: ignoring C.UTF-8: not a valid language tag
Using Volk machine: neon_hardfp
Traceback (most recent call last):
  File /home/analog/Documents/top_block.py, line 101, in module
tb = top_block()
  File /home/analog/Documents/top_block.py, line 62, in __init__
verbose=None,
  File /usr/lib/python2.7/dist-packages/gnuradio/digital/ofdm.py, line
95, in __init__
constel = psk.psk_constellation(arity)
  File /usr/lib/python2.7/dist-packages/gnuradio/digital/psk.py, line
77, in psk_constellation
constellation = digital_swig.constellation_psk(points,
pre_diff_code, m)
AttributeError: 'module' object has no attribute 'constellation_psk'

 Done

I have no idea what to do next...

THANKS! :)

-- 
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] ofdm mod error

[Martin Braun]

Patrcia,

try the new OFDM blocks. I suggest starting with the example
ofdm_loopback.grc and working from there to see how things work,

Cheers,
Martin

On 17.08.2015 22:39, Patrcia Wonder wrote:
 Hi! I'm using gnuradio on ZedBoard and was trying a simple OFDM Mod
 system just like in this video
 https://www.youtube.com/watch?v=LZDWfnrxo6c
 
 the flowgraph just looks like this... random sourceshort to floatofdm
 modthrottlewx gui fft sink
 
 and this comes up...
 
 Generating: /home/analog/Documents/top_block.py
 
 Executing: /home/analog/Documents/top_block.py
 
 Fontconfig warning: ignoring C.UTF-8: not a valid language tag
 Using Volk machine: neon_hardfp
 Traceback (most recent call last):
   File /home/analog/Documents/top_block.py, line 101, in module
 tb = top_block()
   File /home/analog/Documents/top_block.py, line 62, in __init__
 verbose=None,
   File /usr/lib/python2.7/dist-packages/gnuradio/digital/ofdm.py, line
 95, in __init__
 constel = psk.psk_constellation(arity)
   File /usr/lib/python2.7/dist-packages/gnuradio/digital/psk.py, line
 77, in psk_constellation
 constellation = digital_swig.constellation_psk(points,
 pre_diff_code, m)
 AttributeError: 'module' object has no attribute 'constellation_psk'
 
 Done
 
 I have no idea what to do next...
 
 THANKS! :)
 


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

[Discuss-gnuradio] OFDM and FEC combined

[Davi Brilhante]

I am working with the OFDM and FEC blocks combined in the same flowgraph,
but this configuration led to some issues and I am not being able to sort
this out.

I am using the OFDM Transmitter and Receiver Hier Blocks and FEC Encoder
and Decoder, but I already used FEC Extended Decoder/Encoder with
convolutional and dummy variables. With the following parameters:

OFDM:
* FFT Length: 64
* CP Lenght: 16
* Packet Length: 96

FEC (Repetition)
* Frame Bits: 2048
* Repetitions: 2
* a prior prob: 500m

I have made individual tests using this configuration and each block works
perfectly fine. But apparently there is a bug with their integration

Then, I created file sinks in the flowgraph for debugging: One just after
the encoder, to show me how the repetition encoder works and if it's
working properly; other after the receiver, to look into the packet after
all OFDM process.

The file after reception lost part of the packets, thus, I believe it means
that they are being dropped somewhere between transmission and reception.

 For example:

If I am transmitting: A B C\nD E F\nG H I\n
I am receiving: A B C\nG H I\nD E F\nG H I\nA B C\n, i.e. one packet with
D E F\n and other with A B C\n were dropped or lost along the way.

After searching for this type of problem, I found something about
Header/Payload
Demuxer.

Best Regards,

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

Re: [Discuss-gnuradio] OFDM example from gr-digital with UHD

[Martin Braun]

On 22.07.2015 16:49, Jose Perez wrote:
 Thanks again Marcus.
 
 Now I am using the Head block... I don't know which number I have to put
 in Num Items to get out my file with no repeated information. 
 I can understand this number to a Sin/Cosine function or a random source
 that I can limit how many samples I want ... but for a file I don't know and
 how calculate this number.
 Can you help me with this?

Jose,

I suggest you start a new thread for other, specific questions. Also,
you seem to be struggling with some of the basics, may I suggest you
take a look at our guided tutorials:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials

Cheers,
Martin


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

Re: [Discuss-gnuradio] OFDM example from gr-digital with UHD

[Marcus Müller]

Jose,

If you set your file source to repeat it will produce an infinite 
amount of samples, just like a sine would.
If you know you want to produce 10,000 packets (and see how many are 
received), you only need to 96*10,000 samples.
Hence, you'll use the head block after the file source and set it to 
960,000.


Best regards,
Marcus

On 23.07.2015 01:49, Jose Perez wrote:

Thanks again Marcus.

Now I am using the Head block... I don't know which number I have to put
in Num Items to get out my file with no repeated information.
I can understand this number to a Sin/Cosine function or a random source
that I can limit how many samples I want ... but for a file I don't know and
how calculate this number.
Can you help me with this?

My size's file: 120 bytes ; packet length: 96

Thanks so much

Cheers,
José

On 16.07.2015 18:52, Marcus Müller-3 wrote:


As I mentioned, use the head block.
BR,
Marcus



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/OFDM-example-from-gr-digital-with-UHD-tp54446p54974.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

Re: [Discuss-gnuradio] OFDM example from gr-digital with UHD

[Marcus Müller]

Jose,

If you set your file source to repeat it will produce an infinite 
amount of samples, just like a sine would.
If you know you want to produce 10,000 packets (and see how many are 
received), you only need to 96*10,000 samples.
Hence, you'll use the head block after the file source and set it to 
960,000.


Best regards,
Marcus

On 23.07.2015 01:49, Jose Perez wrote:

Thanks again Marcus.

Now I am using the Head block... I don't know which number I have to put
in Num Items to get out my file with no repeated information.
I can understand this number to a Sin/Cosine function or a random source
that I can limit how many samples I want ... but for a file I don't know and
how calculate this number.
Can you help me with this?

My size's file: 120 bytes ; packet length: 96

Thanks so much

Cheers,
José

On 16.07.2015 18:52, Marcus Müller-3 wrote:


As I mentioned, use the head block.
BR,
Marcus



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/OFDM-example-from-gr-digital-with-UHD-tp54446p54974.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

Re: [Discuss-gnuradio] OFDM example from gr-digital with UHD

[Jose Perez]

Thanks again Marcus.

Now I am using the Head block... I don't know which number I have to put
in Num Items to get out my file with no repeated information. 
I can understand this number to a Sin/Cosine function or a random source
that I can limit how many samples I want ... but for a file I don't know and
how calculate this number.
Can you help me with this?

My size's file: 120 bytes ; packet length: 96

Thanks so much

Cheers,
José

On 16.07.2015 18:52, Marcus Müller-3 wrote: 

As I mentioned, use the head block.
BR,
Marcus 



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/OFDM-example-from-gr-digital-with-UHD-tp54446p54974.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] OFDM channel Estimation Block

[monika bansal]

Hiii

I did following :

build% make
build% make test
gr-digital% gr-modtool makexml ofdm_chanestMMSE_vcvc
build% make install
 everything seemed successful but WHEN opening GRC one block pop ups with :

  Cannot import gnuradio.

Is the python path environment variable set correctly?
All OS: PYTHONPATH

Is the library path environment variable set correctly?
Linux: LD_LIBRARY_PATH
Windows: PATH
MacOSX: DYLD_LIBRARY_PATH 

What happened ? Previously it was running... please help..

On Mon, Jul 20, 2015 at 6:56 PM, Marcus Müller marcus.muel...@ettus.com
wrote:

 Probably you're in gnuradio/gr-digital instead of gnuradio/build.

 Best regards,
 Marcus


 Am 20. Juli 2015 12:12:20 MESZ, schrieb monika bansal 
 monika19...@gmail.com:

 Hiii

 The previous problem is solved. Now after

 gr-digital % make -j4

 It is saying :
 make: *** No targets specified and no makefile found.  Stop.

 But Configuring and Generating is done.

 What should i do ?



 On Mon, Jul 20, 2015 at 3:21 PM, Marcus Müller marcus.muel...@ettus.com
 wrote:

  Monika,

 obviously, there's a mistake in gr-digital/lib/CMakeLists.txt, line 189.
 A little more trying to solve this yourself might probably help you find
 the typo; we can't tell you what you've changed, so we can't help you :)

 Best regards,
 Marcus


 On 20.07.2015 11:29, monika bansal wrote:

  Hii

  After the command :
 gnuradio % cmake ..

  Configuring for all other blocks except gr-digital is completed. I am
 posting the output for gr-digital only :

 -- Configuring gr-digital support...
 --   Dependency Boost_FOUND = 1
 --   Dependency ENABLE_VOLK = ON
 --   Dependency ENABLE_GNURADIO_RUNTIME = ON
 --   Dependency ENABLE_GR_FFT = ON
 --   Dependency ENABLE_GR_FILTER = ON
 --   Dependency ENABLE_GR_BLOCKS = ON
 --   Dependency ENABLE_GR_ANALOG = ON
 --   Dependency ENABLE_GR_BLOCKS = ON
 --   Dependency ENABLE_GR_FILTER = ON
 --   Enabling gr-digital support.
 --   Override with -DENABLE_GR_DIGITAL=ON/OFF
 CMake Error: Error in cmake code at

 /home/spclab/Desktop/Monika/GNURADIO/gnuradio-3.7.5.1/gr-digital/lib/CMakeLists.txt:189:
 Parse error.  Expected a command name, got unquoted argument with text
 ${CMAKE_CURRENT_SOURCE_DIR}/qa_ofdm_chanestMMSE_vcvc.cc.

 Configuring incomplete, errors occurred!

  What should i do ?

 On Mon, Jul 20, 2015 at 2:39 PM, Marcus Müller marcus.muel...@ettus.com
  wrote:

  Hi Monika,

 In-Tree components (like gr-digital) are meant to be built within the
 whole GNU Radio tree, so you don't make a build/ directory under
 gr-digital, but under gnuradio:

 gr-digital % cd ..
 gnuradio % mkdir build
 gnuradio % cd build
 gnuradio % cmake ..
 gr-digital % make -j4

 this will build all GNU Radio. You could selectively only build
 gr-digital, but you will probably want to install a complete GNU Radio, so
 that doesn't really help you much.

 Best regards,
 Marcus



 On 20.07.2015 10:58, monika bansal wrote:

   Hii

 After the following command :

 gr-digital % gr_modtool add -t general ofdm_chanestMMSE_vcvc


 and editing the files:  include/.h , lib/.h , lib/.cc and 
 python/digital/qa_ofdm_chanest_vcvc.py


 I run the command
 gr-digital % mkdir build

 gr-digital % cmake ../


 It giving the following output :

 -- The C compiler identification is GNU 4.8.2
 -- The CXX compiler identification is GNU 4.8.2
 -- Check for working C compiler: /usr/bin/cc
 -- Check for working C compiler: /usr/bin/cc -- works
 -- Detecting C compiler ABI info
 -- Detecting C compiler ABI info - done
 -- Check for working CXX compiler: /usr/bin/c++
 -- Check for working CXX compiler: /usr/bin/c++ -- works
 -- Detecting CXX compiler ABI info
 -- Detecting CXX compiler ABI info - done
 CMake Error at CMakeLists.txt:23 (include):
   include could not find load file:

 GrBoost


 CMake Error at CMakeLists.txt:28 (include):
   include could not find load file:

 GrComponent


 CMake Error at CMakeLists.txt:29 (GR_REGISTER_COMPONENT):
   Unknown CMake command GR_REGISTER_COMPONENT.


 CMake Warning (dev) in CMakeLists.txt:
   No cmake_minimum_required command is present.  A line of code such as

 cmake_minimum_required(VERSION 2.8)

   should be added at the top of the file.  The version specified may be 
 lower
   if you wish to support older CMake versions for this project.  For more
   information run cmake --help-policy CMP.
 This warning is for project developers.  Use -Wno-dev to suppress it.

 -- Configuring incomplete, errors occurred!
 See also 
 /home/spclab/Desktop/Monika/GNURADIO/gnuradio-3.7.5.1/gr-digital/build/CMakeFiles/CMakeOutput.log.



 What should i do ? have i done something wrong ?


  On Sat, Jul 18, 2015 at 11:37 AM, monika bansal 
 monika19...@gmail.commonika19...@gmail.com wrote:

 yes... i will.

  On Fri, Jul 17, 2015 at 9:48 PM, Martin Braun 
 martin.br...@ettus.commartin.br...@ettus.com wrote:

  Monika,

 please make sure you've gone through the tutorials at
 

Re: [Discuss-gnuradio] OFDM channel Estimation Block

[monika bansal]

yes... i will.

On Fri, Jul 17, 2015 at 9:48 PM, Martin Braun martin.br...@ettus.com
wrote:

 Monika,

 please make sure you've gone through the tutorials at
 http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials, to
 make sure we're speaking the same terminology and all the basics are clear.

 Cheers,
 M

 On 17.07.2015 06:20, monika bansal wrote:
  Ok... Thanks :)
 
  On Fri, Jul 17, 2015 at 6:47 PM, Marcus Müller marcus.muel...@ettus.com
  mailto:marcus.muel...@ettus.com wrote:
 
  You can of course add that later on, but don't forget to change both
  your include/blockname.h, your lib/blockname_impl.h and your
  lib/blockname_impl.cc. If you want to work with GRC, remember to
  edit the .xml in grc/, too!
 
  Best regards,
  Marcus
 
  PS: gr_modtool doesn't do anything magical; it really just adds
  files with the content you specify. I'd like to encourage you to try
  around a bit more! You can't break much. And with version control
  (git) having your back, you can hardly do any harm even to your own
  work :)
 
 
  On 17.07.2015 14:38, monika bansal wrote:
  Hii
  One more doubt...
  As the gr-digital / include/ ofdm_chest_vcvc.h file  have the
  argument list given as
static sptr make(
const std::vectorgr_complex sync_symbol1,
const std::vectorgr_complex sync_symbol2,
int n_data_symbols,
int eq_noise_red_len=0,
int max_carr_offset=-1,
bool force_one_sync_symbol=false
);
  Do we need to give Argument list at time of gr_modtool add when it
  asks... Or we can add it later if we are not sure at the time of
  adding new block.
 
  On Fri, Jul 17, 2015 at 5:42 PM, monika bansal
  monika19...@gmail.com mailto:monika19...@gmail.com wrote:
 
  Thanks...
 
  On Fri, Jul 17, 2015 at 5:16 PM, Marcus Müller
  marcus.muel...@ettus.com mailto:marcus.muel...@ettus.com
  wrote:
 
  Hi Monika,
 
  absolutely the same method:
 
  cd gr-exisitingmodule
  gr_modtool add
 
  Note that this can only work with modules that follow
  gr_modtool's conventions (i.e. practically only with
  modules generated with gr_modtool in the first place)
 
  Best regards,
  Marcus
 
 
  On 17.07.2015 13:01, monika bansal wrote:
  Hii
 
  I understood how to create new module and block within
  this new module using gr-modtool from
 
 http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules.
  I want to add new block in the existing module. How can i
  do that ?
 
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 
 
 
 
 
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 


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

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

Re: [Discuss-gnuradio] OFDM channel Estimation Block

[Marcus Müller]

Hi Monika,

absolutely the same method:

cd gr-exisitingmodule
gr_modtool add

Note that this can only work with modules that follow gr_modtool's 
conventions (i.e. practically only with modules generated with 
gr_modtool in the first place)


Best regards,
Marcus

On 17.07.2015 13:01, monika bansal wrote:

Hii

I understood how to create new module and block within this new module 
using gr-modtool from 
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules.

I want to add new block in the existing module. How can i do that ?


___
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] OFDM channel Estimation Block

[monika bansal]

Hii
One more doubt...
As the gr-digital / include/ ofdm_chest_vcvc.h file  have the argument list
given as
  static sptr make(
  const std::vectorgr_complex sync_symbol1,
  const std::vectorgr_complex sync_symbol2,
  int n_data_symbols,
  int eq_noise_red_len=0,
  int max_carr_offset=-1,
  bool force_one_sync_symbol=false
  );
Do we need to give Argument list at time of gr_modtool add when it asks...
Or we can add it later if we are not sure at the time of adding new block.

On Fri, Jul 17, 2015 at 5:42 PM, monika bansal monika19...@gmail.com
wrote:

 Thanks...

 On Fri, Jul 17, 2015 at 5:16 PM, Marcus Müller marcus.muel...@ettus.com
 wrote:

  Hi Monika,

 absolutely the same method:

 cd gr-exisitingmodule
 gr_modtool add

 Note that this can only work with modules that follow gr_modtool's
 conventions (i.e. practically only with modules generated with gr_modtool
 in the first place)

 Best regards,
 Marcus


 On 17.07.2015 13:01, monika bansal wrote:

   Hii

  I understood how to create new module and block within this new module
 using gr-modtool from
 http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules.
  I want to add new block in the existing module. How can i do that ?


 ___
 Discuss-gnuradio mailing 
 listDiscuss-gnuradio@gnu.orghttps://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] OFDM channel Estimation Block

[Marcus Müller]

You can of course add that later on, but don't forget to change both 
your include/blockname.h, your lib/blockname_impl.h and your 
lib/blockname_impl.cc. If you want to work with GRC, remember to edit 
the .xml in grc/, too!


Best regards,
Marcus

PS: gr_modtool doesn't do anything magical; it really just adds files 
with the content you specify. I'd like to encourage you to try around a 
bit more! You can't break much. And with version control (git) having 
your back, you can hardly do any harm even to your own work :)


On 17.07.2015 14:38, monika bansal wrote:

Hii
One more doubt...
As the gr-digital / include/ ofdm_chest_vcvc.h file  have the argument 
list given as

  static sptr make(
  const std::vectorgr_complex sync_symbol1,
  const std::vectorgr_complex sync_symbol2,
  int n_data_symbols,
  int eq_noise_red_len=0,
  int max_carr_offset=-1,
  bool force_one_sync_symbol=false
  );
Do we need to give Argument list at time of gr_modtool add when it 
asks... Or we can add it later if we are not sure at the time of 
adding new block.


On Fri, Jul 17, 2015 at 5:42 PM, monika bansal monika19...@gmail.com 
mailto:monika19...@gmail.com wrote:


Thanks...

On Fri, Jul 17, 2015 at 5:16 PM, Marcus Müller
marcus.muel...@ettus.com mailto:marcus.muel...@ettus.com wrote:

Hi Monika,

absolutely the same method:

cd gr-exisitingmodule
gr_modtool add

Note that this can only work with modules that follow
gr_modtool's conventions (i.e. practically only with modules
generated with gr_modtool in the first place)

Best regards,
Marcus


On 17.07.2015 13:01, monika bansal wrote:

Hii

I understood how to create new module and block within this
new module using gr-modtool from
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules.
I want to add new block in the existing module. How can i do
that ?


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



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





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

Re: [Discuss-gnuradio] OFDM channel Estimation Block

[monika bansal]

Ok... Thanks :)

On Fri, Jul 17, 2015 at 6:47 PM, Marcus Müller marcus.muel...@ettus.com
wrote:

  You can of course add that later on, but don't forget to change both your
 include/blockname.h, your lib/blockname_impl.h and your
 lib/blockname_impl.cc. If you want to work with GRC, remember to edit the
 .xml in grc/, too!

 Best regards,
 Marcus

 PS: gr_modtool doesn't do anything magical; it really just adds files with
 the content you specify. I'd like to encourage you to try around a bit
 more! You can't break much. And with version control (git) having your
 back, you can hardly do any harm even to your own work :)


 On 17.07.2015 14:38, monika bansal wrote:

  Hii
  One more doubt...
 As the gr-digital / include/ ofdm_chest_vcvc.h file  have the argument
 list given as
   static sptr make(
   const std::vectorgr_complex sync_symbol1,
   const std::vectorgr_complex sync_symbol2,
   int n_data_symbols,
   int eq_noise_red_len=0,
   int max_carr_offset=-1,
   bool force_one_sync_symbol=false
   );
  Do we need to give Argument list at time of gr_modtool add when it
 asks... Or we can add it later if we are not sure at the time of adding new
 block.

 On Fri, Jul 17, 2015 at 5:42 PM, monika bansal monika19...@gmail.com
 wrote:

 Thanks...

 On Fri, Jul 17, 2015 at 5:16 PM, Marcus Müller marcus.muel...@ettus.com
 wrote:

  Hi Monika,

 absolutely the same method:

 cd gr-exisitingmodule
 gr_modtool add

 Note that this can only work with modules that follow gr_modtool's
 conventions (i.e. practically only with modules generated with gr_modtool
 in the first place)

 Best regards,
 Marcus


 On 17.07.2015 13:01, monika bansal wrote:

Hii

  I understood how to create new module and block within this new module
 using gr-modtool from
 http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules.
  I want to add new block in the existing module. How can i do that ?


  ___
 Discuss-gnuradio mailing 
 listDiscuss-gnuradio@gnu.orghttps://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] OFDM channel Estimation Block

[monika bansal]

Hii

I understood how to create new module and block within this new module
using gr-modtool from
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules.
I want to add new block in the existing module. How can i do that ?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio