It's an Octoclock-G (https://www.ettus.com/product/details/OctoClock-G is
what I ordered). And yes, that is true about the external clock inputs and
GPS lock. Does that matter if it's an Octoclock-G?
On Thu, Jul 7, 2016 at 7:46 PM, <mle...@ripnet.com> wrote:
> Is this an Octoclock, or Octoclock-G?
>
> If it's just an Octoclock, then it has no internal clocks, and acts as a
> high-quality clock/pps distributor.
>
> I notice you don't have the external clock inputs connected to anything,
> and there's no GPS LOCK indicator.
>
>
>
>
>
>
>
>
> On 2016-07-07 17:08, Pavan Yedavalli wrote:
>
> Hi Marcus,
>
> I did what you suggested by wrapping the timed commands as follows:
>
> For the TX side (what you sent me in for_pavan.py):
>
> self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
> now = self.uhd_usrp_source_0.get_time_now()
> start_time = now + uhd.time_spec(.5)
> self.uhd_usrp_source_0.set_command_time(start_time)
> self.uhd_usrp_source_0.set_clock_source("external", 0)
> self.uhd_usrp_source_0.set_time_source("external", 0)
> self.uhd_usrp_source_0.set_clock_source("external", 1)
> self.uhd_usrp_source_0.set_time_source("external", 1)
> self.uhd_usrp_source_0.set_samp_rate(samp_rate)
> self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
> self.uhd_usrp_source_0.set_center_freq(rx_center_freq, 0)
> self.uhd_usrp_source_0.set_normalized_gain(rx_gain, 0)
> self.uhd_usrp_source_0.set_antenna(Antenna_sel, 0)
> self.uhd_usrp_source_0.set_center_freq(rx_center_freq, 1)
> self.uhd_usrp_source_0.set_normalized_gain(rx_gain, 1)
> self.uhd_usrp_source_0.set_antenna("TX/RX", 1)
> self.uhd_usrp_source_0.clear_command_time()
>
> And for the RX side (B210_Phase_Viewer.py):
>
> self.uhd_usrp_sink_0.set_time_unknown_pps(uhd.time_spec())
> now = self.uhd_usrp_sink_0.get_time_now()
> start_time = now + uhd.time_spec(.5)
> self.uhd_usrp_sink_0.set_command_time(start_time)
> self.uhd_usrp_sink_0.set_clock_source("external", 0)
> self.uhd_usrp_sink_0.set_time_source("external", 0)
> self.uhd_usrp_sink_0.set_subdev_spec("A:0", 0)
> self.uhd_usrp_sink_0.set_clock_source("external", 1)
> self.uhd_usrp_sink_0.set_time_source("external", 1)
> self.uhd_usrp_sink_0.set_subdev_spec("A:0", 1)
> self.uhd_usrp_sink_0.set_samp_rate(samp_rate)
> self.uhd_usrp_sink_0.set_center_freq(915e6, 0)
> self.uhd_usrp_sink_0.set_gain(1.5, 0)
> self.uhd_usrp_sink_0.set_center_freq(915e6, 1)
> self.uhd_usrp_sink_0.set_gain(1.5, 1)
> self.uhd_usrp_sink_0.clear_command_time()
>
>
> However, it still does not work when I have the phase viewer running and
> stop and restart the for_pavan.py flowgraph. I had a run of three straight
> where the phase offset was around 11 degrees, but then afterward it started
> fluctuating again (-140, 45, 81 degrees, etc.).
>
> Attached is the front of the Octoclock. I believe the settings are
> correct, but maybe something is wrong with that. Note that the PPS flashes
> (but I couldn't capture when it flashed in the picture). Also note that I
> get the thread priority warning when running each of them, but I don't
> think that is a problem.
>
> I am really not sure what the issue is here, sadly. Thanks again for your
> help and patience.
>
>
> On Wed, Jul 6, 2016 at 6:22 PM, Marcus D. Leech <mle...@ripnet.com> wrote:
>
>> On 07/06/2016 09:04 PM, Pavan Yedavalli wrote:
>>
>> 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.
>>
>> Yes, the receive side needs to be as mutually-coherent as possible as
>> well.
>>
>> Also, I forgot to mention that you'll need to modify the output of the
>> flow-graph I provided to wrap timed-command stuff around the tuning.
>>
>> Same on any RX flow-graph. That's the only sane we to be able to measure
>> any kind of phase-offset that you can trust.
>>
>> If the RX side is a B210, you don't need to do timed commands (and,
>> indeed, they aren't supported for tuning on the B210). What I'd do is
>> leave the RX side running, while you bring the TX side up and down.
>>
>>
>>
>>
>> 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
>>
>>
>
>
> --
> Pavan
>
>
--
Pavan
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
