On 03/27/2020 04:15 PM, Carmichael, Ryan via USRP-users wrote:
I recently updated from 3.11.1 to 3.15LTS to try to resolve a receive
lockup problem, however it still appears to be happening (albeit
seemingly less frequently).
Essentially, stream->recv() gets into a state where it never returns,
even though we are using the default timeout (0.1). Verified via
debugger that recv() itself is just hanging.
We essentially have a function A that roughly looks like the code
below (I’m not leaving much out). We call this function A over and
over quite frequently. Are there any red flags here?
A() {
uhd::stream_cmd_t
rxStreamCmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
rxStreamCmd.stream_now = true;
rxStreamCmd.time_spec = uhd::time_spec_t();
rxStreamCmd.num_samps = nSamples_a;
rxStream ->issue_stream_cmd(rxStreamCmd);
numReceived = 0;
uhd::rx_metadata_t metaData
while (numReceived < nSamples_a) {
.
.
// calculate numLeftToRead
.
.
uint samplesReceived = rxStream->recv(buffer, numLeftToRead,
metaData);
.
.
// calculate numReceived
}
}
This “lockup” typically does not require the radio to be restarted,
just my application.
/
------------------------------------------------------------------------
/
Windows or Linux? Native or VM?
My gut says this is an IP/Network stack issue.
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
