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