[Flexradio] ModularSDR
Frank, Please excuse my pedestrian approach. I am trying to visualize the overall system including how it will be developed and maintained. Your very helpful comments indicate that in the next version, the radio will consist of three discrete components, which communicate via hardware and/or software interfaces. The Flex 5000 (mostly hardware) component communicates with the Core component (all software) via the firewire interface. 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. 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? Is c# available on linux? If not, will the c# part be ported to java or what? A cross-platform RAD environment would be desirable. 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? Here a cross-platform RAD environment would be highly desirable. Perhaps answers to these questions are in the process of being formulated. But it seems to me that they must be answered definitively before actual development can begin. 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. 73 Ed W2RF On 28 Dec 2007 at 10:22, Frank Brickle wrote: A good place to start is with the Extended CAT code vocabulary designed and implemented by K5KDN. The CAT codes, plus some simple extensions to fetch panadapter and meter data, give you most of what you need for a complete console. You're already most of the way there if you simply have your console code print ASCII equivalents to the CAT codes commands to a textfile. 73 Frank AB2KT On Dec 28, 2007 9:56 AM, guenter [EMAIL PROTECTED] wrote: Is there a way to see, test and comment the console (without function behind) before it is ready and integrated to the rest of SDR? And also to understand, how the interface works? May be, someone wants to write his own console. guenter DK1RI Am Freitag, 28. Dezember 2007 12:37 schrieb Frank Brickle: On Dec 26, 2007 7:34 PM, Ed Russell [EMAIL PROTECTED] wrote: What will be the development environment under Linux? Whatever you like. Since the system is protocol-based (not API-based) it isn't dependent on a particular environment or language. Likewise, the system isn't biased towards any particular GUI framework. Different pieces can be written to use different frameworks. However there's a new console in Java that's pretty close to completion. Java is a strong contender for GUI framework of choice. Many of us still use emacs as a programming editor since you don't ever need to take your hands off the keyboard to use it efficiently. But I don't think that's what you're asking :-) 73 Frank AB2KT -- next part -- An HTML attachment was scrubbed... URL: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/attachments/2 0071228/fef899e8/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/ ___ 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/ -- next part -- An HTML attachment was scrubbed... URL: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/attachments/20071228/d5261bec/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/ ___ FlexRadio mailing list FlexRadio@flex-radio.biz
Re: [Flexradio] ModularSDR
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/
Re: [Flexradio] ModularSDR
Quoting Ed Russell [EMAIL PROTECTED], on Fri 28 Dec 2007 11:15:29 AM PST: Frank, Please excuse my pedestrian approach. I am trying to visualize the overall system including how it will be developed and maintained. Your very helpful comments indicate that in the next version, the radio will consist of three discrete components, which communicate via hardware and/or software interfaces. The Flex 5000 (mostly hardware) component communicates with the Core component (all software) via the firewire interface. 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. Since I'm not a developer of this, I'm totally speculating here, but here's my guesses: I would assume that there is actually a slightly finer modularization in action here, because both the SDR1K and the F5K need to be supported, as do other interesting hardware platforms like the softrock and SDR-X, etc. So, I would assume that there is a/are component(s) that is responsible for managing the hardware interfaces (i.e. formatting and communicating via MIDI for the F5K, via parallel port for the SDR1K), which themselves have a message passing interface from a more generic radio core. This interface, I would assume, would look a lot like the current API(s) invoked by console.cs, except restructured for message passing (i.e. instead of calling int set_frequency(float frequency) you'd send a set frequency message) A question would be whether control of the second receiver board in a F5K is handled as a second instance of a receiver control component (in which case, someone has to arbitrate and sequence the messages to the F5K) or if it's rolled into the F5K control component. And, also, I'd assume that the dttsp core(s) is a separate component (since it's always been developed as such and has a fairly clean interface), to which the radio core sends various and sundry messages (set bandwidth, set modes, etc.) Multiple receivers would be multiple instances of a dttsp, fed from the same I/Q stream, but generating multiple audio outputs, which would then be mixed/panned/recorded/played back by standard audio software. The UI component would then talk to the radio core which would keep track of which signals are going where, etc. At this level (UI to radio core), it appears that the messages are structured along the lines of the CAT commands. Jim, W6RMK ___ 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/
Re: [Flexradio] ModularSDR
Jim, I think you have given an excellent and useful breakdown of what kind of things will be in the Core component. It will itself be a rather complex set of sub-components, that will be linked together by different kinds of interfaces than the firewire that links it to the hardware, and the (CAT-like) messaging protocol that links to the Console. So my first question can be restated as: In the Core component, how will its intricate sub-components -- many of which are real time and multi-threaded -- be coded, tested, and debugged? By comparison the current development is housed almost completely in Visual Studio 2003. What will take its place? One suggestion might be that any developer can use any tool at hand that he knows or thinks is appropriate. This creates a practical problem in that other people need to work on the code, both for development and maintenance. Imagine the hodge-podge of tools and specialists this might engender! Even if a few additional tools are needed on the edges, a central widely available and known (hopefully RAD) development environment is, in my opinion, essential. 73 Ed W2RF On 28 Dec 2007 at 12:04, Jim Lux wrote: Quoting Ed Russell [EMAIL PROTECTED], on Fri 28 Dec 2007 11:15:29 AM PST: Frank, Please excuse my pedestrian approach. I am trying to visualize the overall system including how it will be developed and maintained. Your very helpful comments indicate that in the next version, the radio will consist of three discrete components, which communicate via hardware and/or software interfaces. The Flex 5000 (mostly hardware) component communicates with the Core component (all software) via the firewire interface. 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. Since I'm not a developer of this, I'm totally speculating here, but here's my guesses: I would assume that there is actually a slightly finer modularization in action here, because both the SDR1K and the F5K need to be supported, as do other interesting hardware platforms like the softrock and SDR-X, etc. So, I would assume that there is a/are component(s) that is responsible for managing the hardware interfaces (i.e. formatting and communicating via MIDI for the F5K, via parallel port for the SDR1K), which themselves have a message passing interface from a more generic radio core. This interface, I would assume, would look a lot like the current API(s) invoked by console.cs, except restructured for message passing (i.e. instead of calling int set_frequency(float frequency) you'd send a set frequency message) A question would be whether control of the second receiver board in a F5K is handled as a second instance of a receiver control component (in which case, someone has to arbitrate and sequence the messages to the F5K) or if it's rolled into the F5K control component. And, also, I'd assume that the dttsp core(s) is a separate component (since it's always been developed as such and has a fairly clean interface), to which the radio core sends various and sundry messages (set bandwidth, set modes, etc.) Multiple receivers would be multiple instances of a dttsp, fed from the same I/Q stream, but generating multiple audio outputs, which would then be mixed/panned/recorded/played back by standard audio software. The UI component would then talk to the radio core which would keep track of which signals are going where, etc. At this level (UI to radio core), it appears that the messages are structured along the lines of the CAT commands. Jim, W6RMK ___ 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/
Re: [Flexradio] ModularSDR
Frank, Thank you for these very useful details. I need to look into John's work a bit. I realize that the DttSP libraries are c libraries and run on either platform. It is all the other code in PowerSDR that is not Console code, and is written now in c#, that I am wondering about. What will happen to it in the next version? Will it still be in c# on the Windows platform? This does point somewhat directly at a development environment choice. But there is another development environment/tools issue: debugging multi-threaded real time processes. This has to be integrated with a language compiler or interpreter. And it better be good :) 73 Ed W2RF On 28 Dec 2007 at 14:54, Frank Brickle wrote: 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 ___ 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/
Re: [Flexradio] ModularSDR
On Dec 28, 2007 3:45 PM, Ed Russell [EMAIL PROTECTED] wrote: Jim, I think you have given an excellent and useful breakdown of what kind of things will be in the Core component. Based on...what? Speaking here as one of the two sole authors of the Core component, I'm wondering: where on earth are you getting this idea? Furthermore what suggests to you that this bears any relationship to what's currently under development? Even if a few additional tools are needed on the edges, a central widely available and known (hopefully RAD) development environment is, in my opinion, essential. Have you actually looked at how the DSP core is organized and built? It differs not one iota from the conventional methodology used in the overwhelming majority of Open Source/GPL projects. Yipes, it's hard enough trying to explain what's actually going on, much less having to deal with footless fantasies of things that will probably never happen. This whole line of discussion is only serving to confuse the issues, far as I can see, and it's drifting quickly into a waste of precious development time. 73 Frank AB2KT -- next part -- An HTML attachment was scrubbed... URL: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/attachments/20071228/9c80fe80/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/
Re: [Flexradio] ModularSDR
On Dec 28, 2007 3:45 PM, Ed Russell [EMAIL PROTECTED] wrote: But there is another development environment/tools issue: debugging multi-threaded real time processes. This has to be integrated with a language compiler or interpreter. And it better be good :) I suggest you go away and study some of the copious information available online about Erlang and Concurrency Oriented Programming. That may set your mind at ease a little. Also, what is the current multithreaded system? Chopped liver? How do you think it was developed? 73 Frank AB2KT -- next part -- An HTML attachment was scrubbed... URL: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/attachments/20071228/eaa6a897/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/
Re: [Flexradio] ModularSDR
Quoting Ed Russell [EMAIL PROTECTED], on Fri 28 Dec 2007 12:45:53 PM PST: Jim, I think you have given an excellent and useful breakdown of what kind of things will be in the Core component. It will itself be a rather complex set of sub-components, that will be linked together by different kinds of interfaces than the firewire that links it to the hardware, and the (CAT-like) messaging protocol that links to the Console. So my first question can be restated as: In the Core component, how will its intricate sub-components -- many of which are real time and multi-threaded -- be coded, tested, and debugged? By comparison the current development is housed almost completely in Visual Studio 2003. What will take its place? One suggestion might be that any developer can use any tool at hand that he knows or thinks is appropriate. This creates a practical problem in that other people need to work on the code, both for development and maintenance. Imagine the hodge-podge of tools and specialists this might engender! Even if a few additional tools are needed on the edges, a central widely available and known (hopefully RAD) development environment is, in my opinion, essential. 73 Ed W2RF My observations, as someone who uses the code and has looked at its internals quite a bit, but who is NOT contributing changes to it (for a variety of reasons) are: 1) There's not all that many developers (a half dozen?) actually generating code for the platform, and they each choose the dev environment they're comfortable with, and sort of work out an ad-hoc arrangement to deal with compatibility issues. 2) While it's nice to think about contributions from the masses, the organizational infrastructure needed to manage that effectively, especially in a cross platform environment, is impractical for Flex-radio and PowerSDR. There's a fair amount of literature and analysis out there about the structure of software development projects, and when you get to a certain ill-defined size, some amount of structure and rigor becomes necessary. With 3 or 4 folks, not necessarily having to work towards a defined deliverable on a defined schedule with a defined budget, ad-hoc methods work just fine. (What is that, CMMI level 1?) 3) In order to handle effectively hand contributions from a large number of sources, it would require a slightly more mature development process (mature in the SEI/CMMI sense) with defined and published interfaces, defined architectures, some form of change control (not just version tracking, but a conscious decision of what goes into each successive build), QA processes, and so forth. I don't recall seeing an analysis of the Linux kernel dev organization in CMMI terms (I'm sure it has been done by some bright soul for their dissertation), but in practical terms, the kernel development process has just that (i.e. there are some gatekeepers who manage the process, following a fairly well understood set of rules, etc.) Flex-radio and the developers of PowerSDR and its pieces haven't really seen fit to work within that sort of process, and inasmuch as the current product works ok, that's fine, but it does create a fairly steep learning curve for would-be contributors. Recall that Flex-radio's goal is to sell radios, not necessarily to provide a complete development platform for software radio algorithm developers. The fact that Gerald made the (in my opinion) wise and fortuitous decision to start Flex-radio with a goal of open software/hardware is wonderful, but, he's also a realist and knows that the vast majority of sales will come from users not developers. Not only that but the cost to support developers is MUCH higher than to support users. There are companies that exist to sell platforms for development (like Spectrum Signal Processing, Nallatech, etc.) and their platforms are priced accordingly. A $15,000 hardware development platform isn't all that expensive in the context of a $100K seat license for all the FPGA tools which in turn is a reasonable expense in the context of $250k/yr engineers toiling on a $1B/yr in sales radio product. I don't see Flex-radio really getting into that market (except, perhaps as a hardware platform provider, providing board support package type info to a software radio tool vendor, who adds it to their list of supported hardware). I'm just speculating here, of course. (there is that recent agreement between a DoD radio provider and Flex, for instance). Such a vendor might have their own development platform and process that they wish to use, and there's no particular reason why it should be Free and/or Open Source. PowerSDR is sort of the basic software that needs to be provided so that people will buy the hardware and fills that role quite well for the amateur radio market. There's not much economic incentive to try and make PowerSDR a
Re: [Flexradio] ModularSDR
snip There are companies that exist to sell platforms for development (like Spectrum Signal Processing, Nallatech, etc.) and their platforms are priced accordingly. A $15,000 hardware development platform isn't all that expensive in the context of a $100K seat license for all the FPGA tools which in turn is a reasonable expense in the context of $250k/yr engineers toiling on a $1B/yr in sales radio product. snip $250K/yr radio development engineers? What radio industry do you work in and where do I sign-on? I've been a hiring engineering manager for many years in west coast high-tech defense, semiconductor, cellular, and commercial/military radio businesses, and have neither paid an engineer of ANY experience level that kind of salary, nor has such a beast ever been offered to me. Companies that plan to stay afloat for any length of time don't normally offer up that kind of dough - at least not down here in San Diego. Dan ___ 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/
Re: [Flexradio] ModularSDR
On Dec 28, 2007 10:14 PM, [EMAIL PROTECTED] wrote: $250K/yr radio development engineers? What radio industry do you work in and where do I sign-on? Dan -- Most of these numbers reflect the Martian world of huge govvie contractors, locked-up IP, and executing dollars. They're staggering under their own inertia and dead weight as it is. It's illuminating to realize that software development methodologies are all about cost accounting. They have nothing to do with software. If you have a chance to read or hear any of what Bruce Perens has to say about shared infrastructure and Open Source vs. differentiating technology, jump at the opportunity. He's really funny and eye-opening. 73 Frank AB2KT -- next part -- An HTML attachment was scrubbed... URL: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/attachments/20071228/1030b136/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/
