On Fri, Dec 6, 2024 at 4:53 PM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

>
>
> On Fri, Dec 6, 2024 at 9:44 AM Rob Kossler <rkoss...@nd.edu> wrote:
>
>>
>> You might want to look at the Ettus c++ example "rfnoc_radio_loopback".
>> You could also try just running it.  Note that it does not include the
>> DMAFifo block but it does allow you to choose which Rx Radio and Tx Radio
>> block to use. After quickly reviewing your attachment, I would mention that
>> you shouldn't have to send Tx streaming commands. Once you send the Rx
>> streaming command, the data will flow.  However, if you use a "timed"
>> receive command, then the streaming data will have a time tag such that
>> when it arrives at the Transmit radio, it will by definition be late.  You
>> will need to do one of the following: either use non-timed receive
>> streaming commands or else create a custom RFNoC block that manipulates the
>> time tag to add some delay in order to account for the number of clock
>> cycles that it takes for the data to propagate from Rx to Tx.
>>
>
Whoops, should read the whole thread before responding. Thanks Rob for
raising this!


> And, one question for the Ettus dev team: is there an easy way to
> configure this kind of graph such that the host will receive the "Late"
> messages?  Since the host is not involved in the streaming, it's not
> obvious to the user that all of the streaming is arriving Late to the Tx
> radio as it would be in a host-based streaming application.  But, it would
> be nice if the host did receive these Late (or Underrun) messages (at least
> in many situations).
>
>
That's a great question.... sadly the answer is no. Of course, you can
stare at the screen but that's not what you're looking for.

As is, the late message will get passed down the chain, and then eventually
reach the Tx radio block which doesn't know what to do with that message
and then drops it. We'd need some kind of way to redirect the messages, or
at least put them into some queue. Interesting suggestion, but not
something we have in the pipe.

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

Reply via email to