[DSP-10] DSP-10

[Steve Bunch]

Bob,

I used to do cellphone software for a living, which is pretty hard real-time.  We used a real-time executive for the  main OS running the cellular protocol, but for the really critical timing stuff (like RX/TX at the correct slot time), we used special-purpose hardware.  We would load up a SPI-connected custom-silicon timing device with instructions of when to raise and lower digital lines that turned on/off power supplies, RX, TX, etc., and it would signal an attached DSP to supply or accept signals to the A/D and D/A converters and hardware accelerators.  As long as you could service the device with new schedule events in a timely fashion when things changed, the hardware and the DSP could keep a call going with the CPU loafing (in fact, halted most of the time to save power).  With that device going, the CPU could focus on other things without too much worry about blowing the schedule.  But amateur SDR just isn't that demanding.

As Ron says, you can make most any of the usual desktop OSs work with some tuning.  But you may still have problems.  After a brief period of tuning out big problems, I spent months tracking down a glitch I was seeing in my HPSDR system on WinXP, and narrowed it down to a device driver that I couldn't turn off.  Every now and then it took an interrupt and held onto the CPU for a long time (relatively speaking -- lot long in absolute terms but long enough to drop a sample packet) with interrupts off.  This caused glitches on RX, and presumably on TX.  Bottom line was that I couldn't fix that glitch on that computer, but fortunately, it really was a nit -- I was just being fanatical.  A friend at Microsoft who worked on them pointed out some performance measuring tools available on Win7 that make it much easier to find these problems, but they are developer tools and probably not easy enough to use for casual users.

If you want to do software that only you are running, tune away and good luck.  If you're going to do something that other people will run, you should anticipate that some people could have problems caused by their hardware and especially (as Ron says) their software.  Are those problems serious enough to build dedicated hardware to do the entire signal processing chain for, and give up the convenience of using your "main" computer with its high-powered CPU, graphics, and big display for SDR?  Probably not.  What I think I'd do for a commercial product is to make the amount of buffering, and therefore the lag time, tunable and automatically bumped up based on incidents of underrun and overrun (easy enough to determine if you timestamp your sample packets).  If the customer doesn't like the lag you tell him you're using, then he gets to spend some time tuning.  If he's happy with it, all's well that ends well.

73,
Steve K9SRB

On May 3, 2013, at 1:44 AM, Ron Kolarik wrote:

> Almost any OS can be fine tuned to worked. I've fought the SDR wars
> with XP and Win7 and mostly it boils down to motherboard (BIOS) and
> turning off anything in OS "services" that isn't really needed, i.e. indexing,
> wifi and finding software that doesn't want to phone home every 5 minutes.
> Auto-updates and anti-virus are some of the worst offenders. Get a DPC
> checker, http://www.thesycon.de/deu/latency_check.shtml is a good one,
> and find out what is hogging CPU cycles. I'm far from an expert on the subject
> but this may be a good starting point.
> 
> Ron
> K0IDT
> 
> ----- Original Message ----- From: "Bob Larkin" <boblark at proaxis.com>
> To: "Discussion of DSP-10 2-meter transceiver" <dsp-10 at mailman.qth.net>
> Sent: Friday, May 03, 2013 12:05 AM
> Subject: Re: [DSP-10] DSP-10
>> One thing that would be easy to do is a simple program that transmits a bunch of dots to see how "real time" the various OS are.  That might give an idea as to whether it is worth considering.
>> Thoughts?
>> 73, Bob  W7PUA