On 10/06/2015 05:01 AM, irene menicagli wrote:
Hi everyone,
I have the same problem (late packet). I think that the problem is the
time on packet is in the past when the command arrives to device. The
cause can be latency between pc and usrp.
My pc is quite powerfull so this behaviour seems strange.
Maybe I have to change timestamp on packet but I don't know if it is
possible because I work at python level and use UHD functions
(usrp_sink and usrp_source).
I also use only one USRP loopbacking TX e RX.
Thanks,
Irene
It's not about the performance of your PC, typically.
How are you setting the timestamps on the timed packets? If you're
using host time, that will drift relative to the USRP. Further, if you
using timing that's to tight, latency variability across the network
(or USB) stack can cause packets to arrive "late" from the perspective
of the USRP.
2015-10-05 21:13 GMT+02:00 Marcus D. Leech <[email protected]
<mailto:[email protected]>>:
On 10/05/2015 10:58 AM, Leonard Foxes wrote:
Hi list,
It's me again.
I use a USRP N210 with WBX daughterboards and loop back cable to
connect TX e RX. I have two problems:
1. Late packet. I use set_time_now and set_start_time command
and after few seconds I see some Ls printed.
2. Phase. Phase offset changes between executions. (I'm trying
to use set_time_command but nothing changes).
This is my python code about usrp:
self.samp_rate = samp_rate = 500e3
self.USRP_address = USRP_address = "addr=192.168.10.2"
self.tun_freq = tun_freq= 1.45e9
self.tun_gain = tun_gain= 19
self.rx_freq_off = rx_freq_off = 0
self.timeref1= timeref1=time.time()
self.uhd_usrp_TX = uhd.usrp_sink(
device_addr=USRP_address,
stream_args=uhd.stream_args(
cpu_format="fc32",
channels=range(1),
),
)
self.uhd_usrp_TX.set_samp_rate(samp_rate)
self.uhd_usrp_TX.set_time_now(uhd.time_spec_t(timeref1), 0)
self.uhd_usrp_TX.set_command_time(uhd.time_spec_t(timeref1+0.1), 0)
self.uhd_usrp_TX.set_center_freq(uhd.tune_request_t(tun_freq), 0)
self.uhd_usrp_TX.clear_command_time()
self.uhd_usrp_TX.set_gain(tun_gain, 0)
self.uhd_usrp_TX.set_start_time(uhd.time_spec_t(timeref1+1))
self.uhd_usrp_RX = uhd.usrp_source(
device_addr=USRP_address,
stream_args=uhd.stream_args(
cpu_format="fc32",
channels=range(1),
),
)
self.uhd_usrp_RX.set_samp_rate(samp_rate)
self.uhd_usrp_RX.set_time_now(uhd.time_spec_t(timeref1), 0)
self.uhd_usrp_RX.set_command_time(uhd.time_spec_t(timeref1+0.1), 0)
self.uhd_usrp_RX.set_center_freq(uhd.tune_request_t(tun_freq +
rx_freq_off), 0)
self.uhd_usrp_RX.clear_command_time()
time.sleep(0.15)
self.uhd_usrp_RX.set_gain(tun_gain, 0)
self.uhd_usrp_RX.set_start_time(uhd.time_spec_t(timeref1+1))
Any suggestion will be welcome
Thanks in advance,
Leo
Something to realize is that if you call set_time_now() on two
different USRPs, they'll not agree in detail about the
time-of-day. If you're
using an external 10Mhz and 1PPS reference, you should probably
use set_time_unknown_pps(), and make sure that both sides
of this are setting the same time AT THE SAME TIME.
Also, WBX has a 180deg phase-ambiguity. Two WBX boards with the
same 10MHz reference, on USRPs with the same notion of time,
will either be in-phase, or 180deg out-of-phase, due to hardware
ambiguity in the 2XLO mixer used on WBX.
_______________________________________________
Discuss-gnuradio mailing list
[email protected] <mailto:[email protected]>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
