[hpsdr] HPSDR software direction

[Chris Albertson]

There needs to be a set of rules for defining an interface.   One should be that information about an object (I will not call them servers and clients, they are all equal "peers") is contained ONLY within the object.  This sounds easy but it is so easy to violate this rule.  The e-mail quoted below does.  He has the GUI telling the DSP  engine about hardware.   This kind of thing makes for a complex interdendancy where modules can't be independently developed.   In this example you could not add support for different hardware without modifying the GUI because the GUI needs to know about what hardware is available so it can tell the DSP engine about it.   Software is full of problems like this unless yu think about it and make some cast-in-stone rules.     If one is "information about an object will be stored ONLY within the obectitself then the GUI would query the hardware.  The method would be to broadcast a querry like "any SDR front ends in the room?" then zero or five might respond.  Later it might ask each for details one SDR front and at a time.         I would let Object" be defined by the person building it.  But any object needs a certain minimum set of abilities like to be able to respond to broadcast queries.  Like;y a hardware object would include the hardware plus some kind of "driver" or "wrapper".    We need to get out of the mode where we think of interface as a pipe, no it is a language that you speak to your peers with.  The language might sund like this "Mr. DSP, I want you to take data from paul and send it to joe."  DSP would them ask both Joe and paul abut who there are and what they can do.  The person making the request never has to hold information that describes DSP, Joe or Paul.  So if Joe contains plug-in devices and one of those gets un-plugged no one has to be told abut the un-plug event


On Aug 5, 2010, at 7:59 PM, Ray Page wrote:

> ***** High Performance Software Defined Radio Discussion List *****
> 
> I like the gist of Phil's idea. I think it has the potential to make the effort of developers bear more fruit. For instance, if the DSP server interface is defined (no easy task) then a number of "camps" can build servers the way they think is best. By making the software architecture modular, users can piece together "the best" collection of components for their application. If I like GUI-C and my hardware supports DSP Server-A, then I can have my cake and eat it too. 
> 
> Not to minimize the effort required, but all we're doing is standardizing the DSP in/out interface. The hardware enumeration capability would be fantastic, but should probably be apart of the GUI function. I think the DSP engine should be somewhat dedicated to the DSP task. Client software will configure the DSP engine through a standardized command interface and tell it the nature of the raw input data streams, what to do to those streams, and the format of the data-out streams.
> 
> I don't know about the rest of you, but this approach liberates me, because it gives me a black box with defined gozinta's and gozouta's, leaving me completely free to implement the inside of the black box however I want, OR to not worry about what's inside the box and work on the other stuff. It should also make benchmarking easier. The "sever" can run on the same computer as the GUI, or on a dedicated box on the network, allowing me to tool around the house with my wireless laptop, which wouldn't have the needed horsepower to do the DSP stuff.
> 
> -Ray KF5HNK
> 
> 
> 
> 
> 
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/


 1281068023.0