Hey everyone,
I'm currently experiencing timing issues regarding synchronizing two USRP's.
My current setup is the following:
USRP 0 sends a packet with a known preamble (BPSK Modulated) to USRP1. The
packet is formed in the following manner: <Preamble | Packet Header |
Arbitrary Phase / Amplitude Modulation>. The preamble and packet header are
both bpsk modulated.
USRP 1 receives this packet, strips the preamble (using tags from a
correlation estimator), and is left with just the arbitrary phase /
amplitude modulation.
My specific application is ML based, but my problem isn't. Essentially what
I've noticed is, the received constellation of the "arbitrary" modulation I
described above may look either noisy depending on when the USRP's start
receiving or transmitting. Additionally, underflows and overflows will also
desynchronize the way the constellation looks.
So if the constellation looks "noisy" due to this issue, then an underflow
may actually bring it back to synchronization.
If the constellation looks great like the picture attached, then an
underflow will bring the constellation to look bad.
I believe this may be related to how I'm synchronizing these two USRP's.
Right now I have the USRP blocks in GNURadio set to External Clock Source,
External Time Source, and Synced to the same "Unknown PPS". Doing this I
would assume the received constellation should be the same, but it isn't.
I also thought that this may be a sample offset, but that's not the case
either, as testing with a custom sample offsetting block did not fix the
issue.
Here is a picture of my flowgraph and the observed constellation
differences. Note that the channel model / manual phase adjuster are not
doing anything with the issue that I've seen, as bypassing them in gnuradio
does not resolve the problem. (The observed problem is seen even on a
constellation sink on the USRP Source).
If anyone has any experience or knows about this, please let me know.
P.S. I can also screen capture a video of the problem and show what's
happening if that's easier.
Thanks,
Andrew Braun
Hey everyone,
I'm currently experiencing timing issues regarding synchronizing two USRP's.
My current setup is the following:
USRP 0 sends a packet with a known preamble (BPSK Modulated) to USRP1. The
packet is formed in the following manner: <Preamble | Packet Header |
Arbitrary Phase / Amplitude Modulation>. The preamble and packet header are
both bpsk modulated.
USRP 1 receives this packet, strips the preamble (using tags from a
correlation estimator), and is left with just the arbitrary phase /
amplitude modulation.
My specific application is ML based, but my problem isn't. Essentially what
I've noticed is, the received constellation of the "arbitrary" modulation I
described above may look either noisy depending on when the USRP's start
receiving or transmitting. Additionally, underflows and overflows will also
desynchronize the way the constellation looks.
So if the constellation looks "noisy" due to this issue, then an underflow
may actually bring it back to synchronization.
If the constellation looks great like the picture attached, then an
underflow will bring the constellation to look bad.
I believe this may be related to how I'm synchronizing these two USRP's.
Right now I have the USRP blocks in GNURadio set to External Clock Source,
External Time Source, and Synced to the same "Unknown PPS". Doing this I
would assume the received constellation should be the same, but it isn't.
I also thought that this may be a sample offset, but that's not the case
either, as testing with a custom sample offsetting block did not fix the
issue.
Here is a picture of my flowgraph and the observed constellation
differences. Note that the channel model / manual phase adjuster are not
doing anything with the issue that I've seen, as bypassing them in gnuradio
does not resolve the problem. (The observed problem is seen even on a
constellation sink on the USRP Source).
If anyone has any experience or knows about this, please let me know.
P.S. I can also screen capture a video of the problem and show what's
happening if that's easier.
Thanks,
Andrew Braun
