My XTRX accepts a stream from a file with limeTRX without an error and LimeSuiteNG sink will transmit data from the same file with radio limeSDR-USB. However, LimeSuiteNG sink does not work (same file again) using radio limeSDR XTRX and produces the following error:
“LimeSuiteNG :info: Sampling rate set(50.000 MHz): CGEN:400.000 MHz, Decim: 2^1, Interp: 2^1
thread_body_wrapper :error: ERROR thread[thread-per-block[2]: <block sdrdevice_sinkLimeSDR XTRX>]: argument not found”
The flow graph below tested combinations of LimeSDR-USB and LimeSDR XTRX as sink or source. The results are:
(1) USB source and sink works as expect.
(2) XTRX source with USB sink produces a highly distorted spectrum and logs repeated warnings that I don’t understand at this time:
swFIFO:512
LimeSuiteNG USB ep:81 Rx0: 20.079 MB/s | TS:9999060 pkt:9803 o:9291(+4902) l:0(+0) dma:9803/9804(+1) swFIFO:512
LimeSuiteNG USB ep:81 Rx0: 20.079 MB/s | TS:15000120 pkt:14706 o:14194(+4903) l:0(+0) dma:14706/14706(+0) swFIFO:512
(3) Both XTRX and USB sources with USB sink works as expected with the warning only sent once:
LimeSuiteNG USB ep:81 Rx0: 20.079 MB/s | TS:5000040 pkt:4902 o:2091(+2091) l:0(+0) dma:4902/4902(+0) swFIFO:0
This comes from GNURadio, not sure what could cause that, did you compile GNURadio from source? There can be GNURadio companion python bindings issues if GNURadio and LimeSuiteNG is compiled with different C++ compiler versions.
This indicates Rx data overrun, meaning, the data is received, but is not consumed for processing fast enough.
TS: last packet timestamp
pkt: total received packets count
o: overrruns, data had been received but there is no more room in the FIFO, so data is dropped
l: loss, there has been a discontinuity in the received data.
dma: buffer reading/writing indexes
swFIFO: data chunks count in software FIFO
I’ll have to check the order of operations of GNURadio using multiple devices, it could be that one device gets data streaming started, while the other is still being configured.
If you are referring to the XTRX sink error: thread_body_wrapper :error: ERROR thread[thread-per-block[2]: ]: argument not found , no, I haven’t seen or made progress on this. Running the LimeSDR-USB and LimeSDR XTRX source blocks together (in parallel), I am discovering differences between the two which I am trying to understand. I have placed priority on getting the LimeSDR sink and source blocks working and will be doing what I can to facilitate progress. I expect to be spending significant time testing them.
The two flow graph images attached are essentially identical except for the device handle in the sink; one is the USB device, the other is XTRX. I require another communication channel (like email) to send you the *.grc files.
Hi aardric,
I am also experiencing the same error:
thread_body_wrapper :error: ERROR thread[thread-per-block[2]: <block sdrdevice_sinkLimeSDR XTRX>]: argument not found
It happens specifically when I try to transmit using 2 channels with the LimeXTRX using the LimeSuiteNG Sink block by specifying the Data Channel Indexes to [0, 1].
Do you have any updates on this since you posted? Could you find a solution?
Thank you,
Timothee Mac Garry
Timothee
Thank you for this information. I still receive this error but I can’t say whether it’s consistent. I have assembled a very simple flow graph to investigate this particular issue further by identifying conditions and sink block settings under which the error in question consistently occurs. I am using an older build (6f4c28d3) of LimeSuiteNG but will now rebuild before continuing. I’ll provide more detail and progress update later today or tomorrow. Please keep me posted with whatever you discover about the XTRX operation with gr-limesdrng. I am very interested in having this device working properly within gnuradio.
Timothee
Thank you for this information. The only flow graph (of many attempts) for which I have had success with the sink block using the XTRX is a very simple flow graph created specifically to investigate this particular issue by identifying conditions and sink block settings under which the error in question consistently occurs. I don’t understand why this works but the input selector block is necessary; feeding the signal source directly into the XTRX only or both the USB device and XTRX in parallel consistently results in the XTRX thread_body_wrapper error. I have just started experimenting but switching between the null sink and XTRX repeatedly will work anywhere from 1 to a half dozen times before the error occurs. Switching from the XTRX to the USB device will work only once; switching back from USB to XTRX fails. The latest build of LimeSuiteNG was used and the XTRX TX is connected to the USB RX. Perhaps I have created an invalid flow graph so please inspect and comment while I continue exploring this. I have place a copy of TxRx_loop.grc on github link sent on the April 16 post.
This error comes from GNURadio, depending on system load and channels count, the graph starts feeding Sink 1 sample at a time, and that for some reason makes the GNU radio work thread to die. I’ve updated the Sink to work in 256 sample chunks gr-limesuiteng: Set Sink to work with 256 sample chunks. · myriadrf/LimeSuiteNG@ef75a77 · GitHub, that seems to fix this issue. But further investigation is needed to figure out what’s going on with GNU Radio’s thread scheduling.
Thank you for your reply and your time. I installed the latest LimeSuiteNG repo from source, and I do not get the thread_body_wrapper error anymore when the sink transmits in 256 sample chunks, I hope this fixes it for you too.
This fix worked for me and I’m relived that the problem was not due to some peculiarity in my build environment. Thank you Ricardas. I’ll continue to validate gr-limesdrng in particular with the XTRX from basic operation to eventually more subtle features on the basis of my expectations of how it should work and either report differences or review my expectations.
The fix worked for me also. I welcome your gesture of appreciation but to be honest it was not an unselfish act as I had hoped to benefit (and I did) from the result. I thank you for reaching out and encouraging me to move ahead.
USB ep:81 Rx0: 20.079 MB/s | TS:9999060 pkt:9803 o:9291(+4902) l:0(+0) dma:9803/9804(+1) swFIFO:512
