Just a note from my experience with the USRP2 on our LAN, we didn't see any problems initially, but something changed around RC1 that seriously disabled LAN clients/switches in the immediate physical segment. We didn't look into any further yet, but it was an instantaneous effect upon attaching a USRP2 running that RC1 firmware, even before any data collection has begun.
- Ben Buley Black River Systems Co. Inc. bu...@brsc.com -----Original Message----- From: discuss-gnuradio-bounces+buley=brsc....@gnu.org [mailto:discuss-gnuradio-bounces+buley=brsc....@gnu.org] On Behalf Of Juha Vierinen Sent: Thursday, April 16, 2009 11:14 AM To: discuss-gnuradio@gnu.org; Eric Blossom Subject: Re: [Discuss-gnuradio] Timestamps, data rates > I wouldn't expect the time stamps in the streams to start at the same > point (the start_rx_streaming command doesn't accept a "start at > time T argument). I would expect that there is a constant delta_t > between subsequent frames, and that that delta_t would be the same for > both of the USRP2s. How accurate is sync_to_pps? Can you do MIMO with just sync_to_pps (assuming your cables are equal length)? Off topic: We have been playing around with my USRP2 and it seems very nice. I noticed that even though the FAQ strongly discourages connecting the USRP2 to your main network, it does actually work. We have a fairly large LAN and I assume that the USRP2 could possibly flood the network when doing 25 MHz. Is there any other reason for not just putting the USRP2 in your LAN? juha > At -d 4 you are likely to be getting overruns (indicated by an 'S' > (sequence error) on stderr). That is, the host can't keep up. > > Are both USRP2's connected to the same host? > If so, are they each connected to their own dedicated ethernet port, > or are they connected to a switch that feeds a single ethernet port? > > If both USRP2s are connected to a single machine, and even if they are > connected to dedicated ethernet ports, I'd be pleasantly surprised if > you could run -d 8 on both of them. I doubt the problem is in the > USRP2 firmware; the overhead of the host code and lack of sufficient > horsepower on the host is almost certainly the bottleneck. > >> My plan has been to setup buffers to align samples based on timestamp - >> but with such variations it looks to me like it could be quite >> difficult to implement. Or at the very least, I'd need very large >> buffers, and could end up needing/wanting to change their size often. >> Any suggestions on how to best deal with this? Should I be looking into >> the USRP2 firmware code to try to get some more predictable behavior out >> of it? >> Thanks, >> Doug > > Doug, assuming that the host can keep up without overruns, aligning > samples from the two USRP2s should be no big deal. I wouldn't expect > that you need more than 200 ms of buffer. If the host isn't keeping > up, all bets are off. > > I'd start with something like -d 64 of each of them, get that working, > then start reducing the decimation rate until you get failures. Then > go after those. > > Eric > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
