[Flexradio] In a sentimental mood
Frank, Many thanks for explaining your design issues to us software 'numbheads'! Like you say, it's only after a couple of goes at building such a project do you realise the more elegant ways of structuring the thing. I'll be interested to see how much more 'readable' 1.5 et al becomes. I also found Jim Lux's comments very interesting. On the documentation thing - if one of you software gurus had the time to record what the basic inputs, action and outputs were for the various modules, send me a WAV file via email, I'd be very happy to write it up into the code. Probably easiest to do it a few modules at a time. I think what would set me up with being able to tinker with the code like I used to do with the VB console is a design note that outlines the basic mechanisms used to transport signal and control streams around the radio. It might seem obvious to the experts, but without that roadmap I'm currently floundering in this heavily 'event driven' archetecture. As above, if someone knowledgeable is willing to talk it through on a recording, then I'll write it up, get it checked, correct it etc. (I do a lot of technical writing at work with EMC test reports etc.) I'm away on holiday all next week, but anytime after that. Regards, Bob Edwards, G4BBY
Re: [Flexradio] In a sentimental mood
Jim Lux wrote: Is it? Are the various aspects of the receiver and transmit processing truly a series of interconnected little boxes with data flowing continuously through them (in a "you can replace a module, without knowing what's happening in the adjacent modules, recompile, and it still works" sense). Yes. No exceptions. That was one of the fundamental design criteria. It was enforced by the bottom-up decision to write the buffer methods first. you have those "frame" and "unframe" or "rebuffering" steps, which tend to add latency, even if the overall processor loading isn't the issue. There aren't any such steps, again enforced by the bottom-up decision that each unit generator -- a bit of old computer music jargon for processing units, but well entrenched -- knows about nothing but the buffer(s) it allocates or is pointed to at the time it's instantiated. How does changing sampling rates through the chain fit in: e.g. the classic technique if bring the data in wideband, do an fft, then, for multiple streams, grab some adjacent fft bins, and reconvert back to a lower sample rate, producing several lower bandwidth parallel signals. That's not an issue with the SDR1K. That kind of channel downconversion happens upstream from the current DSP in other realizations. I fully agree, although I have some questions about how you'd integrate things like adjusting the phase offset register of the DDS into the DSP stream. It's handled at the virtual radio layer, which has knowledge of the hardware and the DSP, while they know nothing about one another. Probably, if only because the interprocess communications mechanisms in Windows are different than *nix. That's precisely what I was talking about when referring to obstacles being thrown up by the Windows process model. IPC is immeasurably more difficult under Windows because processes are spawned fresh rather than via fork-exec, which enables inheritance of open file descriptors. It's the single worst feature of the VMS/NT/XP design. We looked at and discarded hamlib at the earliest stages as resting on an overly circumscribed model of the radio control. If the interface is defined at an appropriate level, I see no reason why one would care what the gui is written in. It could be Excel macros, if you were really, really ambitious (or foolhardy). It's been that way for months. Unfortunately PowerSDR can't take advantage of it, as it stands. I've been pushing for a PHP interface since before last Christmas, to serve as a web-based console. The only thing preventing it is a little elbow grease. Of course, part of the UI is timing critical things like audio input and playback (maybe?) or things like CW keying (or is CW keying part of the DSP chain.. it gets back to the "variable data rate" thing I was talking about above). Under Linux the CW facility is a separate process that routes its audio output into the pair of auxiliary audio input ports on the DSP. Variable data rates in general are not likely to happen, except as one-off capabilities, owing to the strictures of the OS audio subsystems. 73 Frank AB2KT
Re: [Flexradio] In a sentimental mood
At 08:09 AM 9/1/2005, Frank Brickle wrote: Bob -- Now. Consider the SDR1K software. Under Linux, the DSP and audio chain are *already* modularized in the VST sense, with a tremendous array of options and existing plugins. Is it? Are the various aspects of the receiver and transmit processing truly a series of interconnected little boxes with data flowing continuously through them (in a "you can replace a module, without knowing what's happening in the adjacent modules, recompile, and it still works" sense).Seems that in almost every software receiver design I've ever worked with that there's a remarkable amount of coupling among boxes (usually for performance reasons)... Especially if you're doing any "framed" signal processing (such as FFT based filtering), you have those "frame" and "unframe" or "rebuffering" steps, which tend to add latency, even if the overall processor loading isn't the issue. For instance, you might have your IF filtering done in frequency domain, but, then, be doing your modulation/demodulation on a continuous time series (a trivial example would be an AM detector that simply does (I(t)^2+Q(t)^2) How does changing sampling rates through the chain fit in: e.g. the classic technique if bring the data in wideband, do an fft, then, for multiple streams, grab some adjacent fft bins, and reconvert back to a lower sample rate, producing several lower bandwidth parallel signals. Commercial products like Matlab/Simulink do this (a bit clunkily, in some cases) and will actually generate real live DSP code (which is totally incomprehensible... but then, the argument is that nobody expects to read the object code from a C compiler either). Labview, VEE, and their clones do this kind of thing too (although I'm pretty sure I wouldn't write hard real-time code in Labview). Given that Matlab is available in an inexpensive academic edition, and that Octave provides (for free) many of Matlab's capabilities, one might want to make sure there's some way to do this. It's a lot more congenial as a DSP developer(at least at the beginning of a development) to spend a few more bucks on a faster processor and accept the inefficiencies of Simulink. Never for a minute would I expect something of that level of flexibility to be developed specifically for the SDR1K. I use it as an example of a fairly flexible, modularized approach to defining the signal processing chain. The hardware control is unlikely to be a subject of much tinkering, once it's completely remotable. I fully agree, although I have some questions about how you'd integrate things like adjusting the phase offset register of the DDS into the DSP stream. I suppose, at a basic level, as long as the interface exposes the raw DDS registers (in addition to whatever other features), you've got that fallback. This, by the way, was the problem we encountered trying to use hamlib for our work. The hamlib library wants to make everything look like a radio, and some aspects of the SDR1K aren't particularly "radio-like". We started out modifying hamlib, and then when someone asked for a copy of our modified library we discovered the issue with GPL. (I should also point out that we, JPL, do (now) have a way to do GPL stuff.. ) The console is already in Python under Linux, and the consensus is that in the new version, the "virtual radio" layer will be in Python too, in all versions. Once again, that means that it's designed and written in such a way as to yield the benefits of "modularization" without having that feature designed in explicitly. That leaves, literally, only the gui open for debate. Since the Linux version (and the eventual Mac version) shares the good traits of Python and PyRo with the virtual layer, the question is moot on that platform. It leaves only the Windows gui up for debate. Where we wind up is at a fork. My contention is that, in order to achieve the kind of modularization in the DSP under Windows that already exists under Linux, substantial modifications might have to be made that would cause the two versions to develop independently. Probably, if only because the interprocess communications mechanisms in Windows are different than *nix. Unless you (or someone else has already done it) want to create some sort of generic DSP engine, but that strikes me as a huge ordeal, and realistically not worth it. However, the fork can still have a lot of common code. When all is said and done, both sides will be in C, and the basic algorithms that need to be implemented are the same, so maybe it's a matter of suitable calling protocols to the grunt level routines and OS specific wrappers. I've never even contemplated this for a real time application and it might be unrealistic. My overall experience with shoehorning hard realtime DSP into any general purpose OS has been quite grim. I'm quite impressed that it works well with both. Similarly the gu
Re: [Flexradio] In a sentimental mood
Phil -- Everyone comments on how clear and readable my SSB is over long distances (300+ miles) with a single 12 element K1FO antenna 30' above ground on 2 Meters. HINT - HINT Nag, nag, nag ;-) I know. It's like trying to push water uphill. Not to worry. I have masts, antennas, a rotor, and finally, decent weather. Also a brand new low-band wire antenna. The only way to hide this stuff from my wife is to actually put it all up. It better happen soon because she's been coming up into the shack a lot more frequently lately for some reason. 73 Frank AB2KT
Re: [Flexradio] In a sentimental mood
Bob -- I'm not saying that VST is directly applicable - but why not this concept on a modest scale with SDR? We haven't really begun to see the diverse applications people will put this kind of radio to, given the right interfaces are present. We have no disagreement whatsoever about helping people do what they want with the code. Let ten thousand flowers blossom. The issue is whether modularity in the VST sense is the right thing to do here. I can see why it would be appealing, superficially. But I don't believe it's absolutely necessary, and I believe that an effort to design in that kind of modularity uniformly for this system is misplaced. Here's why. First, consider why Steinberg and others enabled plugins to begin with. It's because their applications are closed, sealed up tighter than a drumhead. Remember too that the development tools required to build an entire application like Cubase are quite elaborate and extensive, while plugins can be less demanding that way. Furthermore, plugins make sense in an application which is just too huge to support an ongoing edit-compile-load-debug cycle. For example, it would make very little sense to have to rebuild FireFox every time just to perfect a little widget down in the lower right-hand corner. Now. Consider the SDR1K software. Under Linux, the DSP and audio chain are *already* modularized in the VST sense, with a tremendous array of options and existing plugins. The hardware control is unlikely to be a subject of much tinkering, once it's completely remotable. The console is already in Python under Linux, and the consensus is that in the new version, the "virtual radio" layer will be in Python too, in all versions. Once again, that means that it's designed and written in such a way as to yield the benefits of "modularization" without having that feature designed in explicitly. That leaves, literally, only the gui open for debate. Since the Linux version (and the eventual Mac version) shares the good traits of Python and PyRo with the virtual layer, the question is moot on that platform. It leaves only the Windows gui up for debate. Where we wind up is at a fork. My contention is that, in order to achieve the kind of modularization in the DSP under Windows that already exists under Linux, substantial modifications might have to be made that would cause the two versions to develop independently. Similarly the gui, for those who prefer to keep it in C#. The real point I was trying to sell was that a fork is inevitable, indeed desirable, and that it's going to happen soon. One of the major motives for it is precisely to keep the versions manageable on their respective platforms and easy for people to push around to their heart's content. Designing in "modularity" across the board is not necessary for that, and would only add an additional level of complexity where it's not required. 73 Frank AB2KT
Re: [Flexradio] In a sentimental mood
Bob Now all that's needed is to get Frank a decent 2 Meter antenna so he can hear first hand the results of his and your efforts thru my 1500 Watts 102.3 miles away. Everyone comments on how clear and readable my SSB is over long distances (300+ miles) with a single 12 element K1FO antenna 30' above ground on 2 Meters. HINT - HINT Phil, K3IB - Original Message - From: "n4hy" <[EMAIL PROTECTED]> To: "[EMAIL PROTECTED] Biz" Sent: Thursday, September 01, 2005 9:45 AM Subject: Re: [Flexradio] In a sentimental mood > No need to disagree gently. You should hear it when we disagree in not > a gentle manner. It can be heard for two counties. > > Something has been misunderstood. Frank has been the leading proponent > of the rapid movement to modularity and has been everyone's adviser on > matters related to the GPL. Frank has spent 35+ years doing computer > generated music, having studied synthesis since he was an undergraduate > at Princeton. I think you misintepreted something he said. > > Bob > N4HY
Re: [Flexradio] In a sentimental mood
No need to disagree gently. You should hear it when we disagree in not a gentle manner. It can be heard for two counties. Something has been misunderstood. Frank has been the leading proponent of the rapid movement to modularity and has been everyone's adviser on matters related to the GPL. Frank has spent 35+ years doing computer generated music, having studied synthesis since he was an undergraduate at Princeton. I think you misintepreted something he said. Bob N4HY [EMAIL PROTECTED] wrote: Unless I've missed the point, I have to gently disagree with Frank on the modularity issue in that I think it has very real practical benefit. You've only got to check out the music software scene to see how fruitful and mutually beneficial Steinberg's VST modular 'plug-in' technology has been. Fair enough, the quality varies enormously, but the rich variety of work out there would never have happened otherwise. This utility has extended far beyond the original authors' ideas, I'm sure. The end result is that musicians now have an enormous number of instruments and effects freely available for use. The dross gets discarded and the good stuff perpetuates. The VST interface is very well defined and there is an SDK which provides an empty 'plug-in ' project and plenty of examples to provide guidance for budding programmers. I'm not saying that VST is directly applicable - but why not this concept on a modest scale with SDR? We haven't really begun to see the diverse applications people will put this kind of radio to, given the right interfaces are present. Does it all boil down as to whether this degree of open architecture is a commercial benefit or not? From the experimenter's point of view it would certainly seem to be a good thing in order to widen the application of the radio. What do you think? Cheers, Bob G4BBY ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
[Flexradio] In a sentimental mood
Unless I've missed the point, I have to gently disagree with Frank on the modularity issue in that I think it has very real practical benefit. You've only got to check out the music software scene to see how fruitful and mutually beneficial Steinberg's VST modular 'plug-in' technology has been. Fair enough, the quality varies enormously, but the rich variety of work out there would never have happened otherwise. This utility has extended far beyond the original authors' ideas, I'm sure. The end result is that musicians now have an enormous number of instruments and effects freely available for use. The dross gets discarded and the good stuff perpetuates. The VST interface is very well defined and there is an SDK which provides an empty 'plug-in ' project and plenty of examples to provide guidance for budding programmers. I'm not saying that VST is directly applicable - but why not this concept on a modest scale with SDR? We haven't really begun to see the diverse applications people will put this kind of radio to, given the right interfaces are present. Does it all boil down as to whether this degree of open architecture is a commercial benefit or not? From the experimenter's point of view it would certainly seem to be a good thing in order to widen the application of the radio. What do you think? Cheers, Bob G4BBY
Re: [Flexradio] In a sentimental mood
Hey Jose! Don’t worry, after we get over all this “chapter and verse” stuff, I’ll get it all stirred up again by suggesting we modify the Console front panel and add a CW decoder or something of that nature. GPL is “Religion” the Console is “Politics”. In the old saying “Never discuss Religion and Politics”. I have refined that abit to add “At least not at the same time”. Eric2 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of José Dumoulin Sent: Wednesday, August 31, 2005 2:51 PM To: FlexRadio@flex-radio.biz Subject: [Flexradio] In a sentimental mood Hi Friends This is one of my favoured songs. I have been reading the last posts from some of you, guys (Ahti, Bob, Eric1, Eric2, Frank, Gerald, Jim, Sami - alphabetical order) :'( I was afraid of seeing this epistolary correspondence degenerate into a brawl. The positive side is that I learned a few new words. Remember this sentence that you could read in the saloons : Don't shoot the pianist down. :-) Then, as a sort of calmness after the storm, Phil, N8VB, came and informed us of his progress with SharDSP and other stuff. Many thanks to Phil, Sami, Jim, Gerald, Frank, Eric2, Eric1, Bob, Ahti. 73 - José
Re: [Flexradio] In a sentimental mood
Ahti Aintila wrote: Thanks to Frank for hollering, but why didn't you holler louder? Honest answer? Because (1) you should choose your battles with care, and (2) in the end, the Windows version is of no importance to me personally. Everybody likes to cherry-pick ideas from Fred Brooks. My two favorites are, in paraphrase: you throw the first version away; and adding bodies to a project doesn't help. That's why the idea of architectural documentation is amusing. It isn't until right about now that we actually know how a system like this should be written. Bob N4HY and I have done similar things in the past, but with nowhere near the tight integration of hardware and software that's necessary with the SDR1K. Our "architectural sketch" was the half-dozen or so systems we've done together before. Now we have a much better idea, and a lot of things about the future versions are going to reflect what's been learned in this effort. It's also why the emphasis on modularity strikes me as a bit fetishistic. To some degree, "modularizing" a system is meant to facilitate contributions from a larger group of programmers. But by the second of my cherished Brooks principles, piling on contributions isn't really going to yield improvements. So it's more of a democratizing gesture than a blueprint for development. The history of successful open source projects indicates something quite different. The way these projects evolve is not by incremental contributions, but rather by forking. Most forks don't survive. Often the major contribution a fork will make is to highlight features that need to be incorporated back in the main branch. One of the major features that the 1.5 design will exhibit is this: it will be very easy to fork. And that's a good thing. 73 Frank AB2KT
Re: [Flexradio] In a sentimental mood
Hi Friends, Thanks to Bob for the GREAT news: MODULARITY FIRST! Thanks to Frank for hollering, but why didn't you holler louder? Thanks to the software developers for plodding along. Thanks to the epistolary correspondents, those will be needed more often. Many thanks to José for the conclusion. We all learned a lot more than new words only. 73, Ahti OH2RZ - Original Message - From: José Dumoulin To: FlexRadio@flex-radio.biz Sent: Wednesday, August 31, 2005 9:50 PM Subject: [Flexradio] In a sentimental mood Hi Friends This is one of my favoured songs. I have been reading the last posts from some of you, guys (Ahti, Bob, Eric1, Eric2, Frank, Gerald, Jim, Sami - alphabetical order) :'( I was afraid of seeing this epistolary correspondence degenerate into a brawl. The positive side is that I learned a few new words. Remember this sentence that you could read in the saloons : Don't shoot the pianist down. :-) Then, as a sort of calmness after the storm, Phil, N8VB, came and informed us of his progress with SharDSP and other stuff. Many thanks to Phil, Sami, Jim, Gerald, Frank, Eric2, Eric1, Bob, Ahti. 73 - José ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Re: [Flexradio] In a sentimental mood
Mon Ami! Merci Beaucoup. Mai chaque jour semblent comme un bol de cerises! (May every day seem like a bowl of cherries). Bob N4HY José Dumoulin wrote: Hi Friends This is one of my favoured songs. I have been reading the last posts from some of you, guys (Ahti, Bob, Eric1, Eric2, Frank, Gerald, Jim, Sami - /alphabetical order/) :'( I was afraid of seeing this epistolary correspondence degenerate into a brawl. The positive side is that I learned a few new words. Remember this sentence that you could read in the saloons : *Don't shoot the pianist down*. :-) Then, as a sort of calmness after the storm, Phil, N8VB, came and informed us of his progress with SharDSP and other stuff. Many thanks to Phil, Sami, Jim, Gerald, Frank, Eric2, Eric1, Bob, Ahti. 73 - José ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
[Flexradio] In a sentimental mood
Hi Friends This is one of my favoured songs. I have been reading the last posts from some of you, guys (Ahti, Bob, Eric1, Eric2, Frank, Gerald, Jim, Sami - alphabetical order) :'( I was afraid of seeing this epistolary correspondence degenerate into a brawl. The positive side is that I learned a few new words. Remember this sentence that you could read in the saloons : Don't shoot the pianist down. :-) Then, as a sort of calmness after the storm, Phil, N8VB, came and informed us of his progress with SharDSP and other stuff. Many thanks to Phil, Sami, Jim, Gerald, Frank, Eric2, Eric1, Bob, Ahti. 73 - José
