[hpsdr] Proposal for a new Software project.

[Chris Albertson]

Have you'll seen Frank's "FSM" talk abut how this should be done?
http://frank.brickle.googlepages.com/FSM-talk.pdf

I think the hardest part is defining interfaces.  What should the API
for an SDR core look like?

Does it allow for many frequencies to be tunned at the same time, how
are multiple audio feeds to be routed out of the engine.   What about
digital modes?  Hopefully we don't have to we don't need to convert to
audio first?  At what level to Morse code de-coding go?  What if the
transmitter doing the CW is drifting?  Hundreds of these kinds of
questions need to be answered

I've been in the software business for 20+ year, many large projects
and I know one thing -- getting the requirements and interfaces
"right" or not will determine if the project fails or not.  Most
failed project fail because of the poor quality of the up-front work
and lack of documentation of requirements and interfaces.  We call
this "system engineering" and it is the hardest part of the project

I think you need to divide the system into more parts than just
"engine" and "gui".  What if someone want s to run multiple front
ends?   What if some one wants to use a set of real hardware rotary
encoders for controls?  How does all this work get distributed over
multiple CPU cores?   Can the GPU be put to use?




On Mon, Nov 30, 2009 at 1:05 PM, Larry Gadallah <lgadallah at gmail.com> wrote:
>.... The GUI is completely isolated from the
> engine/server that takes care of communicating with the SDR hardware, doing
> filtering/demodulation/AGC etc. The two components are isolated so well that
> each one does not have to use the same language, middleware, platform, etc.
> This provides tremendous flexibility, as has been demonstrated by at least a
> dozen variants of the SDRMAX software being deployed for Windows. Mac OS X,
> Linux, and even Pocket PC (I think).

-- 
=====
Chris Albertson
Redondo Beach, California

 1259621992.0