On 2022-07-29 16:41, Jason Merlo wrote:
Hi All,
I’m working on a project using an X310 and UBX-160 daughterboards where we need
to perform full duplex on one daughterboard and time-domain duplexing on the
TX/RX port of the second daughterboard. The end goal is essentially just to
control the switches on the UBX-160 to allow me to transmit or receive on the
TX/RX port on one of the channels while operating the second channel in
full-duplex. Currently, I’m performing timed transmit and receives at the same
time using STREAM_MODE_NUM_SAMPS_AND_DONE whenever data needs to be transmitted.
My current approach to accomplish the time duplexing (effectively controlling
the switches to allow transmit/receive) is by calling
uhd::usrp::multi_usrp::get_tx_stream() each time new data is received by the
transmit function, setting the tx_stream_args.channels field appropriately
prior to re-creating the streamer, to switch on and off the transmit switch on
the TX/RX port since the switchs is in TX mode whenever data is being
transmitted. I always receive data from the TX/RX port and ignore it when TX
is transmitting to avoid overhead of re-creating the rx_streamer each time.
This works, but only for exactly 120 iterations. Additionally, if I dynamically
create the receive streamer as well it works for exactly 60 iterations. Once
it reaches 120 iterations I start to get ERROR_CODE_TIMEOUT receiving 0
samples, i.e., the SDR stops receiving any data, however it still seems to
transmit just fine (I get ACKs for all the transmitted data). For what it’s
worth, it seems to be indifferent to TX/RX buffer size, so it doesn’t seem
directly related to streaming buffers. I don’t know if it has something to do
with the tx_streamer not being fully deleted. I’m calling tx_streamer.reset()
and assigning to nullptr for good measure to suggest the shared_ptr to delete
the object (though I’m not sure how to determine if this is actually
happening). Additionally, before I was dynamically creating the tx_stream
object, the program ran fine; it’s only now that I am re-creating the tx_stream
dynamically based on which channels are actually transmitting during a certain
period.
The only hint I’ve gotten is from the get_tx_stream() documentation: "There can
always only be one streamer. When calling get_tx_stream() a second time, the first
streamer must be destroyed beforehand." So if the shared_ptr isn’t actually being
deleted this could be the cause, though I’m not sure why it allows 120 calls before it
stops receiving—it seems like it should crash after the second call, but I also tested it
without calling reset() or assigning it to nullptr on the shared pointer, and it had the
exact same behavior. However, the tx_stream object does go out of scope at the end of the
function which may also take care of the shared_ptr deletion, so this may not be the
issue. Furthermore, it’s strange that dynamicaly creating tx_stream only seems to affect
the rx_stream operation and tx_stream appears to continue to work fine.
If I accomplish the switching directly without creating a new tx_streamer
object, or if I could change the transmit channels of a tx_streamer object
without deleting/creating a new one that may also resolve this issue I think.
If anyone has suggestions on solving the issue described above, or how to
accomplish this in a different way, I would greatly appreciate the feedback.
Thanks in advance,
Jason
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
I think what you might want to do is use the burst-tags in the metadata
for "send()":
https://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html#ab5ffe812f8d3d1870253e98e6ff1718a
Personally, the TX side of things has never been much of a "thing" for
me, given that 90% of my time I spend as a radio astronomer, but the
START/END of burst
tags were designed to provide more hints to the ATR switching
hardware among other things.
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
