Beta Address: http://blish.org/sdrdxdoc/aboutdocs.html
1.2 - About the Documentation
I generate the documentation using a custom authoring system and markup language I wrote using Python 2, using PostgreSQL as a database containing the various pages, styles and so forth. It creates a local (to me) copy of the documentation as I work, which I can look over, and then when I'm satisfied, I put the result wherever I intend it to go.
This allows me to have fairly quick turnaround on updates and changes, and frees me from dealing with HTML directly; instead, I use a limited markup syntax that is powerful, extensible, yet simple and "tuned" to my peculiarities.
I also expose the documentation as I work on it for technically savvy testers. This link will give you access to the beta documentation.
1.3 - About the Software
1.3.1 - Operating System Compatibility
1.3.2 - Application History and Miscellany
SdrDx was originally derived in 2011 from the initial release of CUTESDR, a very basic SDR program that was made available by RFSPACE and Moe Wheatley. Moe was incredibly kind in giving the SDR community CUTESDR, and beyond that, he has been of great assistance to me personally. My considerable and heartfelt thanks to Moe.
Moe made an interesting choice with CUTESDR; that was to develop it under Nokia's Qt multi-platform environment. This has been both a curse, as Qt has some serious problems; extremely high cost for commercial projects, utterly worthless support, and non-existent fixes — and a blessing, as for most of the program's capabilities, multi-platform support requires no more than a straightforward recompile.
I've run into some real "gotcha's", though. For one, there's no particular USB support in Qt at all, so that requires two complete sets of different code for OS X and Windows support; For another, the sound handling (specifically the QAudioInput class) is pretty severely broken under Windows (hard-coded sample rate limitations), which has unfortunately impacted support of soundcard-based SDRs such as the FCD for the Windows version.
Overall, I have several goals here:
I'm providing various means to monitor and control the audio quality so that listening is easier — and less tiring.
It is my intention to get as many as possible of the primary controls and indicators onto the main control panel so that interaction with dialogs during typical listening operations is reduced to the minimum reasonable amount, and interaction with menus is reduced as nearly as possible to zero in normal operation.
To these ends, I've been working on the SdrDx project since March of 2011, and mostly having a lot of fun doing it, when I'm not fighting the various shortcomings in the development system, Nokia's Qt.
While I do provide the compiled application for free, I don't distribute the source code because some of what I've done, particularly in the audio processing area, is derived from commercial signal processing code that belongs to my company.
I encourage anyone who wants to experiment with RFSPACE software defined radios to go download the CUTESDR source code and dig right in.
1.3.3 - End-User Ownership Policy
I'm giving you this application executable, with the (admittedly optimistic and somewhat vague) idea in mind that if you like it, you might donate a few bucks my way using the Paypal button over on the right. I think it's important to talk about why I do that, as opposed to licensing it to you or selling it to you.
An application doesn't have to be open source to be yours. My terms when I create an application are that you bought, or I gave to you, the application executable — so it's yours. I got money, you got stuff. Or, I gave it to you, and I actually did give it to you.
I decided to do that when I was building commercial software for a living well over a decade ago; I've been doing it that way ever since and don't regret it at all. But not everything I release that way is open source (some is... a matter of giving back some general value to the community. I have a number of projects of various sizes on offer on Github.)
Ownership or licensing: On the face of it, it is a policy decision: do I want to sell a useful thing to someone? Or do I want to hold on to it? Most corporations and many independent developers (myopically, in my opinion) think they need to keep hold of the ownership of the application executable and its support files. Personally, I think they're cutting off their noses to spite their faces.
However. To be fair, a lot of this is due to tort legislation and lawyers; respectively the turds and the assholes that plant the turds all over our lives. I wish personal responsibility for one's own decisions, and careful statement of risks on the part of providers of whatever, were the basis for the things we choose to do, consume, buy, and use. But... sigh. This has turned into a massively litigious society. We choose how to play the cards we are dealt in the environment we have to operate within.
So why not open source? Because, essentially, the food at the market isn't free, and the value of the commercial products we provide drops when competitors arise with a head start equal to everything we spent X amount of time on — and that means less food. And less everything else, too.
Some suggest various forms of "So give the code away, and charge for support."
But when the production model is "provide the best product you can" and you're serious about it, the value of "charging for support" drops precipitously. Likewise, good docs, less support. But really: a good product and good docs? Isn't that exactly what you'd want me to do if I sold you something physical that didn't have to break or wear out?
So charging something reasonable for a product that doesn't need a lot of general end-user support... as far as I'm concerned, that's optimal. So that's where I aim with commercial products. Which leaves little to no window for charging for support.
That's a little different from bugs, though not in the charge-for-fixes sense. You report a fixable bug I am responsible for, I will do my best to fix it, and if I can, you will get the fix for free, because it wasn't doing what I meant it to do for you and I was able to fix it. Or in other words, I said it would do X, the user got involved on that basis, so I consider it my obligation to try and make it do X if it is even remotely practical and possible to do.
Again, this seems to me like a basic premise for being able to claim one has a quality product. Likewise, if I sold a product to you saying it would work under some particular operating environment, then it should, and if it doesn't, then the ethical path appears to me to be that I have an obligation to attempt to fulfill: not money to collect.
Some of my products are donate-ware. That has its merits as well, although most people won't donate. It's not something I choose to do with the idea that I'm going to get a whole lot back. But again, to the extent that it is effective in the first place, it loses that effectiveness if I give away the source code to the product, because then I have diluted the market for what I've created.
Finally, some products share code, and some of those are straight commercial efforts, and it's (obviously, I hope) a really bad idea to hand over valuable technique and technology that is serving to enable me to buy food in one product, in another that I am giving away.
Hopefully, the foregoing has served to enlighten you a bit about why I am not committed to offer all my work product as open source, and why SdrDx is closed source donate-ware and not a commercial or open source effort.
1.4 - Additional Credits
Oliver Janoschek ("multivitamin")
Idea Contributions & testing of same:
Rick Roush, KA8BDD
Chris Smolinski, N3JLY
Larry Szendrei, NE1S
David Turnbull, AE9RB
|toc||index||guide||changes||keyboard||, previous||. next|