--- "George, W5YR" <w5yr@att.net> wrote:
> From the suggestions I have seen about improving the
> Pegasus and other
> digital radio capabilities, especially the
> processing of additional modes,
> it would appear that there is a general
> misunderstanding of the
> computationally intense burden that such operations
> imply. The reason that
> TT shows no interest in modifying their firmware is
> that it simply cannot
> be done that way and they realize that. Major
> changes would be required and
> the result might have a new name - something like
> "Orion."
I don't think that is totally true. While I have no
illusions that every conceivable narrowband mode could
be done with the existing Pegasus/Jupiter hardware,
quite the contrary. I am however convinced that there
could be more offered than currently is. Given that
the DSP-10 radio is built around a very similar
ADSP2181 it would imply that it's PUA43 mode could be
implemented in a Pegasus/Jupiter. Also considering
that the RX-340 is also built on the ADSP2181 would
also imply that it's superior filter shape factors
could be implemented, obviously at the cost of signal
latency as was discussed here on the reflector
earlier. Which would preclude good QSK. Is it
worthwhile thing to pursue? A reasonable debate to be
sure, but it shouldn't be just offhandedly rejected.
>
> Most digital mode programs use a soundcard with its
> support chipset plus
> the CPU plus a large amount of memory, etc. to
> develop the signals required
> for SSTV, PSK31, etc. operation. To expect that the
> comparatively
> low-powered "peanut" processor in a little rig like
> the Pegasus or Jupiter
> could even begin to do all that is to overlook
> practical and feasible
> limits.
>
As for memory requirements, comparing the existing
sound card modes to real-time DSP implementations is
apples and oranges. Much of the large memory
requirements for those programs is not for the signal
processing elements but is instead for the display
handling and so forth. You know those display elements
that I contend do not really belong on the radio
anyhow, but are instead better suited for a computer.
Which brings us back to the realistically needed
requirement to have a sufficient broadband means to
stream raw and/or minimally processed data to/from the
"radio" to a host computer.
I would agree that it is a legitimate debate whether
it is truly better to do that kind of processing
natively on the radio or on a host computer. However
connecting the radio to the computer via audio and
RS232 is not an acceptable means to properly handle
those modes.
> This gets back to the notion and misinformation of
> "software-defined"
> radios. You can never get the rig's processor(s) to
> do more than a certain
> amount of work in a given time. If the designer did
> his job right and met
> his price point goals, he used "just enough"
> processing capability to meet
> his assigned specs. Done right, there is precious
> little capacity left for
> getting more operations out of the processor. So
> much for the never-ending
> series of upgrading rig capabilities through the
> magic of "firmware
> updates." The firmware can never cause the
> processor(s) to do more than so
> much, nor can it do all that some "upgrades" night
> demand of the
> accompanying analog support circuitry.
This precisely illustrates the need for the folks who
design these radios to have a fundamental shift in
their design thinking/criteria for defining component
cost vs. performance for the DSP aspects of the radio.
They simply need to change from designing to find the
minimum capable DSP to do the previously (and probably
too narrowly) defined job. Instead use a design model
where you would chose the processor that offers the
best $/MIPS performance and then continue to write
code for as many modes and/or signal processing
features as you can until you run out of DSP
horsepower. Perhaps then the real limits of the DSP?s
capability may not be reached until long after the
radio has left the factory. Unlike the analog RF side
of the radio where added complexity will most often
hurt performance, adding complexity in the form of
code can generally (though not necessarily always)
offer large worthwhile gains in usability
features/functions if not performance.
>
> When radios contain the equivalent of a Pentium IV
> with half a gig of RAM
> and large mass storage, then we will start to see
> integrated functions in
> the "radio" - or should we call it a computer with
> some r-f circuitry
> tacked on?
For some interesting insight into this kind of
concept, look into the work being done by Lief, SM5BSZ
with his Linrad program.
http://nitehawk.com/sm5bsz/linuxdsp/linrad.htm
For what it's worth his baseline PC CPU requirements
are actually rather low. So needing top end CPU
horsepower is not a requirement for the basics of what
he's done. Nevertheless given the economic nature of
the PC business there no reason not to use a computer
that is at that best $/MIPS point anyhow.
Duane
N9DG
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/
|