[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Discuss-gnuradio] inband timestamp issues
From: |
Eric Schneider |
Subject: |
RE: [Discuss-gnuradio] inband timestamp issues |
Date: |
Thu, 21 Aug 2008 14:27:33 -0600 |
> 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
- Re: [Discuss-gnuradio] inband timestamp issues, Steve Peters, 2008/08/17
- Re: [Discuss-gnuradio] inband timestamp issues, George Nychis, 2008/08/18
- Re: [Discuss-gnuradio] inband timestamp issues, George Nychis, 2008/08/18
- Re: [Discuss-gnuradio] inband timestamp issues, Brian Padalino, 2008/08/18
- Re: [Discuss-gnuradio] inband timestamp issues, George Nychis, 2008/08/19
- Re: [Discuss-gnuradio] inband timestamp issues, Steve Peters, 2008/08/20
- Re: [Discuss-gnuradio] inband timestamp issues, Brian Padalino, 2008/08/20
- RE: [Discuss-gnuradio] inband timestamp issues, Eric Schneider, 2008/08/21
- Re: [Discuss-gnuradio] inband timestamp issues, Brian Padalino, 2008/08/21
- RE: [Discuss-gnuradio] inband timestamp issues,
Eric Schneider <=
- Re: [Discuss-gnuradio] inband timestamp issues, Brian Padalino, 2008/08/21
- Re: [Discuss-gnuradio] inband timestamp issues, George Nychis, 2008/08/21
- RE: [Discuss-gnuradio] inband timestamp issues, Eric Schneider, 2008/08/21
- Re: [Discuss-gnuradio] inband timestamp issues, Eric Blossom, 2008/08/21
- Re: [Discuss-gnuradio] inband timestamp issues, Steve Peters, 2008/08/21
- Re: [Discuss-gnuradio] inband timestamp issues, George Nychis, 2008/08/21
- RE: [Discuss-gnuradio] inband timestamp issues, Eric Schneider, 2008/08/21
- Re: [Discuss-gnuradio] inband timestamp issues, Brian Padalino, 2008/08/21
- RE: [Discuss-gnuradio] inband timestamp issues, Eric Schneider, 2008/08/21
- RE: [Discuss-gnuradio] inband timestamp issues, Eric Schneider, 2008/08/26