Hi Derek, I appreciate it. Okay, I will change all of those. I am using the SBX daughterboards - the ones that support phase sync.
On Thu, Apr 28, 2016 at 3:55 PM, Derek Kozel <derek.ko...@ettus.com> wrote: > Hello Pavan, > > You do not need Ethernet connected to the Octoclock, so that's ok. Your > cabling sounds correct. Can you please combine both UHD Sinks? Just > increase the number of motherboards and channels to 2 and copy the MIMO > attached USRP's settings into channel 2. > > Your sample rate for the receive side is very very low. I suspect that > will throw a warning if you read the log output at the bottom of GRC. Try > raising that to 500kHz or more. Also the WX Scope Sink can be changed to > complex inputs so you don't need the converter blocks. You are also setting > a custom clock rate. The N200 has a fixed master clock rate of 100 MHz so > this is likely also throwing a warning in the log messages. Definitely look > through those and make changes as needed. > > What daughterboards are you using? On the N200 series motherboards only > the SBX daughterboards supports phase synchronization. What you should see > is frequency and time synchronization between the MIMO N210s. > > Regards, > Derek > > On Thu, Apr 28, 2016 at 12:22 PM, Pavan Yedavalli <psy2...@columbia.edu> > wrote: > >> 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 >> > > -- Pavan
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
