At 10:41 AM 6/25/2008, Bill Tippett wrote:
> Given the rate of change of SDR technology, (e.g. >N8VB's QS-1R), you may have unrealistic expectations that >*any* platform today will still be viable in 5 years! > > 73, Bill W4ZV In fact, this is the dominant aspect to SDR. As Flex-radio says, the radio keeps getting better, but in reality, it's also that the radio keeps changing. The key is in providing suitable interfaces between functions so that as various parts of the system change, the rest can remain the same. For instance, if I have a box that generates an I/Q data stream, all the downstream parts should be sufficiently parameterized that they can accommodate various data rates, bit precisions, and frequency offsets. Likewise, controlling that I/Q box should be exposed through a generic interface that says "set frequency", not "set DDS bit 32". A hardware abstraction layer (either in software, firmware, or hardware...it matters not) turns frequency into whatever the box needs, be it DDS control words, GPIB commands to a synthesizer, etc. The box returns the actual center frequency achieved (so that granularity and step sizes can be accommodated) It would be a great service if someone were to start to define suitable abstracted attributes of such boxes. For some commonly used devices, such things have been done. For instance, in the digital RF modem world, there is a JTRS MHAL (Modem Hardware Abstraction Layer) definition that defines various common attributes such as modulation types (BPSK/QPSK/etc), RF chain stuff like AGC behavior, etc., as well as sort of generic data shoveling stuff like FIFO lengths, generic sources/sinks With the abstraction and well defined interfaces will inevitably come some CPU and memory resource consumption, but that's always getting cheaper. If such a standardized set of interfaces is available, then new software might eventually start to use them, if they are sufficiently clean and useful. The danger is in setting the level of abstraction and specification too high or low. For instance, if you make it really complete and complex, then the casual hacker will look at the 200 page spec with the same sort of horror that you get when contemplating the Windows API. If you make it too simple, it doesn't bring any value, because it's either meaningless or because it doesn't accommodate the usual scenarios. The other thing that is absolutely necessary is a "reference implementation" that uses and demonstrates the standard. You need to have some simple radio implementation that uses the proposed standards that can serve as a starting point for a rookie developer. Again, we look to the traditional model.. nobody starts totally from scratch to write, say, a serial port to TCP/IP handler. You take someone else's simple serial port handler and start modifying and adding your unique functionality to it. Actually, you need multiple reference implementations (aka "examples") so that you don't wind up trying to show ALL possible features in one big example. In some ways, this is the problem with pointing someone to the current PowerSDR. It's so big, so complex, and so functional that it's very difficult to know where to start. If one had, say, a single function SSB transceiver that talked to the flex hardware, with a very rudimentary user interface, it would be a lot easier to experiment with or drop in a new function. You wouldn't have to worry about inadvertently breaking another function like CW or pan adapters, etc. Make no mistake.. creating such a thing is a lot of work. And a lot of work that doesn't directly meet a pressing need for the radio. It's there to enable future work and lay the foundation. It doesn't meet any of Flex-radio's needs, for instance. Their needs are met adequately by PowerSDR.. they have enough people to keep its development and maintenance moving along, people who have climbed the huge initial step of familiarization and don't need clearly defined interfaces and examples, because they have the code sitting in front of them. Frank AB2KT, et al., are working towards this goal, but it's not clear that their objectives are aligned with the casual ham who's interested in supporting multiple hardware platforms with the same application. I have the feeling that they're taking on a bit larger goal of creating a generic way to build radios, a framework, if you will, and leaving the details of individual platform support to others. There will, of course, be a reference implementation for the VR-kernel, etc. which may serve as a starting point. On the other hand, there hasn't been much mentioned in the presentations and open discussion about defining specific abstracted functionality (e.g. what attributes should a generic AGC function have). To be fair, I'm not involved in that development at all, and for all I know, they have lots and lots of discussions about this sort of thing among the small group of developers; which would certainly be more productive than having to listen to all the partially knowledgeable lurkers and bystanders weighing in all the time. Coming up with good standards is tough. You need a small group to work on it, because only with a very small group do you get good internal consistency and architecture. On the other hand, small groups tend to not generate good generic descriptions, because they inevitably focus on what they are interested in, or on today's problems, etc. Good generic standards (and I've been involved in a fair number of standards developments over the years, some good, some bad) come about by having a small group publish their thoughts periodically, let folks comment on them, and then go back to decide what to change, if anything, based on the comments. It has to be reasonably fast cycle time, otherwise, the standard only addresses what was possible with last year's technology. For that reason, a good standards development group has to be composed of visionaries (who will push for what might be useful 10 years from now) and pragmatists (who have to implement it today) and reactionaries (who always ask the question "why should we change what works") Left to their own devices: the visionaries will promulgate standards that cannot be built today, so there's no adoption the pragmatists will promulgate standards that help them today, but don't push the state of the art the reactionaries will promulgate standards that define what we did yesterday in infinite detail. Jim Lux, W6RMK _______________________________________________ FlexRadio Systems Mailing List [email protected] http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/ Knowledge Base: http://kb.flex-radio.com/ Homepage: http://www.flex-radio.com/
