Hamed,
you need to clearly formulate what you're showing there, and what the problem with that
is. Your receiver works, as it should, with a rotating channel. Whether that channel is
physical or an effect of perfect synchronization that's just not how you think "perfect"
should be like is irre
What's confusing about that? The point of S&C synchronization is to put you anywhere fixed
in the cyclic prefix with your time-synchronization.
All such points are equally good in terms of reception quality.
As said before, the constellation rotation is inherent, and also inherently not
a probl
I use the Shmdil and Cox gnuradio block and it does time recovery based on
what I have read. I also can retrieve the transmitted data.
But what I am confused about the presence of constellation rotation when I used
the USRP.
On Thursday, May 18, 2023 at 12:32:22 PM CDT, Marcus Müller
wro
Your OFDM receiver already does Schmidl&Cox, I thought? So, if you correctly designed the
length of your OFDM symbols and the subcarrier spacing, that should be sufficient. What
you described, a "constellation rotation for OFDM subcarriers" is unproblematic; you're
doing subcarrier-wise multipli
Okay. I need to figure out how can I do that.
Thanks!
HZ
On Thursday, May 18, 2023 at 11:54:42 AM CDT, Marcus Müller
wrote:
No, that's the opposite of what I said. (also, why would you need a GPSDO when
these USRPs are colocated?)
You *always* have time offset at a receiver – du
No, that's the opposite of what I said. (also, why would you need a GPSDO when these USRPs
are colocated?)
You *always* have time offset at a receiver – due to the finiteness of the
speed of light.
So, *any* working receiver you have has to have timing recovery, there's no way around it.
So,
So, I have to get GPS modules and use GPSDO synchronization.
On Thursday, May 18, 2023 at 11:20:02 AM CDT, Marcus Müller
wrote:
On 18.05.23 18:10, Hamed Al-Zubi wrote:
Actually, I don't know. I thought that by using PC clock in UHD sink and
source block in gnuradio allows s
On 18.05.23 18:10, Hamed Al-Zubi wrote:
Actually, I don't know. I thought that by using PC clock in UHD sink and source block in
gnuradio allows synchronization.
Not in a way meaningful for synchronizing transceivers, no.
Also, I thought that Schmidl and Cox algorithm used for timing recovery
Actually, I don't know. I thought that by using PC clock in UHD sink and
source block in gnuradio allows synchronization.
Also, I thought that Schmidl and Cox algorithm used for timing recovery in OFDM
receivers.
On Thursday, May 18, 2023 at 10:46:38 AM CDT, Marcus Müller
wrote:
Any
Any OFDM receiver needs a timing recovery method anyways, so that has nothing to do with
how well your PC is suitable for synchronizing two devices.
On 18.05.23 17:43, Hamed Al-Zubi wrote:
Thanks for your response, Marcus!
I have observed a constellation rotation for OFDM subcarriers when I us
Thanks for your response, Marcus!
I have observed a constellation rotation for OFDM subcarriers when I use the PC
clock for synchronization. However, by using the channel model, I am able to
see the QPSK constellation.
Thanks!HZ
On Thursday, May 18, 2023 at 10:35:01 AM CDT, Marcus Müller
No, it's several orders of magnitude worse and generally insufficient for anything where
you need synchronization.
Best,
Marcus
On 18.05.23 17:12, Hamed Al-Zubi wrote:
Hello Dears,
I would like to inquire about the synchronization of two USRPs X300, one acting as a
transmitter (Tx) and the o
Hello Dears,
I would like to inquire about the synchronization of two USRPs X300, one
acting as a transmitter (Tx) and the other as a receiver (Rx). If both USRPs
are connected to the same laptop, I'm wondering if the accuracy provided by PC
clock synchronization is similar (or close) to that
13 matches
Mail list logo
