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 <[email protected]>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 >> [email protected] >> 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 > [email protected] > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
