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

[Martin DvH]

On Tue, 2010-02-16 at 15:43 -0700, Eric Schneider wrote:
> 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...  :-/

I am trying to find a working version of the inband code.

Where can we find your work.
The last I could find is at:
http://nyquist.gnuradio.org/svn/gnuradio/branches/developers/ets/inband/

But that shows no activity for a long long time.

I also tried to checkout your personal git and get the inband branch:

git clone http://gnuradio.org/git/ets.git
git checkout --track -b inband origin/inband
git fetch

But that has the inband example C++ apps and libs code moved to
usrp/limbo (in other words, disabled, nonfunctional)


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



Thanks,

Martin

> 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
> >         
> > 
> 
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>