Hi Derek, Sorry - just another quick addition. When I run the Tx flowgraph, I get this error:
Board 0 May not be getting a PPS signal! No PPS detected within the time interval. This definitely tells me something is wrong with the Octoclock-G setup. On Thu, Apr 28, 2016 at 12:18 PM, Pavan Yedavalli <psy2...@columbia.edu> wrote: > Hi Derek, > > I am trying to do (3), as you noted above, and my test to see whether the > Tx USRPs are transmitting at the same time is to directly connect them to > the Rx USRP and plot the real components of each one and see whether they > are in phase (or at least with some constant random offset). In theory, I > believe this is a good test to see that the Octoclock-G is working its > magic. > > The setup: > > *Octoclock*: Two of the three boards (Master Tx USRP and 1 Rx USRP) are > connected to the Octoclock-G (one cable each from PPS out to PPS in, and > one cable each from 10 MHz out to Ref in, so 4 total cables). The primary > ref knob is set to Internal, and the PPS blinks green, while Internal, > Status, and Power are all steady greens. I do *not* have the ethernet of > the Octoclock connected, however. When I connected it to my Gb Ethernet > switch, the indicator was orange, while all the other working ones are > green, so I decided not to connect it for now. Does this matter? > > *Tx side*: I have both Tx USRPs connected to each other via the MIMO > cable, and one of them is connected to the Octoclock, as mentioned above. > In tx_mimo_setup_octoclock.png, we can see that I have two USRP sinks > connected via MIMO cable, and one of them has time and clock set to > External, and the other has time and clock set to MIMO cable. Both have > sync set to Unknown PPS. > > *Between Tx and Rx*: I have an SMA cable from one Tx USRP connected to a > 20 dB attenuator, and then connected to the Tx/Rx port of the Rx USRP. I > have another SMA cable from the other Tx USRP connected to a 20 dB > attenuator, and then connected to the Rx2 port of the Rx USRP. No antennas > are connected. > > *Rx side*: In receiver_recvng_on_both_ports.png, we can see that I have a > USRP source with two channels. The time and clock are set to External, and > the sync is set to Unknown PPS. I run this, but I get the following error: > > RuntimeError: LookupError: IndexError: multi_usrp: RX channel 1 out of > range for configured RX frontends > > I tried looking up what this error is, and apparently there was a fix in a > branch years ago, but I'm assuming I have that fix already? I have a > feeling something is wrong with the Octoclock setup that is causing this, > but I'm not sure. I believe the setup I mentioned above makes sense, right? > > Obviously, I will look into timed commands in UHD and tags in GNU Radio > after I get all of this set up and working. Thank you so much again for the > help. > > > > > On Thu, Apr 21, 2016 at 3:52 PM, Derek Kozel <derek.ko...@ettus.com> > wrote: > >> 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 >>> >>> >> > > > -- > Pavan > -- Pavan
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
