[hpsdr] HPSDR / PowerSDR hardware selection

Sun May 25 07:38:00 PDT 2008

I use Microsoft's VC++ 5.0 to develop programs for Windows. In DEBUG mode it
continually allocates memory until the system crashes! So bad I have to use
the RESET button on the computer to restart.

I plan to try and use a PIC DSP to do the FFT operations done by the PC
software. Since the PIC DSP will be dedicated it won't be sharing time with
other applications. But the sample rate is limited to 100KS/S. But that
should be just fine for my application. To do it faster I would have to use
an external A/D.

Bob Macklin
K5MYJ
Seattle, Wa,
"Real Radios Glow in the Dark"
----- Original Message ----- 
From: "Michael White" <michael.white at zytac.com>
To: <hpsdr at lists.hpsdr.org>
Sent: Sunday, May 25, 2008 6:28 AM
Subject: [hpsdr] HPSDR / PowerSDR hardware selection

> ***** High Performance Software Defined Radio Discussion List *****
>
> I totally agree Glenn.
>
> I am aware that with mainframe computing "Page Faults" i.e. access to
> virtual memory is a sin to be avoided at all costs, yet with Windows
> even if you furnish the machine with insane amounts of memory the vm
> access continues. At a guess I would say the page faults you are
> seeing are coming from a periodic garbage collection routine designed
> to keep the vm access as efficient as possible.
>
> To me this is a problem with these type of OS we can only really guess
> what is going on under the hood. It is so difficult to properly
> engineer a real time system using Windows or even Linux, because the
> guts of the system is inaccessible  (to most people),  and getting a
> setup that has a low probability of buffer overrun is something of a
> black art. You would think that throwing sheer horsepower at the
> problem would gradually ease the difficulty but of course the OS's
> just become more bloated as the new hardware resource is simply
> squandered by the next version of the OS.
>
> Unix to my mind is the best PC OS in that regard.
>
> However I stand by my earlier comments. I doubt if linux can be
> engineered to be deterministic.
>
> To my mind to build a real-time SDR we would need to engineer an
> embedded processor either for stand alone use or possibly using the PC
> for GUI  with some command and control. This embedded solution,
> (Sasquatch concept) , would benefit from a floating point math co-
> processor for the heavy lifting.
>
> HPSDR contributors have studied and reviewed what is available in the
> DSP market. I personally believe the TI..... 6713 is a pretty good
> compromise and has a low cost tool chain available.  (See previous
> postings.)
>
> Or there are a whole host of powerful and useful embedded processors
> and RTOS options out there, it is a very  interesting area to study.
> Overall I think the Saquatch concept as it stands is pretty good and
> personally I would encourage and support its development.
>
> 73
> Michael White
> G3WOE.
>
>
> On 24 May 2008, at 00:07, hpsdr-request at lists.hpsdr.org wrote:
>
> > Send Hpsdr mailing list submissions to
> > hpsdr at lists.hpsdr.org
> >
> >
> > Message: 22
> > Date: Fri, 23 May 2008 16:07:27 -0800
> > From: Glenn Thomas <glennt at charter.net>
> > Subject: Re: [hpsdr] HPSDR / PowerSDR hardware selection
> > To: hpsdr at lists.hpsdr.org
> > Message-ID: <7.0.1.0.2.20080523153230.02390fc0 at charter.net>
> > Content-Type: text/plain; charset="us-ascii"; format=flowed
> >
> > Well... I don't agree. On my SDR1000, I was having occasional drops
> > and hiccups during both RX and TX. After shutting down everything
> > else that might be running, including anti-virus and numerous system
> > services that I don't think I need (i.e. indexing), the problem did
> > not go away. Running the XP performance monitor at length I learned
> > that every so often, for no apparent reason (nothing running other
> > than PowerSDR and performance monitor), XP chooses to do something
> > with its page and swap file, thus generating a LOT of page faults and
> > the resulting disk activity. Apparently page fault activity
> > occasionally out-prioritized the application (PowerSDR) for a
> > sufficiently extended period of time to cause the drops and hiccups.
> >
> > The fix here was to set up a different, faster, processor with more
> > memory. That fixed the problem - most of the time - though XP still
> > wants to do it's page fault thing every so often. The difference in
> > my newer system is that with more physical memory, fewer page faults
> > should occur. FWIW, I saw nothing that leads me to believe the
> > PowerSDR was gobbling so much memory that it was causing the paging
> > storm. This is because SDR ran just fine with no page fault activity.
> > Also, XP likes to do its page fault trick with nothing running at all
> > (except performance monitor).
> >
> > Thus it is clear that a rogue service routine - or possibly even XP
> > itself - can indeed sneak in and corrupt timing by causing an
> > unreasonably large number of page faults. In this respect, it is not
> > clear that XP is capable of being properly configured.
> >
> > 73 de Glenn WB6W
> >
> >
> >
> > At 11:08 AM 5/23/2008, Frank Brickle wrote:
> >
> >> On Fri, May 23, 2008 at 4:30 AM, Michael White
> >> <<mailto:michael.white at zytac.com>michael.white at zytac.com> wrote:
> >>
> >> I think you're vastly overimpressed with what even the best current
> >> QSK radios are actually doing, and that you're vastly underimpressed
> >> with what current off-the-shelf hardware and software are actually
> >> doing in practice all the time these days.
> >>
> >> In any case, the idea that a rogue service routine can sneak in
> >> behind you and corrupt your timing is, on a properly configured
> >> system, just silly.
> >>
> >> 73
> >> Frank
> >> AB2KT
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > HPSDR Discussion List
> > To post msg: hpsdr at hpsdr.org
> > Subscription help: http://lists.hpsdr.org/listinfo.cgi/hpsdr-hpsdr.org
> > HPSDR web page: http://hpsdr.org
> > Archives: http://lists.hpsdr.org/pipermail/hpsdr-hpsdr.org/
> >
> > End of Hpsdr Digest, Vol 27, Issue 20
> > *************************************
>
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at hpsdr.org
> Subscription help: http://lists.hpsdr.org/listinfo.cgi/hpsdr-hpsdr.org
> HPSDR web page: http://hpsdr.org
> Archives: http://lists.hpsdr.org/pipermail/hpsdr-hpsdr.org/
>

 1211726280.0