We're checking timestamps on ethernet frames and everything seems fine
all the way up to 25 MHz over many hours of continuous data streaming.
At lower rates we've done several days of streaming without dropped
frames or conflicting timestamps.
juha
On Tue, Nov 10, 2009 at 20:21, Tim Pearce wrote
Hi Doug,
Yes for each sample its calculating the new sample value by adding the
decimation rate.
I'll try this without the addition as it might reduce the processor load and
can easily be post processed for the application I'm working on.
Cheers,
Tim
On Mon, Nov 9, 2009 at 10:06 PM, Doug Geige
Tim Pearce wrote:
Hi All,
I've modified the source to generate timesamples (as a seperate
stream) from the USRP2 source blocks and noticed an issue - if the PC
is struggling some frames have a timesample dated before the
timesample of a frame processed before it.
It's possible I've done som
Hi All,
I've modified the source to generate timesamples (as a seperate stream) from
the USRP2 source blocks and noticed an issue - if the PC is struggling some
frames have a timesample dated before the timesample of a frame processed
before it.
It's possible I've done something wrong modifying t
