At 11:49 AM 8/25/2006, [EMAIL PROTECTED] wrote: >Jeff, > >Well, by this time, everyone knows where I stand on this sort of discussion. >To me, this is not a marketing issue. We are talking about how to allow >users of the rig (that have already bought and paid for it) to extract the >maximum performance from the system.
Mind you, you bought and paid for the hardware, and some level of software as it was.. And, you have good hardware documentation: all the registers are defined and their behavior follows the description, and it's not likely to change. (at least for the pre RFE version.. I haven't looked at the post RFE version, since I don't have any of those, but we're not talking huge changes here.. a few lines on a port to do one thing or another). You also have example source code (albeit a tad obscure) that achieves some fairly decent performance, within a "usage model" that is similar to conventional radios (i.e. RF gain,AF gain, filter passbands) with a conceptual interface that follows a conventional superhet analog radio model. There's a control interface for this model using a modified version of the Kenwood CAT comamnds that is well documented (although, the date on the current software modules that handle CAT is quite a bit later than the date on the docs, but it's probably "reasonably" close) And, there is a relatively undocumented, but open (in the sense that all the calls and parameters are visible, albeit with no explanations) interface to the dttsp engine. There's also a better documented interface for PortAudio, PortIO, and pthreads. And, let us not forget that there's the software interface to the Windows environment (all gazillion entrypoints) which is documented at varying levels: the call syntax is very well documented, how to hook the calls together, less so. But, I suspect what YOU want (and I want, too, and probably others) is an abstract interface at a level between the "here's 200 DLL entry points in 5 different DLLs that mutually interact in an undocumented way" and the "CAT style interface". That is, you'd like the ability to use the flexibility inherent in either the current dttsp chain or an alternate processing chain, but with a reasonably nice, abstracted, and stable interface. This is not unique to the SDR1000 and PowerSDR, by the way. What that interface should look like as well as what features it should provide is the subject of much discussion. Heck, even a standardized way to describe the radio processing architecture is a subject of much discussion in the SDR world in general. (the idea is.. I have some sort of thing I want to do with a software radio, what kind of description of that radio would tell me whether what I want to do is possible.) This sort of thing, aside from everyone kind of wanting a different manifestation, is not something that anyone has signed up to do for the SDR1000. I personally feel that there are some significant structural, logistical, and organizational impediments in the way of anyone who *would* want to do this, but nothing that is impossible. It would go a long way from turning a fairly generalized and flexible hardware platform (the SDR1000) into a generalized software radio platform. So, to extracting maximum performance (which, of course, is different for everyone) is either by virtue of your own toil or the kindness of others. I think that the discussions of "how do we expose radio functionality", of which the "gain" discussion is but one facet are quite useful. Even if nobody is going to be developing code to support the concepts discussed, they at least provide a context to frame the discussion about the development that *is* being done, such as it is. Even better is that people, like yourself, are bringing comparative concepts into play. Hams are kind of a unique "consumer" of a software radio, because their needs and requirements span such a huge variety of use cases, and hence, require a lot of different "conceputal models" for the radio. It's not like a cellphone radio designer, where you know, a priori, what the modulations, bandwidths, functions, etc. need to be. This is why I like the idea of different interfaces (at a software AND UI level) to the radio for different modes. The kinds of high level controls one might want to manipulate from your UI are different for a CW radio than for a SSB radio than for a SSTV radio. By controls here, I don't mean "knobs and sliders on the screen" but, rather, the functions that the UI calls, after you mouse, or turn, or click, or press the key. >You are only going to get maximum AGC >performance in critical listening situations by having ready access to and >understanding, technically, how to adjust all the DSP engines AGC >parameters. It is that simple. I wish that you could, in fact, put a simple >control on the front panel, call it RF Gain, and have it perform some sort >of magic in all situations. But that isn't going to happen. Hmm.. but I propose a slightly different model. In my model, you have an interface that lets you turn every little inside knob, but, you also have an interface that lets someone else abstract those to a higher level. Think in terms of the idea of the new controllers for home entertainment systems. Rather than have separate remotes for each component, and requiring a great degree of sophistication on the part of the user to get the "best" sound out of the system, you have someone come in and create a single remote that the user can just push "watch TV" on, and all the system parameters are configured appropriately, including the selection of functions available (change channels, etc.). If I then push "listen to Music", the stereo is reconfigured to feed from the CD jukebox or computer, the functions on the remote lose the "channel select" and now I have track select. Right now, the ham SDR world is a bit like about 30 years ago in home stereo. You have graphic equalizers which you can fiddle with, and a zillion other knobs. Compare this to high end sound systems today, where the eq is in a closet somewhere, with screwdriver style adjustments. When was the last time you saw a "tint" control on a TV that was intended to be user accessible? Now you get a few "presets" that encapsulate a whole raft of adjustments. Another example might be to compare the roles of the director and lighting designer and the electricians on set. The director says, "I'd like an oppressive, brooding feeling, like there's a storm brewing". The lighting designer says, ok, I need the following kinds of gels and instruments set up about here and aimed about there. The electricians climb into the rigging and hang the instruments, set up the gels, and program the lighting board so that the right lights come on when the right channels are pushed on. Then, the lighting designer sits at the board and fiddles with the levels and defines the scenes, interacting a bit with the electricians (move the fresnel on #12 stage left a few feet, maybe a blue instead of an violet gel on #54). Finally, the director looks at what the designer has done, and says, yep, that's it, or, I hate it, you're all fired, and you'll never work in this town again because you're clearly incompetent <grin>. But you get the idea... There's a many decade history with analog radios. There's a good conceptual understanding of what happens when you change something in the analog signal processing chain (i.e. change IF filters), and people have gotten to where they describe their requirements in terms of specific implementations (I want a Collins 150 Hz filter, not, I want this particular shape factor and group delay characteristics). The same is true in music... I want that fat overdriven Marshall sound, not, here's the transfer function of the amplifier I want. It's hard with such a flexible canvas as DSP. Most people don't want to have to specify the DSP chain, in native DSP terms. But they also want more adjustibility than just what replicates some other radio. >As far as the "more intuitive", my response is that we all must keep >learning new things until the day we die. When I learned to drive it was >with a stick shift. When I bought my first car with an automatic >transmission it was not intuitive to operate a car with out a clutch, but I >learned. Hams new to DSP radios are going to have to learn a few new >things. The intuitive part comes with practice. Very, very true... As the conceptual models of "what is a radio" evolve, the desired interfaces will change too. These days, very few people worry about how many electrodes vs how fast the rotor spins on their spark gaps, or the difference in quenching speed between alcohol vapor and air, but those used to be something very important, in terms of performance. Jim _______________________________________________ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
