Here is my Lab's N310 experiance: 3.12 had your issue (2)
3.13.0.0 had bizarre TX behavior and lock ups that required a reboot or re-image. Our RX noise floor was also suspiciously high. 3.13.0.1 was no better 3.13.0.2 fixed all our problems. As long as we tell linux to allocate plenty of ram to the Ethernet driver we can transmit and receive with two channels simultaneously. I have not had the chance yet to test 4 TX to 4 RX yet. Over the past several months I have come to the conclusion that getting UHD or GNUradio from a package manager is more trouble than it is worth. If you compile UHD 3.13.0.2 from source and still have these RX timeout problems then I suppose this issue is out of reach for non-Ettus folks. On Tue, Sep 4, 2018 at 6:45 PM, Max Scharrenbroich via USRP-users < usrp-users@lists.ettus.com> wrote: > This message is a continuation of the thread that Rob Kossler last added > to regarding the timeouts on Rx for the N310 when using version 3.13 of the > UHD. Note that we have not tested our X310s with this version - version > 3.10 of the UHD works well with our system of X310s and we don’t see a need > in changing. > > > > We found the same Rx timeout issues that Rob did while testing custom > executables that have been robust using UHD version 3.10 for well over a > year. We noticed that the problem occurs when receiving samples from > multiple channels – a single channel seems to work as expected. As Rob > pointed out the error can be easily replicated with the stock UHD examples. > In our case we saw the errors when running rx_multi_samples with more than > one channel. > > > > To dig into the underlying cause we installed WireShark and captured > packets from the SDR<->host interface. Based on the collects it appears > that there is always exactly one data packet missing. Setting the number > of receive samples to something small (less than or equal to a packet size) > results in N-1 packets being received on the interface, where N is the > number of Rx channels specified. > > > > In an effort to work around the problem we tried hacking at > super_recv_packet_handler.hpp to tell the SDR to send more packets than we > actually want and ignore the timeout condition. This seems to work when > receiving the first burst of samples (STREAM_MODE_NUM_SAMPS_AND_DONE) > but subsequent issuing of stream commands turns the rx_stream into a train > wreck. > > > > The ultimate problem we are having is that we cannot get our N310 to work > with any of the versions of the UHD. > > > > Here are the issues: > > > > (1) Version 3.11 has an sdcard image that is corrupted and won’t allow our > N310 to boot. > > > > (2) Version 3.12 does not accept the PID for the AD9371s > > > > (3) Version 3.13 has the Rx timeout issue. > > > > Questions: > > > > Can someone please recommend an exact version number that will allow us to > use our N310 as we should expect it to? > > > > Or > > > > If the Rx timeout is a known issue can someone point us to a bug fix that > we can implement locally? > > > > Thanks, > > > > Max Scharrenbroich > > Senior Principal Scientist > > SAZE Technologies, LLC > > > > > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
