Hi Marcus,
Trying the attached code with two of the USRPs transmitting, and with the
B210_Phase_Viewer for the other 2 USRPs receiving, still gives me different
offsets for every different run call. And by different run call, I'm simply
running the flowgraph once, seeing the offset, stopping the graph, and then
running it again, seeing the new offset, and so on. I must be doing
something wrong here. A you mentioned, since all of them are using the
Octoclock, that means that they all are having the same reference and pps,
but both receive boards may also not be timed in an aligned fashion for the
same reason, right? So the receive side LO offsets could also be causing
problems in narrowing down the issue, I'm assuming? Thanks again.
On Wed, Jul 6, 2016 at 5:47 PM, Marcus D. Leech <mle...@ripnet.com> wrote:
> On 07/06/2016 02:48 PM, Pavan Yedavalli wrote:
>
> I disconnected the MIMO cable and now have all 4 directly connected to the
> Octoclock, but I get the same results in which the offset changes at every
> run (using the above code).
>
> What about the attached code?
>
> Keep in mind that you'll have to measure it with something that is also
> mutually coherent.
>
>
>
>
> On Tue, Jul 5, 2016 at 9:11 PM, Marcus D. Leech <mle...@ripnet.com> wrote:
>
>> On 07/05/2016 11:45 PM, Pavan Yedavalli wrote:
>>
>> 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.
>>
>> So, a useful experiment would be to do your coherent TX from a pair that
>> are both hooked up to the Octoclock.
>>
>>
>>
>>
>> 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
>>
>>
>>
>
>
> --
> Pavan
>
>
>
--
Pavan
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
