Re: [Discuss-gnuradio] inband timestamp issues

[Steve Peters]

Hi again George,

> I spend all of my time working with the single chain, and if I find bugs I
> can fix them.  But I think you're the only ones using the dual chain... so
> your feedback is useful and I'd appreciate any help solving the problems.  I
> don't really know Verilog, and our Verilog coder is at an internship right
> now ;)

We certainly appreciate the work you've done (along with Thibauld et
al.) towards the inband functionality!

> The main reason I bring this up is that Brian and I were talking on IRC
> about the issue earlier, and agreed that a testbench for the FPGA timestamp
> would be useful in ensuring the timestamps are behaving properly... but I
> don't really know Verilog to do this easily ;)  So if any of you know
> Verilog and want to collaborate on helping fix the issue, it would be
> appreciated.

Sorry I had missed this part before.  We would be happy to help,
although our knowledge of Verilog is probably inferior.  I'm not just
saying that to be modest.

We have been focusing on the TX chain at the moment.  As has been
discussed in two or three places before on this list, the treatment of
individual channels as independent on the tx side puts severe
limitations on MIMO transmission.  In particular, the USB buffer is
likely to fill up with packets for one channel, while the packets for
the other channel are queued and end up missing their scheduled time
of departure.  This was first discussed between Thibauld and Brian
when designing the FPGA inband code.  Brian said the solution would be
for the host to recognize when this would happen and split up large
packets... interleaving packets instead of symbols as before.

A guy who used to work on our project, Sanmi, had also contacted this
list about the problem, and you came up with a good solution of adding
an "interleaving" logical channel to the FPGA code, but you were
concerned about fitting this on the FPGA.  Interleaving the packets on
the host end didn't seem to be a good solution given how the host
ended up being designed.

Anyway, we've found a solution that seems to work, although I'm having
troubles testing it thoroughly.  Basically, instead of having both the
interleaving and non-interleaving functionalities available in the
same rbf, we have made a new rbf that has all the USB packet/timestamp
functionality but assumes symbol interleaving.  For our applications,
we don't anticipate needing the flexibility of independent transmit
channels.

We're currently in the stage of writing the host code for using
multiple USRPs.  Previously, we had host code written to use the
inband_2rxhb_2tx.rbf with both transmit and receive on a single USRP,
and this was relatively successful.  Our current strategy is a little
ugly; we're modifying the inband code so that multiple USRPs are
controlled with a single usrp_server.  I realize this is not how the
code was meant to be utilized, but we've got concerns about sending
data (which is supposed to be transmitted simultaneously) to two
independent usrp_servers and having them both arrive on time.  This
concern is exacerbated by a demo next month where we hope to use 4x4.
So we are taking the safer, yet messier, route for the moment.

Anyway, I wanted to give you (and the list in general) a status update
and let you know that we'll be happy to collaborate on anything
regarding the inband code.  Feel free to contact me and/or Ketan
outside of the list as well.

> - George

Steve