USRP1 Inband rework, request for features and comments

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

Echoing some feedback to the list…

On Mon, 2010-01-25 at 08:47 -0700, Eric S. wrote:

  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.

There seems to be differing views about implementing VRT over USB. Some
like it for the standard, others oppose it from a complexity
perspective.

I haven’t had any feedback regarding bandwidth efficiency specifically,
which I thought was a complaint regarding the original inband code. VRT
would increase overhead, does anyone care?

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.

This is a non-issue, there is no practical gain from reducing the
timestamps by a few bits. 16 bits is too small, next stop 32.

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.

Just disregard this babble…

–ETS

Eric S. wrote:

have specific needs you want addressed, speak up now!

order constant between packets. I am open to entertaining the idea of
[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

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

Hi Eric,

Great, thanks for your time with this! Can you e-mail me the most
recent
version of your compiled RBF?

I have a full TDMA MAC that we can test this with. If the timestamps
are
correct, we should be able to monitor the spectrum in the time domain
and
see some very tightly spaced packet transmissions.

So to some extent, I can test this for you, but if you could get me the
newest RBF that would be great.

  • George

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

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 15:43 -0700, Eric S. wrote:

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

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs