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 -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
