R: Re: R: R: Re: around empty subcarrier in 802.11n implementation

Ok, I was supposing that.
So in the python code of the receiver I’ve put:
where freq and offset are passed as parameters. In this way I got no
Now, the question is: which values are good for “offset”? Hz? KHz?
MHz?I’ve tried small values, like 50 Hz, but nothing changes.
Is there a way to find it?
I’m sorry, but really I have not ideaThank you again for your support

----Messaggio originale----

Da: [email protected]

Data: 09/10/2013 16.31

A: [email protected]

Ogg: Re: [Discuss-gnuradio] R: R: Re: around empty subcarrier in 802.11n

On 10/09/2013 09:55 AM, [email protected] wrote:

  Hi guys,

  I've tried to follow the
    suggested procedure. I guess the problem is inside the uhd
    driver I'm using (UHD_003.005.001), since the set_rx_freq()
    gives the following error:

    'uhd_usrp_source_sptr' object has no attribute 'set_rx_freq'

  Or, maybe, the problem is
    the daughterboard, which is of type XCVR2450.

  Is there another way to set
    dc offset?

  Any hint will be greatly


    ----Messaggio originale----

    Da: [email protected]

    Data: 09/10/2013 10.52

    A: <[email protected]>

    Ogg: [Discuss-gnuradio] R: Re: around empty subcarrier in
    802.11n implementation

    Thanks for your answer.

    I'm a computer scientist, so I'm not so aware
      of what DC-offset exactly means, but I'm going to try this
      tuning. I'll let you know if I solve the problem.

    Best regards


      ----Messaggio originale----

      Da: [email protected]

      Data: 08/10/2013 16.22

      A: <[email protected]>

      Ogg: Re: [Discuss-gnuradio] around empty subcarrier in 802.11n

      Likely, if it's the central tones, you're looking at
        DC-offset (or the removal thereof) interfering.

        You can use offset tuning in the hardware to slide the DC
        offset outside of your passband.


      on Oct 08, 2013, [email protected]
        <[email protected]> wrote:

        Hi list,

          I'm using gnuradio 3.6.0 together with USRPs N210 for
          implementing OFDM 802.11

          n communications, just SISO for the moment (in the future
          it would be MIMO). I

          have properly modified parameters such as FFT size, number
          of occupied tones

          and so on. I have also included all preambles (STF,
          LTF...) and I have

          accordingly modified the "correlate" and
          "calculate_equalizer" functions in

          ofdm_frame_acquisition. FEC is also included in the chain.
          In the

          ofdm_frame_sink file I've added a function that computes
          SNR in a per-carrier


          Everything is working fine, I obtain about 80% of correct
          packets, but I've

          noticed from the snr plotting, that the carriers around
          the central empty one

          (3 subcarriers before and 3 subcarriers after) have very
          poor snr values. So

          I've investigated about this effect, and I've realized
          that the all

          transmission errors are in those subcarriers and, in most
          cases, FEC is able to

          recover, but I would like to understand why this happens.

          I conducted some searches in the web but unfortunately I
          didn't find an


          Let me know if you need some other information about my

          Thanks for your attention



          Discuss-gnuradio mailing list

          [email protected]


Discuss-gnuradio mailing list
[email protected]

Since you're likely using the Gnu Radio interface that is a wrapper
for UHD, you'd use the set_center_freq() method.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

On 10/09/2013 10:55 AM, [email protected] wrote:

I’m sorry, but really I have not idea

Thank you again for your support


You want to move the DC-anomaly right out of your passband, so choose an
offset that’s slightly more than half your sample rate.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs