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 On Fri, Jun 21, 2013 at 1:18 PM, Josh Blum <j...@ettus.com> wrote: > > > On 06/21/2013 09:41 AM, Tim Newman 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. > > > All I'm doing is running "uhd_usrp_probe". I've tried with and without > > adding the --args addr=<ip> 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. > > > > 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 > > > Tim > > > > > > On Thu, Jun 13, 2013 at 12:27 AM, Sean Nowlan > > <sean.now...@gtri.gatech.edu>wrote: > > > >> I think 512 is the max value for N on N200/N210 hence 195kSps is minimum > >> sample rate. > >> > >> > >> Karan Talasila <karan....@gmail.com> wrote: > >> > >> @sean can you please tell me how you got minimum sampling rate for usrp > >> N210 as 100*e6/512. I know that the sampling rate should be 100*e6/N > where > >> N is an integer. So N can be any integer even greater than 512 right. In > >> that way, what is the minimum that the USRP accepts. what is maximum N > that > >> can be used. > >> > >> > >> On Thu, Jun 13, 2013 at 6:20 AM, Sean Nowlan < > sean.now...@gtri.gatech.edu>wrote: > >> > >>> On 06/12/2013 08:49 PM, Marcus D. Leech wrote: > >>> > >>>> On 06/12/2013 08:29 PM, Sean Nowlan wrote: > >>>> > >>>>> > >>>>> The minimum "reasonable" sample rate I've used is 2e5 (100e6/2e5 = > >>>>> 500). I think 100e6/512 = 195312.5 is the smallest supported rate. > >>>>> > >>>>> Yup, sorry, you're right. I tend to pick values that are valid for > >>>> both 64Msps and 100Msps master clock rates, since I write apps that > need to > >>>> be reasonably > >>>> agnostic with respect to hardware. > >>>> > >>>> > >>>> Ah, makes sense. > >>> > >>> > >>>> > >>>> > >>> > >>> ______________________________**_________________ > >>> Discuss-gnuradio mailing list > >>> Discuss-gnuradio@gnu.org > >>> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio< > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > >>> > >> > >> > >> > >> -- > >> Regards > >> Karan Talasila > >> > >> _______________________________________________ > >> Discuss-gnuradio mailing list > >> Discuss-gnuradio@gnu.org > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >> > >> > > > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio