On Thu, Jun 17, 2010 at 12:50 PM, Peter G. Viscarola <[email protected]>wrote:
> <QUOTE> > > Me too. But requirements and architecture/design docs are needed first. > > Not always. When moving into virgin territory often the right answer is to > code something to test a concept, knowing that it is expected to be > discarded and rewritten. > </QUOTE> > > Agreed. But this is sooo not virgin territory anymore. > Not sure I agree. We are talking about SDR, not YAHT (yet another ham transceiver). We are going to be dealing with multiple back-ends covering hundreds of kHz using many CODECs in parallel. The current model of PSDR is so far away from that it isn't even in the same ballpark. So, is it a radio or is it a transparent series of communications channels? This is NOT a trivial question. > > <QUOTE> > > There are a number of us who've been asking for proper architecture > and/or > > design documentation for the software for years. > > Well, it doesn't appear to have been designed. It appears to have evolved. > The first cut has been developed and everyone has learned from it. I think > we should put together a loose framework document, if for no other reason > than discussion purpose. After all, we need something to have a flame-war > over at least once! ;-) > </QUOTE> > > Yes, agreed. > > If by "loose framework document" you mean "product requirements and > architecture document", I think that'd be a great idea. And valuable for > all concerned. > No, I mean "loose framework document", something that will stand as a straw man for us to beat on and use as a placeholder in our minds. I don't think we know enough to produce a product requirements and architecture document. But if you want one, write one. It can stand in for the initial straw-man so we can have something to beat on. > > <QUOTE> > That is fine when the application is clearly and finely defined. I see the > SDR system for Flex as being a bit more out in the wilderness which makes > the development iterative. > </QUOTE> > > I don't agree that we're STILL out in the wilderness. Not at all. > What is an SDR? > > Do we not understand the product requirements? I don't think we do. > I'd argue that we do (or we can, at least pretty well). Do we not > understand the constraints of the environment and the solution space? I > contend that we do. Do we not understand the tools available to help build > a solution to meet the requirements? Again, I say we do. > Then we disagree. > > So, really, this is no longer wide-open, unformed, space that requires > ground-breaking innovation. Gerald and company have already DONE that, from > vision to implementation, and what they've done has been damn impressive. > Groundbreaking. Paradigm shifting, in fact. > No, they haven't. What they built with the Flex 5000 is YAHT. That doesn't make it bad. The Flex hardware when combined with PowerSDR makes one hell of a YAHT. OTOH, what Flex has built with their CDRX-3200 breaks new ground. There is nothing preventing us from having some of the capability of the CDRX-3200 with proper software. PowerSDR is absolutely, positively, definitely not it. So, if you are thinking in terms of something even remotely PowerSDR-like, we are not on the same planet. What PowerSDR did was to provide a platform to test some of the nifty algorithms. It was a framework hacked around a bunch of midware library modules so they could be tested. Now comes the time to start work on the next generation of radio communications *SYSTEM*. To me the sheet looks awfully bare and clean. I think that Flex's code name "Deep Impact" implies that it will be seriously ground-breaking. Here is the thing: if you can still compare it to a box radio, and the comparison between the Flex 5000 and the K3 goes on every day, then you haven't escaped from the F5K being YAHT. So it is time for a REAL paradigm shift. PowerSDR isn't. > > What we need now is the NEXT evolution of the software. And ensuring that > software is world-class will require solid engineering discipline. > You are thinking in terms of building the world's best buggy. I am thinking in terms of building the world's first airplane. > > <QUOTE> > I would propose a separate architecture mailing list. It is useful to > brainstorm on how the features would fit into the architecture. If the > interface is placed in the right spot in the stack, the interface will > exhibit an elegant simplicity. > </QUOTE> > > That'd be cool. > It is the way of all zen software that has achieved nirvana. > > Or, how about a multi-day, live and in-person, architecture review (sorta > like an IETF meeting)? > Most real IETF meetings take place in email. The physical meetings exist primarily to facilitate MFLAD (many fine lunches and dinners -- to quote Geoff Goodfellow). But before that someone hacks some software and writes up a first draft of an RFC. (Well, that is how we used to do it. The IETF has become very ISO-ized and, therefore, mostly useless, with cisco and Microsoft packing the WGs.) But it sounds like you are ready to write that first RFC. Go for it! I am ready to beat on it! ;-) Just one word young man: Interfaces. -- Brian Lloyd, WB6RQN/J79BPL 3191 Western Dr. Cameron Park, CA 95682 [email protected] +1.931.492.6776 (+1.931.4.WB6RQN) _______________________________________________ Flexedge mailing list [email protected] http://mail.flex-radio.biz/mailman/listinfo/flexedge_flex-radio.biz This is the FlexRadio Systems e-mail Reflector called FlexEdge. It is used for posting topics related to SDR software development and experimentalist who are using alpha and beta versions of the software.
