RE: [Discuss-gnuradio] inband timestamp issues

[Eric Schneider]

> From: Brian Padalino [mailto:address@hidden
> 
> On Thu, Aug 21, 2008 at 3:11 AM, Eric Schneider
> <address@hidden> wrote:
> > 1. Is it true that there are N RX Sample FIFOs?  It seems that the
> channels
> > are already muxed by the time they get to the packet_builder, no?
> 
> The packet builder itself actually does the muxing: 
> 
> http://www.gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/inband_li
> b/packet_builder.v

I only see one chan_fifodata input to packet builder:

http://www.gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/inband_lib/pac
ket_builder.v#L8

It would appear that the muxing is between the fifos and the packet builder
at:

http://www.gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/inband_lib/rx_
buffer_inband.v#L205

Not a big difference, but it might make your "N Packet Builders" solution
that much easier.


> The N RX sample FIFOs are built here:

I was looking at RTL schematics on a 1Rx1Tx configuration, which oddly
enough only has 1 RX FIFO, go figure!  *blush*
 
> > 2. Can we just subtract the FIFO size (usedw?) from the timestamp in
> the
> > packet builder?
> 
> Sure, but what for?  I suppose I am not sure what this is addressing?

I'm assuming that at least some of the rx timestamp inaccuracy is due to the
variable latency introduced by the rx_chan_fifo(s).  If usedw represents the
number of samples currently in a FIFO, then the actual timestamp of the
sample read out of the fifo is current_timestamp - usedw, correct?

I do think that building the packets before buffering is a better idea, but
adjusting the timestamps might be a quick interim fix.

> > 3. When checking timestamps for expired command/data packets, is an
> > overflow/wraparound on the timestamp_clock handled?  (ref
> cmd_reader.v:107,
> > chan_fifo_reader.v:145)
> 
> I don't think it's explicitly being taken care of, but I am also not
> sure if the logic just ends up working out.  This should probably be
> looked at and a testbench written.
 
If timestamp_clock is near its max (every ~67s), and a packet is scheduled
such that its future time will cause wraparound (making it a smallish
number), then the reader will detect that pkt_timestamp < timestamp_clock
and discard the packet even though in a "few" ticks timestamp_clock would be
0 again.

> > --ets
> 
> Brian

--ets