Hi Pavan, This is a USRP/UHD question really so I'm including the usrp-users mailing list. If you're not already the list already then you should certainly join as that's a better resource for questions about UHD/USRPs.
1) Any SMA cable will work. For the best performance their electrical lengths should be the same. In practice this usually means equal physical lengths of the same type of coax. This ensures that the signals arrive at the same time (and phase). 2) Most radio systems don't have GPS timebases available and use various protocol level methods for aligning their clocks, if needed. In a very simple system the receiver could simply listen continuously until it receives a full message, then transmits a response if needed. Look up Time Division Multiplexing and Frequency Division Multiplexing. This is an area where there are nearly as many possibilities as there are radio systems. 3) Once you connect all the Octoclock signals then in GNU Radio you can select the Clock and Time sources to be External and the Sync to be Unknown PPS. Your pair of units connected via a MIMO cable are special, the master should have the External time and clock sources, the companion USRP should have MIMO selected for time and clock. The Sync should still be Unknown PPS. Here's a page that talks about synchronization of USRPs. Read this, get your hardware all setup, and try setting up a basic GRC flowgraph with your three radios. Think of what tests you could use to verify that both your MIMO cabled radios are transmitting at the same time. You should look into timed commands in UHD and tags in GNU Radio. http://files.ettus.com/manual/page_sync.html https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf If this is your first use of USRPs and GNU Radio then I'd suggest reading through the tutorials available online and not get too focused on MIMO until you feel comfortable with the basics of the environment and tools that you have. http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials Once you've given this a try let us know if you have additional questions. Regards, Derek On Thu, Apr 21, 2016 at 3:27 PM, Pavan Yedavalli <psy2...@columbia.edu> wrote: > Hi Derek, > > Thanks for getting back to me. So, I do have an Octoclock, so I think > we're getting somewhere and this is starting to make more sense. A few > follow up questions: > > 1.) Do I need special cables to connect all of the units to the Octoclock, > or are they robust SMA cables? > > 2.) I feel like this seems particularly involved to send a signal from a > transmitter to a receiver. I am assuming most non-MIMO, non-beamforming > related tasks have always used your second option of using the GPSDO kits? > I purchased an Octoclock knowing I would do MIMO experiments, but obviously > I'm guessing more conventional communication techniques (like a simple BPSK > or QPSK between tx and rx) would have probably used the GPSDO kits? > > 3.) Once I connect them all to the Octoclock, then I don't need to a > protocol level time synchronization, right? Once they're all synchronized > and I see that in the plots, then I guess the next step would be to figure > out how to implement my actual feedback loop. At that point, then I would > need to figure out how to do burst mode to transmit and receiver timed > signals? Would this end up needing to be one flow graph or would I have to > use two flow graphs? (One for to and one for rx, the way I am doing it now) > > Thank you again for all the help. I think I'm starting to understand what > I need in the setup. > > On Thu, Apr 21, 2016 at 4:56 PM, Derek Kozel <derek.ko...@ettus.com> > wrote: > >> Hello Pavan, >> >> I think we both are starting to understand the setup and the problem. >> Here are the two hardware solutions: >> >> Connect a shared 1PPS signal to *both* the master USRP of your MIMO >> cabled pair and to the receiver (For example using an octoclock: >> https://www.ettus.com/product/details/OctoClock-G) >> >> OR >> >> Connect GPS referenced 1PPS signals to both the master USRP of your MIMO >> cabled pair and the receiver (For example using two of the GPSDO kits: >> https://www.ettus.com/product/details/GPSDO-KIT) >> >> >> There are many ways of implementing a protocol level time synchronization >> in software/DSP. The paper I linked to talks about one way, there are >> certainly others. I do not know of any example projects implementing them >> though so you would have to develop your own. >> >> Regards, >> Derek >> >> On Thu, Apr 21, 2016 at 8:04 AM, Pavan Yedavalli <psy2...@columbia.edu> >> wrote: >> >>> Hi Derek, >>> >>> I'll answer your questions in-line, because I think what you are saying >>> is beginning to make me understand what I need: >>> >>> >>> On Wed, Apr 20, 2016 at 9:03 PM, Derek Kozel <derek.ko...@ettus.com> >>> wrote: >>> >>>> Hello Pavan, >>>> >>>> Are you trying to create a shared timebase between the two USRPs >>>> without having a shared 1PPS or GPS reference? You are still not using >>>> enough detail for us to understand fully. >>>> >>> >>> To clarify, my setup is two USRPs connected via MIMO cable, and then >>> another USRP acting as a receiver. So are you asking whether I'm trying to >>> create a shared timebase between the two-USRP *unit* (because they are >>> MIMO cabled) and the receiving USRP without having a shared 1 PPS or GPS >>> reference? I think my answer to that must be yes, because I have not done >>> anything else but connect them to the computer via ethernet and just have >>> two of them connected via MIMO cable and the other one by itself. I'm >>> assuming I need to have a shared reference between the transmit USRPs and >>> the receive USRP, so how would I be able to do that? This could certainly >>> be one of my problems. >>> >>>> >>>> In Figure 5 both USRPs are connected with a MIMO cable and so have both >>>> shared frequency and time bases. What is your weight block doing to the >>>> sample stream? Is it a time delay block? I don't know what gnuradio would >>>> do if you specified 10*sample_rate as the delay there as that's likely to >>>> be a very large number of samples. >>>> >>> >>> My weight block is applying a normalized magnitude phase correction to >>> each antenna's transmitted signal, so, yes, it is essentially creating a >>> time delay. Each weight is a complex value with magnitude 1 and a >>> calculated phase. You are saying this could be a problem if it's >>> calculating a value that is too high? >>> >>>> >>>> If you have both USRPs connected with a time synchronization (shared >>>> 1PPS, GPSDO, or MIMO cable) and have your flowgraph configured correctly, >>>> then you can just use timed commands to the USRP_alpha to start >>>> transmitting at time X and USRP_beta to start receiving at time X and you >>>> will see your signal. You can then move to using burst mode using tags to >>>> define the number of samples to send/receive along with timed commands to >>>> send/receive bursts of samples. This works because the clocks in both USRPs >>>> will be aligned to each other. >>>> >>> >>> I feel like there are two steps here. First, I need to get the >>> transmitting USRPs (which are conneced via MIMO cable) to time sync to each >>> other (which I believe I have done through using USRP sink in GRC and >>> setting the second channels time and clock to MIMO cable?), and second, I >>> need to get the receive USRP to receive at the same time. So, just as >>> above, I need to get my receive USRP to be on the same time as my transmit >>> USRPs? Once I'm able to do that, then I can do burst mode to transmit and >>> receive timed signals, as you are mentioning? >>> >>>> >>>> If you do *NOT* have a shared time source for each radio, for instance >>>> they are far apart and do not have GPS references, then you need to do some >>>> sort of protocol level alignment to create a shared understanding of time >>>> between them. A frequently used method is for USRP_alpha to transmit a >>>> beacon with a known period (say once every 10 seconds). All other USRPs >>>> then receive for longer than 10 seconds to be guaranteed to receive the >>>> beacon (assuming they're within range of the transmission). When the >>>> receiving USRPs detect the incoming beacon they align their local time to >>>> the master (Beacon transmitting) USRP. >>>> >>> >>> I guess a similar question to the above: can I have a shared time source >>> between the transmit USRPs (which are already MIMO cabled to each other) >>> and the receive USRP? It seems like that would be easier to do than going >>> through this protocol level alignment, but maybe it's not possible given my >>> setup. >>> >>>> >>>> Here's a quick paper talking about this topic. The technique is widely >>>> used. >>>> http://www.ece.uah.edu/~milenka/docs/dc_ssst05_synch.pdf >>>> >>>> >>>> I hope this helps and is applicable to your need. If you have more >>>> questions please try drawing your desired system and maybe include a >>>> timeline of events that you expect the radios to do. Attaching your >>>> existing flowgraphs, either as photos using GRC's screen capture feature >>>> (file>screen capture) or the actual GRC file, also helps us understand what >>>> exactly you are working with. >>>> >>> >>> I had to take down the setup because I am moving labs, but I will send >>> some flowgraphs and the diagram of the system next week. Thank you again >>> for being so patient and trying to help me. I think I'm just a bit lost on >>> a few of the simple things, but once those are figured out, then I think it >>> should be smoother sailing. >>> >>>> >>>> Derek >>>> >>>> On Wed, Apr 20, 2016 at 4:05 PM, Pavan Yedavalli <psy2...@columbia.edu> >>>> wrote: >>>> >>>>> Hi Martin, >>>>> >>>>> I guess I have a few questions: >>>>> >>>>> 1.) Are there any examples in the gnuradio codebase/flowgraph >>>>> repository that show how to do synchronized feedback between two USRPs? In >>>>> other words, I send a signal from a transmit USRP, and then I receive that >>>>> signal at the receive USRP, and then I send back something else from the >>>>> receive USRP back to the transmit USRP, and this would be a sequential >>>>> process in which they are aligned and know when to transmit and/or >>>>> receive? >>>>> I saw a post >>>>> <http://stackoverflow.com/questions/28710869/how-to-set-usrp-transmitting-time-and-receiving-time-in-gnu-radio> >>>>> that >>>>> I think would be relevant, but I'm not sure how to apply it. >>>>> >>>>> I believe this should be a pretty standard scenario in which you want >>>>> to have two USRPs communicate with each other synchronously. I guess I'm >>>>> just having trouble finding an example of how to do this. >>>>> >>>>> 2.) Related to the above question, maybe there are no examples to do >>>>> feedback in one flowgraph, so what I have been doing is the following in >>>>> my >>>>> flowgraphs: >>>>> >>>>> Flowgraph A: >>>>> >>>>> The synchronized MIMO flowgraph (Figure 5) from this >>>>> <https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp.pdf>, >>>>> so essentially I have two USRPs synchronized and transmitting out two >>>>> signals that should be offset but frequency aligned. In my own flowgraph's >>>>> main(), instead of applying a "phase shift" block, I am applying my own >>>>> "weights" block to both transmissions. >>>>> >>>>> So, I am now sending a signal that has those weights applied to it. >>>>> So, after I do tb.start(), then I sleep for 10 seconds (by doing >>>>> sleep(10)) >>>>> hoping that in the 10 seconds my receiver will catch the signal that I'm >>>>> transmitting and put it into file. >>>>> >>>>> Flowgraph B: >>>>> >>>>> My own receiver.py in which I have a USRP sink->FFT->Complex to >>>>> Mag->File sink. I also have a connection from FFT->QT GUI to see a plot of >>>>> what is being captured. >>>>> >>>>> I now run Flowgraph A in one terminal and Flowgraph B in another >>>>> terminal. I need to capture A's transmission with the first weights within >>>>> the 10 seconds (as it's sleeping) into the file sink. Then, A will send a >>>>> signal with another set of weights applied, and I will need to capture >>>>> that >>>>> in the next 10 seconds, and so on. My problem is that I'm often capturing >>>>> noise because my receive was not aligned with when I was transmitting my >>>>> desired signal. So, I end up only capturing noise after the transmission >>>>> stops as opposed to the actual signal when the transmission is happening. >>>>> >>>>> Essentially, I am trying to mimic feedback by doing the above, but I >>>>> don't know how to align my transmitter and receiver, especially because >>>>> they are two different blocks. Is there a way to make both the >>>>> transmission >>>>> and reception one block so that I can do sleep(rx_time + >>>>> n_samples_since_tag/sampling_rate) (I think this could be right?) as >>>>> opposed to my static sleep(10) and pray for the best? >>>>> >>>>> Would it be helpful at all if I showed you my code? I still feel like >>>>> I'm not being clear. Sorry about that. If there were any examples, then I >>>>> think that would be the best for me to look at. >>>>> >>>>> Thanks for any help again. >>>>> >>>>> >>>>> -- >>>>> Pavan >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> Discuss-gnuradio@gnu.org >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>> >>> >>> >>> -- >>> Pavan >>> >> >> > > > -- > Pavan > > > -- > Pavan > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
