[hpsdr] Proposal for a new Software project.

[Larry Gadallah]

Hi Chris:

Chris Albertson wrote:
> 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 work in the industry too, and I agree with your comments above 100%. 
It is frightening to see how frequently this is not done, or done badly.
> 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?
>   
I don't want people to misinterpret my comments. All I was trying to say 
is that the QS1R/SDRMAX software has a better architecture than most, 
based on the current state of the art. It is definitely not the 
ultimate, be-all solution, just a step in the right direction, IMHO.

This is probably a good point to mention that there is a significant 
amount of pragmatism required in amateur/open-source projects. To make 
the system engineering job even more complicated in an open-source 
environment, you have to produce a solution that:

1. Arrives quickly enough for a critical mass of technically 
disinterested users to adopt it
2. Is able to be refactored/rearchitected without significantly 
affecting #1 above
3. Provides enough capability to interest technical users who will help 
to evolve it

If it takes too long to produce a technically perfect solution, the bulk 
of the users will have already moved on to some sub-optimal solution in 
the meantime.

It seems to me that in order to even start on a top-down analysis of the 
architecture of this software, a set of use-cases needs to be derived. 
Based on these, the major components of the architecture could be proposed.
>
>
>
> 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).
>>     
>
>   


 1259624231.0