as far as I know, I was the last one to work on the "inband" firmware. I used it extensively for a project I was working on and didn't have problems with it, but more testing would be warranted before considering for the default firmware. (Which I would like to see)
After we get the USRP1 uhd support with the vanilla images, I think this would be a worthwhile endeavor.
As to the rationale for not making it the default firmware, I'm not sure. The only downside I can think of is a slight decrease in signal bandwidth due to the packet header.
I think we are overstating the effect of the overhead. It may be fine, and this would be an opportune time to test and break things. :-)
I was planning on doing some further revision to revamp the Tx / control packet side logic (my work was a rewrite of the Rx side to ensure accurate timestamps). At that time there was talk about putting a VRT stack on the USRP1, which I am skeptical about. So I decided to just wait.
Im not very concerned about VRT, but it would be nice because there is a lot of shared code in UHD that uses vrt headers. What I really think we need more than a specific packet format is timestamping consistent with the USRP2 (seconds count and fractional seconds/ticks).
If there is interest in further development, I guess git hub or the like is the place to put further development? (Or svn on cgran?)
yes. The firmware and fpga code is all in the uhd git repo. So we can work something out with git.
-josh _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
