Try using the --source argument to test_pps_input, specifying "mimo" for
the mimo-connected unit.
Device addressing is "addressed" here:
https://files.ettus.com/manual/page_usrp2.html#usrp2_
You should probably also investigate using integer_n tuning, which will
definitely improve phase-coherence, but carries with it certain
penalties, AFAIR, like much-coarser frequency step size.
On 2017-09-19 02:56, John Shields via USRP-users wrote:
> Have been getting help on the Discuss-gnuradio site but I think, recent
> investigations indicate this forum might be a better place to raise my
> further questions.
>
> I have 2 N200r4s each with an SBXv3. The unit with address 192.168.10.2 has
> an O/B GPSDO and both units are connected by a MIMO cable. I am feeding an
> attenuated signal, through a splitter to both units and am calculating the
> phase offset.
>
> Ubuntu 17.04, GNURadio 3.10.2.000 and both USRPs have been updated to the
> correct FW (12.4) and FPGA (11.1).
>
> I utilise GRC to come up with a simple FG.
> When both usrps are in the same container, I can get both channels to work
> and the phase offset calculation seems to work but each time I run the FG, I
> get a different offset. In order to mitigate for this, I have included the
> set_command_time and clear_command_time code (in Python) from your sync page
> (and Marcus L has verified it looks good) but still there is an offset which
> is constant but changes between runs.
>
> When I run test_pps_input for ...10.2 it says it found an internal GPSDO
> Jackson...... Firmware Rev 0.926 and reports the attempt to detect the pps
> and set next time as Success!
> " " " 20.2 it says the same
> and in both cases there is ethernet traffic to both devices.
>
> Anyway, in order to debug the variable phase offset situation further, I
> decided to run the USRPs in separate UHD containers but with the same options
> 10.2 Clock src & Time src both O/B GPSDO and for 20.2 both MIMO cable and
> both source blocks have Sync as "unknown PPS".
>
> With query_gpsdo_sensors indicating "GPS Lock" I proceed to attempt to run
> the modified FG, I get:
>
> Detecting internal GPSDO.... No GPSDO found
> -- 1) catch time transition at pps edge
> Traceback (most recent call last):
> File "/home/john/top_block.py", line 401, in <module>
> main()
> File "/home/john/top_block.py", line 389, in main
> tb = top_block_cls(tpint=options.tpint)
> File "/home/john/top_block.py", line 106, in __init__
> self.uhd_usrp_source_1.set_time_unknown_pps(uhd.time_spec())
> File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
> 3787, in set_time_unknown_pps
> return _uhd_swig.usrp_source_sptr_set_time_unknown_pps(self, time_spec)
> RuntimeError: RuntimeError: Board 0 may not be getting a PPS signal!
> No PPS detected within the time interval.
> See the application notes for your device.
>
> I have determined that 'Board 0' is ...20.2 by replacing that block with a
> null source under which configuration the FG runs.
>
> So my questions are:
>
> 1) in a MIMO cable connected system such as this, when I run test_pps_input
> on the mate, is it correct for that utility to report that the mate has an
> 'internal GPSDO' and to set things up using it?
>
> 2) if the answer to 1) is No, then what could I have done/not done to cause
> this error condition?
>
> 3) if the answer to 1) is Yes, then why does the mate block not detect PPS
> when test_pps_input says it can?
>
> 4) in the case of dual usrps in the same container, for the Device Address
> field I put in: addr0=192.168.10.2,addr1=192.168.20.2 - is this correct? I
> only mention this because, if I have a USRP1 powered on, the original FG
> would detect it, saying it was opening "a USRP1 device" and would bomb out on
> set_clock_source. So it seems that my address parameters might not be
> specific enough!
>
> 5) if 4) is in error, in the case where I have individual UHD sources, for
> the Device Address fields I have: addr=192.168.10.2 and addr=192.168.20.2
> respectively. Is this the correct? even with a USRP1 powered, it only Open a
> "USRP2/N-Series device" so it seems to find the devices I want only.
>
> Kind Regards,
>
> John
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
