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----
Data: 09/10/2013 16.31
Ogg: Re: [Discuss-gnuradio] R: R: Re: around empty subcarrier in 802.11n
implementation
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:
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: [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
Francesca
----Messaggio originale----
Da: [email protected]
Data: 08/10/2013 16.22
A: <[email protected]>
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, [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
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
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Discuss-gnuradio mailing list
[email protected]
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 L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium