[hpsdr] Starter question

[Philip Covington]

On 11/15/06, James Courtier-Dutton <James at superbug.co.uk> wrote:
> Philip Covington wrote:
> > ***** High Performance Software Defined Radio Discussion List *****
> >
> > On 11/15/06, Christopher T. Day <CTDay at lbl.gov> wrote:
> >
> >> ***** High Performance Software Defined Radio Discussion List *****
> >>
> >> Bob,
> >>
> >> The way the protocol is currently designed, all the audio data and
> >> SDR-1000-type control data are interleaved into one byte stream into Ozy
> >> and one byte stream out. So, no, I believe you will not be able to run
> >> these functions in separate processes easily. Part of the idea of making
> >> the Janus/Ozy combo into a real audio card would be to separate the
> >> control functions into separate pipes so that multiple processes could
> >> work with the hardware as you would like. However, nothing much has come
> >> of that effort so far. [I've been one of those pushing that idea, but
> >> haven't managed to actually produce anything so far.] Note that this
> >> would involve a fairly deep redesign of the firmware in the FX2 and the
> >> CPLD/FPGA configurations.
> >>
> >>
> >>         Chris - AE6VK
> >>
> > It would probably be better to set up a user mode server process that
> > handles access to the OZY USB device that other processes can connect
> > to.
> >
> > I think it is a mistake to try to make OZY look like a sound card to
> > the system.  Right now we enjoy very low latency and overhead in
> > talking to the OZY via USB.  Making OZY appear as a sound card puts
> > more latency and overhead crud on top of what we have now.
> >
> > Phil N8VB
> >
> I don't know about windows, but for Linux having separate USB endpoints
> for audio and control would be considerably easier to deal with. It
> would not add any latency overhead by separating these. The best
> improvement to latency would be to use USB 2.0 high speed instead of
> full speed. I don't know which speed the OXY will be using. Using USB
> 2.0 high speed could also help with the import of more data from the
> Mercury board, for purposes of passing high speed sampling direct to the
> PC, for maybe the purposes of a high speed storage oscilloscope or
> better panoramic display.
>
> I was going to try to write a Linux driver for the OZY usb, but probably
> will not do it now because the current packing approach involves too
> much work and adds unnecessary CPU overhead in processing the samples
> due to extra memcpy() required when demuxing the stream. It is better to
> get the USB hardware to do the demuxing, and not the CPU.
>
> James

1. OZY uses USB 2.0 High Speed.  On my system I am able to sustain a
35 MByte/s transfer rate.  It appear even the crappiest motherboard
chipsets will do 20+ MByte/s.  It think in the very best case you can
get 40-45 MByte/s.

2. The protocol used for JANUS does not define the protocol used for
Mercury.  For Mercury I am streaming interleaved I and Q just like the
USRP does.  The Mercury does not use the "packing approach" like
JANUS.  Remember we have a FPGA on OZY so we can change the "approach"
at will.  In Mercury Endpoint 0 is used for all the control functions,
setting registers in the FPGA, talking I2C, etc..  Endpoint 2 is used
for streaming high speed data to the PC.  The protocol from/to JANUS
can be just as easily redefined because we also have a reprogrammable
CPLD on JANUS.  So nothing really is set in stone as far as protocol
goes.

3. My comments about avoiding making the OZY appear as a sound card
was in relation to Windows only having dealt with the nasty class
drivers for sound in Windows.  It does not apply to Linux.  Working
with hardware is much easier in Linux than Windows for sure.

Phil N8VB

 1163600958.0