discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Per Zetterberg
Subject: Re: [Discuss-gnuradio] USRP1 Inband rework, request for features and comments
Date: Tue, 26 Jan 2010 11:32:50 +0100
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]