So I'm new to using the mailing list here, so hopefully this shows up as a self-reply. I was able to reproduce the timing issue with better examples. Sending a constant symbol, I get consistent results which is usable for my application. However, sending a BPSK symbol results in an ugly constellation as can be seen in the image below (PSKExample.png)
Is this intentional? Do I just need to do some type of DSP to figure out the best time to sample? I was hoping that given an external clock reference and external time reference and synced to a pps that this type of synchronization would not be an issue, and that a BPSK modulated signal would look something like the results for the constant symbol. (EG two points on just two sides of the constellation plot).
Note that these constellations are out of phase despite being synced to pps, which works for my application. Is that expected?
Thanks,
Andrew Braun
Attached is my previous post in case this doesn't show up as reply (I'm also posting this on the GNURadio board in case this isn't a USRP related issue)
For the BPSK image, I ran the PSK_Mod_Example.grc.
For the constant_sample image, I ran the MinimumReproducibleFlowgraph.grc
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