LimesuiteNG Multithread TXRX

The legacy limesuite allowed to call into the receive and transmit streams at the same time. This was also the only documented allowed MT access.

The new limesuiteNG has only a single stream object on which StreamRX and StreamTX can be called. Are these still MT safe operations? If not how should a full duplex stream be implemented then?

Yes, the Stream Rx/Tx functions are thread safe and can be used as full duplex.

Thank you for reply. I am asking because the stream is wrapped in an unique_ptr. So when passing the stream to both, the rx and tx threads I need to use .get() on the pointer, which looks surprising to me. If on the other hand I am passing by value between threads (as is one of the intended use cases of unique_ptr) only one of the threads can access the stream at any time.

The example code on the other hand looks as if the author tries to tell me that I don’t need separate threads. This would be true only if neither tx nor rx functions are blocking if there is nothing to receive or transmit. However that will rise the question of how to prevent busy looping if nothing is to be done.

Can you also give background information about the design, so that I can make educated decisions for using the library?

I’ll look into the unique_ptr situation.
In the mean time, StreamRx and StreamTx are independent, and can be used from separate threads.
The library internally is running two separate threads for receiving and transmitting.

The StreamRx/Tx functions essentially just copy samples data from/into internal FIFOs.
Depending on your use case how you need to process the data, if it is simple as a loopback then it is not necessary to run your own threads.
the Rx/Tx functions have a timeout parameter, if 0 is used, then they are non blocking, otherwise Rx will block until requested amount of data is received or timeout is reached and will return whatever amount of data it got, and Tx would block while the internal Tx FIFO is full or timeout is reached and return how much data has been consumed from the user buffer.

The internal FIFOs are setup based on sampling rate to hold at most 250ms of data, and data transfers from/to hardware are done in ~100us batches. Transmitting can be done by specifying timestamps when the samples should go out to RF, the hardware will buffer them and will transmit at those times, if the packet’s timestamp is already too late to be transmitted, it will be dropped and nothing will be sent to RF. Or transmitting can be done with timestamps disabled, all data will be sent to RF as soon as possible.