Makes sense, and will do! Thanks. On Tue, May 3, 2016 at 6:41 PM, Derek Kozel <derek.ko...@ettus.com> wrote:
> That's what I put the standard deviation in for. Your photos are showing > ~1 degree of deviation which certainly points to the system being > synchronized. The flowgraph is crude though and can definitely be improved > so don't pay too close attention to the exact number of the deviation. If > you do make a more rigorous one please share it with us. > > On Tue, May 3, 2016 at 6:38 PM, Pavan Yedavalli <psy2...@columbia.edu> > wrote: > >> Hi Derek, >> >> Thanks. Wrt the degrees versus dB, wouldn't it be more useful to test >> that the phase error (not the offset) is only changing over time by less >> than some threshold? It's already known that the offset is around 60 >> degrees, but the question is how much it varies *from* 60 degrees over >> time, right? I thought that was magnitude of the error we were plotting - I >> misunderstood. But thank you for clarifying. >> >> I have no doubt that I will have more questions regarding how to send >> bursts and general tags/timed commands, so I will keep you posted as I >> learn and try to do them. Thank you again for all the help. >> >> On Tue, May 3, 2016 at 6:06 PM, Derek Kozel <derek.ko...@ettus.com> >> wrote: >> >>> Just for clarity. That's a phase error in degrees not dB. :) And yes, >>> there's expected to be an offset. The correct behaviour is that the phase >>> offset is stable for a given frequency (assuming no other changes in the >>> system) and that tuning away and back or restarting should produce the same >>> phase offset (some combinations of motherboards and daughterboards can >>> result in a 180 degree ambiguity). >>> >>> To see the time synchronization you'll need to try sending bursts and >>> look at the rising/falling edge of the signals to see time alignment. But I >>> think you can move forward feeling pretty sure that that is working >>> correctly. When you get timed commands working bursts are a natural thing >>> to implement so you can verify your alignment then. >>> >>> Good luck with the next steps. >>> >>> On Tue, May 3, 2016 at 4:50 PM, Pavan Yedavalli <psy2...@columbia.edu> >>> wrote: >>> >>>> Hi Derek, >>>> >>>> Thanks for getting back to me. I lowered the Tx gain by about 15 dB on >>>> each channel, and then now it's looking good. It makes sense that it was >>>> clipping. Using your flowgraph (thanks!), I am appearing to get good >>>> results for setup (2), which is what we want. Looking at phase_error.png, >>>> we are getting a phase error of about -60 dB, which is very good. And we >>>> can see from i_and_q_both_channels.png that the phase offset is about 60 >>>> degrees (pi/3) (looking at both I and Q). I think this shows that both >>>> transmitters are transmitting at the same time. If I applied accurate >>>> beamforming weights, then ideally that phase offset would be eliminated >>>> (which is what I plan to do). I just want to make sure from you that this >>>> behavior makes sense. >>>> >>>> I believe my next step would be to look into timed commands in UHD and >>>> tags in GNU Radio to see how I can now transmit something from these two >>>> aligned transmitters to just one receiver, then calculate that power at the >>>> receiver, and then send it back to the transmitters for some processing >>>> before transmitting again. >>>> >>>> On Tue, May 3, 2016 at 4:05 PM, Derek Kozel <derek.ko...@ettus.com> >>>> wrote: >>>> >>>>> Hello Pavan, >>>>> >>>>> Your signal strength is much too high. You can see on the plots that >>>>> the received signal is greater than 1 (assuming a sinusoid input). Lower >>>>> the transmit gain and/or the receive gain until you are no longer >>>>> clipping. >>>>> The ADC is being overloaded so the spikes are entirely to be expected. You >>>>> have the 20dB attenuation which should be preventing any damage, but the >>>>> N210+SBX is still plenty sensitive enough to clip. >>>>> >>>>> Test 1, where the receivers are not synchronized, will tell you none >>>>> of time, frequency, or phase alignment since the receivers could be in any >>>>> state compared to each other and the synchronized transmitter pair. >>>>> >>>>> Test 2, where the receivers are synchronized with 1PPS and 10 MHz >>>>> references from the same octoclock as the transmitters (or another GPSDO >>>>> of >>>>> similar grade) will give you time, frequency, and phase (with SBXs) >>>>> information. >>>>> >>>>> I suggest not using complex to float conversion blocks and looking at >>>>> the raw complex values. It should be easy to see time and frequency sink >>>>> with the time sink. >>>>> >>>>> To measure phase alignment you can take the two outputs of your source >>>>> block and use a conjugate multiply to view the relative phase offset. I've >>>>> attached a flowgraph which I use to prove B210 phase alignment. You should >>>>> be able to copy the flowgraph over to your setup pretty simply. >>>>> >>>>> Cheers, >>>>> Derek >>>>> >>>>> On Tue, May 3, 2016 at 3:51 PM, Pavan Yedavalli <psy2...@columbia.edu> >>>>> wrote: >>>>> >>>>>> Hi Derek, >>>>>> >>>>>> I was able to put in another USRP as a receiver, so I have the same >>>>>> transmit setup (connected to Octoclock and with MIMO cable to another >>>>>> USRP), and the receive setup is now 2 USRPs, not connected by anything, >>>>>> and >>>>>> in two different setups: >>>>>> >>>>>> 1.) Neither receiver is connected to the Octoclock, and instead all >>>>>> of the time/sync properties are set to Default and PPS is set to don't >>>>>> sync >>>>>> (see received_not_connected_to_octoclock.png). We can see from >>>>>> recv_real_parts_no_octo_on_recv.png that they seem to be offset in phase >>>>>> slightly, which is what we expect, but the frequencies appear the same. >>>>>> One >>>>>> issue I'm seeing is that there are these periodic spikes in the channel 1 >>>>>> curve - is that because it may not be connected perfectly? I'm not sure >>>>>> where those are coming from. >>>>>> >>>>>> 2.) Both receivers are connected to the Octoclock (separately >>>>>> directly to the Octoclock, not one connected to the other via MIMO cable >>>>>> and only one connected to Octoclock), and all of the time/sync properties >>>>>> and PPS are what you had described in a previous e-mail (see >>>>>> received_connected_to_octoclock.png). Looking at >>>>>> recvd_real_parts_octo_on_recv.png and >>>>>> recvd_real_parts_octo_on_recv_2.png, >>>>>> we can see that the frequencies appear to be slightly different (I >>>>>> think?), >>>>>> and that there is also a spike in the channel 2 capture as well, so I'm >>>>>> not >>>>>> sure what is happening while the Octoclock is connected on the receive >>>>>> side. >>>>>> >>>>>> From (1), which I think is the right test to confirm that the >>>>>> transmitters are transmitting at the same time, we see the constant phase >>>>>> offset that we expect. From (2), things get a bit weird and I'm not sure >>>>>> how to interpret those results. >>>>>> >>>>>> Please keep me posted if you have any insight regarding (a) the >>>>>> periodic spikes, (b) whether (1) confirms what we want it to, and (c) >>>>>> whether I should be concerned about (2), since intuitively it makes sense >>>>>> that that should behave the same as (1), right? Thank you again for all >>>>>> your help. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Apr 29, 2016 at 5:37 PM, Derek Kozel <derek.ko...@ettus.com> >>>>>> wrote: >>>>>> >>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Pavan >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Pavan >>>> >>> >>> >> >> >> -- >> Pavan >> > > -- Pavan
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
