[hpsdr] HPSDR / PowerSDR hardware selection

[T.W.H.Fockens]

Hello Michael,

There is a full desktop operating system which is co-operative
multi-tasking and very usefull in these kind of applications: Risc-OS,
running on ARM-like processors, see the links below:

http://www.riscos.com/
http://www.iyonix.com/
http://www.advantage6.com/products/A9home.html
http://www.drobe.co.uk/
http://www.riscos.info/index.php/RISC_OS

Developed in the UK in the nineties for the education market originally,
it is still very popular under enthusiasts. I use it as my work horse at
home as well as at QRL for more than 10 years, including measurement
applications.

Maybe this is an idea.

73,

Koos Fockens,

PA0KDF

On 23 May, Michael White <michael.white at zytac.com> wrote:
> ***** High Performance Software Defined Radio Discussion List *****

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


> --===============1270625449==
> Content-Type: multipart/alternative; boundary=Apple-Mail-27--851500854

-- 
Ir. T.W.H. Fockens
Kieftweg 1
7165BR Rietmolen

 1211541759.0