Re: [Discuss-gnuradio] Python synchronisation of 2xUSRP N200 with SBX in one UHD container.

[John Shields]

Thanks,
            I have attached the GRC. I should note that before I run, I 
wait until GPS is locked as evinced by the query_gpsdo_sensor utility:

            GPS Locked
            Trying to align the device time to GPS time...
            GPS and UHD Device time are aligned.
            last_pps: 1505763709 vs gps: 1505763709.
            Printing available NMEA strings:
            GPS_GPGGA: 
$GPGGA,194149.00,4331.1729,S,17234.2461,E,2,09,1.5,32.2,M,8.5,M,,*7B
            GPS_GPRMC: 
$GPRMC,194149.00,A,4331.1729,S,17234.2461,E,0.2,0.0,180917,,*20
            GPS Epoch time at last PPS: 1505763710.00000 seconds
            UHD Device time last PPS:   1505763710.00000 seconds
            UHD Device time right now:  1505763710.01897 seconds
            PC Clock time:              1505763710 seconds

            Done!

            Kind Regards,

                   John

p.s. In Jan 2016, Nigel wrote that one of the steps needed to align 
included 'Use integer_N_ mode for PLL' when I tried to use the method 
you recommended, I got an error so ceased that line of investigation for 
the moment - is integer_N_mode tuning required?



On 18/09/17 16:27, Marcus D. Leech wrote:
> On 09/18/2017 12:41 AM, John Shields wrote:
> > Thanks, as always, Marcus,
> >                                            Here is the relevant code 
> > I am executing:
> >
> >         self.uhd_usrp_source_0.set_clock_source('gpsdo', 0)
> >         self.uhd_usrp_source_0.set_time_source('gpsdo', 0)
> >         self.uhd_usrp_source_0.set_clock_source('mimo', 1)
> >         self.uhd_usrp_source_0.set_time_source('mimo', 1)
> >         self.uhd_usrp_source_0.set_samp_rate(samp_rate)
> > self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
> >     # now put in code to make sure that both usrps have seen at least 
> > 1 pps - pulse
> >     # self.save_last_pps=self.uhd_usrp_source_0.get_last_pps(0)
> >     # as the USRPs have been running for hours will tackle the 'spin 
> > until get_last_pps changes' code later
> >
> >     # inserted code to synch LO and, by way of the mechanism, align 
> > the CORDICs
> > self.tune_time=self.uhd_usrp_source_0.get_time_now(0)+uhd.time_spec_t(0.1) 
> > # tune in 100 msecs from 'now'
> >         self.uhd_usrp_source_0.set_command_time(self.tune_time)
> >         self.uhd_usrp_source_0.set_center_freq(freq, 0)
> >         self.uhd_usrp_source_0.set_center_freq(freq, 1)
> >         self.uhd_usrp_source_0.clear_command_time()
> >
> >         self.uhd_usrp_source_0.set_gain(rf_gain+.45, 0)
> >         self.uhd_usrp_source_0.set_antenna('RX2', 0)
> >
> >         self.uhd_usrp_source_0.set_gain(rf_gain, 1)
> >         self.uhd_usrp_source_0.set_antenna('RX2', 1)
> >
> >     when I run the FG, I get variable results - I attach 2 
> > screenshots which show the averaged phase difference is 74-odd 
> > degrees for one run and the next run the result is 101-odd degrees. 
> > Clearly, I am doing something wrong but, for the life of me, I cannot 
> > figure it out. For completeness, I will later put this code, when it 
> > works into the set_freq function but I don't have this parameter 
> > changeable in the FG.
> >
> >           Kind Regards,
> >
> >                   John
> Mayhaps you could share the flow-graph from which this is derived? 
> (Done in GRC I assume?)
>
> > > > self.uhd_usrp_source_0.set_clock_source('gpsdo', 0)
> > > >         self.uhd_usrp_source_0.set_time_source('gpsdo', 0)
> > > >         self.uhd_usrp_source_0.set_clock_source('mimo', 1)
> > > >         self.uhd_usrp_source_0.set_time_source('mimo', 1)
> > > >         self.uhd_usrp_source_0.set_samp_rate(samp_rate)
> > > > self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
> > > >     # inserted code to align CORDICs ?
> > > >
> > > >
> > > >     # inserted code to synch LO
> > > > self.tune_time=self.uhd_usrp_source_0.get_time_now(0)+uhd.time_spec_t(0.1) 
> > > > # tune in 100 msecs from 'now'
> > > > self.uhd_usrp_source_0.set_command_time(self.tune_time)
> > > >         self.uhd_usrp_source_0.set_center_freq(freq, 0)
> > > >         self.uhd_usrp_source_0.set_center_freq(freq, 1)
> > > >         self.uhd_usrp_source_0.clear_command_time()
> > > >
> > > >
> > > >         self.uhd_usrp_source_0.set_gain(rf_gain, 0)
> > > >         self.uhd_usrp_source_0.set_antenna('RX2', 0)
> > > >
> > > >         self.uhd_usrp_source_0.set_gain(rf_gain, 1)
> > > >         self.uhd_usrp_source_0.set_antenna('RX2', 1)
> > > >
> > > >
> > > > While there is a discussion on the web re: the tune_time which 
> > > > seems to suggest, I could just put in the, uhd.time_spec_t(0.1), 
> > > > there is a comment from Josh saying to make sure the time is in the 
> > > > future so that is why I added the time now.
> > > >
> > > >
> > > > In that same thread there were comments to the effect that 
> > > > stream_cmds have not been swig-ed as the control of streaming is 
> > > > part of the scheduler so:
> > > >
> > > > questions:
> > > >
> > > >     1) have I got the correct code to synch the LO i.e. by tuning 
> > > > both devices at the same exact time?
> > > Yes.  That will have the effect of asserting the "phase resynch" pin 
> > > on the SBX's synthesizer at the exact same time.
> > >
> > > >     2) based on the comment about stream synch being controlled by 
> > > > the scheduler, what do I need to do re: synching the CORDICs?
> > > That should happen as a side effect of tuning at the same time.
> > >
> > > >     3) I have noticed that sometimes when I print out the 
> > > > real_seconds of time_now, it has a low number (likely the number of 
> > > > seconds the USRPs have been running.
> > > >
> > > >     -- Setting references to the internal GPSDO
> > > >     --     1) catch time transition at pps edge
> > > >     --     2) set times next pps (synchronously)
> > > >
> > > >         I presume that I am reading the time_now before it is 
> > > > synched at the next pps where the value of time goes to 
> > > > 1505510864.00000 . If the answer to 1) is that my code is correct, 
> > > > how do I make sure that the pps edge has occurred before I 
> > > > get_time_now ?
> > > Do a get_time_last_pps, saved that value.  Spin doing 
> > > get_time_last_pps until it is different from the saved value. Pause 
> > > a few 10s of milliseconds on each
> > >   spin.
> > >
> > >
> > > >     4) the sync document also implies that the phase offset will 
> > > > drift (due to thermal and other characteristics) so phase-coherent 
> > > > applications will need re-calibration. is this done by somehow 
> > > > stopping the stream(s), doing a set_freq and whatever the answer to 
> > > > 2) above is and then restarting. I am trying to collect complex 
> > > > visibilities over a long period of time ( i.e. fringe stopping) so 
> > > > wonder if the drift is slow enough whether I need to do the 
> > > > "calibration" mentioned in the sync doc?
> > > Slow phase rotation is just a an inevitable property of analog 
> > > hardware and temperature differentials.   Some of the big 
> > > observatories do active
> > >   mitigation by sending measurement tones down the coax toward the 
> > > antenna and measuring phase slip, and compensating.
> > >
> > > In my experience, I don't see this on our 600Mhz interferometer 
> > > after it has equilibrated after start-up.
> > >
> > > What is the reason for fringe-stopping?  In small-scale amateur 
> > > observations, it is mostly a  "frill".  I have thought of using it 
> > > for interferometric
> > >   pulsar observations, where you want to keep the correlation at 
> > > maximum over a long period (at least as long as the primary 
> > > field-of-view).
> > >
> > >
> > > >                           Kind Regards,
> > > >
> > > >
> > > >                                        John
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Discuss-gnuradio mailing list
> > > > address@hidden
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > >
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > address@hidden
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Phasor_multi.grc
Description: application/gnuradio-grc