Hello, I have 2 LimeSDR’s one as Tx and one as Rx that I am using to send BPSK data at 300kbaud with an 85MHz carrier signal. I am using gnuradio mixed with python code to operate the LimeSDR’s on separate laptops. For the transmitter, I am using a short, ~312 byte long packet of text data that I am continuously sending to a LimeSDR sink and continously reading back on the second LimeSDR. The byte array is currently initialized as a vector source in gnuradio. Then, using python, and in a threaded loop, we trying to update the byte array using the autogenerated “set” and “get” functions that are generated by gnuradio in python to change the byte stream that is being transmitted over the SDR’s.
It appears that there is ~ a 3 second delay from when we set the new byte packet vs. how long it takes to see the new data packet on our receiver. We know this delay is not at our receiver because we can instantly block the Rx antenna and data instantly becomes noise with no delay. We have tried experimenting with the various buffer functions that are wrapped using swig into python when initializing the SDR sink, but these do not remove the 3 second delay.
One alternative method that improves this delay but is not ideal is if we try to call top_block.stop, then top_block.wait before setting the new byte array, then top_block.start after. This removes the 3 second delay, but the stop, wait, and start commands consume ~20ms. We would like to be able to update our byte array as fast as possible.
Timing the execution of setting the byte array to something new only takes a few microseconds. This leads us to believe that there is a buffer in the LimeSDR transmitter that we need to shorten to accommodate our low data rate or flush when we try to change the byte array.
If anyone has suggestions on how we may be able to mitigate this delay, it would be extremely appreciated. Thank you. Below is the Tx gnuradio code. This will probably go without saying, but I am relatively new to SDR programming, my expertise is in photonics and optics.