Hi Andrew, Have you considered using a MIMO cable to synchronize the 2 USRP-N210?
On Fri, Sep 6, 2019 at 3:06 AM ANDREW BRAUN < andrewbr...@engineering.ucla.edu> wrote: > 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? > > If this doesn't show up as a self-reply, this was meant as a reply to: > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-September/060570.html > > 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 > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- *Laura Arjona * Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering *Paul G. Allen School of Computer Science & Engineering* 185 E Stevens Way NE University of Washington Seattle, WA 98195-2350
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
