At 02:17 PM 8/23/2006, Bob Cowdery wrote: > > 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.
So, what you've effectively done is define an interface abstraction layer that supports a subset of the dttsp functionality, and stripped away all of PowerSDR on top. I've done something similar, except I use matlab for the dsp and I've created a command interface to the hardware that just reads and writes from stdin/out. But neither of these is really PowerSDR anymore. They're a totally separate system (albeit sharing some commonality with PowerSDR). > And, yes the jumping around between >C and C# does make it look like a complicated interface when in fact it >isn't. That's partly the fault of the "windows way", and I don't hold it against PowerSDR developers. The problem I have is that you go into the definition of the interface (in dsp.cs) and you have well over 100 entrypoints defined, with almost nothing that tells you what they do, what the parameters might be, or how they fit together. This is kind of scary when you see entry points that are clearly "flow" related (as opposed to set and get parameters): cwtimerfired, ProcessSamplesThread, etc. A simple entity relationship diagram that showed which data is going where, and, in particular, the realtime flow of data in and out of dttsp would be handy. >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. However, if the interface between the PowerSDR functionality (control and display-wise) were cleanly defined, one would be able to use the PowerSDR front end with a different backend, for instance. It's not clear just how tightly coupled and interdependent the front and back are. As you say, in the *nix world, you have a distinct process, and interprocess communication is fairly well defined and localized. In the current PowerSDR world, you've got a event driven UI calling routines in a realtime-ish backend running in a separate thread. Part of the problem is the incredibly clunky threading model in VS2003, and the fact that the interfaces are DLL style APIs, and not interprocess style messaging. And, because the interfaces have all been defined as unsafe public, etc., there's no real guarantee (enforced by the compiler/linker) that nobody is doing something evil (like looking in some other class's memory space) >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. Hmm. and that 'plan' is a bit vague and shifting. For example, say one wished to run 4 SDR-1000s, with separate dsp instances, but have a separate controller interface that talks to each of the dsps (say to adjust apparent IF frequency) and then bring all 4 (baseband) audio streams together. This is pretty darn clunky today, if even possible in a stable sort of way. A well defined "radio" interface would provide a clean interface to "command" the radio (setting frequencies and the like) and provide the baseband audio streams in a well defined way (whatever that is in the Windows media interface world). YOu can almost get there today by sending CAT commands to instances of PowerSDR, and using something like VAC to move the audio around, but there's a healthy amount of non-determinism in the system. > > 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. Yes, it makes it difficult.. but not impossible. There are a fair number of high performance multithreaded Windows applications around. Perhaps what we need is a skilled Windows programmer who knows this stuff, and who's willing to dig out the information. For that matter, VS2005/.NET 2.0 has a much better threading model. I say this having just spent a few days trying to write real time control stuff for multiple serial ports in that environment, but I will readily confess, it's not easy, and it's nothing at all like VS2003 or VB6, although closer to the Linux proces model. > 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. I think that Windows already has everything needed to do processes (and has had it since NT/XP). The problem is that the conceptual model (and the toolsets to work with them) are radically different than the Linux world. I doubt that one can be effective in both, because both require a fair investment of time and mind, as well as regular use, to maintain proficiency. I don't know that Erlang (or pthreads, for that matter) aren't just an attempt to mask process issues with an abstraction layer. The fate of the numerous "software that makes Windows look like Linux to an application" wrappers is that as the underlying Windows changes, someone has to be willing to try and follow along. The saving grace of something like Erlang is that it is funded by a big player (Ericsson), so as the underlying platforms change (inevitable for Windows), they'll keep it up to date. For that matter, it's not clear why PowerSDR needs to use threads (aka LightWeightProcesses) instead of just using real processes. Is there a performance issue with just using processes? Or is it a historical artifact.. the original program was simpler, it just grew and grew with new features, and now it's kind of hard to separate them. For that matter, I don't see PowerSDR being a multiplatform application, so the value of using pthreads (which lets you use POSIX threading everywhere) in the first place is limited. Maybe there are multiple threads in the DSP core? Seems that for this sort of application (radio) that a single thread (per direction Tx or Rx) would work. Certainly, I'd work pretty hard to make that model work first, because it's a heck of a lot easier to debug. I suppose if you are generating multiple audio streams from the same received I/Q stream (i.e. subreceivers), a multithreaded model would be helpful. Anyway... sometime in the future, all will be revealed <grin> 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
