On Fri, 2006-08-25 at 23:29 -0400, Robert McGwier wrote: > Frank Brickle wrote: > > On Wed, 2006-08-23 at 08:37 +0100, 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... > >>> > >>> > >> 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. > >> > > > > *I* thought so too ;-) > > > > > >> 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. > >> > > > > Just to be explicit, this wadge of code is exactly the "radio kernel" > > we've been talking about. Bob (this Bob!) has done quite a bit of work > > in the area already, very illuminating work one might add. There has > > been another experimental version of this, done up in python, for over a > > year now, as an item -- a "virtual radio" -- to contemplate and meditate > > over, for merits and defects. > > > > I have not found a pitfall yet. It has taken me time to get my old > "write iterative C/C++" code out of my brain and shifted into recursive, > functional list processing but it has been worth every single hard > step. This code is VERY compact. I really do hope we do not run into > any serious performance issues but so far, on Linux, Windows, and Mac > OS/X, erlc writes good code and the foreign language interface/ interop > to C/C++ is quite functional. Very very few people will need to write > erlang. It will be switching station for messages essentially between > distributed things where the core is required to learn and preserve > state while parsing/passing commands. > > > > Bob > > > > >> 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. > >> > > > > FWIW, the DttSP radio kernel is being developed and implemented in > > erlang. Barring unforeseen potholes, erlang will be the platform for the > > virtual radio.
Can I explore this a little because languages and distributed systems fascinate me and I want to understand more about whats good and whats bad for this application. I have an onion skin model of what I want to do and at that level I think its the same type of onion. I should draw a picture but lets make do with words. At the centre is good old sockets, next up is the messaging layer, then potentially but not necessarily language bindings. I say not necessarily because I have two options, a common messaging layer, say in 'C' with binding for each language I might want to interop with or language specific libraries (which is my current preferred route). The application layer then contains DSP, HW Control, GUI, Virtual Radio/ Middle Tier and Management. Each of those pieces will be a separate process interacting only through the messaging layer. There can of course be multiples of each and each can be in virtually any language as they are separated by process boundaries. I've done a lot of this several times before but I've used the capabilities of a specific language such as Pyro with Python and Opera with Squeak. That has required me to have the same language on both sides and therefore language bindings if I wanted the 'other' side to be in a different language. This is an extra hop with marshalling which adds complexity and impacts performance and in a lot of cases might not be possible at all. What I am aiming for now is an efficient language neutral messaging layer where each end can have its own language specific library. At the moment my favourite for this is JSON as being somewhat more efficient than XML and very straight forward to implement. This brings me to Erlang. I can see its a excellent concurrent distributed language. If everything in the system was implemented in Erlang or a minimal language mix I'm sure it would work great. However, if I want to say write my middle tier in Ruby and my front end as a Java web application with my process control layer (manager) in Python and the backend still being in 'C'. A bit of an extreme example maybe but it's a viable mix, I don't want to have to deal with a lot of language integration issues. I am drawing a big distinction here between the messaging layer and what's being called the virtual radio. I see these as completely separate things. The VR *is* the application and the messaging layer is the communications infrastructure which the VR and other processes use. > > > > A nice side-effect of this is the relative simplicity of talking to the > > kernel in any old language you choose. Another nice side-effect is the > > way erlang makes it possible to demonstrate (if not prove formally) the > > correctness of the kernel. > > > > I have seen some really serious papers on "proof of correctness" for > Erlang state machines. They are fascinating (if of limited relevance to > our ultimate purposes). I am finding a hierarchical state machine to be a very good fit for what I want to do in the VR layer. I have a sneaky feeling we are talking about quite different functionality in this layer but that for another time. > > Although it might not be obvious, we went to considerable lengths to > > show the correctness of the concurrency in DttSP. It's taken awhile to > > clear away the weeds around the underlying model, however. Exactly the > > analogous process is now taking place in connection with the kernel. > > > > > >> Incidentally I agree with the mode separation. The state machine I am > >> using in the middle tier is largely based on mode state, separately in > >> RX and TX. This gives the ability to finely control what happens in > >> different modes. > >> > > > > Thank you. This is the far and away best justification for > > one-size-doesn't-fit-all that's yet come to the fore. > > > > > >> However I do believe the request has more to do with the ability to have > >> control over the DSP configuration, to re-sequence blocks and insert > >> user defined blocks aka GNURadio style than it is to do with separating > >> DSP and UI. If I'm way off track tell me. > >> > > > > ...which is exactly what gnuradio is for! > > > > Except for hardware control, there's nothing standing in the way of > > using gnuradio with the SDR1K. It would be great if somebody would > > pursue it. > > > > 73 > > Frank > > AB2KT > > > > > > _______________________________________________ > > FlexRadio mailing list > > [email protected] > > 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 > > > > > > _______________________________________________ FlexRadio mailing list [email protected] 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
