" > And when will those specs be published? RSN? As soon as you've finished them, Jim. " I don't think you want me writing specs that you'll have to conform to, Frank. Defining specifications and architectures for abstract software defined radios, especially the external interface, is what I do for a living these days. Somehow, I suspect that the PowerSDR/DTTSP/SDR1000 world isn't quite ready for that level of rigor (and a darn good thing, too...). However, you're free to read the stuff on the Glenn Research Center website (http://www.spaceref.com/news/viewsr.html?pid=19322 has the links) asking for suggestions on how such radios should be described.
----------- Frank writes: >If you want to know what's going on, make a positive, tangible >contribution, in the form of real, testable code. If you're not interested in doing that -- your reasons for or against are your own business -- then you haven't even made a down payment on the price of admission. --------------- I think that reverse engineering Bob's and your undocumented code last February is more than the price of admission. As far as I know (from reading the mailing list) I am the first to have published documentation on the software flow and structure, as it existed, at the time: February, 2006. After an initial inspiration from the teamspeak forum talking about future development plans, I abandoned this incredibly tedious effort when I discovered that there was dead code from days gone by in the code base (why waste my time figuring out stuff you'd already given up on, or more to the point, given up on, but didn't bother to remove), and, the fact that "real soon now" everything is going to be restructured in a better way. Why toil to document something that's going to die soon? But then, perhaps to someone who eschews documentation and design documentation, only real, testable (and totally unmaintainable and modifiable by someone else) code is worthy. I am sure the authors of the texts in Linear A found in the ruins of Knossos felt the same. Frank: "Once the CVS tree is up, it will be high time to start documenting the code from the standpoint of someone approaching it fresh. A Wiki sounds like the ideal vehicle. " March 3, 2005 Bob: "I feel the cost to me (us?) for all of you putting up with our lengthy development process is that we should share as much detail as possible in some form of writing. We will soon have time to do just that." March 4, 2005 The lack of documentation is just your and the flex community's loss. Hey.. it's a great product as it is. It works reasonably well, lots of people have fun with it, it's moving forward. I'm particularly impressed by the recent EME QSO. And heck, one doesn't need source code documentation as long as you and Bob are alive and interested in it to maintain it. All Flex-er's though, should fear for the day that you get hit by a bus, or get distracted by something else, or have a final fatal disk crash without a backup, etc. And even in that horrible scenario, I suspect that someone would step in to make emergency patches as needed. And someone else will create an entirely new codebase, in the time honored software tradition of "we can just rewrite from scratch in less time than trying to figure out what this all does". The only real problem is that the code base, without documentation, is essentially a private toy for a few to play with. No biggie. I don't aspire to tinker with the Linux kernel either (although there IS some documentation for that). I don't NEED to write code for the SDR1000 to do the things I want to do, and following along with the classic F/OSS model, if it's not scratching an itch for me, I don't do it. However, I DO aspire to do more sophisticated signal processing with the SDR1000 platform. And to do that, 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. That way, I can do what *I* want to do, without having to insert it into the middle of PowerSDR, with all that entails. I'm not the only one asking for the ability to have some well defined interface for "plug-ins", so, you'll excuse my admittedly snide RSN comment (http://en.wikipedia.org/wiki/Real_soon_now) Based on past experience, all we who want such clean interfaces can hope for is that someone more enlightened with a longer term vision will create a new software base for the fine hardware. For myself at work, I have enough software to control the boxes, and for now, non-real-time processing of the data in Matlab is sufficient. Sure, someday it would be nice to use my home SDR1000 as an exciter with my phased array. But right now, my personal programming time is consumed with imbuing myself with "the way of Bill and his minions" with respect to the vagaries of WindowsXP real time programming for the phased array, rather than trying to understand the ever changing codebase of the SDR1000 (which, after all, is due for a big reorganization any time now). When the much anticipated architectural revision is done, maybe, then, it will be a suitable platform for third party development. In the mean time, prompted by curmudgeonly feelings (nay, outright crankiness) induced by Visual Studio 2005 in all it's glory, I'll comment rudely on what I think the software for the SDR1000 should be like. (Being totally selfish, it's all about me, of course.) Or, maybe, when I get done with the present project, we'll still be waiting, and then I'll get around to writing some "real, testable code" for the SDR1000, and maybe even some documentation to go with it. 73, 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 Homepage: http://www.flex-radio.com
