RE: [Discuss-gnuradio] inband timestamp issues

[Eric Schneider]

Just thinking out loud here...

Given your suggested solution (which I like):

N RX Sample Streams -> N Packet Builders -> N Packet FIFOs -> N:1 FIFO MUX
-> FX2 USB Interface

The FIFO MUX could be a module that implements a virtual FIFO output, and
automatically selects (and emulates) the input FIFO based on fullness, so
that the fullest FIFO always gets read first.  A tie would default to
natural ordering.  There should also be a minimum size (128?) or a
channel_ready input to prevent premature FX2 transfer.  Sounds pretty simple
and should just drop-in to the existing design.

What about moving the Packet FIFO into packet_builder?  It seems like we are
just be wasting cycles by pushing headers to an external FIFO when we could
handle that with some read logic.  In this way, the first "FIFO" reads from
packet_builder actually output internally generated/stored header values,
then later the internal FIFO with the channel data.  But maybe it's more
trouble than it's worth.

--ets

> -----Original Message-----
> From: Brian Padalino [mailto:address@hidden
> Sent: Wednesday, August 20, 2008 5:12 PM
> To: Steve Peters
> Cc: address@hidden
> Subject: Re: [Discuss-gnuradio] inband timestamp issues
> 
> On Wed, Aug 20, 2008 at 6:45 PM, Steve Peters <address@hidden>
> wrote:
> >> As a non-hardware person, I was thinking that a simple solution is
> to not
> >> really use the clock on the RX directly, but timestamp packets
> indirectly.
> >>  You have a signal when the sample buffer is empty, when that signal
> is
> >> de-asserted for the first time, read the clock and take this as your
> initial
> >> RX clock time.
> >>
> >> Now, you go by the fact that you're sampling at a constant rate and
> >> timestamp packets based on that.  The next packet gets timestamped
> at
> >> last_timestamp + 126samples_per_packet * decimation_rate.
> >>
> >> That way you're not timestamp on packet building, but logically the
> time the
> >> first sample of the packet arrived at the RX buffer.
> >
> > Correct me if I misunderstand, but you're not actually clocking
> > anything this way.  Theoretically it should work, but there's nothing
> > telling me there weren't actually a million clock cycles between two
> > packets.  There should definitely be a timestamp clock tied to the
> > master clock, in my opinion.
> >
> > Ketan and I discussed a couple possibilities earlier today.  One
> might
> > be to have a timestamp buffer in parallel with the RX FIFO.  Although
> > problems arise with making sure the timestamp changes at the border
> of
> > packets, unless there is one timestamp per sample, which is almost
> > certainly too excessive.
> >
> > Another idea is to move the FIFO to the other side of the packet
> > builder, as long as the packet builder can keep up with the
> > ADC/decimator output.  It then outputs to the buffer.  This was
> > Ketan's idea, so I apologize if I'm communicating it incorrectly.
> 
> The current inband RX chain looks like:
> 
>     N RX Sample Streams -> N RX Sample FIFOs -> 1 Packet Builder -> 1
> USB FIFO -> FX2 USB Interface
> 
> What it should look like (in my opinion):
> 
>     N RX Sample Streams -> N Packet Builders -> N Packet FIFOs -> N:1
> FIFO MUX -> FX2 USB Interface
> 
> I believe the TX chain looks more like this, except with the arrows
> going in the opposite direction.
> 
> On a side note, it might be interesting to have a command that can
> turn on the receiver and receive a specific number of inband packets.
> For example, if you know you may be receiving a transmission that is
> only 2ms long in a specific slot, it might be beneficial to only
> schedule 2ms (+/- a guard time) worth of samples to be delivered to
> the host, freeing up more CPU cycles for signal processing and using
> the USB bandwidth a little more efficiently.
> 
> Comments or suggestions?
> 
> Brian
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio