Thanks Marcus,
Here is the output of test_pps_input for the mate N200
connected through MIMO cable:
john@i7ubuntu:~$ test_pps_input --args addr=192.168.20.2 --source=mimo
linux; GNU C++ version 6.3.0 20170406; Boost_106200;
UHD_003.010.002.000-3-g122bfae1
Creating the usrp device with: addr=192.168.20.2...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Using Device: Single USRP:
Device: USRP2 / N-Series Device
Mboard 0: N200r4
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: SBXv3 RX
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: SBXv3 TX
Attempt to detect the PPS and set the time...
-- 1) catch time transition at pps edge
Error: RuntimeError: Board 0 may not be getting a PPS signal!
No PPS detected within the time interval.
See the application notes for your device.
john@i7ubuntu:~$
so the problem is obvious but is there anything I can have done wrong such that
the PPS would not get over the MIMO?
If I had another N200 and/or another MIMO cable, I would try them but,
unfortunately, I don’t have such.
Kind Regards,
John
From: [email protected]
Sent: Wednesday, September 20, 2017 4:09 AM
To: John Shields
Cc: usrp-users
Subject: Re: [USRP-users] N200 MIMO PPS not being detected on mate...
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
---
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
