Re: [Discuss-gnuradio] inband timestamp issues

[George Nychis]

Hi Eric,

Most, if not all, of our FPGA work is done by an undergrad here who 
knows Verilog.  He might not be able to contribute until September, as 
our first week of classes is this week and things need to settle.

If you have Verilog experience and want to work with me on tackling the 
problem, I'd be more than happy to work with you.  We use Quartus tools 
to build the FPGA, which are completely free, and there is also a 
simulator available for it too if we are (and should) building some test 
benches.

If you're a Linux user, like us, we run everything through VMWare with a 
Windows XP image and it works just fine.

Here is where you can get the web edition:
http://www.altera.com/products/software/quartus-ii/web-edition/qts-we-index.html

This is the FPGA code branch I work out of:
http://gnuradio.org/trac/browser/gnuradio/branches/developers/gnychis/fpga

We can work together on changes to the branch, without you having SVN 
commit access any changes you'd like to make you might have to push 
through me as patches... but regardless, we can figure out a way.

I'm free to work with you at any time, even when I'm traveling, I just 
want to get things done ASAP :)

- George

PS.  I pushed this to the list because its slightly useful information


Eric Schneider wrote:
> 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