> After lot of debugging I have some progress: > 1.) Having multiple channels is not enough since it only sets > _stream_now=FALSE but not _start_time. Consequently both Source+Sink use > get_time_now()+0.1 which may be different I think that you need to call get_time_now()+0.1 just once (not separately for source and sink) and use the result for both.
> 2.) set_unknown_pps only sets the the time to zero at next pps I agree. > 3.) "Sync: Unknown PPS" (set_unknown_pps) has to be only set in either USRP > Source or Sink since they share the common motherboard. (having it in both > still seems to work but takes longer to start because setting time is done > twice, I think) I agree. > 4.) set_start_time *has* to be called on *both* USRP Source/Sink. This can't > be done via grc and requires py edits. set_start_time is a gnuradio and/or gr-ettus function that has no equivalent in UHD. So, I don't really have experience with this one. > Now comes the part that I don't understand. When I use: > > self.uhd_usrp_sink_0.set_start_time(uhd.time_spec(1.0)) > self.uhd_usrp_source_0.set_start_time(uhd.time_spec(1.0)) > > I always get a string of "L" and the flowgraph is stuck. No matter which > number I put here. After long time I figured out that the start time for USRP > Sink has to be at least 100ms later. This works: > > self.uhd_usrp_sink_0.set_start_time(uhd.time_spec(1.1)) > self.uhd_usrp_source_0.set_start_time(uhd.time_spec(1.0)) > > 1.0001 does not work and neither does 1.001, 1.01 etc. But any number larger > than 1.1 does. > > WHY is this the case? This sounds like a bug or quirk in gr-ettus. In my own software (and in the Ettus UHD examples), setting a common start time for Tx and Rx is typical usage. > > Also, why do we need to wait so long (100ms does not work, I get "WARN: USRP > Source Block caught rx error code: 2" and "U")? What exactly has to happen > within this one second and what are the cases when this one second may not be > enough? Again, this is likely a question better answered by a gnuradio/gr-ettus person. I typically use delays as short as 10-50 ms between get_time_now() and start of streaming. For Tx streaming, you just need to make sure that the streaming data arrives at the radio prior to the motherboard clock exceeding the time indicated in the time stamp of the first streaming sample or else you get "Late (L)" messages. For Rx streaming, the radio block will start sending streaming samples once the motherboard clock reaches the indicated time stamp. I don't think that there is any warning if you tell the Rx streamer to start streaming at say time 10.123 when in fact the current motherboard time is already 12.2. I think it will just start streaming immediately with no warning (but I'm not 100% sure on this case). The "Underrun (U)" warning indicates that the radio has already started streaming and has new samples to send (to put into the send FIFO) but the send FIFO is FULL (the samples are not being consumed fast enough downstream and so the radio has no place to put the newest samples). > > I am using USRP X310+UBX+gnuradio for an application where my transmitted > > signal (TX) is reflected and received (RX). > > For my tests I use the simple loopback config (TX -> 30dB Attn -> RX), > > transmit a pulse and plot both on the same plot (triggered in the TX pulse). > > > > The response comes around a whopping 38ms later! How do you measure this delay? Does this include software delays, 10Gb delays, etc? > > I added a delay block before plotting the TX signal but the delay is still > > random each time I restart the flowgraph (residual time delays up to 700us). > > > > I wonder if I can achieve sample-accurate alignment that is consistent > > across flowgraph runs (maybe even USRP power cycles). Assuming that I understand what you mean, this is possible - even with USRP power cycles. When I simultaneously transmit and receive using timed samples, my receive signal always starts at the same sample within the Tx waveform (not sample 1, but that can be calibrated). > > RX+TX Streaming starts at the same time to my understanding because both my > > USRP Source+Sink have two ports and I use the setting "Sync: Unknown PPS" > > as discussed some time on this list. _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
