On Dec 28, 2007 2:15 PM, Ed Russell <[EMAIL PROTECTED]> wrote: ...the > radio will consist of three discrete components, which communicate > via hardware and/or software interfaces.
Roughly three. There may be quite a few more logical pieces, implementing things like multiple receivers, etc. The Core component communicates with the Console component via the > CAT command language on a messaging interface, whether comm emulation > or some other. Provision is to be made for either streaming > panadapter and meter info, or externally controlling a > panadapter/meter window. CAT is one path. It's a protocol layer between an application and the Virtual Radio Kernel. > > > With this breakout it is possible to clarify my earlier question, > which has two parts: > > 1. What will be the development language of the Core DSP and radio > control component? It is currently a mix of c and c#. Will this be > remodeled? No, the DSP core is pure C, and has never been anything but. That is not likely to change until third quarter 2009. We're still evaluating what DttSP 3.0 will look like. > > 2. What will be the development language of the Console component. > > Although users may create their own, I assume there will be one > "official" UI. What will the development language and environment be? > It is currently c#. Will this be ported or rewritten in something > else, perhaps java? For the time being the Windows version will almost certainly be a very close version of the current C# console, while the Linux/OSX/BSD version will be John's new creation in Java. Beyond that we're envisioning a completely new structure making heavy use of 3D compositing window managers. John has already made some forays into this territory with his Java console and Sun's MPK20 virtual collaboration space. > > I am suggesting that the search for development tools and environment > has priority over implementation details, because the latter depends > so intricately and completely on the former. Understood, but I have to stress again the emphasis here is on protocols, not APIs. One of the reasons for this emphasis is to take pressure off the selection of development tools and environment :-) 73 Frank AB2KT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/attachments/20071228/984468d9/attachment.html _______________________________________________ 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 Knowledge Base: http://kb.flex-radio.com/ FlexRadio Homepage: http://www.flex-radio.com/
