Re: Run time FIFO error

GNU Radio
1

I think 512 is the max value for N on N200/N210 hence 195kSps is minimum
sample rate.

2

Yes, bringing this back up. Back to the original topic. When I get this
FIFO ctrl error, the host is sending back an icmp port unreachable msg
to
the usrp, I grab this using wireshark.

All I’m doing is running “uhd_usrp_probe”. I’ve tried with and without
adding the --args addr= parameter, same thing using both.

I’ve debugged a bit, and increased the ACK_TIMEOUT in
usrp/usrp2/usrp2_fifo_ctrl.cpp from 0.5 to 10.0 and it literally just
sits
at:

Creating the usrp device with: …
– Opening a USRP2/N-Series device…
– Current recv frame size: 1472 bytes
– Current send frame size: 1472 bytes
<sits here for 10 seconds>

Then spits out
RuntimeError: RuntimeError: fifo ctrl timed out looking for acks

Again, there is a switch in between the USRP and the host.

Tim

On Thu, Jun 13, 2013 at 12:27 AM, Sean Nowlan

3

On 06/21/2013 09:41 AM, Tim N. wrote:

Yes, bringing this back up. Back to the original topic. When I get this
FIFO ctrl error, the host is sending back an icmp port unreachable msg to
the usrp, I grab this using wireshark.

Well if the app shutdown from the error. That could be the host’s
response to a stray packet coming from the USRP after the socket was
closed. For example a UDP packet w/ a GPSDO NMEA message. So this ICMP
error may not be indicative of anything.

– Current send frame size: 1472 bytes
<sits here for 10 seconds>

Then spits out
RuntimeError: RuntimeError: fifo ctrl timed out looking for acks

Again, there is a switch in between the USRP and the host.

Yup, definitely a lost packet. Its gone and more time isnt going to
help. Question is, where is the packet lost? We have a control packet
from host to switch, then switch to USRP. Then a response packet from
USRP to switch, then switch to host.

-josh

4

It’s hard to tell in the pcap file where it gets lost. I’m not using a
dissector for the UHD packets so I can’t see whats in the data field,
thus
I can’t match up commands coming/going. I have confirmed that this
issue
does not exist when I’m using 003.004.X firmware and fpga load.

Tim