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.
________________________________
The information contained in this message, and any attachments, may contain
privileged and/or proprietary information that is intended solely for the
person or entity to which it is addressed. Moreover, it may contain export
restricted technical data controlled by Export Administration Regulations (EAR)
or the International Traffic in Arms Regulations (ITAR). Any review,
retransmission, dissemination, or re-export to foreign or domestic entities by
anyone other than the intended recipient in accordance with EAR and/or ITAR
regulations is prohibited.
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
