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 <[email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 <[email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 >>>> [email protected] >>>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>> >> >> >> -- >> Pavan >> > > -- Pavan -- Pavan
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
