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 <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
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