-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Forgot to copy the list:
Eric B. wrote:
On Tue, Apr 14, 2009 at 02:19:38PM -0500, Douglas G. wrote:
Doug,
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.
Right - I’d actually like to figure out what is required to implement
such a ‘start at time T’ call now - I realize this may be changed with
the usrp-vita transition, but if I can get it working now I think that
would make things easier for me. From my brief look at the firmware
where starting RX streaming is handled, this is not currently
implemented: so the firmware code would need this functionality added,
in addition to a call added on the host code. It looks like I would need
to be touching the start_rx_streaming_cmd in txrx.c in the firmware -
not sure where else I’d have to go though.
USRP2 firmware; the overhead of the host code and lack of sufficient
horsepower on the host is almost certainly the bottleneck.
I have two gig-e ports on my machine, each connected to a USRP2
(through a dedicated gig-e switch) - it’s a pretty hefty 8-core xeon
machine. I’m not seeing overruns with my experiments at the highest data
rates (at least not with this code).
I do still have a nagging issue with the not-entirely constant delta
(between the two USRP2’s): i.e. it will be constant for a long run of
received frames, then the delta will change, and be constant for a time,
then change again. I’m updating to the latest 3.2 release candidate now,
and will try updating with fresh firmware/fpga code, and see if that’s
still the case (I’m talking about -d 128 or 512 here - no
overrun/sequence errors reported).
Eric
As you suggest - I’m looking to get this working with low data rates
(-d 512, 128, etc.) and then moving down to the high rates (-d 4 is
where I need to get). Of course, 200ms of buffer at -d 4 is 5Ms, and
with 16-bit, complex samples (4 bytes/sample) that’s ~19MB of buffer,
per USRP2. I do have plenty of RAM on this machine, but that still seems
a little extreme. Getting a quick and dirty ‘rx_at_time’ seems like a
better solution to me. Although perhaps implementing the buffers, and
doing the alignment on the host would be quicker to get done. This would
also catch the cases where the delta changes occasionally, like I’ve
seen. Perhaps the best solution long-term is a combination of both
(rx-at-time, and aligning on the host).
Thanks,
Doug
Doug G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
[email protected]
[email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJ53v8gfOzzR5bXIgRAuc+AJ91Tgqxg/f5/V5fzRuHIzJCd6oYTACgnePu
PQMjT0MpoUzeKC4YGJqmdxA=
=wLwZ
-----END PGP SIGNATURE-----