Re: [Discuss-gnuradio] UHD support for USRP1

[Eric Schneider]

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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio