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 > > <per.zetterb...@ee.kth.se> 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 > > Discuss-gnuradio@gnu.org > > 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 > > Discuss-gnuradio@gnu.org > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio