[hpsdr] Starter question

[Bob Cowdery]

Hi Eric

As you are writing this I guess this is the definitive statement of how it will work.

> 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. 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? 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.

> This then requires a "dispatcher" processes (or driver) to allow
> multiple processes to open the virtual device, but I think this is
> going to net out a win.

> I'm hoping to have this coded up by January.

> Eric, K7GNU

 1163665388.0