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
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
