Yes, sorry - two of them are actually connected via MIMO cable, with the
master connected to the Octoclock. Then the other two are directly
connected to the Octoclock. I used the MIMO cable just because I had it,
but hopefully that's not changing the functionality.
Yes, I added even more attenuation because the Tx gain was already quite
low. Thanks for the suggestion.
On Tue, Jul 5, 2016 at 7:29 PM, Marcus D. Leech <mle...@ripnet.com> wrote:
> On 07/05/2016 09:45 PM, Pavan Yedavalli wrote:
>
> According to the spectrum analyzer, there's nothing being transmitted in
> the 900 MHz band around me, so that is actually fine. The biggest unknown
> could be what you are saying about how they combine in the RSSI circuit
> (which I'm not sure how it works).
>
> I am not gaining any more insight when using over-the-air antennas, so I
> used 2 USRPs as transmitters and 2 as receivers, connected them directly
> with SMA cables (and attenuation), and used Derek Kozel's B210_Phase_Viewer
> on the receive side to see whether they were aligned after each run. And I
> am noticing that they are not. The first run produced a 125 degree phase
> offset, while the second one produced a 3 degree phase offset, and this
> continues to fluctuate after each run (see attached). Note that I am using
> the code that I pasted above to transmit.
>
> I must be doing something wrong with the code, or not wrapping the timed
> commands around the correct code. I am not sure though. Thanks again.
>
> Looks like you have a bit of clipping as well. Back off the gain on the
> TX side.
>
>
>
>
> On Tue, Jul 5, 2016 at 5:51 PM, Marcus D. Leech <mle...@ripnet.com> wrote:
>
>> On 07/05/2016 08:20 PM, Pavan Yedavalli wrote:
>>
>> I see, but the offset in phase between the two radios will affect the
>> amplitude, right? That was the assumption I was using, since it gives out
>> an amplitude reading, but the phase clearly will affect that reading, I
>> presumed.
>>
>> Unfortunately, I don't have any documentation on the RSSI circuit apart
>> from the following description from the vendor:
>>
>> The RSSI functionality allows the sampling of the received signal to
>> provide an indication of the amount of energy being harvested. When DSET is
>> driven high the harvested DC power will be directed to an internal sense
>> resistor, and the corresponding voltage will be provided to the DOUT pin.
>> The voltage on the DOUT pin can be read after a 50μs settling time. RSSI
>> shows the actual power level that is being received at the antenna. This
>> number is accurate from 0.04mW to 50mW.
>>
>> This probably does not help at all to debug. Sorry about that.
>>
>> You're making assumptions about how your signals will combine in that
>> RSSI circuit, and how they'll combine with other ambient signals within
>> your frequency band. I cannot imagine that being stable.
>>
>> To measure the phase between two signals, you need a device that is phase
>> sensitive (like, for example, another USRP with two inputs), and
>> compute conjugate multiplication between them, or the phase-angle, via
>> the complex-argument block.
>>
>> Or just plot the two signals on a Qt Time sync, and observe that the
>> phase relationship is the same--that of course requires that your
>> receiver system is internally coherent between the two channels.
>>
>>
>>
>>
>>
>> On Tue, Jul 5, 2016 at 4:42 PM, Marcus D. Leech <mle...@ripnet.com>
>> wrote:
>>
>>> On 07/05/2016 07:28 PM, Pavan Yedavalli wrote:
>>>
>>> The way I'm doing it is the following (please correct me if there is a
>>> fundamental error in assumptions): I am actually using an RSSI circuit that
>>> is receiving the power from the USRPs/antennas, and I'm determining whether
>>> the phase offset is the same based on that RSSI value. For example, I run
>>> the flowgraph once, and I get an RSSI value on the other side of 2.5 mW,
>>> but when I run the flowgraph again, it produces an RSSI value of 9.5 mW. In
>>> my mind, if that offset was constant, then it would have produced something
>>> around 2.5 mW again. I know this adds another variable to the mix, but I
>>> have confirmed the accurate functioning of the RSSI circuit/receiver as
>>> well as the static nature of the channel, so its reading is very reliable.
>>>
>>> Could you describe this RSSI circuit? Normally, they're only sensitive
>>> to amplitude, not phase.
>>>
>>>
>>>
>>>
>>> On Tue, Jul 5, 2016 at 4:19 PM, Marcus D. Leech <mle...@ripnet.com>
>>> wrote:
>>>
>>>> On 07/05/2016 06:47 PM, Pavan Yedavalli wrote:
>>>>
>>>> Hi Marcus,
>>>>
>>>> Thanks for the background. That helps greatly. Having said that, I am
>>>> unclear which commands specifically tune the radios, so I did the following
>>>> around the frequency tuning (after all of the time source, gain, and
>>>> antenna setting code):
>>>>
>>>> addr_string = "addr0=192.168.10.3,addr1=192.168.10.4"
>>>> self.uhd_usrp_sink_0_0 = uhd.usrp_sink(
>>>> ",".join((addr_string, "")),
>>>> uhd.stream_args(
>>>> cpu_format="fc32",
>>>> channels=range(2),
>>>> ),
>>>> )
>>>>
>>>>
>>>> self.uhd_usrp_sink_0_0.set_clock_source("external", 0)
>>>> self.uhd_usrp_sink_0_0.set_time_source("external", 0)
>>>> self.uhd_usrp_sink_0_0.set_clock_source("mimo", 1)
>>>> self.uhd_usrp_sink_0_0.set_time_source("mimo", 1)
>>>> self.uhd_usrp_sink_0_0.set_samp_rate(samp_rate)
>>>> self.uhd_usrp_sink_0_0.set_gain(31.5, 0)
>>>> self.uhd_usrp_sink_0_0.set_gain(31.5, 1)
>>>> self.uhd_usrp_sink_0_0.set_antenna("TX/RX", 0)
>>>> self.uhd_usrp_sink_0_0.set_antenna("TX/RX", 1)
>>>> self.analog_sig_source_x_0_1 = analog.sig_source_c(samp_rate,
>>>> analog.GR_CONST_WAVE, 10000, 1, 0)
>>>> self.analog_sig_source_x_0_0_0 = analog.sig_source_c(samp_rate,
>>>> analog.GR_CONST_WAVE, 10000, 1, 0)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> * self.uhd_usrp_sink_0_0.set_time_unknown_pps(uhd.time_spec())
>>>> now = self.uhd_usrp_sink_0_0.get_time_now() start_time =
>>>> now + uhd.time_spec(.5)
>>>> self.uhd_usrp_sink_0_0.set_command_time(start_time)
>>>> self.uhd_usrp_sink_0_0.set_center_freq(915000000, 0)
>>>> self.uhd_usrp_sink_0_0.set_center_freq(915000000, 1)
>>>> self.uhd_usrp_sink_0_0.clear_command_time()*
>>>>
>>>>
>>>> However, when running it, this does not appear to produce a constant
>>>> offset either, but I'm not sure whether this is the correct code to wrap
>>>> around. Please keep me posted. Thanks.
>>>>
>>>> On Tue, Jul 5, 2016 at 12:49 PM, <mle...@ripnet.com> wrote:
>>>>
>>>>> That is precisely what I'm saying, and precisely what timed-commands
>>>>> for tuning were invented. On certain hardware, after the tune is
>>>>> complete,
>>>>> a phase-reset pulse is sent by the FPGA. The only way for THAT to have the
>>>>> desired effect is to make sure that the phase-reset pulse happens at the
>>>>> same instant.
>>>>>
>>>>> Modern synthesizers use a technique called fractional-N synthesis.
>>>>> One of the side effects of this is that you can't predict where the LO
>>>>> will
>>>>> "lock" with respect to the reference clock. So, any two PLL synthesizers,
>>>>> even when feed an identical reference clock, will not have the same phase
>>>>> offset with respect to one another. It's the "physics" of fractional-N
>>>>> PLL
>>>>> synthesis.
>>>>>
>>>>> SO, if you're using GRC to generate you flows, you'll have to modify
>>>>> the generated code, and wrap set_command_time()/clear_command_time()
>>>>> around
>>>>> the place in the code where it tunes the radios.
>>>>>
>>>>> Clearly, if this depends on TIME, then all radios involved need to
>>>>> agree on the current time, to high precision, hence the related
>>>>> requirement
>>>>> for set_time_unknown_pps(), which uses the 1PPS signal to trigger loading
>>>>> of the time-of-day clocks on each USRP in the multi_usrp object.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2016-07-05 15:41, Pavan Srikrishna Yedavalli wrote:
>>>>>
>>>>> I am using USRP N210 with SBX daughterboards. All devices are
>>>>> connected to the octoclock ref and octoclock PPS. It would be nice to get
>>>>> phase alignment, but mere coherence-with-an-offset is sufficient if that
>>>>> offset stays constant across different runs of the file/flowgraph. Are you
>>>>> saying that that offset cannot be constant due to the randomness of the LO
>>>>> phase offset at each run? Thanks again.
>>>>>
>>>>>
>>>>> _____________________________
>>>>> From: mle...@ripnet.com
>>>>> Sent: Tuesday, July 5, 2016 12:35 PM
>>>>> Subject: Re: [Discuss-gnuradio] random phase offset constantly
>>>>> changing with octoclock setup
>>>>> To: Pavan Yedavalli <psy2...@columbia.edu>
>>>>> Cc: Discuss-gnuradio <
>>>>> discuss-gnuradio-bounces+mleech=ripnet....@gnu.org>, GNURadio
>>>>> Discussion List <discuss-gnuradio@gnu.org>
>>>>>
>>>>>
>>>>> WHat specific hardware line-up do you have?
>>>>>
>>>>> You have to use set_time_unknown_pps(), but also, if you want phase
>>>>> alignment (as opposed to mere coherence-with-an-offset), you need to use
>>>>> timed tuning commands across your systems. This will result in zero
>>>>> relative phase offset between boards, if you're using SBX or UBX (on the
>>>>> X310). Note that this is phase between the boards, there's no way to make
>>>>> certain the the LO phase has a predictable offset with respect to external
>>>>> received signals, only that the two LO phases agree.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2016-07-05 15:26, Pavan Yedavalli wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Despite all of my boards being connected via the Octoclock (ref and
>>>>> pps), I am constantly getting different phase offsets every time I run a
>>>>> gnuradio flowgraph (or python file).
>>>>>
>>>>> I am not sure why this is happening, but I do know that I need to call
>>>>> one of the functions, set_time_now() and/or set_time_unknown_pps(), to
>>>>> make
>>>>> sure all of them are synced. Which one am I supposed to call? I have been
>>>>> calling set_time_unknown_pps(), but I am getting the above/below problem
>>>>> with that, so maybe set_time_now() could be correct?
>>>>>
>>>>> In general, I don't understand why I continually get a different
>>>>> random phase offset of all of the radios after every new flowgraph run.
>>>>> Shouldn't this offset be the same if I continue to transmit at the same
>>>>> frequency? Would one of the above functions fix that?
>>>>>
>>>>> Hopefully that is clear. Thank you so much for the help.
>>>>>
>>>>> --
>>>>> Pavan
>>>>>
>>>>> _______________________________________________
>>>>> Discuss-gnuradio mailing list
>>>>> Discuss-gnuradio@gnu.org
>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Pavan
>>>>
>>>> How are you measuring the phase-offset between the two sinks?
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Pavan
>>>
>>>
>>>
>>
>>
>> --
>> Pavan
>>
>>
>>
>
>
> --
> Pavan
>
>
>
--
Pavan
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
