Josh, 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)
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 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. 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?) --Eric S. On Tue, 2010-08-10 at 02:19 -0700, Josh Blum wrote: > > On 08/10/2010 01:49 AM, Sylvain Munaut wrote: > > On 08/10/2010 01:32 AM, Josh Blum wrote: > >>> Say that I want to interface the USRP1 to Simulink using the UHD and > >>> supporting timed TX samples. Would that be feasible with the anticipated > >>> state of the USRP1 support? > >> > >> The USRP1 does not feature timed samples, > > > > Well, there is a firmware that does (the so called 'inband signalling' > > one, even tough it's a misnomer). > > > > I was hoping that with the UHD api featuring timing control, that it > > would become the default firmware. > > > > The UHD will use the same images that gnuradio uses for fpga and > firmware because its known to work and there is source code for it. I am > not opposed to future enhancement once the basic features work. And I > hear there is some hobbyist interest in implementing a VRT like packet > structure and time control... > > I dont know anything about the state of the 'inband signalling'. It > works but its not stable? There is an fpga image but no source code? > Chime in if you know! > > > > > If there is an underflow during a RX capture, will the samples just be > > missing (and therefore potentially desyncing the receiver) or have a > > 'hole' of zeroes of the correct length (it would be way better as a sync > > at least would be preserved). > > The USRP1 under uhd will behave like the gnuradio USRP1 driver. So > samples will just be missing and maybe an 'O' is printed. > > If the packets had timestamps, it would be easy to integrate with the > uhd's rx_metadata. :-) > > -Josh > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
