Re: [Flexradio] A plea to SDR software developers
Frank Well, I have been reading it all no matter what. See my response to Jose. In the middle of it all. Dale posts with the first ever Health and Welfare message carried via SDR and Phil chimed in with a summary of what he is doing. The operational world continues. I am really looking forward to the dxpedition, and we have all boffed a lot of bits in planning. Still coming together, but we will be a presense for sure. Just need a 'round tuit' and a few other things! My Grandaughter probably will come as the 'ham in training' interest (not a ham yet but. ) Would love to see the 'voice keyer' stuffed into one version or another before Halloween. Will lash it up one way or tother. Have a nice day. I'll repeat again. Thanks to you and all the other high and lower level contributors, without whom we would NOT have this radio, to do Health and Welfare, dxpeditions, or just plain having fun reporting bugs in Beta versions. So why does the console crash when you go into the memory area and click on the topmost entry in 1.4.4. (Hard crash too!, smile) In the best of spirits. I r A Use R. Eric2 -Original Message- From: Frank Brickle [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 30, 2005 10:34 PM To: ecellison Cc: 'Sami Aintila'; FlexRadio@flex-radio.biz Subject: Re: [Flexradio] A plea to SDR software developers ecellison wrote: > NAW! Don't take it private! An occasional 'flame war' sobers or makes us > drunk one way or tother. (That is almost a quote Frank) You've got my number, Eric. The old Irish question "Is this a private fight, or can anybody join?" always seemed like a good way to start a conversation. However out of deference to our host (Gerald), who is a civilized and tranquil man, we have agreed to keep the brawling out in the street. > Jim/Frank/Sami how about a CW/SSB/AM qso? Are you actually USING the radio? If the Linux guys would get off their rear ends and produce something usable, yes. Unfortunately I'm one of those types who likes best packing the radio to a hilltop and fooling around under a shady tree (see previous discussion). N4HY has been trying for years, with his own hands even, to get a decent permanent antenna at my QTH, and it's one of his few failures. The DXpedition is a worthy goal, though: SDR1K to SDR1K. One way or another. 73 Frank AB2KT
Re: [Flexradio] A plea to SDR software developers
MODULARITY FIRST. 1.5 will be modular from the outset before it sees the light of day. We are completely agreed on that. Frank and I and others who develop cannot be the only developers forever. It is not healthy for Flex or this group. The monolithic nature of the current PowerSDR and the impossibility of easily documenting what it is, what it does, is directly attributable to the nearly haphazard way it was constructed.Frank hollered at us for months while we just plodded along. We are all on the same page now. Bob Ahti Aintila wrote: Very well said, Bob! The full modularity is also my main interest. That is worth waiting, but may I suggest that after implementing and debugging the all promised goodies in version 1.5 FlexRadio would freeze it for a while and concentrate in rewriting everything in fully modular way. Many thanks and 73, Ahti OH2RZ
Re: [Flexradio] A plea to SDR software developers
Very well said, Bob! The full modularity is also my main interest. That is worth waiting, but may I suggest that after implementing and debugging the all promised goodies in version 1.5 FlexRadio would freeze it for a while and concentrate in rewriting everything in fully modular way. Many thanks and 73, Ahti OH2RZ - Original Message - From: "Robert McGwier" <[EMAIL PROTECTED]> To: "Sami Aintila" <[EMAIL PROTECTED]> Cc: <> Sent: Wednesday, August 31, 2005 3:56 PM Subject: Re: [Flexradio] A plea to SDR software developers This is like a page out of choir book. This is exactly what we have proposed and while we have paused to catch our breath, it is what we all want (people who have been developers). No one likes the monolithic approach. It is completely ill-suited to this type of distributed development. It has completely prevented many others from participating. If the only way to get your piece in is to get it past Bob, Frank, or Eric, that is a bad thing. No one agrees more than we do. A modular, layered approach, with well specified API's. In the small architectural email interchanges we have made with those who have contributed to the existing code, this is a universally held opinion. Brickle has been insisting on this for months and that is how the new architecture will look. This is simply required for the model we want to build to, which is driven by the desire to allow distributed computing. Nothing else will do for this. But of course, your earlier statement chimed in with support for the Lux's bemoaning the GPL approach. My apologies for the misinterpretation. Bob
Re: [Flexradio] A plea to SDR software developers
At 10:16 PM 8/30/2005, Frank Brickle wrote: Jim Lux wrote: > However, my comment was more addressed to developers of the > software. Basic documentation will make it a realistic goal to get > multiple contributions to the free codebase. Otherwise it will remain an > interesting toy for the technically persistent and skilled software artists > with plenty of paid or unpaid time to spend on it. Well, there is a definite philosophical difference here. I should point out that, FWIW, my view is based on -- well, I was going to say almost forty, but, eep, it *is* forty -- years of working with these idiotic machines, and countless thousands of lines written fast, slow, and anywhere in between. Documentation ain't worth the paper it's writ on. I would say that is is situationally dependent. I'd hate to have to try and write software (of any kind) without some reference that defines the language syntax and semantics, at least at the start. Documentation also becomes more valuable when multiple people are involved, particularly over large spans of time or space. At the same time, I happen to be a convinced exponent of bottom-up programming style. What that means is, in short, building up a small vocabulary of low-level application-specific operations, composing them then into a larger vocabulary of utterances, and then telling the final story in the language that's grown up with the application. Sure.. and one can tell a moving and elegant story with your own private language, and it may sound just fine. However, if you want a dozen people to work on that software, and they aren't all there at the start, the problem is one that the "first step" in working on the program is that you have to "learn the language", unfortunately without the help of a dictionary or any other thing. Immersion may work, but it's painful, and requires a big commitment. It also only works if there's a body of speech to be immersed in. If all the speakers have died, and all that remains is their writings, translating might be a bit tricky. The Rosetta Stone is prized for a good reason. "Bottom up" is a fine programming style, but it's not a particularly effective architectural approach for large systems (where large is defined more in terms of the number of contributors than the number of lines of code). This is a hard problem, which is why software development methodologies have evolved a lot from the "modular programming" of my youth. Creating architectures that can support concurrency is only one challenge. Another is creating software that can be maintained and modified into the future, generally by people not the original creator. To use the construction metaphor: the outside may be stunning and elegant and one of a kind, but making it took a lot of unexciting hammering standard sized nails into standard sized pieces of wood. At some point Frank Gehry has to do drawings, because he can't single handedly build the building. James Lux, P.E. Spacecraft Radio Frequency Subsystems Group Flight Communications Systems Section Jet Propulsion Laboratory, Mail Stop 161-213 4800 Oak Grove Drive Pasadena CA 91109 tel: (818)354-2075 fax: (818)393-6875
Re: [Flexradio] A plea to SDR software developers
This is like a page out of choir book. This is exactly what we have proposed and while we have paused to catch our breath, it is what we all want (people who have been developers). No one likes the monolithic approach. It is completely ill-suited to this type of distributed development. It has completely prevented many others from participating. If the only way to get your piece in is to get it past Bob, Frank, or Eric, that is a bad thing. No one agrees more than we do. A modular, layered approach, with well specified API's. In the small architectural email interchanges we have made with those who have contributed to the existing code, this is a universally held opinion. Brickle has been insisting on this for months and that is how the new architecture will look. This is simply required for the model we want to build to, which is driven by the desire to allow distributed computing. Nothing else will do for this. But of course, your earlier statement chimed in with support for the Lux's bemoaning the GPL approach. My apologies for the misinterpretation. Bob Sami Aintila wrote: There has been a lot of typing going on while I was asleep. Of course, I should have known better, but it wasn't my intention to start (or incite) this GPL discussion. Please let me repeat myself: OK, I'm not a big fan of GPL, but that's not the point. It really isn't. The "GPL problem" doesn't have to be a problem at all. We just need a truly open, modular design instead of the monolithic PowerSDR that we're now using: SDR hardware control, audio I/O, DSP core, a wide selection of GUI modules, advanced DSP functions, support for various digital modes, remote operation, etc. All of these as separate, interchangeable modules with well-documented software interfaces to make sure it all works together. Some of those modules will indeed be open source, GPL, BSD, whatever. But the "old-fashioned", closed, commercial software kind of modules would also be allowed. And everything in between. Again, I know something like this has been proposed before. While it's easy to come up with this great concept, defining the modules and interfaces between them is going to be a lot of work. This is a big challenge. Any takers? 73, Sami OH2BFO ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Re: [Flexradio] A plea to SDR software developers - GPL tangent
Bil and others: This is well tested ground. It has been repeatedly to ad nauseum dealt with all over the place. YOU CAN distribute non gpl modules solely for the purpose of enhancing gpl based code SO LONG AS the distribution is not on "the same hypertext link". I do not know that this has occured, but it would be a problem if Flex distributed the USB widget dll on the same disk the PowerSDR as a hand out at (say) Dayton. When I do a SUSE Linux upgrade using YAST,I have check the link that says "upgrade the non-GPL modules". You can bet with all of the SCO lawsuits, copyright, copyleft, patent, etc. stuff floating around, Novell lawyers know what is legal. It is legal to distribute non-GPL modules for the enhancement of a GPL thing. Do not distribute them together. I know this is what you said, I just want to make absolutely certain that everyone understands that we agree. THERE WILL NOT BE A CHANGE TO THE GPL LICENSING OF THE DTTSP CODE. It is now, and will be, GPL. This is an end to this discussion. There is nothing left to discuss. It will no longer be discussed by me since there is not a single sliver of chance for that snow ball to last in hell. If anyone does not like it, write your own code. Bob Bill Tracey wrote: At 09:27 PM 8/30/2005, Robert McGwier wrote: The GPL does not prevent you from making a non-GPL contribution. It prevents you from using GPL code in your contribution and distributing with out your code being GPL OR without a separate license with the copyright holders. So long as your code does not copy GPL code in to it, you are free to do what you want. I am absolutely certain that after the "I/Q taps" and "audio taps" come out that lots of plugins will be made available from all over the place. I encourage it. Again, if the DLL plugin is distributed by someone with PowerSDR then I'd say the GPL applies to the DLL plugin. This is clearly an area reasonable people can disagree on - they wording of the GPL is ambiguous in that it does not define what a program is in any meaningful technical way. I will admit my interpretation of it is somewhat conservative. Regards, Bill (kd5tfd)
Re: [Flexradio] A plea to SDR software developers
There has been a lot of typing going on while I was asleep. Of course, I should have known better, but it wasn't my intention to start (or incite) this GPL discussion. Please let me repeat myself: > OK, I'm not a big fan of GPL, but that's not the point. It really isn't. The "GPL problem" doesn't have to be a problem at all. We just need a truly open, modular design instead of the monolithic PowerSDR that we're now using: SDR hardware control, audio I/O, DSP core, a wide selection of GUI modules, advanced DSP functions, support for various digital modes, remote operation, etc. All of these as separate, interchangeable modules with well-documented software interfaces to make sure it all works together. Some of those modules will indeed be open source, GPL, BSD, whatever. But the "old-fashioned", closed, commercial software kind of modules would also be allowed. And everything in between. Again, I know something like this has been proposed before. While it's easy to come up with this great concept, defining the modules and interfaces between them is going to be a lot of work. This is a big challenge. Any takers? 73, Sami OH2BFO
Re: [Flexradio] A plea to SDR software developers
Jim Lux wrote: However, my comment was more addressed to developers of the software. Basic documentation will make it a realistic goal to get multiple contributions to the free codebase. Otherwise it will remain an interesting toy for the technically persistent and skilled software artists with plenty of paid or unpaid time to spend on it. Well, there is a definite philosophical difference here. I should point out that, FWIW, my view is based on -- well, I was going to say almost forty, but, eep, it *is* forty -- years of working with these idiotic machines, and countless thousands of lines written fast, slow, and anywhere in between. Documentation ain't worth the paper it's writ on. You must surely know the famous line, attributed variously to Frank Zappa, Elvis Costello, and others: Writing about music is like dancing about architecture. Goes for program documentation as well. I take very seriously the idea that a program isn't a series of instructions, it's an expressive description of a process. The job of the hardware is to carry out the process. (I think it's in the foreword to their introductory programming book that Abelson and Sussman make this point far more eloquently than I ever could.) To invoke Don Knuth again, programming is both a branch of literature and a branch of mathematics. You have to read a program wearing both hats. At the same time, I happen to be a convinced exponent of bottom-up programming style. What that means is, in short, building up a small vocabulary of low-level application-specific operations, composing them then into a larger vocabulary of utterances, and then telling the final story in the language that's grown up with the application. Put those two things together and you have a result that doesn't lend itself easily to any commentary other than, perhaps, marginalia and footnotes. It's like trying to *prove* that two lines of a limerick rhyme. You can't do it. Either you get the rhyme or you don't. There's no substitute for reading the code, because the code isn't a paraphrase of the process; it is the process. Along the same lines, no amount of documentation is as valuable as two or three choice examples. At some point, not too far away, there will be documentation. But it won't serve any purpose other than helping people feel less lonely and confused while they're trying to get oriented. A friendly gesture, nothing more. 73 Frank AB2KT
Re: [Flexradio] A plea to SDR software developers
At 06:16 PM 8/30/2005, Gerald Youngblood wrote: To my knowledge we have NEVER promised source code documentation. We might do it some day but no promises. By the way we sincerely appreciate ALL of you who have in the past contributed and will in the future contribute to the open source development. 73, Gerald K5SDR I'd like to make it clear that I don't and didn't expect software documentation from Flex-Radio. I bought the radios for the hardware. I used the software mostly to make sure the radios weren't broken. If I could have used the software beyond that (which would have depended on documentation) it would have been a bonus. I think the general ham community would have a somewhat different take on it, based on a history of relatively well documented hardware, in the form of readily available service manuals and the like. However, my comment was more addressed to developers of the software. Basic documentation will make it a realistic goal to get multiple contributions to the free codebase. Otherwise it will remain an interesting toy for the technically persistent and skilled software artists with plenty of paid or unpaid time to spend on it. Open software development is just that: OPEN. Put your stuff out there and people get to shoot at it, and from the shooting (and the response thereto) comes better products. If the complaint is that modifications are difficult because there's no documentation, that's a valid complaint. As a developer, you get to decide whether you agree. You can say, nope, it's good enough for me, and I'd rather spend my time on a new feature, or, equally valid, you can say, you're right, it should be better, because my goal is providing a platform for development for others to build on. De gustibus non disputandum. (or, as RMS puts it, free as in speech, not as in beer.) My plea was not intended to convince Flex-Radio to change their ways, but more to the software development community that has sprung up around the hardware platform. I didn't think that what I asked for was particularly expensive or tedious (normal software development processes produce this sort of documentation in the process of doing the job anyway), and the whole GPL thing is more of a cautionary comment for the future direction, and a desire to avoid locking yourself into a path that might have an undesirable endpoint. As far as I know, nobody is advocating trying to privatize GPLed code. On the other hand, you shouldn't be excluding non-GPL participants from the party. While I think that open rants on open software are fair game, I reserve the right to rant privately to Flex-Radio about how they should run their company . Clearly, they should build radios that suit me, particularly, with the interfaces that I want, and bollocks to the rest of you lot. Jim, W6RMK
Re: [Flexradio] A plea to SDR software developers - GPL tangent
At 09:27 PM 8/30/2005, Robert McGwier wrote: <... deleted ...> In fact we use several proprietary plugins. We use a "dll plugin" for the USB widget (remember that one?) and we all use "sound card device driver" plugins every time we power the radio up. So I am unfamiliar with this decision. I do not think the GPL applies to the sound card device driver, as the device driver is not a part of the program - it runs in a different process and address space, and the GPL only applies to a program, which most would define as that entity that sits within a single processes address space. The dll plugin for the USB widget is a different matter. If the author of the USB widget DLL were to distribute the plugin and the PowerSDR code I believe one who received such code would have rights under the GPL to ask for the source for all of it, including the USB plugin. The GPL does not prevent you from making a non-GPL contribution. It prevents you from using GPL code in your contribution and distributing with out your code being GPL OR without a separate license with the copyright holders. So long as your code does not copy GPL code in to it, you are free to do what you want. I am absolutely certain that after the "I/Q taps" and "audio taps" come out that lots of plugins will be made available from all over the place. I encourage it. Again, if the DLL plugin is distributed by someone with PowerSDR then I'd say the GPL applies to the DLL plugin. This is clearly an area reasonable people can disagree on - they wording of the GPL is ambiguous in that it does not define what a program is in any meaningful technical way. I will admit my interpretation of it is somewhat conservative. Regards, Bill (kd5tfd)
Re: [Flexradio] A plea to SDR software developers
>>> "Gerald Youngblood" <[EMAIL PROTECTED]> 08/30/05 08:13PM >>> Yep, the SDR-1000 is not a backpacking rig. Nor is a backpacking rig a SDR-1000. A fork will never be a knife but you can cut some with a fork if you push hard enough. Everything has its place. My point exactly. The SDR is a great rig and I'm proud to have it, and proud to be associated (even remotely) with you and your team who creating it. But as you say "a time to every purpose under heaven". Bill AD5OL
Re: [Flexradio] A plea to SDR software developers
ecellison wrote: NAW! Don't take it private! An occasional 'flame war' sobers or makes us drunk one way or tother. (That is almost a quote Frank) You've got my number, Eric. The old Irish question "Is this a private fight, or can anybody join?" always seemed like a good way to start a conversation. However out of deference to our host (Gerald), who is a civilized and tranquil man, we have agreed to keep the brawling out in the street. Jim/Frank/Sami how about a CW/SSB/AM qso? Are you actually USING the radio? If the Linux guys would get off their rear ends and produce something usable, yes. Unfortunately I'm one of those types who likes best packing the radio to a hilltop and fooling around under a shady tree (see previous discussion). N4HY has been trying for years, with his own hands even, to get a decent permanent antenna at my QTH, and it's one of his few failures. The DXpedition is a worthy goal, though: SDR1K to SDR1K. One way or another. 73 Frank AB2KT
Re: [Flexradio] A plea to SDR software developers
Sami: Who rejected it? I am unaware of this decision. In fact we use several proprietary plugins. We use a "dll plugin" for the USB widget (remember that one?) and we all use "sound card device driver" plugins every time we power the radio up. So I am unfamiliar with this decision. The GPL does not prevent you from making a non-GPL contribution. It prevents you from using GPL code in your contribution and distributing with out your code being GPL OR without a separate license with the copyright holders. So long as your code does not copy GPL code in to it, you are free to do what you want. I am absolutely certain that after the "I/Q taps" and "audio taps" come out that lots of plugins will be made available from all over the place. I encourage it. Using the GPL is a completely practical thing. Let's just concentrate on the code that Frank and I have done. If John Q. Honest Engineering, Inc. wanted to take that code and evaluate it for use in their products, they are free to do so until such time as they wish to distribute the code. Mr. Honest has a choice at the time. Seek a separate license with the copyright holder which is likely to involve the exchange of pieces of paper, white with typing and green with ink, or release their own code GPL. This allows everyone to see the good and the bad of what we have done and protects our interests in that it allows the honest individuals and companies that you would like to do business with a way to do so. If dishonest types take the code and steal it, what have we lost? They weren't going to be honest to begin with and it is better not to have an association. You are free to take our code, study it, learn from it in any way you want and the lock it up and seal it off and do a version of it in a clean room for your own purposes, including distributing your own copyrighted code without source. If you continue to go back and refer to the code, this violates the spirit and letter of clean room. It really is about doing business with honest people and allowing others to benefit from our act of creation. 73's Bob Sami Aintila wrote: Some comments: [Jim Lux] Warning... strong off-the-cuff opinions follow that I'll probably regret. Nothing to regret, Jim. These things needed to be said. [Frank Brickle] Further discussion >/dev/null. Well, this is certainly a helpful attitude. [Eric] We are committed to using the GPL as it gives us protection while at the same time offering an extreme amount of freedom in terms of modification and redistribution. Using GPL is an ideological choice. Nothing wrong with that. But there are lots of people who really don't understand the ideology they are subscribing to. Until it's too late. It's like a cult: once you're in, you can never get out. OK, I'm not a big fan of GPL, but that's not the point. The point is (as Jim was trying to explain in his first post) that GPL may be the single most important reason why some people cannot contribute to this project. I think this is a serious problem. But this problem could be circumvented by following the guidelines Jim suggested. But I know this is not the first time we're having this discussion. The concept of "plugins" has been mentioned (and rejected) many times before. But the concept seems to work just fine in many other applications. Why not here? 73, Sami OH2BFO ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Re: [Flexradio] A plea to SDR software developers
Gerald Youngblood wrote: Yep, the SDR-1000 is not a backpacking rig. Nor is a backpacking rig a SDR-1000. A fork will never be a knife but you can cut some with a fork if you push hard enough. Everything has its place. However, I had fun going mobile with the SDR-1000 on the way to Dayton until my antenna blew off the car and broke the coax. :>( It worked great with the laptop on guess what, my lap. Oh, Eric was driving, not me. Have you *seen* the Rockwell-Collins SDR manpack? Proof that the concept has a long way to go yet. 73 Frank AB2KT PS I love green radios, but whoever thought this one up should be the one carrying it into the field...
Re: [Flexradio] A plea to SDR software developers
Bill (smile) yup, probably not easy, but what ever was? Gerald did give an award to ALAN - K2WS for first base to mobile SDR-SDR contact, so it is do-able with the SDR. You are right, good comparison, ignoring the discussion. Next? Eric -Original Message- From: Bill Guyger [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 30, 2005 8:44 PM To: [EMAIL PROTECTED]; FlexRadio@flex-radio.biz; [EMAIL PROTECTED] Subject: Re: [Flexradio] A plea to SDR software developers Having purchased a 857D myself, disreguarding the open ended - closed ended software discussion, the Yaesu IS a lot more portable. I love you guys (in a brotherly way), but putting a SDR-1000 in a car and operating it might be a bit of a challenge, even with a laptop :-). Same for backpacking it up the side of a mountain. Bill AD5OL >>> "ecellison" <[EMAIL PROTECTED]> 08/30/05 07:12PM >>> Sami I am still reading. However, now I would like for you to comment on my purchase of the Yeasu 857 and compare what I bought from Yeasu with what I bought from FlexRadio Systems, years ago. Which was the better buy for the future, no matter what I want to do in ham radio? Juxtaposition. Eric - AA4SW -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sami Aintila Sent: Tuesday, August 30, 2005 5:27 PM To: FlexRadio@flex-radio.biz Subject: Re: [Flexradio] A plea to SDR software developers Some comments: [Jim Lux] > Warning... strong off-the-cuff opinions follow that I'll probably regret. Nothing to regret, Jim. These things needed to be said. [Frank Brickle] > Further discussion >/dev/null. Well, this is certainly a helpful attitude. [Eric] > We are committed to using the GPL as it gives us protection while at the same time offering an extreme amount of freedom in terms of modification and redistribution. Using GPL is an ideological choice. Nothing wrong with that. But there are lots of people who really don't understand the ideology they are subscribing to. Until it's too late. It's like a cult: once you're in, you can never get out. OK, I'm not a big fan of GPL, but that's not the point. The point is (as Jim was trying to explain in his first post) that GPL may be the single most important reason why some people cannot contribute to this project. I think this is a serious problem. But this problem could be circumvented by following the guidelines Jim suggested. But I know this is not the first time we're having this discussion. The concept of "plugins" has been mentioned (and rejected) many times before. But the concept seems to work just fine in many other applications. Why not here? 73, Sami OH2BFO ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Re: [Flexradio] A plea to SDR software developers
To my knowledge we have NEVER promised source code documentation. We might do it some day but no promises. By the way we sincerely appreciate ALL of you who have in the past contributed and will in the future contribute to the open source development. 73, Gerald K5SDR > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of ecellison > Sent: Tuesday, August 30, 2005 6:59 PM > To: 'Eric'; 'Jim Lux'; 'FlexRadioMail' > Subject: Re: [Flexradio] A plea to SDR software developers > > > Eric > > Good! Not necessarily because Jim has mentioned it, however, it > was a major > topic and lament on Teamspeak last Friday night (Saturday UTC). > Documentation of the code is NOT something that FlexRadio Systems promised > to it's purchasers. From a marketing standpoint, balance the time to > document the code with profit. Documentation will probably help YOU, as it > becomes more involved and complex. Documentation will also help MANY > beginners and wanna be programmers, who MAY at some point come up with a > FANTASTIC new, and FREE, concept and idea. > > You (FlexRadio Systems) promised a stable version of the code at all times > for the operators of the radio, which I think the company has > fulfilled, and > open source, which with a couple of purist exceptions you have also done. > You never promised documentation of the code (that I can find). > > Just keep going. I'll have a little more to say. > > > Eric > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Eric > Sent: Tuesday, August 30, 2005 4:35 PM > To: 'Jim Lux'; 'FlexRadioMail' > Subject: Re: [Flexradio] A plea to SDR software developers > > Source code documentation is coming. We plan to implement some > auto-documentation coding standards in order to take advantage of some > really nice XML based engines that will turn comments into html > documentation. This will come with the new architecture that is > currently being revised for the 1.5 Beta branch of the source. > > We are committed to using the GPL as it gives us protection while at the > same time offering an extreme amount of freedom in terms of modification > and redistribution. > > > Eric Wachsmann > FlexRadio Systems > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jim Lux > Sent: Tuesday, August 30, 2005 1:16 PM > To: FlexRadioMail > Subject: [Flexradio] A plea to SDR software developers > > A couple pleas to those of you ambitously cranking out great stuff for > the > SDR, particularly in the Linux world > > 1) Gosh.. there needs to be SOME documentation of the structure of the > software. Even a readme listing that says what each module does and who > > calls what. Sure.. am_demod.c probably does something with demodulating > > AM, but you'd never know it from reading the comments. > > Same applies to the PowerSDR sources... I hunted through the zip file a > while, but never found any sort of documentation. > > Surely you guys have some sketchy document around that has the overall > architecture? Maybe it exists, but it would be nice to have a link to > where it is. Don't make it too challenging or nobody will get > interested. > > 2) Structure the software so that you can make mods without getting > wrapped > around the GPL axle. There are people out there who would like to make > > contributions, and are actually paid to do software development, but for > a > variety of reasons, can't modify GPL stuff. > > For example, at Jet Propulsion Lab, most all of our work is funded by > NASA, > and software that is developed with that funding is notionally available > to > all, for free (well, the U.S. taxpayers have already paid for it). > There's > a whole raft of contractual details between CalTech (who runs JPL) and > NASA > about how that software is to be released, the (not entirely accurate) > summary of which is that it has to be released in a different way, and > with > a different rights statement, that are incompatible with the usual GPL > way > of doing things. > > This came up when I wanted to use a modified version of hamlib and > rigctl > to control the SDR1000. The real problem came up when we wanted to > release > the modified versions. The GPL requires that modified versions also be > GPLd, etc, be distributed in a certain way, etc. We wound up rewriting > the > needed functions from scratch (which was no big deal, but had I known > from > the start, I would have done things differently). > > So, if I want to insert som
Re: [Flexradio] A plea to SDR software developers
Yep, the SDR-1000 is not a backpacking rig. Nor is a backpacking rig a SDR-1000. A fork will never be a knife but you can cut some with a fork if you push hard enough. Everything has its place. However, I had fun going mobile with the SDR-1000 on the way to Dayton until my antenna blew off the car and broke the coax. :>( It worked great with the laptop on guess what, my lap. Oh, Eric was driving, not me. 73, Gerald > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Bill Guyger > Sent: Tuesday, August 30, 2005 7:44 PM > To: [EMAIL PROTECTED]; FlexRadio@flex-radio.biz; [EMAIL PROTECTED] > Subject: Re: [Flexradio] A plea to SDR software developers > > > Having purchased a 857D myself, disreguarding the open ended - > closed ended software discussion, the Yaesu IS a lot more > portable. I love you guys (in a brotherly way), but putting a > SDR-1000 in a car and operating it might be a bit of a challenge, > even with a laptop :-). Same for backpacking it up the side of a mountain. > > Bill AD5OL > > >>> "ecellison" <[EMAIL PROTECTED]> 08/30/05 07:12PM >>> > Sami > > I am still reading. However, now I would like for you to comment on my > purchase of the Yeasu 857 and compare what I bought from Yeasu with what I > bought from FlexRadio Systems, years ago. Which was the better buy for the > future, no matter what I want to do in ham radio? > > Juxtaposition. > > Eric - AA4SW > > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sami Aintila > Sent: Tuesday, August 30, 2005 5:27 PM > To: FlexRadio@flex-radio.biz > Subject: Re: [Flexradio] A plea to SDR software developers > > Some comments: > > [Jim Lux] > > Warning... strong off-the-cuff opinions follow that I'll > probably regret. > > Nothing to regret, Jim. These things needed to be said. > > > [Frank Brickle] > > Further discussion >/dev/null. > > Well, this is certainly a helpful attitude. > > > [Eric] > > We are committed to using the GPL as it gives us protection while at the > same time offering an extreme amount of freedom in terms of > modification and > redistribution. > > Using GPL is an ideological choice. Nothing wrong with that. But there > are lots of people who really don't understand the ideology they are > subscribing to. Until it's too late. It's like a cult: once you're in, > you can never get out. > > OK, I'm not a big fan of GPL, but that's not the point. The point is > (as Jim was trying to explain in his first post) that GPL may be the > single most important reason why some people cannot contribute to this > project. I think this is a serious problem. But this problem could be > circumvented by following the guidelines Jim suggested. > > But I know this is not the first time we're having this discussion. > The concept of "plugins" has been mentioned (and rejected) many times > before. But the concept seems to work just fine in many other > applications. Why not here? > > 73, Sami OH2BFO > > ___ > FlexRadio mailing list > FlexRadio@flex-radio.biz > http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz > > > ___ > FlexRadio mailing list > FlexRadio@flex-radio.biz > http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz > > > ___ > FlexRadio mailing list > FlexRadio@flex-radio.biz > http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz > >
Re: [Flexradio] A plea to SDR software developers
Frank/Sami NAW! Don't take it private! An occasional 'flame war' sobers or makes us drunk one way or tother. (That is almost a quote Frank) I guess youse guys can probably retire on the hundred million $ or so that you have obtained in royalties from FlexRadio systems, on a volume of 700 units or so (smile).'' Jim ALWAYS has played the devil or devil's advocate on every suggestion ever made to the reflector, and threw the bone "in" hoping someone would end up faced off in the pit. He Gotcha! He keeps us honest. We think about what he says, and then we go ahead and produce the Delta 44 interface card for the fun of it (for instance). Without balanced inputs at that! It also has 1/8 inch mini jacks which will assuredly make it fail! May be a boom or a bust but it is fun! I need a bigger truck, at -$1.00 or so a board (per Jim)! There are lots of examples of the synergy this radio has evoked, from so many creative sources that it is almost not imaginable from just a user standpoint: Ken - N9VV, Beppe - IK3VIG, Phil - N8VB, Dale - WA8SRA, Tony - KB9YIG, and we could go on for a long time with this list! They ALL have different areas to contribute. Even the users I met on 14,313 SSB this weekend! They ARE USING THIS paradigm shift of a radio! And it WORKS! I think bottom line from (my) standpoint as a user, is that I am thrilled with the radio, and what you genius folk have done for it in a totally different paradigm - "User Defined Radio". Fairly recently I am an ACTIVE operator running both SSB, AM, and CW with 1.4.4. Took a while but that was the bottom line be a HAM! as AA4SW, V31SR. Jim/Frank/Sami how about a CW/SSB/AM qso? Are you actually USING the radio? Gerald sic. - Flex Radio Systems - has fulfilled on EVERY promise he ever made, except the pending hardware upgrades - (news at 11). 1. A stable release of the software to run the radio ALWAYS! 2. The articles in QEX have inspired. 3. Free release of almost all of the source code to run the radio, with the exception of several dll's. Users please comment! I am a Proud SDR-1000 owner! Eric - AA4SW -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Brickle Sent: Tuesday, August 30, 2005 6:01 PM To: Sami Aintila Cc: FlexRadio@flex-radio.biz Subject: Re: [Flexradio] A plea to SDR software developers Sami Aintila wrote: > Nothing to regret, Jim. These things needed to be said. > [Frank Brickle] > >>Further discussion >/dev/null. > > Well, this is certainly a helpful attitude. When these things are brought up in a public fashion, prior to any private communication or discussion on the subject, yes. It's helpful to take it out of public view until it can be determined what's actually being said on each side. We were not afforded that opportunity, but I will assert the right to take the discussion private until it is clear what the dispute really is. At present it seems to be a covert lament that the "free" in free software is as in speech, not beer. > The point is > (as Jim was trying to explain in his first post) that GPL may be the > single most important reason why some people cannot contribute to this > project. I think this is a serious problem. But this problem could be > circumvented by following the guidelines Jim suggested. One important point is concealed by the discussion so far. Jim's complaint primarily involved an activity which, if I understand properly, is part of his employment. He's asking for changes to the licensing to make his job easier. I believe that you also have done at least some part of the development work under subsidy, if not salary. If not, I stand corrected. My contributions to the code have been completely uncompensated. Therefore, as stated previously, I (and presumably other contributors) would be more than willing to discuss alternate licensing terms, which under the GPL we are entitled to do. But it seems mildly unreasonable to expect that we, as copyright holders, should essentially give up our copyrights for nothing, for the benefit of somebody else's paid employment. It's simple equity. And now, really, no more public discussion. 73 Frank AB2KT ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Re: [Flexradio] A plea to SDR software developers
Having purchased a 857D myself, disreguarding the open ended - closed ended software discussion, the Yaesu IS a lot more portable. I love you guys (in a brotherly way), but putting a SDR-1000 in a car and operating it might be a bit of a challenge, even with a laptop :-). Same for backpacking it up the side of a mountain. Bill AD5OL >>> "ecellison" <[EMAIL PROTECTED]> 08/30/05 07:12PM >>> Sami I am still reading. However, now I would like for you to comment on my purchase of the Yeasu 857 and compare what I bought from Yeasu with what I bought from FlexRadio Systems, years ago. Which was the better buy for the future, no matter what I want to do in ham radio? Juxtaposition. Eric - AA4SW -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sami Aintila Sent: Tuesday, August 30, 2005 5:27 PM To: FlexRadio@flex-radio.biz Subject: Re: [Flexradio] A plea to SDR software developers Some comments: [Jim Lux] > Warning... strong off-the-cuff opinions follow that I'll probably regret. Nothing to regret, Jim. These things needed to be said. [Frank Brickle] > Further discussion >/dev/null. Well, this is certainly a helpful attitude. [Eric] > We are committed to using the GPL as it gives us protection while at the same time offering an extreme amount of freedom in terms of modification and redistribution. Using GPL is an ideological choice. Nothing wrong with that. But there are lots of people who really don't understand the ideology they are subscribing to. Until it's too late. It's like a cult: once you're in, you can never get out. OK, I'm not a big fan of GPL, but that's not the point. The point is (as Jim was trying to explain in his first post) that GPL may be the single most important reason why some people cannot contribute to this project. I think this is a serious problem. But this problem could be circumvented by following the guidelines Jim suggested. But I know this is not the first time we're having this discussion. The concept of "plugins" has been mentioned (and rejected) many times before. But the concept seems to work just fine in many other applications. Why not here? 73, Sami OH2BFO ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Re: [Flexradio] A plea to SDR software developers
Sami I am still reading. However, now I would like for you to comment on my purchase of the Yeasu 857 and compare what I bought from Yeasu with what I bought from FlexRadio Systems, years ago. Which was the better buy for the future, no matter what I want to do in ham radio? Juxtaposition. Eric - AA4SW -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sami Aintila Sent: Tuesday, August 30, 2005 5:27 PM To: FlexRadio@flex-radio.biz Subject: Re: [Flexradio] A plea to SDR software developers Some comments: [Jim Lux] > Warning... strong off-the-cuff opinions follow that I'll probably regret. Nothing to regret, Jim. These things needed to be said. [Frank Brickle] > Further discussion >/dev/null. Well, this is certainly a helpful attitude. [Eric] > We are committed to using the GPL as it gives us protection while at the same time offering an extreme amount of freedom in terms of modification and redistribution. Using GPL is an ideological choice. Nothing wrong with that. But there are lots of people who really don't understand the ideology they are subscribing to. Until it's too late. It's like a cult: once you're in, you can never get out. OK, I'm not a big fan of GPL, but that's not the point. The point is (as Jim was trying to explain in his first post) that GPL may be the single most important reason why some people cannot contribute to this project. I think this is a serious problem. But this problem could be circumvented by following the guidelines Jim suggested. But I know this is not the first time we're having this discussion. The concept of "plugins" has been mentioned (and rejected) many times before. But the concept seems to work just fine in many other applications. Why not here? 73, Sami OH2BFO ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Re: [Flexradio] A plea to SDR software developers
Eric Good! Not necessarily because Jim has mentioned it, however, it was a major topic and lament on Teamspeak last Friday night (Saturday UTC). Documentation of the code is NOT something that FlexRadio Systems promised to it's purchasers. From a marketing standpoint, balance the time to document the code with profit. Documentation will probably help YOU, as it becomes more involved and complex. Documentation will also help MANY beginners and wanna be programmers, who MAY at some point come up with a FANTASTIC new, and FREE, concept and idea. You (FlexRadio Systems) promised a stable version of the code at all times for the operators of the radio, which I think the company has fulfilled, and open source, which with a couple of purist exceptions you have also done. You never promised documentation of the code (that I can find). Just keep going. I'll have a little more to say. Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Sent: Tuesday, August 30, 2005 4:35 PM To: 'Jim Lux'; 'FlexRadioMail' Subject: Re: [Flexradio] A plea to SDR software developers Source code documentation is coming. We plan to implement some auto-documentation coding standards in order to take advantage of some really nice XML based engines that will turn comments into html documentation. This will come with the new architecture that is currently being revised for the 1.5 Beta branch of the source. We are committed to using the GPL as it gives us protection while at the same time offering an extreme amount of freedom in terms of modification and redistribution. Eric Wachsmann FlexRadio Systems -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Lux Sent: Tuesday, August 30, 2005 1:16 PM To: FlexRadioMail Subject: [Flexradio] A plea to SDR software developers A couple pleas to those of you ambitously cranking out great stuff for the SDR, particularly in the Linux world 1) Gosh.. there needs to be SOME documentation of the structure of the software. Even a readme listing that says what each module does and who calls what. Sure.. am_demod.c probably does something with demodulating AM, but you'd never know it from reading the comments. Same applies to the PowerSDR sources... I hunted through the zip file a while, but never found any sort of documentation. Surely you guys have some sketchy document around that has the overall architecture? Maybe it exists, but it would be nice to have a link to where it is. Don't make it too challenging or nobody will get interested. 2) Structure the software so that you can make mods without getting wrapped around the GPL axle. There are people out there who would like to make contributions, and are actually paid to do software development, but for a variety of reasons, can't modify GPL stuff. For example, at Jet Propulsion Lab, most all of our work is funded by NASA, and software that is developed with that funding is notionally available to all, for free (well, the U.S. taxpayers have already paid for it). There's a whole raft of contractual details between CalTech (who runs JPL) and NASA about how that software is to be released, the (not entirely accurate) summary of which is that it has to be released in a different way, and with a different rights statement, that are incompatible with the usual GPL way of doing things. This came up when I wanted to use a modified version of hamlib and rigctl to control the SDR1000. The real problem came up when we wanted to release the modified versions. The GPL requires that modified versions also be GPLd, etc, be distributed in a certain way, etc. We wound up rewriting the needed functions from scratch (which was no big deal, but had I known from the start, I would have done things differently). So, if I want to insert something useful into a body of software that is GPLed, I have to make sure that my little piece is sufficiently standalone and doesn't include any GPL code in it. I can call modules in some library that's GPLd, and I can be called by GPL'd software, but I have to be self contained. This meets the GPL requirement: " If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. " Once it's been released (with the NASA process), you'd be free to include that with the rest of the system. And, in fact, you could freely modify what we developed and released. (you might even be able to GPL the copied/modified version, for all I know) There is also a review process that we have to go through to make sure that we haven't inadvertently trampled on someone else's proprietary rights, and that we aren't
Re: [Flexradio] A plea to SDR software developers >/dev/null
Frank (smile) Wonderfull! Jim does tend to try to keep us honest. He must have some time on his hands. Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Brickle Sent: Tuesday, August 30, 2005 4:16 PM To: Jim Lux Cc: FlexRadioMail Subject: Re: [Flexradio] A plea to SDR software developers >/dev/null Jim Lux wrote: > Nonsense... it's never premature to at least describe the intended > structure as you build it. I'm inclined to believe you haven't actually made any serious attempt to look at the code. Don Knuth often has made the point that the chief deficiency in most programmers' skillsets is the art of reading other people's programs. Everything you're talking about strikes me as learning curve issues. One thing at a time. What exactly has you all riled up, anyway? > Not to too vigorously cast aspersions here, but the SDR1000 is more than > a year old, and there's never been any sort of architectural > description, except perhaps in Gerald's articles, and those were of a > more generic nature. If you'd like to find somebody to underwrite it, great. I'm ready. > There is no comparable thing for the SDR1000's software component. Have you looked at gnuradio? > Which is not documented anywhere? At least not in any sort of file with > an obvious name. Did you notice the file called "command-vocabulary?" main.c? sdr.c? update.c? Horse, water, drink. > This would be something other than is currently on the CVS repository? No. It's currently under development by the excellent Bob Cowdery, and it's been discreetly distributed, I assume in order to avoid exactly this kind of kvetching. Speaking only for myself here. > Isn't the concept of open software similar to that of the egoless > programmer? No. Further discussion >/dev/null. 73 Frank AB2KT ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Re: [Flexradio] A plea to SDR software developers
Sami Aintila wrote: Nothing to regret, Jim. These things needed to be said. [Frank Brickle] Further discussion >/dev/null. Well, this is certainly a helpful attitude. When these things are brought up in a public fashion, prior to any private communication or discussion on the subject, yes. It's helpful to take it out of public view until it can be determined what's actually being said on each side. We were not afforded that opportunity, but I will assert the right to take the discussion private until it is clear what the dispute really is. At present it seems to be a covert lament that the "free" in free software is as in speech, not beer. The point is (as Jim was trying to explain in his first post) that GPL may be the single most important reason why some people cannot contribute to this project. I think this is a serious problem. But this problem could be circumvented by following the guidelines Jim suggested. One important point is concealed by the discussion so far. Jim's complaint primarily involved an activity which, if I understand properly, is part of his employment. He's asking for changes to the licensing to make his job easier. I believe that you also have done at least some part of the development work under subsidy, if not salary. If not, I stand corrected. My contributions to the code have been completely uncompensated. Therefore, as stated previously, I (and presumably other contributors) would be more than willing to discuss alternate licensing terms, which under the GPL we are entitled to do. But it seems mildly unreasonable to expect that we, as copyright holders, should essentially give up our copyrights for nothing, for the benefit of somebody else's paid employment. It's simple equity. And now, really, no more public discussion. 73 Frank AB2KT
Re: [Flexradio] A plea to SDR software developers
[Sami Aintila] Using GPL is an ideological choice. Nothing wrong with that. But there are lots of people who really don't understand the ideology they are subscribing to. Until it's too late. It's like a cult: once you're in, you can never get out. OK, I'm not a big fan of GPL, but that's not the point. The point is (as Jim was trying to explain in his first post) that GPL may be the single most important reason why some people cannot contribute to this project. I think this is a serious problem. But this problem could be circumvented by following the guidelines Jim suggested. [Eric W] Contrarily, I believe it is the GPL which has ENABLED many people to contribute to this project without endangering the rights of the copyright holders. I assure you that had this project not been GPL, the DSP would still be in a very infantile form. I understand and respect your opinion of the GPL, but I believe choosing to use the GPL is one of the single best decisions our company has made. [Sami Aintila] But I know this is not the first time we're having this discussion. The concept of "plugins" has been mentioned (and rejected) many times before. But the concept seems to work just fine in many other applications. Why not here? [Eric W] I am still not completely clear on all of the legal implications of using plugins with a GPL project. There are clearly many sides to this argument with strong opinions as noted in previous messages. I don't have enough solid sources to make a statement one way or the other on this subject, except to say that the GPL license is VERY open. It would seem to me that a conflicting license would have to be closed more so than the GPL for this to ever be a problem. Jim's example does bring cause for more thought, however. Eric Wachsmann FlexRadio Systems -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sami Aintila Sent: Tuesday, August 30, 2005 4:27 PM To: FlexRadio@flex-radio.biz Subject: Re: [Flexradio] A plea to SDR software developers Some comments: [Jim Lux] > Warning... strong off-the-cuff opinions follow that I'll probably regret. Nothing to regret, Jim. These things needed to be said. [Frank Brickle] > Further discussion >/dev/null. Well, this is certainly a helpful attitude. [Eric] > We are committed to using the GPL as it gives us protection while at the same time offering an extreme amount of freedom in terms of modification and redistribution. Using GPL is an ideological choice. Nothing wrong with that. But there are lots of people who really don't understand the ideology they are subscribing to. Until it's too late. It's like a cult: once you're in, you can never get out. OK, I'm not a big fan of GPL, but that's not the point. The point is (as Jim was trying to explain in his first post) that GPL may be the single most important reason why some people cannot contribute to this project. I think this is a serious problem. But this problem could be circumvented by following the guidelines Jim suggested. But I know this is not the first time we're having this discussion. The concept of "plugins" has been mentioned (and rejected) many times before. But the concept seems to work just fine in many other applications. Why not here? 73, Sami OH2BFO ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Re: [Flexradio] A plea to SDR software developers
Some comments: [Jim Lux] > Warning... strong off-the-cuff opinions follow that I'll probably regret. Nothing to regret, Jim. These things needed to be said. [Frank Brickle] > Further discussion >/dev/null. Well, this is certainly a helpful attitude. [Eric] > We are committed to using the GPL as it gives us protection while at the same > time offering an extreme amount of freedom in terms of modification and > redistribution. Using GPL is an ideological choice. Nothing wrong with that. But there are lots of people who really don't understand the ideology they are subscribing to. Until it's too late. It's like a cult: once you're in, you can never get out. OK, I'm not a big fan of GPL, but that's not the point. The point is (as Jim was trying to explain in his first post) that GPL may be the single most important reason why some people cannot contribute to this project. I think this is a serious problem. But this problem could be circumvented by following the guidelines Jim suggested. But I know this is not the first time we're having this discussion. The concept of "plugins" has been mentioned (and rejected) many times before. But the concept seems to work just fine in many other applications. Why not here? 73, Sami OH2BFO
Re: [Flexradio] A plea to SDR software developers >/dev/null
At 01:16 PM 8/30/2005, Frank Brickle wrote: Jim Lux wrote: Nonsense... it's never premature to at least describe the intended structure as you build it. I'm inclined to believe you haven't actually made any serious attempt to look at the code. I have done so, both a year ago with the original SDR control software (in VB), and with the latest version. Don Knuth often has made the point that the chief deficiency in most programmers' skillsets is the art of reading other people's programs. Reading the program isn't the problem. It's that there are 40 some odd modules, and no table of contents. I hardly think that Knuth was contemplating multithreaded, multithousand line programs with very few comments and no specification document. I'd think that Brooks's comment in "The Mythical Man-Month" about the architectural summary document for OS/360 is more appropriate. Everything you're talking about strikes me as learning curve issues. One thing at a time. What exactly has you all riled up, anyway? Because I think (today, anyway) that if we really want an open architecture, with modifications to be made by all, that part of the openness is documentation to know where to even start. Perhaps, because you've been close to it from the inception, you might believe that it's all "obvious by inspection". Certainly that is the case for large software systems that I've developed.. they made perfectly logical sense to me, but when someone else came in to modify it, they scratched their head and thought "why the heck did they do that". When you arrive at the endpoint by following all the development steps along the way, it DOES tend to look elegant, efficient, and obvious. Not to too vigorously cast aspersions here, but the SDR1000 is more than a year old, and there's never been any sort of architectural description, except perhaps in Gerald's articles, and those were of a more generic nature. If you'd like to find somebody to underwrite it, great. I'm ready. This was in the context of "what it will take to gain general acceptance of SDR".. without such descriptions, general acceptance of open designs will not happen. Gotta have that block diagram and schematic. Which is not documented anywhere? At least not in any sort of file with an obvious name. Did you notice the file called "command-vocabulary?" main.c? sdr.c? update.c? Horse, water, drink. Now, that's sort of rude, but no matter... strong feelings are certain in these situations. If we didn't have these feelings, life would be stale, flat, and uninspiring, and we'd all still be using spark transmitters and iron filing coherers. Yes, oddly, I did notice them... However, what does main do? (in 25 words or less), what does sdr do? (in 25 words or less).. etc. If one wants to encourage modifications by the general population, one shouldn't require that they read and understand all several thousand lines of code. What's the basic update cycle? What are the timing restrictions? What are the interactions between modules. This is all basic stuff that you'd have to describe in any sort of software review. And, if, we in the SDR community aspire to anything better than tube sockets on cutting boards, we'll have to come up with it. This would be something other than is currently on the CVS repository? No. It's currently under development by the excellent Bob Cowdery, and it's been discreetly distributed, I assume in order to avoid exactly this kind of kvetching. Speaking only for myself here. Excellent that it's in the works and will presumably be released publicly. Although, citing non-publicly available resources to make a point is sort of rhetorical cheating. You can't claim "Gosh folks, it's all open, and ready for modification by every Dick, Sandra, and Paul DSP programmer" if basic stuff needed to do that mod isn't published. A better claim would be "Real Soon Now, you too will be able to modify the SDR code for your own desires, as soon as we release a final version". But then, that sort of contradicts Geralds espoused philosophy of eternal upgrades for increased functionality. James Lux, P.E. Spacecraft Radio Frequency Subsystems Group Flight Communications Systems Section Jet Propulsion Laboratory, Mail Stop 161-213 4800 Oak Grove Drive Pasadena CA 91109 tel: (818)354-2075 fax: (818)393-6875
Re: [Flexradio] A plea to SDR software developers
At 12:46 PM 8/30/2005, KY1K wrote: Hey guys... I'm not a programmer, never have been and never will. I don't understand 2/3rds of the terms used in the original message. But, I know the hardware and the concept of the QSD and that software is needed to make it run...hardware implementations become quite complex for a variety of reasons. The SDR-1000 page makes a very big deal about being flexible and the source code being available. Software is the heart of the SDR. While I can't speak as a software person, I can speak with great authority as a potential purchaser of the SDR-1000. If there is a problem with distribution or with anything that affects the ability of third parties to add features in software, I think the customers have a right to know this BEFORE they buy. Maybe this matter needs more public exposure. As a potential customer who wants one of these units, I think I have the right to know if the source code isn't 'available' (as it's advertised to be). Is this a topic that should be further explored by the ARRL before they publish the third Product Review of the SDR-1000 (scheduled for publication in June 2006)? The source code IS available (right on the http://www.flex-radio.com/ website) . And it's available under the Gnu General Public License. That license (in partial summary) essentially says that if you modify it *AND* redistribute the modified version, that the license has to continue with the modified version. You can't, for instance, take PowerSDR, add a bunch of nifty features throughout, call it (for example) "LuxSuperSDR" and sell it (or give it away) with a license that doesn't let people make copies or imposes other restrictions that the original PowerSDR GPL didn't. If you want to modify it for your own use (and not redistribute), you can do whatever you darn well please in the privacy of your own home, as far as GPL is concerned. If you're happy with GPL and it's terms (most folks are.. I certainly am), then for work you do for yourself, you're in great shape. The hiccup comes when someone else is paying for the work and THEY aren't happy with GPL. One scenario where this is the case is the one I outlined in my original post: JPL has problems with distribution of GPLed software because it doesn't match their NASA contractual requirements, which also require them to distribute software developed with taxpayer money. (This IS being dealt with, by the way, but "The gears of the law grind slow and exceedingly fine"...) The other scenario is where a third party vendor wants to add functionality, but for some reason, needs to keep a proprietary component. I give a lengthy example below. My plea was to make sure that the software architecture is built in a way that lets me add something to it in a way that's separate from the GPLed software, and that I could do my thing without having to modify the GPL software. Here's a practical example.. Say you wanted the the PowerSDR software to control your antenna rotator. The rotator manufacturer supplies a program that controls their rotator, but it's proprietary. You'd click on some menu option, and PowerSDR would just fire off a command to that program (something like "LuxRotate 137" would point the antenna to 137 degrees). It might well be that Lux Rotator company isn't interested in releasing the details of their proprietary computer to rotator interface. Lux Rotator is a hardware company, making money selling rotators... they have no interest in producing super duper software, BUT, they do want to keep people from making knockoff rotators. However, they might be willing to license it to another company who wants to create a program that will translate call signs off DXCluster into lat/lon and then into heading. So, they license the control protocol to Art's Software Mill, who then creates a new program called OwlRotate. Lux Rotator, though, requires Art to keep that protocol secret, which means that Art cannot distribute source code (since that would reveal the command protocol). Hopefully, you could configure some file in PowerSDR that would fire off "OwlRotate W6RMK" and life would be good. Art's Software Mill can then sell their OwlRotate program happily, complying with their agreement with Lux Rotator. And, PowerSDR stays totally open and GPLed, because NO modifications were made to PowerSDR. You can do this integration at a somewhat finer level (i.e. rather than a standalone program that gets called, maybe it's a library routine that gets called, or compiled in). However, IF the architecture of PowerSDR (or dttsp) is incorrectly formulated, then it might not be possible to do this. Maybe PowerSDR requires the program names and syntax to be compiled into the code, so that changing from LuxRotate to OwlRotate requires modifying PowerSDR.Then, Art's Software Mill is faced with trying to do two things.. distributing a m
Re: [Flexradio] A plea to SDR software developers
Source code documentation is coming. We plan to implement some auto-documentation coding standards in order to take advantage of some really nice XML based engines that will turn comments into html documentation. This will come with the new architecture that is currently being revised for the 1.5 Beta branch of the source. We are committed to using the GPL as it gives us protection while at the same time offering an extreme amount of freedom in terms of modification and redistribution. Eric Wachsmann FlexRadio Systems -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Lux Sent: Tuesday, August 30, 2005 1:16 PM To: FlexRadioMail Subject: [Flexradio] A plea to SDR software developers A couple pleas to those of you ambitously cranking out great stuff for the SDR, particularly in the Linux world 1) Gosh.. there needs to be SOME documentation of the structure of the software. Even a readme listing that says what each module does and who calls what. Sure.. am_demod.c probably does something with demodulating AM, but you'd never know it from reading the comments. Same applies to the PowerSDR sources... I hunted through the zip file a while, but never found any sort of documentation. Surely you guys have some sketchy document around that has the overall architecture? Maybe it exists, but it would be nice to have a link to where it is. Don't make it too challenging or nobody will get interested. 2) Structure the software so that you can make mods without getting wrapped around the GPL axle. There are people out there who would like to make contributions, and are actually paid to do software development, but for a variety of reasons, can't modify GPL stuff. For example, at Jet Propulsion Lab, most all of our work is funded by NASA, and software that is developed with that funding is notionally available to all, for free (well, the U.S. taxpayers have already paid for it). There's a whole raft of contractual details between CalTech (who runs JPL) and NASA about how that software is to be released, the (not entirely accurate) summary of which is that it has to be released in a different way, and with a different rights statement, that are incompatible with the usual GPL way of doing things. This came up when I wanted to use a modified version of hamlib and rigctl to control the SDR1000. The real problem came up when we wanted to release the modified versions. The GPL requires that modified versions also be GPLd, etc, be distributed in a certain way, etc. We wound up rewriting the needed functions from scratch (which was no big deal, but had I known from the start, I would have done things differently). So, if I want to insert something useful into a body of software that is GPLed, I have to make sure that my little piece is sufficiently standalone and doesn't include any GPL code in it. I can call modules in some library that's GPLd, and I can be called by GPL'd software, but I have to be self contained. This meets the GPL requirement: " If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. " Once it's been released (with the NASA process), you'd be free to include that with the rest of the system. And, in fact, you could freely modify what we developed and released. (you might even be able to GPL the copied/modified version, for all I know) There is also a review process that we have to go through to make sure that we haven't inadvertently trampled on someone else's proprietary rights, and that we aren't violating export controls, etc. There's a whole team of folks who deal with this stuff. I suspect other companies have similar issues. They may have no problem with releasing software that they've paid to develop into free distribution, but can't tolerate some aspect of the GPL. So.. when structuring your software, make sure you do it in a way that allows other parties to hook into it, without requiring too tightly tying it to the rest. Giant include files that define the world are "bad" from this standpoint. Shared memory structures likewise. Clean procedure call interfaces with relatively simple data structures as parameters or socket level comms, with a well defined protocol, are good. And, keep those data and message structures reasonably stable, because I can't use the GPLed .h file to define them. I have to create my own version that replicates it. (or, alternately, release the .h file into the public domain, explicitly) James Lux, P.E. Spacecraft Radio Frequency Subsystems Group Flight Communications Systems Section Jet Propulsion Labora
Re: [Flexradio] A plea to SDR software developers >/dev/null
Jim Lux wrote: Nonsense... it's never premature to at least describe the intended structure as you build it. I'm inclined to believe you haven't actually made any serious attempt to look at the code. Don Knuth often has made the point that the chief deficiency in most programmers' skillsets is the art of reading other people's programs. Everything you're talking about strikes me as learning curve issues. One thing at a time. What exactly has you all riled up, anyway? Not to too vigorously cast aspersions here, but the SDR1000 is more than a year old, and there's never been any sort of architectural description, except perhaps in Gerald's articles, and those were of a more generic nature. If you'd like to find somebody to underwrite it, great. I'm ready. There is no comparable thing for the SDR1000's software component. Have you looked at gnuradio? Which is not documented anywhere? At least not in any sort of file with an obvious name. Did you notice the file called "command-vocabulary?" main.c? sdr.c? update.c? Horse, water, drink. This would be something other than is currently on the CVS repository? No. It's currently under development by the excellent Bob Cowdery, and it's been discreetly distributed, I assume in order to avoid exactly this kind of kvetching. Speaking only for myself here. Isn't the concept of open software similar to that of the egoless programmer? No. Further discussion >/dev/null. 73 Frank AB2KT
Re: [Flexradio] A plea to SDR software developers
Warning... strong off-the-cuff opinions follow that I'll probably regret. (I'm home with my kids today, and it makes me tetchy) At 11:43 AM 8/30/2005, Frank Brickle wrote: Jim Lux wrote: > 1) Gosh.. there needs to be SOME documentation of the structure of the > software. Even a readme listing that says what each module does and who > calls what. Sure.. am_demod.c probably does something with demodulating > AM, but you'd never know it from reading the comments. It's premature. There will be documentation, but not until the DSP core has stabilized. That point is approaching very quickly. Nonsense... it's never premature to at least describe the intended structure as you build it. Would you build a house by just getting a pile of lumber dropped off and starting in with saw and hammer? Nah, you'd at least have a sketch, or an idea of how big the house was going to be. There's certainly lots of documentation on features out there.. Cynical I know, but the absence of documentation up to this point has been a natural selector, screening out the inevitable requests for support and explanation. Up till now it was a choice of either writing the code or explaining the transitional versions. Not a choice at all, really. I'm not asking for full on MIL-STD documentation sets. Just a map of what modules there are and what they do. You're perfectly free to tell people who ask for more to pound sand, but it's somewhat unrealistic to hope that, as Gerald puts it, "The user community gets to help make it a better solution" Software without documentation, albeit openly published, is not "open software". Or, as Gerald says, "Sure the new features may have a quirk or two but what ever happened to the joy of experimentation in the hobby." Trying to do this with ZERO software architecture documentation, is like trying to modify your radio without even a block diagram, much less the schematic. If someone DOES actually make a successful mod, it's likely it's the result of localized reverse engineering, and they have no way to know if it fits in the overall scheme of things correctly. Will it break when the next rev comes out? Does it have some unforeseen side effect? The situation is different once the code is basically frozen. With the exception of the AGC and the EQ, and perhaps some mods required to play well with Bob Cowdery, it's nearly on ice. Not to too vigorously cast aspersions here, but the SDR1000 is more than a year old, and there's never been any sort of architectural description, except perhaps in Gerald's articles, and those were of a more generic nature. You've got to start somewhere, and it's not like there's a long history of software radios to look at for architectural guidance. At least from a hardware standpoint, if I were looking at a mystery radio, I'd look for standard components in a superhet design. I'd find mixers, LOs, filters, etc. Sure, there are differences in the details, but if I wanted to, for instance, change the IF filter in a hardware radio, I'd know where to look, and conceivably, where to probe with a scope. There is no comparable thing for the SDR1000's software component. This puts a HEAVY burden on the software developers if they want public acceptance of the SDR concept. Otherwise it will remain a tinkerer's toy, and the vast majority (of the minority of hams who actually use one) will be forced to operate it as an appliance, because they'll have no idea where to even start modifying. > Surely you guys have some sketchy document around... > Don't make it too challenging or nobody will get interested. Nope. No such document. A great deal of how the DSP works is exposed in its control API. Which is not documented anywhere? At least not in any sort of file with an obvious name. Unfortunately this is completely concealed in the PowerSDR package, owing to the exigencies of the Windows process model. Nonsense. It is entirely possible to have architectural documentation of Windows processes, including for quasi real-time multithreaded processs. There's an enormous amount of software development for the windows architecture that could not be done without tools and methods to deal with it. While I don't think you need to go whole hog UML, with process and interaction diagrams, it's a canard to say that you can't document how it works because of the way Windows works. I will grant that there's a fundamental mismatch between the Windows "events driven by user actions" model and the typical DSP application, which is why I really, really prefer purpose designed DSPs and RTOSs for signal processing. I believe you will find the situation very different with the decoupled Python code. This would be something other than is currently on the CVS repository? > 2) Structure the software so that you can make mods without getting wrapped > around the GPL axle... Sorry, that's not going to happen. Anyone is of
Re: [Flexradio] A plea to SDR software developers
Jim Lux wrote: 1) Gosh.. there needs to be SOME documentation of the structure of the software. Even a readme listing that says what each module does and who calls what. Sure.. am_demod.c probably does something with demodulating AM, but you'd never know it from reading the comments. It's premature. There will be documentation, but not until the DSP core has stabilized. That point is approaching very quickly. Cynical I know, but the absence of documentation up to this point has been a natural selector, screening out the inevitable requests for support and explanation. Up till now it was a choice of either writing the code or explaining the transitional versions. Not a choice at all, really. The situation is different once the code is basically frozen. With the exception of the AGC and the EQ, and perhaps some mods required to play well with Bob Cowdery, it's nearly on ice. Surely you guys have some sketchy document around... Don't make it too challenging or nobody will get interested. Nope. No such document. A great deal of how the DSP works is exposed in its control API. Unfortunately this is completely concealed in the PowerSDR package, owing to the exigencies of the Windows process model. I believe you will find the situation very different with the decoupled Python code. 2) Structure the software so that you can make mods without getting wrapped around the GPL axle... Sorry, that's not going to happen. Anyone is of course free to make whatever mods they please for their own use. The crunch only arises with distribution, as you've underlined. As is always the case with the GPL, secondary licensing under other terms is possible and negotiable. But the basic commitment to the GPL is not going to change. 73 Frank AB2KT
[Flexradio] A plea to SDR software developers
A couple pleas to those of you ambitously cranking out great stuff for the SDR, particularly in the Linux world 1) Gosh.. there needs to be SOME documentation of the structure of the software. Even a readme listing that says what each module does and who calls what. Sure.. am_demod.c probably does something with demodulating AM, but you'd never know it from reading the comments. Same applies to the PowerSDR sources... I hunted through the zip file a while, but never found any sort of documentation. Surely you guys have some sketchy document around that has the overall architecture? Maybe it exists, but it would be nice to have a link to where it is. Don't make it too challenging or nobody will get interested. 2) Structure the software so that you can make mods without getting wrapped around the GPL axle. There are people out there who would like to make contributions, and are actually paid to do software development, but for a variety of reasons, can't modify GPL stuff. For example, at Jet Propulsion Lab, most all of our work is funded by NASA, and software that is developed with that funding is notionally available to all, for free (well, the U.S. taxpayers have already paid for it). There's a whole raft of contractual details between CalTech (who runs JPL) and NASA about how that software is to be released, the (not entirely accurate) summary of which is that it has to be released in a different way, and with a different rights statement, that are incompatible with the usual GPL way of doing things. This came up when I wanted to use a modified version of hamlib and rigctl to control the SDR1000. The real problem came up when we wanted to release the modified versions. The GPL requires that modified versions also be GPLd, etc, be distributed in a certain way, etc. We wound up rewriting the needed functions from scratch (which was no big deal, but had I known from the start, I would have done things differently). So, if I want to insert something useful into a body of software that is GPLed, I have to make sure that my little piece is sufficiently standalone and doesn't include any GPL code in it. I can call modules in some library that's GPLd, and I can be called by GPL'd software, but I have to be self contained. This meets the GPL requirement: " If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. " Once it's been released (with the NASA process), you'd be free to include that with the rest of the system. And, in fact, you could freely modify what we developed and released. (you might even be able to GPL the copied/modified version, for all I know) There is also a review process that we have to go through to make sure that we haven't inadvertently trampled on someone else's proprietary rights, and that we aren't violating export controls, etc. There's a whole team of folks who deal with this stuff. I suspect other companies have similar issues. They may have no problem with releasing software that they've paid to develop into free distribution, but can't tolerate some aspect of the GPL. So.. when structuring your software, make sure you do it in a way that allows other parties to hook into it, without requiring too tightly tying it to the rest. Giant include files that define the world are "bad" from this standpoint. Shared memory structures likewise. Clean procedure call interfaces with relatively simple data structures as parameters or socket level comms, with a well defined protocol, are good. And, keep those data and message structures reasonably stable, because I can't use the GPLed .h file to define them. I have to create my own version that replicates it. (or, alternately, release the .h file into the public domain, explicitly) James Lux, P.E. Spacecraft Radio Frequency Subsystems Group Flight Communications Systems Section Jet Propulsion Laboratory, Mail Stop 161-213 4800 Oak Grove Drive Pasadena CA 91109 tel: (818)354-2075 fax: (818)393-6875
