RE: [Discuss-gnuradio] Timestamps, data rates

[Ben Buley]

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.
  address@hidden 
 
-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of Juha
Vierinen
Sent: Thursday, April 16, 2009 11:14 AM
To: address@hidden; 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio