I built Gnuradio from the source, Gnuradio version 3.8.1 with UHD 4.1.04 or
UHD 4.0.0(I tested with  all UHD versions)
now when I want to install gr-ettus oot in Gnuraadio  I am faced with the
below errors...
How can I solve this problem?

Thanks in advance

[ 64%] Swig source ettus_swig.i
Deprecated command line option: -modern. This option is now always on.
/home/sp/Documents/gr-ettus-1038c4ce5135a2803b53554fc4971fe3de747d9a/swig/ettus_swig.i:140:
Error: Template 'set_property' undefined.
/home/sp/Documents/gr-ettus-1038c4ce5135a2803b53554fc4971fe3de747d9a/swig/ettus_swig.i:141:
Error: Template 'set_property' undefined.
/home/sp/Documents/gr-ettus-1038c4ce5135a2803b53554fc4971fe3de747d9a/swig/ettus_swig.i:142:
Error: Template 'set_property' undefined.
/home/sp/Documents/gr-ettus-1038c4ce5135a2803b53554fc4971fe3de747d9a/swig/ettus_swig.i:143:
Error: Template 'set_property' undefined.
/home/sp/Documents/gr-ettus-1038c4ce5135a2803b53554fc4971fe3de747d9a/swig/ettus_swig.i:145:
Error: Template 'get_property' undefined.
/home/sp/Documents/gr-ettus-1038c4ce5135a2803b53554fc4971fe3de747d9a/swig/ettus_swig.i:146:
Error: Template 'get_property' undefined.
/home/sp/Documents/gr-ettus-1038c4ce5135a2803b53554fc4971fe3de747d9a/swig/ettus_swig.i:147:
Error: Template 'get_property' undefined.
/home/sp/Documents/gr-ettus-1038c4ce5135a2803b53554fc4971fe3de747d9a/swig/ettus_swig.i:148:
Error: Template 'get_property' undefined.
/usr/local/include/uhd/types/dict.hpp:145: Warning 503: Can't wrap
'operator std::mapstd::string,std::string' unless renamed to a valid
identifier.
make[2]: ***
[swig/CMakeFiles/ettus_swig_swig_compilation.dir/build.make:65:
swig/CMakeFiles/ettus_swig.dir/ettus_swigPYTHON.stamp] Error 8
make[2]: *** Deleting file
'swig/CMakeFiles/ettus_swig.dir/ettus_swigPYTHON.stamp'
make[1]: *** [CMakeFiles/Makefile2:421:
swig/CMakeFiles/ettus_swig_swig_compilation.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

Hi,
I am using mixed types of USRPs in my applications, namely, X310 and N310. The signals are timed. I find 0.2-second time difference between these two USRPs.Details:Each USRP is controlled by a Linux server;
The same Linux version in all PCs;All USRPs are connected to the same Octoclock;
UHD version is 4.1.0 in Linux servers;All Linux servers are connected to a control PC which is the client;The sampling rates are different: 184.32MHz in X310 USRP and 245.76MHz in N310 USRP
Control PC sends command to set time 0 after PPS in all USRPs, then query the time in each of them.The time difference between USRPs of the same type is small, ~2ms, but the time difference between different types of USRP is much bigger, ~0.2s.Times should be impacted by sampling rate; when setting timers, no signal is transmitted.
2ms time difference between USRPs could be due to network delay; 200ms can't be because of network. It seems to be due to HW in USRPs. Does this mean that X310 and N310 are not synchronized?
Thanks for any comment,
Hongwei

Hi,

We had the exact same issue a couple months ago between an N320 and an X310. The issue is that the N320 (and I'm guessing the N310) detects the 1PPS pulse on the rising edge, as expected. The X310 detects the 1PPS edge on the falling edge. Note that the 1PPS pulse from the Octoclock stays high for about 200ms, so I'm guessing this is the issue you are seeing.

We ended up making our own custom FPGA build for the X310. We modified the file:
"uhd/fpga/usrp3/lib/rfnoc/utils/timekeeper.v".

Originally, the PPS edge detection looked like:
pps_edge<= pps_del & ~pps;

We changed it to:
pps_edge<= ~pps_del & pps;

It would be good if this could get "fixed" in UHD, as it would be nice to not have to maintain a custom FPGA build. I'm not sure what effect this change will have on other USRP FPGA builds that use the same timekeeper.v file.

In any case, I'm guessing this is your problem.

Jim

From: zhou via USRP-users usrp-users@lists.ettus.com
Sent: Monday, December 20, 2021 5:31 AM
To: usrp-users@lists.ettus.com usrp-users@lists.ettus.com; Marcus Müller marcus.mueller@ettus.com
Subject: [USRP-users] Time different between X310 and N310 USRPs using UHD4.1.0

Hi,

I am using mixed types of USRPs in my applications, namely, X310 and N310. The signals are timed. I find 0.2-second time difference between these two USRPs.
Details:
Each USRP is controlled by a Linux server;
The same Linux version in all PCs;
All USRPs are connected to the same Octoclock;
UHD version is 4.1.0 in Linux servers;
All Linux servers are connected to a control PC which is the client;
The sampling rates are different: 184.32MHz in X310 USRP and 245.76MHz in N310 USRP

Control PC sends command to set time 0 after PPS in all USRPs, then query the time in each of them.
The time difference between USRPs of the same type is small, ~2ms, but the time difference between different types of USRP is much bigger, ~0.2s.
Times should be impacted by sampling rate; when setting timers, no signal is transmitted.

2ms time difference between USRPs could be due to network delay; 200ms can't be because of network. It seems to be due to HW in USRPs. Does this mean that X310 and N310 are not synchronized?

Thanks for any comment,

Hongwei

Hi Jim,
Thank you so much for your quick reply. Your finding is very interesting and I believe it is very related to my problem.After some thinking, I am still having some confusion:Because N320 and X310 USRPs are using different pulse edges, their time 0s are actually different by 200ms in universal time, but their internal timers should be similar. When querying their time respectively, we should get similar time - the responses are their internal times. But I am seeing 200ms difference.
Could you please give some comments on this?
Thanks a lot,
Hongwei

On Monday, 20 December 2021, 11:04:09 GMT, Jim Palladino <jim@gardettoengineering.com> wrote:  

Hi,
We had the exact same issue a couple months ago between an N320 and an X310. The issue is that the N320 (and I'm guessing the N310) detects the 1PPS pulse on the rising edge, as expected. The X310 detects the 1PPS edge on the falling edge. Note that the 1PPS pulse from the Octoclock stays high for about 200ms, so I'm guessing this is the issue you are seeing. 
We ended up making our own custom FPGA build for the X310. We modified the file:
"uhd/fpga/usrp3/lib/rfnoc/utils/timekeeper.v".

Originally, the PPS edge detection looked like:
pps_edge<= pps_del & ~pps;

We changed it to:pps_edge<= ~pps_del & pps;

It would be good if this could get "fixed" in UHD, as it would be nice to not have to maintain a custom FPGA build. I'm not sure what effect this change will have on other USRP FPGA builds that use the same timekeeper.v file.
In any case, I'm guessing this is your problem.
Jim

From: zhou via USRP-users usrp-users@lists.ettus.com
Sent: Monday, December 20, 2021 5:31 AM
To: usrp-users@lists.ettus.com usrp-users@lists.ettus.com; Marcus Müller marcus.mueller@ettus.com
Subject: [USRP-users] Time different between X310 and N310 USRPs using UHD4.1.0 Hi,
I am using mixed types of USRPs in my applications, namely, X310 and N310. The signals are timed. I find 0.2-second time difference between these two USRPs.Details:Each USRP is controlled by a Linux server;
The same Linux version in all PCs;All USRPs are connected to the same Octoclock;
UHD version is 4.1.0 in Linux servers;All Linux servers are connected to a control PC which is the client;The sampling rates are different: 184.32MHz in X310 USRP and 245.76MHz in N310 USRP
Control PC sends command to set time 0 after PPS in all USRPs, then query the time in each of them.The time difference between USRPs of the same type is small, ~2ms, but the time difference between different types of USRP is much bigger, ~0.2s.Times should be impacted by sampling rate; when setting timers, no signal is transmitted.
2ms time difference between USRPs could be due to network delay; 200ms can't be because of network. It seems to be due to HW in USRPs. Does this mean that X310 and N310 are not synchronized?
Thanks for any comment,
Hongwei

Hongwei,

If this is your problem, then "get_time_last_pps()" should report the same time between the X310 and N320, unless you happen to ask it (or if you set it) during that 200ms window between the 1pps rising and falling edges.

However, like you said, absolute time will be off by 200ms. So, since the falling edge occurs 200ms after the rising edge of the 1pps pulse, the X310 will not start at 0s until 200ms after the N320 (or I assume N310). So, if you issue the "get_time_now()" command at the same time to both devices, the X310 will be 200ms behind the N320.

To see if this is the issue, you could try to rebuild the X310 FPGA image with the fix, or you could try inverting the Octoclock output if you have an inverter (to see if the offset shifts the other way). To help us confirm that this was our issue, we used a function generator instead of the Octoclock to generate the 1pps to both devices. Then, we varied the duty cycle of the 1pps pulse and saw that the time difference between the two devices tracked the duty cycle (the time that the 1pps pulse is high per second).

Also, the way we were setting the time, it actually looked like we were off by 800ms because we'd tell the USRPs to set their time to a specific value after the next pps. But, we'd issue this command right after the rising edge of the 1PPS pulse. So, this would set the N320 to the time we specified 1 second later (when the next rising edge occurs). However, the X310 would see the falling edge occur 200ms after issuing this command. So, it would set it's time then. So, the way we were doing it, the X310 was actually getting set 800ms earlier than the N320.

Hope this helps.
Jim

From: zhou hwzhou@yahoo.com
Sent: Monday, December 20, 2021 7:50 AM
To: usrp-users@lists.ettus.com usrp-users@lists.ettus.com; Marcus Müller marcus.mueller@ettus.com; Jim Palladino jim@gardettoengineering.com
Subject: Re: [USRP-users] Time different between X310 and N310 USRPs using UHD4.1.0

Hi Jim,

Thank you so much for your quick reply. Your finding is very interesting and I believe it is very related to my problem.
After some thinking, I am still having some confusion:
Because N320 and X310 USRPs are using different pulse edges, their time 0s are actually different by 200ms in universal time, but their internal timers should be similar. When querying their time respectively, we should get similar time - the responses are their internal times. But I am seeing 200ms difference.

Could you please give some comments on this?

Thanks a lot,
Hongwei

On Monday, 20 December 2021, 11:04:09 GMT, Jim Palladino jim@gardettoengineering.com wrote:

Hi,

We had the exact same issue a couple months ago between an N320 and an X310. The issue is that the N320 (and I'm guessing the N310) detects the 1PPS pulse on the rising edge, as expected. The X310 detects the 1PPS edge on the falling edge. Note that the 1PPS pulse from the Octoclock stays high for about 200ms, so I'm guessing this is the issue you are seeing.

We ended up making our own custom FPGA build for the X310. We modified the file:
"uhd/fpga/usrp3/lib/rfnoc/utils/timekeeper.v".

Originally, the PPS edge detection looked like:
pps_edge<= pps_del & ~pps;

We changed it to:
pps_edge<= ~pps_del & pps;

It would be good if this could get "fixed" in UHD, as it would be nice to not have to maintain a custom FPGA build. I'm not sure what effect this change will have on other USRP FPGA builds that use the same timekeeper.v file.

In any case, I'm guessing this is your problem.

Jim

From: zhou via USRP-users usrp-users@lists.ettus.com
Sent: Monday, December 20, 2021 5:31 AM
To: usrp-users@lists.ettus.com usrp-users@lists.ettus.com; Marcus Müller marcus.mueller@ettus.com
Subject: [USRP-users] Time different between X310 and N310 USRPs using UHD4.1.0

Hi,

I am using mixed types of USRPs in my applications, namely, X310 and N310. The signals are timed. I find 0.2-second time difference between these two USRPs.
Details:
Each USRP is controlled by a Linux server;
The same Linux version in all PCs;
All USRPs are connected to the same Octoclock;
UHD version is 4.1.0 in Linux servers;
All Linux servers are connected to a control PC which is the client;
The sampling rates are different: 184.32MHz in X310 USRP and 245.76MHz in N310 USRP

Control PC sends command to set time 0 after PPS in all USRPs, then query the time in each of them.
The time difference between USRPs of the same type is small, ~2ms, but the time difference between different types of USRP is much bigger, ~0.2s.
Times should be impacted by sampling rate; when setting timers, no signal is transmitted.

2ms time difference between USRPs could be due to network delay; 200ms can't be because of network. It seems to be due to HW in USRPs. Does this mean that X310 and N310 are not synchronized?

Thanks for any comment,

Hongwei

Hi Jim,
Thanks for your explanation. I got it. Inverter may be a quick solution; just the duty cycle will become 80% after conversion. I will definitely try it. If not, I will rebuild X310 FPGA as you suggested.
Have a Merry Christmas and happy New Year,
Hongwei

On Monday, 20 December 2021, 13:18:23 GMT, Jim Palladino <jim@gardettoengineering.com> wrote:  

Hongwei,
If this is your problem, then "get_time_last_pps()" should report the same time between the X310 and N320, unless you happen to ask it (or if you set it) during that 200ms window between the 1pps rising and falling edges.
However, like you said, absolute time will be off by 200ms. So, since the falling edge occurs 200ms after the rising edge of the 1pps pulse, the X310 will not start at 0s until 200ms after the N320 (or I assume N310). So, if you issue the "get_time_now()" command at the same time to both devices, the X310 will be 200ms behind the N320.
To see if this is the issue, you could try to rebuild the X310 FPGA image with the fix, or you could try inverting the Octoclock output if you have an inverter (to see if the offset shifts the other way). To help us confirm that this was our issue, we used a function generator instead of the Octoclock to generate the 1pps to both devices. Then, we varied the duty cycle of the 1pps pulse and saw that the time difference between the two devices tracked the duty cycle (the time that the 1pps pulse is high per second).
Also, the way we were setting the time, it actually looked like we were off by 800ms because we'd tell the USRPs to set their time to a specific value after the next pps. But, we'd issue this command right after the rising edge of the 1PPS pulse. So, this would set the N320 to the time we specified 1 second later (when the next rising edge occurs). However, the X310 would see the falling edge occur 200ms after issuing this command. So, it would set it's time then. So, the way we were doing it, the X310 was actually getting set 800ms earlier than the N320.
Hope this helps.Jim
From: zhou hwzhou@yahoo.com
Sent: Monday, December 20, 2021 7:50 AM
To: usrp-users@lists.ettus.com usrp-users@lists.ettus.com; Marcus Müller marcus.mueller@ettus.com; Jim Palladino jim@gardettoengineering.com
Subject: Re: [USRP-users] Time different between X310 and N310 USRPs using UHD4.1.0 Hi Jim,
Thank you so much for your quick reply. Your finding is very interesting and I believe it is very related to my problem.After some thinking, I am still having some confusion:Because N320 and X310 USRPs are using different pulse edges, their time 0s are actually different by 200ms in universal time, but their internal timers should be similar. When querying their time respectively, we should get similar time - the responses are their internal times. But I am seeing 200ms difference.
Could you please give some comments on this?
Thanks a lot,
Hongwei

On Monday, 20 December 2021, 11:04:09 GMT, Jim Palladino jim@gardettoengineering.com wrote:

Hi,
We had the exact same issue a couple months ago between an N320 and an X310. The issue is that the N320 (and I'm guessing the N310) detects the 1PPS pulse on the rising edge, as expected. The X310 detects the 1PPS edge on the falling edge. Note that the 1PPS pulse from the Octoclock stays high for about 200ms, so I'm guessing this is the issue you are seeing. 
We ended up making our own custom FPGA build for the X310. We modified the file:
"uhd/fpga/usrp3/lib/rfnoc/utils/timekeeper.v".

Originally, the PPS edge detection looked like:
pps_edge<= pps_del & ~pps;

We changed it to:pps_edge<= ~pps_del & pps;

It would be good if this could get "fixed" in UHD, as it would be nice to not have to maintain a custom FPGA build. I'm not sure what effect this change will have on other USRP FPGA builds that use the same timekeeper.v file.
In any case, I'm guessing this is your problem.
Jim

From: zhou via USRP-users usrp-users@lists.ettus.com
Sent: Monday, December 20, 2021 5:31 AM
To: usrp-users@lists.ettus.com usrp-users@lists.ettus.com; Marcus Müller marcus.mueller@ettus.com
Subject: [USRP-users] Time different between X310 and N310 USRPs using UHD4.1.0 Hi,
I am using mixed types of USRPs in my applications, namely, X310 and N310. The signals are timed. I find 0.2-second time difference between these two USRPs.Details:Each USRP is controlled by a Linux server;
The same Linux version in all PCs;All USRPs are connected to the same Octoclock;
UHD version is 4.1.0 in Linux servers;All Linux servers are connected to a control PC which is the client;The sampling rates are different: 184.32MHz in X310 USRP and 245.76MHz in N310 USRP
Control PC sends command to set time 0 after PPS in all USRPs, then query the time in each of them.The time difference between USRPs of the same type is small, ~2ms, but the time difference between different types of USRP is much bigger, ~0.2s.Times should be impacted by sampling rate; when setting timers, no signal is transmitted.
2ms time difference between USRPs could be due to network delay; 200ms can't be because of network. It seems to be due to HW in USRPs. Does this mean that X310 and N310 are not synchronized?
Thanks for any comment,
Hongwei

USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com

Assuming this is the issue, inverting the 1pps input into only the X310 should fix the offset and get everything aligned. If you invert the input to both USRP devices, that would just flip the time offset.

Hope that works for you. Happy holidays to you, too.
Jim

From: zhou hwzhou@yahoo.com
Sent: Monday, December 20, 2021 10:38 AM
To: usrp-users@lists.ettus.com usrp-users@lists.ettus.com; Marcus Müller marcus.mueller@ettus.com; Jim Palladino jim@gardettoengineering.com
Subject: Re: [USRP-users] Re: Time different between X310 and N310 USRPs using UHD4.1.0

Hi Jim,

Thanks for your explanation. I got it. Inverter may be a quick solution; just the duty cycle will become 80% after conversion. I will definitely try it. If not, I will rebuild X310 FPGA as you suggested.

Have a Merry Christmas and happy New Year,

Hongwei

On Monday, 20 December 2021, 13:18:23 GMT, Jim Palladino jim@gardettoengineering.com wrote:

Hongwei,

If this is your problem, then "get_time_last_pps()" should report the same time between the X310 and N320, unless you happen to ask it (or if you set it) during that 200ms window between the 1pps rising and falling edges.

However, like you said, absolute time will be off by 200ms. So, since the falling edge occurs 200ms after the rising edge of the 1pps pulse, the X310 will not start at 0s until 200ms after the N320 (or I assume N310). So, if you issue the "get_time_now()" command at the same time to both devices, the X310 will be 200ms behind the N320.

To see if this is the issue, you could try to rebuild the X310 FPGA image with the fix, or you could try inverting the Octoclock output if you have an inverter (to see if the offset shifts the other way). To help us confirm that this was our issue, we used a function generator instead of the Octoclock to generate the 1pps to both devices. Then, we varied the duty cycle of the 1pps pulse and saw that the time difference between the two devices tracked the duty cycle (the time that the 1pps pulse is high per second).

Also, the way we were setting the time, it actually looked like we were off by 800ms because we'd tell the USRPs to set their time to a specific value after the next pps. But, we'd issue this command right after the rising edge of the 1PPS pulse. So, this would set the N320 to the time we specified 1 second later (when the next rising edge occurs). However, the X310 would see the falling edge occur 200ms after issuing this command. So, it would set it's time then. So, the way we were doing it, the X310 was actually getting set 800ms earlier than the N320.

Hope this helps.
Jim

From: zhou hwzhou@yahoo.com
Sent: Monday, December 20, 2021 7:50 AM
To: usrp-users@lists.ettus.com usrp-users@lists.ettus.com; Marcus Müller marcus.mueller@ettus.com; Jim Palladino jim@gardettoengineering.com
Subject: Re: [USRP-users] Time different between X310 and N310 USRPs using UHD4.1.0

Hi Jim,

Thank you so much for your quick reply. Your finding is very interesting and I believe it is very related to my problem.
After some thinking, I am still having some confusion:
Because N320 and X310 USRPs are using different pulse edges, their time 0s are actually different by 200ms in universal time, but their internal timers should be similar. When querying their time respectively, we should get similar time - the responses are their internal times. But I am seeing 200ms difference.

Could you please give some comments on this?

Thanks a lot,
Hongwei

On Monday, 20 December 2021, 11:04:09 GMT, Jim Palladino jim@gardettoengineering.com wrote:

Hi,

We had the exact same issue a couple months ago between an N320 and an X310. The issue is that the N320 (and I'm guessing the N310) detects the 1PPS pulse on the rising edge, as expected. The X310 detects the 1PPS edge on the falling edge. Note that the 1PPS pulse from the Octoclock stays high for about 200ms, so I'm guessing this is the issue you are seeing.

We ended up making our own custom FPGA build for the X310. We modified the file:
"uhd/fpga/usrp3/lib/rfnoc/utils/timekeeper.v".

Originally, the PPS edge detection looked like:
pps_edge<= pps_del & ~pps;

We changed it to:
pps_edge<= ~pps_del & pps;

It would be good if this could get "fixed" in UHD, as it would be nice to not have to maintain a custom FPGA build. I'm not sure what effect this change will have on other USRP FPGA builds that use the same timekeeper.v file.

In any case, I'm guessing this is your problem.

Jim

From: zhou via USRP-users usrp-users@lists.ettus.com
Sent: Monday, December 20, 2021 5:31 AM
To: usrp-users@lists.ettus.com usrp-users@lists.ettus.com; Marcus Müller marcus.mueller@ettus.com
Subject: [USRP-users] Time different between X310 and N310 USRPs using UHD4.1.0

Hi,

I am using mixed types of USRPs in my applications, namely, X310 and N310. The signals are timed. I find 0.2-second time difference between these two USRPs.
Details:
Each USRP is controlled by a Linux server;
The same Linux version in all PCs;
All USRPs are connected to the same Octoclock;
UHD version is 4.1.0 in Linux servers;
All Linux servers are connected to a control PC which is the client;
The sampling rates are different: 184.32MHz in X310 USRP and 245.76MHz in N310 USRP

Control PC sends command to set time 0 after PPS in all USRPs, then query the time in each of them.
The time difference between USRPs of the same type is small, ~2ms, but the time difference between different types of USRP is much bigger, ~0.2s.
Times should be impacted by sampling rate; when setting timers, no signal is transmitted.

2ms time difference between USRPs could be due to network delay; 200ms can't be because of network. It seems to be due to HW in USRPs. Does this mean that X310 and N310 are not synchronized?

Thanks for any comment,

Hongwei

USRP-users mailing list -- usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.commailto:usrp-users-leave@lists.ettus.com

Thanks Jim. I will only invert 1PPS for X310.
All the best,
Hongwei

On Monday, 20 December 2021, 15:47:42 GMT, Jim Palladino <jim@gardettoengineering.com> wrote:  

Assuming this is the issue, inverting the 1pps input into only the X310 should fix the offset and get everything aligned. If you invert the input to both USRP devices, that would just flip the time offset. 
Hope that works for you. Happy holidays to you, too.Jim
From: zhou hwzhou@yahoo.com
Sent: Monday, December 20, 2021 10:38 AM
To: usrp-users@lists.ettus.com usrp-users@lists.ettus.com; Marcus Müller marcus.mueller@ettus.com; Jim Palladino jim@gardettoengineering.com
Subject: Re: [USRP-users] Re: Time different between X310 and N310 USRPs using UHD4.1.0 Hi Jim,
Thanks for your explanation. I got it. Inverter may be a quick solution; just the duty cycle will become 80% after conversion. I will definitely try it. If not, I will rebuild X310 FPGA as you suggested.
Have a Merry Christmas and happy New Year,
Hongwei

On Monday, 20 December 2021, 13:18:23 GMT, Jim Palladino jim@gardettoengineering.com wrote:

Hongwei,
If this is your problem, then "get_time_last_pps()" should report the same time between the X310 and N320, unless you happen to ask it (or if you set it) during that 200ms window between the 1pps rising and falling edges.
However, like you said, absolute time will be off by 200ms. So, since the falling edge occurs 200ms after the rising edge of the 1pps pulse, the X310 will not start at 0s until 200ms after the N320 (or I assume N310). So, if you issue the "get_time_now()" command at the same time to both devices, the X310 will be 200ms behind the N320.
To see if this is the issue, you could try to rebuild the X310 FPGA image with the fix, or you could try inverting the Octoclock output if you have an inverter (to see if the offset shifts the other way). To help us confirm that this was our issue, we used a function generator instead of the Octoclock to generate the 1pps to both devices. Then, we varied the duty cycle of the 1pps pulse and saw that the time difference between the two devices tracked the duty cycle (the time that the 1pps pulse is high per second).
Also, the way we were setting the time, it actually looked like we were off by 800ms because we'd tell the USRPs to set their time to a specific value after the next pps. But, we'd issue this command right after the rising edge of the 1PPS pulse. So, this would set the N320 to the time we specified 1 second later (when the next rising edge occurs). However, the X310 would see the falling edge occur 200ms after issuing this command. So, it would set it's time then. So, the way we were doing it, the X310 was actually getting set 800ms earlier than the N320.
Hope this helps.Jim
From: zhou hwzhou@yahoo.com
Sent: Monday, December 20, 2021 7:50 AM
To: usrp-users@lists.ettus.com usrp-users@lists.ettus.com; Marcus Müller marcus.mueller@ettus.com; Jim Palladino jim@gardettoengineering.com
Subject: Re: [USRP-users] Time different between X310 and N310 USRPs using UHD4.1.0 Hi Jim,
Thank you so much for your quick reply. Your finding is very interesting and I believe it is very related to my problem.After some thinking, I am still having some confusion:Because N320 and X310 USRPs are using different pulse edges, their time 0s are actually different by 200ms in universal time, but their internal timers should be similar. When querying their time respectively, we should get similar time - the responses are their internal times. But I am seeing 200ms difference.
Could you please give some comments on this?
Thanks a lot,
Hongwei

On Monday, 20 December 2021, 11:04:09 GMT, Jim Palladino jim@gardettoengineering.com wrote:

Hi,
We had the exact same issue a couple months ago between an N320 and an X310. The issue is that the N320 (and I'm guessing the N310) detects the 1PPS pulse on the rising edge, as expected. The X310 detects the 1PPS edge on the falling edge. Note that the 1PPS pulse from the Octoclock stays high for about 200ms, so I'm guessing this is the issue you are seeing. 
We ended up making our own custom FPGA build for the X310. We modified the file:
"uhd/fpga/usrp3/lib/rfnoc/utils/timekeeper.v".

Originally, the PPS edge detection looked like:
pps_edge<= pps_del & ~pps;

We changed it to:pps_edge<= ~pps_del & pps;

It would be good if this could get "fixed" in UHD, as it would be nice to not have to maintain a custom FPGA build. I'm not sure what effect this change will have on other USRP FPGA builds that use the same timekeeper.v file.
In any case, I'm guessing this is your problem.
Jim

From: zhou via USRP-users usrp-users@lists.ettus.com
Sent: Monday, December 20, 2021 5:31 AM
To: usrp-users@lists.ettus.com usrp-users@lists.ettus.com; Marcus Müller marcus.mueller@ettus.com
Subject: [USRP-users] Time different between X310 and N310 USRPs using UHD4.1.0 Hi,
I am using mixed types of USRPs in my applications, namely, X310 and N310. The signals are timed. I find 0.2-second time difference between these two USRPs.Details:Each USRP is controlled by a Linux server;
The same Linux version in all PCs;All USRPs are connected to the same Octoclock;
UHD version is 4.1.0 in Linux servers;All Linux servers are connected to a control PC which is the client;The sampling rates are different: 184.32MHz in X310 USRP and 245.76MHz in N310 USRP
Control PC sends command to set time 0 after PPS in all USRPs, then query the time in each of them.The time difference between USRPs of the same type is small, ~2ms, but the time difference between different types of USRP is much bigger, ~0.2s.Times should be impacted by sampling rate; when setting timers, no signal is transmitted.
2ms time difference between USRPs could be due to network delay; 200ms can't be because of network. It seems to be due to HW in USRPs. Does this mean that X310 and N310 are not synchronized?
Thanks for any comment,
Hongwei

USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com