I am experimenting with OFDM between two USRPs. Unfortunately, I am not
yet
able to master the gnuradio framework so I have made my own
implementation.
The results are given in the link below.
What is the cause of the problems. Clock jitter ?, non-linearities ?
No idea what could be the problem in your case, but maybe try also
plotting the phase of all symbols in one OFDM symbol vs the offset from
the central carrier.
I’m currently working on DAB and I found some problems by doing this,
e.g. in [1] there is a frequency dependent phase offset due to an
inaccurate the sampling frequency.
In your sixteen QAM and other figures I see two effects.
Notice just the slightest hint that arcs through the top four
constellation points in the 16 QAM is not straight. This curvature is
caused by nonlinearity.
Your result almost surely can NOT be clock jitter. If you had a lot of
clock jitter, the pictures would look much worse. Notice the
dispersion gets larger as your proceed away from the origin. This is
almost surely phase noise in some oscillator.
constellation points in the 16 QAM is not straight. This
curvature is caused by nonlinearity.
Your result almost surely can NOT be clock jitter. If you
had a lot of clock jitter, the pictures would look much
worse. Notice the dispersion gets larger as your proceed
away from the origin. This is almost surely phase noise in
some oscillator.
Bob
Thanks!
New question:
Would the phase noise get smaller in USRP2 where we can use an external
reference, given that we use a high precision external reference ?
In your sixteen QAM and other figures I see two effects.
Notice just the slightest hint that arcs through the top four
constellation points in the 16 QAM is not straight. This curvature is
caused by nonlinearity.
Your result almost surely can NOT be clock jitter. If you had a lot of
clock jitter, the pictures would look much worse. Notice the
dispersion gets larger as your proceed away from the origin. This is
almost surely phase noise in some oscillator.
“Phase noise” of an oscillator to me means jitter. Can you clarify? Do
you mean a
sinusoid oscillator that has some issue with shape; i.e. non-linearity?
Thanks.
The USRP is not in the same league with the USRP2. The on board
oscillator is much better but external oscillators will make it even
better. So the answer is a big yes, the USRP2 will be better.
clock jitter, the pictures would look much worse. Notice the
dispersion gets larger as your proceed away from the origin. This is
almost surely phase noise in some oscillator.
“Phase noise” of an oscillator to me means jitter. Can you clarify? Do you mean a
sinusoid oscillator that has some issue with shape; i.e. non-linearity? Thanks.
I have to disagree with Bob here. I think that you are seeing some form
of distortion.
In a QAM pattern, gaussian noise will look like uniformly-sized round
balls. Phase noise will look like ovals which are longer in the
“rotation direction” than they are along the line to the center of the
constellation, proportionally so for the outer points than the inner
ones. ISI, frequency-selective fading and ICI will, over time, tend to
look round as well. Distortion like nonlinearities in the transmitter
will mostly affect the outer constellation points. This is a little
more complicated in an OFDM system rather than straight single-carrier
QAM, but that still looks like what you are seeing. Also, 31
subcarriers is a very small number for OFDM, so the affect is more like
on plain old QAM.
I would suggest backing the transmit power off a bit further.
Good to hear from you again. I am distinguishing betwen clock recovery
operations in the receiver and the oscillator feeding the down
conversion mixers. Even though there is some commonality in the sources
for these two DIFFERENT things on the USRP, implementation factors of
the clock recovery, how well the DBS-RX takes the up conversion of the
oscillator by MANY factors to make the downconversion mixer sources,
etc. are almost enough different to be independent noise sources.
I believe the clock recovery is working just fine or these pictures
would look like crap. The jitter of the constellation increasing with
increasing distance from the origin is VERY indicative of angular phase
noise in the downconversion oscillators in (say) the DBS-RX.
increasing distance from the origin is VERY indicative of angular phase
noise in the downconversion oscillators in (say) the DBS-RX.
Ok thanks for your explanation. Also I found a Wikipedia page on “phase
noise” that
even had a formula to convert to jitter. I understand what you are
saying now.
Your result almost surely can NOT be clock jitter. If you had a lot of
I have to disagree with Bob here. I think that you are seeing some
form of distortion.
To me there is no doubt about the nonlinear distortion as you can see
curvature in the edges of the “square”. If you have amplitude
components modulating the signal coming into the DBS-RX mixer, it will
not just spread them in angle. I do take your point about the
constellation points being symmetric rather than more elongated it might
just be compression effects. Back off will answer the question.
The USRP is not in the same league with the USRP2. The on board
oscillator is much better but external oscillators will make it even
better. So the answer is a big yes, the USRP2 will be better.
Actually, I need to disagree again here
The master oscillator on the USRP1 is actually exceptionally clean. It
may be as much as 20ppm off in frequency and will drift with
temperature, but it is very clean down to 10 Hz offsets. It is amazing
what you can do with a cheap oscillator as long as you don’t make it
tunable or temperature compensated.
As soon as you make an oscillator temperature compensated or voltage
controlled, as we need to in the USRP2, you have to go to much greater
lengths (and expense!) to get comparable phase noise performance. So
the USRP2 will have roughly the same phase noise performance as the
USRP1. The USRP2 will be lockable to an external oscillator, but that
will only affect phase noise at less than 100 Hz offsets.
Matt
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.