Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Pavan Yedavalli]

Makes sense, and will do! Thanks.

On Tue, May 3, 2016 at 6:41 PM, Derek Kozel  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 
> 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 
>> 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 
>>> 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 
 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
>
> 

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Derek Kozel]

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 
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  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 
>> 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 
>>> 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 
 wrote:

> Hi Derek,
>
> I was able to put in another USRP as a receiver, so I have the same
> transmit setup (connected to Octoclock 

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Pavan Yedavalli]

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  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 
> 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 
>> 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 
>>> 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

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Derek Kozel]

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 
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  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 
>> 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 

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Derek Kozel]

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 
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
> 
> )
>
> Thanks again.
>
> On Fri, Apr 29, 2016 at 12:21 PM, Derek Kozel 
> 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 
>> 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 
>>> 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 
 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

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Pavan Yedavalli]

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

)

Thanks again.

On Fri, Apr 29, 2016 at 12:21 PM, Derek Kozel  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 
> 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 
>> 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 
>>> 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  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

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Derek Kozel]

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 
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 
> 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 
>> 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 
>>> 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  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 

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Pavan Yedavalli]

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  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 
> 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 
>> 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 
>>> 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

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Derek Kozel]

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 
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 
> 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 
>> 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 

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Pavan Yedavalli]

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 
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 
> 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 

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Derek Kozel]

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 
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 
> 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 
>> 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 
>>> wrote:
>>>
 Hello Pavan,

 Are you trying to create a shared timebase between the two USRPs
 without having a shared 1PPS or GPS 

[Discuss-gnuradio] Feedback with Transmitters and Receiver

[Pavan Yedavalli]

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 > 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  > 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 > > 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
>> 

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Derek Kozel]

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 
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 
> 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 

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Pavan Yedavalli]

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  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 
> 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 

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Derek Kozel]

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.

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.

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.

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.

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.

Derek

On Wed, Apr 20, 2016 at 4:05 PM, Pavan Yedavalli 
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
> 
>  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
> , 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 

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Pavan Yedavalli]

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

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
, 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

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Martin Braun]

Pavan,

this is still a pretty generic scenario. I'll be able to help you with
specific questions on UHD usage etc., so if you break it down you'll get
some better answers.

Cheers,
Martin

On 04/17/2016 10:02 PM, Pavan Yedavalli wrote:
> Hi Martin,
> 
> Thank you again for getting back to me. Let me elaborate on the process
> that I am doing, and hopefully what I need will be clarified.
> 
> I have two USRPs connected via MIMO cable that are transmitting a sin
> wave and one USRP receiving that sin wave.
> 
> I am trying to implement a system in which I determine the power of the
> received signal, feed it back to the transmitters, adjust weights that
> I'm multiplying the transmitted signals by (according to some
> algorithm), and then send again to the receiver, and this goes on for a
> certain number of iterations.
> 
> The problem I am having is that I have no idea how to make sure that the
> received signal is the one that I am transmitting with my correct
> weights. In other words, I want to turn that receiver on only for it to
> receive my signal that I transmitted, then turn it off again as I adjust
> the weights, and then transmit again, and have it receive again. So,
> it's basically a full feedback loop that is sequential: transmit new
> signal, receive that signal, send back some information about that,
> transmit new signal, receive that signal, etc.
> 
> I still feel like I'm not able to describe this articulately, so please
> keep me posted. I am a bit unclear on how the rx_time could work in this
> above scenario. Thank you so much again!
> 
> 
> 
> -- 
> Pavan
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Pavan Yedavalli]

Hi Martin,

Thank you again for getting back to me. Let me elaborate on the process
that I am doing, and hopefully what I need will be clarified.

I have two USRPs connected via MIMO cable that are transmitting a sin wave
and one USRP receiving that sin wave.

I am trying to implement a system in which I determine the power of the
received signal, feed it back to the transmitters, adjust weights that I'm
multiplying the transmitted signals by (according to some algorithm), and
then send again to the receiver, and this goes on for a certain number of
iterations.

The problem I am having is that I have no idea how to make sure that the
received signal is the one that I am transmitting with my correct weights.
In other words, I want to turn that receiver on only for it to receive my
signal that I transmitted, then turn it off again as I adjust the weights,
and then transmit again, and have it receive again. So, it's basically a
full feedback loop that is sequential: transmit new signal, receive that
signal, send back some information about that, transmit new signal, receive
that signal, etc.

I still feel like I'm not able to describe this articulately, so please
keep me posted. I am a bit unclear on how the rx_time could work in this
above scenario. Thank you so much again!



-- 
Pavan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Martin Braun]

It seems like if you have one USRP sink (for MIMO tx) and one USRP
source (for rx) that's all you should need. You can evaluate the rx_time
from the rx to know where you are in time.

Although I admit I'm probably not fully understanding what you want to
do. Maybe you can eloborate?

m

On 04/13/2016 09:23 AM, Pavan Yedavalli wrote:
> Hi,
> 
> I have been trying to do some research using MIMO transmitters and
> feedback from a receiver. Specifically, I have two antennas connected to
> two USRPs, and I am transmitting the same signal from both of those
> (MIMO synchronized) to another USRP and antenna.This receive USRP and
> antenna needs to measure its received power, which I then feed back to
> my computer, do some processing on it, and then produce a new
> transmission from the two antennas on the left, and that keeps going
> until my loop is done. 
> 
> What I'm having trouble with is how to set up my self-created block to
> transmit from the two synchronized ones with my particular weights but
> also receive from the one on the right correctly so that it gives me the
> proper received power. Right now, I'm doing both the transmit and
> receive processes independently, and it's very difficult to get the
> proper capture on the receive side and send it back.
> 
> I'm not sure if that makes sense, but that type of feedback has been
> very difficult. Note that I've been able to create this loop, block, and
> feedback setup with an RSSI circuit and the two transmitters because I
> can feedback its reading through USB nicely/if not with a bit of a hack
> using minicom. I just can't do it when the receiver is a USRP. I must be
> missing something. Thank you for any help.
> 
> -- 
> Pavan
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Feedback with Transmitters and Receiver

[Pavan Yedavalli]

Hi,

I have been trying to do some research using MIMO transmitters and feedback
from a receiver. Specifically, I have two antennas connected to two USRPs,
and I am transmitting the same signal from both of those (MIMO
synchronized) to another USRP and antenna.This receive USRP and antenna
needs to measure its received power, which I then feed back to my computer,
do some processing on it, and then produce a new transmission from the two
antennas on the left, and that keeps going until my loop is done.

What I'm having trouble with is how to set up my self-created block to
transmit from the two synchronized ones with my particular weights but also
receive from the one on the right correctly so that it gives me the proper
received power. Right now, I'm doing both the transmit and receive
processes independently, and it's very difficult to get the proper capture
on the receive side and send it back.

I'm not sure if that makes sense, but that type of feedback has been very
difficult. Note that I've been able to create this loop, block, and
feedback setup with an RSSI circuit and the two transmitters because I can
feedback its reading through USB nicely/if not with a bit of a hack using
minicom. I just can't do it when the receiver is a USRP. I must be missing
something. Thank you for any help.

-- 
Pavan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio