Eric Blossom wrote:
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 think (1) is mandatory and (2) is secondary. I would suggest against doing (2)
exclusively (not that you're suggesting it). Doing (2) exclusively could dampen future
packet formats, requiring more modifications to the FPGA. (1) is definitely the simple
approach from the FPGA standpoint. I'd say lets tackle (1) first.
What's the downside to this: "it freezes the analog AGC for the duration of the packet."
Feed my lack of an EE background... Thibaud is out of town for me to poke him :D
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.
Yeah, sorry...
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 ;)
Join us David ;)
I was thinking that a lot of this "mode stuff" gets set up by writing
specific registers in the FPGA.
I agree, sounds like the best approach.
- George
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
