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 >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
