Re: [Discuss-gnuradio] USRP1 Inband rework, request for features and comments

[Eric Schneider]

Hi George, no worries, I know perfectly well how it is to have too many
ambitions and too little time...  :-)

I can confirm that the timestamps are correct.  I have been using it for
some time.

The compiled RBF is not in my developer branch.  I haven't even moved my
recent work to git...  :-/

There are some older (but should be functional) versions at:
http://www.schneider-group.com/gnuradio/

The only recent changes I have made were related to debugging
dropped/late tx packets due to host latency (I echo the tag fields from
tx to rx).

I have had some inquiries regarding the ability of the tx chain to use
lower clock rates ( <48M, the xfer rate to the FX2).  Apparently others
have had problems with that setup.  I will investigate this sometime in
the "near" future.  

I will also try to put together some tests to fully exercise the inband
functionality.  Please recommend any tests you would like to see.

--Eric

On Tue, 2010-02-16 at 14:42 -0500, George Nychis wrote:
> Hi Eric,
> 
> Sorry for the late response here, I've been wrapped up in so many
> things.
> 
> Is your latest compiled RBF in your developer branch?  There are
> several people I know (some that I CC'ed) that are interested in using
> the inband code.  
> 
> Last I checked, the timestamp had an issue of "jumping" which I know
> you tried to fix.  Last time I tried your branch, I'm not sure it was
> working yet.  Have you confirmed that timestamps to the host are not
> jumping in any manner when there is no overrun, and have you confirmed
> that timestamps are being treated properly when trying to transmit?
> 
> Thanks a bunch for updating this code.
> 
> - George
> 
> 
> On Tue, Jan 26, 2010 at 5:32 AM, Per Zetterberg
> <address@hidden> wrote:
>         
>         Eric Schneider wrote:
>                 Hi all,  I'm looking to be doing some more rework of
>                 the USRP1 inband
>                 code, specifically to align with the USRP2 VRT work.
>                 
>                 For those not familiar, USRP1 inband allows for
>                 timestamped rx/tx
>                 samples (and commands), which is very useful for TDMA
>                 type systems.  It
>                 is a separate FPGA configuration and host side
>                 interface.  
>                 Has anyone besides me used the current inband FPGA?
>                 
>                 I'm not sure who on this list is interested in such a
>                 thing, but if you
>                 have specific needs you want addressed, speak up now!
>                 
>                 A few notes on my current thinking:
>                 
>                 1. I do not intent to implement VRT over USB.  Only to
>                 implement a VRT
>                 compatible interface on the host.  The USB inband
>                 protocol will simply
>                 serve to make that possible in the most efficient way
>                 possible.
>                 
>                 2. I don't intend to keep the existing inband packet
>                 structure.  This is
>                 one area where interested parties really need to
>                 provide feedback as to
>                 supported (or supportable) feature sets.
>                 
>                 It is my hope that the new inband Verilog modules can
>                 be used by other
>                 custom FPGA builds as a standard host interface.
>                 
>                 For example, it has just recently occurred to me that
>                 the FPGA side
>                 could be made more efficient by the use of trailer
>                 metadata rather than
>                 headers.  Since the USB packets are fixed size, I
>                 don't really see a
>                 downside.
>                 
>                 There are also fields in the current inband packet
>                 that are either
>                 obsolete, or should be optional fields, IMO.  RSSI,
>                 for example.
>                 
>                 Do timestamps really need to be 32 bits?  That allows
>                 scheduling
>                 transmission 33 seconds in advance on a 64MHz clock,
>                 which seems
>                 excessive to me.
>                 
>                 Is there a reason to send timestamps in every packet
>                 if samples are
>                 contiguous?
>                 
>                 I'm leaning towards a 16 or 32 bit trailer with
>                 optional, per packet,
>                 meta data.  Less than 16 bit alignment of trailer/meta
>                 would fragment
>                 individual (16 bit) samples, and 32 bits would keep
>                 I/Q interleaving
>                 order constant between packets.  I am open to
>                 entertaining the idea of
>                 tiny (8 bit?) trailers, so long as we can reliably
>                 detect and recover
>                 from buffer overruns and such.
>                 
>                 --ETS
>                 
>                 
>                 
>                 
>                 _______________________________________________
>                 Discuss-gnuradio mailing list
>                 address@hidden
>                 http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>                  
>         Sounds great!!
>         
>         It would also be nice to have a "pps" input to synchronize the
>         clocks of multiple units. General purpose pins could be used.
>         
>         One feature I have always wished for is "external triggering"
>         where a USRP transmits/receives when a pin goes high. But that
>         is maybe another project.
>         
>         Good luck!
>         
>         BR/
>         Per
>         
>         
>         
>         
>         
>         
>         _______________________________________________
>         Discuss-gnuradio mailing list
>         address@hidden
>         http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>         
>