George, thanks for the direction (I'm brand new to the m-block stuff)...
Worked fine, did the delta in cc, too lazy to do post processing. ;-)
Certainly looks like the FIFO are periodically get backed up, causing the
variance.
Deltas from the erroneous sequence:
8063
22369
987
985
7915
8065
The average is 8064, so it would seem than it is all about the buffer backup
(the total reported deltas add up correctly).
Looking forward to working with you on the timestamp issues. I think I've
got a handle on the relevant areas of the FPGA design now, so hopefully I
can help out.
Hope your trip went well,
Eric
-----Original Message-----
From: George Nychis [mailto:address@hidden
Sent: Thursday, August 21, 2008 1:36 AM
To: Eric Schneider
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] inband timestamp issues
Hi Eric,
Thanks for your interest! Sorry for a small response, but I'm about to
head to bed and I'm out of town for a conference.
Go to 'usrp/host/apps-inband/' and modify test_usrp_inband_rx.cc to add
the following line at line 315:
std::cerr << timestamp << std::endl;
That will output the timestamp of every RX block to stderr, which you
can pipe somewhere. Then you can just write a small script to check
the
space between timestamps. Rebuilding and running should be enough, you
shouldn't have to make install.
Thanks!
George
Eric Schneider wrote:
George, would you mind sharing the code you used for this test?
-----Original Message-----
From: George Nychis [mailto:address@hidden
Sent: Wednesday, July 23, 2008 5:23 PM
To: Steve Peters
Cc: Ketan Mandke; Eric Blossom; address@hidden
Subject: Re: [Discuss-gnuradio] inband timestamp issues
Steve Peters wrote:
Just a quick follow-up to this. Last night I printed out diffs in
the
std::clock() function along with the timestamp diffs right after the
packets are read. There are no jumps in the std::clock(), which
tells
me the timestamp jump is caused by something strange like the clock
being overwritten and not an actual delay.
I'll get back to you on the other requested tests.
This is interesting... I decided to run some of my own tests. I did
a
capture of ~10k packets with a single RX chain and I see the same
issue.
I used a decimation rate of 64, and therefore the timestamps on the
recorded packets should be 64*126samples=8064 ticks apart.
I recorded 8 timestamp jumps of the following sizes:
10264763
1003
985
5569
1738245
1003
987
5557
Very odd, but there's got to be something that explains it :) I'm
looking in to this now.
- George
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio