[Top] [All Lists]

[TenTec] software for the Jupiter... what I would like to see..

To: <tentec@contesting.com>
Subject: [TenTec] software for the Jupiter... what I would like to see..
From: n9dg@yahoo.com (Duane Grotophorst)
Date: Thu, 28 Feb 2002 15:30:19 -0800 (PST)
--- Bill Ames <bames@aob.com> wrote:
> ..is an application that does not attempt to put an
> interface that looks
> like a radio on the screen. 

I couldn't agree more.

> I want something that is
> set up to support the
> activities that I use a radio for. This would
> require one to look at the
> functionality that is available for the Jupiter via
> software and putting
> together a GUI that supported the current need. For
> example, someone who was
> doing some SWLing would most likely want their GUI
> to support that task. If
> one were doing some analysis of spectrum and
> propagation conditions then
> another interface would be best. Some day we will
> have something of this
> nature, a GUI that is selectable depending on the
> activity.

I completely agree with these remarks too, so much of
what software define radios and software control can
give us is simply not being recognized by hams in
general. When building a tradition knobs and button
radio it makes perfect sense to try and put everything
on the panel that people *might* want to use. After
all once the radio is built you will always have what
you have, no provisions for adding or removing
controls as needed or desired. In the software centric
radio world those restrictions are completely removed,
there is no technical reason whatsoever that you can't
have completely different programs for different
needs/uses. In reality it wouldn't be much of a trick
to write software that makes a Pegasus/Jupiter a SWL
box, it is more or less a matter of simply ignoring
the TX commands/functions of the box.

And I would even take it a step further in that there
is no reason to not have several different firmware
loads (or perhaps just additional modes) for different
purposes or needs. As was pointed out earlier in the
week the Pegasus/Jupiter filtering performance is
bounded by the necessary design tradeoffs of signal
latency through the IF vs. decent QSK performance
because of the DSP's raw horsepower capability. In the
case of IF filtering there are times where a second or
two of latency doesn't matter much but having razor
sharp filtering does. Both cases can be accommodated
with appropriate firmware for each need. This roughly
exists today with the Ten Tec DSP IF radios and the
DSP-10 radio project, they do share closely related
DSP processors after all, but the DSP-10's DSP code is
optimized for the extreme weak signal work. I really
don't see why that kind of capability couldn?t be
written for the Pegasus/Jupiter/RX-350. And in the
case of the upcoming Orion with a presumably super
clean analog chain ahead of the DSP goodies, the
potential is even greater.


Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!

<Prev in Thread] Current Thread [Next in Thread>