On Wed, 2006-08-23 at 07:35 -0700, Jim Lux wrote: > At 12:37 AM 8/23/2006, Bob Cowdery wrote: > >On Tue, 2006-08-22 at 22:54 -0700, Jim Lux wrote: > > > > > I've been waiting for the long > > > anticipated UI/backend split with a well defined interface, as announced, > > > gosh, several times over the past couple years. That way, I can do what > > > *I* want to do, without having to insert it into the middle of PowerSDR, > > > with all that entails. I'm not the only one asking for the ability to > > have > > > some well defined interface for "plug-ins", so, you'll excuse my > > admittedly > > > snide RSN comment (http://en.wikipedia.org/wiki/Real_soon_now) > > > > >Am I the only one that doesn't understand this. As far as I can see > >there *is* a good split between the DSP and the rest of the radio. > > Perhaps it's a difference between expectations and reality? > We've been hearing about a well defined (i.e. documented) interface between > the realtime radio code and the control interface for some months now. > (Version 1.7?) > > Is there? If you download the latest PowerSDR is there an obvious > interface layer between the "radio" code (dttsp, and the interface that > controls the SDR hardware) and everything else? Or, does it all have to > get compiled together? > Jim, I fully understand what you mean. Perhaps its the starting point which differs. The backend I use when on Windows is the pure DSP code plus my own audio code packaged with a very simple interface. This makes it look almost the same as the Linux version (which has always had excellent separation, heck its a different process, how more separated can you get) from a programming perspective except I call a function with the DSP control string rather than shove it down a pipe or receive data from a pipe. The interface really is very simple mainly because I keep it at the string command level rather than enumerating all the possible functions as PowerSDR does. And, yes the jumping around between C and C# does make it look like a complicated interface when in fact it isn't.
The controller is just a C module which I link and call exactly the same way on both platforms (in fact the C# implementation is more complete at this time but I've dropped using it because I don't want to bridge into the .NET platform). These interfaces could be defined such that people don't have to to search out how to use them but I'm not sure it would solve the problem as I'm not sure what the problem is. All it would let you do is write a front end which right now is an awful lot of code to get anywhere near the PowerSDR functionality and frankly the extra day you would need to spend figuring out the interface will get lost in the noise. If you want to write front ends (and I don't think you do) then you need a much higher level interface at the presentation layer which hopefully the various efforts going on right now will eventually give you. If you want to plug-in user defined things either at the user interface level (say a new tuning control) or at the DSP level, say your own AGC algorithm then that's a whole different game and I defer to the guys that know 'the plan' for that. > There is also a plethora of little pieces that all have to work together > (which is how ALL real applications work at some level, so no complaints > there), but to me, a well defined interface would have ONE place where > you'd go to figure these things out. Not, Oh, you make these DLL calls to > dttsp, then call this routine to control the 9854, and then, you have to > support this other callback to display data from the dsp, and, you also > have to manage pthreads and portaudio. > > Where's the "abstraction layer"? > I'm not going argue for or against the way its done on Windows. It's pragmatic because of who is responsible for what. The lack of reasonable ways to split Windows programs into processes makes life difficult. I'm sure Bob, Frank and Eric have a way forward. Maybe erlang is the way to bring processes to Windows. I'd only be guessing so best keep quiet. > Frankly, I'm not interested in reverse engineering the architecture, > particularly if it's going to change in the future. > > > > I > >avoid saying UI because there is a heck of a lot of code which is > >neither DSP nor UI. This not inconsiderable wadge of code is what I am > >incorporating into a middle tier with a defined interface to the UI. > >This interface will be defined in terms of JSON (www.json.org). Whether > >anybody else is interested in this approach is academic. I just wanted > >to point out I don't follow the line of thought. > > > This is interesting.. > > > > Jim > > _______________________________________________ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
