I changed the code in “usrp2_iface_impl::ctrl_send_and_recv” slighly,
see below. It seems to solve the problem for my current application New
and removed lines are marked with “PZ”.
BR/
Per
usrp2_ctrl_data_t ctrl_send_and_recv(const usrp2_ctrl_data_t
&out_data){
boost::mutex::scoped_lock lock(_ctrl_mutex);
unsigned int number_of_tries=0; // PZ
//fill in the seq number and send
usrp2_ctrl_data_t out_copy = out_data;
out_copy.proto_ver = htonl(USRP2_PROTO_VERSION);
out_copy.seq = htonl(++_ctrl_seq_num);
_ctrl_transport->send(boost::asio::buffer(&out_copy,
sizeof(usrp2_ctrl_data_t)));
//loop until we get the packet or timeout
boost::uint8_t usrp2_ctrl_data_in_mem[USRP2_UDP_BYTES];
//allocate max bytes for recv
usrp2_ctrl_data_t *ctrl_data_in =
reinterpret_cast<usrp2_ctrl_data_t *>(usrp2_ctrl_data_in_mem);
while(true){
size_t len =
_ctrl_transport->recv(boost::asio::buffer(usrp2_ctrl_data_in_mem));
if(len >= sizeof(boost::uint32_t) and
ntohl(ctrl_data_in->proto_ver) != USRP2_PROTO_VERSION){
throw std::runtime_error(str(
boost::format(“Expected protocol version %d, but got
%d\n”
“The firmware build does not match the host code
build.”
) % int(USRP2_PROTO_VERSION) %
ntohl(ctrl_data_in->proto_ver)
));
}
if (len >= sizeof(usrp2_ctrl_data_t) and
ntohl(ctrl_data_in->seq) == _ctrl_seq_num){
return *ctrl_data_in;
}
//if (len == 0) break; //timeout PZ
if (len == 0 ) { // PZ
if (number_of_tries==50) // PZ
break; //PZ
else // PZ
number_of_tries++; // PZ
}; // PZ
//didnt get seq or bad packet, continue looking...
}
throw std::runtime_error("usrp2 no control response");
}
From: discuss-gnuradio-bounces+perz=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+perz=removed_email_address@domain.invalid] on behalf of Josh B.
[[email protected]]
Sent: Thursday, July 15, 2010 9:40 PM
To: [email protected]
Subject: Re: [Discuss-gnuradio] UHD problem
You have done nothing wrong. This is a result of the transmit SM in the
FPGA using ethernet pause frames to flow control the transmit. The pause
frame is blocking the transaction from the issue stream command, and
causing the timeout error (no response).
Sending a large packet (greater than the fpga buffering) several seconds
in the future will cause the FPGA to issue these pause frames and it
will last for several seconds (until the transmit packets are
processed).
Understanding that, it may be possible for you to work around this by
making the sends in the future sooner (within 100 ms). Or issue the
stream command before any sending occurs. In the long run, we are
working on a host based flow control to avoid using the pause frames.
Hope that helps,
-Josh
On 07/15/2010 12:16 PM, Per Z. wrote:
[email protected]
Discuss-gnuradio Info Page
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio