[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: FT-847 and USB-to-Serial Converter

>Would that were the case with the FT-847 CAT. There's *nothing* dealing 
>with the memories, or with scanning; the only access you would have to 
>the memories would be by reverse-enginering the memory-clone data 

Which is no great loss. As long as you have the basic ability to tune
the radio to some specified frequency, you can implement your own
arbitrarily fancy memory and scanning scheme in host software. And it
can present a completely uniform user interface, independent of what
model radio is in use.

If you just want to program a particular radio's memories so it can be
used without a computer, that's an entirely different problem that
should be solved with a separate program written specifically for that
purpose. You'll probably need a different one for every radio model.

Badly designed computer interfaces are endemic in devices originally
designed to operate standalone. Ham transceivers are just one example;
I see the same problem with my Meade LX200 telescope and the Trace
power inverter in my PV system. In each case, the designers seem to
assume that the only use of the computer interface would be to
reproduce the device's original control panel on the computer screen
for manual use by a human operator. What's the point in that,
especially since so many devices now come with remoteable front panels?

> The clone funtions still have to be initiated from the front 
>panel though. CAT will let you *tune* the various VFOs, and set their 
>operating modes modes. 

I haven't seen a radio with more than one VFO in probably 20 years.
What modern radios call "VFOs" are really just CPU memory locations
selected with a front panel switch; there's only one actual hardware
VFO inside the radio. These "virtual VFOs" are a classic example of
the kind of feature that doesn't need to be exported over the computer
interface. The host computer can easily do the same thing itself.

>Well, that's basically my intention. In fact, the software uses a
>Java interface defining the generic core radio functionality used by
>the GUI front-end, basically an internal command set. It's left up to
>the author of support for a particular radio to write to that
>interface.  Naturally that interface needs to be sparse; it can't use
>anything that *any* supported radio can't do somehow.

Right. By the way, this is the exact same philosophy that underlies
the TCP/IP protocols used on the Internet. The goal was to run IP on
as many kinds of subnetworks and links as possible, so IP could not
use any features that were not already universal. Functions like
reliability and application multiplexing were moved upstairs to TCP,
operating on an end-to-end basis. IP itself was kept extremely simple.

>Hmmm. Yeah. I haven't tackled any real DSP stuff yet, although that's 
>certainly somethink I'd like to do in the future. For satellite things, 

Basic DSP functions like mixing, filtering and frequency shifting are
very well documented in the literature. Modern PCs are already plenty
fast enough to perform these functions in C at audio sampling rates
(Java may be too slow, though). Newer Pentiums and Athlons implement
various vector instruction sets (MMX, SSE, SSE2, 3D Now!, etc)
specifically designed for DSP operations. You generally have to write
assembler to use them directly, but libraries are appearing to make
life easier for the C programmer. I've started such a library myself
with the DSP primitives I found useful in my AO40 telemetry proposal.

One way to look at it is to treat the audio output from the radio as
just another IF, albeit at a very low frequency. The DSP then performs
the final down-conversion to baseband, along with the various filters,
etc, that you want. This is how many of the "DSP radios"
function. They typically establish an IF around 11 kHz, as that fits
everything nicely within the passband of a hi-fi digital audio A/D.


Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org