Hi guys,

just for letting you know. No offset correction is needed. The problem was 
elsewhere in my implementation of 802.11. It was how I was calling the ifft 
function in the transmitter side. By putting the correct parameters, I obtained 
a perfect spectrum.

Regards

Francesca





----Messaggio originale----

Da: xe...@libero.it

Data: 09/10/2013 16.55

A: <mle...@ripnet.com>, <discuss-gnuradio@gnu.org>

Ogg: [Discuss-gnuradio] 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:
tr=uhd.tune_request(self._freq,self._offset)self.uhd_usrp_source_0.set_center_freq(tr)
where freq and offset are passed as parameters. In this way I got no error.
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
francesca








----Messaggio originale----

Da: mle...@ripnet.com

Data: 09/10/2013 16.31

A: <discuss-gnuradio@gnu.org>

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





  
  
    On 10/09/2013 09:55 AM, xe...@libero.it 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:
      

      
      AttributeError:
        '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
        appreciated.

      
      Francesca

      
      

      
      

      
      

      
      
        ----Messaggio originale----

        Da: xe...@libero.it

        Data: 09/10/2013 10.52

        A: <discuss-gnuradio@gnu.org>

        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

        
        Francesca

        
        

        
        

        
        

        
        
          ----Messaggio originale----

          Da: mle...@ripnet.com

          Data: 08/10/2013 16.22

          A: <xe...@libero.it>

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

          

          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.
           
          http://files.ettus.com/uhd_docs/manual/html/general.html#tuning-notes
          
           
           
          on Oct 08, 2013, xe...@libero.it
            <xe...@libero.it> 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 

              basis.

              

              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 

              answer.

              Let me know if you need some other information about my
              implementation.

              

              Thanks for your attention

              francesca

              

              _______________________________________________

              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

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

    

    

    

    -- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

  





 



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

Reply via email to