Beta Address: http://blish.org/sdrdxdoc/aboutdocs.html

1.2 - About the Documentation

Authoring System

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.

Caution:

Please be aware that the beta documentation often reflects unreleased changes incorporated into the unreleased version presently under development, and may also temporarily contain information relating to features I decide to put in, and then change my mind about for various reasons such as ultimate practicality, quality, compatibility, etc. Having said that, I very much appreciate any feedback on documentation errors or improvements either in the release documentation or the beta documentation.

Tip:

If you're interested in looking over, or using, my Python-based markup language, I've made it available here.

I have also released the entire server-based documentation system (here.) Please be aware that this is a Python-based system that must be deployed on a web server and is then accessed via web browser. It is not a desktop application.

1.3 - About the Software

1.3.1 - Operating System Compatibility

• OS X 10.6.8 through 10.13.2
• Windows XP and later

1.3.2 - Application History and Miscellany

SdrDx 2.16z

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.

CUTESDR v1.0

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.

Caution: As the Qt people have gone on to later versions, and those later versions no longer support the platforms many of my users, and I, are using, it appears there will be no resolution forthcoming for the 48 kHz bandwidth limitation for soundcard-based SDRs like the FCD under Windows. Truly sorry, folks. I reported the bug in more than enough time for them to fix it, but they never did so, and now it seems to be far too late (I can't even get them to fix bugs in the current version!)

Overall, I have several goals here:

I'm adding features so the AFEDRI, AirSpy HF+, SDR-IQ, NETSDR, SDR-14, FCD, FCD Pro Plus, Andrus SDRs can be more useful and more enjoyable.

Note: I'd like to add other SDRs as well. If you make an SDR product and you'd like to see support for it added to SdrDx, please contact me using fyngyrz aht gmail dawt com (sorry for the minor obfuscation, publishing usable email addresses just seems to earn one offers from certain Nigerian princes...)

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.

Note: One of the things I like best about my favorite analog radios are the directly accessible controls on the front panels — it makes them much more enjoyable to operate. Please take advantage of the TIP / TIP / TIP switch to turn on tooltips.

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 - Feature Loading - So Many Buttons!

The following serves as a good indicator of my idea of appropriate application feature loading:

I'm sure I could squeeze in some more...

1.3.4 - 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

Program Icon:
Oliver Janoschek ("multivitamin")

Beta Testing:
Chris Smolinski
Rick Roush
Pete Barrow
Terry Genes
Jerome ?
Jamie Lodberg, Norway
Rob ?

Documentation Feedback:
David Jaksha

Idea Contributions & testing of same:
Rick Roush, KA8BDD
Chris Smolinski, N3JLY
Larry Szendrei, NE1S
David Turnbull, AE9RB

Note: Paypal and Other Donations:

Andrus Aaslaid (Andrus MK 1.5 SDR x2)
Anonymous (Perseus SDR)
Charles R. Allen — N4TVC
David Ault
Justin Bevan
George Blahun Jr
Francisco Borja
Clear Sky Institute
Lawrence Fagan
Robert Fisher
Steven Freeman — K1MV
Greg Gilbert
J Patrick Harrington
Pete Helme
KF7DRU
David Hochfelder
Chris Laplante
Vesa Laulumaa
Howard Long (Funcube, Funcube Pro SDRs)
ITEAD (AirSpy SDRs x2)
JCMaxwell
Jay Novelio
Juan Olmos
Daniel Porter
Jason Schwarz
SDRPlay (Play RSP SDR)
Douglas Smith
RB Smith
James Spears
David Strubbe
Larry Szendrei — NE1S
Serge Van der Torre
Alexander Trushkin — 4Z5LV (AFEDRI AFE822 HF+HF Dual-Channel SDR)
Mark Turner
Bill Wantz
Mark Watanabe
Stephan Wick
Huw Williams
Norbert Wohlfarth
Dave Wright

My heartfelt thanks to these fine folks; I deeply appreciate your contributions, and will use them in pursuit of radio; filters, antennas, etc., while I continue to work on SDR code so we can all have more fun. When SDR contributions come in, the odds of support of that SDR go way way up.