On 2021-11-23 17:19, isaac mario tupac davila wrote:
Hi Marcus
-->Are both of these N210 in the same flow-graph, in a multi-Usrp object?
I'm using two Pc's. One for Tx and the other for Rx. So, two
flow-graph, each in one Pc.
-->You might try "Next PPS" instead of "Unknown" PPS.
Interesting method the next PPS
:usrp->set_time_next_pps(uhd::time_spec_t
<https://files.ettus.com/manual/classuhd_1_1time__spec__t.html>(0.0));
As i understood from the example given here
:https://files.ettus.com/manual/page_sync.html, I can recognize my
last pps and then establish my synchronization with the next PPS.
When I look at the sync parameter of my UHD:USRP source block in GRC,
it only give me the options of unknown PPS, PC clock and don't sync.(
GNURadio:3.7.13.4 UHD_3.14.0.HEAD-0-g6875d061)
How do I utilize the "next pps" method if my UHD:USRP source block
doesn't give me that option for the sync parameter?
-->But you may still need to modify the code generated by GRC for this
particular app, and it's unclear to me why you need to delay the PPS
pulse.....
What I have is an external generator of PPS (No trimble) that
generates a PPS pulse in a specific hour. So I want the USRP's could
catch the PPS pulse at that hour, make the synchronization and start
the tx and rx. To do it, the flowgraphs in my pc's have to start
before that hour (seconds before), so that they can wait for that
pulse. But the UHD:USRP source and sink blocks only wait a few seconds
for the PPS pulse. So, I'd like to wait for more time that PPS pulse
to catch it....
Regards
Isaac T.
YOu'll need to modify the code to use "set_time_next_pps()" then. Since
the Gnu Radio block doesn't support that option. The Gnu Radio blocks
DO NOT reflect 100%
of the available UHD API. Sometimes, you'll need to modify things.
El lun, 22 nov 2021 a las 19:47, Marcus D. Leech
(<patchvonbr...@gmail.com>) escribió:
On 2021-11-22 17:37, isaac mario tupac davila wrote:
Hello everyone
My name is Isaac. I'm doing some probes of synchronization
between two USRP's N200 and a trimble. What I'd like to do is the
USRP's wait a specific time (3-5 seconds) before starting to send
and receive data synchronize. So, I run my GRC flowgraph but I
don't put the PPS pulse in the USRP's for that "wait" time. But
what I see is:
[32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 7.5.0;
Boost_106501; UHD_3.14.0.HEAD-0-g6875d061
[32;1m[INFO] [USRP2] [39;0mOpening a USRP2/N-Series device...
[32;1m[INFO] [USRP2] [39;0mCurrent recv frame size: 1472 bytes
[32;1m[INFO] [USRP2] [39;0mCurrent send frame size: 1472 bytes
[33;1m[WARNING] [UHD] [39;0mUnable to set the thread priority.
Performance may be negatively affected.
Please see the general application notes in the manual for
instructions.
EnvironmentError: OSError: error in pthread_setschedparam
[32;1m[INFO] [MULTI_USRP] [39;0m 1) catch time transition at
pps edge
Traceback (most recent call last):
File
"/home/soporte/Isaac/PruebaParaUSRP/TransmisiónUSRP/top_block.py",
line 145, in <module>
main()
File
"/home/soporte/Isaac/PruebaParaUSRP/TransmisiónUSRP/top_block.py",
line 133, in main
tb = top_block_cls()
File
"/home/soporte/Isaac/PruebaParaUSRP/TransmisiónUSRP/top_block.py",
line 79, in __init__
self.uhd_usrp_sink_0.set_time_unknown_pps(uhd.time_spec())
File
"/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 4814, in set_time_unknown_pps
return _uhd_swig.usrp_sink_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.*
*
*
It seems the UHD:USRP sink and UHD:USRP source have a short wait
time for the PPS pulse.
¿ Is there a way to get a longer wait time for the PPS pulse in
GNU Radio?....If it is not possible, any advice or idea to deal
with it will be appreciated.
Regards
Isaac T.
Are both of these N210 in the same flow-graph, in a multi-Usrp object?
You might try "Next PPS" instead of "Unknown" PPS.
But you may still need to modify the code generated by GRC for
this particular app, and it's unclear to me why you need to delay
the PPS pulse.
