Hi Pavan, Yes, you are correct, this test won't show phase alignment. The most common checks for phase alignment need a receiver able to do two simultaneous channels, such as a high bandwidth oscilloscope, another N210/SBX that can be setup the same as your transmitter pairing, or an X300 series USRP with two SBXs. Perhaps others on the list will have less equipment ways of verifying phase alignment.
Perhaps capturing the combined waveform at one frequency, tuning only the transmitters to a different frequency and then back to the original and comparing the waveforms would be sufficient? The phase alignment will be a constant offset at a given frequency, assuming nothing else in the system changes. On Fri, Apr 29, 2016 at 5:14 PM, Pavan Yedavalli <psy2...@columbia.edu> wrote: > Hi Derek, > > That makes sense. I will put a combiner and try this. However, now the > test is a bit different, right? The only way I could tell that the > transmitters are transmitting at the same time is if the power level is > double what it used to be, assuming they are actually fully in phase. Is > there a possibility that they are out of phase though, but there is a > constant random offset, so they add up slightly differently and not > completely coherently? (as shown in Figure 7 in this document > <https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf> > ) > > Thanks again. > > On Fri, Apr 29, 2016 at 12:21 PM, Derek Kozel <derek.ko...@ettus.com> > wrote: > >> Hi Pavan, >> >> I'm sorry, I didn't read your cabling closely enough or I would have >> noticed this before. If you only have one SBX in the receive N210, then you >> only have one possible receive channel! That is why you are seeing the >> error that RX channel 1 (remember they're 0 indexed) is out of range. On >> the SBX, and all other daughterboards, the TX/RX and RX2 ports are shared >> by a single receive channel. They are setup with a switch to allow either >> time divided transmit and receive on a single antenna (using the TX/RX >> port) or having separate transmit and receive connections (transmit on >> TX/RX and receive on RX2). >> >> You will need to use a combiner to merge the two transmit signals into a >> single receive connection, to either TX/RX or RX2. Or use antennas and let >> the air do your combining. You may want to keep the attenuators in line >> until you are comfortable with the power levels. You'll be able to see when >> your receiver is clipping in the Scope GUI. >> >> Derek >> >> On Fri, Apr 29, 2016 at 11:32 AM, Pavan Yedavalli <psy2...@columbia.edu> >> wrote: >> >>> Hi Derek, >>> >>> I made all the changes, and the Tx error as well as the warnings are now >>> gone. However, the Rx error still remains: >>> >>> File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", >>> line 2168, in set_samp_rate >>> return _uhd_swig.usrp_source_sptr_set_samp_rate(self, *args, >>> **kwargs) >>> RuntimeError: LookupError: IndexError: multi_usrp: RX channel 1 out of >>> range for configured RX frontends >>> >>> I'm not entirely sure what the problem is here. Attached are the >>> flowgraph pictures. In addition, I am using Rev 5.1 SBX daughterboards. >>> Thanks again. >>> >>> >>> >>> On Thu, Apr 28, 2016 at 4:21 PM, Pavan Yedavalli <psy2...@columbia.edu> >>> wrote: >>> >>>> 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 >>>> >>> >>> >>> >>> -- >>> Pavan >>> >> >> > > > -- > Pavan >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
