[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] inband signaling usb host

From: Eric Blossom
Subject: Re: [Discuss-gnuradio] inband signaling usb host
Date: Wed, 14 Mar 2007 07:24:37 -0700
User-agent: Mutt/1.5.9i

On Wed, Mar 14, 2007 at 09:47:08AM -0400, George Nychis wrote:
> First off, I never received the original e-mail that you are responding 
> to... was it sent to the board?  I don't see it in the archives either.  If 
> so, this is the second e-mail I've not received simply related to the 
> in-band signaling that was sent to the board.  I don't keep up with the 
> other threads to know my overall loss ratio :)
> David Scaperoth wrote:
> >So, when you are doing reception that has to be tightly coupled with 
> >time, how do you specify when to retrieve the samples? or were you 
> >thinking that you would simply keep receiving samples from the USB, and 
> >checking the time-stamp on the response_recv_raw_samples() to see if it 
> >was "just right"?  I would tend to think that only receiving samples 
> >when you wanted them would be ideal, and in that case you would need a 
> >time-stamp argument in the cmd_recv_raw_samples.

My original thought was to support two modes:

  (1) Just keep streaming samples at me.
  (2) The FPGA is doing some kind of packet detection, possibly linked
      to the AGC control loop, and it just sends when it thinks it's
      got a packet.   In this case, I think it freezes the analog AGC
      for the duration of the packet.

> I don't know if this was added in after your discussion or before, because 
> I see no response to your e-mail either... whether it exists and was lost 
> from my perspective, I have no clue :)  But...
> response_recv_raw_samples(invocation_handle, samples, timestamp, properties)
> I think that is what this method is for, you specify the timestamp at which 
> the first sample in the samples was received by the A/D converter.  So that 
> would follow along with your suggestion.

FYI, that's the response, not the command.

We could of course implement a third mode

  (3) Retrieve samples given the specified timestamp and duration

Except for reducing the aggregate USB bandwidth, I don't see this
mode as a big win.  Of course, if David's volunteering to implement it,
then no problem ;)

> In response to Eric's discussion question in the doc, I say we use 
> different modes.  I think that being able to specify the number of 
> cmd_recv_raw_samples commands and a flag would provide the most flexibility 
> and functionality.

I was thinking that a lot of this "mode stuff" gets set up by writing
specific registers in the FPGA.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]