[hpsdr] Starter question

[Eric Blossom]

On Thu, Nov 16, 2006 at 08:23:08AM -0000, Bob Cowdery wrote:
> Hi Eric
> 
> As you are writing this I guess this is the definitive statement of how it will work.

This is the current plan.

> > I think either of these approaches is technically feasible.  Right now
> > with the current USRP firmware + host code we use 3 endpoints, ep0 for
> > control and status, ep2 for streaming Tx samples and ep6 for streaming
> > Rx samples.  ep0 can be opened by multiple processes, so that part
> > works OK.  ep2 and ep6 may each be opened by the same or a different
> >processes, but only a single open per endpoint.
> 
> So it does in fact work the way (from a host pont of view) I would like it to at the moment.
> 
> > That said, I'm going to be changing the host+firmware such that
> > control/status is passed "in-band" with the data.  Part of the problem
> > with the existing setup is that control messages on ep0 are sent
> > across the USB at higher priority than the data messages.  This means
> > that it's pretty much impossible to figure out when a control message
> > has actually taken place with regard to the flow of samples to/from
> > the device.
> 
> > This makes it hard to write host code that for example scans the front
> > end across a wide band, since it's pretty much indeterminate as to
> > when the "new samples" start coming.  The kludge is to wait "a while",
> > but this kills your scanning rate.
> 
> > With "in-band signaling" you can provide a "host cookie" with the the
> > tune command.  The host cookie could be a monotonically increasing
> > value that is stored in the FPGA and then copied into the outgoing
> > data headers.  You'll still need to account for time required for the
> > front end PLL (if any) to settle, etc., but the temporal ambiguity of
> > command vs data will be resolved.  This will also allow pipelining of
> > control.

> Can I check I have the right understanding here. If I compare with
> the SDR1000 at the moment we also have no idea when the new samples
> start, especially as there is a lot of buffering going on. If I tune
> faster than the latency of the system the samples will get
> behind. If I knew when the samples started related to the current
> frequency (using your host cookie method) then I would guess holes
> could develop in the audio as samples would be ignored until the
> right ones arrived.

Yes, you'll have to ignore the number of samples that correspond to
your front end settling time.  Not sure how long that is on the
SDR-1000.  On the RFX-* daughterboards, it's about 200 us.

Just to clarify, I'm talking about sending the "tune command" over the
USB to the FPGA where it is "intepreted" into appropriate big
banging, etc.

And there are two independent latencies.  One is the round-trip
communication time, the second is the settling time after issuing a
tune command.

> In the system I am developing there is a lot of
> concurrency so potentially frequency commands would get queued it
> they were not consumed fast enough and therefore the display could
> say a different frequency to the last frequency command that was
> sent. Does in-band signalling mean commands are interleaved in the
> output data itself at any point or only discrete points?

Only at discrete points (the data will be fragmented into fixed length
packets).  If it's not at discrete points, then you need a "quoting
mechanism" to ensure that data is never confused with signalling.  The
packet size is yet to be determined for the gigabit ethernet case, but
for USB the packet size will be 512 bytes (== 128 complex samples -
the header we'll be adding).  At 8 (complex) MS/s a packet contains
about 4us worth of data.

> I think I will need to close the loop so the tuning rate is regulated to be
> within the latency of the system, which shouldn't be too difficult.

At least with regard to the communication latency, what I'm proposing
does not have that particular limit.  That's the part about
pipelining.  For the sake of discussion assume that there's a "ping
command" and that it takes 10ms from the time you send it from the
host, until the host receives the reply.  Also assume that every 2ms
you send a tune command (interleaved with the transmit data) and that
each tune command contains a unique "host cookie".

Thus, I've got 5 pipelined tune requests, and by examining the
received host cookie in the header of each packet, I can match samples
to frequencies.  

If you think about it this way, the GUI doesn't change what it
displays until it receives the corresponding host cookie on the
receive path.  Or it has a "set point" and an "actual" like an
industrial control system.  Or a "tuning in progress light" that goes
out when it's locked, or some such.  If the latency is < 10 ms, I
suspect that you can just update the GUI when you receive the cookie.

Eric, K7GNU

 1163699031.0