UHD problem

GNU Radio
1

Hi Josh and List,

I am trying to send two frames and then receive a frame. The two
transmit frames are transmitted several seconds in advance using
d_dev->send. They arrive nicely at the receiver as they should. However,
then I try to receive a frame using
“d_sdev->issue_stream_cmd(stream_cmd)” followed by d_dev->recv. However,
the command “d_sdev->issue_stream_cmd” gives the error “usrp2 no control
response”.

Could it be that when I do the command d_sdev->issue_stream_cmd the
USPR2 is busy waiting to transmit the two transmit frames ?

BR/
Per

2

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

3

Two questions:

How large is the fpga buffer ?

Does this imply that it would be fairly straightforward for a
FPGA-skilled person (i.e. not myself) to implement decimation=1 ?
I mean, not continous streaming, but using the FPGA to store short
bursts.

BR/
Per

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

4

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