| |||||||||||||
|
| |||||||||||||
Looking at Real Time for Linux, PowerPC, and Cell (developerWorks)Looking at Real Time for Linux, PowerPC, and Cell (developerWorks)Posted Aug 23, 2005 19:13 UTC (Tue) by mikec (guest, #30884)In reply to: Looking at Real Time for Linux, PowerPC, and Cell (developerWorks) by farnz Parent article: Looking at Real Time for Linux, PowerPC, and Cell (developerWorks)
I meant that each operating band is relatively narrow... given the cost (or lack of cost), the analog solution, you can easily cover that range and more and even do so "on-chip" so that it is part of the processor... That is you have N analog hard macros for handling whatever range you like.. all highly flexible and programmble - all they do is downconvert, so they don't need to very complex...
The argument that you can "future proof" hardware seems to sell a lot of people but if you look at real behavior and product life it is a "sales pitch" not a reality... When it comes down to it, most consumer electronics simply don't survive long enough to be moved from one generation of behavior to the next...
But, all that does not really matter, I am knowingly disagreeing with a good portion of the world in my statement that the balance of hardware vs software does not head in only one direction... It is somewhat sinusoidal as technologies, skills and applications move forward in time... We are WAY over to the software side now and I expect that product margins, support costs, development costs and ultimately power consumption are going to be the drivers of this balance back toward the middle...
Intel finally ending its seemingly endless pursuit of clock rate at the expense of everything else is a great indication (at least to me) of this trend. As is the proliferation of "applicances" (such as tivo, linksys etc..) which when you open them up are low clock-rate embeded processors coupled with hardware acceleration for the compute-intensive operations (mpX codec, IPsec, HDTV etc...)
These tasks were previously accomplished in sofware - once they stabilized, then the hardware showed up to do it faster, cheaper, cooler...
The same can be said for RF processing... Although it often seems to go through 3 phases:
There is another interesting aspect of this which is that the more is accomplished in hardware, the less undue control software vendors have over your use of it... It is amazing the clarity a little plasitc or ceramic packaging can bring to the consumer/producer relationship...
(Log in to post comments)
Looking at Real Time for Linux, PowerPC, and Cell (developerWorks) Posted Aug 25, 2005 3:39 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] a software radio has the huge advantage that it can receive multiple signals at the same time.
with hardware you have to have a physicly seperate receiver for each signal you want to receive.
there are a lot of situations where you have a lot of radios in one place to try and monitor lots of signals (and a scanner doesn't do the job, it hops between channels with one receiver, it still only listens to one signal at a time)
in addition, software radios can handle new types of signal encoding with just software changes, including spread spectrum sideband, etc that would require hardware redesigns for traditional equipment.
and finally, there are some things that just can't be done reasonably in hardware that software makes possible. The advances in telecom speeds are mostly due to the audio-speed circuits being changed from being implemented in hardware to being software, the software has made it possible to adapt the signal to the lines (and detect the inteded signal from the lines) to a degree that was considered physicly impossible not too long ago, and these changes have made much of the broadband service that people use possible. we really don't know what will end up happening as this scales up to higher frequencies, but past experiance makes it clear that it will be things that we can't imagine today.
and before you say that hardware radios give you more flexibility, consider that you can't purchase a scanner in the US to receive some frequencies becouse the hardware to do so has been outlawed (cellular freqs for example). even excluding these limits, you are in just as much need to hack the hardware as you would be the software of a software controlled radio if the manufacturer decides to put limits in there.
besides the origional article just listed that as one of the things that could be done if performance was to improve that much, not that that was the only reason to improve performance to that level.
|
|
||||||||||||