On Thursday, May 18, 2023 at 01:48:27 PM CDT, Marcus Müller <mmueller@gnuradio.org> wrote:
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 problem.
Best regards,
Marcus
On 18.05.23 19:42, Hamed Al-Zubi wrote:
> 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.
>
>
>
> 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 multiplication with the inverse of your channel estimate, anyways,
> and that cancels that.
>
> Best regards,
> Marcus
>
> On 18.05.23 19:08, Hamed Al-Zubi wrote:
> > Okay. I need to figure out how can I do that.
> >
> > Thanks!
> > HZ
> >
> <mailto:marcus.mueller@ettus.com>> 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 – 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, getting better hardware-level synchronization *does not help you at all*. Not if you
> > do it badly, not if you do it really really well.
> >
> > Best,
> >
> > Marcus
> >
> > On 18.05.23 18:21, Hamed Al-Zubi wrote:
> >
> > So, I have to get GPS modules and use GPSDO synchronization.
> >
> >
> >
> <mailto:marcus.mueller@ettus.com>>
> > <mailto:marcus.mueller@ettus.com> 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 synchronization.
> > Not in a way meaningful for synchronizing transceivers, no.
> >> Also, I thought that Schmidl and Cox algorithm used for timing recovery in OFDM receivers.
> > Exactly, that's why your PC clock synchronization would contribute nothing, even if it was
> > more accurate. You just don't benefit from synchronization.
> >>
> <mailto:mmueller@gnuradio.org>>
> >> <mailto:mmueller@gnuradio.org> wrote:
> >>
> >>
> >> 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 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
> >> <mailto:marcus.mueller@ettus.com>> wrote:
> >> >
> >> >
> >> > 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 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 achieved through GPSDO synchronization?
> >> >
> >> > Regards,
> >> > HZ
> >>
>
usrp const.png
channel model const.png