[hpsdr] HPSDR / PowerSDR hardware selection

[Michael White]

Hi Frank

Thanks for the info. I guess another boost will also come from sheer  
processor horsepower as time marches on.

The fundamental issue I have with SDR DSP sitting on a PC, is that  
without a pre-emptive kernel (with associated well behaved re-entrant  
code sitting on it), it seems to me it will always be a struggle to  
engineer a deterministic result using PC OS's. , both Linux and  
Windoze. XP. (forget Vista for now).

Fine tuning, adding horsepower and a bit of pixie dust here and there  
is to my mind the best that can be done, but there are no guarantees  
the OS or some errant hardware driver won't suddenly branch off into  
some other low level task to spoil all that careful tuning.

The professional audio industry solved the problem with off board DSP  
processors that connect via firewire. Pro Tools did it with plug-in  
PCI co-processor cards etc etc.

With HPSDR we are routing complex audio at high speed off the hardware  
via USB , processing it on the PC OS and then sending it back to the  
hardware via USB. I just cant see how that architecture will persist.  
At least this allows us code our own software and experiment which is  
just the ticket, so long live HPSDR. But to build a CW contest capable  
SDR that way is another matter.

Michael White
G3WOE.






On 23 May 2008, at 04:49, Frank Brickle wrote:

>
>
> On Thu, May 22, 2008 at 12:07 PM, Lyle Johnson <kk7p at wavecable.com>  
> wrote:
> ***** High Performance Software Defined Radio Discussion List *****
>
> Certainly one of the biggest issues I have stumbled on with SDR is  
> full break in CW which is defeated by latency in the OS.
>
> One of the drivers for Sasquatch, or embedded DSP in general.  In  
> the K3 we have minimized latency and taken advantage of the buffers  
> to allow QSK at 40 WPM plus, so I know it *can* be done!
>
> Under Linux, using the latest JACK audio system, it's quite  
> practical to use 64-sample buffers at 192kHz in full duplex. That's  
> a little over 300usec/buffer. A digital audio workstation  
> application like Ardour does it all the time, in multiple channels  
> on off-the-shelf hardware. Not an interrupt handler in sight.
>
> Current SDR implementations are pretty far behind what the OS's can  
> support and what applications are using at this point, especially on  
> multicore machines. It won't take long to catch up, however.
>
> 73
> Frank
> AB2KT
>
>
> -- 
> The only thing we have to fear is whatever comes along next. --  
> Austin Cline

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20080523/84fca1c4/attachment-0003.htm>